Stop Scaling Dysfunction: The AI and OKR Trap.

AI won’t save your dysfunctional company. Neither will OKRs.

Both are accelerators. Catalysts. They take whatever you’re already doing and amplify it, for better or worse. If your processes are solid, they’ll scale your excellence. If they’re broken, they’ll scale your dysfunction at unprecedented speed.

I’ve watched this play out dozens of times with my consulting clients. Let me show you what’s really happening.

A SaaS company came to me last quarter, excited about their AI implementation. Their marketing team was producing 10x the ad variants they used to create manually. Sounds impressive, right?

Here’s what happened: They went from creating 5 carefully crafted ads per campaign to 50 AI-generated variants. Testing cycles accelerated. They discovered winners faster. Conversion rates improved by 23%.

This is AI working as intended: amplifying a competent team’s ability to experiment and optimize.

Now contrast that with another client, a B2B software company. They deployed AI to help with documentation. Within two weeks, they had:

• ~40 process documents nobody read

• 83 meeting summaries nobody referenced

• Hundreds of pages of AI-generated “best practices” that contradicted each other

Their Notion became a graveyard of content. The problem? They already had a documentation problem. People didn’t read or maintain docs before AI. Now they just weren’t reading or maintaining more docs, faster.

AI didn’t create their problem. It revealed it at scale.

OKRs work exactly the same way. They’re a mirror, not a magic wand.

I worked with a fintech startup that prided itself on “aggressive goals.” Their OKR process looked impressive on paper: quarterly objectives, clear key results, alignment meetings. But when I examined their actual goals, I saw the pattern:

Q1 Objective: Increase user acquisition

• KR1: Grow active users from 50,000 to 52,000 (4% growth)

• KR2: Reduce CAC from €45 to €44

• KR3: Improve onboarding completion from 68% to 70%

These weren’t aggressive. They were sandbags. The team had learned that hitting 100% of their OKRs meant bonuses and good performance reviews. So they gamed the system, setting goals they knew they’d exceed.

OKRs didn’t create this low-balling culture. They exposed it. The framework gave it structure and made it measurable, which actually made the problem worse because now mediocrity had a formal process.

Patrick Lencioni writes about this in “The Five Dysfunctions of a Team”: when you lack trust and fear conflict, any framework becomes a tool for self-protection rather than growth. OKRs in this environment become a theater where everyone pretends to stretch while actually playing it safe.

Eliyahu Goldratt’s “The Goal” fundamentally changed how I think about systems and speed. The central insight: every system has exactly one constraint, the bottleneck that limits overall throughput. Everything else is non-constraint.

Here’s the counterintuitive part: making non-constraints faster doesn’t improve system performance. It makes it worse.

Imagine a factory with five stations. Station 3 can process 100 units per hour. Every other station can process 200 units per hour. What happens if you speed up Station 1 to 300 units per hour?

You don’t get more output. You get more inventory piling up before Station 3. You get more work-in-progress. You get more complexity, more coordination overhead, more waste.

Station 3 is still your constraint. The factory’s output is still 100 units per hour. You’ve just made the system more chaotic.

This is exactly what happens with AI and OKRs when applied without understanding your actual constraints.

Share The Key Results Newsletter

Here’s the critical insight: Both AI and OKRs shift work downstream.

Before AI: Creating took 80% of the time. Reviewing took 20%.

After AI: Creating takes 20% of the time. Reviewing takes 80%.

If reviewing is your constraint, if your team lacks the judgment, standards, or capacity to evaluate quality, then AI just overwhelmed your bottleneck. You accelerated the non-constraint (creation) and starved the constraint (quality control).

The result? Inventory piles up. In this case, the inventory is documents nobody reviews, code nobody maintains, content nobody validates.

Tom DeMarco captured this in “Slack”: teams need capacity to think, review, and improve. When you optimize for pure throughput, you eliminate the slack needed for quality work. AI promises to give you slack by automating creation. But if you fill that slack with more creation instead of better review, you’ve missed the point entirely.

The same applies to OKRs:

Before OKRs: Teams spent most of their time executing without much strategic planning. Decision-making was distributed and implicit.

After OKRs: Teams spend significant time defining objectives, aligning across departments, and reviewing progress. Decision-making becomes explicit and centralized.

This shift only works if your constraint was lack of strategic alignment. If your constraint was actually execution capability, organizational trust, or decision-making speed, then OKRs just made your real bottleneck worse while optimizing something that wasn’t limiting you.

I saw this at a manufacturing software company. They had brilliant engineers who understood the domain deeply. Their constraint wasn’t knowing what to build, customers told them constantly. Their constraint was organizational dysfunction: teams didn’t trust each other, middle management hoarded information, and executives changed direction every six weeks.

They implemented OKRs hoping it would create alignment. Instead, it created a new overhead process that consumed 15% of engineering time in planning and alignment meetings while doing nothing to address the trust deficit. They optimized a non-constraint (strategic clarity) while ignoring the actual constraint (organizational trust).

The engineers became cynical. Leadership became frustrated. The OKR process became something to endure rather than embrace.

At Arduino, we faced this exact challenge when considering automated testing tools. The tools would let us run tests 50x faster. Great, right?

Not if we wrote bad tests. Not if we didn’t understand what we were testing for. Not if we couldn’t interpret the results effectively.

Andy Grove understood this at Intel. In “High Output Management,” he describes the breakfast factory thought experiment. Each step: boiling eggs, making toast, pouring coffee, has a different cycle time. The constraint determines when breakfast is ready. If you serve toast faster but eggs take longer, breakfast doesn’t arrive earlier. It just gets cold.

Grove’s insight: optimize the constraint first. Everything else is secondary.

One of my consulting clients, a manufacturing software company, illustrates this perfectly. They implemented AI-powered code generation for their engineering team. Productivity metrics soared. Pull requests tripled.

Then technical debt exploded. The AI was writing functional code, but not maintainable code. The team hadn’t established architectural guidelines. They hadn’t invested in code review processes. They hadn’t built the quality gates.

Their actual constraint wasn’t code creation speed. It was architectural decision-making and technical leadership. They had two senior engineers who understood the system deeply enough to make good architectural choices. These two people were already overloaded reviewing critical changes.

AI accelerated creation from perhaps 10 pull requests per week to 30. But the two senior engineers who could properly review architectural implications didn’t scale. They became overwhelmed. Review quality dropped. Bad decisions got merged.

The AI accelerated their ability to create code. It also accelerated their accumulation of technical debt from 6 months to 6 weeks.

They optimized a non-constraint (creation speed) and starved their actual constraint (architectural review capacity).

There’s a pattern: companies adopt tools and frameworks as performance rather than practice.

The language is there. The rituals are there. The Jira boards are perfectly groomed. The OKR documents are beautifully formatted. The AI tools are integrated into every workflow.

But the substance is missing.

This is what I call Management Theater, the performance of good management without the actual work of good management.

Are we real managers or just acting as such?

Real management is hard. It requires:

• Honest conversations about capability gaps

• Difficult trade-offs to decide on priorities

• Sustained attention to developing people

• Willingness to confront dysfunction

• Discipline to say no to mediocrity

Management Theater lets you skip all that. You implement the framework. You adopt the tool. You perform alignment. But you never do the underlying work of building capability.

I watched this at a logistics company before they got serious about OKRs. Their quarterly planning was elaborate theater. Two-day offsites. Facilitated workshops. Beautifully designed strategy documents.

Then everyone went back to their desks and did whatever they were going to do anyway. The goals were decorative. The real decisions happened in hallway conversations and last-minute firefighting.

When they finally implemented OKRs successfully, it wasn’t because they got better at the OKR process. It was because their new COO had the credibility and spine to call out the theater. She started asking uncomfortable questions in planning meetings:

“That’s a nice goal. How specifically will you achieve it?”

“What are you going to stop doing to make room for this?”

“Last quarter you committed to something similar. What happened?”

People hated it initially. Several senior managers left. But the ones who stayed started having real conversations. The goals became real. The accountability became real.

The OKR framework didn’t create this transformation. The hard work of building a culture of honest performance conversations did. The OKRs just gave that culture a better structure.

Most companies overestimate their competence by at least two levels. This is the root cause of failed AI and OKR implementations.

Here’s a framework I use to assess organizational capability:

Level 1: Unconscious Incompetence You don’t know what good looks like. You can’t distinguish quality from mediocrity. You implement tools hoping they’ll solve problems you haven’t accurately diagnosed.

Level 2: Conscious Incompetence
You recognize gaps but haven’t built capability to close them. You know your documentation is poor, your goals are sandbags, your code reviews are superficial. But you don’t yet have the skills or processes to fix it.

Level 3: Conscious Competence You’ve built specific processes and capabilities. Quality is maintained through deliberate effort and attention. Things work, but they’re fragile and dependent on key people and constant vigilance.

Level 4: Unconscious Competence Quality is embedded in culture and systems. People do the right things naturally because the organizational muscle memory is strong. This is rare.

Most companies think they’re at Level 3. Most are actually at Level 2. Some are at Level 1.

This matters because AI and OKRs only work at Level 3 or above.

At Level 1 and 2, these tools accelerate your incompetence. You produce more bad documentation faster. You set more mediocre goals with better formatting. You move faster in the wrong direction.

The B2B software company with the documentation problem? They were at Level 1. They genuinely couldn’t tell good documentation from bad. They thought completeness equaled quality. They measured documentation by page count rather than utility.

When I asked, “Who’s your documentation for?” they said, “Everyone.” When I asked, “When was the last time someone actually used a process document to solve a problem?” they couldn’t answer.

They needed to climb from Level 1 to Level 2 developing awareness of what good documentation actually looks like before AI could help them.

Both AI and OKRs require high-trust environments to work. Without trust, they become instruments of dysfunction.

Consider what trust actually means in an organizational context:

Trust = (Credibility x Reliability x Intimacy) / Self-Orientation

This equation comes from David Maister’s work on professional services, but it applies universally.

Credibility: Do people believe you know what you’re talking about?

Reliability: Do you consistently do what you say you’ll do?

Intimacy: Can people be vulnerable and honest with you?

Self-Orientation: Are you focused on the collective good or your own interests?

Low-trust organizations fail with OKRs because:

• People set sandbagged goals to protect themselves (low intimacy, high self-orientation)

• Commitments aren’t kept, so planning becomes meaningless (low reliability)

• Strategy discussions lack honest input because people fear consequences (low intimacy)

• Political maneuvering trumps actual performance (high self-orientation)

The fintech startup with the sandbag goals had exactly this problem. Their CEO had fired two VPs in the previous year for “missing targets.” Everyone learned: set achievable goals, hit them, survive. The OKR process became an elaborate mechanism for self-preservation.

Low-trust organizations fail with AI because:

• Nobody wants to admit they can’t review AI output effectively (low intimacy)

• Quality standards aren’t enforced consistently (low reliability)

• People optimize for metrics rather than outcomes (high self-orientation)

• Knowledge hoarding prevents effective quality control (low intimacy, high self-orientation)

The manufacturing software company with the code generation problem? Their two senior engineers knew the AI-generated code was accumulating technical debt. But they didn’t have the social capital or organizational support to slow down the process. The VP of Engineering was celebrating the productivity metrics in board meetings. Raising concerns would have made them look like they were resisting innovation.

Low intimacy, high self-orientation from leadership. The engineers chose silence. The technical debt grew.

The companies that succeed with both AI and OKRs share common characteristics. They built the foundation before adding the accelerator.

The Ad Optimization Success Story:

That marketing team I mentioned earlier? Here’s what they had in place before deploying AI:

• Clear brand guidelines and voice documentation

• Established A/B testing methodology with statistical rigor

• Data-driven decision framework with defined success metrics

• Weekly review cycles with clear approval criteria

• Senior creative director with final approval authority

• Culture of constructive critique on creative work

AI didn’t replace any of this. It made the creation step faster so they could test more hypotheses. The judgment, strategy, and quality control remained human.

More importantly, they knew where their constraint was: generating enough variants to test different messaging approaches with statistical significance. Creation speed was genuinely limiting them. They had the review capacity, the testing infrastructure, and the decision-making framework. They just needed more creative variants to test.

AI solved their actual constraint. It didn’t overwhelm a hidden bottleneck.

The OKR Success Story:

I worked with a logistics company that implemented OKRs after years of traditional goal-setting. They succeeded because they already had:

• Honest performance culture (people discussed failures openly in post-mortems)

• Strategic clarity (leadership had a coherent 3-year vision)

• Trust between teams (weekly cross-functional standups had built relationships)

• Data infrastructure (they could actually measure key results in real-time)

• Decision rights (people knew who owned what decisions)

OKRs gave them a better framework for something they were already doing well. The framework amplified their existing strengths.

But here’s what made it really work: they started with a pilot. One division, one quarter. They used it to discover their actual constraints.

Turned out, their constraint wasn’t goal-setting. It was mid-quarter adaptation. Their business was volatile enough that quarterly goals often became irrelevant by week 8. They needed more frequent strategic conversations, not better goal documentation.

They adapted the OKR framework to include monthly strategic reviews where they could pivot key results without feeling like they were “failing.” This wouldn’t have worked in a low-trust environment as people would have seen pivots as excuse-making. But in their high-trust culture, it enabled agility.

They identified their constraint (adaptation speed) and optimized for it. OKRs became a tool for strategic agility rather than rigid planning.

Before you deploy AI tools or implement OKRs, ask yourself:

For AI implementation:

1. What is our actual constraint? Is it creation speed or review capacity?

2. Can your team effectively review and edit the output AI will generate?

3. Do you have explicit quality standards, not just intuitive ones?

4. Are you prepared for review and quality control to become the bottleneck?

5. Do you have the discipline to reject AI output that doesn’t meet standards?

6. What percentage of AI output do you expect to use unchanged? If it’s over 50%, you’re probably at Level 1 or 2 competence.

For OKR implementation:

1. What is our actual constraint? Is it strategic clarity, execution capability, or organizational trust?

2. Can your leadership have honest conversations about what’s actually achievable?

3. Do you have the cultural safety to set ambitious goals and miss them?

4. Can you measure the things that actually matter to your strategy?

5. Are you willing to say no to good ideas that don’t serve your objectives?

6. Do people believe that performance matters more than politics in your organization?

If you answered “no” or “I’m not sure” to more than one question in either category, you’re not ready. You need to build the foundation first.

And here’s the hardest question: Are you willing to find out you’re not as good as you think you are?

Because that’s what these tools will show you. AI will reveal the gap between your quality standards and your quality control. OKRs will reveal the gap between your stated strategy and your actual priorities.

Most leadership teams aren’t ready for that mirror.

Here’s my recommendation based on watching this play out across dozens of companies:

Phase 1: Fix Your Fundamentals (3-6 months)

This is the hard work nobody wants to do. It’s not glamorous. It doesn’t make for good board updates. But it’s essential.

For documentation and content:

• Establish explicit standards for what good looks like (with examples)

• Build review and editing processes with clear quality gates

• Create a culture where critique is normal and expected

• Train people to evaluate and improve work, not just create it

• Identify your constraint: is it creation speed or review capacity?

For goal-setting:

• Practice honest performance conversations without OKRs first

• Build trust between teams through joint problem-solving

• Clarify your actual strategy, write it down in simple language a new hire could understand

• Learn to measure what matters, not what’s easy

• Establish decision rights so people know who owns what

• Create psychological safety for discussing failures

This phase feels slow. Good. If it feels fast and easy, you’re doing Management Theater again.

Phase 2: Test at Small Scale (1-2 quarters)

Don’t deploy AI or OKRs company-wide. One use case. One objective.

The logistics company did this right. One division, one quarter. They learned:

• Where their real constraints were (adaptation speed, not planning)

• What data they actually needed (leading indicators, not just outcomes)

• Which team behaviors needed to change (frequency of strategic conversations)

• What aspects of OKRs worked in their culture and what didn’t

The marketing team with AI did this right. One campaign type, one month. They learned:

• How much review capacity they actually had

• What quality signals to look for in AI output

• Which parts of their creative process AI could accelerate vs. where human judgment was essential

• How to adjust their approval workflows for higher volume

Both organizations treated the pilot as a learning exercise, not a proof-of-concept to justify a pre-made decision.

Phase 3: Scale Thoughtfully (6-12 months)

Only after proving it works at small scale should you expand. And even then, slower than you want to.

Why slow? Because you’re not scaling a tool. You’re scaling capability.

The logistics company took 8 months to roll OKRs across all divisions. Not because the framework was complicated, it’s not. But because each division needed to:

• Build the trust required for honest goal-setting

• Develop the data infrastructure to measure their specific key results

• Learn the discipline of monthly strategic reviews

• Adapt the framework to their specific constraints

The marketing team took 6 months to expand AI usage to all campaign types. Not because the technology was complex, it wasn’t. But because they needed to:

• Train the broader creative team on effective prompting techniques

• Expand review capacity by developing more creative directors

• Build quality assessment skills across the team

• Create feedback loops so they could continuously improve their AI usage

Scale is about capability, not deployment.

Let’s return to Goldratt. His methodology for managing constraints:

1. Identify the constraint. What’s actually limiting your system performance?

2. Exploit the constraint. Get maximum throughput from your bottleneck.

3. Subordinate everything else. Align all non-constraints to support the constraint.

4. Elevate the constraint. Increase its capacity.

5. Repeat. Once you elevate one constraint, another emerges.

Apply this to AI and OKRs:

If your constraint is creation speed: AI can help. But only if you have review capacity ready.

If your constraint is strategic clarity: OKRs can help. But only if you have the trust and honesty for real goal-setting.

If your constraint is review capacity: AI will hurt. Fix the constraint first.

If your constraint is organizational trust: OKRs will hurt. Fix the constraint first.

Most companies skip step 1. They don’t identify their actual constraint. They implement tools based on what’s trendy or what the board asked about. Then they wonder why nothing improves.

I worked with a SaaS company that was struggling with product quality. They implemented AI-powered testing tools to catch more bugs. Bug detection increased 5x. Bugs fixed per sprint stayed the same. Customer-reported issues didn’t decrease.

Why? Their constraint wasn’t bug detection. It was engineering capacity to fix bugs. The AI overwhelmed their bottleneck. The bug backlog exploded from 200 to 1000+ issues. Engineers became demoralized by the mountain of known problems they couldn’t address.

They eventually shut down the AI testing until they could hire more engineers. The constraint needed elevation before exploitation.

I’ve seen companies waste millions on AI tools that generate content nobody uses. I’ve seen companies spend years on OKR implementations that formalize mediocrity.

The problem is never the tool. It’s always the foundation.

Andy Grove didn’t implement OKRs at Intel until Intel already had:

• Rigorous operational discipline

• Data-driven decision making

• High trust between executives

• Clear accountability for results

• Culture of constructive confrontation

The framework worked because the culture could handle it.

The same applies to AI. It’s not a solution. It’s an accelerator. Make sure you’re accelerating in the right direction before you press the gas pedal.

Here’s what nobody tells you about organizational change: it’s not about adopting new practices. It’s about discarding old ones.

Your calendar is full. Your team’s attention is finite. Your organization has existing habits, processes, and cultural patterns.

Adding OKRs without removing something means OKRs become overhead. Adding AI without removing manual processes means AI creates duplicate work.

What will you stop doing to make room for the new capability?

Most companies refuse to answer this question. They pile new on top of old. Then they wonder why change initiatives fail.

The logistics company that succeeded with OKRs? They eliminated their existing quarterly planning process completely. No more two-day offsites producing strategy documents nobody read. The OKR cycle replaced it, not supplemented it.

The marketing team that succeeded with AI? They stopped having junior designers create initial concepts manually. The AI replaced that step entirely. The humans focused exclusively on review, refinement, and strategic creative direction.

Both organizations made room. They didn’t just add.

Not next quarter. Not when you have budget. This week.

1. Identify your actual constraint. Not the constraint you wish you had. The real one. Ask your team: “What’s actually preventing us from achieving better outcomes?” Listen to the answers you don’t want to hear.

2. Audit one process where you’re considering AI or have already deployed it. Map the workflow. Measure time spent on creation vs. review. Calculate your review capacity. Be honest about quality standards. Do you have them written down? Can people apply them consistently?

3. Review your last quarter’s goals. Not to celebrate or commiserate. To learn. Were they actually ambitious, or were they sandbags? Did you achieve them because you stretched or because you low-balled? More importantly: did achieving them actually matter to your business outcomes?

4. Have one honest conversation about organizational trust. Use Maister’s equation. Where are you strong? Where are you weak? This conversation will be uncomfortable. If it’s not uncomfortable, you’re not being honest enough.

5. Pick one quality gate you need to strengthen before adding any accelerator. Document what good looks like. Create a review process. Train people to evaluate quality. This is the foundation everything else builds on.

The companies that win with AI and OKRs aren’t the ones that adopt fastest. They’re the ones that build the right foundation first.

Stop looking for tools to save you. Start building a company worth accelerating.

• “High Output Management” by Andy Grove - The original OKR playbook from Intel. Pay particular attention to Grove’s breakfast factory thought experiment on constraints.

• “The Goal” by Eliyahu M. Goldratt - Essential reading on Theory of Constraints. Understanding bottlenecks changes how you think about organizational improvement.

• “Slack” by Tom DeMarco - On why organizations need capacity for thinking, not just execution. Required reading before implementing any productivity tool.

• “The Five Dysfunctions of a Team” by Patrick Lencioni - On why trust is the foundation for everything else. OKRs fail without it.

• “The Trusted Advisor” by David Maister - Where the trust equation comes from. Applicable far beyond consulting.

Got thoughts on this? Find me on LinkedIn. And if you’re implementing either AI tools or OKRs, let’s talk before you scale something you’ll regret.

Ciao,

Luca