The Operator's Case

What My Agents Taught Me

Since early summer I've been running parts of my own work through AI agents. There are about twenty of them now, and most of them own a single outcome: the company plan, a recurring update email, the list of people waiting on a reply from me, a project with an end date.

Last month I wrote about a mistake I made with them. Our plan work had ended up split between two agents, and which one did the work depended on which one I happened to be talking to. My co-founder and I agreed in a chat thread to change one of the plan's goals. The change never reached the plan, and a day later another agent was drafting an email that led with the outdated goal. The mistake was mine. It wasn't the first time. At VA Linux and then SugarCRM, when something I'd decided didn't happen, I went looking for the person who let it slide, and the name I came back with was often my own.

This time I'd given the plan two owners, and neither of them had the whole history. I gave it one owner and handed that agent everything, and the lesson I took is that work which needs the same history belongs with a single owner.

Then I thought about what that lesson says about the people I work with. Each of my agents has a narrow job, and each one slips when its history splits. The person at the center of a company has the widest job there is. Everything the leadership team decides, every commitment that hangs off those decisions, and every goal they roll up to share one history, and that history runs through one or two people. I built my agents a rough system that holds their history. Nobody has built a durable one for the people at the center of a company.

I'll call them operators. In one company the operator is the COO. In another it's the CEO who still runs the business day to day, a CFO who owns operations, or a program director nobody outside the building has heard of. Sometimes it's the leader whose calls create the work, and sometimes it's the person who carries that leader's context. When we look for them at Brief, we've learned to screen on the role: whoever owns keeping track of what the team decided, who committed to what, and which goals it all serves. Every company has someone doing that job, usually by hand.

Work That Looks Like No One Else's

Most business software is organized around a unit of work: personal productivity tools around the task, management tools around the project, and collaboration tools around the conversation. An operator's unit of work is the decision, along with everything it sets in motion. A single call on a Tuesday creates commitments for four people in three functions, changes a goal the board approved in January, and lands on a customer who wasn't in the room. Each tool holds the slice of that call that fell inside it, and none of them holds the decision, the reasons behind it, or the web of promises it created.

Essay 01 named two properties of this work, decision density and multi-entity operations, and a third belongs beside them. Together they're why the job gets hard to carry by hand past a certain size.

Decision density is how many consequential calls a leader makes, weighted by how much each one depends on the calls before it. An operator's decisions lean on each other. The staffing call on Wednesday turns on a commitment someone made three weeks ago, and the pricing call on Thursday turns on the staffing call. Density is what turns a busy week into a fragile one, because each call can be no sounder than the operator's memory of the calls underneath it.

Multi-entity operations means the operator owns a portfolio of moving parts at once: people, projects, decisions, commitments, and goals, each with its own state. An operations VP at an industrial machinery manufacturer described how his team works. "We follow ownership of tasks in the organization instead of just the task themselves." The thing being tracked is who owns what across the whole company and how those owners affect each other.

The third property, cross-functional ownership, comes from where the operator sits, at the point where functions meet, with the context they need spread across every system those functions use. Internal communication was the biggest challenge to sales, according to a VP of sales at a self-service kiosk manufacturer. "We have the right solutions but struggle to communicate effectively internally in what can be quite complex projects that need to be managed through design, engineering, operations and finance simultaneously." Four functions are working one customer project at the same moment, and the operator's head ends up as the one place where the state of all four comes together.

Donald Sull teaches at MIT Sloan and taught at London Business School before that, and for two decades he has studied why good strategies break down in execution. His research keeps landing on this seam. In the Harvard Business Review study he published in 2015 with Rebecca Homkes and Charles Sull, managers said they were three times more likely to miss a performance commitment because another unit didn't give them the support they needed than because their own team fell short. Most companies organize to manage the work inside each function, and the work that breaks runs between them, in the place where the operator stands.

A Week at the Center

At Brief, we've interviewed and surveyed more than 150 executives and the people who support them since last fall. When we asked them for a commitment that slipped, they described ordinary weeks, and laid end to end, their answers read like one.

Monday starts with a call. A CFO at a construction contractor described what he needs to make one. "I'm comfortable making a call before every variable is known, but I want the key facts, risks, and tradeoffs to be explicit." That's where the gap opens, before the decision is even made. The facts exist, spread across a dozen inboxes and a few people's heads, and the operator either assembles them before the meeting or decides without them. Nobody's job is to assemble them, so the operator does it, usually early in the morning or late the night before.

The call gets made and handed down. An operations VP at a private-label food manufacturer passed a decision on to his department. "I assumed everyone was on board but they weren't. So we had to have meetings every day." The price of that assumption was a daily meeting held to find out whether the work was happening.

Tuesday and Wednesday go to chasing. The smallest version of it came from an HR director at a manufacturing company. "I asked an employee to analyze a data set and had to remind her to do it twice before I got it." The work got done. The two reminders are the part no system sees.

Thursday, work comes back. A director at an electrical contracting firm assigned an estimate with a tight but workable deadline. "It was given back to me at the last minute and I had to complete the work." Thursday is also when a settled question returns. A senior program director at a medical device manufacturer described a product decision his team had aligned on, reopened months later, "causing a huge amount of extra work and time to essentially re-litigate which had already been decided." That one is decision amnesia, and I lived it at SugarCRM, where some decisions had to keep holding for months and the people who joined later never heard the reasoning behind them.

Friday is when the operator finds out. A finance director at a manufacturing company told us about a project she'd handed off. "I delegated the completion of a margin analysis project for our CEO. I had to follow up with the person the work was delegated to multiple times and she continued to defer the review deadline. When I set a more firm deadline for completion she did not have the required analysis completed which resulted in me giving the project to another person on the team and the project being delivered 2 months late."

In the stories from our first two surveys, the commonest shape was that one: something was owed, and it still hadn't arrived. In about one story in five, someone believed the work was in someone else's hands or already done, and it wasn't. Silence reads exactly like progress. When the miss crosses functions, it gets worse. Sull's 2015 study found that conflicts between units are handled badly about two-thirds of the time: resolved slowly, resolved quickly but poorly, or left to fester.

When we asked what a slip cost them, the answer that came back most often was wasted time and rework. Lost deals and lost money, the costs most software in this space gets sold on, came well behind. The most expensive people in the building pay it every week, and it never appears as a line in a budget.

I paid it myself. At SugarCRM I ran a weekly staff meeting, and the first fifteen minutes went to status, establishing whether the things we'd decided the week before had happened. Nobody around that table logged that quarter hour as the price of a commitment that slipped, because it didn't feel like a price. It felt like managing.

The Systems Operators Build Themselves

Operators don't wait for someone to fix this. More than half of the leaders in our latest survey told us they manage slips with a system of their own. In an earlier survey, a data and business intelligence director at a fire protection and life safety contractor told us he'd tried to build one in Power Automate, a tracker for his own commitments and his goals for the year. Others keep a spreadsheet, a notebook, a list pinned to the top of their inbox, or a Friday hour set aside to go through it all.

Companies build these systems too, at a larger scale. Sull's 2015 study found that more than 80 percent of the companies it studied have at least one formal system for managing cross-unit commitments, and that 20 percent of managers believe those systems work well all or most of the time.

The strain in every one of these systems is the one I ran into with my agents. A tracker knows what someone put into it and nothing more. The same holds for a project plan, a status meeting, and a chief of staff who wasn't on the call. Each depends on a person noticing that a decision was made, translating it into an entry, and coming back to update it as the work moves. The chief of staff became the system of record for the executive's decisions because no software ever was. Most companies don't have a chief of staff, so the operator does that job too, on top of their own.

I like to write my own tools, and this summer I started watching where my time went: fixing a prompt that had drifted, reconnecting something that broke, rebuilding a piece after I changed something underneath it. I'd made myself the IT department for my own productivity. A homegrown tool is as reliable as the person keeping it alive, and it rarely survives past that one person.

Operators who build these are reaching for a record. They want a place where each decision lives with the reasoning behind it, where every commitment it created is tied to the person who made it and the goal it serves, and where the state of each one stays current because the system is watching the work. The tracker was always the operator's attempt at that record, and keeping it current by hand wears it out. A record that keeps itself current lets delegated work carry through, because the operator finds out about a slip while it can still be fixed.

Two Ways In

Two kinds of people live inside that week, and they come to the problem from different directions. Inside Brief we call them the Decision Owner and the Context Integrator.

The first is the leader whose calls create the work: the CEO, the COO, the general manager, the CFO who runs operations. Their need is narrow. They want what they delegate to get done. Done belongs to the person who asked for the work. The pain they name first is Friday, the commitment that lapsed while they believed it was handled. They'll take on a system that fixes that, as long as it runs without their feeding it.

The second is the person who carries the context so the leader can decide. Sometimes that's a chief of staff. In the industrial companies we've interviewed, it's as often an operations lead, a program manager, or the person in IT or business intelligence who ended up owning the leadership team's tracking because somebody had to. They need to stop rebuilding the picture by hand every morning and chasing the same commitments every afternoon.

Either one can start, on their own work and without anyone's approval. The leader judges it by whether Friday's lapse got caught before it was due, and the person carrying the context by whether they walked into Monday's leadership meeting with the picture already assembled.

Both of them are managing the same thing. Sull and Charles Spinosa made the case in Harvard Business Review in 2007 that every company is a network of promises, and that managing execution means cultivating and coordinating those commitments systematically. That framing has held up better for me than most of what came after it. The leader makes the promises and depends on the ones made back. The person carrying the context keeps track of the whole network so nothing in it goes quiet.

Proof on one person's own work earns the next conversation, which is about the leadership team. It takes both of them to make a system hold there. The leader brings the mandate, because what they delegate is what the whole team is trying to get done. The person carrying the context brings the daily practice that makes the system part of how the team works. Department and function heads carry it from there to their own teams, once they see the commitments made to them landing.

What the Leadership Team Commits To

When the conversation reaches the leadership team, the team has to decide whether it will run its decisions through one record, because the need lives there. The organization's delegated work carrying through is the whole team's job, and no single function owns it.

I made the point in our newsletter last month that a leadership team can produce bookings, burn, and headcount on request and still can't say how many promises it has open, because nobody built the thing that produces it. Goals have the same problem one level up. Sull, with Charles Sull and James Yoder, surveyed the people responsible for executing strategy across 124 organizations, and 28 percent of those executives and middle managers could name three of their company's top strategic priorities (MIT Sloan Management Review, 2018). My read is that the goals were written down somewhere, and nothing connected them to the decisions and commitments being made against them every day. A goal needs the same four things as any decision meant to produce a result: an owner, a date, the number it should move, and someone checking whether it did.

A leadership team that runs its decisions through one record gets both numbers back: the promises it has open, and which goal each one serves. When it comes time to put that in a budget, the case to a CFO fits in one sentence. The company already pays for decided work that doesn't carry through, in rework, in decisions made twice, and in meetings held just to check, and this system is how that work gets done.

A Discipline With No System

The operators in this essay are practicing a discipline by hand, with spreadsheets and reminders and Friday hours, because the software they needed didn't exist.

It can exist now. A system can read the email, the calendar, the meeting, and the chat where decisions get made, recognize a decision and the commitments it creates, and keep that record current without anyone retyping it. With the record in place, it can anticipate which commitment is about to slip, while there's still time to act.

That system holds the most sensitive context in the company: what the leadership team decided, who committed to what, and which relationships are under strain. In October I wrote that AI adds the governance of actions to everything we learned getting enterprises comfortable with Open Source and cloud, and a system that holds an operator's context is the first place a company has to draw the limits on what AI may do.

My agents taught me that work needing one history needs one owner. The operator has been that owner for every company I've run, holding the history in their head. Now a system can hold it with them, and a leadership team can ensure what gets decided, gets done.

The Executive Intelligence Papers is a series of seven essays by the founders of Brief on the formation of a new category of software.