Management Teaches Better Engineering

One of the easiest traps for engineers to fall into is mistaking software development for software delivery.

It’s understandable. Most engineers spend the overwhelming majority of their day inside the technical layer - writing code, reviewing code, debugging code, designing systems, discussing architecture, refining abstractions. That is the craft, after all. It’s where we live, where we build confidence, and often where we derive professional pride.

But code is just one component in a much larger machine. The more senior you become, the more dangerous it is to forget that.

Software does not create value because it is elegant. It creates value when it solves real problems for real users in ways that are viable for the business, usable through design, and deliverable through coordinated effort. Engineering is critical, obviously, but it is still only one specialty among several required to make valuable software real. Product shapes what matters and when, design shapes how it works for humans, and engineering makes those things a functional reality.

Engineers who don’t regularly interact with these broader systems and remain buried in the code lose sight of this and end up optimizing locally while harming globally.

Every Line of Code Is a Business Decision

This is where otherwise excellent engineers can accidentally become expensive - and not in the good way.

A little extra flexibility here. A more scalable abstraction there. A cleaner architecture “for later”. A more elegant refactor because “we’ll need it eventually”.

Usually, these decisions are made with good intentions - they often come from craftsmanship, foresight, and genuine care. But good intent does not erase cost.

Every additional line of code carries a cascading burden: more implementation time, more review time, a larger testing surface, more QA complexity, more deployment risk, more maintenance, more cognitive overhead for future engineers, and - perhaps most critically - more delay before users can interact with the thing and generate the feedback required to determine whether any of this was even the right investment.

This is one of the most important mindset shifts leadership tends to force onto engineers: building more is not inherently better - in fact, overbuilding can sometimes be worse than underbuilding.

YAGNI remains one of the few principles in software that is consistently worth treating almost as law. Not because future-proofing is a bad idea, but because most “future-proofing” is better called “speculative engineering”. Even the most seasoned engineers can guess future requirements with little more accuracy than a coin flip. Despite great inner conviction, the evidence points against us.

Perhaps a more subtle consequence of this behaviour arises because people don’t notice when you get it right - but they sure as hell notice when you get it wrong. The bet isn’t worth it.

Overbuilding Causes Trust Problems

This is a key point many engineers miss - even late into their careers. When you build beyond agreed requirements without sufficient justification, you are not simply writing code - you are making unilateral decisions on behalf of product, design, QA, stakeholders, and your teammates about where their time and energy should now go.

That can become a trust problem.

Not immediately, of course. Nobody usually explodes because an engineer made something slightly too flexible. But over time, habitual divergence from team priorities - even when technically impressive - creates friction. Teams begin to feel that alignment is optional, priorities are negotiable, and engineering effort is being partially redirected toward individual ideals rather than collective outcomes.

Often without realizing it, engineers can slowly erode trust within their teams not by building poorly, but by building selfishly. Even when they believe full well what they are doing is in service of the very others they are quietly letting down.

Leadership Forces You to Zoom Out

This is one reason technical leadership, team leadership, or engineering management can be such a powerful growth phase for engineers, even for those who have no long-term desire to remain in people management. Leadership forces you to zoom out.

Suddenly, your perspective can no longer end at “Is this good code?” You are now required to think in terms of broader systems:

• Is this the right investment right now?
• What downstream burden does this create?
• Who will own this?
• How certain are we that this is the correct problem?
• Are we solving for user value or technical satisfaction?
• What is the opportunity cost?
• What does this delay?

You begin to understand that software delivery is not primarily about maximizing technical quality in isolation; it is about maximizing valuable outcomes globally under many competing constraints.

This does not make you less of an engineer. In many cases, it makes you substantially better - because you are able to understand your work and its impact within a much larger context than your IDE.

Code Becomes Investment

Once you truly internalize the full software delivery lifecycle, your engineering judgment sharpens.

You start recognizing that a “brilliant” refactor done at the wrong time may actually be poor engineering in context.

You begin asking not only whether something should exist, but why it should exist now.

You become more sensitive to coordination costs, strategic timing, and product confidence.

You stop seeing code purely as creation and start seeing it as investment that requires justification.

This broader awareness is often what separates senior engineers who merely build well from those who consistently drive meaningful impact above and beyond their own (or Claude’s) typing speed.

This Matters for Staff and Principal Engineers

For engineers pursuing Staff or Principal pathways, this is particularly important. There is often a false dichotomy presented between “management” and “real engineering,” as though stepping into lead responsibilities somehow contaminates technical purity.

In reality, a temporary period of team leadership can function like cross-training. Done well, it teaches product thinking, organizational leverage, stakeholder negotiation, prioritization, and systems-level reasoning - all of which will dramatically increase your effectiveness when you return to or remain on the IC track.

In other words: learning leadership does not necessarily mean abandoning engineering. Often, it means finally actually understanding what good software engineering looks like in its full glory.

Leadership Needs Engineering Proximity

Of course, this cuts both ways. An engineering manager who spends too long away from implementation can absolutely lose touch with the friction of software development - the papercuts of tooling, the compounding frustrations of delivery pipelines, the invisible drag of technical debt in practice rather than theory.

Managers may be strategically proficient but if they become operationally disconnected, well, good strategy doesn’t matter if it can’t be operationalised. This disconnect is a very fast way to burn out teams while producing little or no real value. That is why the relationship matters in both directions.

Good engineers benefit from leadership perspective because it teaches systems awareness. Good leaders benefit from engineering proximity because it preserves practical empathy.

The strongest technical leaders are usually those who can move between these levels - from architecture to team trust, from implementation detail to product strategy - without losing sight of either. And this ability to “zoom in and out” is an exceptionally powerful problem solving skill that serves engineers as well as managers.

Keep An Eye On Your Growth

For senior engineers who don’t aspire to be managers it’s worth knowing that this “management” work is not necessarily a detour on the path of an engineer. In fact, for many it can turn out to be exactly the missing layer in their development. It certainly was for me.

After my first year of “hands off the tools” management I hit a wall of frustration, and rather embarrassingly unloaded it on my boss at the time. I was given some exceptionally clear and useful feedback in that exchange, and consider myself lucky for it. One thing I was told was told I needed to be thinking “above and around” engineers in order to be an effective leader. This wasn’t clear to me immediately, but as this advice sunk in I realised this was exactly the bigger global picture of work that I was missing. I was still thinking in terms of software development, and not software delivery.

That said, there is danger to be aware of, as many competent senior engineers end up in these team lead roles by default - but the threat is not leadership, itself. Management may be optional, but leadership is not.

The danger is quiet stagnation disguised as leadership.

If you are consistently being given responsibility without broadening authority and autonomy, this may be a sign that you are simply a reliable way for the organisation around you to turn dysfunction into delivery. This is not learning, or growth. It’s the curse of competency. It may be hard, since you may have people relying on you, but you need to consider your own growth and move if this becomes the case.

Typically, this will look like you being responsible for decisions of people made above you, despite having no say in those decisions, and no viable means of pushing back. You may be given a title formally, or a position informally, but if you are left executing on or defending decisions that weren’t yours then you are likely stuck in a position of stagnation.

Know the difference between a genuine growth opportunity and this kind of “false promotion”. One comes with autonomy, authority and accountability - the other often sees you simply become a shield or a messenger between the team and the person who should be leading.

So, strongly consider taking the opportunity to lead a team if it arises. But keep an eye on your growth, and know when it’s time to move on.

Final Thought

The shift from code-centric thinking to systems-centric thinking is exactly why learning to lead can make you a better engineer, whether or not you choose to stay there.

The best engineers are not merely the people who write the cleanest code - they are the ones who most consistently help their teams build the right thing, at the right time, for the right reasons. And in doing so consistently create genuine value for their organisations and their users.