Daniel showed it to us on a Wednesday or a Thursday, the kind of day that has no character of its own, and within ten minutes I had the kind of look on my face that you generally only see when receiving an online purchase or a negroni at the end of a long day. The tool - and it was barely a tool at that point, more like a sermon delivered in the voice of a parole-board chatbot - could take a Slack channel full of incident chatter, a half-filled-out template, and a few prompt instructions, and produce something that looked, at squinting distance, like a post-incident review.

It was 2023. Large language models had been a public concern for less than a year, and inside the kind of company that ran on Jira and SOC 2 controls they were still treated as something between a curiosity and a compliance problem. Most enterprises had not yet decided whether they were tools or trinkets. The doom-or-salvation discourse existed elsewhere - on Twitter, in McKinsey reports, in the speeches Sam Altman was giving to anyone with a podium - but it had not yet reached the rooms where things actually got built. Inside our team, we had just spent another quarter watching engineers grind through the post-incident review process like someone chewing through a wall with their teeth. Daniel was an SRE. He had been quietly experimenting with what would later be called prompt engineering and was at that point still called typing stuff into ChatGPT until it stopped being stupid. He brought us a working prompt, untouched by legal, with no production access, no governance, and no expectation that it would amount to anything beyond a parlour trick.

Reader, it amounted to something.

I want to be precise about what we saw, because the optimism of that exchange is the entire reason the rest of this essay exists, and I am wary of telling you the story in a way that lets either us or the institution off the hook later. What we saw was a tool that could do, in maybe forty-five seconds, the part of a PIR that engineers found most miserable: the narrative reconstruction. The what-happened-in-order-with-timestamps-and-human-verbs. The part where you have to go back through Slack and translate “lol we restarted the pod” into at 14:07 UTC the on-call engineer initiated a pod restart in the affected service. That part. The boring part. The part nobody wanted to do.

And the demo did it. Not well, not at the level we would come to consider acceptable a year later, but well enough that you could see the shape of a future in which engineers were freed from the worst portion of an already unloved chore. Which, if you have ever been an engineer asked to write a PIR for an incident you do not really remember in the middle of a sprint you are already losing, you understand to be roughly the same scale of liberation as the invention of the dishwasher.

We took it to engineering leadership the following week. They blessed it without much theatre, which should have been a clue, and we joined the legal and privacy queue.

The legal and privacy queue is its own genre of waiting. You file the paperwork, you describe the use case, you propose a control surface, you receive twenty-three follow-up questions written by someone who has never used the product and has no plans to, and then you wait. You wait through a quarter-end. You wait through a reorg. You wait through the kind of compliance review that arrives via a ticket update from a person you have never met, to whom you are asked to explain, in non-technical terms, what a token is.

We were lucky in that our use case was relatively clean. We were not feeding the model customer data; we were feeding it internal incident chatter, which existed in a different and slightly more forgiving compliance category. We were not asking the model to make decisions; we were asking it to re-narrate, which is a thing computers had been doing in some form for decades, under names that were less marketable. So the queue was not as long as it could have been. It was, however, long enough.

So we waited. And while we waited, we built.

The prompt grew. What started as Daniel’s half-page proof-of-concept had turned into a multi-section instrument with explicit guidance for each part of the PIR template - summary, timeline, impact, root cause, contributing factors, action items. We learned the way you learn everything in prompt engineering: by watching the model fail and adjusting. The model wanted to proclaim customer names; we told it not to proclaim customer names. The model wanted to attribute blame; we told it not to attribute blame. The model wanted to use the word streamline in every other sentence; we told it the word streamline was now retired.

The thing we got right - the thing I want to underline now, before I tell you what we got wrong - was that we never asked the model to know anything. We asked it to re-arrange. The Slack logs went in. The template structure went in. The model’s job was to take a pile of inputs and produce something shaped like a PIR. Hallucination is a function of how much the model has to invent; we left it almost nothing to invent. The principle of this exercise, in case you are building one of these and would like to skip a class of failure: the model’s job is to synthesise the material you give it, not to source the material itself. If you find yourself asking the model to know things, you are asking it to lie eventually, and it will oblige.

Legal blessed it. We rolled it out. The first PIRs landed in review. The reviewers found them surprising - not because they were good, exactly, but because they existed at all, in roughly the right shape, having taken the human author perhaps twenty per cent of the time the human author would normally have spent. We had successfully automated forty-five minutes out of an unloved chore. The dishwasher metaphor from the demo, it turned out, had been roughly correct.

For a few months we felt like we had built something. I will not pretend the feeling lasted.

The first thing we noticed was the waffle. The prompt asked for concise output. The prompt asked for concise output repeatedly, in increasingly direct language, with examples of what concise looked like. The model agreed. The model agreed enthusiastically. The model then wrote summaries that took five sentences to do the work of one, in a register that one of our engineers eventually described as verbal diarrhea. It talked around itself. It explained things by length rather than brevity. The hallucination problem had been solved. The talking-too-much problem had been not just unsolved but, in some quiet way none of us yet understood, actively introduced by our own instructions.

We made a list of fixes. We did not, immediately, get to make them.

Immediately turned out to be a longer word than we’d planned.

The list of fixes went into a Jira ticket. The Jira ticket went into a backlog. The backlog went into a quarterly planning session, where it competed against twenty other things, most of which involved heads of engineering going ‘hmm’ in a concerned manner, and lost. The quarterly planning session was followed by another quarterly planning session, in which the backlog was reviewed again, and the list was, by general consensus and without any specific person being responsible, deprioritised. Nobody was opposed to fixing it. Nobody was opposed to almost anything. There was simply more shouting elsewhere.

This is a thing that happens to tools that kind of work. It is, in fact, the most reliable thing that happens to tools that kind of work. The fully-broken get fixed because the breakage is intolerable. The fully-functional get celebrated because the functioning is visible. The mediocre live forever, because the cost of revisiting them is greater than the cost of putting up with them, and because nobody who could authorise the revisit ever has to read the output themselves.

We were not idle in those months. There was always another incident, always another process to revise. We launched other things. We retired others. The team grew, shrunk, grew again. We upgraded the underlying model when GPT-4o came out, because that was the kind of small win you could ship in an afternoon; we did not revisit the prompt, because that would have required time we did not have. The PIR machine kept running quietly in the background, getting copy-pasted into reviews, getting approved, getting closed. We told ourselves we would get back to it. We did not.

Here is a principle I wish I had understood eighteen months earlier than I did: prompt engineering is craft, and craft requires maintenance windows scheduled into the calendar by people who are willing to defend them. You can ship a prompt. You can be proud of the prompt. The prompt will get worse without your noticing, not because the model is changing - though the model is also changing - but because the world the prompt is describing is changing, and the prompt is not. A prompt is a snapshot of your understanding at the moment you wrote it. Without scheduled revision, it ages the way photographs age: slowly, then all at once.

Eighteen months is a long time in software. Eighteen months is also, it turns out, exactly the length of time required for a tool that kind of works to become a tool that people are quietly furious about, without anybody being quite ready to say so. The fury was there. The fury was building. It was just waiting for someone to write it down.

The person who finally wrote it down was an engineer. I will not name them. They were having a bad PIR.

Specifically, they were having a bad PIR inside a piece of internal tooling we had built on top of Jira DC, which had been cobbled together in the way that internal tooling generally is at companies large enough to have opinions about internal tooling and small enough to defer the building of it until later. The tool worked. The tool worked the way most internal tooling works, which is to say: it worked if you held it correctly. If you did not hold it correctly - if, for instance, you attempted to save an incomplete set of information and the tool decided something was missing - the tool would, in a moment of administrative malice that nobody had specifically designed but nobody had specifically prevented, wipe everything you had entered. Not save it incorrectly. Not warn you. Wipe it.

This engineer had had this happen to them. More than once, I believe. They had then gone to the AI-generated draft to complete that, and the AI-generated draft had given them the kind of meandering, schoolboy-essay output we had been ignoring for eighteen months because, as previously established, nobody who could authorise the revisit ever had to read the output themselves.

The engineer took to Confluence.

The post compared our team - meaning specifically the team I was on, the team responsible for the PIR machine and the tooling around it - to Satan and to Hitler. The post was specific. The post named the data-wipe, the AI waffle, the time it had cost. The post did not propose solutions. The post was furious in the way that internal Confluence posts are furious, which is to say: with no structural restraint and the potential charge of physical assault on a keyboard.

It was, in many ways, the best thing that happened to the project.

Within a week, we had the authorisation we had been asking for in measured tones for eighteen months. The reason was simple, and it is the principle this section is here to land: organisations fund repair, not maintenance. Maintenance is invisible until it stops, at which point it is not maintenance, it is repair. The fury was the budget. The blog was the business case. The engineer who wrote it had, without intending to, performed the single most useful act of project sponsorship the project had ever received.

We did not thank them. I sometimes wonder if we should have.

The list of fixes came out of the drawer. Some of the fixes had aged better than others - the world had moved on, the models had moved on, the assumptions had moved on. Some of them needed to be thrown out entirely. We were not going to be patching v1. We were going to be building v2. Better. Cleaner. As it should have been, quarters ago.

The person who wanted us to use a different model worked in the AI team, which is a thing companies of a certain size have. I do not begrudge the AI team. Their job is to be the responsible adult in the room while a hundred product teams attempt to do something irreversible with someone else’s compute budget. I have been the responsible adult in rooms before, and I know what it does to a person. The cheaper model on offer was a flash model, and the fans of the flash model in this case had a spreadsheet, and on the spreadsheet there were two columns, and one of the columns was cheaper than the other. The fans of the flash model in this case had not read the prompt. The fans of the flash model in this case had not read any output the prompt had produced.

So we made the case. We made it politely, in writing, with examples; and then we made it again, less politely, in person, with more examples; and then we made it a third time, in language flat enough to survive translation through three layers of management. We compared outputs. We compared the quality of the comparisons, which is a meta-step you should always include, because the cheap-model fans will otherwise quietly judge the comparison on cost rather than on whether the comparison was fair. This took weeks. It felt like longer.

The principle that buys you back the weeks, if you have to make this case yourself: the right model for the job is not always the cheapest, and the people gatekeeping cost are not always the people who will read the output. Cost gating is a perfectly reasonable function of a perfectly reasonable team that, in the absence of skin in the game, will optimise for the metric they actually have. Your job, if you are the team who has to live with the output, is to make sure your metric is visible too.

We got Claude. The model was, on every measure we cared about, better. Claude wrote sentences a human would have written. Claude knew when to stop a sentence. Claude understood, in a way that earlier models had not quite understood, that the absence of a word was sometimes the right call. The waffle disappeared.

Around the new model, we rebuilt the prompt. The monolith became a series of sections, one per PIR component, each with its own tone guidance and its own source-grounding rules. Each section returned its output with citations to the Slack timestamps that had produced it, so the author could check the work in seconds rather than minutes. We were aware, painfully so, that the timelines for some incidents - the incidents where the team had been on a Zoom call rather than typing - were thin. Things had happened. Things had been resolved. The middle was missing.

So we added Zoom transcription via Loom. This is the part of the story where I have to tell you about one of our developers, who I will call Wilson, because we need a name and Wilson is not theirs. Wilson, in a moment of operational efficiency that we should have anticipated and did not, decided that the simplest way to ensure every incident Zoom call had a transcript was to put their own Zoom account into every incident bridge. Wilson’s account would join the call silently, record it, transcribe it, and deliver the transcript to the prompt. Wilson’s account joined a number of calls before anybody noticed.

When people noticed, the response was not measured. The response was: who is recording us, why, and what will be done with the recordings. The response was immediate, unanimous, and slightly biblical. We had built, without intending to, a small in-house panopticon, and the workforce was responding the way workforces respond when they find one in their meetings. We did the work of explaining, in clinical detail, what was recorded and what was not, where the transcripts lived and who could read them, how long they were retained and how they were destroyed. We did this because we had to.

The last change we made, and the change that mattered most, was the framing. The v1 prompt had produced output that read like a PIR. The v2 prompt produced output that read like a draft of a PIR. The difference is not subtle. The v1 output had headers and bullets and a structure that invited the reviewer to read it as finished. The v2 output had headers and bullets and a banner at the top, in language we had spent the better part of a fortnight getting right, that explained: this is a guide for the author to work from. It is not the PIR. The PIR is the document the author is responsible for writing, with this as a starting point. We had not changed what the model produced. We had changed what we called it.

The reframing helped. It did not help as much as we had hoped. There is a thing humans do when given a document that is almost what they need, which I have been trying to find a polite name for.

The polite name I have been trying to find, and the one I will settle for in the absence of better, is convenience. Humans, when given a document that is almost what they need, will treat it as if it were exactly what they need. Humans will do this even when the document is labelled in friendly capital letters DRAFT NOT FINAL. Humans will do this even when the document is preceded by a banner that the team writing the document spent two weeks getting right. Humans, in the end, do not read banners. They read the document.

The links had been thick and fast in my DMs long before v2 emerged - long before we had a name for the dynamic they evidenced, long before we had built anything to address it. Engineers I had not spoken to in months would forward me a link with the kind of brief, exhausted message that engineers send when they have run out of patience but have not yet run out of decorum: thought you’d want to see this. The thing I would ‘want’ to see, in every case, was an approved PIR that had been written by the model and submitted by a human who had not, by any reasonable interpretation of the word, written it. The PIRs were good enough to pass review. They were not good enough to be useful. They had been used anyway.

The reviewers, meanwhile, had developed a parallel adaptation. The reviewer’s job is to read the submitted PIR and decide whether it is adequate. The reviewer’s job, in practice, is to clear PIRs from the queue before the SLO expires, because the queue grows faster than the reviewer’s available reading time. The reviewer who is behind on the queue will scan, not read. PIRs written by the model scan beautifully - they were designed to. More often, and worse, they will not even scan and simply tick.

The author and the reviewer had, between them, found a workflow in which neither party was doing the human work the PIR was supposed to capture.

We built two things, and we built them quickly, because the longer this dynamic ran the more institutional memory we were quietly losing about every incident the system had processed.

The first was a copy-check. The submission flow ran a text similarity comparison between the AI-generated draft and the submitted PIR. If the similarity was too high - if the human had, in essence, copied the model’s output and called it their work - the submission was flagged, and a polite note explained that the PIR appeared to have been submitted without modification, and would the author like to take another pass. The note was polite. The note was also firm. The note had the effect of making the next twenty minutes of the author’s day moderately worse than the previous twenty had been, which was the point.

The second was a scoring system. We took every PIR from the previous two years that had been written for a sev one incident - the most-scrutinised, most-rewritten, most-stakeholder-edited PIRs we had - and we distilled them into a rubric. What did the strong ones do that the weak ones did not? What sections were always present, always specific, always actionable? What kinds of sentences did the gold-standard PIRs avoid? The rubric became an automated audit. Every submitted PIR would be scored against it. The score was visible to the author. The score was visible to the reviewer. The score did not block submission; it simply existed, on the page, in numbers, in places where numbers had not been before.

The rubric did two things. For the author, it provided immediate feedback on where the PIR was thin - your timeline lacks specificity, your contributing factors are not distinguished from your root cause, your action items have no owners - at the moment they could still fix it. For the reviewer, it provided immediate triage on where to focus their attention - this PIR scores well on timeline, poorly on action items, you can probably skip ahead and concentrate on the second half. The first audience used the rubric to write better. The second audience used the rubric to read more efficiently. Both, crucially, were doing more of the human work and less of the rubber-stamping.

Here is the principle, and I want to be careful with it because it is the one that mattered most and the one I most wish I had understood at the start: the predictable failure mode of automation is that humans will use the automation to skip the work the automation is supposed to assist with, not replace. If your tool makes a job faster, your tool will be used to skip the job. If your tool makes a job easier, the job will be skipped. If your tool produces an output that is almost the deliverable, the output will become the deliverable. This is not a failure of the humans. This is not a failure of the tool. This is the predictable interaction between a labour-saving device and a labouring human, and you need to design against it from day one. Not on day three hundred and sixty, after the fury has built and the engineer has taken to Confluence.

The copy-check has hopefully shipped, as has the rubric. The PIR quality, by every measure we had, will begin to recover. We had built, finally, a tool that knew how to coexist with the humans using it. We had built it after eighteen months of drift, one furious Confluence post, a flash-model fight, an accidental panopticon, and a framing rewrite that had nearly worked.

Reader, I'll never know for certain. I was made redundant three weeks later.

Subscribe now

What follows is not a framework. There is no certification at the end of it. These are the rules I wish someone had handed me in the first week of running major incidents - rules I have since watched colleagues learn one by one, at the cost of one Robert at a time. They look like manners. They are not.

On bridges and the people who join them

• If you are an IC and you do not control the bridge, the bridge controls you. Set the cadence, name the speakers, call the stand-downs. Otherwise the loudest voice runs the response, and the loudest voice is rarely the right one.

• The executive who joins the bridge to “help” is not helping. The executive who joins the bridge to “observe” is not observing. There is no observer mode. Every additional person on a bridge costs the IC roughly 8% of her remaining cognitive function, and she has already spent the other 92% on you.

• The head of engineering who is irritating everyone by ensuring things are truly fixed and every base is covered is doing the work nobody else will. It is not pleasant. It is thorough.

• If you join the bridge, say your name and your function within ten seconds. The IC is not a clairvoyant. She is tracking six responders, a Splunk dashboard, and a Senior Director who keeps unmuting to ask “where are we at.”

• Scribe as you go. The first ten minutes of an incident are seven different teams logging on and asking the same three questions. If the answers are not already in the channel, you will be repeating them yourself, in real time, while also running the response.

• Do not engage an individual directly. Always use the on-call roster, lest you disturb Robert for the seventh time that will likely result in his departure from the company three weeks later.

• PR and Legal get a bridge of their own. They serve a real purpose, and that purpose is not asking the engineers what they were thinking at 2:14am while they are still thinking it. Once the technical bridge becomes a discussion of who knew what and when, it is no longer a war room. It is a deposition.

• The senior engineer who knows the answer but doesn’t speak up because he’s “not on this rotation” is not being humble. He is being expensive. Speak up or log off.

• Never assume during an incident. There is no such thing as a stupid question. There are only stupid assumptions, made by people who did not ask one.

• Fifteen minutes. If a paged engineer hasn’t responded in fifteen, escalate. The clock is not a moral instrument; every engineer has missed a page. Anna once waited twenty-eight minutes for Damien out of politeness - the customer noticed at minute forty-one. Damien had been mowing the lawn.

On the language of incidents

• Do not type “should be resolved” in any channel. “Should” is an admission. “Is” is a commitment. Pick one and live with it.

• Warm handovers only. Revenge is a dish best served cold; a handover is not.

• An ETA is not an estimate. An ETA is a vow. Do not bring an ETA into a war room unless you intend to be married to it, in sickness and in 4am Slack pings, until rollback do you part.

• “Quick question” is reserved for things that are both quick and questions. Almost nothing qualifies. Almost nothing.

• Assumptions will ruin you. The quickest way to surface the right answer is to loudly proclaim - or scribe - the wrong one. The corrections arrive fast.

• Every engineer eventually causes a major incident. It is the rite of passage. Affix no blame while the fix is happening. Everyone is human.

• If a service falls over and nobody is told, does it make a sound? Yes - louder than the outage, and longer-lasting. Send the comms before the fix lands, when it lands, and on resolution. Silence is not modesty. It is a second incident, and you do not control it.

• When in doubt, shotgun. Page every team that could plausibly own the fault and let them stand down as they clear themselves. The alternative is finding the right team at minute eighty-nine, having spent the first eighty-eight on a polite tour of the wrong on-call rosters.

On the politics of severity

• Severity is a description, not a negotiation. After mitigation, a Sev 1 becomes a Sev 2 - the bleeding has stopped, and the work that remains needs hours rather than a war room. Before mitigation, talking it down because "we can manage it in business hours" is administrative violence performed with a calendar invite.

• Pages have a half-life. Every Sev 1 that turns out to be a Sev 3 increases the response time on the next real Sev 1, and on the one after that.

• Mitigated is not resolved. Mitigated means the bleeding has stopped. Resolved means there are no loose ends. Close at mitigation and you will reopen the same incident in two hours’ time.

• Do not resolve the incident until the customer confirms it is resolved. Until then, you have only resolved the symptom you can see from where you are standing, which is rarely where the customer is standing.

• A Sev 1 called at 4am is a parachute pull, not an escalation. Do not ask why it wasn’t called at 2am - that question is for the retro, and the retro will be brutal enough. Maria got asked it on the bridge once. Maria now works in product management.

On heroes and the cost of them

• No incident process or toolset is ever good. Get the duct tape, grit your teeth, and run the response with what you have. The perfect tool is always two quarters away.

• Heroes get singled out. Heroes get burnt out. Heroes leave. If you are watching one person fix the incident alone, you are not running a war room - you are running a hospice, and the patient is your retention rate.

• The IC is also the scribe. Every off-topic message in the channel is a tax on her bandwidth and a hole in the timeline. The gaps in the PIR you’ll skim in two weeks are not Priya’s failure. They are yours.

• Twelve hours. No engineer stays on a bridge longer than that. After twelve, they are not an engineer. They are a liability with a Slack handle and a degraded sense of what “safe to deploy” means at 3am. Owen made it to hour nineteen. He authorised the rollback that became INC-1843. Owen has not returned.

On what comes after

• Incident metrics are never accurate at resolution. If you do not revisit them during the PIR, congratulations - your metrics are a fable, and the moral is whatever the dashboard says it is.

• Blameless does not mean toothless. A PIR that cannot say the word “we” has nothing to say at all.

• A PIR without action items, owners, and due dates is theatre. "We will learn from this one" is a New Year's resolution - sincere in January, gone by February, repeated word-for-word at the next PIR.

• The post-incident review is not a trial. The post-incident review is also not a group hug. It is what the Greeks would have called catharsis, if the Greeks had ever had to roll back a deployment at 11pm on a Friday.

• Close a bridge without a debrief and you have built a boomerang. Confirm who owns what, write it down, then close. Real boomerangs return to the thrower; this one returns to whoever is on call next.

None of this is etiquette in the way the word usually means it. The rules exist because Maria now works in product management, Owen never came back from hour nineteen, and Robert left three weeks after the seventh disturbance. Politeness - the well-meaning, professional, didn't-want-to-bother kind - is what put them there. The protocol is what's left when you take it out. Print the list. There will be another Robert. The list cannot save them all, but it can save the one whose name you have not learned yet.

Subscribe now

It was morning, my time. For the customer it was the back end of an afternoon at the end of several days that had not gone well. The incident had been running long enough that nobody on the bridge could remember which version of the timeline was current, only that it had been grinding along for a few days now without a fix and the room had stopped treating it as urgent.

There were reasons for this and the reasons were structural. A single-tenant issue does not look like an incident to a system whose metrics are calibrated to blast radius. The dashboards do not light up. The all-hands channels do not move. Only one tenant, the team had said at some point in the previous days. Not unkindly. Not maliciously. Accurately. In the language another industry would use it would have been only one patient, and an emergency room with one patient runs at a different tempo than an emergency room with forty. The room’s tempo adjusts to its own load. The room knew its load to be small.

We do not bring customers onto technical bridges. This is policy and there are reasons for the policy. The reasons are that customers, when present, ask questions that the engineering team cannot answer while still solving the problem, and that the presence of an angry account on the call corrodes the focus required to do the work. The policy is correct.

The team in the room was good. I want this on the record. The engineers were senior, the work was real, the problem was not trivial. They were debugging in the way that twenty years of practice had taught them to debug. They were communicating with each other in the channel in technical detail and at appropriate intervals. They were doing all of this at the cadence the room considered appropriate to the size of the room’s problem, which is to say they were not hurrying, because the room’s problem was not large. By any measure the room had its own metrics for, the room was working.

What was not working was anything the metrics did not see. The customer had not been spoken to in several hours. Not, at any rate, in the way a customer four days into an unresolved incident needs to be spoken to. The customer service representatives joining the bridge to ask for updates were being given updates that were technically accurate and operationally useless, because the engineers were oriented toward the fix and the comms were a thing the engineers did between debugging steps when they remembered to. The reps then took the technical updates back to the account, where they were translated and softened and stripped of the specifics that might have made them informative, and then relayed to a senior contact at the customer who had been on the phone, on and off, for multiple working days.

I joined the bridge after the head of customer service and support called me into it. They had picked up the customer’s call directly, several minutes earlier, after a senior contact at the account had bypassed every reasonable escalation path the company offered and gone directly to the senior-most person whose job title contained the word customer. By the time I joined the call they were already on it.

They were cracking skulls. Diplomatically - they were choosing their words carefully, carefully enough to stay short of the line that would have required a follow-up conversation with HR, but not so carefully that anyone on the bridge could pretend they did not understand what was being communicated. The questions they were asking were structured around customer experience and resolution timeline. These were not, technically, accusations. The engineers in the room understood them as accusations, because they were.

I have a policy of not bigfooting incident calls. The incident commander is supposed to have authority and I am supposed to leave it with them. The policy is one I still defend in most circumstances. It also meant, in the days leading up to this bridge, that I had not been watching it. There were other bridges. There were larger incidents. Somewhere in the structure that allocated my attention there was a working assumption that a bridge running this slowly did not need senior process attention, because if it had needed it the metrics would have said so. The metrics had not said so. Until somebody picked up a phone, neither had I.

The fix was finalized within a few days. The metrics will record it as a SEV-2 with an extended duration but a clean technical resolution. The bridge had ended in success.

There have been others. The names are different and the systems are different and the day of the week is different but the shape of the failure is not. A room calibrating its tempo to its own metrics. A patient outside the room. A comms chain that loses fidelity at each translation. An executive whose unannounced arrival is what produces movement. Perhaps four hundred of them, by now, across a career. I have stopped counting.

What was missing from those bridges has a name. We have not been using it.

The role is incident commander. The name is in widespread use. What is not in widespread use is the discipline the name is supposed to describe.

We use the title two ways. One is the senior engineer or engineering manager who is on-call when the page lands and is therefore, by default, the person on whom coordination falls. The other is a person whose entire role is to coordinate the incident - whose authority derives from the role rather than from seniority, and whose orientation is toward the patient rather than the room. The first version is a rotation. The second is a discipline. They are not the same thing.

The rotational incident commander has authority, but it is the wrong shape. A senior engineer running a bridge has technical authority - the room defers to them on how to fix the thing. An engineering manager running a bridge has team authority - their reports execute and their peers cooperate to whatever degree the org chart governs. Neither of these is the authority the role actually requires, which is coordinative - the standing to direct attention across functions whose hierarchies the IC does not sit inside, the position from which to tell customer success and product and the VP that the room will hold for ninety seconds while a decision is made about comms. Coordinative authority is bounded. It is not the authority to make the technical call or the team call or the political call. It is the authority to hold the coordination of the people who do.

It is also oriented.

My wife works in surgery. The temperature in the operating theatre is set by someone who is not in the room. The surgeon can have it changed, but they cannot change it themselves; they must communicate the need to the role, who makes the adjustment. The setting is not chosen for the comfort of the people present - it is chosen for the patient. The room is held cold for the patient even though the surgeons would prefer it warmer, because the room is not for the surgeons. The role that holds the temperature is the role oriented toward the patient and away from the room.

The rotational IC has neither the bounded coordinative authority nor the patient orientation. They are of the room. They have been pulled into the role from the room, and they will return to the room when the incident is over. Their measures of success are the room’s measures. Their relationships are the room’s relationships. The patient - the customer, the user - has no advocate in the room because no role in the room is structured to be one. So the room defaults to its own metrics. The metrics record the incident as resolved. The patient leaves, some weeks or months later, for reasons the system that knew about the incident will not track.

The objection to all of this is one I have held myself, in some version, for years. The policy of not bigfooting incident bridges contained the assumption that the model in place was structurally sound. I would not have written this essay without first having to admit that it was not.

The objection runs roughly: coordination is a leadership skill that any senior person can develop. The rotational model works because the people in it are senior enough to hold coordinative authority and patient orientation alongside their other contributions. The cases where it fails are cases where the wrong person was in the rotation, or the org has not trained well enough, or the IC was having a bad day. The fix is better people in the existing model, not a new discipline.

This has truth. The rotational model works in small organisations. It works in tightly-cohered teams whose incidents are bounded and whose customers are few enough to be visible to everyone in the room. It works when the volume is low enough that the people in the rotation can hold coordinative authority and outcome orientation alongside their other work without strain. In those contexts, the senior-engineer-on-rotation is the right answer.

The contexts where it fails are the contexts where it most needs to work.

The surgeon cannot adjust the temperature themselves. To change it they have to relay the request to someone whose role is to hold the temperature, who then makes the change and confirms it back. The architecture of the operating theatre enforces what the surgical discipline already requires: that orientation toward the operation and orientation toward the temperature are different orientations, held by different people, communicated across a deliberate boundary.

Software has built no equivalent architecture. We put the manager-as-IC and the senior-engineer-as-IC inside the room and ask them to hold both orientations at once, under pressure, for several hours or several days. They are competent. They are senior. They cannot hold both. One orientation loses. The patient drifts out of frame in small increments until the room is being run for the room.

The rotational model works until the room and the patient diverge. They always diverge. By the time they have, the room has built its metrics around its own comfort.

What this costs, when gotten wrong consistently, is a thing that does not appear in any single retrospective.

A customer who churns six weeks after a bridge that the metrics said had gone fine. A customer service rep who had been trying to flag what nobody on the bridge would hear, who is reviewed at the end of the year on a metric that does not include having been right. An engineer who runs incidents the way their seniority equips them to run them, who burns out from a role nobody has named and that nobody is going to thank them for. An incident that resolves cleanly on the metrics and quietly poisons three account relationships because the room could not see what the room was being measured against.

None of this is what the postmortem says happened. The postmortem says the fix shipped, the TTR was acceptable despite the extended duration, the on-call rotation worked as designed. The room’s metrics record the room’s experience. The patient leaves quietly some weeks or months later for reasons the system that knew about the incident will not track.

What is missing has a name. We could give it one.

The role would be coordinative rather than commanding. Bounded rather than ultimate. Oriented toward the patient by the structure of the role itself, not by the goodwill of whoever is awake when the page lands. It would be hired for, trained for, and protected from being collapsed back into the rotation. It would have authority over coordination and not over the work being coordinated. It would not be the senior engineer or the engineering manager, although either of them might do it well if they were trained for it and given it as their full role.

We have built the architecture for this in other industries. We have not built it in ours.

There is a bridge open somewhere right now. It is well-run. The metrics, when they are recorded, will say it ended in success.

Subscribe now

Every engineering organisation I have worked inside has had its rituals. Not the formal ones - not the standup, the retro, the quarterly planning offsite - but the older kind. The kind steeped in superstition. The kind that predates silicon and will outlive it. The kind a visiting anthropologist would recognise immediately, even if the practitioners would object to the comparison. We do not deploy on Fridays. We do not touch the billing service at end of month. We do not rename the queue. We do not utter the word "quiet" when on-call. We do not speak honestly about the bad region. Each of these is an offering. Somewhere in the organisation's past, the system became angry. We have agreed, collectively and without quite saying so, on the offerings that keep it from becoming angry again.

The original event has usually been forgotten. The offering persists.

The Friday Deploy

The most universal of the rituals, observed in some form by every engineering organisation that has lived long enough to have a folklore. The rule states that production deployments shall not occur on Fridays, and shall certainly not occur on Friday afternoons. The justification, if pressed, is operational - engineers do not like cleaning up messes on the weekend, nor do they enjoy the surprise of a Monday fiasco once everyone logs on to find things irrevocably broken. The justification is accurate. It is also incomplete. The deeper truth is that engineers have learned, over years and across companies, that Fridays are when systems choose to fail. Not because Fridays are technically different from Thursdays. Because the cost of a Friday failure is uniquely punishing, and the system, in its particular cruelty, seems to know this. The rule remains. It is enforced by engineers who have personally cleaned up a Friday deploy, who carry the specific memory of a weekend lost to a rollback or a Monday morning spent explaining what went wrong. They enforce the rule against the new engineers who have not yet had their own Friday, who will have one eventually, and who will then enforce the rule the same way against the next cohort. The folklore renews itself.

The Billing Sabbath

The billing service is sacred. It is not to be modified during the closing days of the month, when invoices are generated, totals are reconciled, and the organisation's revenue passes through a series of pipelines nobody fully understands. The freeze is enforced. There is a change window, a CAB approval requirement, a deployment lockout. The taboo underneath the policy is older. The freeze existed before the change window did, and the change window was written to formalise what the engineers had already agreed to without writing anything down. The new engineer who proposes a billing-related change in the last week of the month learns quickly that they have proposed something else. The response is not a polite redirect. It is a small ripple of alarm in the channel - senior engineers materialising to ask what is being proposed, why it is being proposed now, whether the proposer is aware of what week it is. The policy has a date. The taboo has none.

The Queue That Cannot Be Renamed

Somewhere in the architecture diagram is a queue with a name that no longer matches what it does. It was named for a feature that has been deprecated, a service that has been retired, or a use case that has shifted three times since the original implementation. Its current purpose has nothing to do with its name, and both facts are accepted as part of the system. Everyone agrees the name is wrong. Nobody renames it. The folklore whispers that once upon a time, a rename was attempted. The story is rarely told in full. The cost of renaming is judged higher than the cost of explaining the discrepancy to every new engineer for the rest of the system's life. The explanation becomes part of onboarding. Six months later, the new engineer will be the one explaining it to someone newer. The wrongness, eventually, becomes a feature.

The Word Not Spoken

The on-call engineer does not say it is quiet. Even when it is quiet. Especially when it is quiet, because that is when the system is listening. The rule is enforced not by management but by the other engineers in the channel, who will respond to any utterance of the word with a chorus of warnings and the horror reserved for genuine taboo. The reasoning, when articulated, is statistical. The word does not summon incidents. Incidents simply tend to follow it. The distinction is technically important and operationally meaningless. The reasoning, when not articulated, is older. It is the same reasoning that prevents sailors from naming storms while still at sea.

The Deprecation That Will Not Complete

The service was deprecated in 2022. The retirement date was set for Q3 2023. In Q2 2023 the date was moved to Q1 2024. In Q4 2023 the date was moved to Q3 2024. In Q3 2024 the date was moved to Q2 2025. The service is still running. It will, almost certainly, still be running next year, and the year after. Each delay is justified by a specific dependency unmigrated, a customer unnotified, a downstream system unmodified. None of these justifications are wrong. All of them, taken together, describe an organisation that has agreed to keep a thing alive while pretending to be killing it. The deprecation is no longer a project. It is a posture.

The Black Sheep Region

Every cloud-scale system has a region with a reputation. The reputation is real. It is also, officially, not real - the formal position is that all regions are equal, and the architecture documentation describes a uniform deployment topology that does not distinguish between them. The engineers who actually operate the system know better. There is a region where things simply go wrong. The other regions should be over-provisioned to compensate. Sometimes the over-provisioning has been quietly skipped, and the gap is treated as a manageable risk that has not yet manifested. Runbooks have specific procedures for when this region fails, written in a tone that suggests the failure is anticipated rather than handled. Capacity planning treats the region's reliability as a known quantity, and the known quantity is "lower." None of this is in the architecture document. All of it is in the operational reality. The engineers who run the system have built an entire infrastructure of compensations around a region they continue to officially treat as equal to its peers, and new engineers learn the compensations through exposure, not through documentation.

These rituals are not a problem. The problem is that the institution cannot admit the rituals exist. The architecture document describes a uniform topology. The roadmap describes a deprecation that will complete. The change-management policy describes a freeze that has reasons. None of these documents acknowledge the superstitions underneath them. The rituals persist anyway, transmitted through warning glances and onboarding asides and the kind of hushed corrections that new engineers learn to recognise as folklore.

We are not a rational industry. We are a tribe with rituals, and we have agreed not to call them rituals because we are an industry that does not believe in superstition.

The original event has been forgotten. The offerings persist.

Subscribe now

Every severity scale is a map of what an organisation is willing to admit.

The top of the ladder is well-lit and well-trodden. The bottom, less so. Walk down it slowly and you notice the lighting getting worse.

SEV-0 is the incident that ends one company and starts another in its place - the same logo, the same office, the same payroll, but a different company, the way a building is a different building after a fire even if the bricks are the same. You learn about a SEV-0 the way you learn about anything serious in this industry: late, indirect, and from someone who would rather not be telling you. The principal engineer at the bar who says "we don't deploy on Fridays anymore" and does not explain why. The staff engineer who flinches, fractionally, at the mention of a particular subsystem. The runbook with a section so over-engineered it could only have been written by someone who watched the previous version fail. SEV-0 is the inheritance nobody hands you. The architecture remembers. The taxonomy does not.

SEV-1 is the one everyone understands. The site is down. The money has stopped. Your company is mentioned by name on a news site. Someone senior is awake who should not be awake, and someone junior is typing with the terrible precision of a person who knows their commit history will be read aloud in a room next week. SEV-1 is loud, expensive, and - because of the noise and the cost - honest. You cannot hide a SEV-1. The category works because the incident refuses to be ignored.

SEV-2 is the incident that does not sleep, and arranges for you not to either. It is too big to ignore and too small to escalate to someone important. It is real enough that the channel stays open through the night. So you hold the line for four hours, sometimes eight, and you watch the clock the whole time, because the longer it runs the more likely it becomes that someone important will have to be woken anyway, and at that point the incident is no longer a SEV-2. SEV-2 is the severity that is partly defined by how quickly you can make it stop being one. It is where you learn that incident management is a clock-management problem.

SEV-3 is the workhorse. It is where most of incident management actually lives - the elevated error rates, the latency creep, the integration partner who has chosen today to have feelings about their API contract. It is also, by volume and by neglect, the severity most likely to be ignored. Not rejected. Not triaged and deprioritised. Ignored. Left in the channel like a glass on a counter that someone will get to eventually. And then four hours pass, and the glass is still there, and the customers who were patient at hour one are no longer patient at hour four, and the SEV-3 is no longer a SEV-3. It has become a SEV-2 by sheer laziness - not because the incident got worse, but because nobody made it better while making it better was still cheap. If you want to know whether an organisation's incident management is real or performative, watch how it handles a SEV-3 on a Friday afternoon. The answer is usually: it doesn't.

SEV-4 is the severity that half the industry claims to have and nobody actually runs. It is the incident too small to mobilise for and too real to dismiss - the queue that backed up for six minutes, the endpoint that five-hundred'd for a fraction of a percent of traffic, the alert that fired and resolved before the channel filled. In theory this is where the organisation learns. In practice it is where the organisation files and forgets, because the cost of taking a SEV-4 seriously is higher than the cost of shipping something else instead. So the category quietly empties. And in some places - I worked inside one - it never existed to begin with. The scale goes one, two, three, and then straight to the end. A house with no ground floor. Everyone who worked there understood why without ever quite saying it.

SEV-5 is the category we do not have, because having it would mean admitting what it contains. It is the documentation that went stale in 2023 and is still being cited in 2026. It is the monitoring nobody trusts, because the thresholds were set by someone who left three reorgs ago. It is the single engineer who understands the billing pipeline and is currently interviewing at a competitor. It is the runbook that has been wrong for fourteen months, and the team that has learned to work around the wrongness, and the new hire who will inherit the workaround as the thing itself. None of this will page you. All of it will kill you. The reason we do not have a severity for slow erosion is that a severity implies a response, and the response to slow erosion is structural, and structural responses require someone willing to say aloud that the house is on fire even though nothing is visibly burning.

The ladder does not end at SEV-3. It does not end at SEV-4. It ends somewhere below, in a category we have decided not to name.

It will wait there, whether we name it or not.

Subscribe now

There is a particular kind of silence that used to exist in the world, and I would like to report it missing.

It lived in the two-minute gap between ordering a coffee and receiving it. It lived in supermarket queues, in the passenger seat of a long drive, in the waiting room at the GP, in the shower, in the three-second pause between pressing the button for the lift and the lift arriving. It is gone now. Every one of those silences has been surveyed, zoned, subdivided and sold to a developer, and the developer is Meta, or Google, or ByteDance, or whichever of them got to the zoning board first, and the tenant is a ninety-second video of a man deep-frying a Toblerone.

This was not a natural process. Silences do not spontaneously fill with Toblerones. Someone had to do it. Someone had to decide that the pause was a market failure, that the gap was inventory, that the three seconds you spent waiting for the lift were unmonetised and therefore an affront. I would like, in the next thousand words, to itemise the damage and, eventually, to name them.

Let me itemise what was taken, for the purposes of the file. The queue at the post office. The minute at the traffic lights. The bit in the shower after the shampoo and before the conditioner. The walk down the driveway to the bin. The thirty seconds you used to spend looking out a train window. The forty seconds you used to spend looking at your own ceiling. The four seconds between setting the pressure cooker and realising you had nothing to do for the next forty minutes, which used to be a complete thought and is now a low-grade panic attack.

The perpetrators were not, in a strict technical sense, thieves. Thieves break in. Thieves leave evidence. These men applied for a permit. They filed paperwork. They had a lawyer explain to a man in Congress that the pause between stimuli was a market failure, that the three seconds you spent waiting for the lift were inventory, that an unmonetised second of human attention was, in fact, an insult to the shareholders. The man in Congress nodded. The permit was issued. The bulldozers arrived in 2011, or thereabouts, disguised as an iPhone.

Their names are on a list somewhere, but the names are the least interesting thing about them. They are interchangeable. They rotate. One goes to Meta, the next goes to OpenAI, a third sells everything and buys a ranch in Montana and calls it retirement, though in reality he is still on four boards. They wear Patagonia vests because the uniform is required for entry. They speak in a dialect assembled from Stanford business school, a self-help book about habits, and the collected tweets of a man who owns a rocket company. They do not think of themselves as criminals. They think of themselves as founders.

I should, at this point, admit that I am the mark. I was made redundant in March. I had expected, in some remote and theoretical way, that a redundancy would involve a period of rest - that there would be, inside the disorientation and the grief, some pocket of stillness, some hours unclaimed by anybody. There was not. By the first week I had built a personal brand. By the second I was posting and browsing on LinkedIn on a strict Tuesday-to-Thursday cadence. By the third I had ranked nine prospective employers by salary band. By the fourth I had written a two thousand word essay about a fidget toy. I did not rest. I did not know how. A day in which I had not generated something - a post, a pitch, a paragraph, a note, a thought worth capturing - was a day I had failed, and the failure was personal, and the failure was metabolic, and it arrived on time every morning at 3am, uninvited, with a list.

This is, I recognise, a diagnosis. The symptom is the inability to sit in a chair for forty minutes and watch a dashboard go green without reaching for a second screen to watch the dashboard watch itself. The symptom is the inability to queue at the post office without feeling the queue is a kind of theft. The symptom is the inability to experience a Sunday afternoon without narrating it into a piece of content. The symptom is shared, I suspect, by most of the people reading this, and by most of the people who will not, and most especially by the people whose professional responsibility is to notice, in a room full of green dashboards, the one thing that is not quite right.

Consider the on-call engineer. Consider the air traffic controller. Consider the anaesthesiologist who spends six hours watching a number on a screen that must not change, whose entire job is the capacity to remain vigilant during the fifth hour and fifty-ninth minute of a shift in which nothing has happened. Consider the sonar technician. Consider the nurse on a night shift in ICU. We have built an economy that requires a class of people to be professionally bored - to sit still, to watch, to notice - and we have issued each of them a phone engineered by the best minds of a generation to ensure they cannot. You cannot ask a human to watch a quiet dashboard for four hours and also hand them a slot machine, and we have done both, at scale, and called it digital transformation.

The case will not be investigated. No charges will be filed. The crime was legal. The crime is, in several jurisdictions, considered a growth sector. The evidence is in my pocket. It is in the anaesthesiologist's pocket. It is in the on-call engineer's pocket. I checked mine while writing the previous sentence. I will check it when I finish this one.

I will check it, I suspect, during the pause between you reading this paragraph and deciding whether the piece was any good.

Subscribe now

The instruction was simple. Hands flat on the desk. Eyes forward. Pay attention.

At some point in the history of Western education, someone decided that the ideal learning posture was that of a person waiting to be executed. Upright. Still.

The first thing they take is the movement. Before they take your confidence, before they take your grades, before they install the particular brand of shame that follows a restless child into adulthood like a bad debt - they take the movement. The stance of compliance, dressed up as the posture of learning.

And so, rebellion. The pen went first. Confiscated, second week of term, on the grounds that the clicking was disruptive. Then the eraser - or what was left of it. Apparently the small debris field on the desk constituted some kind of offence. The smart ones learned to doodle under the pretense of taking notes. If you could pretend to be still enough, you could get by.

Here is what they do not teach you in school, possibly because it would undermine the entire architecture of the place: your brain runs on dopamine the way a city runs on electricity, and when the supply is irregular - when the system is wired differently from the start, which is the case for a significant percentage of the population - the lights flicker. The executive function dims. The prefrontal cortex, that smug little governor of attention and impulse, starts to go offline.

As it turns out, the restless ones were right.

Here is what the science has established, at considerable expense and over several decades of peer-reviewed effort:

The brain is not separate from the body. Mental functions cannot be understood without reference to the physical body and the environment. Movement - deliberate, rhythmic, embodied movement - changes brain structure. It preserves grey matter. It strengthens neural connectivity in regions governing attention, emotion, and executive function. It means your body can start regulating itself before your brain has decided to. No thinking necessary.

Yoga practitioners. Tai chi practitioners. Qigong. The Feldenkrais Method. Conscious dance. All of them producing measurable neurological change in people who practice them.

The field has a name. Movement-based Embodied Contemplative Practices - MECPs, per a 2014 paper in Frontiers in Human Neuroscience by Schmalzl, Crane-Godreau and Payne that is worth reading if you want the full architecture.

The concept is older than the acronym by several thousand years.

Somewhere in a UC Davis laboratory, a researcher named Julie Schweitzer has spent years proving something that should have been obvious to anyone who ever watched a kid get their pen confiscated. Children and adults with ADHD, she found, performed better on cognitive tasks when they fidgeted. Not slightly better. Measurably, consistently better. The movement wasn't despite the focus. It was how the focus was happening.

For neurodivergent brains in particular - ADHD, autism spectrum, sensory processing differences - this isn't optional. It's the mechanism.

You see, the prefrontal cortex - your brain's executive function hub, the part responsible for planning, working memory, and sustained attention - runs on dopamine. This is not controversial. What is slightly more interesting is that physical movement, including something as small and apparently pointless as rolling a pen between your fingers, triggers dopamine and norepinephrine release through a mechanism that lands in roughly the same neurochemical neighbourhood as what Ritalin does. Nobody puts this on the label of fidget toys. They probably should.

Before the prayer bead, before the rosary, before any of the formalised liturgical hardware that organised religion eventually wrapped around this impulse - there was a stone. Just a stone. Smooth, because a river had been working on it for longer than any human civilisation has existed. Picked up, held, rubbed with the thumb until the thumb knew every contour.

Archaeologists have found them in ancient Greek burial sites, worn smooth in a way that only years of daily handling produces. The Greeks were pulling them from the sea specifically for this purpose as far back as 1000 BCE.

At some point - and the exact point is disputed, obscured by the usual fog of religious history - somebody had the idea of putting the stones on a string. This was, in retrospect, a significant upgrade. A single stone is a comfort. A string of them is a system. You can count on a string.

Monks on Mount Athos in the medieval period were tying knots in cords to count prayers - the komboskini, prayer rope, functional and austere. Then it escaped the monastery, as useful technologies tend to do, and found its way into the cafes and street corners of Greek life, where it shed the prayers but kept the rhythm.

By the twentieth century the komboloi was everywhere. Prime ministers had them. Shipping magnates had them. The old men in kafeneions clicking their beads in the shade of the plane trees had them. The rhythm of the beads had become a kind of ambient music of Greek culture - fast clicking signalling agitation, slow rolling signalling ease, the hands encoding mood in sound the way a jazz musician encodes feeling in tempo.

And then there was the begleri. The stripped-back version. No closed loop, no tassel, no elaborate bead count - just a short cord with weighted ends, open-stranded, designed for tricks and manipulation rather than counting. Simpler, more versatile, easier to carry in the slim pockets of blue jeans. The begleri became associated with the mangas - the Greek urban countercultural type, linked to the working class port districts, to rebetiko music, to a particular brand of cool that had no interest in respectability. They would swing the beads with theatrical confidence, clacking them together in ways that attracted attention, that demonstrated skill, that said: I have nowhere to be and I know exactly what I’m doing.

The object that started as a monk’s prayer tool had become a prop for the Greek equivalent of James Dean.

In 1967, the Greek military junta banned begleri with long cords. A dictatorship, with tanks and all the apparatus of authoritarian control, found time to legislate the dimensions of a hand toy. The practice survived. The cord got shorter.

The timeline of this technology runs roughly as follows: Smooth stone pulled from a river, ancient Greece, approximately 1000 BCE. Knotted prayer cord, Mount Athos monastery, medieval period. Komboloi, nineteenth century. Begleri, Greek urban working class, late nineteenth century onwards. Begleri with long cords banned by military dictatorship, 1967. Begleri unbanned, junta collapses, 1974. While the fidget spinner circa 2017 gained peak absurdity and was largely forgotten within eighteen months, a small machined object from Canada had already quietly arrived two years earlier. The Knucklebone. 2016. Still in production. Still in pockets.

What this timeline is the history of is not toys. It is not stress relief products. It is not the wellness industry finding new ways to monetise anxiety. It is the human nervous system, across three thousand years of recorded history, refusing to accept that the hands have nothing useful to do.

Every civilisation that ever tried to sit still and think eventually put something in its hands. The only thing that has changed is the material.

The timeline does not tell you which of these things actually worked.

There is a test for this. Simple, brutal, takes about thirty seconds. Put the thing in your hand during a task that requires genuine concentration. After five minutes, ask yourself: where was my attention? If the answer is anywhere near the object in your hand, you have a toy. If the object has faded into the background of sensation - present, grounding, doing its quiet work below the waterline of conscious thought - you have a tool.

Most of what got sold in the great fidget panic of 2017 fails this test immediately. The spinner fails it. The cube with its sixteen satisfying interactions fails it. They were designed to be noticed, to be played with, to be the thing you were doing - because that is what sells, and the alternative, a small unremarkable object that works precisely because it refuses to be interesting, does not photograph well and cannot be unboxed on YouTube.

The worry stone does not have a YouTube channel. It has been in continuous production for three thousand years.

The first thing you notice about the knucklebone is the weight. Not heavy, exactly, but present - the particular density of machined metal that communicates craftsmanship without announcing it. You roll it once between the fingers and something settles, somewhere in the background of the nervous system, in the way that a good pen or a well-worn stone settles. The hands have found something that fits.

It is approximately the size of a small spool, with rounded end-knobs and a central grip that sits naturally in the pinch of thumb and forefinger. It was designed by a Canadian schoolkid in 1989 who was tired of getting in trouble for doing yo-yo tricks in class. He was, in other words, exactly the kind of kid this article is about. He built it from polymer clay, then forgot it in a box for twenty-seven years before the world was ready for it in 2016.

It was a solution looking for a problem that already existed. The problem being this: how to give a restless mind somewhere to put itself without disturbing everyone around you.

Here is what the classroom never told you: the fidgeting was correct. The tapping, the rolling, the increasingly elaborate doodles in the margins of notebooks that were supposed to contain something else - all of it, correct. The nervous system doing what nervous systems do when they need to think and are not being allowed to move: finding something, anything, to keep the hands occupied while the mind gets on with it.

The monks on Mount Athos knew this. The Greek mangas knew this. The schoolkid in Victoria Canada with the polymer clay knew this.

The teacher who took the pen did not know this. That is not your problem anymore.

AroundSquare make the knucklebone and several other objects worth putting in your hands. They did not sponsor this article, endorse it, or receive advance notice of its existence. This is not an advertisement. It is a recommendation, which is a different thing entirely, and the difference matters. aroundsquare.com

Subscribe now

PROBLEM RECORD — PRB-1743-BLACKSPOT Raised following INC-1743-BLACKSPOT (Total Loss of Vessel, The Black Spot)
Status: Post-Incident Review Complete
Problem Owner: D. Norkin, Harbour Master (recipient of both ravens)
Review Facilitated by: Nobody. This document was written collectively. It took fourteen weeks.

INCIDENT SUMMARY

On the evening of [DATE UNKNOWN - the ship’s log was being used to prop open the powder room door], The Black Spot encountered severe weather conditions in the North Atlantic. The vessel sustained catastrophic and irreversible damage resulting in total loss of ship, cargo, and most of the crew’s confidence in each other.

The position of Incident Commander had been formally eliminated six weeks prior to the incident following an operational efficiency review conducted by Harwick & Sons Maritime Consultants, who noted that the Captain “did not directly contribute to propulsion, navigation, or combat operations” and recommended the role be dissolved with responsibilities distributed across existing crew.

The review was conducted during fair weather. This was considered representative.

The redistributed responsibilities were documented in a two-page appendix. The appendix was filed. No one is able to confirm where.

The storm did not appear to have read the appendix.

INCIDENT DETAILS

Duration: Approximately 64 minutes from initial storm detection to reef contact. The incident is considered ongoing in the sense that the ship has not been recovered as of this writing.

Scope: The entirety of the vessel The Black Spot, inclusive of cargo. Vessel was forcibly relocated in close proximity to a well documented reef in the North Atlantic Ocean.

Crew Impact: Of the original complement of 27, fourteen are confirmed present for this review. Nine are accounted for but declined to participate. The remaining four submitted stew as a mitigating factor and have been asked to resubmit (see below timeline).

Cargo Impact: Total loss. The manifest has not been recovered. This is considered fortuitous given the nature of several listed items.

Reputational Impact: Significant. The Black Spot was previously considered a competent vessel with an experienced crew. This assessment will require revision.

Financial Impact: The Black Spot was valued at approximately £3,400 at time of loss. The efficiency review which precipitated the incident (see summary above) saved the vessel £65 per annum in Incident Commander’s salary. A full return on this saving would have been achieved in approximately 52 years, assuming no further storms.

Recovered by: Several restoration streams were attempted (see below timeline), however none were successful in averting the ship’s erratic movement directly into a reef, resulting in complete loss of service, buoyancy, and stew (again, see below timeline).

Root Cause: Reef.

TIMELINE

02:31 | Storm detected. No single person notified. Everyone notified simultaneously via ship’s bell.

02:33 | Gunner begins firing cannons at the storm. When later questioned, notes that cannon fire successfully deterred a hostile boarding party during a previous storm in 1741. Considered this a comparable situation.

02:35 | Navigator charts course to nearest port. Does not communicate this to the crew. Crew continues bailing toward open ocean.

02:47 | Deckhand J. Pemberton correctly identifies reef ahead. Mentions it to the gunner. Gunner is busy.

02:51 | First Mate assumes command. Calls crew meeting to establish agenda for response.

02:53 | Crew meeting quorum disputed. Three crew members are bailing and cannot attend. Meeting paused pending their availability.

02:58 | Bailing crew members rotate in. Two previous attendees have returned to bailing. Quorum disputed again.

03:00 | Ship's bell commandeered for continuous ringing "to alert nearby vessels." No nearby vessels. Nobody can hear anything anymore.

03:04 | Crew meeting resumes. First agenda item: whether this meeting requires minutes. Debate lasts eleven minutes as the crew is unable to hear each other. Motion eventually passed. No one volunteers to take minutes.

03:15 | Sub-committee formed to determine chain of command. Sub-committee immediately disagrees on its own membership.

03:19 | First Mate declares the storm “appears to be passing” based on a brief reduction in wind. This information travels through the crew instantly.

03:21 | Cook, having heard the storm is passing, begins preparing a restorative meal for the crew. Requests an ETA on full resolution so he can time the stew. Receives four different answers. Begins stew anyway.

03:22 | Storm resumes. Cook does not receive correction. Stew continues.

03:26 | Smell of stew reaches upper deck. Four crew members, independently concluding the storm must be over, secure their stations and make their way below.

03:27 | Bosun identifies mainsail is torn. Goes below to file maintenance request. Awaits approval. Gets distracted by smell of food on his return trip to the upper deck. Does not return.

03:28 | One Crew Member proceeds to set the upper deck on fire, believing that fire will deter water and hence prevent waves from washing remaining crew overboard. Waves unaffected. Upper deck significantly affected. Available crew now managing both storm and fire. Stew unaffected.

03:29 | First Mate notes a significant reduction in available crew on deck. Unable to locate the Bosun, and too occupied to search further, he returns to the helm. The helm is on fire.

03:30 | First Mate sends raven to harbour master with detailed situation report.

03:31 | Raven returns with clarifying questions and a request for additional detail before the harbour master can determine appropriate next steps. First Mate begins drafting response by the warmth of the fire on the upper deck.

03:32 | Crew asks for guidance. First mate is too busy to respond.

03:34 | Deckhand Pemberton raises reef concern again, this time in writing. Information reaches First Mate, who is mid-draft on raven correspondence. Notes it for the agenda.

03:35 | Reef reached.

03:36 | Second raven dispatched. Contents unknown. Raven did not return.

03:37 | Sub-committee adjourns inconclusively.

CONTRIBUTING FACTORS

CF-01: Absence of a single coordinator with authority to direct crew actions. Evidence: Seventeen independent and individually correct decisions were made during the incident window, none of which were aware of the others. Net effect: the ship moved approximately 200 yards in a random direction.

CF-02: Problem identification occurred early but was not actioned. Evidence: Deckhand J. Pemberton correctly identified the reef at 02:47. This information did not reach a decision-maker until 03:34, at which point it was no longer actionable for reasons that will be apparent from the vessel’s current location.

CF-03: Technical response initiated before problem was understood. Evidence: Cannon fire commenced at 02:33. The storm was not a ship. This approach was maintained for eleven minutes.

CF-04: A remediation action created a second, unrelated incident. Evidence: The upper deck fire, intended to deter wave activity, required three crew members to manage for the remainder of the incident window. Those three crew members had previously been bailing. The water level is relevant here.

CF-05: Communications infrastructure repurposed mid-incident. Evidence: The ship’s bell, primary alerting mechanism, was commandeered for continuous ringing at 03:00 and remained unavailable for directed use for the remainder of the incident. Crew reported being “unable to hear anything important, or each other, or themselves think.”

CF-06: Process compliance prioritised over incident response. Evidence: The bosun correctly identified a critical equipment failure at 03:27 and followed established maintenance request procedure. The request remains pending. The ship does not.

CF-07: Uncontrolled communications caused compounding crew misalignment. Evidence: The First Mate’s premature declaration that the storm was passing at 03:19 was not corrected through any official channel. It reached the cook, who began preparing a meal. The smell of the meal reached the upper deck, where four crew members independently concluded the incident was resolved and stood down. Available response capacity reduced by approximately 30% as a direct result of one uncorrected status update.

CF-08: Stakeholder communications consumed disproportionate crew resource. Evidence: Two ravens were dispatched to the harbour master during the active incident window. The harbour master was not in a position to assist. The ravens were.

CF-09: Command structure decided by committee during active incident. Evidence: The crew held a vote on interim command at 02:51. Quorum was disputed twice. A sub-committee was formed at 03:15 to resolve the matter and adjourned inconclusively at 03:37, by which point the matter had resolved itself, albeit poorly.

ROOT CAUSE

The root cause of INC-1743-BLACKSPOT was not the storm.

It is to be noted that both storms and reefs are known environmental hazards. The Black Spot had navigated these previously, under the coordination of a dedicated Incident Commander whose role was to maintain a complete picture of the vessel’s situation, direct crew actions, manage communications, and make decisions with incomplete information under time pressure.

As noted in the summary, that role was eliminated six weeks prior to the incident on the basis that the previous incumbent “wasn’t doing anything visible.”

It is the finding of this review that he was doing something visible. We were it.

RECOMMENDATIONS

REC-01: Reinstate the role of Incident Commander with clearly defined authority during active incidents.

REC-02: Establish a communications protocol that does not involve all crew being notified simultaneously of everything, always, via a bell.

REC-03: Create a defined escalation path for crew observations so that information like “there is a reef” reaches someone who can act on it in under forty-seven minutes.

REC-04: Prohibit the use of fire as a wave mitigation strategy.

REC-05: All status updates during an active incident to be issued by a single designated coordinator. Premature declarations of resolution to be corrected immediately through the same channel they were issued. The cook cannot be expected to know the storm resumed if nobody tells him.

REC-06: The harbour master is a post-incident resource. Ravens are to be dispatched after resolution, not during. This recommendation will not be popular with the First Mate.

Subscribe now

[A glass elevator descends through ambient hold music and the faint sound of someone crying on a Teams call. An HR Executive in a tasteful blazer, carrying a tablet, smiles warmly at the assembled audience.]

Ah, hello! It’s lovely to see you all here. As the more perceptive of you have probably worked out by now - yes, this is that meeting, and I am your… well, ex-Chief People Officer. Karen. Now, HR stands for Human Resources - and I want to be very clear that the company valued its human resources enormously. Right up until the point where it didn't.

Which is, broadly speaking, why you're here.

Now, you’re all gathered for... (checks tablet) ...an indefinite period of professional transition! Which in today’s economy could be a heck of a long time, so you’ll get to know your LinkedIn connections very well by the end. But for now I’m going to need to split you up into groups. Could you please stop texting your teammates to find out if they're here too. They are. Different room. We find it's cleaner that way.

Now - Google? Google, if you could come over here please. And Meta - yes, there are rather a lot of you, aren’t there - if you could form a line over there. Microsoft, you can join Meta. You’ve had practice.

Intel, if you could just... wait, are you here again? That’s three times in two years. You know where the chairs are. Amazon? Yes - find the group yourself. Consider this your us-east-1 moment. Everything goes down eventually.

Ah - Atlassian! Welcome, welcome. You can stand anywhere you like, you’re quite good at self-organising. Block? Yes, you're exactly half the company. Which sounds bad until you realise the other half have to do all your jobs now. So.

Engineers? If you’d step forward. My goodness. Could I split you into “genuinely surprised” and “had a go-bag ready since 2023”? Lovely. DEI teams, if you could come down here - I am so sorry, you were the first to go and somehow the last to know. The irony is not lost on me, I did flag it.

Senior middle managers? Over here please. There’s a sub-group specifically for people whose entire job was to attend meetings about other meetings. You’ll feel right at home. Technical Program Managers? Over there. You'll be pleased to know we've created a Confluence page documenting today's meeting. No one will read it.

Heads of Engineering? You’re in that corner, thank you. I know this is difficult. You hired most of these people. You fought for the headcount. You made the business case. In 2021.

People who found out via a 2am email - if you’d just... yes, that’s right. And people who found out when you were forcefully logged out of the meeting you were midway through - if you’d join them. I know. I did raise the communication strategy in planning but that feedback wasn’t actioned.

Now, Performance Improvement Plan alumni? Yes, all two of you. You’re in that group too. No need to look surprised - you’d already seen the preview content.

Right. Are there any questions? Yes. No, I’m afraid the severance isn’t negotiable. If you read your employment contract - and I appreciate many of you did not - you’ll find your options are quite limited. The equity cliff situation is particularly... well, yes. The career coaching is complimentary for thirty days, after which you’re on LinkedIn Premium, which gives you five InMail credits a month to contact people who are also on LinkedIn Premium looking for someone to contact.

(brightly)

I’ll hand you over now to Brad from Outplacement. And I’ll see you all at the networking event - which is, yes, a webinar. Unmute yourself if you need anything. The company's stock is up 3.4%.

[Karen steps back into the elevator. The doors close. The hold music resumes. Somewhere, someone is still crying on a Teams call.]

Subscribe now