Some of the best parts of my time at Mozilla were the moments of brilliant humility. We had assholes, to be sure, but there would be these moments…
20 people sitting around a conference table during an all hands. Each of them brilliant. Brilliant like I’ve rarely met before or since. The people in that room could reinvent the internet from sand and germanium on up if humanity ever misplaced the one we had. And every one of them in that room convinced that they were the dumbest one there.
It felt like we could out-think any problem. I loved those moments.
And, like so many nice-feeling stories I write about here, they were quicksand and I didn’t see it.
Bullets
I was in one of those moments the first time I read the lead bullets essay. It’s a story borne out of Netscape, Mozilla’s origin myth, and still I almost skipped it. I don’t love war metaphors in business; they often feel callous and gross. But somehow this essay got through.
It kicked me in the gut. It lit something up that I had been feeling but hadn’t labelled. If you haven’t read it yet, go. It’s not long. I’ll wait.
What hurts about that essay is that I, and most of Mozilla, had gotten addicted to silver bullets. I don’t blame anyone in tech for falling into the same trap. Our industry is built around disrupting. We think different. It infuses our language and our value systems because it’s an incredibly powerful tool set.
People rag on “disruption” as an overused word, and I get that. But holy shit our industry really does blow up some stuff. It’s so rewarding to fix an entire class of problems. It reaffirms our belief that there are silver bullets out there if we’re smart enough to look for them.
Never mind that we push out other important stuff to get those wins. Never mind that it’s impossible to appropriately size or plan around those insights. Never mind that they aren’t as frequent as they seem, and our examples are drenched in survivorship bias. They happen, and they feel great.
The Easy Way Isn’t
Is your organization lured by the same temptation? Have you fallen into the same quicksand? It’s easy enough to figure out:
Imagine a problem comes up that would be labour-intensive to fix manually. You discover that thousands of new accounts haven’t been tagged with the right attributes. Or you have an API change that’s going to break a whole ecosystem of third party apps. How do you respond? How does your team approach the problem?
Everyone will, of course, look for the obvious smart fix first. Can we auto-deduce the missing tag? Can we shim the old API? Let’s say there isn’t one. Now what? This is where it gets really interesting. This is where the ground sinks beneath you.
Many companies, smart companies full of smart people, will keep looking for a way to think themselves out of it. They’ll look for a very, very long time. At small scales, this is the running joke of engineering. Every programmer has a story about the time they spent longer automating a task than it would take to just do it.
But some organizations spend years on this stuff. They spin up teams for it. They find a glimmer of hope, announce that a fix is on the way, and then delay over and over as they discover that the problem goes deeper. They are addicted to out-thinking. The sunk costs are devastating.
You don’t have years to spend on this stuff.
The Only Way to Win is Not to Play
The organizations that dodge this trap share a crucial adaptive trait. After that initial sniff test to see if there’s a quick way out, these groups stop chasing after an elegant solution and just do the grunt work. That’s it. They see the ground shifting under them as they start to contemplate a brilliant way across. And they stop it dead. They sense that it’s not safe. And they’re right.
Need to re-tag those accounts? Grind it out through a mix of partial, unsatisfying fixes and good old fashioned repetitive labour. Need a way to port those third party apps? Send some emails. See which ones you can convince to rewrite on their own, and volunteer your own developers to help fix the rest.
Do the hard work. Put the problem to bed, and move on. This isn’t news. I’m not the first to suggest that grinding works. It’s what Paul was on about, and he wasn’t first either. Neither was the lead bullets essay. But I still meet plenty of folks stuck in quicksand, so it seems the message bears repeating.
3% Wins.
Not all problems get the grunt work treatment. Sometimes incomplete solutions are more damaging and you do need to fix things the right way. A sign of a healthy team is that it should be easy to cite examples of each. But many teams, particularly those with engineer founders, strongly prefer “elegant” solutions to grunt work. And it’s where you can win.
While your competitors look for silver bullets, push through. You pay an upfront cost in ugly labour that your competitors won’t. But with your team no longer distracted, every day that goes by is a little incremental win. Not huge, 2 or 3%. For a big, really distracting problem, more.
Those wins add up. They compound. There is no greater miracle than compound interest in your favour. And there is no greater foe than compound interest pitched against you.
Your team will get better at finding these wins. It’s a different mindset to see grunt work and think “how can I grind this out efficiently,” instead of only ever asking “how can I obviate this problem altogether?” The 3% wins build up faster. And more of them are 5% wins.
The silver bullets do happen. Occasionally you find a 100% win. Once in a very long while you will find a 10x lift, a 1000% win. They’re worth looking for, at least some of the time. But the team doing the hard work and putting up those little wins every day is a lot more reliable. You can predict those marginal wins. You can plan for them. You get to the point where you can rack up a few 2%, and 3%, and 5% wins every week. Do the math over months and years. I’ll give you a hint: it’s far better than 1000%.
About the Author
This article was written by John Nightingale, editor of https://mfbt.ca. and partner of @rawsignalgroup.
