Keep Coding
Every Saturday I come to the office, open up VSCode, and engage in single combat with our web application’s codebase. The goal: To add a mere few dozen lines of TypeScript without screwing up anything important. To make our users’ lives just slightly better, myself, with my own hands. When I think I’ve done it, I interrupt my co-founder’s real work to ask for a code review of my humble change, and then bite my fingernails watching the little icons turn green in the CI/CD pipeline.
Some of my illustrious recent changes include adding little credit card icons to the billing screen, automatically adding new self-signups to our CRM, and alerting users when Modelbit’s systems are unstable. Not exactly great feats of Computer Science. So why spend all day on changes that would be a few moments of work for any engineer on the team?
For a clue to the answer, here’s another story. Recently I ran into an old colleague who just took a job as a senior engineering exec at a big tech company. We were just chit-chatting until he realized I’m a customer of some of the infrastructure products he now owns. Suddenly he was leaning forward and asking rapid-fire questions: “Does product X work?” “Does product Y scale?” “Is product Z easy to use?”
He was searching for ground truth. He’s just taking over as a manager of managers of managers, and his biggest problem is knowing what’s even true on the ground. Everyone who tells him things has an agenda he can’t yet parse. The team has biases that are mysterious to him. The org has a trove of accepted wisdom that’s quite valuable overall, but some pieces of that accepted wisdom are dangerously out of date. He doesn’t yet know what his underlying reality is, so independent outside perspectives are very valuable to him.
My friend is in an unenviable position, coming into a situation without any ground truth and having to stumble through the fog to figure it out. As founders, our circumstances are much easier: We built the first product, we sold the first deals, we supported the first users. Ground truth lives, in high resolution, in our heads. We don’t have to assemble truth from clues in the forest. This gives us a massive advantage. All we have to do is ensure we don’t lose that advantage – that high-resolution picture of ground truth – as we scale. Unfortunately, we usually screw this up.
As you start adding management layers, it will feel natural to give up the hands-on-keyboard work. You’ll feel like a bottleneck by doing it, and to an extent you will be. Your team will pressure you to stop, because your presence on the sales call or in the support loop will add some stress and friction to the team. It’s true that insisting on being present for every sales call or every support ticket will grind the org to a halt. But you do need to keep sampling these things in order to stay up to date. You need your own perspective on the facts, independent of the carefully-wordsmithed reports your managers give you.
In Only The Paranoid Survive, Andy Grove describes the lead-up to orchestrating one of the greatest pivots in tech industry history. He describes talking to individual sales and support staff on the front lines, and discovering that they all knew something none of the senior leaders knew: That Intel’s position in the memory business was irreparably fucked. Only by going on sales calls himself, as the CEO of a public company, did he learn this.
A year ago, I was heartened to read that the CEO of Uber had started driving Uber rides himself on weekends. When he finishes his shift, he files bugs and fires off emails based on the day’s experiences on the ground. Dara was in the same situation as my friend: Taking over an organization from the outside, and having to discover ground truth for himself. I guarantee that entire orgs at Uber bite their fingernails on the days Dara is driving. I’m sure some VP told him a better use of time would be reading reports based on millions of datapoints, rather than gathering just a few datapoints himself. Dara does it anyway. He does what Andy Grove did: Going to the ground himself, so he can learn the truth for himself.
We will all have to pivot along the way. To survive, we’ll have to learn the unpopular truths our teams would rather not say out loud. There’s only one way to do it: Set aside time to take some support tickets yourself. To go on sales calls. To listen to Gong recordings and fire off emails with notes and questions. Only by spending the occasional Saturday building a feature yourself will you maintain a visceral understanding of how your product works, of its innate strengths, and the places where its legacy architecture makes it vulnerable to competition. Yes, your team will roll their eyes and question your wisdom in doing it yourself. Do it anyway. Keep coding.