What’s Your Job as an Engineering Manager?

As a manager, maybe you start your day looking at your calendar, or the pings that are already piling up. It can be easy to get caught up in what people are asking of you – but your job needs to look beyond the requests and into the causes underlying them.

Here’s what I think the job of an engineering manager actually is:

You’re a force multiplier for a team, and you take responsibility for that team.

There’s a lot to unpack in that. But here I want to talk about three things:

• The timeframe you live on
• The distinction between a learning opportunity and a fuckup
• The Clarify and Shard

The Three Timeframes

As an EM, you don’t just live on one time horizon. You need to live on multiple, and that needs to change over time. Consider your week – how much time have you spent on the immediate, versus the longer term.

This is clearest when you’re ramping up on a new role. Then it roughly looks like:

This week: What is a problem this week? Get it fixed.

This month: What is a problem this month? Systematize it. Delegate it.

Next quarter, next year: What is a problem next quarter or year? Make a plan.

It’s less clear when you’re in the middle of things. Of course you go back and forth. Of course you pitch in when someone’s sick or there’s an incident. A week when you don’t get to the future is okay. Every week is not. A problem you don’t fully root cause is not the end of the world. But some of them are probably connected, and you’ll never get to those connections if you don’t get to stop and think.

The pull of the urgent is strong, and bluntly handling the urgent makes your immediate value clearer. Your real value, though, that shows up over time.

Learning Opportunities vs. Fuckups

As an EM you need to both develop your team, and hold them accountable. When faced with a person + challenge, you need to understand: what’s a learning opportunity and what’s a fuckup?

A learning opportunity is when your teammate missed something. They didn’t know, they didn’t see it, with the best of intentions they made a call that turned out wrong.

A fuckup is when the risk was called – by you or someone else – and they did it anyway.

Your job as a force multiplier is to increase learning opportunities and reduce fuckups. Learning opportunities are how people grow – they’re the place for the blameless postmortem, the non-judgemental deconstruction, and the process update.

Fuckups are unforced errors that erode trust. They are where you need to be clear on accountability, what’s negotiable – and what is not. Was the process ignored? Was something not clear?

When you’re coaching someone through these situations, say what you believe. Ask the question about what you’re curious about.

Delivery overshot by a week? Learning opportunity. A quarter? That’s a fuckup. And it shouldn’t happen again.

New manager didn’t realize the hire needed specific feedback? Learning opportunity. You told them and they didn’t do it? Fuckup.

Incident from factors no one saw coming? Learning opportunity. Same incident twice because the process wasn’t followed? Fuckup.

The learning opportunity, you can get curious about what can be learned from it.

The fuckup? The question is more direct – how did this happen, and why am I finding this out now?

Clarify and Shard

One of the ways to create learning opportunities is what I call the “clarify and shard”. It’s a leader’s job to navigate ambiguity, and create clarity for their team.

In the ambiguity, you make the ~~vibes~~ concrete. That feeling that the thing is slow, or the initiative is not working, or the process is wrong – you go into it and you come out with a point of view.

That clarity can then be sharded (delegated, not necessarily just to one person). It’s the learning opportunity – with some guard rails that prevent it becoming a fuckup.

What does this look like in practice?

For example: the vibes say you’re no longer confident in the hiring process – that’s the ambiguity. Making it concrete looks like figuring out why that is. What parts of it aren’t working, or aren’t giving signal. Once the outcomes needed are clear, you can delegate.

Another: the vibes say DevEx is slowing the team down. Getting concrete is about digging into what is slower and why, and whether or not that’s a problem. Maybe the change is that you have a PM now and they want to spec things? That’s good. But if they are becoming a bottleneck – that’s not. Now you know what you need to fix.

Bringing it Together

Put these together:

• This week’s problem, fix it – then figure out if it’s a learning opportunity or a fuckup.
• This month’s problem, run the clarify and shard.
• Next quarter or year – make space for the ambiguity. You have some thinking to do.

So when you look at your calendar tomorrow, or that pile of pings – remember you’re not just responding to requests. You’re looking for patterns, building systems, and clearing the path ahead. That’s what makes you a force multiplier.

The hardest part? You won’t see the impact of the third timeframe for months. Your calendar will keep filling up with the urgent. But your job is to protect that thinking time anyway – because that’s where your real value as a leader shows up.

---

If this was helpful, you might also like The Engineering Manager Survival Guide. An 8 week fully async course, to help you survive – and thrive – as an EM in the post-ZIRP era. Start March 13th. Early bird ends Feb 28th.