Surviving Tech Startup Scale
I told someone recently that I was just a “startup kind of guy.”
Yes, it’s a bit of a cringe-worthy line and I regret saying it. Worse — the thought that perhaps it really is true, in which case I regret being the kind of guy about which such a statement may be said.
Hopefully, if it is true, being a “startup kind of guy” is not code for “I don’t like working for other people” or “I don’t take direction well”. Those… uh, no — those are definitely not the reasons. I’m sure I’m fine.
That’s not hair dye running down my forehead— I’ve got pluck oozing out my ears! If you’ve been following past posts, you’ll know that I am so stinking self-aware it can be hard to watch and, of course, this article is no exception: it will also be hard to watch. You see, introspection is how I can write an article like this one. One that analyzes That Tech Startup Life that I’ve so far lived, and says something witty and half-way useful.
In particular, and this is me landing the plane of a quippy intro: I want to talk about surviving the startup scaling problem.
The Problem
My biggest takeaway from startup experiences is that team scale changes everything. When you have only a handful of people, hiring a few more people doesn’t just give you more bandwidth, it changes your job entirely. This is probably true of any leadership position at a scaling organization (but I wouldn’t know), but it is guaranteed if you’re a programmer.
The most compelling model I have employed to think about these changes is by thinking in powers of two. Every time your engineering team doubles in size, your org is an entirely new org and your job is an entirely new job. This takes place when you move from 1 to 2, 2 to 4, 4 to 8 — I assume you know how powers of two work (don’t you program, after all?). At massive scales, I have no idea if this law holds true. I would guess that past Dunbar’s Number, perhaps some other interesting dynamics come into play. Like pushing an aircraft through the sound barrier.
Powers of two are boring though, so let me make this crystal clear: your organization is a Pokémon, and powers of two are its evolutions. Now we’re getting somewhere.
Sometimes these evolutions are simple: it just makes sense that Rattata evolves into Raticate: it’s literally a bigger rat. But keep in mind that, wait what — Magikarp evolves into Gyarados?
In Chinese mythology, Longmen (lit. The Dragon Gate) is located at the top of a waterfall cascading from a legendary mountain. The legend states that while many carp swim upstream against the river’s strong current, few are capable or brave enough for the final leap over the waterfall. If a carp successfully makes the jump, it is transformed into a powerful dragon. The legend is so famous that throughout China, a common saying is that “a student facing his examinations is like a carp attempting to leap the Dragon Gate.”
Have you ever ridden a fish while it transforms into a dragon?
Pokémon is the perfect high-grossing-media-metaphor for a tech startup.
Survival
I can’t say the best way to survive these scale evolutions, but I can relate how I have approached them and lived to tell the tale. “Approached” is an elegant way of describing my experience, by the way. Much like approaching a flight of stairs before falling down them. Before I go about describing my ancient wisdom, if you haven’t already read my article on me not knowing what the hell I’m doing, I’d suggest you start there.
My dad, at some point in his 50s (this is another metaphor), after having played guitar for over thirty years, after thousands of live gigs, after recording multiple albums, touring Europe at some point (that may have been as a drummer, I can’t recall) — he unlearned and relearned how to play scales and — news to me, even recently abandoned using a pick at all. At some point, he hit the far edge of his particular style and, rather than trying to keep making it work as he advanced, had to pour another hundred hours into a new technique that foundationally changed how he played.
The same thing happens repeatedly at a startup.
What strikes me, having gracefully fallen down these startup stairs several times, is that management across these evolutions follows a particular set of transformations. Patterns have emerged only in retrospect, specifically around how one communicates expectations.
Let me explain.
Hands-on
Even your most junior Pokémon Trainer knows that you start with Basic Pokémon. You’ve got one or two basics and a backpack full of empty Pokéballs. You are Ash Ketchum and Pikachu is dancing on your shoulder as you say goodbye to Pallet Town. At this stage in your startup, as I said before, you are writing all the code. You are defining your expectations for your fledgling non-team with cold, hard code.
Beknownst-or-un, your fingers dig deep into the stone tablets — your code is the Written Word. “Look at this! This is how simple I want things. At our company, this is what a good REST API looks like.” Or maybe, “This is what a simple OOP class looks like. These are good git commit messages, these are good code comments.”
You describe your expectations of others’ code by showing them… using your own code. It’s called leading by example.
Documentation
At some point, when you sense your Bulbasaur is about to go full Ivysaur, you switch to describing your expectations via written documentation. This is not a binary switch — not all documentation all the time, but there is a partial transition that needs to take place. You need to to write a style guide (as I’ve said before, this is essential). You need to write a code review process, a VCS workflow document, job descriptions, hiring pipelines, SecOps best practices, technical design templates, documentation on how much documentation to write — you need to write docs till your hands bleed.
You’ve taken a step back and moved from implementation details to patterns of implementation details.
Open your hand
Daggum, now you’re at level sixteen, and at this power of two your growing team is too big for you to even half-way manage. You need to put leaders in place, train them, then hand off anything and everything you can.
Take that fancy style guide, give it to a leader and say, “take this and have fun.” That beautiful VCS workflow document? Forge someone else’s signature on it and drop it in their office cubby. It’s their baby now.
You pop in and out. You review changes to high level guiding processes, documents, and workflows. You make suggestions but slowly start to relax your grip on them. You work directly with these leaders to help shape their plans and the details of the things they own. You need to starting holding things with an open-hand. You are no longer writing documentation from scratch. Just like when you went from Jr to Sr Programmer — now you’re mostly reviewing documentation. You’re working directly with your leaders, talking through expectations that they can translate into documentation.
Your Ivysaur is still gaining experience, though. It’s about time for your job to change again.
Goals
A Venusaur emerges. This is the Final Form of the Basic Bulbasaur (or so you think). You are now leading leaders that lead other leaders (I think I got that right), so naturally your job needs to change again. This metaphor is turning out to be an excellent pick because Venusaur emerges at level 32, which happens to be — you guessed it — a power of two. I am just so smart it hurts. Literally at least 100 IQ.
Yes, at this level, you can’t even hold the same things, open-handed or closed. You need to switch from describing expectations through leader-to-leader mindmelds and move to describing expectations through goals. Your leaders take those goals and figure out how to hit them.
Take that style guide for example. The goal of that document was not so that you’d have a style guide. The goals were:
- Increase engineering velocity
- Reduce disagreements between team members
- Reduce onboarding friction
- Decrease maintenance costs
You determined that a style guide would help meet those goals — and so at a smaller level of scale it made sense to work on that specific solution. Now? At Venusaur scale? You give those goals directly to your leaders of leaders, instead of coming up with the form of the solution for them.
???
In my outline for this post, which I quickly spat out when inspiration struck me with the force of a thousand Dolph Lundgrens, I have written, as a last bullet:
“Define expectations through ???”
This is because I don’t really know what’s after the next evolution. Little known fact: in The Isle of Armor, they introduce a Gigantamax form of Venusaur. Yes, loyal fans, I’ve misled you. Technically Venusaur is not actually the final form of Bulbasaur.
The Gigantamax form will be the next scale to look forward to. Unless the CTO of — I don’t know, Amazon or something, is reading this post, there is always a bigger scale for you to look forward to. Recall: I have never led 30,000 engineers so I have no clue how it’s done (not that a 30,000 person org is “next” for me…). I don’t know exactly how the next step works, but I am led to believe that the job would be wholly different than what I do right now, because that has been true over and over thus far.
This is just primitive inductive reasoning. I’ve seen it happen a bunch-load of times, so I’m going to assume it will continue to happen.
Final outlook
This inductive exercise leads me to thoughts I’ve already sensed myself and heard from others. It leads me down a winding path from Pallet Town, through the tunnels of the Diglett Hills to the Indigo Plateau and leaves me with the question: “Where to from here?”
I’ve mentored a number of engineers that keep eating and evolving: up the ladder they go. “Toodle-oo and ta-ta for now! Think of me when you own the digital avacado industry!”
I’ve mentored others that instead, stop on a rung and start collecting twigs and bits of string. I think to myself, “What on Earth is she doing?” Then I realize: she’s building a nest. “I like it here,” she yells to me.
Some engineers stay at the same title or in the same position for a decade because they like the job. I can’t really blame them. Over beers, and on a long enough timeline, I will start on about the Peter Principle. It’s a real thing that I’ve experienced directly and indirectly, repeatedly. Once you’ve done well enough in one job, they promote you — which sounds great until you realize that you’re about as useful in your new position as a blockchain-based streaming video service for the metaverse.
The ladder climbers, it turns out, need to figure out if they enjoy something fundamental about the climb, rather than the rungs along the way. I think a terribly high number of them (of us) are just putting one foot in front of the other. Really we need to stop climbing for a second and introspect.
Where to from here?
