Rohan, the CEO of Northstar, woke up to discover that two of his teams had given their most important customer wildly different commitments.
This sort of incoherence is common within large companies like Google. But Rohan was shocked to find it within his 500-person startup. It started happening soon after they aggressively adopted AI.
I spent a decade doing deep learning research at Google, and worked on LLMs since before they were cool. After leaving, I’ve been curious about the main bottlenecks for diffusing AI into the economy.
AI allows each employee to Do More Stuff. Giving each employee a “team” of agents sounds great on paper. But someone has to integrate all this work in a reasonable way. That’s hard! It requires each employee to increase their capacity for leadership, which grows slower than token spend.
Aggressively deploying AI into a startup before it’s ready simply imports Big Company Problems without Big Company Benefits. It’s common to see startup CEOs or founding engineers burn out because they rapidly become single points of failure.
Fortunately, this dynamic is neither inevitable nor insurmountable. This essay explores how Rohan, the fictitious CEO of Northstar overcomes this dynamic using a practice called Integration Agreements. Integration Agreements gradually grow his capacity for leadership, and unlock more value creation with AI.
Tokenmaxxing has its cultural moment
Rohan realized that LLMs would profoundly change the nature of work, and the shape of organizations. But he didn’t know how yet, and neither did his employees. So he imitated many other CEOs and instituted token dashboards within Northstar. He encouraged everyone to try injecting AI into every single one of their tasks and workflows.
It wasn’t cheap, but it started to work. All their productivity and financial metrics started improving.
It was unbelievable how much a single engineer could ship in a few days. Yet Rohan started feeling like the captain of a ship that wasn’t his. One day, he found three teams in his 500-person startup trying to launch the same thing! So he centralized the launch process, and only allowed launches with his personal sign-off.
Centralization worked for a while, but the queue of launch reviews started piling up. Everyone felt stressed by the delays, and the company lost some important deals.
So he relented and let teams manage their own launches. Everyone started moving a lot faster. But he found it harder to keep track of everything. He created various processes in response. For example, he asked everyone to document all their decisions, and share all their documents with him by default. Naturally, teams started using AI to deal with such overhead. Rohan was then forced to use AI to stay on top of this deluge.
AI amplified his visibility, and he started seeing incoherence everywhere. But he didn’t want to go back to centralization. So he kept adding more processes, and everyone kept using more AI to cope.
Zooming in on Rohan’s specific pattern
Let’s look at this interplay of centralization and decentralization by zooming in on two specific incidents.
Alex and Peter were the VPs of Northstar’s Applications and Platforms orgs respectively. Applications sold specific workflows to customers, and Platforms built horizontal infrastructure. Both teams relied on each other, and both VPs reported to Rohan.
Peter sent Rohan’s centralized launch process a plan for a new agent control plane. Rohan immediately noticed that Peter’s plans materially conflicted with Alex’s recent plans. Moving forward without fixing the plan would affect their largest customer. Instead of asking Peter to fix it, Rohan spent all weekend integrating each team’s roadmap. He used AI to sift through all the details, and sent each VP updated roadmaps.
Fast forward to when things were more decentralized. Rohan’s AI flagged one of Alex’s launch documents. They contained discrepancies with Peter’s team, which if left unresolved, would have materially affected the company’s strategy. He was too overwhelmed from other escalations to get personally involved. So he became furious with Alex for creating another “mess”. He blamed him for it, told him to “do better”, and to “figure it out” without more elaboration.
Yet another time, Rohan’s AI flagged an unfinished PRD for a company-critical project. He started dropping lots of comments and edits before anyone had asked him to. Employees eventually learned to carefully manage Rohan’s Slack access, and the documents he had access to.
The Meridian Incident
Meridian was Northstar’s largest and most important customer. Losing them would likely cause other big customers to follow suit.
Applications had pitched Meridian’s Sales and Finance leadership a set of bespoke workflows that’d immediately create value. Platforms had pitched Meridian’s IT leadership a single control plane for governing the company’s AI agents. Northstar was a trusted vendor, and Meridian quickly funded and staffed both projects. Applications and Platforms had each told Meridian that both projects would interoperate soon, and were complementary. It turns out they weren’t.
Meridian realized a few months later once its own teams started running into each other. The workflows created by Applications would eventually interoperate with Platforms, but not for another 18 months. Till then Meridian would have to staff and manage the integration themselves. They were not happy, and escalated to their CIO. The shocked CIO then started blowing up Rohan’s phone with DMs.
Rohan had no idea that the two teams had such interoperability issues. Every launch review he’d read had used the words “imminent” and “complementary”. He immediately apologized to the CIO and bought himself some time.
Rohan was furious. He started poring over every document related to the projects. The two teams had spent months talking past each other. But despite their confusion, they’d painted a rosy picture for Rohan. He’d believed them because he was already too overwhelmed. He was about to launch himself into fixing this mess, but something in him stopped himself.
Rohan’s dilemma
Rohan wanted to grow his company as fast as possible, but this incident was a wake-up call. Things were not okay.
Part of him desperately wanted to rescue Alex and Peter from this mess. He was already so exhausted. But he was scared that if he didn’t, they’d do this all over again. And Northstar would pay the price. He deeply valued his company’s integrity.
Another part of him was furious with them. They were senior executives, and this was a massive fuck up. They should have taken care of this without him. So he wanted to blame them for all of it. He was scared that if he didn’t, they wouldn’t take responsibility for this failure. He valued accountability, and wanted his company to be a place where people would take ownership for their actions.
To understand why he was stuck between rescuing or blaming his reports, we need to understand how he got there.
Why was this incident a big deal?
My executive coach, Brian Whetten, defines a commitment as an honest agreement made between two people to produce a specific outcome by a specific time. Every company, including Rohan’s, is a web of commitments organized around a value chain. Every incremental commitment creates a foundation upon which more complexity can be built. Companies formalize these commitments via artifacts like product roadmaps, PRDs or launch calendars.
Northstar’s incompatible commitments materially damaged Meridian’s ability to deliver on their own commitments to their own customers. This was untenable behavior from one of their vendors.
Why was it hard for Northstar to make coherent agreements?
Keeping its own commitments coherent required Northstar to coordinate context across a lot of busy people.
We define context as not just what a person knows, but why and how they know it. For example, I might believe that my last sales call didn’t land. But why did I feel it was off? Or perhaps I believe that arranging my pitch deck in a specific way would be more convincing. But why do I believe that?
Our conscious beliefs are supported by a vast web of tacit and unconscious knowledge. When we use the word context, we’re using the full spectrum of conscious and unconscious knowledge that shapes how an individual frames a situation.
We can’t share our full contexts with each other, because we can’t read each other’s minds. We’re forced to compress and represent our context into various forms of content.
We define content as the lossy compression of one’s context so that it can get legibly communicated to others. e.g. slides, documents, code, etc.
Employees within a company are able to meet their commitments to each other by compressing their context into content. This lossy compression, and its ensuing decompression, is a fundamental limitation within human organizations. Larger companies have more context to manage because there’s more people doing more stuff. They have to coordinate and manage more complex games of telephone to continue meeting their commitments.
My executive coach Brian Whetten defines leadership as the capacity to take accountability for delivering specific future results with integrity. There’s only so much an individual can deliver alone. Leaders help an organization by holding space and integrating competing and contradictory contexts. They turn that integrated understanding into clear content that aligns the actions of many people towards specific goals. The best leaders are those that grow this capacity for integrating context in others.
Why does AI need more leadership?
In the pre-AI world, we used various heuristics for deciding whether a piece of content was “polished”. “Polished” documents used to be hard to make. “Polish” was a trustworthy heuristic for creating commitments. AI violates that assumption.
AI allowed everyone to create substantially more polished-looking content, even if its context was unintegrated. Existing job roles and token dashboards incentivized creating more content. This surge of unintegrated content overwhelmed peers and leaders with context they needed to integrate. To cope, everyone was tempted to make dishonest agreements or incoherent commitments.
We define slop as this polished, but flawed content. We then define a company’s integration debt as a measure of the breadth and severity of the slop it both produces and consumes.
In the pre-AI world, larger companies needed more leadership capacity to stave off integration debt, because they produced more content. Rapid and ubiquitous deployment of AI within a startup is analogous to artificially increasing headcount, because fewer people can produce far more content. Northstar started drowning in slop and integration debt because it didn’t realize this.
It was actually worse in Northstar’s specific case. Rohan was deeply committed to making Northstar “AI-native”. That is, deeply integrating LLMs into every single Northstar workflow. Every quarter saw a natural increase in the underlying frontier models because of the LLM arms race. Therefore, every quarter saw an increase in complexity of content produced across the company, and the context everyone had to integrate.
Becoming AI-native before Northstar had sufficient leadership capacity doomed the company to drown in slop. This overrun of slop precipitated the Meridian incident.
Integration debt led to dependence on Rohan
Rohan had built Northstar from a single-person startup into a 500-person unicorn. They’d swept most of the Fortune 500 logos. And it’d mostly been on his inhuman ability to hold an entire company’s context in his head. It might have even worked for a few more years if AI hadn’t artificially increased his company’s “headcount”. Unfortunately, this pattern had made the company dependent on his capacity to integrate disparate contexts across the company.
This dependence led to a vicious cycle. Rohan swooped in whenever anyone brought him content with integration debt. He’d heroically fix all their “mistakes” and tell them what to do. So his executives didn’t get practice resolving integration debt themselves. They kept sending him increasingly unintegrated content as the company grew. He’d keep grinding out clarity till he got overwhelmed, at which point he’d start blaming his reports. He’d chew them out and tell them to “figure it out” themselves. This trained his execs to consciously or unconsciously hide integration debt in the content they sent him. He wouldn’t always catch everything, and the debt would pile up. Eventually, the bill would come due. This burgeoning integration debt would inevitably make contact with reality, and cause a big fire. Rohan would then reactively drop everything else to try to put it out.
This entire cycle was “manageable” until AI amplified their integration debt. It ultimately precipitated into the Meridian incident.
Putting this all together - why was Rohan stuck?
Rohan didn’t know how to help his employees without attempting to “rescue” them. Each rescue wore him out, and the rescuing eventually overwhelmed him. At this point, he’d start blaming his reports for not “figuring it out” by themselves. Rescuing and blaming his reports shifted his attention from him, onto them.
He didn’t realize how avoiding reflecting on his own pattern of behavior was keeping him stuck.
Avoiding failure versus growing from failure
As CEO, he was the most powerful person within the company at shaping its culture. The amount of slop overrunning Northstar was a testament to his commitment in avoiding the implications of his own failures. Over the years, this shifted the entire company’s culture towards an avoidant tone.
Saving his company involved becoming consciously aware of this pattern, accepting it and practicing growing from his failures.
Consciously growing from failure meant reflecting and owning his complicity in each failure, while simultaneously inviting his reports to own theirs. This shift in perspective allowed him to help his reports without rescuing them or blaming them.
His old stance of avoiding failure was encapsulated in the question - “How can I fix what these people have done?”. His new stance was encapsulated by the question Jerry Colonna made famous in his book Reboot - “How have I been complicit in creating the conditions I say I don’t want?”
Integration Agreements
His practice of forming integration agreements with his reports allowed him to shift from avoiding his failures towards growing from them.
An integration agreement is a structured conversation which allowed Rohan and his reports to authentically integrate context with each other. These conversations allowed him to grow each report’s capacity for leadership, which in turn reduced their integration debt and dependence on him.
He created a habit of doing this practice whenever he felt a strong desire to rescue a failing project. Or when he felt a desire to blame one of his reports for not being good enough.
The practice involved inviting a particular report to a 1:1 conversation, and taking the following steps:
1. Taking ownership for his contribution to the failure.
He shared with his report the answer to the following question - What did I do, or fail to do, that made this specific problem harder than it needed to be?
He then took a moment to apologize for his lapse in leadership. He then followed that with listening deeply to any feedback his report had for him.
2. Discussing who was accountable for what.
He clarified what specific future results his report was still accountable for, and what Rohan needed to be accountable for.
3. Surfacing missing context.
He created a document with their specific responsibilities from the previous step at the top.
They then traced the most relevant parts of who they depended on to achieve those outcomes, and who depended on them. In particular, they tried to surface the most relevant unresolved dependencies and disagreements.
4. Creating properly resourced commitments.
They then worked through each unresolved dependency and disagreement to understand:
What needed to happen next?
Why did it need to happen?
Who would be responsible for it?
By when did it need to happen, and what would an honest check-in look like?
How could Rohan support his report in this process, and vice versa, without each rescuing or blaming the other?
This process rapidly brought all the integration debt to the surface, and created clarity for how it’d be dealt with.
What changed after doing this practice?
Let’s go back to the specific moments after Rohan’s interaction with Meridian’s CIO. He was tempted to go on a warpath and rescue his company. But this time, he slowed down. He reflected on how he was complicit in creating this existential incident for Northstar. He then scheduled a 1:1 call with Peter, the VP of Platforms.
Rohan started by taking ownership for his contribution to the situation, and apologizing for his actions. Specifically, for either attempting to override Peter and rescuing him, or for blaming him.
He then explained that he wanted to try something different during this 1:1. He explained the process and rationale of Integration Agreements, and led the two of them through the steps.
It turned out that Peter already knew about the 18-month incompatibility that Meridian ran into. He’d just assumed that if it was a genuine problem, Rohan would have caught it with AI like he’d always done. This was a revelation for Rohan. They worked through many other misunderstandings like this one.
Coming into contact with these misunderstandings was deeply uncomfortable for Rohan. Processing and integrating these misunderstandings brought forth so many implications and associated questions. This new information challenged both his perception of himself, his identity, and the story he’d had about his relationship to the company. But he couldn’t avoid it any longer. Sitting with this additional context tugged at him from all edges. It was as if his very being was being stretched to create space to hold it all. By the end, he felt a deep sense of grief, acceptance and satisfaction. They eventually walked away with a clear set of next steps. He felt a deeper sense of clarity than he’d ever had in his 1:1s with Peter.
Rohan did similar 1:1s with everyone involved with the Meridian incident. It turned out there were many, many misunderstandings and miscommunications. It took them weeks to fully align on a new plan for Meridian. By far the biggest bottleneck was giving everyone space and time to process all this new context.
They all agreed that Northstar wouldn’t be able to meet their original conflicting commitments with Meridian. They decided to offer Meridian a full refund. Applications narrowed the pilot to just two workflows, and Platforms agreed to prioritize fully supporting it. Meridian’s CIO was still pissed. But he accepted the revised plan instead of canceling the relationship altogether.
Northstar’s culture gradually began to shift. His reports started proactively surfacing important issues sooner. He got better at holding back his instinct to rescue them or blame them. He wasn’t perfect, but he treated the integration agreements as a habit to build. Eventually, his reports got better at integrating the relevant context themselves. The company started feeling like his again. But this time, without the overwhelming pressure that everything relied on him.
Before long, even individual contributors started getting practice creating integration agreements with each other. The company as a whole increased its capacity for leadership. This greater leadership allowed it to create far more value with AI than it could have imagined before.
Acknowledgements
Brian Whetten - for teaching me essentially everything in this essay.
John Vervaeke - a lot of his deep theory on relevance realization, 4Ps of knowing, etc. heavily influenced the ideas in this essay.
Jerry Colonna’s book Reboot, where I got the question “How have I been complicit in creating the conditions I say I don’t want?”
David Chapman and Charlie Awbery - for various discussions around the interplay of emptiness and form that shaped how I think about context.
Ian Tracey for a fun conversation at dinner that led to this title. The title is inspired by an old ML paper from Google Research.