How I’d go from programmer to manager without burning out in the first year

I took the manager seat and kept writing code like that was proof I had not “sold out.” That was the mistake that nearly burned me out in year one.

The job had changed. My calendar had not gotten the memo. I was still optimizing for personal throughput while being paid to multiply other people’s throughput. The result was predictable: mediocre management, slower personal coding, and evenings spent apologizing to both.

Here is how I would make the IC-to-manager jump now — the version that protects the team and your nervous system.

Accept the scoreboard change on week one

As an IC, the scoreboard is tangible: PRs, designs, incidents closed. As a manager, the scoreboard is lagging and social: team health, clarity of priorities, quality of decisions, growth of people, and whether the org can ship without you as a hero.

If you keep the old scoreboard, you will steal coding time from coaching time and call it integrity. It is not integrity. It is avoidance with a compiler.

Write down your new outcomes for the first ninety days. Mine would be: every person has clear priorities, on-call is humane, hiring bar is consistent, and I know each person’s strongest fear about the work. Notice “I merged my pet refactor” is not on the list.

Do not quit code cold turkey — but quit being the critical path

I am not religious about managers never coding. Small reviews, a spike, a bugfix that builds empathy — fine. Being the person who must land the release — not fine.

The first-year trap is keeping the most interesting technical work because it feels like competence. Hand that work to someone growing into it. Keep a thin technical practice so you can still smell risk. Drop ownership of the critical path.

A practical rule: if the team cannot ship the milestone without your personal commits, you are still an IC with meeting overhead.

Replace heroics with systems

Burnout in new managers often comes from being the router for every decision. Install systems early:

• A weekly priorities note the team can see
• Office hours instead of perpetual Slack reactivity
• A decision log for irreversible calls
• 1:1 agendas owned by both people, not vibes
• Escalation paths that do not require you as the only adult

Systems feel slower than heroics for about two weeks. Then they start buying back sleep.

Learn the conversations that are the job

Your first year will be decided less by your architecture taste and more by whether you can do hard conversations early. Feedback delayed becomes performance theater. Scope lies become trust debt.

Practice:

• Clear expectations in week two, not month six
• Naming miss matches between ambition and capacity
• Protecting focus without becoming a human firewall of vague nos
• Advocating for the team upward with evidence, not vibes

If conflict makes you nauseous, treat that as a skill gap, not a personality verdict. Get a mentor. Role-play. Read less Twitter management advice and have more real talks.

Guard energy like a production dependency

First-year managers inherit everyone else’s urgency. Without boundaries you will become a polite outage.

My non-negotiables now:

• No calendar without focus blocks for thinking and 1:1 prep
• A shutdown ritual — write tomorrow’s top three before leaving
• Exercise or a walk that is not optional “when things calm down”
• One peer manager I can text when I am about to do something cowardly

Burnout is not proof you cared. It is often proof the role had no edges.

Hiring and performance: where new managers get hurt

Hiring feels like productivity because it is busy. Bad hiring is a multi-year tax. Slow down enough to use a consistent loop. Speed up enough that roles do not stay open until the team is underwater.

On performance: document early, be specific, and do not outsource courage to HR templates. The kindest timeline is the honest one.

A ninety-day plan I trust

Days 1–30: Listen. Map work, risks, and people. Clarify priorities. Stop being on the critical path for code.

Days 31–60: Install 1:1 quality, on-call sanity, and a visible priority system. Give feedback that is slightly scarier than comfortable.

Days 61–90: Make one org/process improvement that reduces your router load. Sponsor someone else’s technical win publicly. Reassess what coding you still do.

What I would tell my past self

You are not abandoning craft. You are changing the medium. The craft is now team outcomes, decision quality, and creating conditions where excellent engineering can happen without you typing it.

Keeping all your IC habits will not keep you technical. It will keep you exhausted and half-present in both jobs. Go from programmer to manager by changing the scoreboard, leaving the critical path, building systems, practicing hard conversations, and protecting your energy like the dependency it is. That is how you survive year one — and how your team survives you.