The Slowest Link: Accountability on a Team of Humans and AI

One of the questions I ask myself often on the teams I run is, "What is the worst or weakest part of the team?" The truth is, we can only run as fast as the slowest part of the process. I'm constantly trying to find that slowest link, the thing that jams us up.

Anyone who has ever run a team knows it gets harder as you add more workers. That problem is exacerbated as we add more and more artificial intelligence agents to the mix. The challenge with AI is that it can move so much faster than humans, which means it runs into the roadblocks and obstacles much faster than it would at the speed of a human. (I wrote about that hazard in Supersonic Broken Processes.)

Deconflict First

I've mentioned this in previous posts, but one of the most critical things to do is to deconflict contradictions across the team. When we first started coding with artificial intelligence, the first thing I did was have AI inventory all of the ways we contradict ourselves. How does Charles or Ryan or Kevin write an integer to a database? Let's figure out what becomes our way instead of having different standards across the team.

As I described in Fish in a Box, I continued that business throughout the whole of the organisation, looking at how we market, how we contract, how we engage on social media, and how we interact with each other on the team. I developed a set of norms that we call The WitFoo Way, and we version those norms in canon as they change. They do change often, because the world is changing, the market is changing, and our business has to change with it. Our norms have to expand to meet the new edge cases we face with our customers, our team and our partners.

In adding artificial intelligence to the mix of our teams, we needed to figure out how to coordinate between humans and AI, and how to do it while respecting the limitations and the risk of each.

Places, Names and Channels

Three decisions came first.

1. We chose tools for different things. For synchronising data across the team, we used the legacy platforms we've been using for human-to-human collaboration for years. We do most of our document storage in SharePoint, with different sites and different folders with different permissions for different teams (it also has the merit of being distributed across all of our systems). We continued that as we added artificial intelligence into the loop, so documents still go into the right place. Those places have permissions that are granted to the people and to the AI.
2. We issued first-class personas to the AI agents. We gave them names, we gave them credentials, and we built permission sets for those agents based on what work they would be doing and on the risk they brought in. We also want to be able to audit who is doing what at the level of the agent, at the level of the human, or at the level of the human controlling the agent.
3. We found ways for everyone to talk. We needed ways for humans to talk to humans, for humans to talk to AI, and for AI to talk to AI. For human-to-human collaboration, we tend to use Slack. We've used it since we started WitFoo, and it's a great format. When the AI needs to talk to the humans, it has permission to talk in some channels to some of the humans. For AI talking to AI, we created an AI bus.

The AI bus is a file share that lets the agents send messages to one another through deterministic software, which checks that the communications are in accordance with policy and norms. When one agent that has permissions to Folder A requests information about Folder B (which it cannot access, but another agent can), that request goes through a pipeline that checks it for compliance and puts a human in the middle for approval as appropriate.

Three Layers of Tasking

The next thing to deal with is tasking. We have three layers that we use:

1. Support tickets through Zendesk
2. Code issues through GitHub
3. Microsoft To Do lists via Outlook

Essentially, Zendesk lets us coordinate with external parties like customers, partners and sales. GitHub is internal, for the development team. The to-do lists are shared across the whole business internally. We have shared lists between each of us. I have tasking that I give to my reports; when I have new tasks, I add them to their list, and then we coordinate off of that.

So, with:

• a way for AI to communicate with AI
• a way for AI to communicate with humans
• a way for humans to communicate with AI through harnesses like Claude Desktop or Claude Code
• a way for humans to communicate with humans via email and Slack
• and access for both AI and humans to all of those things

we've solved for communication and tasking with permission sets, applying to AI access the same least-privilege philosophy we would use in managing human access.

Canon Says Who Approves What

We can also limit the visibility that each worker has. Through canon, we establish how information can be shared between parties and how changes to canon are approved, and we can explain why a workflow was rejected. Canon also establishes who is in charge of approving what, whether that's legal approval, HR approval, the advisory board, fiduciary officers or the board of directors.

We also run adversarial agents that look for violations of canon and boil those up to human managers. (I showed a small version of that idea in Adversarial Code Review Example with Claude.) With all of that tooling in place, we're able to create tasking that's assigned to humans and AI, and we're able to monitor the output to ensure it complies with all of the requirements of canon.

Measuring the Team

Finally, we're able to start monitoring the performance and bottlenecks of the teams. We have agents running on scheduled tasks to gather and analyse different metrics, ranging from:

• how many software launches occurred
• how many website visits there were
• the effectiveness of social media engagements
• revenue changes
• impacts to cost and accounting

They put those into formats that can be used in executive reports. Every week, team-wide reports are also posted into Slack, covering the performance metrics that are important to the business. At a secondary level, managers maintain, via the task lists, the expectations of the people they're managing. I've been preaching measurement since Metric Driven Development; the difference now is who gathers the numbers.

The Daily SITREP

A core skill that I run every day is called SITREP, which is short for situation report. It's an idea I borrowed from my time in the U.S. military.

A SITREP goes and pulls all of the information about operations and readiness from all of my data sources. For me, this includes:

• looking at the accounting software
• looking at CRM transactions
• checking my email
• checking Slack
• looking at the progress of research and development tasking
• checking on the movement of tasking to each one of my reports

It gives me a daily understanding of what is on target and what is lagging behind. For the things that are lagging behind, I regularly do a detailed analysis of what the bottleneck is.

I have a great team, so it's rarely a problem with motivation or effort from my contributors. For teams where that is an issue, it becomes immediately apparent, because as workflows move through our tasking, the effort and time spent by each person is logged too. We also create audits of where they hit a roadblock, so my primary job as a manager is to remove those blockers for my team. Oftentimes that means building better tooling, providing better data or giving better scope to the team. It also means giving feedback to my reports and their contributors on how well they're tracking against proposed deadlines.

What happens is, every day, I'm able to understand where frustration and stagnation exist inside our teams. Then we can take a pause, look for ways to better tool the workflow or better staff it, and continue on to the next cycle.

Extreme Accountability Is Liberating

While this extreme accountability may be scary at first, it is rather liberating for a team that's devoted to getting a mission accomplished together. We know how to ask each other for help. We know how to detect when our teammates need help, and we have the capability to work together to build solutions that remove blockers and obstacles. Collectively, this has let us spin much faster.

The other benefit is that each contributor has an artificial intelligence between them and the work. It has an endless level of patience, which I can't honestly say is true of me. The AI will give a detailed explanation, in the tone and language each contributor needs, of what the gap is, what's missing and how it can be resolved. On my worst days, I can just scream, "Just do it, get it done," or give a flat no to an otherwise good idea.

Also, the AI can retrieve information and contextualise it faster than I can. I've been running WitFoo for ten years, and there are many things that I forget, or that I don't have the foresight to bring to mind in a given conversation.

Having well-organised documentation, norms and expectations allows us to spin much faster than we can when I'm the single point of failure. In the end, it's meant my team feels more empowered, they feel more respected, and the quality and velocity of our work are greatly improved. None of this replaces the people. It's the same argument I made in The OODA Loop Strikes Back: the machines are there to make the humans better.

Why This Was Easier for Us

I will admit that building this out has been a bit easier because of the composition of our team. Many of the decisions in building out The WitFoo Way I was able to make unilaterally. We have a very technical team that's able to pick up new tooling much faster than an average team can. Finally, much of my team is made up of U.S. military veterans, who have a high capacity for resilience, for taking criticism and for looking at the bigger picture.

Even so, there were a lot of experiment and failure cycles that let us build this out, and it was a pretty painful process, even with our small team that has a high level of respect for each other.

Wrap Up

Essentially, the steps we took were:

1. Agreeing on what our norms and our values are. To do that in a concrete, defined way meant, for us, developing The WitFoo Way canon: not just giving it lip service, but making sure every idea we have is maintained and approved in a process that is rigorous but also flexible.
2. Creating AI teammates the way we treat human collaborators. At the technical level, we give them permissions and access that are customised to their capabilities and their responsibilities, and then put in mitigating controls in case something happens, such as an insider threat, prompt injection or general malfunction.
3. Giving everyone coordination tools. With the permissions in place, the AI needs the same things we needed as human beings: places to share documents that have different levels of privacy depending on the audience, ways of handling tasking to assign and track the completion of work (how long it took and how it was prioritised), and channels of communication that are effective for the participants.

By understanding the strengths and weaknesses of my team, and the strengths and weaknesses of our new team members, the artificial intelligence, we're able to build a mechanism that brings out the best in all of us while keeping each other accountable and improving our collective judgement.