The Cost of Teamwork

Not all engineering work needs to exist.

5 min read

In 1975, Fred Brooks warned that adding people to a late software project makes it later. Half a century later, the answer is still "add more engineers." Hard to blame them. Nobody gets promoted for shrinking their team.

So I built a simulation to explore quality over quantity. Each colored block is a unit of code. Each completed row is a shipped feature. Yes, it's unrealistic. You'll spot a dozen bad assumptions. But if you're too busy listing them to enjoy a fun little toy, perhaps you're part of the problem.

One engineer is a closed system. The tradeoffs are simple and the math is obvious.

The obvious next step? Hire someone.

You've seen this before. The sync that could've been a Slack message. The standup where half the team zones out. The incident that pulls everyone off what they were doing. You've watched the calendar fill up with follow-ups to follow-ups, and wondered when the actual work is supposed to happen.

That's the cost of coordination. It's manageable, until someone starts creating more problems than they solve. Thinking of someone on your team right now? Share on LinkedIn and tag them! (Do not do this. Unless you like meetings. With HR.)

You've watched someone generate more work than they complete. Here, and probably at your last job too. The fix is sometimes training, sometimes tooling, sometimes a hard conversation. But the reason it festers is simpler: removing someone is a career risk. Keeping them is invisible.

Not all engineering work needs to exist.