The Blameless Postmortem Solved the Wrong Problem

You have twelve engineers. Velocity is down. Standups are running long. Two workstreams keep stepping on each other in code review. The obvious move feels like splitting the team —…

You have a senior engineer who's been carrying the team for eighteen months. They know the codebase, the customers, the history of every bad decision made before you arrived. A man…

You built it eighteen months ago. A custom deployment dashboard, an internal metrics aggregator, a homegrown feature-flag system — something that felt genuinely necessary at the ti…

You already wrote about this once — back in July, the argument was that promoting the IC into management is treated as a reward rather than a capability decision. This is the upstr…

You've already written about this twice. The June post covered when coordination costs justify restructuring. The July post covered the signals you explain away after the fact. Wha…

You've been managing this engineer for eighteen months. Strong output, respected by peers, never misses a deadline. Then something shifts — not their code quality, but everything a…

You built the internal tool six months ago. It solved a real problem. Engineers loved it. Then the person who built it moved to a different team, and now it's a haunted house — eve…

You've written the post-mortem. You've run the retro. You've added a new Slack channel to "improve communication." And somehow, three months later, you're writing another post-mort…

Most engineering managers facing their first management gap do the same thing: they look at their best senior engineer, decide that person has "leadership potential," and hand them…

At some point in the last year, someone on your team said "on-call is getting rough." You nodded, maybe added a person to the rotation, maybe promised to look at the alert volume.…

Every team that decides to build internal tooling thinks they're making an engineering decision. They're not. They're signing a long-term maintenance contract — and most of them do…

You already wrote the post about when to split — back in April, the signals were standup bloat and ownership ambiguity. But there's a harder version of this question that comes up…

You already know you have a problem. The engineer is missing deadlines, or the code quality is slipping, or they're checked out in planning. You've had one uncomfortable one-on-one…

You have a sprint planning meeting in two days. Your product lead wants three new features scoped. Your tech lead wants to spend the next two weeks on refactoring the event process…

You have a senior engineer who's been with you two years. She's technically strong, well-liked, and has been informally leading the team through your last two sprints. Everyone ass…

You have two teams that keep stepping on each other. Shared components, overlapping roadmaps, a Slack channel that's become a permanent escalation queue. The obvious fix feels like…

You have an engineer who ships. Consistently. They're the one you call when something's on fire at 2am, and they actually pick up. They've built systems that three other people dep…

You're three weeks from a product milestone. The team is moving. Then someone opens a PR that's half feature, half workaround — patching around a data model that's been wrong for e…

You've done the work. The team has capacity mapped, dependencies identified, technical debt prioritized. You've built a case for why the next two quarters need to focus on platform…