👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
Gloria Mark, a professor at UC Irvine has spent two decades measuring attention at work. She found it takes about 23 minutes and 15 seconds to fully return to a task after a meaningful interruption. A joint study by Qatalog and Cornell found that even switching between two apps costs about 9.5 minutes of lost momentum.
The person generating the bulk of a team’s interruptions usually isn’t a badly-timed meeting invite, or a noisy slack channel. It’s the manager. Every “quick question” or “can you jump on a call” is 23 minutes of someone else’s focus, spent by you.
I used to read that stat and think it was an argument for eliminating interruptions, but it’s not that. The habits that made me efficient as a senior engineer, the ones I still see recommended to new engineering managers everywhere, assume that if you protect enough deep work, the rest sorts itself out. Does it though?
What I follow as an Engineering Manager is a smaller set of habits, rebuilt for a job that’s fundamentally about other people’s context switching. Four of them changed how I run my week.
1. The decision log
As a senior engineer, I wrote everything somewhere. Every gnarly bug, every architecture decision, every “why did we do it this way” started as a messy doc and ended up as a design doc or a jira ticket. It worked, because the audience for that writing was future-me and the two or three engineers touching that system.
That same habit applies for engineering managers. Why you didn’t promote someone this cycle. Why you descoped a feature under deadline pressure. How you plan people’s progression and the steps they need to follow to get where they want to be. All of that benefits from being documented.
You need to have a decision log for your judgment calls. One line, added the day you make the call: what you decided, why, and what you’d need to see to change your mind.
The first time this paid off for me was a headcount decision I’d made and half-forgotten. Six months later, my skip-level manager asked why I hadn’t backfilled a role. I had the actual reasoning in front of me in 10 seconds. That’s the whole point... the log isn’t for your team. It’s so you’re never rebuilding your own reasoning from memory, under pressure, in front of the person questioning it.
2. The near-miss review
When there’s an incident it’s good practice to do a post incident review. How about when we just about avoid one?
I love having postmortems that cover the outage that almost happened, not just the one that did. That can also be applied it to the other parts of your job. The meeting where you almost said the wrong thing to someone. The 1:1 where you nearly let a fixable performance issue slide because confronting it felt harder than avoiding it. The moment you caught yourself about to side with the loudest person in a room instead of the person who was right.
Those near misses are available to you for review and almost nobody reviews them because there’s no known ceremony for it.
You can create one for yourself quite simply. Just book in your calendar fifteen minutes every week, with one set of questions. Where did I almost mishandle something this week, and what made me catch it in time? Was it luck, or a signal I got right, and can I get that signal earlier next time?
I started keeping mine next to my decision log, and a pattern that showed up quickly was that most of my near misses happened in the same 20 minutes before a 1:1 I’d been avoiding. Knowing that changed how early I now flag a conversation I’m dreading, instead of letting the avoidance itself become the risk.
That’s two of the four. The other two are the ones that cap the interruptions I opened this issue with, including the exact rule I follow to prevent myself from sending “got a sec?” type of meetings: