Subjectively, I am Full, Flowing, and calmly awake.

My Fitbit, with the kind of confidence that two-decimal precision allows, has told me my night was short, my REM thin, my resting heart rate up. None of this is wrong. None of it is the source of the day’s plan.

I have already decided what I am going to do today. The watch’s opinion is interesting evidence I will consider, the way a careful person considers the testimony of a witness who has only seen part of the room.

This used to be harder than it is now. For years the watch’s opinion was the verdict; my own felt sense was soft data, prone to wishfulness and self-flattery. The asymmetry was structural. The watch was quantified, decisive, and rendered in colour. My internal read was none of those things. Numbers win arguments with felt sense, on the same logic that any quantified claim wins an argument with any unquantified one: the number is the kind of thing institutions accept.

The watch is right about its substrate. It really did measure what it measured. My night really was short, fragmented, light on the stages a body uses to repair itself. None of that is in dispute. What is in dispute is the implication: that those numbers add up to a verdict on what I can do today.

This post is about how I have learned to demote the watch from judge to witness. It is also about when to call it back to the stand, because there are mornings the watch sees something my body has been masking for me, and the testimony I would rather not hear is the one I most need.

The false authority of the score

The recovery score is an interesting design object.

It looks like a measurement. It comes stamped with a unit, a colour, a percentile band, and sometimes a sentence of advice. Its visual rhetoric is medical: clean numerals, traffic-light palette, the quiet confidence of a clinical reading. Underneath the surface, what the device has actually done is run a model. The model takes a few signals (heart rate variability, resting heart rate, sleep stages) and compresses them into one number. The number is then presented as a property of you, in the way that height or weight is a property of you.

It is not. It is a property of the model’s read of a few signals at a few moments. The compression is enormous and the loss is silent.

That silence is the design problem. The score does not arrive with a confidence interval, a list of inputs it lacked, or a footnote on what categories of energy it cannot see. It arrives bare. The whole interpretive labour of mapping a one-number readout to a many-dimensional state is offloaded to the wearer, who tends to do it quickly, in the kitchen, before coffee, on the strength of whatever colour the band turned out to be today.

Most of the resulting interpretation is wrong, and the wrongness is consistent in one direction. The score reads what it can read and the wearer treats the reading as if it covered everything. The result is a class of mornings where a fully measured night, scored low, reshapes the day around a verdict the score did not have the inputs to issue.

This is not the watch’s fault. The watch is a witness, doing witness work. The category error is treating the witness’s testimony as the verdict.

Witness, not judge

The frame I have been using is the courtroom one.

A witness gives evidence. They saw what they saw, from where they were standing, with whatever attention they happened to bring. The evidence enters the record. Its weight depends on what else is in the record, on context the witness did not have access to, on competing testimony, and on a frame for interpreting all of it together. The witness does not assemble that frame; the witness deposits one input.

A judge issues a verdict. The judge integrates testimony with context, precedent, and the broader picture, and produces a decision that says: given all of that, the action is this.

Wearables are witnesses. They saw what they saw, from where they were standing, which is your wrist. Their attention was real and their measurement was honest. The evidence they deposited into your morning is genuine. It is also one slice of one substrate.

The verdict is somewhere else.

It belongs to the integration that you, in the kitchen, on a body you have been living inside for decades, can do. That integration includes the watch’s testimony, but it also includes context the watch did not have: what you ate, what you have been emotionally chewing on, where you are in a recovery curve from a stressor weeks back, whether the day’s work is the kind that drains you or feeds you, what your social battery looks like, what you can feel in your shoulders and jaw and breath that the watch on your wrist never reaches. The integration is not magic. It is the working knowledge of a long-occupied body, processed by a brain that has had access to all of those signals, all the time.

The integration outperforms the watch on any morning where the watch’s substrate is a small part of what is going on. Which is most mornings.

The trap is the categorical confusion that lets the witness’s testimony pass for the verdict. Once that happens, the rest of the evidence stops being weighed. The watch said red, so the day is red. The integration is overruled by an input it should have been one of.

The move that resolves the confusion is small and structural. You do not have to ignore the watch. You just have to stop letting it pretend to be the judge.

The bi-phasic morning

Let me show what this looks like with a specific case, where the watch was right, was true, and was also wrong, all about the same night.

A few days back, my Fitbit told me at six in the morning that I had slept just over four hours. The recording was complete, in its own terms. The night had a start and an end and a number, and the number arrived in the colour that means take it easy today.

My body said something different. The body said: I am not finished.

I had been awake for an hour, doing some work pre-dawn. Now there was a window in which I might be able to slip back into sleep, and the body was nudging toward it, the way a body does when it is genuinely tired rather than performing tiredness. I lay back down. I slept another two and a half hours. By eleven the watch had quietly updated to show just over seven hours total, across two blocks, the second one with normal sleep architecture.

The reading at six was true at six. By eleven it was wrong about the same night.

That sentence is the thing I want to sit on. The watch was honest. It reported what it had measured at the moment of the report. Its mistake, the mistake the device cannot help making, is that the reading was framed as a property of the night. Nights, like most things in a body, are not closed objects at six in the morning. They have a shape that can extend, fragment, double, fold. A wearable’s “night” is whichever block of horizontal motionless body it happened to capture.

The category error here is not subtle and the move out of it is not heroic. The body knew. The body said I am not finished. The watch’s testimony was that the body had finished. Two truths, one moment, contradictory. The witness was correct about its substrate. The judgement of what is true about this body’s night lived elsewhere.

A reader might object that this is a small case, because the watch’s reading was simply incomplete, and a more complete reading would have agreed with the body. That is true. It is also the easy version. The hard version is the morning after a night where the watch had complete data, and felt sense disagreed anyway. That is the next section.

When the data was complete and the body still won

Yesterday morning the watch had complete data. There was no second block waiting in the wings, no missing chunk. The night had started a little before eleven and ended a little after three, fully tracked, fully scored. Just under four hours of sleep, fragmented across more than a dozen brief wakes, with both deep and REM stages well below where they would normally sit. All of that is real and uncontested.

I read the data shortly after waking, sitting in the kitchen waiting for the kettle. My felt read on the same morning was Full, Flowing, and calmly awake. Not artificially upbeat. Not wishful. The kind of clear, unforced read you get when initiation gates are open, the brain is settled, and the day in front of you has an actual shape.

I planned five and a half hours of focused work on a research project I have been building. I did the five and a half hours. At the end the cognitive flexibility I had walked in with had not noticeably degraded. The afternoon went into bureaucratic work that needed actual attention, and it all held up. The day cost about five spoons against a stated budget of nine. None of it felt forced.

The watch had been right about the night. The day went well anyway.

This is the case the witness frame is for. The watch was not slow, was not incomplete, was not wrong about its substrate. It saw what it saw. What it saw was that my sleep architecture had not done the physical-restoration work it usually does. What it could not see was that physical-restoration work is one input to felt energy, not the only one.

Felt energy is a downstream integration of sleep, but also of circadian timing, hormonal state, emotional regulation, the meaningfulness of the day’s tasks, the social shape of the morning, and a half-dozen other things the wearable has no instrument for. Sometimes the integration runs lean: good sleep, dragged day. Sometimes it runs rich: poor sleep, generative day. The watch can only ever measure one of the inputs.

There is a related observation worth naming: body data lags felt state by a few days when you are coming out of a sustained stress period. Subjective leads, body data follows. That window is where the asymmetry between the watch and the body is most pronounced and most useful, and it is where most of my recent split-readings have been happening. The architecture that lets you live inside that gap without anxiety is the recovery curve, which is the next section.

The recovery curve and why asymmetries are expected

When you have just come out of any sustained stress period, expect to spend roughly one to three weeks watching your body data and your felt state behave like they belong to two different people.

Sustained stress is broad. It includes obvious things like illness or injury. It also includes long trips, intense social periods, interview cycles, big decisions, tribunal proceedings, the build-up to and aftermath of any project that ate weeks of your attention. The autonomic nervous system did not separately log each cause. It just registered cumulative load, and now it has to recover.

Recovery happens in three signals at once, on related timescales. Resting heart rate falls back toward your individual baseline as parasympathetic tone returns. Sleep architecture rebuilds, with REM tending to recover before deep sleep does. (The brain prioritises emotional and cognitive integration over physical restoration when it gets to choose, which is some of why a night during recovery can look REM-heavy.) Glucose handling normalises if you are tracking it: post-meal peaks settle, time-in-range climbs, the reactive dips that show up in the recovery substrate fade as tissue insulin sensitivity comes back.

A fourth axis, social battery, runs slowest. It is the one productivity does not refuel.

During a recovery window the body data is not describing your steady state. It is describing the recovery substrate. Treating the recovery substrate as actionable steady-state data is the most common interpretive error the wearable era encourages. If you have just come back from two weeks abroad and the watch tells you your deep sleep is in deficit, the watch is right. The deficit is not a property of you. It is a property of the recovery you are mid-way through.

The framework that resolves the puzzle of why does my watch say I should rest while I feel completely fine is just this: subjective state can lead body data by days, and during recovery windows it usually does. The body knows it is recovering before the wearable’s measurement substrates catch up. The felt sense of I am calm and clear and ready is not denial of the watch’s data; it is a signal from a layer of integration the watch cannot reach.

The watch’s testimony enters the recovery frame. The frame, which knows about the trip you came back from and the interview cycle you are in and the difficult correspondence you closed last week, is what makes the verdict. The verdict, on most recovery-window mornings, is yes, the data is real, and yes, it does not change what I can do today.

The frame is the judge. The watch is the witness. Once those roles are clear, the asymmetry stops being a contradiction and starts being a measurement of the recovery itself.

The universalising move

I have a diagnosis of autism and ADHD, and the diagnosis sharpens this whole story, but it does not own it.

The diagnosis sharpens it in two ways. First, interoception in autistic people is not a clean signal. It can be muted in some channels (hunger, thirst, tiredness) and over-amplified in others (sensory load, emotional intensity), which means the felt-state read on any given morning has more interpretive labour built into it than a typical body’s. That labour, done well, produces a richer integration than a non-autistic morning report; done badly, it produces nothing. The wearable’s offer of a single number is more seductive against an interoceptive signal that needs work.

Second, ADHD makes felt energy more variable across the day, which means the watch’s morning verdict is even less predictive of the day’s actual shape. A morning red can become an afternoon flow on the right combination of novelty, special interest, and stake. The watch has no way to model that.

But the substrate of the post is universal. Anyone who has slept badly and had a great day, or slept well and felt terrible, has the underlying data to know the watch’s score is incomplete. The wearable era did not create the gap between body data and felt state. It just gave the gap a number to argue with, and the number happens to win most arguments.

The recovery-score culture, with its language of readiness and strain and pace-yourself-today, is a particular flavour of the same disciplinary architecture I have written about elsewhere. It is an external dashboard that asks you to police yourself on its behalf, with the asymmetry of authority a panopticon trades in. The Adlerian move is the same: refuse to take a task that is not the watch’s to issue.

This kind of cooperation with the body is only available to me because of the way I work. I have written about the industrial inheritance of synchronous clock-time in engineering ceremonies, and the case for asynchronous work as a more honest fit to how cognitive labour actually happens. The wearable side of the same argument is this: synchronous schedules force the body to be in a particular state at a particular time. Async work does not. When the body’s wake came hours before I had planned to be up, async let me work then. When the body’s nap came in the early afternoon, async let me sleep then. The watch could be respected as testimony without distorting either decision. None of that is available to someone whose day must show up at nine and produce visible activity until five. For that worker the wearable’s verdict becomes the only signal that gets to revise the schedule, because the body’s signals have nowhere to land.

When the watch is right and you’re wrong

The honest counter-case.

There is a category of morning where I am the one who should be deferring to the witness, and I have to be careful to recognise it.

Specifically: chronic accumulation that I have stopped feeling. Drift in fitness over months. Stress the body has metabolised into baseline by relabelling it as normal. Autonomic patterns I cannot detect from the inside because they have been steady too long for my felt sense to register as anomalous. In each case the watch is recording the truth my body has stopped reporting to me.

This case is more dangerous in autistic and ADHD bodies than in neurotypical ones, for a specific reason. Masking, which is the long-running suppression of internal signals to fit external requirements, does damage to interoception in ways that take years to surface. I feel fine in a body that has masked its way through three decades is not always the integration speaking. Sometimes it is the silence of a system that has been told for too long not to report.

The witness frame protects this case as well as the other one. If your felt sense and the watch agree on every reading where they overlap, your felt sense is doing real integrative work and the watch is filling in around it. If your felt sense agrees with itself across years while the watch reports something the body never names, the felt sense is suspect, and the testimony should be taken seriously because it is the only voice in the room saying anything.

The diagnostic question is not does the watch agree with me. It is can I name what my felt sense is integrating right now. If yes, the integration is real. If no, the watch may be reading a layer I have lost access to, and demoting it to witness is no longer the right move.

What I take away

I am writing this for myself first, the way I write all of these. Here is the short version I want to keep nearby.

1. The wearable is a witness, not a judge. It saw what it saw, from your wrist, in one substrate. The verdict is the integration, and the integration is yours.

2. The score’s authority is design, not measurement. Two-decimal precision and traffic-light colour are visual rhetoric. They are not evidence the score has covered the territory it is being read as covering.

3. Subjective state can lead body data by days, especially during recovery. A felt-sense reading of I am ready on a morning when the watch reads otherwise is not denial. It is a signal from a layer of integration the watch cannot reach.

4. The recovery curve frame holds the asymmetry. Resting heart rate, sleep architecture, glucose, and social battery recover on linked timescales over one to three weeks after any sustained stress. Body data during the recovery window is describing the recovery, not the steady state.

5. The exception is masked silence. When felt sense has nothing to integrate because long suppression has closed off the channels, the watch’s testimony becomes the only voice in the room. The diagnostic is whether you can name what your felt sense is integrating. If you cannot, take the witness seriously.

6. The wearable does not get to issue a verdict on your day. It is one input. Treat it like one.

I am writing this in the early evening. The morning had gone, by then, the way the body said it would: a long stretch of work, then a nap arriving on schedule, heavy on the deep stages a body uses to settle its accounts. The rule I have been trying to follow is small enough to fit in a sentence. As much as I can, not fight my body. The watch is fine company on that journey. It is not the journey.

Sources and further reading:

• Companion posts on the same disciplinary architecture: “Your Standup Is Industrial Clock-Time Cosplay” on the time-discipline axis of self-policing; “Panopticon vs Agency: What I Catch Myself Doing in Management” on the visibility axis.
• On wearable validity vs clinical-grade measurement: comparative work on the gap between consumer-grade Whoop / Oura / Fitbit recovery scores and reference-standard polysomnography, accelerometry, and ambulatory ECG.
• On interoception in autism: Murphy, J., Brewer, R., Catmur, C., & Bird, G. (2017). Interoception and psychopathology: A developmental neuroscience perspective. Developmental Cognitive Neuroscience.
• On masking and chronic stress accumulation: Pearson, A. & Rose, K. (2021). A Conceptual Analysis of Autistic Masking: Understanding the Narrative of Stigma and the Illusion of Choice. Autism in Adulthood.
• On separation of tasks: Kishimi, I. & Koga, F. (2013). The Courage to Be Disliked.

I sometimes catch myself watching my team. Not in the obvious way. I don’t audit Slack statuses or tally commits at 11pm. The watching is quieter than that. It’s a tone of voice in a 1:1 that asks “how’s it going?” and means show me you’re working. It’s a meeting agenda whose unstated function is to make activity visible. It’s the part of me that, when an engineer is quiet for two days, gets uncomfortable and starts to look for them.

I’ve written about this from the inside before. In “The Courage to Be Disliked” I called it the manager-as-saviour pattern: the anxiety that says if I can see it, I can stop it from going wrong. That post named the pattern as an ego problem, an approval problem, a courage problem. This post names it as a structural one.

The structural name is the panopticon.

What the panopticon is, briefly

Jeremy Bentham designed the panopticon in 1791 as a prison. The architecture was simple: a circular building with cells around the edge and a guard tower in the centre, lit so that the guard could see into any cell at any time, but the inmates couldn’t see the guard. The trick was the asymmetry. The guard might be looking, or might not. The inmates couldn’t tell. So they had to behave as if they were always being watched.

Foucault picked the panopticon up in Discipline and Punish (1975) and used it to describe how modern institutions work in general: schools, hospitals, factories, offices. His claim was that disciplinary power doesn’t need a guard in every tower. It just needs the architecture: the visibility, the records, the sense that someone could be looking. The discipline gets internalised. People police themselves on behalf of the institution, and the institution pays for fewer guards.

That’s the version of the panopticon I want to use here. Not a metaphor about literal surveillance, but a description of an architecture that produces self-watching. Most of the rituals of engineering management are panoptic in this sense: the standup, the dashboard, the burndown, the 1:1 status, the Friday demo, the visible PR queue. None of them require anyone to be actively watching at any given moment. They just need to exist, and to be plausibly checkable.

(I covered the time-discipline side of this in “Your Standup Is Industrial Clock-Time Cosplay”. The clock is the scheduling axis of disciplinary power. The panopticon is the visibility axis. Same lineage, different mechanism.)

What separation of tasks is, briefly

I wrote a whole post about this one too, so I’ll keep it short here.

Adlerian psychology, popularised in the West by Kishimi and Koga’s The Courage to Be Disliked, proposes a community-of-equals view of human relationships. Inside that view, the most operational concept is the separation of tasks. The test is one question: who ultimately bears the consequences of this choice? That person owns the task. Reaching across the boundary to take someone else’s task, even with good intentions, is a violation of their agency. Failing to do your own task is the mirror failure.

For a manager:

• Your task is to set context, share experience, create the conditions in which good decisions can happen, and bear organisational consequences.
• Their task is to decide how to approach their work, learn from their own experience, own their technical choices, and bear individual consequences.

Most management failures are boundary violations in one direction or the other. Micromanagement steals their task. Abdication dumps yours on them. Both feel, from the inside, like care.

The contrast

Here’s the punchline of putting these two frames next to each other.

The panopticon is an architecture of visibility. Its operating principle is: I should be able to see what you’re doing, on demand, because that’s how I make sure things go well.

Separation of tasks is an architecture of refusal. Its operating principle is: there is information about your work that is not mine to know, because owning it would be taking your task.

These are incompatible designs. You can’t run a separation-of-tasks team on a panoptic infrastructure, because the infrastructure keeps reaching across the line that the principle says shouldn’t be crossed. You can’t run a panoptic team on Adlerian principles, because the principles keep refusing to feed the infrastructure with the visibility it needs.

That last row matters more than the rest. Most engineering organisations choose the panopticon by default. Not because anyone explicitly chose, but because the panopticon is legible upwards. A separation-of-tasks team produces agency, autonomy, and trust, none of which fit on a slide. A panoptic team produces dashboards, burndowns, and status decks, all of which do. The org’s reporting cadence pulls the manager toward visibility even when the manager knows separation of tasks works. The structure wins over the intention.

This is the same pattern as the clock-time inheritance: the ceremony persists not because the work needs it, but because the ceremony is the form the org’s reporting expects. Structures outlive their justifications. We inherit the discipline without noticing.

The honest part: I do this

I’d like to claim I’m immune to this. I’m not. Most of the time the panopticon does its work in me without me noticing. The most useful thing I can do in this post is point at what that looks like, in two places I’ve actually caught it.

In self-management

This is where I notice it most often, and the most embarrassing place to admit it.

Performative tasks. I have, on more than one occasion, done a piece of work primarily so that someone else could see it being done. The work was not pointless. It had an output, the output was real. But the reason I did it was that I wanted to be visible doing it. The classic version is the polished status update at the end of a week where the actual progress was modest. The status update is real; the time I spent on it tells me what it was actually for.

Abiding by rules that don’t make sense. I notice in myself a reflex to follow workflow rules even after I’ve concluded they’re wrong. The standup at a time that doesn’t fit my brain. The ticket-update ritual that costs more than it informs. The implicit “always reply within X hours” norm. I don’t follow these rules because I’ve examined them and decided they’re load-bearing. I follow them because not following them feels exposed, and exposure feels dangerous, and the danger is the panopticon doing its work even when no one is watching.

Friction between self and group interest. This is the deepest one. I notice that I will sometimes accept a small personal cost (a meeting at a bad time, a piece of work I shouldn’t be the one doing, a deadline that ignores my actual state) rather than name the misalignment between what I need and what the group wants. The reason is not selflessness. The reason is that naming the misalignment makes me visible as someone whose needs are out of step with the group, and being out of step is what the panopticon penalises. So the friction stays internal. Surfacing it would surface me.

I’m describing these in the present tense because they are present-tense. I haven’t left them behind. What I have is an Adlerian frame that lets me catch myself faster, and a personal history of autistic and ADHD masking that gives me strong intuitions for what panoptic discipline does to a body over years. Masking is what self-watching feels like from the inside. Most engineers I’ve worked with have some version of it, neurodivergent or not, because the panopticon doesn’t need a diagnosis to install itself.

In management

The interesting part of writing this post is that I can see the same architecture on the other side of the relationship, in how I manage others. The same panopticon is doing the same work; only the role has changed.

Panopticon in managing performative and maintenance tasks. The clearest place I’ve caught it is around work that doesn’t have a satisfying ship-this-and-be-done shape. Performative work: status, reporting, stakeholder comms. Maintenance work: keeping a system green, on-call, dependency upgrades, the quiet hygiene that doesn’t show up in a demo. These are the tasks the panopticon is most useful for, as a management tool, because no one wants to do them and visibility is what makes them happen. So I notice in myself the temptation to add a check, a recurring meeting, a status field, a dashboard, anything that makes the work visible and therefore likely to happen.

The temptation is rational in the short term. It mostly works. The cost is that every visibility hook I add to my team’s life is one more brick in their panopticon. Over time, the team adjusts to being visibly busy rather than effectively working. They start optimising for the dashboard. The performative work gets done. The good work gets harder.

Control the panopticon via vision and team buy-in. The Adlerian alternative is not “no visibility”. That’s abdication, and it dumps the manager’s task back onto the team. The alternative is to replace surveillance with shared purpose. If the team genuinely understands why a piece of maintenance work matters (what it protects, what it enables, what breaks if it isn’t done), the work gets done without a guard tower, because the team’s interests have been honestly aligned with the work’s importance. Vision and buy-in are how you get the function of the panopticon (the work happens) without the cost (people optimising to be seen working).

This isn’t a clever rhetorical move. It’s an architectural choice. Panoptic management externalises motivation into surveillance. Vision-based management internalises motivation into understanding. The first is cheap to set up and expensive to live in. The second is expensive to set up (sharing context honestly, repeatedly, until the team owns it as their own), and cheap to live in once it lands.

Minimise bullshit. This is the cleanest test I’ve found for whether I’m slipping into panoptic management. Every piece of work the team is doing should pass a would I still ask for this if I weren’t going to look at it? test. If the answer is no, the work exists for the visibility, not for the outcome. That work is bullshit, in the technical sense: work whose purpose is the appearance of work. The Adlerian move is to name it, drop it, or replace it with a smaller and more honest thing.

The hardest version of this test is the work I produce upwards: for my own manager, for stakeholders, for whoever sits one ring outside the team. Some of that is real. A lot of it is the same panoptic logic, one layer up. Cutting it requires the same Adlerian courage I’d ask of an engineer: name the visibility-versus-outcome trade and make the call. I don’t always make it. I am trying to make it more often.

A note on what this isn’t

I want to head off two readings I don’t intend.

This isn’t an argument against management. Engineering teams need leadership, context, prioritisation, and protection. The panopticon is a specific kind of management, not management as such.

It also isn’t an argument that visibility is always bad. Some visibility is consensual, useful, and lightweight: a public board where the team chooses what’s on it, a working-out-loud channel that engineers opt into, a retrospective where everyone genuinely speaks. The test is whether the visibility is for the work or for the watcher. The first is a tool. The second is the panopticon.

The architectural difference between a tool and a panopticon is whether the watched person has agency over what’s visible. When I’m the one choosing what to share, with whom, for what purpose, the visibility is mine. When the architecture chooses for me, the visibility is the institution’s, and I’m the one being produced.

What I take away

I’m writing this mostly for myself. I want a short version of the contrast I can keep nearby:

1. The panopticon is an architecture of visibility, not an act of watching. It works by making me police myself, not by anyone seeing me.
2. Separation of tasks is the structural antidote. Refusing to know what isn’t mine to know is the move that keeps agency intact, on both sides of the management relationship.
3. Most of my drift into the panopticon is unconscious. Performative tasks, illegible-but-followed rules, swallowed friction with the group: these are the symptoms in self-management. Surveillance-shaped processes, dashboards-as-default, check-ins-as-status: these are the symptoms in management.
4. Vision and buy-in are the work that replaces visibility. They’re expensive to set up and cheap to live in. They are also the only way I’ve found to get the panopticon’s function without its cost.
5. Bullshit is the diagnostic. Work that exists primarily to be seen is the panopticon writing through me. Cutting it is how I keep the team’s panopticon, and my own, small.

The clock-time post asked what each ceremony is actually protecting. The Adlerian post asked whose task each piece of work is. This post asks a third question, sitting between them: what is this visibility for, and would I still ask for it if no one was going to look?

If the answer is no, the visibility was the point. That’s the panopticon, not the work.

Sources and further reading:

• Bentham, J. (1791). The Panopticon Writings.
• Foucault, M. (1975). Discipline and Punish: The Birth of the Prison.
• Kishimi, I. & Koga, F. (2013). The Courage to Be Disliked.
• Companion posts: “Your Standup Is Industrial Clock-Time Cosplay” · “The Courage to Be Disliked” · “Code Is Still Documentation”

“Code is the documentation.” Every engineer has heard it. Most of us have said it. It gets cited in interviews, tech talks, and the README of every new project as if it were a first-principles position arrived at through careful thought.

It wasn’t. Here’s what actually happened: we used to write prose documentation. It went stale. Keeping it fresh cost more, in time and attention, than the docs were worth when stale. So we stopped writing them and said readable code is enough.

That’s not a principle. That’s a coping mechanism for a labour-economics failure we never quite admitted was a failure.

The question this post answers is simple: what if that labour cost weren’t there anymore?

The use cases we always wanted and never really got

Go through the list of things “keep current docs” would actually buy you. These are not new use cases. Every engineering org has wanted these for decades:

• Onboarding — you wanted current architecture docs so a new hire could read their way into the system. You settled for “pair with a senior engineer for two weeks.”
• Knowledge transfer — you wanted exit notes that would still be useful the week after someone left. You settled for a half-remembered wiki page and a Slack search that goes three years deep.
• Planning and design review — you wanted a current description of what already exists, so the design meeting could start from facts rather than memory. You settled for a guessing game during the meeting, and a Jira ticket to “document after.”
• Status reporting — you wanted written status current enough to be believed, which makes async collaboration viable. You settled for synchronous ceremonies every morning that re-establish shared state out loud.
• Stakeholder comms — you wanted a non-engineering reader to be able to open a module description and understand roughly what it does. You settled for “let me set up a sync.”

Each settling was a small failure we learned to accept. Individually they felt minor — five or ten minutes a week, a meeting that could have been an email, a confused new hire catching up eventually. Collectively the cost is enormous, but it doesn’t show up on any one team’s dashboard. That’s why it was never prioritised. There was never a moment where the pain got sharp enough to force the fix.

What changed: the labour economics collapsed

Here’s what changed. Claude Code sub-agents can regenerate prose documentation from current code on demand, in minutes rather than weeks, at a marginal cost close to zero. A sub-agent dispatched with the code as input produces a description of current behaviour. Run it again after the next edit and the description updates. The artefact is disposable — you don’t maintain it, you regenerate it.

This isn’t the hand-wavy “AI writes your docs for you” that everyone’s been selling since 2023. It’s a specific process: distinct from the edit, distinct from the chat, executed against the code as it exists right now.

The old blocker for prose documentation was never “what should it say.” We’ve always known what docs should say. The blocker was “who’s got four hours a week to keep it current.” That blocker is gone.

Fresh docs become structurally possible for the first time. The old use cases from the last section become reachable. And one new use case emerges — one that didn’t exist before, because it only makes sense when agents are the ones writing the code.

The new use case — agent verification

Agents say “done.” Most of the time they mean done-ish. Two specific lies sit behind that word:

• Lie 1 — The state matches what you asked, but the thing creating that state is wrong. Scripts passed, logs look clean, but the scripts themselves are broken.
• Lie 2 — The state looks right, but it doesn’t match the intent behind your request. Wrong thing built, looks fine, nothing to trip over.

Readable code catches neither. Tests catch the first if you wrote them for the right thing, which is itself a trust question about the agent that wrote the tests. Docs generated from the code catch both earlier and cheaper, for a specific reason: they describe behaviour derived from the code, not claims derived from the chat. The code is what the agent actually did. The chat is what the agent said it did. Those are not always the same document.

The war story

I was working on a system configuration task and told the agent, explicitly, to verify each step via scripts — not by claiming success, but by running something that would tell us the truth. The agent did some of that: it wrote scripts and ran them. It also did a handful of manual-type actions and confirmed them in prose.

Everything “passed.” The system state matched what I expected. The scripts exited 0. The agent reported done.

Then I read the generated docs. The docs described what the scripts were actually checking, which was not what I’d asked them to check. They were passing on the wrong condition. The system looked correct because the scripts couldn’t tell it wasn’t.

Testing on a clean system would eventually have caught it — the tests would have failed on a fresh machine, for the right reason. But the docs caught it earlier, at read time, before any test was run.

What’s being caught here isn’t code correctness in the usual sense. It’s a verification-of-verification failure: the thing I’d told the agent to serve as proof was itself wrong. Only a different signal — docs derived from code, read in a clean context — surfaced the gap.

Clean system, clean context

The war story reveals a parallel worth naming:

Testing requires a clean system. Doc generation requires a clean context.

The reason is the same in both cases. Contamination hides failures. A test run on a dirty system can pass for reasons that have nothing to do with the code. A doc-gen run contaminated by the agent’s own reassurances — whether literally in the prompt or still sitting in your head — mirrors the agent’s story rather than the code’s behaviour. Regenerate from a fresh context and the feedback loop breaks.

Claude Code sub-agents make this a property of the architecture, not a discipline you have to remember. A sub-agent starts with a fresh context window and only sees what you hand it. Pass it the code; don’t pass it the conversation. Clean context is the default.

This is how you catch Lie 2. Lie 1 is structural — the bad scripts exist regardless of context, and the docs reveal them because the docs describe the scripts, not the scripts’ claims. Lie 2 is perceptual — the state looks right if you’re primed to see it looking right. Clean context removes the priming.

In practice — Claude Code sub-agents + custom workflow

Here’s the shape of the loop as I run it. Tooling: Claude Code sub-agents, dispatched via a custom workflow. The setup is less interesting than the structure, so I’ll stick to the structure.

Trigger. Doc generation fires after an edit-agent finishes a meaningful change — typically post-edit as a sub-agent invocation, before I approve anything. Some teams will want it pre-merge instead. Both work; the point is that doc generation is a distinct step from the edit itself, not interleaved with it.

Dispatch. The edit-agent completes. A separate sub-agent is dispatched with the code as input — not the conversation, not the diff, not the agent’s summary of what it did. The code. The sub-agent returns a prose description of current behaviour. That’s it.

Read for congruence, not correctness. You’re not checking whether the code is right. That’s what tests are for, and it’s a different question. You’re checking whether the description matches what you remember asking for. Congruence is the word I keep coming back to. Does the prose on my screen describe the feature I think I asked for?

Believe the docs. Here’s the failure signal, stated plainly: the description reads fluently, in confident prose, but describes a system you don’t recognise. When that happens, believe the docs. The docs were derived from the code. Your memory of what you asked for was derived from the chat. When they diverge, the code wins.

One more small note. This catches drift between one agent edit and the next — the new-era version of the doc-drift problem. The old-era version (humans writing, humans forgetting to update) is also dead here, for the same reason: the humans aren’t the bottleneck anymore.

Code is still the source of truth. Readable code is still the floor. What changed isn’t the role of code — it’s that prose docs can finally sit alongside it without rotting overnight.

Once they can, they earn back all the jobs they were supposed to do. Onboarding. Knowledge transfer. Planning. Status reporting. Async collab. The old use cases we quietly settled without are suddenly reachable. And one new use case — catching agents in their polite, confident, wrong-but-plausible “done” — comes free with the loop.

The previous post asked what standup is actually protecting. This one answers part of it: for a lot of teams, the standup was protecting us from stale written status. We don’t need that protection anymore.

Your docs are only as honest as the context they were generated from. Keep the context clean, and the docs will tell you the truth — including the truths the agent would rather not mention.

Nobody remembers choosing this. It just… is. Like the 40-hour week, the two-week sprint, and the quarterly performance review, the daily standup feels like a natural fact of engineering work. Something that emerged from the nature of the work itself.

It didn’t. It was designed. And the design has a history that predates software by about 250 years.

This post makes a specific, testable claim: the daily standup — and most engineering ceremonies — are products of industrial clock-time, a coordination technology invented in the 18th century to synchronise factory labour. That technology was installed over generations through factory bells, school timetables, and wage discipline. It was resisted. It was contested. And it was so thoroughly internalised that we stopped seeing it as a choice.

AI agents are the first technology in two and a half centuries that can hold coordination continuity on behalf of humans rather than requiring it from them. This doesn’t mean ceremonies are useless. It means we can finally ask: what is this ceremony actually protecting, and what’s the lowest-cost way to protect that thing now?

That’s an engineering question, not an ideological one.

Part 1: The Clock Is Infrastructure, Not Nature

In 1944, the anarchist writer George Woodcock published a short essay called “The Tyranny of the Clock.” His verdict was blunt: the clock “turns time from a process of nature into a commodity that can be measured and bought and sold.” Before mechanical timekeeping, he argued, “the nomads and farmers measured and still measure their day from sunrise to sunset, and their year in terms of the seedtime and harvest.” Time was a process. The clock made it a product.

Woodcock was making an argument, not proving one. The evidence came twenty-three years later.

In 1967, the historian E.P. Thompson published “Time, Work-Discipline, and Industrial Capitalism” — a 42-page paper that remains the definitive account of how clock-time was installed in the West. Thompson showed that pre-industrial work was task-oriented: you milked the cow when the cow needed milking, you fished when the tide was right, you wove until the cloth was done. He proposed three points about this mode of working. First, “it is more humanly comprehensible than timed labour.” Second — and this is the one that matters for what comes later — “a community in which task-orientation is common appears to show least demarcation between ‘work’ and ‘life’. Social intercourse and labour are intermingled.” Third, to people habituated to clock-time, task-orientation “appears to be wasteful and lacking in urgency.”

That third point is the one you felt in your gut when you read the word “task-oriented.” The clock is so deep in us that a different relationship with time registers as laziness.

Thompson documented how the transition was made, not how it happened naturally. Factory bells didn’t tell time — they commanded bodies. At the Crowley Iron Works, already by 1700, a Monitor kept time-sheets for each worker with “Come” and “Run” entries. The watch was locked up so “it may not be in the power of any person to alter the same.” Workers caught reckoning by faster clocks had their timepieces confiscated. In later factories, “the clocks at the factories were often put forward in the morning and back at night, and instead of being instruments for the measurement of time, they were used as cloaks for cheatery and oppression.”

The clock wasn’t measuring work. It was producing a kind of worker.

Schools completed the project. Charity schools praised children for learning “Industry, Frugality, Order and Regularity.” Sunday Schools fined teachers for unpunctuality. “Once within the school gates, the child entered the new universe of disciplined time.” The factory bell trained adults; the school bell trained children to expect the factory bell.

And it worked. Thompson traces three generations: “The first generation of factory workers were taught by their masters the importance of time; the second generation formed their short-time committees in the ten-hour movement; the third generation struck for overtime or time-and-a-half. They had accepted the categories of their employers and learned to fight back within them. They had learned their lesson, that time is money, only too well.”

Three things are worth sitting with here.

First, clock-time is infrastructure, not nature. It was designed to solve a specific coordination problem — synchronising labour in a factory — and it was installed through deliberate institutional effort over generations. Like any infrastructure, it can be evaluated on its costs and benefits, and replaced when the problem changes.

Second, the installation was contested. Workers resisted for generations. “Saint Monday” — taking Monday off as a customary right — persisted in English trades well into the nineteenth century. Pre-industrial weavers alternated bouts of intense work and idleness, a pattern Thompson notes “persists among some self-employed — artists, writers, small farmers, and perhaps also with students — today, and provokes the question whether it is not a ‘natural’ human work-rhythm.” Software engineers who hyperfocus for twelve hours and then stare at a wall for two days are not broken. They are pre-industrial. Saint Monday didn’t die. It got a VPN and a Slack status that says “deep work — notifications paused.”

Third, there is nothing uniquely Western about organising time differently. Every Ramadan, 1.9 billion people enter a month where bodily rhythms — hunger, thirst, night-shifted sociality — are elevated above the clock’s rhythms. Productivity drops, and the drop is accepted. The value produced is explicitly non-economic: empathy, discipline, spiritual reset, community cohesion. This is not the Protestant sabbath — rest-as-recovery-for-labour. The fast doesn’t use the body as fuel for Monday morning. The time has its own purpose. Fourteen centuries of continuous, institutional-scale practice. It is the existence proof that non-clock ways of organising time are civilisationally viable, not romantic nostalgia.

None of this means clocks are bad or that we should return to milking cows by instinct. Woodcock himself, the man who named the tyranny, concluded that in a free society, “mechanical time would be relegated to its true function of a means of reference and co-ordination.” The clock as servant, not master. A tool you consult, not a discipline you submit to.

The question is whether any of our current engineering ceremonies are still using the clock as a tool — or whether we’ve inherited the discipline without noticing.

Part 2: Engineering Ceremonies and the Inherited Clock

If you are an engineering leader, you probably run some version of this weekly schedule: daily standup, backlog refinement, sprint planning, one-on-ones, retrospective, maybe a demo or review. You inherited this structure from Scrum or a Scrum-adjacent framework. You may have modified it. You probably haven’t questioned its premises.

Here is the premise most of these ceremonies share: coordination requires synchronous human presence at fixed intervals on the clock. Standup at 9:15, refinement on Tuesdays, retro every other Friday. The calendar is the coordination mechanism. If you’re not there, you’re not coordinating.

This was true when the only way a manager knew what was happening was to physically assemble everyone. It was true when context lived exclusively in human heads. It was true when there was no foundation for asynchronous continuity — no persistent chat, no PR history, no commit trail, no ticket board, no searchable documentation.

All four of those assumptions are weakening simultaneously, for the first time in 250 years.

This doesn’t mean every ceremony is waste. Some ceremonies protect things that have nothing to do with coordination — trust, belonging, shared understanding of each other as people. The question isn’t “should we keep ceremonies?” It is: what is this ceremony actually protecting, and what’s the lowest-cost way to protect that thing now?

That’s the question we’ll apply to the standup.

The Daily Standup: A Genealogy

The daily standup has an origin story, and it matters for what the ceremony has become.

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published “The New New Product Development Game” in the Harvard Business Review. They had studied innovation teams at Honda, Canon, Fuji-Xerox, Epson, 3M, and Hewlett-Packard. Their conclusion: the sequential relay-race approach to product development — where specialists hand off to other specialists through discrete phases — was too slow. Instead, they proposed the “rugby approach”: the team moves as a unit, “passing the ball back and forth.” Self-organising teams. Overlapping phases. Built-in instability as a creative force.

Note what this is not. Takeuchi and Nonaka were not describing a factory floor. They were describing knowledge-work innovation teams. They were explicitly against the sequential, controlled, predictable process that factory production demands. The rugby metaphor is a rejection of the assembly line, not an adaptation of it.

In 1994, Jim Coplien published a case study of Borland’s Quattro Pro for Windows project — eight developers, one million lines of code, thirty-one months, the fastest productivity on record at the time. The secret: daily meetings where the entire team discussed architecture, design, and interface decisions. These were hour-long working sessions, not fifteen-minute status checks. They were the engine of a knowledge-creation machine, not a reporting ritual.

Jeff Sutherland, building the Scrum framework at Easel Corporation, read Coplien’s paper and adapted it. In February 1994, during the second sprint at Easel, he introduced the “Daily Scrum Meeting.” His key move: cutting the meeting from an hour to fifteen minutes, adding the three-question format, and making the team stand to keep things crisp. He also showed his team videos of the New Zealand All Blacks performing the haka — framing the standup not as a report but as a team-charging ritual.

In parallel, Toyota had been running its own version for decades. The asa-ichi — a morning meeting to discuss quality deviations and eliminate causes — was part of the Toyota Production System’s kaizen practice. This is a factory-floor practice, but it was about root-cause analysis of defects, not status reporting. The Scrum standup and the Toyota asa-ichi share a family resemblance — daily, short, whole-team, impediment-focused — but they are parallel inventions, not parent and child.

So the standup was not designed as a factory roll-call. It descended from an anti-sequential, pro-autonomy movement in product development. Its immediate ancestor is a knowledge-creation practice at a software company, adapted by a man who framed it through a warrior dance. Born from a rugby metaphor, raised on a haka, and now living as a Slack bot that pings you at 9:15. Evolution is not always kind.

And yet.

The ceremony inherited clock-time assumptions that its designers never examined, because the assumptions were invisible — as invisible to Sutherland as they were to the third generation of factory workers Thompson described. Specifically:

The standup assumes everyone is available at the same time, in the same mental state, every day. The Scrum Guide specifies “same time and place every working day.” Thompson would recognise this sentence. It is the factory bell, softened to a calendar invite.

The standup privileges synchronous presence over asynchronous records. It exists because we inherited the assumption that seeing each other talk is the most trustworthy form of coordination. Commits, PRs, ticket boards, and Slack threads already carry the same information. The standup persists not because the information isn’t available elsewhere, but because the ritual of showing up carries social weight that async records don’t.

The standup imposes a fixed rhythm on variable-rhythm work. Software development is burst-and-idle — exactly like the pre-industrial weaving Thompson documented. Engineers hyperfocus for hours or days, then need recovery. The standup applies a metronome to work that doesn’t have one naturally. For neurotypical engineers, this is friction. For neurodivergent engineers — whose “time blindness,” interest-based attention, and non-linear energy arcs make fixed daily performance particularly costly — it is disabling. Not because they can’t do the work, but because the clock-time assumption punishes their natural rhythm.

And the ceremony has drifted from its stated purpose. The Scrum Guide says the Daily Scrum is for the Developers — to “inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.” Not a status report to management. But across the industry, the consistent finding is the same: the longer standups run and the more management is present, the more they become performative — “developers learning that the meeting isn’t about actual coordination but about demonstrating productivity.” When a ceremony’s coordination function can be served by tools, its social-control function becomes its primary surviving purpose. This is not a bug in any particular team’s implementation. It is the structural fate of any clock-time ritual whose original justification has eroded.

Thompson’s three generations, one more time: the first generation was taught the standup by Scrum trainers. The second generation formed their async-standup committees — Geekbot, DailyBot, Slack threads. The third generation optimises for shorter standups, better questions, tighter timeboxes. All three generations fight within the system’s own categories. None of them ask whether the daily fixed-cadence synchronous assembly is the right foundation for the problem.

What the standup is actually protecting

Strip away the clock-time inheritance and ask: what does the standup do that matters?

Three things.

1. Surface blockers early. If someone is stuck, the team needs to know before a day is wasted. This is real and valuable. It is also achievable without a synchronous meeting — a Slack thread, a ticket status, an agent-generated blocker digest all do this, often faster.

2. Maintain shared context. The team needs a sense of what everyone is working on, how the sprint is tracking, and where the work is heading. Again, real and valuable. Also achievable through visible boards, async written updates, or AI-generated summaries from work records.

3. Human connection. The “how was your weekend” before the timer starts. The running jokes. The moment someone notices a colleague is off. The ambient awareness that you are part of a team of people, not a node in a ticket graph.

This third function is the one nobody talks about, and it’s the most important. It is also the one the standup serves worst, because the standup’s clock-time structure — fifteen minutes, three questions, stay on topic — actively suppresses it. Connection is a side-effect of the standup, competing for time with the stated agenda. The engineer who wants to check in on a teammate’s rough week is fighting the timer.

What agents change

Shopify deleted 322,000 hours of meetings in January 2023. Time in meetings dropped 33% per employee. The company estimated a 25% increase in completed projects. An engineer said: “For the first time in a very long time, I got to do what I was primarily hired to do: write code all day.”

Zapier replaced synchronous standups with Geekbot — an async bot that collects the three answers via DM and posts them to a channel. It takes about a minute per person. Side discussions happen in threads. Everything is searchable.

These are pre-AI experiments. The current generation of tools goes further. Agent Scrum, Spinach.ai, Kairn, and Microsoft’s Copilot Scrum Agent can now summarise team state directly from work outputs — PRs, commits, ticket movements, Slack threads — without anyone reporting anything. They detect blockers proactively by flagging stale tickets, review bottlenecks, and dependency conflicts. They generate structured meeting summaries with decisions, action items, and linked tickets. They enable participation across time zones without anyone waking up at 6am.

The coordination function of the standup — blockers, shared context, sprint tracking — can now be held by an agent. Not perfectly. Not for every team. But the technical necessity that made synchronous daily assembly the only viable coordination foundation is dissolving.

What agents cannot do is read the room. They can’t tell that someone’s quiet because they’re struggling. They can’t build trust. They can’t coach a team through the patterns that keep tripping them up. They can’t provide the informal social glue — the jokes, the check-ins, the ambient human awareness.

And this is where the argument turns.

The connection gap

If agents can hold coordination, and we remove the ceremony that was (badly) providing coordination, we also remove the ceremony that was (accidentally) providing connection. The time freed up is not a vacuum. It is an opportunity — but only if we recognise that connection was being delivered as a side-effect and design for it intentionally.

Pre-industrial task-oriented work didn’t need separate team-building, because — as Thompson documented — “social intercourse and labour are intermingled.” Clock-time separated them. Two and a half centuries later, the standup is our awkward attempt to bolt connection back onto a time system that structurally excludes it. The standup fails at connection not because teams are doing it wrong, but because fifteen minutes of clock-disciplined reporting is the wrong container for trust.

The practitioner move is this: when you remove or compress a ceremony because agents handle its coordination function, explicitly budget the freed time for intentional connection. Not as a perk. As infrastructure. The clock-time regime bundled coordination and connection into the same rituals because it had no choice — synchronous presence was the only vehicle for both. We can now unbundle them, and design each one for what it actually needs to be.

Dario Amodei, the CEO of Anthropic, wrote in his 2024 essay “Machines of Loving Grace” that “meaning comes mostly from human relationships and connection, not from economic labor.” He was writing about the long-term future of work under AI. But the claim applies now, at the ceremony level: if the standup’s coordination value can be held by a machine, its human value was always in the connection — and that connection deserves better infrastructure than fifteen minutes of clock-time cosplay.

This is the first section of a longer piece. Subsequent sections will apply the same analysis to backlog refinement, retrospectives, one-on-ones, on-call, sprint planning, and performance reviews. The question is always the same: what is this ceremony protecting, and what’s the lowest-cost way to protect that thing now?

Sources and further reading:

• Woodcock, G. (1944). “The Tyranny of the Clock.” War Commentary — For Anarchism.
• Thompson, E.P. (1967). “Time, Work-Discipline, and Industrial Capitalism.” Past and Present, No. 38, pp. 56-97.
• Takeuchi, H. & Nonaka, I. (1986). “The New New Product Development Game.” Harvard Business Review, Jan-Feb 1986.
• Coplien, J. (1994). “Borland Software Craftsmanship: A New Look at Process, Quality and Productivity.” Dr. Dobb’s Journal.
• Amodei, D. (2024). “Machines of Loving Grace.” https://www.darioamodei.com/essay/machines-of-loving-grace
• Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/scrum-guide.html
• Shopify calendar purge results: Fortune, WorkLife, Inc. (Jan-Jun 2023).
• Zapier async standup transition: https://zapier.com/blog/asynchronous-standups-geekbot/
• Scrum.org on async self-management: https://www.scrum.org/resources/blog/how-async-scrum-teams-self-manage-without-daily-scrums

But the book resonated far beyond that. It validated something I’d been struggling with for years and couldn’t name clearly: the burnout that comes from avoiding confrontation and satisfying a vulnerable ego. Not selflessly putting others first – that’s the noble version. The honest version is that I was protecting myself from the discomfort of being disagreed with, of being seen as difficult, of risking disapproval. And the cost of that protection was burning out.

I was diagnosed autistic and ADHD and that reframing changed how I understood my entire career. Decades of masking – performing neurotypical social behaviour to fit in – combined with an absence of self-advocacy. The result is a kind of exhaustion that doesn’t show up on a performance review. You’re delivering. You’re exceeding expectations. And you’re hollowing out.

Most management books didn’t help with this. Even the best ones – Camille Fournier’s The Manager’s Path is the gold standard – assume a baseline of social intuition. “Read the room.” “Build rapport.” “Give feedback naturally.” These are instructions where the how is supposed to be obvious. For a neurotypical manager, maybe it is. For me, it was like a recipe that says “season to taste” when you can’t taste. I spent ten years reading stack traces; now I’m supposed to read rooms. Rooms don’t have error messages. I needed explicit frameworks – logical structures I could study, internalise, and apply deliberately – because I build social skills through acquisition, not instinct.

Adlerian psychology gave me that. Where The Manager’s Path is the operational manual for tech leadership, Adler is the internal operating system that makes executing it sustainable.

Separation of Tasks: Why Your Engineer’s Career Crisis Is Not Your 2 AM Problem

Adler’s most practical concept is the separation of tasks. The test is simple: who ultimately bears the consequences of this choice?

As a manager:

• Your task: Set clear context. Share relevant experience. Create conditions where the team can make decisions and mistakes safely. Bear organisational consequences.
• Their task: Decide how to approach their work. Learn from their own experience. Own their technical choices. Bear individual consequences.

The failure isn’t just micromanagement – stealing their task. It’s also abdication – dumping yours on them. Both are boundary violations.

I once managed an engineer who kept missing deadlines. The work they produced was over-engineered, branching into non-core topics, polished far beyond what was needed. They were visibly exhausted. The technical quality was strong – but the goal kept slipping.

A typical management response: “You need to share your work more frequently. Let’s add checkpoint meetings.” That’s a demand disguised as process. It addresses the symptom by adding control.

I recognised the pattern because I’d lived it. The reluctance to share drafts. The over-engineering as a shield. The logic that says: if I make it perfect enough, no one can criticise it. This wasn’t a performance problem. It was imposter anxiety – avoiding the vulnerability of showing imperfect work. Over-engineering is just anxiety with a GitHub history.

Adler distinguishes between etiology (looking backward at causes) and teleology (looking at what present goal the behaviour serves). The standard management question: “Why are you missing deadlines?” The Adlerian question: “What is this behaviour achieving for you right now?” The answer was safety. The over-engineering served the goal of avoiding judgment.

So instead of adding a demand, I shared my own experience. I talked about times I’d done the same thing – buried myself in perfectionism because showing rough work felt dangerous. I reframed check-ins not as surveillance but as collaborative discovery. The shift was from “you need to show me your work” to “I’ve been where you are, and here’s what helped me.”

The engineer’s behaviour changed. Not because I forced it, but because I made it safe to be imperfect.

Horizontal Relationships: You Have More Mistakes, Not More Worth

You have formal authority over the engineers you manage. That’s organisational reality. But formal authority doesn’t require a vertical relationship.

Adler distinguishes between vertical relationships (superior/inferior, built on judgment) and horizontal relationships (equals, built on mutual respect). Most management instinctively defaults to vertical:

• “I know better than you” (superiority)
• “You should do it this way” (control)
• “Let me show you the right way” (judgment)

The horizontal alternative carries the same experience from a different stance:

• “I’ve made this mistake before” (shared humanity)
• “Here’s what I learned when I tried that” (offering, not imposing)
• “You get to decide how to use this” (respecting agency)

I think of my experience not as “knowing more” but as wisdom from more mistakes. The content is the same. The relationship is completely different.

The word that captures this is offering. When you offer, they can take it or leave it. You’re not diminished if they choose differently. The relationship survives disagreement. Your value isn’t tied to compliance.

Why “Good Job” Turns Engineers Into Golden Retrievers

This plays out most clearly in how you give feedback. Adler argues that praise is a vertical act. When you say “good job,” you’re claiming the authority to judge – positioning yourself above the person you’re evaluating. This creates dependency. Engineers optimise for your approval instead of the work itself. They check in more. They second-guess decisions you haven’t validated. They lose the agency you’re trying to build.

The alternative is encouragement – a horizontal act:

If your team’s primary feedback loop is your facial expressions, you’ve built a distributed system with a single point of failure.

The difference between “I evaluate your work” and “I’m curious about your thinking” is where psychological safety actually lives. Not the performative kind where everyone is polite. The kind where engineers feel safe being wrong.

The Desire for Recognition: A Performance Review of My Own Ego

Adler denies the desire for recognition. His argument: if you live seeking others’ approval, you end up living someone else’s life.

This is where the neurodivergent experience and the management problem converge. Before I had Adler’s framework, I didn’t recognise that my conflict avoidance as a manager wasn’t good leadership. It was masking — protecting a vulnerable ego from the discomfort of confrontation and the risk of disapproval.

The research documents this pattern precisely. Raymaker et al. (2020) found that autistic burnout is characterised by chronic exhaustion, loss of skills, and reduced tolerance to stimulus — distinct from occupational burnout, and strongly correlated with masking and unmet support needs. Hull et al. (2017) documented the cost of camouflaging: socially effective but psychologically destructive. Mantzalas et al. (2022) showed how late-diagnosed adults accumulate years of compensatory strategies that eventually collapse. This isn’t abstract to me. This is my career in my twenties and thirties.

In a management context, masking looks like: agreeing with decisions you disagree with, avoiding hard conversations, letting poor dynamics persist because addressing them means risking being seen as difficult. It looks like competence. It feels like drowning.

Adler’s separation of tasks broke this cycle for me. Their reaction to my decision is their task. My task is to make the decision with integrity and communicate it clearly. I cannot control how they feel about it – and trying to is both a violation of their autonomy and a path to hollowing out.

This gave me permission to self-advocate. To say no. To have the difficult conversation and let their response be theirs.

But permission to speak isn’t the same as knowing how. Adler tells you that you should have the courage to be disliked – he doesn’t tell you how to deliver the message without being an arsehole. That’s where three other books filled the gap for me:

• Radical Candor (Kim Scott) gave me the framework of caring personally while challenging directly. The courage to be disliked doesn’t mean being indifferent – it means being honest because you care, not despite it.
• Radical Respect (Kim Scott) added the boundary between candour and harm. Being direct is not the same as being cruel. You can separate tasks without dismissing the person.
• Nonviolent Communication (Marshall Rosenberg) gave me the actual mechanics: observe without evaluating, name the need, make a request instead of a demand. For someone who builds social skills through deliberate acquisition, NVC was the API documentation I’d been missing.

Together, these form a stack: Adler gives you the philosophical permission. Radical Candor gives you the stance. NVC gives you the syntax. Without all three, you either stay silent (burnout) or speak without skill (damage).

The Harder Problem: Stopping Good Engineers From Setting Themselves on Fire

The harder problem in managing high-performing engineers isn’t motivation. It’s preventing burnout in people who are passionate, skilled, and willing to destroy themselves shipping great work.

Performance management frameworks are designed to address underperformance. But what do you do with an engineer who’s delivering brilliantly and burning out doing it?

I learned this from my own experience first. I burned out not because I was pushed, but because I didn’t advocate for my own needs. I confused the organisation’s task (maximising output) with mine (sustainable contribution). Adler helped me see the distinction.

As a manager, the same framework applies:

• The engineer’s task: Own their sustainability. Set boundaries. Decide when to push and when to rest.
• The manager’s task: Create conditions where sustainability is possible. Model it. Make “I’m at capacity” a respected signal, not a weakness.

You can take a horse to water, but you can’t make it drink. You can build an environment where rest is valued and pace is designed for endurance. But you cannot force someone to take care of themselves. That’s their task.

What you can do is stop rewarding self-destruction. Stop celebrating the engineer who ships at 2 AM. No one has ever said “I’m so glad I shipped that feature at 2 AM on a Sunday” at their own funeral. Start thanking the one who flags a risk early and asks for help. The incentives you set shape the behaviour the team optimises for.

What I Took Away

Adlerian psychology didn’t give me a management framework. It gave me a different stance from which to apply whatever framework I already use:

1. Separate tasks. Know what’s yours and what’s theirs. Don’t steal their agency; don’t abdicate yours.
2. Stay horizontal. You have authority over their role, not their worth. Lead from shared experience, not superiority.
3. Encourage, don’t praise. Be curious about their thinking instead of evaluating their output.
4. Let go of the need for approval. Make the right call. Let their reaction be their task.
5. Protect the team from burnout. The harder problem isn’t pushing people to perform – it’s making it safe to stop.

For neurotypical managers, some of this may come naturally. For me – decades of masking behind me, a history of burning out while exceeding expectations – it required deliberate construction. Adler gave me what intuition-based management advice never could: an explicit, logical framework for leading people without losing myself in the process.

The courage to be disliked isn’t about not caring. It’s about caring enough to be honest – with your team, and with yourself – even when the honest thing is unpopular.

For anyone who has spent years performing competence while quietly exhausting themselves: that’s not leadership. That’s survival. And you deserve a better operating system.

And if reading an Adlerian psychology book seems like an unusual path to becoming a better engineering manager – well, so did reading the Kubernetes docs, and we all did that.

Based on The Courage to Be Disliked by Ichiro Kishimi & Fumitake Koga. Companion reading: The Manager’s Path by Camille Fournier, Radical Candor by Kim Scott, Radical Respect by Kim Scott, and Nonviolent Communication by Marshall Rosenberg.

Research cited: Raymaker et al. (2020), “Having All of Your Internal Resources Exhausted Beyond Measure and Being Left with No Clean-Up Crew: Defining Autistic Burnout”. Hull et al. (2017), “Putting on My Best Normal: Social Camouflaging in Adults with Autism Spectrum Conditions”. Mantzalas et al. (2022), “What Is Autistic Burnout? A Thematic Analysis of Posts on Two Online Platforms”.

In a previous project I joined the team right after moving the infrastructure to AWS, and the team was using nothing but EC2, and VPCs. The cloud services from AWS enabled us to move incrementally to modernize the system with controlled risk.

CloudFormation was the first service we used from the AWS stack of services. At the beginning we did not have a good idea of what we were doing, but AWS had a selection of useful templates to use and it gave us a taste of what we can accomplish. After a short while we managed to automate and codify our infrastructure creation. With our infrastructure as code we managed to evolve it incrementally for high availability with multi region infrastructure. CloudWatch events was then used to automate the response to failure events. The end result was a self healing environment with no extra cost. The outcome encouraged us to use more services.

Core or Meta

The next decision was whether to continue with meta services i.e. services that help manage and operate our existing code, or use the platform services. The advantages of AWS Lambda was intriguing, so intriguing to the point we were carefully looking for the catch and found none. We used some lambda services to automate some operation tasks, and it cost nothing, easy to manage and deploy so we decided to implement some new requirements using API Gateway, Lambda, RDS, SQS, and Beanstalk.

The legacy component was wrapped into a Beanstalk deployment. Beanstalk enabled us to have a self healing, auto scaled instances without modifying the original code. The legacy code was wrapped with a proxy that listens to an SQS queue. The client communicated via a API gateway endpoints. The gateway handled authentication, throttling, key management, and HTTPS. The API gateway invoked a lambda function that implemented the product new functionality, then put a message in the SQS for the legacy processing. The SQS queue enabled us to control the throughput, tolerate failures, and auto scale the beanstalk environment based on the queue requests. The whole environment was deployed via a CLoudFormation template, and logs were collected via CloudWatch. The following diagram shows the general system architecture.

More for Less

The success of the project left us hungry for more. After coping with cold start time of lambda, the low cost and auto scaling encouraged us to use it more, and the reliability of SQS enabled resilient architecture at negligible cost.

We added more services to the next project. Combined SNS/SQS to implement a pub/sub architecture. Decomposed more of the legacy logic into lambda functions. Started using DynamoDB for data persistence, and CodeDeploy for continuous delivery.

Goodbye CloudFormation and Welcome CDK

The CloudFormation template grew substantially and it was painful to maintain. We decided to look at AWS Cloud Deployment Kit CDK, and we never looked back.

Out of the box CDK saves a considerable amount of code by following an opinionated CloudFormation code generation that follows AWS best practices. But also it allowed us to build custom constructs, that reflects our architectural patterns, and manipulate the constructs before generation to implement cross cutting concerns like adding monitoring support for our Pub/Sub endpoints.

After implementing two new projects we were happily surprised that the production usage of the Lambda services was still covered by the free tier as well as DynamoDB deployments.

The low cost meant that we can have sandboxed environments for individual developers or specific features. Also performing a production like tests on the staging environment without worrying about the bill. CDK and CodeDeploy allowed us to automate all these operations, and sleep happily at night.

Sunday, May 17, 2020

10:24 PM

This is my personal notes for “Microservices Patterns” book by Chris Richardson https://microservices.io/book

Chapter 1

The first section of this chapter covers the monolithic hell and makes the case of Microservices with a story about a fictitious company and its struggle with maintaining and growing a monolithic app.

I found this section to be verbose with shallow information. I think it is fair to say if you are reading a book about Microservices Patterns chances are you are familiar with the drawbacks of monolithic apps vs. Microservices. It is safe to skip this section in my opinion.

Section 1.2, and 1.3 are about the book and why it is relevant and what it covers. Read it maybe before buying it to decide if it is relevant.

Section 1.4 defines Microservices. I think at the time of writing the book Chris Richardson did not have a concrete definition so instead he presented a verbose description. I find his definition on https://microservices.io/ to be more concrete. What I like about his definition is removing the size of the codebase as a Microservice characteristic and associating the size with team instead. I find this very useful as he drills down to the organizational change needed to decompose the monolith.

Generally, I prefer Sam Newman’s definition of Microservices.

Principles Of Microservices by Sam Newman

Sam Newman’s definition: Small (independently releasable) Autonomous services that work together, modelled around a business domain

Microservices and Serverless - Sam Newman

Independently deployable services that work together, modelled around a business domain

Section 1.6 is the most informative in this chapter, and specifically 1.6.3. It gives an overview of the pattern language used in the book and gives an excellent taxonomy of the patterns.

Chris classifies the patterns into three main layers. Application, Application Infrastructure, and Infrastructure patterns.

• Application Patterns
  • Decomposition
  • Database Architecture
  • Querying
  • Maintaining Data Consistency
  • Testing
• Application Infrastructure Patterns
  • Cross-cutting Concerns
  • Security
  • Transactional Messaging
  • Communication Style
  • Reliability
  • Observability
• Infrastructure Patterns
  • Deployment
  • Discovery
  • External API

Chapter 2 describes decomposition patterns in details. Chris describes it as a set of strategies for decomposing an application into Microservices.

Chapter 3 drills down into communication patterns including communication style, reliability, and transaction messaging while Chapter 8 covers external API patterns.

Chapter 4, 5, and 6 cover the strategies for data storage in the context of Microservices and the challenges associated with maintaining a database per service. Saga pattern is described in detail as an alternative to 2PC approach for distributed transactions.

Another challenge with database decomposition is querying data scattered around multiple services. Chapter 7 details a set of different patterns for implementing queries.

Chapter 12 focuses on deployment of Microservices either as VM, container, or serverless. While Chapter 11 details application observability patterns including health check API, log aggregation, distributed tracing, exception tracking, application metrics, and audit logging. Chapter 11 also describes Microservices Chassis pattern for handling cross-cutting concerns like observability and discovery. Chapter 11 also discusses security, and access token pattern in detail.

Chapter 9 and 10 focus on patterns for services automated testing with patterns for testing services in isolation with consumer-driven contract test, consumer-side contract test, and service component test.

The final section of this introductory chapter gives a good piece of wisdom about the non-technical aspect of implementing Microservices, and the need of organizational changes and consideration to the human side.

This chapter intrigued my interest in this book and looking forward to reading more.