-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbeyond.html
118 lines (93 loc) · 12.8 KB
/
beyond.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
<html>
<head><title>Working Beyond Support - Tactics for Increasing Effectiveness across the Company</title>
<style type="text/css">
*{font-family: Verdana;}
</style>
</head>
<body bgcolor=black text=white link=yellow vlink=orange>
<h2>Overview</h2>
Support often struggles to work well with other teams and in general keep up with the business - in terms of changing and new features, sales techniques, marketing campaigns, and engineering effort allocation. This talk was about ways to improve that situation, and was delivered at <a href=http://elevatesummit.co>Elevate Summit</a> 2016 in Austin.
<p>
<h2>Introduction</h2>
How many of you feel like your Support team is completely well-respected and thoroughly effective in driving things at your company like product direction, engineering effort, marketing campaigns, and hiring budgets? C'mon, raise your hands. OK, you 3 can leave. For the rest of us, I have some ideas and battle scars to show how well they worked, or didn't work, from my time during the growth of New Relic's Support organization.
<p>
<h2>The Road from Success</h2>
I started that leg of my support career as employee #3 on the Support "mini-team" that was just starting to self-organize because engineering was too busy...engineering...to provide much customer support. Nonetheless, the engineers were still on call to help with support questions, and had just been relieved of duty in our ZenDesk queue, so those folks were pretty customer-savvy. Over the next 4 years, Support turned into its own full-fledged team, and then into its own Customer Success organization, and finally got so big it moved out of engineering's office plus led the opening of the first overseas office in Dublin.
<p>
<h2>The problem</h2>
While my personal ally count was high, since I had watched the company grow by 10x and customer success org grow by over 20x, most of the rest of the team did not have any pull with Product, Marketing, or Sales...and even Engineering was starting to forget that we were on the "same team". Needless to say, my Support colleagues were a little bummed out about the disconnect.
<p>
Specifically, marketing would advertise nonexistent products, Sales was using misleading terminology and filing terrible support escalations, Product was deprioritizing all bug fixes in favor of new features, and even HR was stodgy about getting us more people as we grew from a ticket queue I could manhandle all by myself into something with over 1000 technical tickets a week. Some of those tickets took hours to research and required work across growingly distributed Engineering and Product organizations to supplement our knowledge.
<p>
<i>"I can see how it <b>is</b> working...but how is it intended to work? Is what this customer is trying to do even a good idea? Oh, you work entirely outside of my work hours on another continent. Um. I'll look forward to an answer in a day or two..."</i>
<p>
<h2>Brainstorming Part I</h2>
Realizing that I as a resource was neither scalable, nor did I have a high enough bus factor for the team I loved to count on me, we started brainstorming about better ways to work with the rest of the company. We had a million ideas, but many were expensive, lacked buy-in from our intended partners, or continued to rely on personal connections. So we went back to the drawing board - what was ALREADY working that we could leverage? And what was worth fighting for?
<p>
Of course the place to start working on a huge (and growing daily - new products, new teams, new hires) multivariable equation is to figure out what parts of the problem are actually the most important. That's when we got some project management in the mix, and decided to focus on some of our highest pain areas:
<p>
<ol>
<li>Gathering and maintaining in-depth up-to-date product knowledge, especially for enterprise-level solutions that we couldn't easily simulate on our laptops, and effectively communicating where the product fell short to people who could effect change.
<li>Playing nice with sales.
<li>A growing disconnect with the Product org, who were the ones who decided what engineering would work on.
</ol>
<p>
But what underlaid most of these? I never actually met anyone at the company who chanted that broken stereotype that suggests that <i>"Support is just an entry-level, foot-in-the-door stepping stone of a job"</i>but I soon realized that despite that, the reason I could work so well across the technical organization was that there was a shared respect - I understand that a bug fix is more than just a line of code, and I'd had time to get to work with most of engineering and meet them halfway when I asked for help with escalations. I'd traveled to the Sales Office and held office hours to connect with many of the folks there. But maybe they didn't know all of my teammates as well. And these folks were sometimes quite fresh to the world of tech and perhaps even the new to working in an office at all, and were somewhat less conversant with the development lifecycle. And remember how a single person doesn't scale? Yeah.
<p>
<h2>First Pass Solution</h2>
So I started delegating my respect. I carefully selected proteges, crammed all of my historical knowledge into some wiki docs that I forced them to grind up and snort, and then introduced them to a specific engineering team with a weeks-long handoff. Guess what - that also didn't scale - we were at over 20 engineering teams (and growing) that were in a constant state of flux (who worked where, which team owned what) and the company had grown enough that we just didn't know someone on every team well enough to get us in the door everywhere, and I couldn't babysit that many sub-relationships to make sure they were working anyway.
<p>
<h2>Brainstorming Part 2</h2>
Back to the drawing board again. This time we came up with a value proposition to pitch, and this was the magic ticket - it worked well with all of the teams we wanted to interface with.
<ul>
<li><b>For Engineering and Product</b>: <i>"We have some info that you could use about how people are using your product and where it is fragile, and we'd like to get embedded with your team to talk about it."</i>
<li><b>For Sales</b>:<i> "We can help you sell smarter, decrease our response time to your cases, and help reduce churn on our monthly subscription product - which means your commission is bigger."</i>
<li><b>For Marketing</b>:<i>"Hey, you need a feedback loop that doesn't look like a Funnel. We have some unsolicited customer (and potential/former customer) opinions that you'd probably be interested in..."</i>
</ul>
<p>
A big piece of the the value proposition was quality: fewer and less surprising escalations for Engineering, better and reduced volume of feedback to Product. And of course, helping make sure Sales was closing their deals with actual answers rather than handwaving, which meant their customers stuck around for awhile.
<p>
This time, things went over surprisingly well!
<h2>Brass Tacks & getting down to them</h2>
It's easy to talk in metaphors, but let's get down to examples of what didn't work and how we turned it into something that did work.
<p>
I'm going to provide some examples of things that worked and things that didn't. There are funny slides to go with this but they don't add much to this web page so they aren't here...
<p>
<h3>NOPE</h3>
Complaining to Product that there were too many open bugs and we need them all to be fixed. We were just echoing our customers' sentiments, so we thought it would be a slam dunk.
<h3>YUP</h3>
Arriving for a Product planning meeting with a prioritized list of Support's top 5 bugs with the # of reports & amount of money the customers reporting them were worth. When we asked a "million dollar question" or delivered a "hundred customer impact" report, Product sat up and listened, and agreed to meet with us regularly on the same topic. And we started adding impact assessments to any bug we came across that seemed important, so that they would have that info in hand in case someone else - say, Sales - came to them with an escalation.
<h3>NOPE</h3>
Complaining that sales interrupted us constantly with the same product questions over and over yet couldn't file a decent support ticket to save their lives. Working with each individual salesperson worked great while I could still make a tour-du-sales-cubicles in a day, but the sales team was growing (and churning) faster than we were by a factor of more than 2!
<h3>YUP</h3>
We'd like to offer a channel in our corporate chat system where there will always be someone from the Support team on duty to answer your questions within 15 minutes (or your money back, guaranteed!), and further, we'd like to come offer your team training on how to file tickets that will get quick answers and touch on some of the frustrations you can prevent for instance by avoiding certain vocabulary - "real time" does not mean what you think it does!
<h3>NOPE</h3>
Hi Dev Team! We have 2 dozen escalations in your product area that we don't know how to troubleshoot; we'd like to get all of these customers an answer today!
<h3>YUP</h3>
We'd like to assign someone to your team who can attend your standups and sprint planning, to understand your workflow and schedule, and that person will also pair with you on any escalations - with the goal that you'll train them to answer that question themselves next time. While they're working with you, you'll train them on how to file bugs that match your workflow - bite sized chunks or epics, sufficient supporting info, enough context to be sure you're solving the right problem. Further, in developing our knowledge alongside the development teams, we generated a raft of internal documentation about not only "how X works" but "who knows what this type of error really means" and even "how to fix Z if it's something we have access to do."
<h3>NOPE</h3>
complaining to DevOps that our "transparent communications" were awesome and customers loved them - but that a little timeliness, editing and customer service on our status page could go a long way to deferring many tickets and calming customers down.
<h3>YUP</h3>
Hey, can we train some people up to understand what's going on with service interruptions, send them to the "war room" to listen along when there is a problem, and handle all the public communications ourselves?
<h3>NOPE</h3>
Hey the docs are wrong, halp!
<h3>YUP</h3>
Here, I improved the docs for us :)
<h3>NOPE</h3>
Oh, you want to give us some money? Uh, here, let me read the pricing page to you.
<h3>YUP</h3>
Hey, I know a guy who can talk terms and has the authority to extend your free trial and cut you a deal on your subscription costs. Let me introduce you to your account exec!
<h2>Simpler Pro-Tips</h2>
Some other ways we did outreach were a little more basic: appealing to human tendencies.
<p>
<ul>
<li>People like entertainment, so we sponsored a monthly game night for the company. Suddenly, Support was no longer faceless for the folks who hadn't worked with us directly. We enjoyed the same beer and pizza and shared the same highs and lows over Settlers of Catan and DevOps against humanity, and respect started to grow. We even got Dev's (rather larger) budget to pay for it...
<li>People like effective training, and Support are always Product Experts. We got really good at training ourselves to cope with our explosive growth and constant onboarding needs, and then branched out to the engineering organization. When one of the first things you learned as a new developer was that Support actually knew more about the architecture and history of your microservice soup than anyone else who had time to talk to you, that Respect blossomed.
<li> People like helpers. When any team (from DevOps to Marketing) asked for participants in simulated exercises (eg: roleplaying a large outage, or understanding customer use cases in detail), we jumped at the chance to participate, and worked internally to define the most effective personas to portray (eg: demanding enterprise customer) and then sent a good presenter to work with them using that information.
</ul>
<h2>What can you do?</h2>
In the end we actually lived a pretty agile lifestyle - we tried things, assessed whether they were working, and then adjusted and tried again. When something really worked for one team, we'd try to apply it to other teams or arms of the business. Are things perfect now? Well, I left because I wanted a job where I could scale - but support at New Relic continues to scale and enjoy a good relationship with dev, sales, and product, so it seemed like it worked.
<p>
Now - go forth and embrace the chaos, and find ways to be that team that everyone in the company *wants* to work with - whatever that looks like in your organization. Remember the themes: generate respect (you deserve it! but you may have to show, not tell), come to them on their terms - with your issues, and don't forget to give back to the people you rely on when you can.
</body>
</html>