What Does an Engineering Manager Actually Do All Day?
At 5:00 PM you close the laptop after a day of meetings, 1:1s, a hiring discussion, a dependency you unblocked, and two conversations nobody else was going to have – and you wonder: what did I actually accomplish? You wrote no code, shipped nothing, and closed no ticket. So were you productive? Almost certainly yes.
Engineering management has no contribution graph, so the job is easy to do and hard to measure. This guide breaks down what you should actually be doing all day: the responsibilities, the time split, the decisions, and the traps that make the role feel busy without being effective.
The job in one sentence
That sentence sounds simple until you try to run a day by it. The work behind it is indirect: you create clarity, you remove obstacles, you make decisions, you develop people, and you prevent problems. None of it shows up in a commit, and all of it compounds.
If you find yourself evaluating your days by what you personally produced, you are grading management on the wrong scoreboard. The question is not “did I ship anything?” It is “did I make it easier for someone on the team to ship?”
Everything on your calendar should map to one of five buckets
People, delivery, technical direction, stakeholders, and the organization around the team. If an activity does not fit into one of these, it is usually a candidate for delegation, automation, or refusal.
The percentages are a mental model, not a rule. During a hiring push, people can swallow the week. During an incident, technical work temporarily dominates. The test is whether your time reflects your actual responsibilities – not whether it matches a spreadsheet.
Your highest-leverage recurring activity
A 1:1 is not a status update. You already have Jira, Slack, dashboards, and pull requests for tracking work. A 1:1 is about the person: what frustrates them, what they want next, what they are avoiding, and what they would never write in a ticket.
A useful structure for a 30-minute 1:1:
- 5 min · how are they, really
- 20 min · their agenda
- 5 min · your feedback and context
The most important skill is listening without immediately solving. When an engineer says “I’m frustrated with this project,” your instinct is to fix it. First find out what they need: a solution, context, a removed obstacle, or simply someone who understands. Solve too early and they stop bringing problems at all.
Never cancel a 1:1 twice in a row. If your calendar keeps eating them, your team will learn exactly what you think of them – and you will hear about it in retention numbers months later.
Blockers are your queue
An engineer waiting on another team’s API, a security approval, infrastructure access, a vendor response, or a decision nobody owns can sit for three days. You can often resolve the same thing with three messages and one conversation. That asymmetry is the core leverage of the role: you trade your access for their velocity.
The same blocker recurring every month is not a blocker – it is a design failure. Fix it once at the root: a better ownership model, an automated approval, a written decision. Unblocking individuals is daily work; unblocking the system is the job.
Manage priorities, not tasks
The easiest mistake for a new manager is becoming a Jira administrator. You do not need the status of all 50 tickets. You need to know which three are critical, which deadlines matter, what is blocked, and – above all – which work should not exist.
The senior question is not “is this task done?” It is “should we be doing this task at all?” Killing or deferring the right work is as valuable as shipping the rest, and most teams feel it more.
- What are we trying to achieve
- What does not matter right now
- Who owns it
- What does success look like
Be a buffer, not a shield
Engineers need uninterrupted time to solve hard problems. A Slack ping, a meeting, a production question, an urgent request – each one costs far more than the minute it appears to take. Part of your job is absorbing that noise: pushing back on unnecessary meetings, consolidating requests, and filtering the work that does not matter.
But do not become a wall. Engineers still need context to make good decisions. Remove noise, not information. The goal is that the team feels the priority changes, not every tremor that produces them.
Stay technical, without being the bottleneck
You do not need to write most of the code, but you must stay close enough to smell a bad decision before it ships. That means reading design docs, sitting in on reviews, and knowing the state of the systems your team runs – cloud architecture, Kubernetes, CI/CD, observability, security, and cloud costs if you manage a DevOps or platform team.
When someone proposes moving a workload to Kubernetes “because it will make everything easier,” your job is not to agree or block – it is to ask what problem is being solved, what it will cost, what complexity it adds, and what alternatives were considered.
Decide, delegate, or consult
New managers tend to either decide everything – becoming the bottleneck – or delegate everything without guidance – creating chaos. A simple ladder keeps both failure modes in check.
Push everything that can be pushed down the ladder, and make the things that must stay with you quickly and transparently. Teams forgive decisions that were thoughtful; they stop trusting managers who avoid them.
Hiring is organizational design
Hiring is not an HR function – it is yours. One strong hire changes your next year, and one bad one changes it in the other direction. You should know the gaps in your team’s capability profile – the missing networking expertise, the absent security depth, the lack of architecture experience – because your next hire is how you fix them.
Keep a pipeline running even without an open role. And treat onboarding as part of the job: the first 90 days decide whether a new engineer thrives or drifts.
Stakeholders, translation, and team health
A large part of the job never appears on a plan: translating between engineers and the business, managing up, and keeping the team healthy. An engineer saying “we need another quarter to refactor this” sounds like “we don’t want to deliver” to a stakeholder. Your job is to restate the trade-off – ship now and take on months of operational risk, or invest now and reduce it – so everyone can decide with full information.
Upward communication follows a simple shape: what happened, why it matters, what we are doing about it, what we need from you. That beats a status report nobody reads.
And watch the health signals: excessive hours, recurring frustration, blame culture, constant firefighting, people quietly avoiding responsibility. A team that delivers while burning out is still unhealthy – it just has not shown you the bill yet.
The traps that feel productive
What a healthy calendar looks like
No two days are identical – team size, project phase, hiring, and incidents all shift the mix. But a strong day has a shape: unblock early, protect deep work, keep 1:1s sacred, and leave buffer for the unexpected.
Incidents, blockers, urgent messages – not every Slack message. Clear the path before the team starts.
Listen for blockers and changed priorities. Speak mainly to clarify ownership and decisions.
Strategy, planning, hiring reviews, feedback drafts. This is your maker time – protect it like you used to protect a deploy window.
About the person, not the project. Career, blockers, feedback, anything they bring.
Resolve a dependency, align on scope, push back on what cannot be done well this quarter.
Interview, debrief, or pipeline review. Batch it instead of scattering it across the week.
Actually take it. A burned-out manager produces a burned-out team.
Ask the question nobody asked: what are we optimizing for, and what does this trade away?
Coaching, feedback, or a skip-level conversation. Spread 1:1s across the week rather than stacking them.
Mentoring a tech lead, planning structure, improving a process, writing down what you learned.
What changed today? Who is blocked? What decision is still mine? Then stop – the evening inbox is not the job.
The weekly scorecard
Since the work is invisible, you need a deliberate scoreboard. At the end of each week ask five questions:
- Did I make priorities clearer
- Did I remove a meaningful blocker
- Did I help someone grow
- Did I make a decision the team could not
- Is the team more independent than last week
The last question is the most important one. The better you get, the less visible your personal contribution becomes – the team decides more, ships without you in the room, and stops routing everything through you. If someone asks “what does the manager actually do?” that is often a sign you are doing it well.
Longer-term signals: the team ships valuable work with less drama, people grow and take on ownership, you are not the single point of failure, stakeholders trust the team’s commitments, and recurring problems get fixed at the root instead of patched.
Popular questions about the engineering manager role
Q1What does an engineering manager actually do all day?
Run 1:1s, unblock the team, set and defend priorities, review designs, make decisions the team cannot make, communicate with stakeholders, hire, and improve how the team works. Almost none of it produces a visible artifact – and that is normal.
Q2How much time should an engineering manager spend on 1:1s?
Weekly 30-minute 1:1s per direct report is a common baseline, which puts people work at 25–35% of a typical week. Junior engineers and anyone struggling get more; stable seniors can go bi-weekly. Never cancel twice in a row.
Q3Should engineering managers write code?
Some, but never on the critical path. Throwaway spikes, internal tooling, and small fixes keep you credible and current. Code that the team depends on will stall on your availability – that makes you the bottleneck.
Q4How do I avoid becoming a bottleneck?
Push decisions down the ladder: decide only what is high-stakes or irreversible, and delegate the rest with clear constraints. Review at milestones instead of daily check-ins, and treat recurring requests for your approval as a system problem to fix.
Q5How do I measure my work if I did not produce anything tangible?
Track what you changed for other people: blockers removed, priorities clarified, decisions made, engineers coached, friction reduced. The weekly scorecard in this guide is a workable replacement for the contribution graph.
Q6How is the role different for a DevOps or platform manager?
The same five responsibilities, plus a heavier technical and compliance load: audit evidence, security findings, control reviews, and translating infrastructure work into language that satisfies regulators. In regulated industries that is a real share of the week, not overhead.
Q7How many meetings is normal for an engineering manager?
Plenty – the calendar is your production environment. But a healthy week leaves room for deep work and buffer. If you are back-to-back from nine to five every day, you are not managing, you are reacting.
Q8I feel like I did nothing today – is that a problem?
Not by itself. The output of management is delayed and indirect: you see it weeks later, when the team ships something hard without a death march or someone who struggled leads their first project. If the feeling persists, run the weekly scorecard to find what you are actually skipping.
Management is not “senior engineer plus meetings.” It is a distinct craft based on leverage through other people and through systems.
Your best days will look unremarkable: a good 1:1, a cleared blocker, a decision made with confidence, a team that ships without drama. Your worst days will feel like pure administration. The difference between a good manager and a great one is not the absence of the latter – it is the presence of the former, consistently.
If you can describe your day in terms of people, priorities, and decisions, you were managing. If you can only describe it in terms of meetings, you were busy. Learn to tell the difference – and if you want the full picture of the transition, our guide on moving from senior engineer to engineering manager covers what changes and how to plan the first 90 days.