The Saturday Nobody Asked For

Introduction: the question from LinkedIn

A friend of mine posted recently about an engineer on their team who had, without being asked, put in an enormous amount of work over a weekend. The post asked a good question: once you’ve seen someone operate at that level unprompted, what does it actually mean to elevate them? The suggestion seemed to be: give them more work, more responsibility. I commented on that (on a Sunday, if we want to be pesky) and you can ready it here.

I want to start somewhere adjacent to that question, not inside it, because the more I turned it over, the less it seemed to be about any one engineer, and the more it seemed to be about what an organisation silently decides Saturday means.

And I want to be upfront about something, because this kind of piece has a tendency to slide into moralising about overtime, and that is definitely not where I’m going. I think people should be able to work whenever they want. Not “whenever, as long as it’s within reasonable hours or days.” Whenever. Six in the morning, midnight, Saturday, Tuesday at 4 p.m. instead of Monday at 9 a.m. Some of that is just personality. Some of it, it turns out, is older than personality.

There’s a hypothesis in evolutionary anthropology called the sentinel hypothesis, and I like it more than almost anything else I’ve read about circadian rhythm, because it reframes the concepts of morning person and night owl as something other than a lifestyle quirk. The idea is that group-living animals share the task of staying alert during sleep, with some individuals asleep while others keep watch.

What was known as Snyder’s sentinel hypothesis (1966) was tested by Samson and colleagues in 2017, by observing Hadza hunter-gatherers in Tanzania and publishing their findings in Proceedings of the Royal Society. Across twenty days of observation, the group was recorded as entirely asleep at the same time for a grand total of eighteen minutes, with a median of eight people awake at any given point through the night. Nobody appeared to be assigned the night shift. The awareness we need a sentinel and the variation in when people naturally wanted to be awake was, on its own, enough to keep a sentinel posted more or less around the clock. One of the study’s co-authors suggested that this variation may have been adaptive in our ancestral past, even if it now sits awkwardly inside a modern school-and-office schedule built for a single, shared rhythm. We didn’t just tolerate having morning larks and night owls in the same tribe. We needed both: farmers and hunters moving with the sun, and somebody else awake to watch the dark.

For your reference:

• Snyder, F. (1966). “Toward an evolutionary theory of dreaming”. American Journal of Psychiatry, 123(2), 121–142. The paper that originally proposed the sentinel hypothesis (the idea that periodic awakenings during sleep serve a vigilance function for the group).
• Samson, D. R., Crittenden, A. N., Mabulla, I. A., Mabulla, A. Z. P., & Nunn, C. L. (2017). “Chronotype variation drives night-time sentinel-like behaviour in hunter–gatherers“. Proceedings of the Royal Society B: Biological Sciences, 284(1858), 20170967. The Hadza study, showing the group was never fully asleep simultaneously for more than 18 minutes total across 20 nights of observation.
• Samson, D. R. (2021). “Sound reasons for unsound sleep: Comparative support for the sentinel hypothesis in industrial and nonindustrial groups“. Evolution, Medicine, and Public Health, 11(1), 53–65. Extends the sentinel hypothesis argument to modern/industrial populations.

So no, this isn’t an argument against Saturdays. If anything, it’s an argument for taking chronotype and personal rhythm far more seriously than the standard nine-to-five allows, and for building workplaces flexible enough to let a natural night owl do their best work at 11 p.m. on a Tuesday without anyone blinking.

But there’s a difference between a team where people choose their hours because the culture genuinely supports it, and a team where an enormous chunk of unplanned, unmentioned work shows up over a weekend, and the only question anyone asks is how to reward it. That gap — between flexibility as autonomy and flexibility as a cover story for absorbed dysfunction — is what the rest of this piece is about. DevOps culture research, oddly enough, has been mapping exactly that gap for over a decade, in organisations that had every incentive to get it right: because when the hero who quietly saves the weekend is running a nuclear plant or a hospital system instead of a codebase, nobody gets to call it dedication. By the end of the piece, I’ll also sprinkle some LEGO Serious Play on top, with the design of a workshop on how to assess your company culture.

1. The Brent Problem

Gene Kim‘s The Phoenix Project is a novel, technically, but it functions more like a manual dressed up as a story, and I’ve been recommending it to everybody who was willing to listen, alongside its successor The Unicorn Project.

It follows a fictional company through the kind of slow-motion operational crisis that IT leaders read and recognise immediately, uncomfortably, as their own. And at the centre of it is a character who never asked for any of this: Brent.

Brent is the brilliant and overworked engineer who knows how everything actually works, underneath the documentation and the organisational chart. When a deployment fails at 2 a.m., Brent gets the call. When a system nobody else understands breaks on a Friday, Brent stays late, and Brent fixes it, and Brent doesn’t really complain, because Brent is good at this and being needed feels like a kind of worth. Everybody loves Brent. Managers point to Brent in reviews. And the entire second act of the book is the painful realisation that Brent is not the company’s greatest asset: he’s its single point of failure, and everyone built their plans on top of him without ever writing that dependency down anywhere.

I think this is the part that might not transfer intuitively from fiction to a LinkedIn post: praising the unplanned work is a resourcing decision, even if nobody files it as one. Every time an organisation responds to absorbed, unplanned effort with admiration instead of inquiry, it quietly confirms that this is how the gap between plan and reality gets closed around here: not through better estimation, not through someone raising a flag mid-week, but through somebody’s personal willingness to eat the difference.
And admiration is cheap.
It costs the organisation nothing to say “what a legend,” which is exactly why it’s the default response, and exactly why it changes nothing.

The part Kim’s book is actually careful about, and that I think gets lost when people invoke Brent casually, is that the book doesn’t blame Brent. Brent isn’t a problem because he’s lazy or because he’s angling for praise. He’s a problem because he’s competent and conscientious in an environment that has no other mechanism for closing gaps, so his competence gets treated as infrastructure. The fix, in the book, is the opposite of giving Brent more work, more responsibility or even people to help him: we need to get Brent’s knowledge out of Brent’s head, build the processes and documentation and cross-training that mean the next 2 a.m. failure doesn’t route through one specific person’s phone, and — crucially — stop rewarding the absorption in a way that recruits more Brents.

That’s the mechanism worth sitting with. Once a team sees that unplanned, unasked-for weekend work is what gets someone noticed, you haven’t just found your Brent: you’ve built an incentive structure that produces more of them, whether or not that was the intention. The Saturday that gets celebrated on a Monday call is a Saturday that other people will feel, sooner or later, they need to have too.

2. What kind of organisation is yours anyway?

Here’s a question that sounds simple and isn’t: was Saturday good or bad?

I don’t think that’s actually answerable in the abstract, and I don’t think it’s the right question. The right question is what happened before and what happened next. What the organisation did with the information once it had it. And it turns out there’s a decades-old framework, built for contexts far higher-stakes than a codebase, that gives you a precise way to answer that.

Back in 1988, Ron Westrum was not writing about software: he was a sociologist studying human factors in safety-critical systems — aviation, nuclear plants, hospitals — where the thing that goes wrong when information doesn’t flow properly isn’t a missed sprint, it’s a plane going down. Back then, he proposed a typology of organisational culture with three types, and the axis he sorted them on wasn’t “friendly vs. hostile” or “fast vs. slow.” It was information flow: how does this organisation behave when someone tries to tell it something it might not want to hear? The most systematic summary of his approach was then published in 2004, in an article called “A typology of organisational cultures,” in Quality and Safety in Health Care.

Here’s his take, and you’ve heard this from me before:

• Pathological organisations run on power and fear. Information gets hoarded, or distorted to make the messenger look better, because sharing it honestly is dangerous. Failure gets hidden, because failure is punished. New ideas are, structurally, a threat.
  I know at least an architectural firm that operates this way.
• Bureaucratic organisations run on rules and departmental boundaries. Information doesn’t get weaponised here, it just gets filed and often ignored — not because anyone’s afraid, but because nobody’s job is to actually do anything with it. Failure gets processed correctly, by the book, and nothing changes as a result. New ideas create paperwork.
  I know at least an engineering firm that operates this way.
• Generative organisations run on mission and performance. Information gets actively sought out, including — especially — the uncomfortable kind. Messengers of bad news are trained, not shot. Failure triggers curiosity: what does this reveal, and what do we fix? Responsibility gets shared, and cooperation across team boundaries is rewarded rather than merely tolerated.
  It would be nice to meet one.

Westrum’s own image for the difference, from his work in aviation, is worth borrowing directly: imagine a pilot reporting a near miss. A pathological culture silences the pilot to protect its reputation. A bureaucratic culture files the report and moves on. A generative culture treats the near miss as the whole point: free information about how the next real accident could be prevented, handed to you before anyone got hurt.

Far from being a niche academic curiosity, this concept always pops up, eventually, while I’m training BIM managers. When Nicole Forsgren, Jez Humble and Gene Kim ran the research that became the DORA State of DevOps reports and later the book Accelerate, Westrum’s typology turned out to be one of the strongest predictors they found of the actual, measurable four-key delivery metrics:

1. deployment frequency,
2. lead time,
3. mean time to recovery,
4. change failure rate.

Generative culture predicted better software delivery performance. It also predicted less burnout and better staff retention, which is the part I think matters more than the delivery metrics, honestly, even if it’s the delivery metrics that get a culture change approved by whoever’s holding the budget.

So: back to Saturdays. Run it through the typology, and the interesting diagnostic might be the silence around them. If nobody mentioned it on the next call, nobody flagged, mid-week, that something had gone sideways enough to require that much unplanned effort. In a generative organisation, that silence should be slightly alarming on its own, because a generative culture is hungry for exactly that kind of information, and its absence means either the information didn’t feel safe to share, or nobody thought to ask for it. In a pathological culture, the silence makes perfect sense: you don’t announce that something needed rescuing, you just quietly rescue it, because admitting the gap existed is riskier than closing it yourself at 11 p.m. on a Saturday.

I’d gently suggest that most organisations that end up praising a Brent aren’t pathological in Westrum’s sense: nobody’s hoarding information out of fear, nobody’s being punished for bad news. They’re something closer to accidentally bureaucratic-leaning-generative: genuinely well-intentioned, genuinely proud of their people, and just… not curious enough, yet, about the why. Which is, if you think about it, an easier problem to fix than fear. It just requires asking a different question on Monday.

3. The Feedback Loop, and what happens when it breaks

There’s a second framework I want to borrow from the same corner of the literature, because it answers a question the typology doesn’t quite get to, and it’s about the specific point where company culture might be failing.

The DevOps Handbook — Gene Kim again, this time with Jez Humble, Patrick Debois and John Willis — organises the whole discipline around what they call the Three Ways, and long-time readers of this blog are very familiar with this concept as well.

1. The First Way is fast flow: work should move from left to right, from idea to production, without getting stuck.
2. The Second Way is fast feedback: problems should be visible and loud, as close as possible to where and when they happen, so they get fixed at the source instead of quietly absorbed downstream.
3. The Third Way is continual learning and experimentation: an organisation that treats every incident, near-miss and unplanned Saturday as an experiment it didn’t mean to run, but can still learn from.

As much as I love the First Way, it’s the Second Way I keep coming back to, because an unplanned Saturday is, almost by definition, what it looks like when that loop has failed. Something might have gone wrong earlier in the week — an estimate that didn’t hold, a dependency that blocked later than expected, a scope that quietly grew past what anyone budgeted for — and maybe none of that surfaced when it happened. It surfaced two days later, converted into a solitary weekend effort, at the exact point where surfacing it stopped being useful for preventing the problem and started being useful only for absorbing it.

This is the part I think gets missed when the story is focusing on production and not on rhythm. The volume is a symptom, not the point. The actual failure might have happened days earlier, and several people upstream of Brent, whoever’s estimate or plan or handoff created the gap he then spent his Saturday closing. A team with a working feedback loop would have heard about that gap on Tuesday, in a standup, from someone slightly annoyed and entirely comfortable saying so out loud. A team without one hears about it, if it hears about it at all, on the following Monday. And even then, only in retrospect, dressed up as a success story instead of flagged as the near-miss it actually was.

There’s a specific piece of DORA research that directly contradicts the instinct to read heroics as a good sign: sustainable pace is one of the metrics the Accelerate research tracks, and it correlates positively with the four key delivery metrics. Teams that consistently work unsustainable hours don’t out-perform teams that don’t: they underperform them, on the same measures the business already cares about, while also burning through the people doing the overtime. The heroics aren’t buying the organisation anything except a store of goodwill it’s about to spend.

So here’s the reframe I’d actually want a team lead to sit with on Monday: don’t ask how to get more Brents, but hunt for the cause. Ask where did a problem travel further than it should have before anyone said anything out loud, and go find that point, because that’s the loop that needs fixing, not the person who happened to be standing at the end of it when it finally broke.

4. Smart Working vs. Always Working

Having taken that out of my system, let me take the most generous reading possible, because I think it’s worth sitting in for a moment before we complicate it: maybe that person just wanted to work on a Saturday. The weather was bad. There’s air conditioning in the office. Their dog ran away with another dog for the weekend. They woke up with an idea on how to fix a problem, and that creative itch to solve it now.

Maybe Saturday wasn’t absorbed dysfunction at all.

Maybe it was flow: that specific, slightly addictive state where a problem finally gives way under your hands and you’d genuinely rather keep going than stop for dinner. Maybe that person’s a night owl, or a weekend-morning person, whose best two hours of concentration all week happen to fall on a day everyone else has designated as off-limits, and they used them, and it felt good, the way finishing something always feels good.

This is exactly the kind of autonomy I argued for in the opening of this piece: work should be able to happen whenever a person’s rhythm and motivation actually line up, Saturday included.

Here’s the problem, though, and it has nothing to do with the person doing the work: it’s what happens to the rest of the team, the company, and to everyone standing next to him.

A culture doesn’t need anyone to be coerced for a norm to spread: it just needs one visible data point and an audience that’s paying attention, and a team is always paying attention to what gets rewarded. The moment unplanned Saturday work becomes the thing that gets someone noticed — even once, even sincerely, even when it was chosen freely and enjoyed — it stops being one person’s rhythm and starts being a benchmark everyone else is now measured against, whether or not anyone said so out loud. Nobody has to demand it. Comparison does the work on its own.

And it doesn’t stop at comparison.

Give it a few cycles and the people who don’t work Saturdays — because they have children, because their rhythm runs the other way, because they simply have a life outside the company that they’d like to keep — start to feel it. As a mood. A joke about “banker’s hours” or “working part-time” I heard a dozen times when everybody’s overworked and someone dares to leave the office before 8 p.m. A slightly raised eyebrow in a retro.
The creeping sense, arriving on Monday, when you find someone else had quietly fixed your part of the system over the weekend. The guilt in feeling you, too, should probably start checking in on Saturdays, just in case, so that doesn’t happen again.

Guilt and shame.

Nobody needs to write a memo for this to happen: the culture does it by itself.

This is the part that makes smart working such a slippery term, because it gets used to describe two entirely different arrangements.

One is genuine flexibility: an hourly or output-based budget that a person is trusted to spend however suits their rhythm, with a real boundary around the total, so that working Tuesday at 4 p.m. instead of Monday at 9 a.m. is a swap, not an addition.

The other is flexibility as a euphemism: no fixed hours, which sounds identical to the first arrangement right up until you notice that nobody’s total ever seems to shrink, only redistribute, and the “freedom” to work anytime quietly becomes an expectation to work most of the time.
And this happens also because there’s no coordination. Actual flexibility is a manager’s nightmare, because communication and work organisation need to be flawless. You won’t be in the office to answer a doubt if you’re the night-owl. Your weekend-working people won’t be able to pick up the phone and call their colleagues to consult on a matter. And you’ll have to organise meetings in the overlapping hours, if it’s just an 18-minute standup like the Hadzas.

The difference between the two settings is visible in what a team does with a Saturday like this one: a team with the first kind of culture checks in, and moves on when one person’s rhythm doesn’t obligate anyone else’s. A team with the second kind starts, without quite noticing, keeping score.

5. Practical Diagnostic Tools

As promised, here’s the design of a LEGO Serious Play workshop to help you finalise it. I have associates all around the world, through my partnership with Denmark: just drop me a line if you’re interested, and I’ll hook you up with someone who can run it for you.

5.0. Setting the Goal

Goal: create a system of your organisation and map the two-ways flow (production downstream, feedback upstream, information both ways)

In LEGO Serious Play terms: give a team a way to figure out, physically, whether their information actually flows the way they assume it does.
We’ll do that by running the same topology twice with a different payload, and letting the possible gap between the two runs be the diagnostic.

5.1. Building the Company

This is how it might actually look after a dedicated warm-up (and you know this part if you’re a trained facilitator).

1. Building the company’s departments. If you’re lucky enough to have one person from each department, this can be an easy individual models exercise. If you have more than one person from each department, the workshop will be richer in insight, but definitely longer: you’ll have to go through individual models (each person’s view on their department), and then you’ll have to split them to build a shared model they agree upon, with all key elements from all models.
2. Placement. Each department’s model will have to be placed in what we call a landscape. Since we’re operating in the DevOps framework, I would use a guinding canvas with production departments at the centre of the landscape, and facing outwards I would guide people to place departments that have more contact with the customer, that work in distribution, that need to use (operate) what’s being developed at the core.
3. Youi might decide to do connections, here, if you feel there’s a need to figure out how the different departments play together, or not.

5.2. Scenario 1: a sunny day

Now, the workshop runs on two different levels. The first one is to ask people to do a round of agents (one agent each), and each agent should represent a splendid idea that’s born inside the company. The splendid idea needs to be placed next to the department that came up with it.

To help visualise the ideas, I’d suggest you give people a small constraint: ask them to build agents on colour-coded baseplates, such as this blue one. You’ll use a dark one later.

The next round of connections will have to answer this question: how does this bright idea get communicated through the departments? Who’s approving it? Who’s acting upon it? Who’s left out of the loop? This will give you a first set of insights.

5.3. Scenario 2: a stormy night

Now’s the time to make it nasty. Ask people to build, on a grey or black plate, an agent each, representing a catastrophic failure. It might be a failure in production or deployment, a client leaving, the Tax Inspectorate finding something nasty in the company’s logbooks. Anything that makes sense, but keep it grounded. The more realistic the failures, the best. By this time, the facilitator did their job, the play mode will be in full swing, and people will feel free to express realistic scenarios they won’t have discussed in a regular meeting (see more here).

Ask people to do the same: place the failures next to the department that originated them, and then the crucial question will be “how are these documented and communicated across departments?” Then sit back, and enjoy the method unravelling the un-unravellable: people will start talking about who’s not getting warned of the failure, who can contribute to its fixing, and you built into the system a need for communication that might have been unthinkable a few hours prior to the workshop.

5.4. Let’s fix it

It’s not a LEGO Serious Play workshop unless we come out with actionable items we can take forward. The last request I would recommend is giving people small, colour-coded baseplates and asking them to build solutions to specific communication gaps in the systems. If you see people reverting their focus on the “sunny day” scenario, you can specifically ask them to build solutions to the “stormy night” scenario and then reflect on how (and if) it’s helping the “sunny day” scenario as well. I think it will. And I think it’s a gamble it might be worth to take. But maybe I’m overstepping as a facilitator into the consultant.

Closing the Loop

I keep coming back to Atlas. Not Heracles, the hero working on weekends. Atlas, holding the sky up because someone convinced him it was his to hold, alone, indefinitely. Nobody in the Brent story is a villain, and I doubt anyone in the story that started this piece is either. That’s precisely what makes the whole thing worth writing about: this isn’t a piece about bad managers or toxic, lazy organisations. It’s a piece about how easily a genuinely well-meaning culture — proud of its people, quick to praise, in good faith the whole way through — can end up quietly handing someone the sky, and calling it a compliment.

Westrum’s typology, the Second Way, the sunny-day and rainy-night boards: none of it is really about diagnosing villains, and none of it is about any one Saturday in particular. It’s about building a culture generative enough that the sky never has to sit on one set of shoulders in the first place, where a gap gets flagged on Tuesday instead of closed in silence on the weekend, where the people who’d rather work at 11 p.m. on a Tuesday can, and the people who’d rather leave at six on a Friday can too, without either of them keeping score on the other.

And if you do run the workshop, and the two overlapping boards end up looking uncomfortably different — the blue one clean and confident, the dark one stalled three departments short of where it needed to go — don’t treat that as a verdict on anyone in the room. Treat it the way a generative culture treats a near miss: as the most useful, cheapest piece of information your team is ever going to get for free, handed to you before anyone actually needed rescuing.

Nobody wants to be Atlas. Not even the ones who are good at holding the sky.