Autonomy at Scale¶
Over the years I've tried a lot of organisational models. Standups. Retrospectives. Timesheets. Sprint planning. The full suite.
At eXOReaction, we've converged on something different. It's not a framework with a name. It's more a set of positions — things we've decided, and held to, even when they make people uncomfortable.
No meetings¶
Not "fewer meetings." No meetings.
The reasoning is straightforward: a meeting is a synchronous event that requires everyone to be available at the same time, consumes the same calendar slot for people with different levels of relevance to the topic, and produces output that exists only in the memories of the people present — unless someone takes notes, which usually means the person who was least able to focus on the actual content.
Documentation does the same work asynchronously. You write it once. Anyone reads it when they need it. It persists. It can be referenced, searched, updated. It doesn't require scheduling.
The standard objection is that meetings build relationships and resolve ambiguity faster than written communication. That's true in specific cases. For those cases we use calls — but we're explicit that a call is an exception, not the default.
The default is: write it down.
No timesheets¶
Timesheets measure presence, not contribution. They're an instrument of control dressed up as an instrument of accountability.
The implicit contract behind a timesheet is: I don't trust you to work unless I can see the hours. That contract corrodes everything it touches. People fill timesheets to satisfy the system, not because they reflect actual work. Managers manage the timesheet, not the outcomes. The organisation learns to optimise the metric rather than the thing the metric was supposed to measure.
The alternative is trust with clear expectations. Here's what needs to happen. Here's when. You work out how.
If you need timesheets to know whether someone is contributing, you have a different problem — a clarity problem, or a trust problem — and timesheets won't fix either.
Documentation over meetings¶
This is the synthesis of the two above, and the thing most people find hardest to internalise.
Every decision made in a call should be documented. Every design choice should be explained in writing — not just what was decided, but why. Not for the meeting's participants, who already know, but for the next person who needs to understand the system, or the same person six months later who no longer remembers.
When documentation is the default, you know your team is thinking clearly about something when they can write it clearly. If you can't explain a decision in writing, you probably don't understand it well enough yet.
Eilif's objection¶
In the comment thread, Eilif Monrad-Krohn raised the concern I hear most often: that replacing meetings with documentation just creates a different kind of overhead. Documentation takes time to write and time to maintain. It goes stale. It multiplies.
He's right that bad documentation is its own failure mode. A codebase buried under outdated READMEs and contradictory decision logs is not better than a team that meets too often.
The answer isn't to write more — it's to write better, and to apply the same discipline to documentation that you'd apply to code: tidy as you go, delete what's obsolete, keep the signal-to-noise high.
The difference between "documentation as overhead" and "documentation as infrastructure" is curation. The former is entropy. The latter is investment.
The filter effect¶
I've noticed that these positions attract a certain kind of person and organisation — and repel others. That's not an accident.
If you believe accountability requires observation, async-first will feel irresponsible to you. If you believe that the way to build trust is through shared presence, no-meetings will feel isolating. If you believe that structure requires ceremonies, this won't fit.
Those are genuine differences in how people think organisations should work. I'm not arguing they're wrong for everyone. I'm saying they're wrong for us — and that stating them clearly saves time for both sides.
The clients and colleagues who've worked best with eXOReaction are people who already work this way, or want to. People who prefer ownership over oversight. Clarity over coordination overhead. Output over activity.
Stating the positions publicly is how they find us.
Why this connects to methodology¶
A week earlier I'd posted about the 80/50 Rule — the principle of manufacturing urgency early, before the deadline creates it for you. The methodological link isn't obvious, but it's real.
Both positions are about removing friction from productive work. The 80/50 Rule removes the friction of deadline psychology. Async-first removes the friction of coordination overhead.
Both require trust — in yourself in the first case, in your team in the second.
That trust isn't naive. It's the deliberate choice to optimise for outcomes rather than the appearance of outcomes. And at scale, the difference between those two things compounds fast.
Originally published on LinkedIn, November 17, 2025.
This post is part of the Methodology series.