Posts 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.

The Pass-Through Problem

Fri, 10 Apr 2026 00:00:00 +0000

Someone asks you a question. You don’t know the answer off the top of your head, so you paste it into Claude, copy the response, and send it back.

That’s not a human interaction. That’s a very slow API call with extra steps.

I keep seeing this pattern, at work, on forums, in social communities, and it makes me wonder if we’ve completely missed the point. Not of AI. Of ourselves.

Here’s what the pattern tells the person on the other end: I could not be bothered to engage with your question. The response might be accurate. It might even be helpful. But it carries a clear signal: you were not worth the effort of actual thought. The sender probably didn’t mean it that way. It doesn’t matter. That’s what arrived.

If I wanted an LLM answer, I would have asked the LLM. I asked you.

The useful version of this technology isn’t a faster copy-paste. It’s a forcing function. The interactions that don’t require a human (the FAQ, the status update, the “what does this acronym mean”) should go away entirely. Build a better doc. Point to a bot. Remove the friction. That’s the job.

What should be left over is the stuff that actually requires a person. Judgment calls. Messy context. The question behind the question. The moments that only work if someone actually gives a shit.

Those interactions deserve more, not less. If AI is buying back any of your time, that’s where it goes. And if you’re one of the people who already gets that — start talking about it. The people around you are probably already losing the thread, and they don’t know it yet.

What’s happening instead is the opposite. The low-effort questions get a low-effort LLM response dressed up as a human answer. The hard questions get the same treatment. And slowly, the expectation of genuine engagement just… lowers.

There’s a word for what this looks like at scale: enshittification. And I don’t think the people doing it are cynical. I believe they’re trying. They picked up - or were forced to use - a powerful tool and pointed it at a real problem. Nobody handed them a manual for which problems it should and shouldn’t touch.

But good intentions don’t change what lands on the other end. The person who asked you something real still got a hollow answer. The gap between meaning well and doing well is exactly where the work is.

The technology isn’t the problem. Mistaking the shortcut for the improvement is. And that mistake doesn’t land evenly. For some people, a hollow answer isn’t an inconvenience - it’s confirmation of something they were already afraid was true. The impact isn’t equally distributed. Neither is the responsibility to fix it.

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.

A Centimeter or Two

Fri, 13 Feb 2026 00:00:00 +0000

The blood on my hands didn’t register as blood at first.

I’d thrown my mask off after the shot. Reflex. Pain management. Give the jaw some air. The pain was sharp and then immediately dull, the kind that makes you think stinger before it makes you think anything else. So I knelt on the ice, head down, eyes on the white below me, and stayed there. A couple of guys skated over. Told them I was fine. Just a stinger. Give me a minute.

I believed that.

I stood up. Reached around to check on things. Brought my hands to my eyes.

They were covered in blood.

This is a shinny game. Eleven at night in Toronto, which is the only time you can get ice when you’re thirty-five and have kids and a job and a long list of reasons why you should probably be in bed. The guy who shot it was younger than the rest of us, wearing red, came in from the blue line on my right side and unloaded a hard wrist shot. I was dropping to make the save. The puck hit my shoulder on the way down, deflected hard, and found the gap between the bottom edge of my mask and the top of my neck guard.

I didn’t know that gap existed.

I’ve thought about that a lot since.

Once the blood started it didn’t stop. Someone handed me a towel. My friend swapped it for a wad of paper towels and I held it to my chin, to my neck, trying to figure out where exactly the problem was. He offered another wad a few minutes later. I replaced it and glanced briefly at the soaked one as it went in the trash.

Then the nausea hit, and someone said we should call 911, and I heard myself say that I was starting to feel light headed, and someone guided me to a bench.

What happened next is the part I’ve been glossing over for two years.

My hands went numb. Then my feet. Then they started to clench, fingers curling inward like something was pulling them closed. I slumped right. The feeling left my face. Then the right side of my body. I remember someone to my left trying to make sure I stayed conscious, talking at me, keeping me present. I remember paramedics removing my pads and skates while I sat there. I remember my vision blurring. I remember the questions getting harder to answer and then, for a while, not a lot else.

I know I got onto a stretcher. I don’t remember getting onto it. I know it was cold outside, Toronto in winter, and I remember the bumps of the path to the ambulance because it had snowed. I remember the lights inside the ambulance and the sound of the sirens and the medics figuring out which hospital could take me fastest. I remember one of them going through my wallet for my health card and either not finding it or deciding I was declining too fast to stop. Both seemed possible at the time.

The ER doctor stitched me up and told me, while her hands were still in my neck, that whatever hit me was a centimeter or two from being fatal. Then she said she was going to call her son when she was done. He was around my age. Played hockey. She wanted to make sure he was ok.

In the moment that was nothing. I was wearing hockey pants and a cartoon mummy wrap of tape and gauze, paying a forty-five dollar ambulance transfer fee, trying to find the cut with a selfie while waiting for a nurse. The cut was gaping — wound edges pulled wide apart, the kind that doesn’t close on its own — and even then it was hard to find in my beard. My brain was somewhere between shock and an unusual species of relief. I got stitched. Got discharged. My in-law picked me up outside a hospital I’d never been to, on a street I didn’t recognize.

The part that landed later, once I’d told the story enough times to hear it out loud, was this: she finished her shift, went home, and called her son. Not because anything happened to him. Because something almost happened to me, a stranger, and she needed to hear his voice. That’s how close it was. Close enough that a doctor who sees bad nights for a living went home and made that call.

The helmet is still in my bag. Still perfectly usable. The puck found a gap the equipment didn’t account for, and the equipment came through fine.

I added a dangler after. A promise to my wife. Safer.

It took me three weeks to get back on the ice and when I did, I was afraid of the right circle. Every time someone loaded up to shoot, my mouth hung open like it was waiting for something to happen. I couldn’t stop it. It took a while for that to go away.

My friend waited up that night. I texted him from the parking lot at 1:30 that I was at my car. He was relieved. I drove to his place and we stood outside in the cold and dark and he told me about what happened after I left. Apparently nobody wanted to shoot on the other goalie for the rest of the game. They cut it short and went home. We stood there laughing about that, me in my skate shoes and stitches, him shaking his head at how quickly I’d gone from fine to gone and then somehow back to standing in his driveway at two in the morning looking more or less like a normal person.

That’s the part that’s genuinely hard to sit with.

I was holding my own neck on that bench. Applying pressure to stop the bleeding. There is a version of that night where I apply too much pressure, stop the blood to my own brain, and become a hockey fatality. A freak accident statistic at an eleven o’clock shinny game. A number in a report somewhere. The young guy in red spends years carrying a shot he didn’t do anything wrong on. My wife gets a phone call instead of a sleepy conversation in the dark.

That version isn’t hypothetical. It was the same night, the same bench, the same hands.

I don’t live with pain from this. No lasting damage, no real reminder except a scar that hides in my beard. I got out clean and drove myself home at two in the morning like it was nothing. Then I walked in the door and woke up my wife.

She wanted to know I was ok. Then she wanted to know why I forgot to wear the right equipment, why I’d taken the car and left her stranded, how we were going to make sure this never happened again. All fair questions. The last one doesn’t really have an answer. When she’d run out of things to be furious about, she told me to wash up and come to bed. She’d look at the stitches in the morning.

I’ve told the gory part of this story plenty. Got cut playing hockey, here’s the bloody equipment. I’ve told it like it’s a war story, something to pull out for shock value.

That’s not what it is.

I was the lucky one. The gap was there the whole time. I just didn’t know it until the puck found it.

Some Nights You Just Show Up

Sun, 18 Jan 2026 00:00:00 +0000

Easy save. I could smother it, kill the play. Instead I kick it out to their other forward.

Not a mistake. A choice. I’m bored and my team’s up four goals and I want to make another save. So I manufacture chaos, create my own work, turn an easy night into something that feels like hockey.

That’s the first thirty-six minutes.

The second half, I’m making four saves in a row and watching the fifth one trickle past my pad anyway. My defense is skating like they’re underwater. Passes are dying on sticks. I’m doing everything right and we’re getting shelled.

Here’s the thing about being on-call: some weeks, everything you touch works. You’re rolling back that bad deploy before anyone notices. You’re catching the disk space issue at 87% instead of 99%. You’re so dialed in you start getting cocky, maybe let a minor alert sit an extra minute just to see if it self-heals, because you know you can fix it anyway.

Other weeks, you’re making all the right calls and it doesn’t matter. The primary fails over cleanly and the secondary’s already degraded. You catch the memory leak but the restart triggers a cascade. You did the runbook perfectly and the system finds a new way to fail anyway.

Both are the job.

The dangerous part is thinking the first kind of week means you’re great at this, or the second kind means you’re not. Some nights the puck just goes in. Some nights your coverage is perfect and it still finds the gap. The only consistent thing is that you have to show up.

You can’t manufacture chaos in production the way I do on ice - that’s how you end up in a post-mortem explaining why you thought it would be “fun” to test failover during peak traffic. But you also can’t let the brutal weeks convince you that you’re not doing it right.

The shinny game is rec league hockey at eleven PM with a bunch of tired old men. Nobody’s keeping score except me. The second half, we lost 8-2.

In production, someone’s always keeping score. But the principle holds: some nights you just show up, make the saves you can make, and skate off when it’s done.

The job is to show up anyway.

The Lie That Taught Me About Blameless Culture

Fri, 09 Jan 2026 00:00:00 +0000

I was standing outside a conference room watching my team lie to another team about a database outage. It was day four.

Through the glass door, I could see the engineer on the call, explaining with impressive confidence that our cloud provider was having issues. Any minute now, they said, the vendor would resolve it and services would come back up.

I pulled up the provider’s status page. Green across the board. Checked their Twitter. Nothing. I caught the eye of the engineer leading the response and motioned them outside.

“What actually happened?”

The way they looked at the floor told me everything. Then: “Accidental deletion. We’re working on recovery.”

Here’s the thing about inheriting a team: You don’t just inherit their code and their systems. You inherit their patterns. Their fears. The lessons they learned from whoever led them before you.

My team had learned that mistakes meant consequences. That admitting fault meant exposure. That the safest play was to redirect blame to something faceless—a cloud provider, a vendor, a system “acting weird.” They’d learned this so well that lying to the team we supported felt safer than telling their new boss the truth.

I had about thirty seconds to decide what kind of leader I was going to be.

The Conversation

We found an empty office.

“I’m not mad about the database,” I said. “I’m concerned you felt you couldn’t tell me.”

They stared at their hands.

“I need you to understand something. I’m four days into this role. I don’t know your systems. I don’t know the history here. But I know this: I can’t help you fix problems I don’t know about. And the other team can’t tell us how severe this actually is if we’re feeding them fiction.”

“Previous leadership didn’t react well to mistakes.”

There it was. The inherited culture, delivered in one sentence.

“Okay. Here’s the new standard: You tell me the truth, always. I’ll handle the hard conversations. You focus on the fix. Deal?”

They looked up. “Deal.”

Falling on the Sword

I walked back into that conference room.

“I need to correct something,” I said. “This isn’t a cloud outage. One of our engineers accidentally deleted the pre-production database. We’re working on recovery now, but I need your help: How critical is this to your operations? What’s the actual impact?”

The silence lasted maybe three seconds. Felt like an hour.

Then: “Thank you for being straight with us. Here’s what we need…”

They walked us through their priorities. Which services mattered most. What data they could recreate versus what needed restoration. The conversation became a collaboration instead of a performance.

We got the database back. It took six hours and some creative recovery work, but we got it back.

The Post-Mortem

The next day, I gathered the team in the conference room for our first post-mortem. I’d never run one with them before, so I started by explaining how we were going to do them from now on.

“When we name people in post-mortems,” I said, “it’s only for successes. Who responded quickly. Who had the knowledge to guide recovery. Who communicated clearly under pressure.”

I looked at the engineer who’d led the recovery effort. “You did excellent work getting us back online.”

“For failures, the buck stops with me. I’m the lead. Anything that goes wrong happened on my watch. My job is to figure out what systemic failures allowed this to happen and fix them.”

I watched the team process this. Some looked skeptical. Some looked relieved. All of them looked like they were waiting for the other shoe to drop.

“Here’s what we’re changing. Permissions on production-like environments. Backup verification procedures. Documentation on recovery processes. And most importantly: the expectation that you can always tell me the truth, especially when things break.”

The Timing

Looking back, week one was actually the perfect time for this to happen.

I had no history with this team. No pattern of reactions for them to predict. No baggage about “how we’ve always done things.” When I said “this is the new standard,” there was no previous version of me to contradict it.

Being new meant I had nothing to lose and everything to prove. I couldn’t lean on established trust or authority. I had to show them, in real time, what kind of leader I was going to be.

Culture isn’t built during the smooth times. It’s built in how you respond when things break. And things always break.

What Stuck

That engineer never lied to me again. Neither did anyone else on the team. Not because I’d scared them straight, but because I’d shown them the alternative: honesty gets you help, not punishment.

The other team? They became one of our strongest advocates. Years later, they still reference that incident as the moment they knew they could trust us.

The post-mortem approach stuck too. Name people for successes, take responsibility for failures. It sounds simple, but it changes everything about how teams respond to pressure.

I couldn’t change what my team had learned before I arrived. I couldn’t undo whatever had taught them that self-preservation trumped transparency. But I could show them a different future, starting with one deleted database and one honest conversation.

The bad news: People will test your principles during crisis. The good news: Crisis is when principles matter most.

The job is to be ready anyway.

Everything I learned about Ops, I learned playing goal

Thu, 06 Nov 2025 00:00:00 +0000

Well, maybe not everything.

Look, being a goalie is objectively ridiculous. You strap on forty pounds of equipment designed to protect you from frozen rubber traveling at speeds that would make physicists frown. Then you stand in front of a net and dare people to shoot at you. It’s a strange job.

But here’s the thing: being a goalie is basically the same job as running ops, or security, or honestly, any part of software development where you’re the one who has to keep the thing from breaking.

Both jobs share the same core truth that nobody tells you in the job description: when everything’s working, no one notices you’re there. But the second something gets past you? Everyone knows exactly where you were and what you should have done differently.

You spend most of your time reading patterns, anticipating problems before they fully materialize, and communicating with people who may or may not be listening. You’re simultaneously trying to follow the systems that keep you consistent while also staying loose enough to react when something weird happens. Because something weird always happens.

And whether it’s a breakaway in overtime or a production incident at 2 AM, you learn pretty quickly that freezing up isn’t an option. You make the save or you don’t. You stop the breach or you don’t. Then you’ve got about eight seconds to shake it off and get ready for the next shot, because there’s always a next shot.

The bad news? You can’t stop everything. The good news? Neither can anyone else. The job is to be ready anyway.

Decoupling Deployment from Release: An Architectural Imperative

Tue, 30 Sep 2025 00:00:00 +0000

Photo by Patrick Konior on Unsplash

We need to talk about how we ship software. Not because we’re doing it wrong, but because we can do it so much better, for our customers, for our colleagues, and for ourselves.

The Core Problem: Deployment Isn’t Release

Here’s the shift we need to make: deploying code and releasing features are not the same thing, and they shouldn’t happen at the same moment.

When we conflate deployment with release, we create unnecessary risk and friction. We deploy code to production, and suddenly a feature is live, ready or not. If something goes wrong, we scramble. We hotfix. We roll back entire deployments, potentially affecting unrelated changes. We make our product and support teams reactive instead of strategic.

There is a better way.

Why This Matters: Safety First

Our customers trust us with their business. Our colleagues across product, support, and operations depend on stable, predictable releases. When we tie deployment directly to feature availability, we put both at risk.

Safe software releases mean:

Our customers experience fewer disruptions
Our support team can prepare for changes before they go live
Our product team can control the narrative and timing of new features
Our engineers can deploy confidently, knowing they have safety nets in place
We can see the impact of our changes

This isn’t about adding bureaucracy. It’s about adding control.

The Mindset Shift for Engineers

I know what some of you are thinking: “This sounds like more process. More overhead. More barriers between my code and production.”

Let me reframe it: What if deployment was easier because it was safer? What if you could push code to production multiple times a day without the anxiety of “did we just break something for customers?”

This requires us to think differently:

Code goes to production dark, deployed but not activated
Features are controlled by flags, not by deployment timing
Your code can live in production for days or weeks before anyone uses it
When issues arise, you flip a switch instead of rolling back a deployment

This is actually more engineering control, not less. You own the technical deployment. Product and support teams own the feature release timing. Everyone wins.

Empowering Product and Support

Our product managers understand customer needs, market timing, and strategic rollout. Our support team knows when they’re ready to handle inquiries about new features. Our documentation should be created in production.

When we give them control over feature flags, we put release decisions in the hands of the people best positioned to make them. Engineering provides the capability; product and support control the activation.

This isn’t about taking power away from engineering, it’s about giving everyone the right kind of power.

Stop Removing What People Still Use

We’ve all been there: a feature is marked for deprecation, so we rip it out. Then we discover customers were still using it, or they needed more transition time.

With feature flags and dual code paths, we can:

Run old and new implementations side by side
Give customers time to migrate naturally
Gather actual usage data before removal
Roll back feature changes without rolling back deployments

We keep both paths alive until we know the old one isn’t needed. Data drives decisions, not assumptions.

Creating Dual Code Paths

The technical pattern is straightforward:

if (featureFlag.isEnabled('new-checkout-flow')) {
  // New implementation
  return enhancedCheckout();
} else {
  // Current implementation
  return traditionalCheckout();
}

This enables:

Rapid feature releases, toggle a flag, feature goes live
Instant rollbacks, toggle it back if issues arise
Gradual rollouts, enable for 10% of users, then 50%, then 100%
A/B testing, compare new vs. old with real data
Safe deprecation, maintain the old path until usage drops to zero

Yes, you maintain two paths temporarily. But the flexibility and safety are worth it.

We Already Test in Production, Let’s Do It Right

Here’s an uncomfortable truth: we all test in production. Even with the best staging environments, production has data patterns, load characteristics, and edge cases we can’t fully replicate.

Feature flags let us test in production safely:

Enable new features for internal users first
Roll out to beta customers who opt in
Gradually expand to broader audiences
Monitor in real time and react instantly

Instead of pretending we don’t test in production, let’s acknowledge it and build systems that make it safe and controlled.

Making Monitoring and Observability Easier

When features are flag-controlled, monitoring becomes clearer:

Dashboard metrics tagged by feature flag status
Alerts that distinguish between feature issues and infrastructure issues
A/B comparison of performance between flag states
Clear correlation between flag changes and system behaviour

You’ll spend less time debugging “what changed?” because you’ll know exactly what changed and when.

This Is About Your Value

Every engineer brings immense value. You solve complex problems. You build systems that serve customers. You keep the platform running.

This approach amplifies your impact:

Deploy more frequently without stress
Spend less time on hotfixes and emergency rollbacks
Focus on building new capabilities instead of managing release logistics
See your features succeed because they’re released at the right time, to the right users

Your technical expertise deserves better tools. Feature-flagged releases are those better tools.

Getting Started

We don’t need to transform everything overnight. Here’s how we can begin:

Start with your next major feature, wrap it in a feature flag
Integrate flags into your monitoring, make flag status visible in dashboards
Coordinate with product and support, let them control release timing
Gather data before deprecation, keep old code paths until usage proves they’re unnecessary
Share what works, as teams succeed with this approach, spread the practices

This is a journey, not a destination. Each team can adopt at their own pace.

The Bottom Line

Separating deployment from release isn’t just a technical practice, it is a philosophy of safety, control, and collaboration. It acknowledges that great software delivery involves engineering excellence and thoughtful release management.

We have the talent. We have the technical capability. Now let’s build the practices that let us ship with confidence.

Let’s deploy fearlessly and release deliberately. Our customers, our colleagues, and our code deserve nothing less.

ZFS Raid Types

Mon, 21 Apr 2025 00:00:00 +0000

If I didn’t have to spend a bunch of time moving virtual machines around, this probably wouldn’t matter very much. But, alas, I did find myself building zfs raid arrays a few times and couldn’t seem to remember what I wanted where.

🧂 Take with a conservative grain of salt.

RAID Type	Min Disks	Usable Capacity	Fault Tolerance	Performance Notes	Notes
Striped	1+	100% of total	None	Fastest read/write, no redundancy	Equivalent to RAID0
Mirror	2+	50% of total	1 disk per mirror vdev	Excellent read, good write, fast recovery	Equivalent to RAID1 in traditional RAID
RAIDZ1	3+	N - 1	1 disk failure	Slower write, decent read	Similar to RAID5
RAIDZ2	4+	N - 2	2 disk failures	Slower write, decent read	Similar to RAID6
RAIDZ3	5+	N - 3	3 disk failures	Slowest write, decent read	For high fault tolerance
ZFS RAID10	4+ (even)	50% of total	1 disk per mirror vdev	Best balance of performance + redundancy	Stripe of mirrors (manual mirror vdevs)
dRAID	3+	Varies (RAIDZ-like)	Parity-based (configurable)	Improved resilver vs. RAIDZ, good balance	Requires newer ZFS versions
Special VDEV	1+	Not for main storage	Depends on layout	High IOPS for metadata/small files	Used for performance, not redundancy

N = Number of disks in the vdev

New Team, New Processes

Mon, 31 Mar 2025 00:00:00 +0000

Starting fresh with a new team—whether it’s stepping into the net as a goalie or joining a company as a Site Reliability Engineer—comes with a rush of excitement, uncertainty, and the need to quickly adapt. In both worlds, you’re expected to understand the system, earn trust fast, and make the right decisions under pressure. This piece explores the parallels between guarding the crease in ice hockey and taking on infrastructure responsibilities in a new engineering org: the importance of communication, learning team dynamics, managing risk, and building confidence through early wins.

When you join a new hockey team as a goalie, you don’t just protect the net—you learn how the defensemen play, how aggressive the forwards are, and when the team tends to collapse or stretch the ice. Every team has its own rhythm and unspoken rules. The same is true when joining a new company as an SRE. The architecture is only part of the story; the real learning curve is understanding how incidents are handled, who actually makes the calls in a crunch, and which “informal” channels carry the most context. Just like a goalie can’t force their style on a team that plays differently, a new SRE needs to observe, adapt, and gradually find ways to complement and strengthen the existing flow. It’s less about proving you’re technically sound (that’s assumed) and more about showing that you can read the play and make the team better as a result.

In both hockey and SRE work, the moment things go sideways is when communication really counts. As a goalie, you see the whole ice—you’re the only one facing the play—and you need to call out shifts, loose players, or breakdowns in real time. If you hesitate, the puck’s in the net. As an SRE, it’s similar during an incident: you often have a high-level view of what’s happening across systems, and the ability to stay calm and clearly relay what you’re seeing can make the difference between a contained issue and a full-blown outage. But communication isn’t just about shouting the loudest—it’s about knowing when to speak, who needs to hear what, and doing it in a way that builds confidence rather than panic. Like a goalie steadying the team during a penalty kill, an SRE who brings calm clarity in high-stakes moments becomes an anchor for everyone else to rally around.

So, how do you build trust in a new team?

Trust isn’t earned by pretending to be perfect—it’s built by showing up consistently, being accountable, and owning your impact, good or bad. As a goalie, you’re going to let in goals. Some are unstoppable, some are a result of defensive breakdowns, and some are just flat-out on you. What matters is how you handle it. Do you sulk? Blame? Or do you skate over, tap a teammate’s shin pads, and reset for the next faceoff? The same dynamic plays out in SRE. Early on, you’ll miss signals, ship a bad change, or overlook something you should have caught. Heck, there are days where you’ll break production. But by being transparent, acknowledging the miss, and showing what you’re doing to improve, you demonstrate humility and build credibility. Teams trust people who are honest about their fallibility and show a pattern of learning. Whether it’s a soft goal from the point or a mistuned alert that paged the team at 3 a.m., owning it builds more goodwill than perfection ever could. That openness also invites others to bring their guard down, leading to better collaboration and stronger long-term bonds.

As both a goalie and a leader, you quickly learn that most mistakes aren’t rooted in malice or incompetence—they’re byproducts of unclear systems, missing context, or just the fast pace of the game. When someone misses an assignment on the ice or forgets to update a runbook, it’s rarely because they don’t care—it’s usually because the process failed them. As an SRE leader, it’s your job to zoom out after the fact and ask not just who made the mistake, but why it made sense in that moment—and how the system can be improved so the next person has a better shot. Maybe the alert was noisy, the handoff lacked key context, or a dependency wasn’t clearly documented. Whatever it is, you shift the focus from blame to learning. Like a goalie giving quiet guidance during a timeout, your job is to reset the team without undercutting their confidence. Owning your own mistakes gives you the credibility to address others with empathy—and turning those moments into durable process improvements is how teams get stronger over time.

Whether you’re stepping onto the ice or into a new engineering org, the fundamentals are the same: learn the team, communicate clearly under pressure, take ownership, and lead with empathy. Both roles are high-trust, high-impact, and deeply human. You’re not just reacting—you’re anticipating, supporting, and constantly adjusting to help the people around you succeed. The best teams don’t expect perfection—they expect presence, accountability, and a shared commitment to get better together. In the end, it’s not about never letting a goal in or preventing every outage. It’s about being the kind of teammate who learns fast, shows up when it matters, and helps turn every setback into forward motion.

Goalie as a Service

Wed, 19 Mar 2025 00:00:00 +0000

I remember the moment vividly—a hard shot struck the lower side of my mask. The impact was sharp, a bolt of pain radiating through my face. I dropped my head to the ice, letting the sting settle before pushing myself up onto my knees. It wasn’t until I stretched my neck, looking around, that the blood started flowing. When I glanced down, the realization hit—red pooling rapidly beneath me. Instinct took over. I stripped off my blocker, glove, and helmet, heading straight for the dressing room. Players were already scrambling for medical supplies as I pressed a hand to my face, trying to assess the damage and scrambling to find the source of the blood.

In that moment, I wasn’t thinking about the pain. I was thinking about getting back on my feet, assessing the damage, and figuring out my next move—just like in an on-call incident.

Being an amateur hockey goalie mirrors the world of DevOps and Site Reliability Engineering (SRE) in ways that only those who’ve been through the chaos can truly appreciate. Both demand the ability to anticipate disasters, react with composure under pressure, and recover quickly when everything goes sideways. A goalie can’t afford to dwell on the last goal any more than an SRE can get stuck in post-mortem blame. The job is about resilience, adaptability, and learning from every incident—whether it’s a slapshot to the mask or a production outage at peak traffic.