When I lived in British Columbia, Canada, I used to go running in the forests behind our house. My housemate (appalled at the idea) insisted that I run with his dog to keep the grizzly bears away. At the end of one run I was chatting with a neighbour, a retired Canadian mountain guide with a huge grin and a beard to match: “Ain’t no point runnin’ with a hound,” he drawled. “Too fast. Yeh need a buddy slower‘an you are. Let the bear deal with him and you keep on runnin’!”
I never came face to face with a grizzly (and an irrational part of me is a little disappointed about that…), but I was reminded of this story recently when talking to a product-manager friend who was colourfully describing her last one-to-one meeting as a “mini-bollocking”. A few weeks ago she’d started a new project with her team but her group lead was now reproaching her for not having a clear plan and target metrics. As we talked through the project it became clear that she’d actually made good progress in understanding and thinking through the problem, and that – naturally – the issue was more complex than it had initially appeared. Most of her thinking, though, was just in her head.
Feeling like you need to have all the answers before presenting a strategy is certainly something that worries me. I don’t want to appear as though I’ve missed anything obvious and I find it hard to share a plan before completely comprehending the issues. This, of course, is a mistake (not to mention impossible). No plan survives contact with the enemy, and sharing a work in progress earlier means you could learn an important insight or discover a radical new possibility. Easier said than done though.
“No plan survives contact with the enemy”
– Helmuth von Moltke the Elder, German Field Commander
The gap Into Agency
Kate’s issue was not her lack of progress, but the gap between her actual progress and her perceived progress. Mark Logan, former COO of Skyscanner, would say the key to resolving this is to gain agency. In other words, building enough trust or confidence to get a licence to operate, and bringing your key stakeholders along on the journey. This doesn’t necessarily require in-depth reports or detailed plans. People may just need to hear the story of where you’re going, the steps involved, and where you are now. It’s your job to learn what you need to do to get agency. How to give yourself just enough space to breathe and stay far enough ahead of your stakeholders that they’re not worried about you. They have plenty of teams and projects to worry about, so you need to make sure that they think your project is on track.
You need to run faster than the slowest person being chased by a bear.
Joel Spolsky tells the story of when he was product manager for Excel Basic. Back in the 90s every major Microsoft feature got reviewed by Bill Gates. They were known as BillG Reviews, and the tradition was to count the number of times Bill said the F word. The lower the number of F-bombs, the better. The day before Joel’s BillG Review he noticed something worrying. Dates in most programming languages are stored as a number, counting up from some reference date in the past. For Excel, the reference date is 1st January 1900 (so the 2nd January 1900 is 2 and 9th September 2017 is 42987). However, for Excel Basic, the reference date was 31st December 1899, even though both Excel and Excel Basic store today’s date as exactly the same number! Joel did a lot of digging and discovered the reason was due to a cascade of quirks, including 1900 not being a leap year because it’s divisible by 400, and Lotus 123 Worksheets (which Excel needed to import) having to fit in 640Kb (yes, kilobytes) of memory. The BillG Review arrived. Bill Gates asked increasingly difficult questions until he expressed concern that Excel Basic wouldn’t handle all the date functions in the same way as Excel. “Yes, it will,” Joel replied, “except for January and February, 1900.” After a moment of complete silence, Bill got up, said “OK. Well, good work,” and left. Joel had gained agency. And a mere four F-bombs!
Controlling the Narrative
In Kate’s case she didn’t need that level of detailed technical knowledge, she needed to manage expectations and reassure that she had everything in control. She’d been tasked with building a product to automatically detect and repair failing micro-services. In a perfect world, success would be easy to measure: all failures instantly detected and repaired. A more nuanced version would put a realistic framework around that. For example: 95% of failures detected within 10 seconds, and 90% automatically repaired within one minute. Even that, though, describes an ideal end state of a large, complex project.
The key for Kate in gaining agency was to break the problem down into milestones – achievable targets or goals, each with a distinct outcome that moves her team closer to the (too-easily-stated) overall measure of success. Then she would need to ask “what do you need to achieve those” (for example, are there established methods for detecting failures or is that a body of work in itself) in order to uncover any smaller goals and determine where the primary focus should be.
For example, automatically detecting failures and notifying engineers would deliver value, even though the fixes would be done manually. It would also mean you could define a simpler target metric, as an intermediary, because you could temporarily ignore complications around automatic repairs. Similarly, being able to automatically detect one failure is a valuable step towards automatically detecting all failures. Especially if you target a high impact service. There are at least two ways of measuring impact in this scenario though: how important the service is, and how often it fails. Kate had done the correct product management thing of asking “is this a problem that actually needs solving?” without considering whether there was anything they could tactically achieve in the meantime. This led her to discover there was no tracking in place to be able to measure how often these services actually failed, and if they did, which of them failed most often.
At this point, Kate made the easy mistake of holding all this good thinking in her head – all the multiple scenarios and moving parts. Knowing that she had to work out X, Y, Z before moving on to Q, R, S, but forgetting that nobody else could see any of this. Her group lead was operating under the reasonable leap of faith that these services did fail (there were certainly qualitative observations to back this up) and that when they did, customers got a poor service and the company lost money (which appears logical, even if there was no measure of the actual revenue loss). Meanwhile Kate was operating under good product-management first principles: understand the problem, and assess the impact or opportunity.
She needed to close the gap between her and her boss. Crafting a narrative was a big part of this. Sharing the story of the high-level journey, with milestones and outcomes. Communication is the foundation of gaining agency, but execution also matters. Kate could demonstrate progress by working under the assumption the leap of faith is correct (while at the same time collecting data to support or refute it). In the interim she could use other, more readily available metrics (like the number of times a service is called), to identify a target service on which they could try out methods of automatically detecting failures. Each small step would build trust in her and her team.
One thing’s for sure: if I was trying to outrun a bear with Kate, there would be no one between me and the bear!
Comments 0