Last post I told you about “Project Boring” and I elided the details with an all too clever joke. I’d like to say I’m now going to go into those details by popular demand, but not a single person asked for this.
To recap: I had an amazing team who took a messy, slow onboarding process and started posting borderline unbelievable improvement stats. I can’t take credit for the results, but I can claim responsibility for the changes that enabled them. [link]
I started the way I always do – by annoying my new employees.
I looked over the shoulders of the technical delivery managers as they onboarded new customers. I wrote down what I thought was happening, asked many, many dumb questions, and eventually had a set of documents in my own words that all of us could agree were what was actually happening.
We repeated the same painful exercise with historical support tickets but this time we used a structured set of dumb questions. Why did a customer ask that? Where would they find the answer? What could we do so they never have to ask us again?
Once I had an understanding of the work the client had to do, from their point of view, we could start to see what was taking time, what was frustrating clients, and where we could improve.
We discovered a GitHub repository with an ancient SDK for products that no longer existed. A customer-facing Postman collection that was no longer being maintained. An out of date OpenAPI spec. Our API docs sometimes contradicted commercial contract language.
Through organisational change and drift, owners had shifted, mandates had shifted and nobody had noticed the holes opening up. These were not difficult things to fix. They just needed someone to notice.
The support tickets told us an unexpected story. Customers would go live, panic when they hit unexpected results that they thought were product bugs, but were actually integration errors. It wasn’t necessarily their fault – our product was complex and our docs were aimed at giving technical coverage of specific functions, not solution architecture.
The fix was straightforward. First, we provided guidance on integration architecture, aligned with the commercial packages we were selling. Second, we introduced go-live checklists. We wrote in a go-live review into the contract, so there was no confusion – you had to pass the check to get prod access.
This was the start of asserting control over the customer. It can be scary to demand things of a customer. But customers crave certainty, and it’s sometimes good to remember as a start up delivery team that you are the literal world experts in integrating your product. Everyone wins when that expertise is shared properly.
We were making real progress – customers had fewer surprises, the support ticket volume decreased, and we had started exercising our improvement muscles. Less chaos meant more time to improve the foundations.
Things were starting to look nice and boring.
Leave a comment