👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: AI Interview Coach | 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
You know that feeling at the end of the day where you look at your calendar, scan your Slack history, and realise you spent six hours... reminding people to do things they already know they should do?
Update the ticket. Review the PR. Flag the blocker. Close the loop with the other team. You said it in standup. You said it in the 1:1. You said it in a DM. And somehow, here you are, saying it again.
It’s exhausting. And the worst part is that it feels productive in the moment (you are keeping things moving) but deep down you know something’s wrong and you shouldn’t be spending your time like this.
Constant follow-up isn’t a discipline problem on your team. It’s a clarity problem in your system. And until you fix the system, no amount of automation, tooling, or process improvement will get you out of reminder mode.
The reminder trap
When an engineering manager becomes the primary mechanism for keeping work moving, something has gone structurally wrong. Not with the people, with the environment those people are working in.
Your engineers are smart, capable professionals. They don’t forget to update tickets because they’re lazy or careless. They deprioritise it because, in their mental model of what matters, it genuinely doesn’t rank high enough.
And… are they wrong?
In many organisations, updating a Jira ticket is performative. Everyone knows the board doesn’t reflect reality. The real status lives in someone’s head, surfaces in Slack threads, and gets reconstructed by you every Monday morning from five different conversations. Your engineers have figured this out. They’ve learned that the appearance of process matters more than the process itself. So they invest their energy accordingly: into the code, into the problem, into the thing that actually ships.
Your reminder is just the tax they pay for working in a system that doesn’t align what’s tracked with what’s valued.
You’re not a coordinator
The deeper issue is that most engineering managers don’t realise what their “nudges” actually communicate. Every time you ping someone about a ticket, you’re not just asking for an update. You’re implicitly saying: this is what I care about right now.
That’s enormously powerful - and enormously dangerous.
Your team is constantly reading your signals. Your behaviour. When you spend Monday chasing ticket updates and Tuesday asking about a tech debt initiative and Wednesday following up on a cross-team dependency, you’re broadcasting three different priority signals in three days. Your team isn’t ignoring you. They’re drowning in conflicting cues about what actually matters.
Early in my management career, I was proud of how “on top of things” I was. I had a mental model of every open workstream and I checked in on all of them, constantly. What I didn’t see was that my team had started waiting for my nudges before acting on anything. I’d accidentally trained them to treat my follow-ups as the real prioritisation system. If I didn’t ask about it, it must not matter yet.
I’d built exactly the dependency I was trying to eliminate.
If you’re enjoying this article, consider subscribing to get:
✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide
Create a system for clarity
You don’t need better tooling or stricter process. You need to build system - an environment where your team knows what matters, why it matters, and what “done” looks like without you having to say it every day.
Here’s what that looks like in practice:
Make priorities explicit and ruthlessly narrow. If everything is important, nothing is. Your team should be able to tell you, at any moment, what the top two things are. Not the top ten. Two. If they can’t, you haven’t been clear enough. In your next planning session, try this: after laying out the work, ask each person to share what they think the single most important thing is this sprint. If you get different answers, that’s your problem to solve.
Connect the work to the “why” every single time. Engineers don’t resist process for fun. They resist process that feels disconnected from outcomes. When you explain why having tickets up to date matters, then it becomes meaningful. When you just say “please update your tickets” it just feels like busy work.
Design accountability into the workflow, not on top of it. If the only way you know a PR is stale is by manually checking, you have an architecture problem, not a people problem. Set up branch-to-ticket automation. Make PR age visible in your team’s daily workflow. Use your CI pipeline to surface what’s stuck. The goal isn’t to automate the nagging - it’s to make the state of work visible to everyone, so the team self-corrects without you being in the loop at all.
Stop treating standup as a status meeting. If your daily standup is people reading ticket descriptions back at you, it’s broken. Standup should be for exactly one thing: surfacing surprises. “This is taking longer than I thought because of X.” “I’m blocked on Y and need help.” “I’m going to miss the Thursday target.” If there are no surprises, standup should take three minutes. If people aren’t surfacing surprises, it’s because they don’t feel safe to, or they don’t understand that surprises are what you need from them.
Invest in context, not control. The best teams I’ve worked with didn’t need reminding because every person understood the landscape well enough to make their own priority calls. They knew what the business cared about this quarter. They knew which cross-team dependencies were fragile. They knew which stakeholder was watching which metric. That context didn’t arrive by accident - their manager invested time in sharing it. Your 1:1s shouldn’t be status check-ins. They should be context-sharing sessions where you’re constantly expanding your team’s view of the world beyond their individual tickets.
The litmus test
Take a week off. Not a “half-checking-Slack” week off. A real one. When you come back, look at what happened.
Did work stall? Did tickets pile up? Did cross-team communication break down? If so, you’re still the system. The team is depending on your presence to function, which means you haven’t built something that sustains itself.
Or did things mostly keep moving? Did people make reasonable priority calls? Did they flag blockers without being asked? That’s the signal that your team has internalised not just what to do, but why and when it matters.
You’ll never eliminate every follow-up. Complex work in large organisations will always require some coordination. But there’s a vast difference between occasionally nudging a stalled workstream and spending half your week as a human Jira bot.
Your job is to build systems that work - and then focus on what only a leader can do: growing your people, shaping strategy, and making your team’s work matter to the organisation.
That’s the work worth doing. And you can’t get to it if you’re busy reminding someone to move a ticket from “In Review” to “Done”.
If you enjoy articles like these, you might also like some of my most popular posts:
See you in the next one,
~ Stephane