Customer success and Agile were destined to love one another. Here’s how we got them to date.
People have been asking us how we set up our Agile customer success team, and we discussed the concept in our last webinar and event. (If you missed the webinar, catch the replay here.) Those talks were fairly high-level overviews. We’re going to go into a little more detail this time.
Zailab, way back when
A year ago we, like many companies, had four ‘departments’ (although we insisted we didn’t) for everything relating to our clients and potential clients. Y’know, your usual sales, marketing, support and PR silos.
Our tangled ball of sales, marketing, PR and support became something of a crisis. That’s because when software as a service became a thing, it sidled up to the traditional model, folded it into a ball and stuffed it in a dumpster.
We solved (or are in the process of solving!) most of our problems with two interlocking tools: the customer success model and the Agile process.
Let’s just define those before we dive into the specifics.
Invented by Salesforce, the customer success model has a simple, compelling idea at core: you succeed when your customer succeeds. Therefore, it is in your best interests to help your customer succeed in any way you can.
Let’s stop to think about this for a second. Because it’s tempting to assume that means helping your customer get the best out of your product. But what it really means is that you take every opportunity (without being ridiculous) to help your customer do amazingly well.
In our case, for example, this is the difference between helping our clients set up our software and helping them iron out issues with their process.
Yes, it’s extra work, but this is where it’s at. Anybody who isn’t in on this won’t be around to complain about the extra work in ten years’ time. Trust us.
The Agile way was born into the software development world as a means to better manage large, complex projects. A comprehensive breakdown of the methodology is sorta beyond the scope of this article, but these are the core principles behind it as applied to our industry:
- Customer satisfaction over metrics and SLAs
- Value and service over rules and procedures
- Collaboration and openness over management and titles
- Continual improvement over rigid process
Our very own hypermind Kornel Steyn came up with these, and talked about the concept at our event on 27 August. You can download his slideshow by clicking here – and if you’re interested in the origins of Agile, see the Agile Alliance. (Note: it is software-centric, but many of its tenets are broadly applicable.)
Now that we’ve got the definitions out of the way, let’s work through how we implemented Agile and customer success – problem by problem.
The problem: we were discouraging accountability
Here at Zailab we work to cultivate an entrepreneurial spirit in all our staff. Everybody needs to think like an owner.
Trouble was, we were locking our talent down into their job descriptions. Sales people did sales. Marketing people did marketing. You get the idea.
It sounds like a reasonable separation of concerns, but look, it really isn’t.
‘Silos’ is the word for it. Yes, sometimes we worked together for the occasional project, but for the most part we were like little boats on a vast, foggy lake. We could see one another’s headlamps, but otherwise we were charting our own courses without so much as a compass.
And with this traditional sort of role-separation, nobody has the space to think like an owner. People look to the things they’re given control over, especially when times are turbulent.
We’re also blessed: our exceptional staff have diverse and complementing skillsets. Why, then, were we holding them back? They were frustrated. We were frustrated.
Thankfully the problem had a simple solution.
The solution: dispense with job descriptions altogether
We no longer have ‘roles’ in the customer success team. No but really: we do not have job roles in the customer success team.
Instead, we have tasks that require certain skillsets, and anybody with that skillset (within reason) can and will pick it up.
This means if a particular type of work requires more effort than another at any point, the team’s focus naturally falls on it. Everybody pitches in to take up the slack. (Yes, our team is made up of absolute champions and we love them to bits.)
We also make it a priority to get everybody up to speed with skills they don’t have but are interested in. We borrow from the software world here, where a thing called pair-programming has shown fantastic results.
The idea is simple: the person with the skill does the driving, so to speak; the person who’s up-skilling shadows them. This has more than a few benefits.
- It (obviously) improves the knowledge of the person doing the shadowing.
- It (less obviously) improves the knowledge of the person driving – because to teach a thing is to know a thing.
- It massively boosts creativity. The best ideas tend to come out of conversation, after all.
- It helps catch errors when you have somebody looking over your work as you do it.
- It brings the team closer together; instead of sitting in headphone-isolation, they’re interacting and learning about one another.
You might think that this practice would harm productivity. In the short term, yes, work might slow down. But in the long-term, you’ll start seeing massive gains – in quality of work, morale, and indeed speed.
The problem: traditional management doesn’t work
We’re fiercely (fiercely) opposed to the ‘do what I say’ varietal of management that is still, weirdly, pretty much the norm. The model tends to generate the old us-and-them mentality, tearing trust and getting in the way of closeness. It also usually robs people of their sense of ownership over what they’re doing – because they’re doing it for somebody else, not themselves.
So we swam in the opposite direction. We emphasized a flat hierarchical structure in which everybody was to take control of their own workload and responsibilities.
This worked well – but only when everybody knew what they had to do and how they had to do it. If we didn’t, well, it didn’t go down so grandly. The result: we spent a lot of time feeling aimless and frustrated.
Workshops! We had workshops. We had so many workshops they’d clog the shower drain after a busy day.
The workshops admittedly did a lot of good in helping us think about what Zailab actually was and who it was meant to be serving. But they didn’t get us out of our rut.
The solution: bring on a product owner and coach
First, we assigned a product owner to help align the team’s activities with the vision for the product itself. We’re incredibly lucky to have Catherine Collins as our product owner. She’s largely responsible for the monumental task of setting down our software roadmap, and now she’s tasked with ensuring the customer success team’s efforts correlate with that roadmap.
In other words, Catherine crafts the customer success team’s long-term plan, and pulls items from that vast backlog at the beginning of every two-week sprint. She also runs interference on anybody who tries to slip us unsanctioned work from the sidelines, and for that we are ever grateful.
But importantly, Catherine is also with us in the trenches every step, able and willing to do any of our tasks with us. If you’re into military analogies, she’s like that general every soldier would follow into Hades. Yeah.
Another key role we filled was that of Agile coach. If customer success is there to help the customer succeed, the coach is there to help the customer success team succeed.
In our case the lovely Sebastien Ejdaa is responsible for this onerous task. Sebastien (in addition to his other duties) makes sure we’re not held back by anything, and keeps us to our word.
It’s critical to note here that Sebastien was voted into this servant-leadership role after a trial period during which the position was rotated among those who were interested. (Not many were – let’s just say being a coach is not all croquet and caviar.)
Think of the product owner as responsible for the macro and the coach as responsible for the micro.
The effect the two have had on our team is real night-and-day stuff. Suddenly our efforts became coordinated and goal-driven; we’re now moving together, as one.
It’s remarkable, it really is.
The problem: we were too far from the product
When we started out, there was a sharp divide organisation-wise between the makers (our dev team) and the sellers (what is now our customer success team).
Now you have to understand: we can’t do our job if we don’t know the product so well we’d recognize it blindfolded in a nightclub by the sound of its breathing (don’t ask). We also absolutely have to be able to help shape development with information such as customer feedback, bug reports and market research.
We did our best to do all these things, but we were falling short. We weren’t aware on a day-to-day level of precisely what the dev team was doing. They, in turn, weren’t aware of what we were doing.
Even small gaps in this area are a big problem in the field of software-as-a-service. And with our product still undergoing high-pace development, the effect is greatly amplified.
The result is a sort of slippage – the two decoupled teams drifting away from one another day by day. The ever-widening space between is one of the places people refer to when they say stuff is ‘slipping through the cracks’.
The solution: integrate customer success into dev
The idea here is grander than the subheading above might suggest. What we’ve essentially done at Zailab is absorb everybody (including the development team) into the customer success model. We are one giant customer success team – because every aspect of our work is geared toward helping our customers succeed.
Now how does this work on the ground? Essentially we needed to create a two-way feedback loop between the new team and those responsible for creating the software.
To begin with, each member of the core customer success team is part of one of the software ‘feature teams’ on the dev side. We attend their meetings, we give feedback during design and modelling, and we report back on the development cycle during our own meetings.
During company-wide demo sessions, we get to see the well-deserved pride on our developers’ faces when they talk everyone through their creations – and then we do the same with them.
We also jump in to help test the software, especially during late deploys that can sometimes drag a whole night down with them. We’ve even started assigning customer success team members as release officers, responsible for ensuring deployments go smoothly.
The result is astounding. We have much more insight into the software, and our knowledge is always freshly milled. We can now plan important work on our side with greater foresight. Perhaps most importantly, we’re now part of the bigger team, where once there was a definite divide.
It does the heart good, it does.
That about wraps it for starters. We’ve barely scratched the surface of this topic – so you can be sure we’ll revisit this topic in the coming weeks.