Your Architecture Complexity and Engineer Onboarding

Your architecture’s complexity is measured in how long it takes your next hire to ship their first feature.

Fred Brooks warned us fifty years ago: adding people to a late project makes it later. But the deeper lesson from The Mythical Man-Month isn’t about deadlines. It’s about communication overhead. Every person you add multiplies the connections. Every connection requires context.

That microservices setup that made sense to the original team? It’s now three weeks of context before a new engineer can touch anything. The event-driven architecture that felt elegant? It’s a maze of invisible connections that nobody documented.

This is complexity making Brooks’s Law worse. Not just more people communicating, it is more system to communicate about.

Every clever abstraction needs to be taught. Every implicit convention needs to be discovered. Every “you just have to know” becomes hours of pairing, confused pull requests, and senior engineers pulled away from their own work.

I’ve watched teams double their headcount and halve their velocity because every new hire spent months learning the system instead of improving it.

Simple systems compound. A new engineer who ships in their first week becomes productive in their first month. They have time to learn while contributing. They ask fewer questions because there’s less to ask about.

Complex systems tax. A new engineer who takes a month to ship their first feature is still ramping up at month three. They’re nervous to touch things. They depend on the same two people who understand how it all works.

When you’re deciding whether to add that abstraction, that service, that layer of indirection—ask yourself: how would I explain this to someone who starts Monday?

If the answer takes more than five minutes, you might be writing an onboarding problem, not a solution.

How long does it take your new engineers to ship their first real feature?