1. Owning Work Design
Eleven issues ago I restarted this newsletter with a question I kept finding nobody was asking: who designs Work? Not who automates the tasks, and not who buys the tools. Who decides how work should flow through an organisation now that a machine can do part of it, and who answers for the result?
In Issue 57 I asked you a sharper version: in your organisation, who owns the cost that no function owns? And last time I ended by saying that who that somebody is would be this issue’s problem.
So this issue does two things. It puts the arc back together, because each issue was a piece of one argument and I think the pieces are easier to see side by side. And it makes the proposal as concrete as I can. I will say now that the proposal is not a new job title. I argued in Issue 55 that the proliferation of “Chief of…” titles is a symptom of the problem, and I have not changed my mind. What I want to describe is a way of governing and executing. Owning work design, in practice, means owning the capabilities through which the work gets done.
How we got here, one piece at a time
It started with a question about who designs Work in Issue 49, and the first thing that question needed was evidence. Issue 50 went looking in the productivity numbers and found a gap between what AI can do and what it is actually producing inside organisations. That gap is not a technology problem. It is a design problem: the tools get bought, while the work around them stays as it was.
If the gap is about design, the next question is what kind of capability would close it. Issue 51 answered with a way of governing the capabilities an organisation holds: treating them as a portfolio, managed with the same discipline a pension fund applies to its assets. I’m coming back to that proposal as the backbone of this issue.
Before going further, the arc had to look at what the gap costs. Issue 52 showed that when nobody redesigns the work, people inherit what is left behind: the checking and the monitoring, or an exhausting load of supervision. That raised an awkward question for my own profession: why had HR not noticed? Issue 53’s attempted answer was that HR’s instruments measure jobs, while AI moves work across the boundaries between them, and accountability quietly lands on whichever human happens to be nearest. Issue 54 went one step further and turned the lens on the operating model HR built for itself: designed for a world AI is dissolving, and asked to answer for outcomes it has no real authority to design, causing it to behave defensively.
So who should hold the design, if not HR as it stands today? Issue 55 looked at three companies that had tried to answer with a new structure, and concluded that the answer was a brief, not a title: the authority to rebalance the capability portfolio, not just the duty to describe it. Issue 56 created a link with my past, celebrating one of my earlier mentors, Franco D’Egidio. In the work I did with him (writing one of his books) I have been able to trace the reason why that brief is so hard to create: organisations are, in his words, over-managed and under-led, and they struggle to change from the inside because they cannot stop being what once made them successful. Once again, the obstacle is not the technology.
The last three issues turned from the organisation to the people inside it, because that is where the cost of the gap is paid. Issue 57 described the adoption debt, the cost that lands in the system while the gain is booked at the task, and introduced Sarah, Jack and Clara. Issue 58 added Ben, and showed that the work being automated first is the work through which people used to become good. And Issue 59 argued that development is a capability, not a culture, and that the right nobody holds is the right to end things.
Put side by side, all this makes a coherent argument. There is a gap between what the technology makes possible and what organisations do with it. The gap is in how capability is governed. It has a human cost that falls unevenly. And it persists because nobody holds the whole. Howard Yu's recent account of Japan Airlines' collapse puts it in a single line: "Competence in each job doesn't guarantee overall competence across different jobs."
Four people, four meanings of work
Before the proposal, one thing I have not said explicitly until now.
Sarah, Jack, Clara and Ben (the people you met in the last 3 issues) were not just four random employees. Each of them stands for a different answer to the question of what work means, the lens I have been developing on my website as the discourses of work. Over history, people have understood work in several distinct ways, and the older ways never really disappeared. They sit underneath the newer ones, inside the same office.
Sarah works in the discourse of Craftsmanship. Work is mastery, built slowly against a standard. What AI took from her was the practice through which the mastery was made.
Jack works in the discourse of Personal Realisation. Work is how he becomes someone. What AI took from him was the gradient; he is not disengaged, he is becalmed.
Clara works in the discourse of Subjugation. Work was imposed on her, not chosen. What AI brought her was more speed and more monitoring, and less slack in which any meaning could be improvised.
Ben works in the discourse of Work as Job. Work is a role in a system, with a title, a dashboard and a credential. What AI changed for him is that the role still looks the same from the outside, while the thing it was supposed to build inside him is no longer being built.
This matters for the proposal I am making, because it means the same redesign has to land in different ways. A change that frees Sarah’s time can wound her craft. A change that speeds up Clara’s day tightens a system she never agreed to. You cannot govern work well if you cannot see these differences, and most organisations have no instrument that sees them.
What owning something actually means
The word I would like to use for the brief is ownership, because every manager understands it. But it needs defining, because we use it loosely, and the loose version is exactly what has failed.
To own a piece of the organisation’s work, a capability, a process, a platform, you need three things at once.
You answer for the result. If it does not deliver, you are the one who explains why.
You can change how the work is done. Not request a change, not escalate it: change it.
You can narrow it or stop it. Or at least you can propose ending it, and be heard.
Take away any one of the three and what you have is not ownership. If you answer for the result but cannot change the design, you get the defensive behaviour Issue 54 described: you block, you delay, you ask for sign-off, and everyone calls it a culture problem. If you can change the design but answer for nothing, you get tinkering without consequence. And if nobody can stop anything, every capability becomes permanent by default, which is how organisations end up carrying things for years that nobody would choose today.
That third part is the one we forget, and it is the one Issue 59 was about. Functional ownership is a good way to build a capability and a poor way to end one, because the function that carries it depends on it continuing. So when I say ownership, I mean all three, including the uncomfortable one.
The proposal: holding the capability portfolio
In Issue 51 I proposed that organisations manage their capabilities as a portfolio, and that doing so imports four disciplines most of them lack.
Trade-offs made explicitly. Every decision to build, buy or borrow a capability is a choice between cost, speed, quality and dependency, and it should be made in the open. With AI there is now a fourth option on the table, automate, and it needs to be weighed the same way.
Continuous rebalancing. Not once a year at budget time, because with AI the value of a capability can shift within a quarter.
Risk as an explicit dimension. Borrow too much and you hollow out what you know. Build too much and you lock yourself in. These effects are predictable, but only if someone looks at the whole.
Ownership at the level where trade-offs are made. Somebody has to hold the whole picture, not just the line items.
Everything the arc has argued since adds four more.
Every capability has one owner, in the full sense. One named person who answers for it, can change it, and can propose ending it. Not a committee, and not a dotted line.
Every capability has an ending condition, and is argued for again on a cycle. When it is created, someone writes down what would have to be true for it to stop. Some endings cannot be undone, so the condition also says whether the decision can be reversed, and the ones that cannot need a higher bar of evidence. At regular intervals its owner explains why it is still worth what it costs, and what it costs is visible without anyone having to ask.
Formation is on the list. Before the preparatory work inside a capability is automated, the portfolio says where the next generation will learn to do the real work. This is Ben’s point, and it is the one that disappears first when the business case is written.
Meaning is read before work is redesigned. Any significant redesign comes with a reading of what it does to the people inside the work: to the Sarahs, the Jacks, the Claras and the Bens. Not a satisfaction survey. A deliberate account of which meanings of work the change supports and which it breaks.
So who holds it? This is the part I want to be precise about.
The portfolio belongs to the CEO and the executive team as a whole, because that is where trade-offs between capabilities can actually be made. It should sit on the agenda the way strategic planning or budget does: on a fixed rhythm, capability by capability, not only when a crisis forces the conversation. It is not an extra meeting. Most executive teams already spend hours arguing about capabilities; they just do it indirectly, line by line, in the budget round and in every restructuring proposal. The cycle moves that argument to the place where it can actually be settled, one capability at a time.
Each capability then needs its defined owner, usually the executive or senior manager whose part of the business depends on it most. The owner defends it at each cycle.
Anyone can table a proposal to redesign or retire a capability, and the owner has to answer it. This is where the right to end things finally lives: not with the custodian alone, and not with a committee for shutting things down, which would be captured within a year, but in the obligation to defend what you hold.
And one function runs the cycle without owning any of it. It keeps the map of what the organisation holds, makes the carrying costs visible, flags where formation is at risk, and brings the reading of meaning into the room. It is a steward, not an owner.
In a company of a few hundred people this is simpler than it sounds. The executive team already is the portfolio conversation, and the steward may be one person with a map, a cost column and the licence to ask awkward questions.
Why insist that ending something has to be an active decision? Because even in medicine, where the evidence against a practice can be overwhelming, a scoping review of how low-value clinical practices get abandoned found that active change interventions were associated with the greatest likelihood of actually stopping them. The evidence was not enough on its own. I see no reason to think organisations are better at stopping things than hospitals are.
What it looks like on a Monday morning
An example helps, so let me build one. It is a composite, but I have seen every piece of it.
A mid-sized company deploys an AI agent to handle customer complaints. Under the usual way of governing, IT buys the tool, operations deploys it, HR maybe runs some training, and the productivity gain is booked. Under the portfolio way, the complaints-handling capability has an owner, for example the head of customer operations, and the change goes through the cycle.
The trade-off is made in the open: first-line complaints are automated, escalations stay human, and the cost of the checking that remains is counted rather than assumed away. The formation question is asked before go-live: if the agent now handles the easy cases, where does a new hire learn what a hard case looks like? The answer is written down: every new handler resolves a number of difficult complaints end to end, alongside someone experienced.
The meaning is read. For the experienced handler, the craft now lives in the hard cases, so her role is redesigned around them. For the team lead who expected to run an escalation desk that no longer exists, a different next step is designed, perhaps owning the quality of the agent itself. For the outsourced night shift, the monitoring that came bundled with the tool is reviewed, and whatever nobody actually needs is switched off. And the old scripted-response training gets an ending condition: it stops when the new formation path is running.
A year later the owner stands up and explains whether the capability is still worth what it costs. Someone else may propose redesigning it again. The cycle is doing its job.
None of this requires a new executive. It requires the executive team to govern capability the way it already governs money.
Where HR fits
Which function should be the steward? In most organisations the obvious candidate is the people function, and I want to state the condition as sharply as I can: only if it is redefined, not rebranded.
My profession has asked for a seat at the table for twenty years. We got the seat. The problem was never the seat; it was what the function was built to do. A people function designed around transactions, expertise and translation, the three things AI is now absorbing, does not become able to steward a capability portfolio because someone changes its name. It has to be rebuilt around the portfolio: the map, the costs, the formation, the meaning. If it is not, handing it this role simply creates another silo next to the ones that were not talking to each other in the first place.
And the steward must not become the owner. The moment the people function owns the capabilities, it inherits the same interest in their continuation as every other custodian, and the right to end things disappears again.
What I cannot close
I told myself I would not tidy things away at the end, so three things stay open.
The first is Clara. The portfolio can switch off the monitoring nobody needed, and it can redesign her work around her rather than around the software. What it cannot do on its own is give her a say in what the work is for. Reading meaning is a start. Letting the people inside the work change what the organisation thinks the work means is a much longer road.
The second is that the reading of meaning cannot simply be installed. The authority to say what work means inside an organisation moves slowly, and only through deliberate investment over years, as the Italian fieldwork I cited last time shows. A steward can bring the reading into the room. Whether the room listens is a matter of leadership, and no governance model substitutes for that.
The third is how I would know I am wrong. If organisations that run this cycle for a few years end up retiring no more capabilities than those that do not, and the Bens still have nowhere to learn, then the problem was never governance, and the portfolio is one more ritual. I would rather name that test now than be spared it later.
What comes next
This issue closes an arc I started in May. It does not close this newsletter.
The next few issues are deliberately provisional, and I would rather say so than pretend to a plan: the fallacy of treating work as a list of tasks, what a people function looks like once AI has dissolved the logic it was built on, and the difference between being accountable and being responsible. Alongside them I am starting a parallel thread on intentionality in practice, which I will introduce properly soon.
For now, one question: pick one capability your organisation has been carrying for years. Who owns it in all three senses, and who could end it?
If you can name them, the portfolio is already being held, at least there.
If you cannot, you know where to start.
Sergio
References
D’Egidio, F. (2003). La Nuova Bussola del Manager. ETAS.
Niven, D. J., Mrklas, K. J., Holodinsky, J. K., Straus, S. E., Hemmelgarn, B. R., Jeffs, L. P. and Stelfox, H. T. (2015). Towards understanding the de-adoption of low-value clinical practices: a scoping review. BMC Medicine, 13, 255. https://doi.org/10.1186/s12916-015-0488-z
Yu, Howard (2026). “What If Doing Your Job Is Part of the Problem?” Substack newsletter. One Inch Ahead, September 18, 2026.
Zucca, A., Bieber, K., Ghignone, E. and Solari, L. (2026). Il ruolo necessario degli artefici della libertà del self-management. Harvard Business Review Italia, luglio-agosto 2026. https://www.hbritalia.it/luglio-agosto-2026/2026/07/01/news/il-ruolo-necessario-degli-artefici-della-liberta-del-self-management-16622/
2. Site Updates
A long piece went up on the site last Sunday, and it is this issue’s question seen from inside the people function. The One Thing the CHRO Designs starts from Dave Ulrich’s September reading of the CHRO priority lists, which puts work, rather than people, at the centre of the function, and sets it against two decades of survey data showing how little the function itself has moved. Its argument is that the HR operating model is the one thing a CHRO designs outright, and that the business partner is where that model meets the line, and so where it fails first.
Read it next to the section above on where HR fits. There I say the people function should steward the capability portfolio without owning it. The essay asks what the function would have to look like to do that, and starts from the interface with the line rather than from the chart. It runs to about half an hour, with three figures and a full reference list, so it is one for a quiet hour.
One correction, too. The page on consistency, congruence and coherence now claims less than it did. The study at its centre measured whether an institution’s stated values, goals and leadership signals pointed the same way, not whether any of that matched what the institution actually did, and I had read it as saying more. The corrected argument is smaller and, I think, stronger.
3. Reading Suggestions
We Know How to Worry About AI That Fails — Richard Claydon, Leadership, Rewritten. The Substack pick. Agents that each behave well can still fail together, because the failure lives in how they interact. The governance version of this issue’s argument: somebody has to look at the whole.
Impact pathway: beyond automation and augmentation – a relational ontology of AI in operations and supply chain management — Wilhelm, Yan, Hendriksen, Sanders & Micheli, International Journal of Operations & Production Management, 46(13), 2026. The scientific pick, from Zotero. The authors argue that AI can no longer be treated as a discrete tool added to existing operations, and read role drift, unstable process boundaries and contested performance attribution as things to study rather than implementation failures. The operations literature arriving at the same place as this arc.
The Gap Is Where the Job Gets Learned — John Sumser, HRExaminer. Work as prescribed and work as done are never the same, and the gap between them is where people actually learn the job. AI governance written only from the prescribed side misses it. Ben’s problem, seen from the governance desk.
AI agents are not people, and that’s a problem for HR — Colby Kennedy Nesbitt, Variance, Explained. Calling AI labour serves a lot of interests, and most of them gain more from the word than from the responsibility that would come with it. The strongest position is to talk labour and act software. He then asks HR a sharper question about its own instruments: does this measure need a continuous person behind it, or is it only counting units of work? Read it against the section above on where HR fits. He worked at Lattice when it tried to give agents employee records, so he is a participant as well as an observer.
Managing AI Employees — Matteo Cellini, on Substack. Agents need a defined job, reviews, limits and eventually a retirement, and someone in the business who answers for what each one produces: the box the org chart is still missing. His lifecycle has a stage I did not put in the essay, restriction, which means narrowing an agent’s scope instead of switching it off. Read it next to Nesbitt: one treats agents as employees to be managed, the other shows what that framing hides.
4. The (un) Intentional Organisation 😁
5. Keeping in Touch
Don’t hesitate to reach out by directly hitting “reply” to this newsletter or using my blog’s contact form.
I welcome any feedback on this newsletter and the content of my articles.
Find me also on: