Safe defaults.

Back in 2018, when I first wrote about sizing engineering teams, I was surprised how much my advice rankled a colleague. He wanted to spin up a new engineering team of two people, which I thought was a bad idea. It would be a fragile team that would fall apart quickly if it didn’t grow. It would be missing the components we’d seen make other teams successful, like an engaged manager or ability to handle on-call if someone took a vacation. Finally, I argued that there was no real advantage to creating a new team, you could accomplish the same goals by just focusing two members of an existing team onto a new project for a bit.

My colleague didn’t address my concerns, but reassured me that it had to be a new team. Although at the time he wasn’t able to articulate why that was, I mostly got his deep frustration with the advice, I later came to believe it was rooted in his intuitive understanding of the staffing and headcount process. If you had a very small team, you would likely get hiring priority, even if its smallness was an intentionally crafted artifice.

Good process, like good strategy, is a solution to your current challenges. When I, or anyone, write about an effective approach, I’m inevitably describing it with the assumption of somewhat generic constraints. Any process will have to change to scale to an organization of ten thousand people, and almost no process makes sense in a company of two people. This doesn’t mean that reading is, as one influencer recently suggested, a useless way to grow as a leader, but it does inform how to benefit from writing.

Much of my writing describes “safe defaults” for an organization. When possible, I include the abbreviated story of how we decided on a given approach, or my rationale for the approach. Defaults are just defaults, though, and there will always be additional context that could make my recommendation the right approach or the definitively wrong one.

When you first come to a problem and aren’t sure what’s possible, then I think it’s extremely effective to copy approaches from those around you. This will establish a floor for performance while you come to better understand the problem. In some cases, you may never need to understand the problem beyond that point, the copied approach is good enough.

In other cases, the copied behavior won’t work particularly well. In that case, you should dig in! Once you decide to stray off the documented path, the challenge is deciding whether the writing is missing insight into your circumstances, or whether you’re missing insight into the ideas behind the writing. Make that decision by building up your mental model of the scenario the writing describes and of your own circumstances, then test a change to validate that model. If it works, then there you go, you’ve escaped from safe defaults to bespoke excellence. Both are valuable approaches to keep in your pocket.