On Constraints, Bottlenecks and AI

At any given time, the output of any system is limited by a single constraint, or bottleneck. Your organization's overall performance is dictated by the performance of this one component. Efforts to improve any other part of the system will be wasted until the constraint itself is addressed.

Another useful metaphor is a highway/motorway reduced to a single lane for roadwork. The entire flow of traffic, regardless of how many lanes there are before or after, is restricted by the throughput of that single open lane. This single lane is the bottleneck.

What Does Work: Prioritizing the Traffic

An ambulance, an express delivery truck, and a passenger car are all stuck in the traffic jam. They should not be treated equally; and we give emergency vehicles an explicit prioritization mechanism - the lights and sirens. A core strategy is to prioritize the high-value traffic. An effective system gets the ambulance (a critical bug fix for a major client) through the single lane first, even if it means delaying less critical vehicles. This is a crucial part of exploiting the constraint: ensuring it is always working on the most valuable tasks.

A Systematic Approach: The Theory of Constraints (TOC)

The TOC provides a structured method for this, the Five Focusing Steps:

1. IDENTIFY the Constraint: Find the single part of the process that limits the entire system.
2. EXPLOIT the Constraint: Get the absolute most out of the constraint, ensuring it is always working on the highest-priority tasks.
3. SUBORDINATE Everything Else: The rest of the system must align to support the constraint. All other processes must serve the needs of the bottleneck.
4. ELEVATE the Constraint: If the constraint still limits the system, invest resources (money, people, equipment) to improve its capacity.
5. REPEAT the Process: Once a constraint is resolved, a new bottleneck will emerge elsewhere. Continuous improvement is key.

A Real-World Example: The Software Development Pipeline

Consider a software development team where a single senior engineer is the bottleneck for code reviews.

Applying the Five Focusing Steps with prioritization in mind:

• Identify: The senior engineer's code review process is the constraint.
• Exploit: Create a priority queue for reviews. A bug fix for a major customer (ambulance) is reviewed before a new feature for a small client (express truck), which is reviewed before an internal documentation update (family car). The engineer's time is protected for this prioritized work.
• Subordinate: Developers finish and submit their work according to this priority system, ensuring the most critical code is ready for review first.
• Elevate: Train another developer to become a senior-level reviewer, or invest in automated tools.
• Repeat: Once code review is no longer the bottleneck, perhaps the QA testing environment becomes the new constraint. The process begins again.

This framework is a powerful tool for any executive. By systematically identifying, prioritizing, and addressing the true constraints within your organization, you can achieve significant performance improvements with focused, high-leverage effort.

Common Hurdles and Executive Mindset Shifts

While the theory is straightforward, implementing it can expose deep-rooted organizational challenges. An executive championing this approach will inevitably hear critiques like these:

• "The bottleneck isn't in my department or my budget." This is a common reaction from a manager in a non-constrained department. The mindset shift required here is understanding the Subordinate step. Your department's primary role may not be to maximize its own output, but to ensure the actual bottleneck is never starved for work or overwhelmed. Success, in this case, means throttling your own department's pace to match the bottleneck's rhythm. True leadership is seeing beyond your silo and serving the entire system.
• "My KPIs reward me for my local output." This critique highlights a fundamental conflict: the system rewards behaviour that harms the overall goal. If a department is incentivized to "keep busy" and maximize its own output, it will inevitably overproduce and flood the bottleneck. This is a call to action for senior leadership. KPIs must be realigned to reward contributions to the system's overall throughput, not just local efficiency. For example, a department's performance could be measured by its ability to deliver work to the bottleneck just-in-time and with perfect quality, rather than by the sheer volume it produces.

Consider these classic examples:

• Sales sells more than Services can deliver. The Sales team is rewarded with commissions for hitting a quarterly revenue target. They succeed, but the Professional Services team—the bottleneck—is now overwhelmed with implementation projects they cannot possibly staff. The result: the company hits a sales KPI, but generates a cohort of angry, poorly onboarded customers who will soon churn.
• Sales sells features that don't exist yet. To close a strategic deal, a salesperson promises a future feature, and their commission structure rewards them for it today. The Engineering team—the bottleneck—must now abandon its strategic roadmap to build a one-off feature. The local KPI (deal closed) is met, but the entire system's strategic progress is sacrificed.
• Developers create a backlog of unmerged code. Developers are measured on "features completed" or "lines of code written." To look productive, they finish their part and quickly start the next task, throwing their code "over the wall" to the next stage. This creates a massive inventory of unmerged, un-integrated code waiting for the true bottleneck: the single senior engineer who performs final reviews. Individuals look busy, but no real value is being delivered to the customer.
• Development creates a backlog of untested code. The Development team is measured on how quickly they can move tickets to the "Ready for QA" column. They rush code to the Quality Assurance team, hitting their velocity targets. However, the QA team—the bottleneck—is flooded with low-quality work. They can't keep up, and bugs are found late, causing expensive rework. The dev team meets its local KPI, but the system's ability to deliver reliable software grinds to a halt.
• "Only the CEO has the oversight of the whole system." This is often true, but it is not an excuse for inaction; it's a diagnosis of an information silo problem. While the ultimate view rests at the top, identifying a system-wide constraint requires leaders at all levels to collaborate. This necessitates creating transparency across the entire value stream, using tools like Value Stream Mapping. It demands a culture where managers are empowered and expected to understand how their team's work impacts the final customer outcome. It is a core responsibility of C-level executives, particularly the CTO and COO, to provide this system-wide visibility.

AI/Automation Reducing a Bottleneck (The Right Way)

In many companies, the Accounts Payable (AP) department is a bottleneck, (although sometimes this can be deliberate!) A small team must manually receive invoices, match them to purchase orders, check for errors, and get approvals before issuing payment. The entire company's payment cycle is limited by this team's capacity.

• The Bottleneck: The manual validation and approval work done by the AP team. ⚙️
• The AI Solution: An AI-powered automation platform is implemented to directly address this constraint. The system uses Optical Character Recognition (OCR) to read invoices, extracts the relevant data (vendor, amount, PO number), and automatically matches it against the company's financial records.
• The Result: Invoices that match perfectly are passed for payment automatically. Only the exceptions—invoices with errors or no matching PO—are flagged for the human AP team to review. This elevates the constraint by using AI to handle the high-volume, repetitive work, freeing up the skilled humans to focus only on complex problems. The department's throughput of processed invoices increases dramatically. ✅

AI/Automation Making a Bottleneck Worse (The Wrong Way)

Imagine a company where the sales development representatives (SDRs) are the bottleneck. There is a limited number of skilled SDRs who can perform high-quality qualification calls and product demos to turn leads into real sales opportunities. Their time and expertise are the constraint.

• The Bottleneck: The limited time and capacity of the SDR team. 👨‍💻
• The Misapplied AI: The marketing team, whose KPI is "number of leads generated," implements a powerful AI tool to massively scale its lead-generation campaigns. The AI scrapes social media and web data to generate 10 times the previous volume of marketing leads.
• The Result: The marketing team celebrates hitting its KPI. However, the SDR team (the bottleneck) is now completely overwhelmed by a flood of mostly low-quality leads. 🌊 Their calendars are filled, they can't respond to everyone, and high-quality prospects get lost in the noise or face long delays. The overall system's throughput—the number of actual sales opportunities created—goes down. Optimizing the upstream, non-bottleneck process made the bottleneck's job harder and the entire system less effective.

AI/Automation for Software Development

In software development, the process of writing code is often the most visible activity, making it the perceived bottleneck. AI coding assistants, which can 10x the speed of raw code production, appear to be the perfect solution.

But is writing code truly your constraint?

Let's examine the entire value stream, from idea to deployed feature:

1. Idea & Requirements Definition: How clearly are problems defined?
2. System Design & Architecture: Are we building a scalable, maintainable solution?
3. Code Generation: The act of writing the code.
4. Code Review & Integration: Does the code meet quality standards? Does it integrate safely?
5. Quality Assurance & Testing: Does the feature work as intended, without regressions?
6. Deployment & Release: How quickly and safely can we get it to customers?

For many mature engineering organizations, the bottleneck is rarely the raw speed of code generation (Step 3). More often, it lies in Code Review (Step 4) or QA (Step 5).

A Non-Trivial Example: The Pull Request Deluge

Imagine a team of 10 engineers. Their bottleneck is the cognitive load on the two senior engineers who perform the majority of critical code reviews. The review process is slow, ensuring quality, security, and architectural coherence. The team's effective throughput is limited by the rate at which these two seniors can approve Pull Requests (PRs).

Now, we give all 10 engineers an advanced AI agent. Suddenly, they are generating code at 5x their previous speed. The number of PRs submitted per day explodes.

What happens to our system?

• The pile of "work-in-progress" (unreviewed PRs) skyrockets.
• The two senior engineers, already the bottleneck, are now completely overwhelmed. Their queue is longer, context-switching is constant, and the quality of their reviews may even decline under pressure.
• Junior and mid-level engineers, having finished their "coding" tasks, are now idle, waiting for reviews. Or worse, they start new tasks based on un-merged code, creating a future integration nightmare.

The result? We have "optimized" a non-bottleneck (code generation), drowned our actual bottleneck (code review), and our overall throughput—the rate of merged, high-quality, deployed code—has gone down. We are producing more lines of code, but delivering less value. This doesn't mean AI tools are useless (far from it!). It means they must be applied strategically, with a focus on the system's actual constraint.

Addressing a Code Review Bottleneck

If the goal isn't to generate more code for review, but to make the review process faster and more effective, consider:

• AI-Powered Review Assistants: Instead of a human spending 30 minutes understanding a complex change, an AI agent can pre-process the Pull Request.
  • Summarization: The AI provides a natural language summary: "This PR refactors the authentication module to use OAuth2, deprecates the legacy token method, and adds three new endpoints. Potential impact on the user profile service is high."
  • Automated Suggestions: The agent can be trained on your organization's specific coding standards and architectural patterns. It can then leave initial comments like: "This function is missing telemetry data" or "This database query doesn't use the established connection pooling pattern." This handles the low-hanging fruit, letting senior reviewers focus on complex logic and architecture.
  • Test Coverage Analysis: The AI can analyze the changes and report: "This change has 95% test coverage, but the new error-handling path is not tested."

Addressing a Quality Assurance (QA) Bottleneck

The constraint is the time and resources required to ensure a feature is production-ready.

• Intelligent Test Generation: The AI doesn't just write code, it writes the tests for it. By analyzing the product requirements and the code changes, an agent can:
  • Generate comprehensive unit and integration test suites.
  • Create end-to-end test scripts for tools like Playwright or Cypress.
  • Design load tests to check for performance regressions under stress.
• Log and Anomaly Detection: In a complex system, "Did we break something?" is a hard question to answer. An AI agent can monitor logs and performance metrics post-deployment, automatically flagging anomalies and correlating them to specific code changes, drastically reducing the mean time to recovery (MTTR).

Addressing Requirements & Design Bottlenecks:

This is often the most impactful bottleneck because errors here have a massive downstream cost.

• Specification Analysis: Before development begins, an AI agent can analyze a Product Requirements Document (PRD). 🤖
  • It can flag ambiguities: "The requirement 'the page should load quickly' is not specific. What is the target P95 latency?"
  • It can identify contradictions or missing edge cases: "The spec defines a user role of 'guest', but does not specify what should happen if a 'guest' attempts to access the settings page."
• Dependency Mapping: An AI can parse the request and cross-reference it with the existing codebase and documentation to warn of potential cross-team impacts: "This change to the User API will require updates to the Analytics and Marketing Automation services. Have those teams been looped in?"

"Vibe coding"—using AI to rapidly prototype—can be immensely valuable, but only if the bottleneck is discovery and exploration. If it's used to feed an already-strained delivery pipeline, it's an expensive way to create chaos.

Closing

Ultimately, the Theory of Constraints provides more than just a process; it offers a new lens for leadership. It forces a move away from the tempting but flawed goal of keeping everyone busy, towards the far more potent objective of increasing the throughput of the entire system. This is less a technical challenge and more a test of executive focus—the discipline to identify the one thing that matters most and the courage to subordinate everything else to it. Applying this thinking is the most direct path to unlocking the latent performance within your organization. It is the core of my work, and the critical question every leader should be asking: where is the single link that truly dictates the strength of your entire chain?

The effectiveness of any tool is determined by where it is applied. Introducing AI agents to accelerate code generation without first identifying and understanding your system's primary constraint is a path to reduced efficiency, frustrated teams, and a lower return on your technology investment.

The critical task for any technology leader today is not simply to adopt AI, but to map their value stream, identify the true bottleneck, and focus AI's power where it will have a systemic impact.

If you are navigating the complexities of integrating new technologies while ensuring your engineering organization is delivering measurable business value, I'm always open to a discussion.

For Further Reading

For those interested in exploring these concepts further, I recommend the following resources:

• The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
  • Why: This is the foundational text on the Theory of Constraints. Written as a fast-paced business novel, it's the most accessible and engaging way to understand the core philosophy in a practical, relatable context. This is the best place to start.
• The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford
  • Why: This book is the spiritual successor to "The Goal" but set in a modern IT and software development organization. It brilliantly applies TOC principles to DevOps, demonstrating how to identify and resolve bottlenecks in technical value streams. Essential reading for any technology leader.
• The Goldratt Institute
  • Why: The official website for the organization founded by Dr. Goldratt. It contains articles, case studies, and more in-depth materials on the application of TOC across various industries, including the "Five Focusing Steps."
• Wikipedia: Theory of Constraints
  • Why: For a concise, well-structured summary of the key concepts, including the Five Focusing Steps and the different types of constraints. It serves as an excellent quick reference guide to the core terminology and ideas.