A Day in the Life of an Engineering Manager: What the JD Doesn't Tell You

It's 8:47am. Your on-call engineer paged at 3:14am for a Postgres replica that recovered itself by 3:22am, which means she got eight minutes of sleep instead of the rest of the night. Your skip-level wants a roadmap update by noon and you haven't opened Notion yet. You have a 1:1 with a senior IC in 13 minutes that you haven't prepped for, and the recruiter who placed you in this job six months ago described it as "leading a high-performing team."

That sentence is true the way "I run a restaurant" is true when you're actually doing inventory at 11pm and apologizing to a regular about a wrong order. It's the headline. The job is everything underneath.

This is what the day actually looks like for an Engineering Manager with 5 to 12 reports at a B2B SaaS company. Real time stamps, real interrupts, real tradeoffs. If you're an IC weighing the move, read this and ask yourself if it sounds like work you'd do for years. If you're a current EM who feels like you're failing because your day is nothing but interruptions, read this and recognize you're not failing. You're doing the job.

8:00am — Standup Prep, Slack Triage, and PagerDuty

Before your team logs on, you do the work nobody sees.

Open PagerDuty. Skim last night's incidents. Who got paged, what fired, was it real or was it the same flapping alert you flagged for cleanup three sprints ago? If it was real, your on-call needs cover today; tell them in Slack to skip standup and sleep an extra 90 minutes. If it was noise, that's a ticket for whoever owns observability. Either way, decide before standup so you can absorb the disruption instead of letting the team eat it.

Then Slack. You have 47 unreads across six channels. You're not reading for content. You're scanning for two things: who's blocked, and who's frustrated. Blocked engineers need a path cleared by 10am or they lose half a day. Frustrated engineers in public threads need a DM, not a public reply, and the DM probably needs to happen this morning.

Open Linear. Or Jira. Whichever your team uses, the question is the same: which tickets are stuck in review, which are blocked on a dependency outside your team, and which look "in progress" but haven't moved in four days? That last category is the dangerous one. An engineer who hasn't moved a ticket in four days is either stuck and won't say so, working on something they didn't tell you about, or quietly looking at other jobs. You need to know which by Friday.

You haven't written code in three weeks. You used to do this part of the day with a coffee and a compiler. Now you do it with a coffee and seven people's worth of context loaded into your head. The shift from "I write code" to "I clear paths for 7 people who write code" is the first thing nobody warns you about, and it's the part most ex-ICs grieve quietly for the first six months.

9:00am — The 1:1 You Didn't Prep For

The 1:1 is your highest-leverage 30 minutes of the week, and it's the first thing that gets sacrificed when sprint planning runs over. Today it's with Maya, a senior backend engineer. She's been here three years. She shipped your last big migration. And two weeks ago her LinkedIn quietly went from "open to opportunities: no" to "open to opportunities: yes."

You don't lead with that. You lead with: "How are you doing this week?" And then you shut up.

A real 1:1 isn't a status update. Status updates happen in Linear and standup. The 1:1 is for everything that doesn't fit in a ticket: the feedback she's been sitting on, the architecture decision she disagrees with, the fact that her manager (you) didn't push back hard enough when product cut her redesign in half. Your job is to make it safe to say the hard thing, and then act on what she says.

At 9:18am, PagerDuty fires. Not your team's service, but adjacent enough that Slack lights up. You glance at your phone. Maya sees you glance. Here's the script that works:

"That's not ours, but Slack's about to get loud. Give me 20 seconds to mute it, and then we keep going. Your time is more important than that thread."

Then you actually mute it. You don't half-listen for the next 12 minutes while your eyes track Slack notifications. The 1:1 gets your full attention or you cancel it. There is no middle option. The middle option is how senior engineers learn that their manager isn't really there, and that's how Maya's LinkedIn flips from "yes" to "I just accepted an offer."

10:30am — PR Review, But Not For Correctness

You open GitHub. Or GitLab. There are 14 open PRs across your team. You are not reviewing them for correctness. Your staff engineer reviews for correctness, and she's better at it than you are now.

You're reviewing for flow.

Who's been waiting more than 48 hours for a review? That engineer is losing momentum and probably context-switching to something else, which means when the review finally comes in, they'll need an hour to swap context back. Find the reviewer, find out why they're stuck, unblock it.

Which two PRs are touching the same file? That's a merge conflict in the making, and one of those engineers is about to lose a morning to a rebase. Get them on a 10-minute call now.

Which PR has six rounds of nitpick comments on a 40-line change? That's a senior engineer being too careful with a junior, and it's eroding trust both directions. You don't comment in the thread. You DM the senior: "Hey, the change looks fine. Approve and let's move." That's the call that nobody else will make, because nobody else has the authority to make it.

GitHub is a code tool for your engineers. For you, it's a management surface, a real-time dashboard of where attention is stuck, where collaboration is friction, and where your team's velocity is leaking out through review bottlenecks. Call this the PR queue tax. Every PR sitting more than two days costs you compound interest in lost focus, and you're the only person whose job it is to notice.

11:15am — Sprint Planning, Then The Interrupt

You're 15 minutes into refining next sprint's Linear board with your tech lead. You're pushing back on a story that says "investigate auth provider migration" because that's not a story, that's a quarter of work disguised as a Tuesday afternoon.

Slack: "hey got 2 min for a quick question?" From the VP of Product.

It's never two minutes. It's never one question. The "quick question" is "we're moving up the AI feature launch by three weeks, what can your team realistically ship by then?" That answer requires you to know your team's capacity, your existing sprint commitments, your tech debt that's gating the AI feature, your senior engineer's PTO next month, and the political reality that saying "no, we can't" is a career-defining sentence you only get to use a few times a year.

You take the call. You don't give the answer in the call. You say: "Let me look at the dependencies and come back with a real number by 4pm." Then you go back to sprint planning at 11:38am with your tech lead, who has been politely staring at her screen for 23 minutes.

This is the role no JD mentions: context translator. You sit between exec strategy ("we want AI by Q3") and engineering reality ("the auth migration blocks that, and the engineer who knows auth is on parental leave"). You don't get to say yes to both. Your job is to translate one into the other in a way that doesn't break trust in either direction. Some weeks you do this well. Some weeks you do it badly and your team gets whiplash. Both are normal.

1:00pm — The Meeting With Yourself That Never Happens

After lunch, your calendar shows "FOCUS: Q3 planning doc." It's been there for three weeks. It moves every day.

This is the meeting-with-yourself problem. The work that requires uninterrupted thought — your team's quarterly plan, your performance reviews, the architecture decision your staff engineer escalated to you on Friday — never has a hard deadline today. So it always loses to the work that does. The on-call alert. The Slack DM from the engineer who needs cover. The "quick question" from the VP.

Most EMs lose this fight. The Q3 doc gets written at 11pm on Sunday because your director needs it Monday morning. The performance reviews get crammed into the week before they're due, and they show it.

The fix is unglamorous: book the focus block on your calendar and treat it like an external meeting. Decline overlapping requests. Accept that some weeks you'll lose the block to a real fire, and that's fine, but the default has to be defended. The engineers who become Senior EMs and Directors are the ones who learned to protect their own thinking time before it became a crisis.

3:30pm — Async Notion, Not Real-Time Slack

By mid-afternoon, your brain is wrecked. This is when you should be doing your lowest-thought, highest-volume work: writing the documentation that lives in Notion and doesn't change a thing about your day but compounds across the next two quarters.

The team handbook update. The on-call runbook your engineer asked for two weeks ago. The retrospective notes from the last sprint that you promised to circulate. The hiring loop calibration doc your recruiter has been waiting on.

None of this is urgent. All of it is important. The compounding effect is that six months from now, when you onboard a new engineer, they read three Notion pages and ramp in a week instead of asking your tech lead the same questions for a month. That's the leverage of written work, and it's invisible until you stop doing it and watch the team slow down without anyone being able to point to why.

5:00pm — Promotion Packet Work

The team's logging off. You open Notion. You're writing two promotion packets (one for an engineer going Senior, one for an engineer going Staff) and a self-review for yourself.

Promo packets are the work that gets postponed every single day until performance review season hits like a truck. And the engineers who get promoted are the ones whose managers wrote the case across the entire cycle, with specific receipts, not the ones whose managers crammed it in over a weekend with vague language about "demonstrated impact."

Here's a Notion template snippet that actually works:

## Promo Case: [Name] → [Level]

### What changed in scope (last 2 quarters)
- [Specific project, owned end-to-end, with measurable result]
- [Specific cross-team collaboration with named outcome]
- [Specific mentorship moment with named mentee + result]

### Evidence the next level is already happening
- [Link to design doc they wrote]
- [Link to incident they led]
- [Link to feedback from peer/skip-level]

### Risks the panel will raise (and answers)
- [Risk]: [Pre-empted answer]
- [Risk]: [Pre-empted answer]

### Asks of the panel
- [What you need them to weigh more / less heavily]

The risks-and-answers section is the one most managers skip. It's the one that wins. Promotion panels are skeptical by default, and a packet that pre-empts their objections does 80% of the work before they open their mouths.

You finish the first packet at 5:51pm. Your kid has a recital at 7. You'll do the second packet tomorrow, except tomorrow has a 1:1 you forgot, an incident review, and a candidate panel. So you'll do it Thursday. Maybe.

The Scaling Inflection: 5 Engineers to 9

Everything I just described works at 5 engineers. It breaks at 9.

At 5, you can hold every PR in your head. You can 1:1 weekly with everyone and still have time to think. You know who's stuck before they ask, because you can see it in standup body language.

At 9, you can't. The math doesn't work. Nine 30-minute weekly 1:1s is 4.5 hours; with prep and follow-up, it's a full day. PRs you used to glance at now require a tech lead's filter before they reach you. Standups stop being signal and start being status theater because there are too many voices.

The systems you ignored at 5 become non-negotiable at 9: a written team charter so new joiners know the bar, an on-call rotation that doesn't depend on your memory, a hiring rubric that lives outside your head, and 1:1s that go biweekly for the most senior people because they need it least and weekly for the people newest to the team or newest to senior level.

When you make the shift to biweekly, somebody feels neglected. Tell them why directly. "I'm stretched thinner than I was. Biweekly is what I can sustain. If something urgent comes up, my Slack DM is open and I'll respond inside an hour." The honesty buys you more goodwill than the missing 30 minutes costs you.

What the JD Got Wrong

"Lead a high-performing team" really means:

• Protect their focus. Most of your day is absorbing chaos so they don't have to.
• Translate ambiguity. Exec strategy is vague on purpose. Your team needs tickets, not vibes.
• Defend their time. Saying no to the VP's "quick question" is part of the job, not avoidance of it.
• Write the doc no one else will write. Runbooks, charters, promo packets, retro summaries.
• Absorb stress so they don't have to. This is the unglamorous core of the role and the part that burns people out.

The JD says "drive results." The day says "write the Notion page that means the next person doesn't have to figure this out from scratch."

Closing

If everything in this article sounds energizing (the 1:1 you'd actually look forward to, the chaos you'd enjoy translating, the slow compounding of written documentation that nobody else will do), you're ready.

If it sounds draining (you'd rather ship code than absorb meetings, you'd rather solve hard technical problems than human ones), the IC track isn't a demotion. It's a different shape of senior work, and the industry is finally rewarding it properly. The Staff Software Engineer JD is the companion to this article for a reason. Read both. Pick the one whose hard parts you're willing to live with for the next five years.

The right answer is the one where the bad days still feel like work worth doing.

Learn More

• Staff Software Engineer JD (companion)
• Running 1:1s Engineers Don't Dread
• The IC-to-EM Transition
• Writing Promotion Packets That Actually Land