Decisions are the real output of senior engineers

As engineers become more senior, the code they personally write matters less than the decisions they shape. Choosing an architecture, agreeing an interface between teams, deciding to pay down a piece of technical debt: each of these affects far more code than any single pull request.

What makes technical decisions hard at scale

In a small team, decisions happen in a conversation. Everyone has the same context and the cost of being wrong is limited. As organisations grow:

• Context is spread out. No single person knows every constraint across teams.
• Consequences reach further. A shared library or platform choice affects many teams for years.
• More people have a stake. Each wants to be heard, and some have veto power, formally or informally.
• Decisions are forgotten. People leave, and the reasons behind a choice disappear with them.

Without a deliberate process, organisations tend toward two failure modes. Either decisions stall in endless debate, or they are made quietly by whoever happens to build first, and others discover them too late to contribute.

A good decision process

A healthy process does four things:

1. Matches effort to impact. Small, reversible choices are made quickly. Large, hard to reverse ones get careful thought.
2. Makes decision rights clear. Everyone knows who decides and who should be consulted.
3. Records the reasoning. Future engineers can understand why, not just what.
4. Communicates the outcome. Affected teams hear about the decision and its implications.

Good decisions and good outcomes

A decision can be good and still lead to a bad outcome, because of luck or information nobody could have had. A decision can also be poor and work out fine. Judge decisions by the quality of reasoning and information at the time. This matters because blaming people for unlucky outcomes discourages them from making decisions at all.

The case study

We follow an online learning company with about sixty engineers in eight teams. Their main application is a monolith that every team changes. Deployments are slow, teams block each other and an increasing number of features need asynchronous processing. Leadership asks the senior engineers for a plan. Over the course you will help them decide how to approach splitting the monolith, which messaging system to adopt and how to migrate a large database table without downtime.

Your starting point

List three significant technical decisions made in your organisation in the last year. For each, note who made it, how, whether the reasoning was written down and whether people still agree on why it was made. The answers usually reveal where your process needs work.