Almost nobody trains you to be an engineering manager. You were good at writing code, so you got handed more people and more meetings, and one day the job was leading a team instead of shipping features.
Nobody sat you down and taught you how to do it. You learn it on the job, in the middle of doing it, which is a strange way to learn anything.
That creates a specific trap.
The pull is always back toward the work you already know how to do. Tickets, standups, the next fire. Getting into the weeds feels productive because it's the thing you're good at.
But a manager who only does that has quietly stopped doing the actual job, which is noticing whether the work still makes sense and where the team is really headed.
That's the whole tension of engineering management: staying close enough to the work to be useful, without disappearing into it.
Nobody holds that tension by accident. It takes a deliberate habit, something that pulls you up out of the weeds on a schedule, whether the week felt busy or not. So I gave myself one.
Introducing the Focus Five
The Focus Five is a small habit I put together to fight that pull, and one I give the managers on my team at Full Scale. Once a week you sit down by yourself and answer five questions. Not to report status to anyone. To step back and look at the whole picture: did we move, did we learn, are we even pointed in the right direction, and what do I need to change.
This is personal reflection. You're a leader, so it's reflection on both fronts, how you did and how your team did. The point is to make yourself stop and think critically about how things are actually going, instead of running on autopilot week after week. It's easier to be honest with yourself than in a room full of people, and that honesty is the whole value. ("We" here means your team and you, together.)
Underneath all five questions is really one question: are we getting a return on the team? A software team is the most expensive thing most companies buy, and the manager's job isn't to keep everyone busy. It's to make sure all that effort turns into progress on things that actually matter. Are we moving? Are we working on the right things? Or are we busy and distracted, pouring effort into work that won't matter in a month? The five questions are just different ways to check that same thing.
How to use it
A few habits keep this from collapsing back into a to-do list.
No tickets. Don't answer these by listing what got worked on. If an answer fits on a Jira card, it's the wrong altitude. Make yourself think about the forest, not the trees.
Be honest with yourself. "I don't know," "nothing," and "not much" are real answers. They're often the most useful ones. Don't talk yourself out of them.
A thin answer is a signal, not a failure. A week where you and your team didn't get much done is the most valuable thing this can surface, as long as you do something about it.
End with a change. Reflection that changes nothing by Monday is wasted. At least one of these questions should turn into something you actually do differently this week.
This is about the work. The five questions point at what your team is building and where it's going. How individual people are doing is fair to think about too, but the place you act on that is your one-on-ones.
The five questions
1. What did we accomplish last week?
This is a momentum check, not a victory lap. Did the team actually move, or did we tread water? Don't recite a task list. Render a verdict. If the honest answer is "not much," that's the signal to change something, and it sets the stakes for everything else.
2. What did we learn from it?
What do you know now that you didn't a week ago? Learning and progress aren't the same thing. The team can ship a lot and learn nothing, or ship nothing and learn the approach won't work. If the answer is consistently "nothing," you're either coasting or not pushing into hard enough problems.
3. Are we still building the right thing?
The most important question, and the easiest to skip. The team can accomplish a ton, stay focused, and still build something nobody needs. Stop and check: does this still serve the customer? Would it matter to a real user if you shipped it tomorrow? If the answer is shaky, everything else changes.
4. What help do we need right now?
This forces you to admit the team can't do it all alone. What's blocking us, and who can clear it? The point is to catch blockers while they're still small, before they quietly cost you a week.
5. What can we say no to?
Focus is a weekly decision, not a one-time one. What can the team drop, defer, or stop doing? Saying no is how you protect the yes. If you can't name something to cut, you probably aren't really focused.
The shape of it
Read in order, the five climb out of the weeds on purpose:
What moved, then what it taught us, then are we even pointed right, then what we need, then what we cut.
That's you stepping back, getting your bearings, checking the direction, and then re-committing the team's energy. In a good week, these are a tune-up. In a stalled week, they're how you catch it before it becomes a stalled month.
But no single week is the point. The point is the loop. You reflect, you learn something, you change one thing, and then you do it again the next week. Run that loop fifty times a year and the gains compound. The team keeps catching what isn't working while it's still cheap to fix, and keeps adjusting toward what is. That's what constant improvement actually looks like up close. It isn't a big initiative. It's a small correction, made over and over.
This isn't only for new managers, either. The best managers I know are the ones who never stopped running some version of this loop. That's usually how they got good, and it's how they stay good. Experience doesn't graduate you out of reflection. If anything, the longer you do the job, the easier it is to run on autopilot and assume you already know how the week went. The loop is what keeps that assumption honest.
Here's the part that's easy to miss: you only get that loop if you stop. A team that never pauses to reflect doesn't improve. It just repeats the same week over and over and calls it experience. You don't get better by working harder or moving faster. You get better by stopping long enough to see clearly, and then changing something. The Focus Five is how you make sure that stop actually happens.
And maybe the most valuable thing that ever comes out of it is the week you stop and realize you need to quit doing something. Not do it better, not do it faster. Stop. Some project, some process, some meeting that made sense six months ago and doesn't anymore. Nobody catches that while their head is down. You only see it when you pull up and look. If the Focus Five does nothing else, getting you to kill the wrong work before it eats another month is worth the whole habit.
The courage to improve yourself
There's a name for what this really asks of you. In Product Driven I write about courage as one of the pillars of a healthy team: the psychological safety that lets engineers speak up, push back, and ask why. The Focus Five is that same courage pointed inward. It takes courage to write "not much" and mean it. It takes courage to admit the team is building the wrong thing, or that the meeting you set up is the thing to cut.
Nobody trained you for this job, so getting better at it is on you. And getting better starts with the honesty to see clearly, even when what you see isn't flattering. That's the first step, and it's the hardest one. The courage to improve yourself.