Most IT Management Advice Was Written by People Who Have Never Lost a Senior Engineer

Most IT management advice was written by consultants who have never had a senior engineer quit because the codebase was a dumpster fire.

That is not a knock on consultants broadly. It is an observation that there is a meaningful difference between someone who has read about managing technical teams and someone who has been in the room when a principal engineer drops their laptop bag on the table and says they are taking an offer somewhere else. The reasons are rarely salary. They are almost always environment. And the environment is almost always the manager's fault, even when the manager had no idea anything was wrong.

That gap, between the advice and the reality, is where most IT management falls apart.

Technical Teams Work Differently Than You Think

You can manage a sales team by looking at the numbers. Pipeline, close rate, revenue. The work is visible in near real time. If someone is underperforming, you can usually tell within a week.

Engineering does not work that way.

A developer can spend three days doing something that looks like nothing and then ship a change that prevents an entire class of bugs from ever happening again. Or they can spend three days looking busy while quietly making a system more fragile. From the outside, both look identical. This is why you cannot manage engineers the same way you manage everyone else.

The second difference is interruptions. When an engineer is pulled off deep work to answer a question, join a meeting, or handle something that could have been an email, the recovery time is not five minutes. Research puts it closer to twenty. Do that three times in a morning and you have effectively consumed that person's productive output for the day. Most non-technical managers operate in a more interrupt-driven mode by default. They assume their team does too.

That assumption costs real money.

The third difference is the expertise gap. If you are managing engineers and you did not come up as an engineer yourself, you cannot evaluate the work directly. You have to trust the people doing it. That means your management levers are different. You are managing through relationships, context, and the quality of the environment you build. If you are not doing that work, you are not actually managing. You are attending meetings and signing off on timesheets.

Ambiguous Ownership Kills Teams Slowly

The most common structural failure I see in technical teams is nobody knowing who actually owns what. Two teams share a service. Three people are responsible for a component. Nobody is accountable for the documentation.

It sounds like a minor organizational detail. It is not.

When something breaks at 2am, ambiguous ownership leads everyone to assume someone else is handling it. When technical debt accumulates, nobody has the standing to prioritize fixing it. When a new engineer joins and asks who they should talk to about a particular system, the answer "oh, it is kind of a shared thing" is a sign that system is slowly rotting.

Every component, service, and product area needs a named human who is accountable for it. Not a team. A person. Teams do not feel embarrassed when documentation is poor. People do. Ownership creates the kind of quiet professional pride that keeps systems healthy over time.

Calling ambiguity a management style does not make it one.

Technical Debt Is a Retention Problem

Here is a conversation that plays out at companies everywhere.

Engineers flag serious structural problems in the codebase. Management acknowledges it, creates a backlog item labeled "tech debt cleanup," and then never actually schedules time for it because there is always something more urgent. Six months later, a senior engineer leaves. In the exit interview, they mention the codebase. Management is surprised.

They should not be surprised.

Technical debt slows feature development, increases bug rates, makes onboarding harder, and signals to your best engineers that the organization does not take quality seriously. Your best engineers have options. They will use them.
Giving technical debt real time and visibility is a retention strategy. It is risk management. It is the difference between a team that can move fast in year three and one that has ground to a halt under the weight of shortcuts taken in year one.

If you have never pushed back on a product roadmap to protect time for foundational work, you have not been doing the full job.

One-on-Ones Are Not Status Updates

Most engineering managers either skip one-on-ones or run them as project check-ins. Both approaches miss the point.

Status updates are what standups and project trackers are for. One-on-ones are for the things that do not show up in any system. The engineer who is quietly frustrated with a team dynamic. The person who has been blocked for two weeks but did not want to escalate. The high performer who has been thinking about leaving for three months and has not told anyone yet.

You find out about these things in one-on-ones, or you find out about them in resignation letters. Those are often your only two options.

A good one-on-one is mostly listening. Asking questions that are not about the current sprint. Creating enough psychological safety so someone will tell you the uncomfortable thing before it becomes irreversible. Done consistently, they are the cheapest and most effective early warning system available to a technical manager.

Done inconsistently, they are just another thing you said you would do.

Scaling Without Slack Is Just Hiring Toward a Crisis

There is a version of team scaling that is just hiring more people and hoping it works. It does not, and the reason is utilization.

If your team is operating at 100% capacity, any unexpected work creates a crisis.

An engineer gets sick. A production incident takes three days to resolve. A stakeholder adds scope mid-sprint. At full capacity, all of these events cascade. Deadlines slip, people work nights, morale drops, and the team starts to feel like it is always behind, even when it is technically delivering.

Building in some slack is what allows your team to handle reality, which is reliably messier than any plan made in January.

The other scaling question that gets answered wrong constantly is whether to hire or bring in external help. A four-month recruiting cycle to fill a specialized role for a six-month project is not a good trade. There are situations where a temporary external specialist is faster, cheaper, and less disruptive than a permanent hire. Hire for the permanent core. Borrow for the spikes.

The Part Nobody Wants to Hear

Most team problems trace back to a manager who did not do the boring parts of the job.

Not incompetence. Not inexperience. Avoidance of the unsexy work that does not show up in any status report and does not get celebrated in any all-hands.

Documenting decisions. Running one-on-ones that are actually useful. Pushing back on the scope to protect engineering quality. Naming owners. Tracking debt. Building in capacity.

None of it is complicated. All of it requires showing up repeatedly, without fanfare, even when there is no immediate crisis demanding your attention.

You do not need a better framework. The people on your team need a manager who is paying attention. Most of the time, those are not the same thing.

If you want the longer version of what I've learned leading engineering teams, Tech Leadership Made Simple is the book. Practical, direct, no management fluff.