I’ve spent a lot of my career working near or with engineers stuck in survival mode. There are always telltale signs when an engineer is fighting themselves. Projects needing several revisions of designs because the “magical system” we designed doesn’t perfectly solve every use case, projects consistently going over deadline because the work required to get it over the line expanded in an expected way, working nights and weekends to catch up on a deadline that initially seemed reasonable or conservative.
All of these things are symptoms of the same core problem: thinking too big. Engineers like solving big problems. Big data, big scale, big abstractions, all things that we identify as marks of seniority. The problem is that “big” is the worst way to start building. Big projects are complicated to design, they have many moving parts, they have far-off deadlines that are difficult to meet, and they almost always get off track or fail in some way or another.
In almost every retro I’ve participated in for one of these projects, with almost every one of my reports who’s ever felt frustrated by a project getting off track, there’s a consistent through-line: “we needed to break down the problem more.” The further I get into my career the more I believe that all of these problems are solved by simply biasing ourselves towards building the smallest possible thing. Breaking systems down into the smallest possible units of effective work allows us to visualize dependencies, race conditions, and API design problems. Breaking projects down into the most granular tasks possible allows for more effective milestone planning and deadline estimation. Even breaking technical work down into small commits and PRs rather than large monolithic blocks of code allows you to spot problems earlier in the development cycle than getting an “LGTM” on a 4,000 line change.
I’m certainly not the first person to have an idea of this flavor, there’s many people, much smarter than me, to apply this thinking to parts of the job of a software engineer:
- Sandi Metz talks about small units of code being superior
- Sunil Pai talks about taking on smaller scope to actually create bigger impact
- Donella Meadows talks about breaking big problems down into systems to better understand them
The obvious common through-line between all of these is that small units and decomposition win, almost every time. Decomposing problems, building them with small units of code, and shipping iteratively will pay dividends over time. I’ve started to talk to my team about this as needing to develop a “bias towards small.”
A bias towards small means that there’s no such thing as a six month project. There are actually six projects that are one month long. There is no such thing as a rewrite, instead there’s a thoughtful and methodical refactor that permeates through the codebase. When problems are tackled in their smallest units, the complexity falls away. “Make the hard thing easy, and then do the easy thing.”
A bias towards small also means risk is now negotiable. A six month migration retains a finite amount of risk. What if we learn something in month five that makes a decision in month one invalid? What if we move 10% too slowly and our six month project takes nine? On the scale of half a calendar year these are reasonable worries, and can be threats to the success of teams. On the other hand, six projects each scoped for one month are far more predictable. The risk is now absorbed before the project begins by designing the project work to not be susceptible to going off track.
Reduce risk, improve velocity, maintain a bias towards small.