Engineering-Management on Coffee or Blog

Fumbling Through Loss

Tue, 29 Sep 2026 00:00:00 +0000

I got it wrong the first time and probably the second time too. I’ll likely get it wrong again, so here I am writing a reminder to future me.

A beloved colleague died unexpectedly. The email came the same day, evening for me, direct, no euphemisms. The video call was set for the next afternoon, late enough that people had a night to sit with it before they had to be on camera together. Someone senior said her name out loud and then let the silence sit instead of filling it. By every measure I’d use later to judge how this should go, it was done right.

Then, the following week, we sold part of the business, and a dozen people I’d worked closely with - people I looked forward to working with - were suddenly on someone else’s org chart. There was no email like the first one. Just an announcement calling it a strategic move and a Slack channel that went quiet within hours. Nobody had died. But it landed on top of someone who just had, and I remember thinking: we know how to do this well, we did it a week ago, so why does this one feel like an afterthought. I didn’t say that to anyone. It felt like complaining about a paper cut in a room where someone had just been in surgery.

Nobody hands you a runbook for this. We have runbooks for a full disk at 3 AM. We have severity levels, escalation paths, comms templates, and a blameless review afterward. When a person is gone, most of us walk into the room with nothing, and the team watches to see what we do with it.

This is what I’ve pieced together since. None of it is expertise, believe me. It’s fumbling, written down.

Kenneth Doka has a name for grief that isn’t openly acknowledged or socially allowed: disenfranchised grief. Most workplaces create it without meaning to, because nothing at work makes room for grief. There’s no casserole, no service you’re expected at, no week off. There’s a Slack announcement, a reassigned Jira board, a cold email, and a standup the next morning where everyone is waiting to see if it’s okay to talk about it.

Usually, it isn’t, because nobody says it is. So people don’t. They process it alone or not at all, and it shows up later as the engineer who stopped arguing in design reviews, or the one who started interviewing.

It doesn’t have to be a death to land this way. I think about three kinds:

Someone dies. The obvious one, and the one we’re least equipped for. The shock is real, and so is the operational hole.

Someone leaves without leaving. A divestiture, a carve-out, a team transferred to another company. Pauline Boss calls this ambiguous loss: the person is gone from your world but not gone. They’re still on LinkedIn. You still see their name in git blame, their avatar in an open pull request. Their Slack account is deactivated and their knowledge is still the only copy of how half the system works. It gets announced as a strategic win, so there’s nothing to mourn, officially. People mourn anyway, quietly, with no end point.

A third of the room is gone. Layoffs. David Noer wrote about this in the early 90s and called it layoff survivor syndrome. The people who stay carry guilt about why it wasn’t them, scan every all-hands for the next signal, and pick up the work of the people who left without anyone adjusting a single deadline. A Leadership IQ survey of about 4,000 layoff survivors found 74% said their own productivity dropped and 69% said the quality of the company’s product did too.

That tracks with everything I’ve seen. People under threat stop taking risks. They pick the safe option, ship less, flag less, propose nothing. Stevan Hobfoll’s Conservation of Resources theory says it plainly: under stress, people protect what they have left. Your team is conserving.

Three different losses, one failure mode. The company treats it as a transaction and moves on. The people can’t, or can’t without feeling like they’re doing it wrong.

The systems keep going. This is the part I’d want someone to have told me.

When someone dies, the automation doesn’t know. Their name is still in the PagerDuty rotation. They’re still in CODEOWNERS, so PRs auto-request their review. The calendar invite for their 1:1 still fires every Tuesday. A bot pings the channel asking them to update a stale ticket. A welcome-back reminder from the HR tool arrives the day they would have returned from PTO.

Each one of those is a small wound delivered by a system someone on your team built. They’ll notice every one. I notice every one.

The first week is still the best version of this I’ve seen, so the checklist starts there. Treat it like an incident, because it is one:

Confirm the facts, then say it the same day. Plainly, no euphemisms. Rumour spreads faster than a Slack post.
Tell the people closest to them first, privately, before the broad announcement. Not in a channel. Not by email if you can help it.
Give people a night before you put them on camera together.
When you do get everyone together, say their name and let the silence sit. Don’t fill it.
Pause the automation before it fires: on-call schedules, code review assignment, recurring meetings, ticket bots, HR and payroll workflows, anything that sends a message with their name on it. Don’t deprovision the account in a way that erases their history. Their commits and docs are part of the team’s memory.
Give people the EAP number and say out loud that using it is normal. Then use it yourself if you need to.
Don’t reassign their work in the same breath as the announcement. It will need to happen. It doesn’t need to happen that day.
Let the team decide how they want to remember them. Some teams want a channel, some want a donation, some want to name something after them. It’s not yours to pick.

Divestitures and layoffs need the same playbook. We had it. We didn’t use it the second time. Say what happened plainly. Name who’s gone. Don’t let the reorg announcement be the only acknowledgement. How the company treats the people who left is the clearest signal the people who stayed will ever get about how they’ll be treated.

As a leader, you lost them too.

Arlie Hochschild’s term is emotional labor, managing your own feelings to meet what the job expects. For a manager during a loss, the job expects calm. So you do the work of being calm, all day, for everyone, and then you get to your own feelings sometime after the last meeting, if at all.

You’re also in the middle. Leadership above you wants the roadmap back on track. Your team below you needs time and a lighter load. Both are reasonable. They can’t both be fully met, and you’re the one who has to decide how much of each to give, usually without guidance, usually while absorbing some of the dropped work yourself.

I don’t have a clean answer for this. What’s helped:

Telling my team that I’m finding it hard too. Not performing it, just saying it. It gives them permission they won’t otherwise take.
Saying what I expect, out loud. “I don’t expect to see you online until the next steps meeting.”
Having one peer manager I can be honest with. Not my boss, not my team.
Pushing the roadmap conversation upward explicitly instead of quietly eating the gap. “We lost a person and a third of our context. Here’s what moves.” That’s a capacity conversation that you’re allowed to have.

If you’re the person above the managers: they need somewhere to put this. If you don’t give it to them, you’ll find out where they put it when they resign.

What I’d do now is mostly small and unglamorous.

Say the thing. Name the person. Name what happened. Staying quiet can feel like you’re giving people space. From their side, it looks like nobody noticed. That Leadership IQ survey had one bright spot: survivors who rated their manager high on visibility, approachability, and candor were 72% less likely to report a productivity drop. Being present and straight with people moves the number.

Don’t aim for closure. Especially with layoffs and divestitures, there’s no event that ends it. People will keep running into the gap for months, every time they need the person who knew how the billing pipeline worked. Expect that. It’s not a performance problem, but it is a visibility problem: the time lost working around that gap won’t show up anywhere unless you put it in front of leadership.

Cut scope on purpose. The team is smaller and sadder. Pretending it has the same capacity is how you turn grief into burnout. Stop the low-value work explicitly and let the team help decide what goes.

Make it safe to not be fine. Amy Edmondson’s psychological safety isn’t a poster. After a loss, it’s whether someone can say “I can’t take that on right now” in standup and have it be okay. It doesn’t come back on its own, and you rebuild it by going first.

Keep checking in after everyone else stops. Week one, everyone is kind. Week six, the calendar has moved on and the person who’s still struggling is alone with it. Put a reminder in your calendar six weeks out. Then ask. Let them brush it off if they’re fine. Be the one who remembered.

Accept that you’ll fumble. You’ll say something clumsy. You’ll forget to pause a bot. You’ll check in with the wrong person and miss the right one. Show up anyway.

Those two weeks sit side by side for me - one loss handled so well it became the standard I measure everything else against, the other that never got a fraction of that care because nobody called it a loss out loud.

If I could go back, I’d tell myself the paper cut is still a cut. It doesn’t need a comparison to earn the right to be noticed, and neither does anyone on your team who’s still running into the gap six weeks from now.

I bring them up now, usually when someone I’m talking to is in their own version of it and doesn’t quite believe it’s allowed to hurt this much. It’s not advice at that point, just proof that someone else has been there. I still get a pit in my stomach telling it, longer after it happened than I’d have guessed. I’ve stopped expecting that to go away.

Release Discipline in the Age of AI-Accelerated Development

Mon, 17 Aug 2026 00:00:00 +0000

Photo by Patrick Konior on Unsplash

A maturity model for shipping fast without breaking customer trust.

I made an earlier argument that deploying code and releasing a feature are not the same event, and that treating them as one causes unnecessary risk. That argument still holds. But the environment it was written for has changed.

AI-assisted development has made writing and shipping code dramatically cheaper. A change that used to take a sprint now takes an afternoon. That’s a genuine gain, but it doesn’t automatically make the judgment around releasing that change any faster or better. When the cost of producing change drops and the discipline around exposing change doesn’t rise to match it, the result is exactly what customers are describing: things move, break, or reappear differently, without warning, more often than they can absorb.

Here’s the core claim: in 2026, the bottleneck in software delivery is not how fast we can write code. It’s how deliberately we control who sees a change, when, and with what warning. AI removes the first constraint. It makes the second one more important, not less.

This isn’t a call to slow engineering down. It’s a call to stop routing all of that new speed straight at the customer, unfiltered.

The symptom we’re solving for

Customers aren’t complaining that we ship too much. They’re complaining about three specific things, and it’s worth being precise because each has a different fix:

Rate of change — things they learned last month look or behave differently now, with no signal it was coming.
Forced change — a workflow they depend on changed or disappeared, and they had no way to stay on the old behavior while they adjusted.
Unpredictability — they can’t tell the difference between “this is a bug” and “this is intentional,” because both arrive the same way: silently.

None of these are solved by shipping less. All three are solved by separating four things we currently bundle into one event: code lands in production, a feature becomes visible, a customer is told about it, and an old behavior is retired. Each deserves its own timeline, its own owner, and its own decision.

The four-question test for every user-visible change

Before a change reaches a real customer, someone should be able to answer:

Question	Answer determines
Is it visible?	Whether it needs a flag at all
Is it disruptive?	Whether it needs staged rollout or can go straight to 100%
Is it reversible?	Whether we need a dual code path, or a simple toggle is enough
Does it remove something?	Whether it needs a deprecation notice and a minimum notice period

A change that’s invisible (backend refactor, performance work) skips all of this, deploy it and move on. Everything else routes through the toolkit below. The mistake teams make under AI-accelerated velocity is treating all changes like the first category because the code was cheap to produce.

Blast-radius classification

Use this before merge, not after a customer complains. It should take seconds, not a meeting.

Class	Example	Rollout pattern	Notice required
Invisible	Refactor, perf work, dependency bump	Deploy directly	None
Visible, additive	New optional feature, new button	Flag → rings → GA	Changelog entry
Visible, behavioral	Changed default, changed workflow	Flag → opt-in beta → staged % → GA	Advance in-app notice + changelog
Disruptive / breaking	Removed capability, forced migration	Dual path, minimum notice window, opt-out during transition	Direct communication, not just changelog

The AI-specific risk is that classes 2–4 get produced at the same velocity as class 1, and without this checkpoint they get shipped at that velocity too. The checkpoint is cheap. Skipping it is what customers are feeling.

The toolkit

1. Feature flags, but with a lifecycle, not just an on/off switch

Flags fail long-term not because teams don’t use them, but because nobody owns their end state. A flag that’s still in the codebase eighteen months after full rollout is a liability, not a safety net. Every flag needs a stated life stage:

Rollout flag (temporary, by default): exists to ramp a change safely. Has an owner and an expected removal date at creation time. Options at end of life:
- Graduate — feature is fully rolled out and stable → flag is deleted, new behavior becomes the only behavior.
- Revert — didn’t work → old path stays, new path is removed.
- Extend deliberately — a real reason exists to keep ramping slowly (enterprise contracts, regulatory cohorts) → re-approve with a new date, don’t let it drift by default.
Operational flag (long-lived, by design): kill switches, ops-only toggles. These are allowed to live indefinitely, but should be inventoried separately from rollout flags so the two don’t get confused in review.
Permission / entitlement flag: controls who gets a capability (plan tier, beta cohort, region). Long-lived by design, owned by product.

Ownership split that matters: engineering owns whether the flag exists and works; product/support own when it flips for whom. That split is still correct, it just now needs a flag registry with an expiry date on every rollout flag, reviewed monthly, or the flag count grows faster than the org’s ability to reason about it. AI-generated code makes it trivially easy to wrap a new flag around everything; that’s a reason to enforce the registry harder, not skip it.

2. Progressive rollout rings

Don’t choose between “ship to everyone” and “ship to no one.” Use rings, and pick the entry ring based on the blast-radius class above:

Internal — team, then company-wide dogfooding.
Design partners / opt-in beta — customers who explicitly asked to try new things early. This is where self-service enablement lives (see below).
Staged percentage — 5% → 25% → 100%, gated on real usage signals and support ticket volume, not a calendar date.
General availability — announced, documented, supported.

A change only needs to pass through every ring if it’s disruptive. Additive, low-risk changes can compress rings 3–4. The point isn’t ceremony, it’s that someone decided how much exposure this change gets before it got any, instead of exposure being a side effect of when the deploy happened to land.

3. Self-service enablement (beta opt-in)

Give customers a way to choose to be early, rather than discovering they’re early. Concretely: an in-product “early access” or “labs” area where customers can turn on features ahead of GA, with a visible way to turn them back off. This does two things at once:

It converts “why did this change on me” into “I opted into this.”
It gives you a self-selected, motivated feedback cohort before wide rollout, which is a better signal than support tickets after the fact.

The precondition for this to work: opted-in features must be genuinely reversible by the customer. If turning it off doesn’t actually turn it off, don’t offer it as opt-in, that’s a forced change wearing an opt-in costume, and customers notice the difference immediately.

4. Change communication, tiered to disruption level

Not every change deserves the same announcement weight. Matching the tier from the blast-radius table:

Additive: changelog / release notes. Low ceremony, always shipped.
Behavioral: in-app notice before the change reaches a user’s account, plus changelog. Should say what’s changing and, if relevant, how to preview it early via opt-in beta.
Disruptive / breaking: direct communication (email, CSM, in-app banner with acknowledgment) with a stated timeline, not just a mention in release notes. If there’s a deadline for an old behavior going away, that deadline should be visible to the customer well before it arrives, not just to us.

A useful gut check: if a customer would reasonably say “I wish someone had told me,” the tier was too low.

5. Deprecation without forced change

The single biggest driver of the “forced change” complaint is removing something before the data says it’s safe to. The pattern that avoids it:

New path ships behind a flag, old path stays live.
Both paths run in parallel long enough to gather real usage data, not a fixed arbitrary window, but until usage of the old path is actually low or zero.
A minimum notice period is announced before the old path is scheduled for removal, sized to the disruption class (days for a minor UI tweak, months for a workflow customers have built process around).
Only once notice has elapsed and usage has dropped does the old path get deleted, as its own change, separately reviewed from the feature that replaced it.

This costs engineering effort (two paths, temporarily) in exchange for the thing customers are actually asking for: predictability. That trade is almost always worth making for anything customer-facing.

What AI-accelerated development changes, specifically

The proposal rate goes up, the review/rollout rate doesn’t automatically follow. The gap between them is where uncontrolled change leaks out. Treat rollout classification as a required step in the definition of done, not an optional nicety, it’s the part of the pipeline that didn’t get faster, so it needs to be protected, not skipped under pressure to keep pace.
Flag sprawl accelerates. If it’s cheap to generate a flag-wrapped change, flags will be created faster than they’re retired unless the registry-and-expiry habit from the toolkit above is enforced, not just recommended.
“It’s just a small change” stops being a reliable signal. AI can produce a large, behaviorally significant change with the same apparent effort as a small one. Blast-radius classification should be based on what the change does, not how much manual effort it took to write, that correlation has broken.
Volume of change is a communications problem now, not just an engineering one. If ship velocity increases, either communication cadence scales with it, or customers experience the increase as noise. Product/support capacity to write good change notices becomes a real constraint on release pace, plan for it explicitly rather than discovering it during a rollout.

A maturity model to self-assess against

Level	Deploy vs release	Flags	Communication	Deprecation
0 — Coupled	Deploy = release, always	None, or ad hoc	Release notes after the fact, if at all	Rip and replace
1 — Flags exist	Some features flagged	Used inconsistently, no registry	Changelog exists	Removal decided by engineering alone
2 — Rings defined	Standard for risky changes	Registry exists, no expiry discipline	Tiered by change type	Notice periods exist but informal
3 — Customer-facing control	Default practice	Expiry dates enforced, monthly review	Self-serve beta / early access live	Data-gated removal, formal notice
4 — Governed change contract	Assumed, invisible as a decision	Flags treated as inventory with owners	Change comms scale with ship velocity by design	Deprecation SLA is a documented customer commitment

Most orgs feeling the pain described at the top of this post are sitting between Level 0 and 1, while their code output has jumped to what used to require a Level 3 org’s engineering throughput. That mismatch, velocity outrunning governance, is the actual root cause, not “we ship too much” or “AI is risky.” The fix is closing the governance gap, not throttling the code.

Getting started, in order

Adopt the four-question test and blast-radius table as a required checklist step before merge for anything customer-visible. This alone catches most of the “forced change” and “no warning” complaints.
Stand up a flag registry with expiry dates. Even a spreadsheet beats nothing. Review monthly.
Define your rings and who has authority to move a change from one ring to the next.
Ship a self-serve early-access surface, even a minimal one. It reframes the relationship from “this happened to me” to “I chose this.”
Write a deprecation SLA, minimum notice periods by disruption class, and hold to it publicly. This is the fastest way to rebuild trust with customers who’ve been burned by forced changes before.

The bottom line

AI didn’t create the need for release discipline, it just removed the natural speed limit that used to give teams cover for not having it. The teams that get faster and keep customer trust in 2026 aren’t the ones writing more code carefully. They’re the ones who separated “we built it” from “you see it” a long time ago, and are now deliberately re-tuning that separation for a world where the first half of that sentence happens ten times faster than it used to.

Deploy fearlessly. Release deliberately. That was true before AI. It’s the whole game now.

Why Doesn't Anyone Own That?

Mon, 23 Mar 2026 00:00:00 +0000

It’s 5 PM on a Thursday. Something broke mid-morning and your team has been grinding on it for hours. Good engineers, working hard, coming up empty because the system is poorly documented and the people who built it have either moved on or moved teams. You’ve burned most of the day and you’re no closer to resolution.

So you escalate. You ping the leads. You ask in the channel where someone, surely, knows this service well enough to point you in the right direction.

Silence.

Not because nobody cares. Because nobody actually owns it. There’s a name in the CMDB, but that person will tell you they haven’t touched it since a reorg reshuffled their priorities. There’s a runbook, but it describes a version of the system that no longer exists. There’s a Slack channel with forty members and no clear authority.

This is where the real cost of diffuse ownership lives. Not in the architecture review, not in the postmortem writeup. Right here, in a live incident, with a team that has already spent most of a day spinning their wheels and a business that is losing patience.

The easy diagnosis is that engineers don’t want ownership. Nobody wants the accountability when something critical falls over. That read is intuitive, and it’s mostly wrong.

Most engineers I’ve worked with want to own something. They want the stakes, the identity, the sense that they know a system cold and it shows. Ownership is a fundamental motivator in this work. It’s one of the few things that makes the job feel like more than ticket throughput.

The problem isn’t appetite. It’s that we’ve built organizations that punish people for taking it.

We say we want owners. Then we punish them.

Most performance systems weren’t designed to reward operational excellence. They were designed to measure visible output — features shipped, projects delivered, things a manager can point to in a calibration meeting and defend. Keeping a critical service healthy produces none of that. No launch. No demo. No ribbon cutting.

Here’s what it does produce: a rating of “meets expectations.” Which, in most four-point HR scales, means no raise. Sounds fair until you consider that the engineer just spent a quarter instrumented to the gills on a service that didn’t go down, pushed for refactors the team had been deferring for two years, and responded to every incident that came their way. They did their job flawlessly. The organization scored it as ordinary because ordinary is the only category it fits in.

That engineer is not doing that again next year. Neither is anyone who watched it happen.

The performance review is just the most visible mechanism. The same signal gets sent in sprint planning when operational work gets bumped for roadmap items, in reorgs when the “boring” platform work gets deprioritized, in how leaders talk about the team that keeps things running versus the team shipping the new thing. It accumulates. People are paying attention even when you think they aren’t.

Rational engineers respond rationally. Ownership becomes a liability, ambiguity becomes protection, and the next time someone asks who owns the broken thing, there genuinely isn’t an answer.

Accountability without authority is just blame.

There’s a second trap that even well-intentioned leaders fall into, and it’s more insidious than the performance review problem because it often comes wrapped in the language of empowerment.

We assign ownership without giving people the actual power to act.

Think about what that looks like in practice. An engineer is named owner of a critical platform service. They identify that the deployment process is bypassing validation steps and creating instability. They flag it. They write it up. They ask for a two-week pause on releases to address it. The response from leadership: “We can’t stop the roadmap, let’s find another way.” There is no other way. The service degrades, falls over, and in the postmortem the question on the table is why the service owner didn’t catch this sooner. It plays out constantly, in slightly different costumes, and the person in the owner role learns the same lesson every time.

Ownership without the authority to say no to a risky deployment, to pull capacity from feature work when a system is genuinely at risk, to set a standard and enforce it — that isn’t ownership. It’s a title with no teeth. The person holding it gets the pager, gets the postmortem questions, gets the performance conversation, and had none of the leverage required to prevent any of it. Smart engineers recognize that setup fast. Word travels.

The organizations that do this aren’t malicious. Most of them genuinely believe they’ve created clear ownership. They put a name in a doc and called it done. What they actually created is a designated scapegoat with a service catalog entry.

The cost is higher than you think.

Diffuse ownership doesn’t just create operational risk, though it absolutely does that. It degrades the institutional knowledge your organization depends on.

When nobody owns a system, nobody deeply understands it. Documentation becomes aspirational fiction. Runbooks describe what someone intended the system to do, not what it actually does. Incidents take longer, cost more, and teach less, because there’s no through-line of accountability that connects cause to effect to learning.

And the talent impact is brutal. The engineers who want to own things, the ones you most want to retain, will eventually get tired of operating in that vacuum. They’ll go somewhere that lets them. The engineers who remain will have self-selected for comfort with ambiguity and low accountability. That is a culture you cannot easily reverse.

What actually changes this.

This isn’t a process problem. You can’t RACI-chart your way out of a culture that punishes ownership. You have to change what you reward.

Start with how you evaluate performance. If your engineering managers cannot point to explicit, visible credit given to engineers for operational ownership — in promotion cases, in calibration sessions, in public recognition — then you are implicitly telling your team that it doesn’t count. Fix that first.

Next, make ownership legible. A service with a named owner, a clear charter, and explicit authority boundaries is a service people will actually step up to own. Ambiguity is where accountability goes to die. Define the thing. Name the owner. Give them real power over their domain.

Toyota figured this out on the factory floor decades ago. Their Andon system gives any line worker the authority to stop production the moment they identify a problem — not escalate it, not flag it for later, stop it. The entire premise is that the person closest to the issue has both the standing and the backing to act. It works because leadership built a culture where pulling that cord is the right call, not a career risk. We’re supposedly more sophisticated in software, yet we routinely put engineers in positions where they can see the problem clearly, have no authority to stop anything, and get blamed when it blows up anyway.

Back your owners when it’s hard. When someone pulls the cord on a deployment, or pushes back on a timeline because the system genuinely can’t absorb it, support that call publicly. If you quietly override it three times, you’ve taught everyone watching that ownership is theater.

The question worth asking.

The next time you find yourself in that room, the incident is running, the silence is thick, and nobody’s hand goes up, resist the urge to blame your people.

Ask instead what you, and the organization above you, built that made this feel like the right call.

Because I promise you: somewhere, at some point, someone tried to own that thing. And something happened that taught them not to.

Your job is to find out what that was, and fix it.

Good ownership isn’t found. It’s cultivated, or it’s extinguished. Pick one.