Abandoning code for people

Within two weeks of starting my new job, I was made aware of a powerful faculty I hadn’t thought to explicitly ask for: budget to hire consultants. If these consultants performed well, I could bring them in full-time.

It’s not like this hadn’t occurred to me as a possibility - it’s just that I had sold myself on the idea that I would roll my own software at this company for a few months to a year before really pulling in more people. But the truth is that I like abandoning code for people. When there are code problems that take 8 hours of my time and people problems that take 8 hours of my time, I will spend my time on the people problems. I am sometimes a little ashamed of it, but that has less to do with my performance at the job or what the business requires and more to do with my own identity as a technical person. Oftentimes, the right thing to do is to spend 8 hours of my time on people problems.

I wish I wasn’t like this sometimes. I look at the people around me who have reached similar years of experience and I see very different career paths that have led them to a much more deeply, or at least, differently satisfying set of skills.

The Technical PM

Google had PMs who ran the gamut - some were PhDs in databases who helped communicate the complicated use cases and requirements of BigTable to a larger community. Some were ex-marketing folks who understood users a bit, process a bit and technology not at all. The most interesting PMs I’ve met are what I’ll call “infrastructure” PMs. They often understand the 30,000 foot view of the technical side, sometimes better than any individual engineer does. They are perhaps not comfortably conversant in the technical language but they understand perfectly. They can usually tell when an engineer is fibbing or being generous with deadlines.

The Uber-Technical Prototyper

These are engineers who have spent enough time around reliable systems that they know what it takes to really launch and maintain one. But their inclinations are still mostly towards users and speed. They don’t love the process of iterating on a system’s design to eke out that next level of performance. This is me. I spent most of my career at Google convinced that through osmosis, I would somehow become the type of engineer who also cared about reliability, in addition to users and speed. But this never happened. I was either immune to the type of lessons that I needed to learn or perhaps I filled the niche that mattered most in the moment - the one focused on users and speed.

In an environment full of tuners, I was finding alpha in prototyping. It was the missing piece of the engineering puzzle in that environment.

The Uber-Technical Tuner

Google is filled with this type of engineer. I was surrounded by people who were not just more willing to dive into the details of a system, but so much more comfortable in it than I was that it made little sense for me to pay the cost of diving in myself. I fully trusted the technical wisdom of the senior engineers around me. These people knew what was wrong with a system and where future issues would come up.

If we were sailors on a boat, they were the ones who could sense the storm coming even when it looked sunny all around. I trusted their storm-sense and with their help, I always knew how to mobilize the team to “batten down the hatches”.

This type of engineer often focused much more on the needs of the technical system than on the needs of the user. This isn’t a bad thing. A good organization involves a playfully antagonistic dynamic between the tuners and the product people. But I was never on either side of this dynamic. I was somewhere in the middle, trying to help both sides make progress. Or at least, that’s what I thought I was doing!

The Mythical Maker-Doer

I didn’t think this type of person existed. But out here in the world outside of Google, I see a lot more of these types. My friend Ryan built Do Browser with a friend of his in just a few weeks. It’s already financially successful.

Pablo wrote a blog post about programming languages that went viral on Hacker News. It shows the depth of thought he has put into the nitty-gritty of implementing software. What’s less visible is that his blog is hosted by a blogging engine he wrote himself. Oh, also, he was the founding engineer of a decacorn.

Levels.io might be another example of this type of person. He has launched a series of businesses that are all doing fantastically financially. Some of them involve a decent amount of technical implementation.

A black metal analog

A slight aside. It is extremely common in black metal music for a ‘band’ to be just one person. One of the original famous black metal bands - Mayhem - was a “normal”, multi-person band. Until of course, Varg Vikernes killed one of his bandmates and was sentenced to prison. In Norwegian prison you can still get access to musical instruments and so Varg recorded Filosofem - one of the most acclaimed black metal albums of all time.

It takes a decent amount of effort to play the guitar and sing at the same time. Learning bass, synths and drums on top of that would take quite a bit of time. To be truly exceptional at any of those pieces is to forget some other instrument a little bit. But that wasn’t the goal, Filosofem isn’t a showcase of Varg’s instrumental skill. It is a compositional masterpiece. It shows you what it might look like if there were no organizational seams in the production of a musical work.

What type of person do I want to be?

The mythical maker-doer. Without a doubt. The type of person who understands the technical, product, marketing, finance pieces enough to understand how it all works. And with enough time (say…by being imprisoned) I would be able to build something entirely with my own hands.

But what if the mere act of being in a human organization means letting go of this vision? The reason we group and specialize is because there are real advantages to doing so. It’s really only the most misanthropic who develop such a powerful need for developing all the skills themselves.

Or perhaps it is organizations that prevent us from reaching this state by nipping our nascent godhood in the bud with an irresistible offer or tempting alternate candies. Prestige! Title! Why would you want to be an even more engineer-y engineer when you can be a Manager of Engineers?!

Or perhaps it is organizations which expose us to all the facets of humanity that are needed to make things for humans. It’s where we realize that our initial goals, the initial mountain we wanted to climb is not the tallest one.

It’s only when we climb halfway that we notice there are peaks much higher, summits that we can scarcely see. We can see the switchbacks that disappear into the clouds above. We are thankful for how far we’ve come, daunted by what comes next. The peak we’d initially set out to conquer seems pointless. There’s much more to do.

Some lingering concerns

What if this “gap-filling” role I pick obscures the skills I’ve gained in each of these areas - finance, product, marketing and the various technical domains?

I know that there are certainly some ways in which being the “gap-filler” hides my skills, but the more important question is why is this coming up now?

It’s an “artifact” problem. I look back and don’t have enough hard evidence of the work I’ve done. The gap-filler fills the gaps and it’s not entirely clear what would have happened if they weren’t there. I would love to have more tangible projects, released entirely under my own name. Maybe it won’t be a whole black metal album, but it might be a death metal jingle.