Most engineers who move into management expect the job to be their old job plus meetings. It isn't. The meetings are the visible part; the real change is that almost everything you used to rely on to know you were doing well stops working. This post walks through what changes, what to stop doing, and how to try the job before you commit to it.
Your output is now the team's output
Andy Grove put it bluntly in High Output Management: a manager's output is the output of the organization they run, plus the output of the neighboring organizations they influence. Not the code you write. Not the number of meetings you attend. What the team ships, and how well.
That sounds obvious until you notice what it rules out. A day where you wrote a clever fix but two people on your team were blocked waiting for a decision from you was, by this measure, a bad day. A day where you wrote no code but unblocked three people, clarified a priority and had one hard conversation that was overdue was a good one.
The shift is from doing the work to making the work possible: setting direction, removing obstacles, growing people and keeping everyone pointed at the same goal.
What changes, side by side
| As an engineer | As a manager | |
|---|---|---|
| A good day | You finished something | Other people finished things and nobody waited on you |
| Feedback loop | Seconds to days: tests pass, the feature ships | Weeks to months: people grow, the team gets faster, or doesn't |
| Your calendar | Long blocks for focused work | Many short conversations, interruptions are part of the job |
| Who you serve | The codebase and the user | Your team, your peers and the people above you |
| How you add value | Depth in one area | Judgement across many areas, most of which you don't own |
| What "done" looks like | Merged and deployed | Rarely done; it's a system you keep tuning |
The feedback loop is the one that catches people out. As an engineer you get dozens of small signals every day that you're competent. As a new manager you can go weeks without any, and the ones you do get are ambiguous. Many new managers quietly retreat to writing code because it's the only place they still feel useful. Knowing this in advance makes it easier to resist.
Where the time goes
Paul Graham's essay Maker's Schedule, Manager's Schedule describes the clash well: makers need half-day blocks, managers work in one-hour slots, and one meeting in the middle of an afternoon can wreck a maker's day. As a manager you move to the manager's schedule, but your team stays on the maker's. Part of your job is protecting their blocks while giving up most of your own.
A typical week for a manager of five to eight engineers includes:
- One-on-ones with each person, usually 30 minutes weekly or every other week.
- Team rituals: planning, stand-ups or async check-ins, retrospectives.
- Coordination with product, design, other teams and your own manager.
- Hiring: interviews, debriefs, reviewing candidates.
- Unplanned work: incidents, a sudden priority change, someone who needs to talk now.
- Thinking time: planning, writing, preparing feedback. This is the first thing to disappear if you don't book it.
Some managers still write code, especially on small teams. If you do, keep it off the critical path: tooling, small fixes, prototypes, code review. If a feature can't ship until you find a free afternoon, the team is blocked on the person with the least free afternoons.
What to stop doing
These habits served you well as an engineer and will hold your team back now:
- Being the person who knows the answer. If every question routes through you, the team can't grow and you become the bottleneck. Answer with a question more often: "What options have you considered?"
- Reviewing everything. Choose what genuinely needs your eyes (risky changes, new people's work, cross-team interfaces) and let the team own the rest.
- Fixing it yourself because it's faster. It usually is faster, once. Delegating something you could do in an hour takes three hours the first time and zero hours after that.
- Measuring your day in tasks completed. Keep a short weekly log of decisions made, people unblocked and conversations had instead. It will feel thin at first; that's normal.
What to start doing
- Hold regular one-on-ones and protect them. They're where trust, feedback and early warnings happen. Rescheduling is fine; cancelling repeatedly tells people where they rank.
- Make priorities explicit. Write down what the team is doing this cycle and, just as important, what it isn't doing. Most team friction comes from people guessing differently.
- Give feedback early and specifically. Small, frequent, about behavior rather than personality. The longer you wait, the harder it gets.
- Build a relationship with your own manager. Agree what they want to hear about, how often and in what form. Surprises in either direction damage trust.
- Book time to think. Two blocks a week, treated like meetings.
It's not a one-way door
Charity Majors' widely shared essay The Engineer/Manager Pendulum argues that the best technical leaders often swing between the two roles over a career: managing for a few years, going back to hands-on work, managing again. Each swing makes you better at the other role. Engineers who have managed understand how organizations actually make decisions; managers who have recently engineered keep their technical judgement sharp.
So the question isn't "Do I want to be a manager forever?" It's "Do I want to spend the next two years getting good at this?"
Try it before you switch
You can test most of the job without the title. If your manager is supportive, ask to take on some of these for a quarter:
- Lead a project end to end, including the planning and the status updates.
- Mentor a newer engineer with a regular check-in.
- Run the team's retrospectives or planning sessions.
- Write the proposal for a piece of work that needs sign-off from outside the team.
- Handle communication during an incident rather than the fix.
- Sit in on interviews and debriefs.
Then be honest about how it felt. Not "Was it easy?" (it won't be) but "Did I find the people problems interesting, or did I resent them for keeping me from the real work?" If the answer is resentment, that's useful to know now.
Questions to ask yourself
Before you say yes to a management role, try answering these in writing:
- Would I be satisfied by a week in which I built nothing myself but the team shipped well?
- Am I curious about why people behave the way they do, including when it's frustrating?
- Can I tolerate having no clear signal that I'm doing well for a month at a time?
- Am I willing to have conversations I'd rather avoid, and have them soon?
- Do I want this for the work itself, or because it looks like the only way to progress? (Many companies have a senior individual contributor track; check before assuming.)
If you're still interested after that, the PTMF study guide covers the foundations of leading a technical team, planning work and communicating as a new manager, and it's a useful map of the job before you're in it.