Operations and ProcessesGrowth Transformation
What makes your company work today may be what keeps it from scaling tomorrow
The processes that sustain one stage of growth don’t always sustain the next. What to review before they become a limit.
The company is selling more than ever. It has hired people, added a CRM, brought in a project management tool and started using artificial intelligence. Yet delivery times are getting longer, approvals pile up in the inboxes of two or three executives, and teams seem busier and busier without work moving any faster. Nobody is working less. The problem isn’t effort.
It’s design. The practices that made growth possible (deciding quickly from the top, coordinating through a conversation, solving things with a spreadsheet, keeping everyone at full capacity) worked under certain conditions of size, volume and variety. When those conditions change, some of those practices stop being an advantage and become the limit. Not because they were wrong, but because their cost grows faster than the operation.
A company can become less efficient precisely when it starts to grow, without anyone having done anything wrong.
Key takeaways
- Growing means increasing volume; scaling means increasing it without cost, lead time and quality deteriorating in the same proportion or more.
- Some costs grow faster than volume: coordination channels, waiting times near full capacity and the decision load on a few people.
- An operation’s performance is limited by its constraint. Improving a stage that isn’t the constraint doesn’t improve the system’s result.
- The goal isn’t more or fewer processes, but structure that enables work instead of merely controlling it.
- Automating a stage upstream of the constraint can increase accumulated work instead of increasing capacity.
- Available evidence suggests AI amplifies the system it is installed in: it delivers more when work is redesigned and less when it is layered onto unreviewed processes.
Growing isn’t scaling
It helps to separate concepts often used as synonyms. Efficiency is the relationship between resources used and results obtained. Productivity, the relationship between what is produced and what is consumed to produce it. Capacity, the volume an operation can process or deliver under given conditions. Resilience, its ability to absorb disruptions and recover. And scalability, a system’s ability to respond to more demand or broader reach while maintaining acceptable levels of performance, quality and economics.
A process can be efficient and not scalable. It happens when its efficiency depends on conditions that growth changes: a few people who know each other, little variety of cases, a volume that leaves spare capacity, someone who holds the knowledge and decides on the spot. Under those conditions, informality is cheap and fast. When conditions change, the same process can become slow and costly without anyone having modified it.
The underlying reason is that some costs don’t grow in proportion to volume. Frederick Brooks observed it in software projects: if every person has to coordinate with everyone else, communication channels grow according to the formula n(n−1)/2.4 Five people have 10 possible channels; fifteen, 105; fifty, 1,225. Not every organization needs everyone to coordinate with everyone, which is why structures and processes exist. But the figure shows why the informal coordination that worked in a small team doesn’t scale on its own. Something similar happens with waiting times when a resource approaches the limit of its capacity, as we’ll see later.
Panel 1: Brooks (1975). Panel 2: classic queueing theory result for a simple queue with random arrivals and service times (M/M/1), where mean waiting time is ρ/(1−ρ) times the service time. Real operations have other assumptions; the shape of the curve is what matters. Analysis: Advisent®.
The problem of multiplying what works
Robert Sutton and Hayagreeva Rao, of Stanford University, spent years studying how different organizations tried to spread excellent practices from a small group to many more. They called that challenge the problem of more: taking what works to more people and places without degrading it along the way.1 Their central conclusion is that multiplying a practice doesn’t guarantee multiplying its results. A methodology that works with five people may need changes to work with fifty; a delivery process designed for ten clients may stop being viable with a hundred.
The authors pose a tension every growing company faces. On one side, precisely replicating what works, a logic they call Catholicism. On the other, passing on a mindset and letting each team adapt it to its context, which they call Buddhism. Neither option is superior in the abstract. A regulated financial operation may need identical controls everywhere; a creative or solution-design process may need room to adapt. The mistake is applying the same degree of standardization to everything.
Sutton and Rao add two useful warnings. The first is that growth adds people, rules, tools and interactions, and with them cognitive load: at some point people lose the ability to focus and decide well. The second is that improving doesn’t always mean adding. Sometimes it requires removing rules, meetings, steps or tools that no longer contribute. Rao summed it up with practical advice: before adding a new meeting, kill an existing one.24
But there is a limit their work doesn’t resolve on its own: a company can successfully replicate a process that is no longer suited to its new scale. Replicating what worked doesn’t guarantee it will keep working when conditions change. That requires another question.
When improving a part doesn’t improve the system
Eliyahu Goldratt asked that question in The Goal, the management novel he wrote with Jeff Cox that gave rise to the theory of constraints.2 Its central idea is simple and demanding at once: a system’s performance is limited by one or a few constraints. An hour gained at the constraint is an hour gained for the whole system; an hour gained anywhere else doesn’t change the overall result. Improving every area equally doesn’t improve the company equally.
Goldratt formulated five steps for managing that limit: identify the system’s constraint, decide how to exploit it, subordinate everything else to that decision, elevate its capacity and, when the constraint is broken, start again without letting inertia become the new constraint.3 The last step is the most overlooked: when a bottleneck is resolved, the limit moves elsewhere. A company that expands its sales capacity may discover the limit has moved to delivery; when it resolves delivery, it may appear in billing or in supervisory capacity.
The theory uses its own terms, which are worth not confusing. Throughput is the rate at which the system generates money through sales, not the number of units processed or resource utilization. Inventory is the money invested in things the system intends to sell, an economic definition different from the work in progress used in Lean or Kanban. And operating expense is the money spent turning inventory into throughput. The practical consequence is that a local indicator (an area’s productivity, billed hours, proposals sent) can improve while the system’s result worsens.
Combined, the two perspectives produce this article’s central tension, which is Advisent®’s interpretation and not their authors’: replicating isn’t always scaling, optimizing isn’t always improving, and increasing the capacity of one part doesn’t always increase the capacity of the whole.
The hidden cost of coordinating a larger organization
A growing share of the work in a growing company produces nothing for the customer: it exists to coordinate other work. Follow-up meetings, status updates, approvals, handoffs between areas, reconciling information across systems. None of it is useless in itself, but its volume grows with interdependencies, not with sales.
Organization theory explains why. James Thompson distinguished three types of interdependence: pooled, when units share common resources; sequential, when one unit’s work feeds the next; and reciprocal, when they feed each other. Each is coordinated differently (with rules and standards, with planning or with mutual adjustment), and each is more costly than the previous one.9 Jay Galbraith added that the greater a task’s uncertainty, the more information must be processed to coordinate it, and that organizations have two paths: reduce that need (with more autonomous units or slack resources) or increase their capacity to process it (with information systems or lateral relations between areas).8 Behind both is Herbert Simon: people have a limited capacity to process information and make decisions.7
The problem worsens because we tend to underestimate it. Chip Heath and Nancy Staudenmayer called it coordination neglect: the tendency to divide work carefully and think far less about how to put it back together, underestimating interdependencies and communicating too little between the parts.10 A company that grows by splitting teams and specializing functions, without redesigning how they integrate, accumulates friction without knowing it.
What share of our teams’ work creates value for customers, and what share exists only to coordinate other work?
Neither more nor fewer processes: structure that enables
An organization with too little process depends on improvisation, tacit knowledge and a few people: mistakes repeat, rework is routine and nobody knows exactly how something was done last time. An organization with too much process suffers the opposite: redundant approvals, documentation nobody uses, overlapping controls and decisions that take weeks. Both extremes reduce capacity. The question isn’t how many processes to have, but what kind of structure.
Paul Adler and Bryan Borys proposed a distinction that remains useful: bureaucracy can be enabling, when procedures help people do their work well and solve problems, or coercive, when they exist mainly to control them.11 The same procedures manual can be one or the other depending on how it is designed and used. And evidence shows that standardization isn’t necessarily the enemy of flexibility: Adler, Barbara Goldoftas and David Levine studied how a Toyota plant managed to be efficient and, at the same time, flexible during model changeovers, thanks to routines designed precisely to manage the non-routine.12
From this follow criteria for deciding what to standardize. It makes sense when the activity is repeatable, when variability causes costly errors, when there are regulatory requirements, when customer impact is high or when many people need to be trained. It makes less sense when the task requires judgment, when every case is different or when adaptation is part of the value delivered. Standardizing what requires judgment produces rigidity; leaving to judgment what should be standard produces errors.
Processes also accumulate debt
Much of a company’s complexity wasn’t designed: it accumulated. A parallel spreadsheet someone created to solve a specific problem and that was never replaced. An extra approval added after a mistake and never reviewed. Two systems that don’t talk to each other and a person copying data from one to the other. An exception that became the usual way of working. A weekly meeting that exists because the process doesn’t work. Each solution made sense at the time; the whole doesn’t necessarily.
In software engineering, Antonio Martini and colleagues proposed the concept of process debt, by analogy with technical debt: shortcuts that bring an immediate benefit and a cost paid later, with interest.14 The term has no established academic definition outside that field, but the analogy describes well what happens in many operations: shortcuts accumulate, interact with each other and end up costing more than the problem they solved.
Process mining offers a way to see it with data. From the event logs that systems leave behind, it reconstructs how work actually flows, not how the manual says it flows: how many variants a process has, where steps repeat, where cases wait.15 It doesn’t replace the judgment of those who know the operation, and it requires systems that log events, but it usually reveals the gap between the designed process and the real one.
What part of our operational complexity was designed, and what part simply accumulated?
The bottleneck often has a name
A hypothetical example, common in service companies, shows how the constraint moves. With ten clients, the founder approves quotes, assigns tasks and reviews every deliverable. It works well: they decide quickly, know every client and guarantee quality. With forty clients, the first delays appear; there are more projects, more reviews and more meetings, and decisions start to wait. With a hundred clients, the number of decisions exceeds what one person can process. Teams wait for approvals, work in progress piles up, lead times stretch. The company hires more people, but the bottleneck stays in the same place.
The question stops being how many more people are needed and becomes which part of the system limits capacity. In this case, the constraint isn’t headcount, but the decision architecture. Nor is the answer to delegate everything. Some decisions should remain centralized, because their risk or impact justifies it. What changes is the design: which decisions are made at each level, with what criteria, which cases are resolved through a standard procedure, which exceptions are escalated and when, and who is accountable for the result. Distributing decisions without explicit criteria produces inconsistency; centralizing them all produces queues.
It is also a matter of the model’s survival. In Latin America, where according to ECLAC large companies can be up to 33 times more productive than micro-enterprises (compared with a gap of 1.3 to 2.4 times in OECD countries), much of that distance comes down to the ability to move from an operation that depends on people to one that depends on systems.25 This is Advisent®’s interpretation: the gap has many causes, but founder dependence is one of the most common in companies trying to grow.
The 100% utilization trap
In many service companies, keeping everyone busy at full capacity looks like the definition of efficiency: every unbilled hour is a loss. Queueing theory suggests that operating too close to the capacity limit has a cost that doesn’t show up in the utilization report. Little’s Law states that, in a stable system, accumulated work equals the arrival rate multiplied by the average time each unit spends in the system.5 If more work comes in than gets finished, or if projects in progress pile up with the same capacity, lead times stretch.
John Kingman also showed that, as a resource’s utilization approaches 100%, waiting times grow non-linearly.6 In the simplest case, with random arrivals and service times, going from 70% to 95% utilization multiplies average waiting time by more than eight. Real operations don’t follow those assumptions exactly, but the shape of the curve holds: with variability, near the maximum, any urgency, error or unexpected request creates a queue. Donald Reinertsen applied this to product development: queues are one of the largest hidden costs, because they don’t show up on the balance sheet but delay everything else.16
This doesn’t mean utilization should be low. It means slack has economic value, especially at the constraint and in variable environments. A delivery team at 100% bills all its hours and, at the same time, delivers later, absorbs urgencies poorly and has less room to correct mistakes. The question isn’t the maximum possible utilization, but the utilization that allows meeting deadlines and quality given the operation’s real variability.
A team at 100% capacity can bill all its hours and, at the same time, deliver later and later.
Automating one stage can move the problem
Michael Hammer put it in 1990 with a slogan that still holds: don’t automate, obliterate.13 Automating a poorly designed process produces the same process, faster. The theory of constraints adds a less obvious consequence: automating a stage that isn’t the constraint can make the system worse.
A hypothetical example shows it. A company automates the generation of sales proposals and goes from preparing twelve a week to thirty. But legal still reviews eight, operations takes just as long to allocate resources and the founder still approves every contract. The company doesn’t close more contracts: it accumulates more proposals waiting, more follow-ups, more pressure on legal and more clients waiting for an answer. Automation increased the flow toward the constraint, not the system’s capacity.
Hypothetical example; weekly capacities. The constraint (legal review) determines the system’s result. In a product company, the same logic appears when order intake is accelerated without expanding production, shipping or after-sales service. Source: Advisent®.
Evidence on artificial intelligence points in a similar direction. In McKinsey’s survey of 1,000 executives at companies with revenue of at least USD 500 million, almost 90% said they were at least experimenting with AI, but only 7% reported having scaled it across the organization. Companies with greater operational excellence maturity showed more than three times the three-year return on invested capital of less mature ones, a correlation the firm itself notes doesn’t prove causality.17 In its 2026 state of AI survey, 80% of participants reported individual productivity improvements, but only 37% attributed some EBIT impact to AI; nearly three quarters of the top-performing companies had substantially redesigned their workflows, compared with a quarter of the rest.18 One person’s productivity doesn’t automatically turn into system capacity.
Results are also heterogeneous. In a McKinsey survey of 334 product development and engineering leaders, only 25% of executives reported meaningful acceleration and 30% said their team’s productivity had fallen; teams that redesigned their processes before adopting AI were more than twice as likely to report gains above 20%.19 The DORA report on software teams described AI as an amplifier of the strengths and dysfunctions an organization already has.20 These are software development figures, which don’t translate directly to the whole operation, but they illustrate the point: technology performs according to the system it is installed in.
The distinction between technologies also matters. Digitizing means representing information in digital form. Automating means executing tasks through rules. Robotic process automation (RPA) executes repetitive tasks with structured data, often on top of existing interfaces. AI that assists people improves their work without replacing their judgment. And AI agents can plan and execute actions within defined limits, with human oversight.22 The more agents are added, the more orchestration and governance matter: who coordinates them, with what permissions and who is accountable for their decisions.23 Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear value or inadequate risk controls.21 AI can remove constraints; it can also create new ones, such as reviewing its output or integrating systems.
In the region, adoption is still mostly superficial. In Spain, 21.1% of companies with ten or more employees used AI in 2025, according to the national statistics institute (INE).26 In Chile, a study commissioned by AWS found that 45% of companies use it, but that 58% of them do so only with basic tools and just 14% are confident they can measure its return.27 Using AI and redesigning the operation with AI aren’t the same thing.
Product and service companies: different constraints
Operations aren’t just factories. Service companies also have operations, although their constraints tend to sit in less visible places: in the people who hold knowledge, in review capacity, in team allocation or in decisions waiting for approval. The table summarizes common differences, which aren’t universal rules.
| Dimension | Product companies | Service companies | Scaling question |
|---|---|---|---|
| Capacity | Production, procurement and logistics | Hours of people with specific knowledge | Which resource limits what we can deliver? |
| Inventory and work in progress | Stock, materials and pending orders | Open projects, proposals and pending reviews | How much started work is waiting? |
| Variability | Demand, suppliers and quality | Scope, change requests and every client being different | How many exceptions can the process absorb? |
| Knowledge | Embedded in the product and the plant | Concentrated in key people | What happens if one person is missing? |
| Marginal cost | Tends to fall with volume | Can grow almost in proportion to each client | Does each new client require proportionally more hours? |
| Quality | Statistical control and specifications | Deliverable review and professional judgment | Does review depend on a few people? |
| Automation | Planning, inventory, shipping | Proposals, reports, allocation, billing | Are we automating the constraint or what comes before it? |
In professional services, the underlying question is what happens when each new client requires proportionally more hours of work. The usual answers (standardizing parts of delivery, turning services into defined offerings, creating shared services, using AI to prepare and review) can reduce that dependence, but not all apply to every service. Productizing what actually requires judgment can destroy the value the client was buying. The goal isn’t to eliminate personalization, but to separate what must be personalized from what simply repeats. How this connects with the commercial system is covered in our article on customer relationship profitability, and its relationship with expansion into new markets in the cost of growing without a strategy.
What to review before the next stage of growth
To structure that diagnosis we propose two Advisent® conceptual tools. They aren’t validated academic models, but structured ways of asking the right questions. The first, The Scalability Stress Test by Advisent®, assesses whether a process can withstand the next stage across six observable dimensions.
Advisent® conceptual framework, not a validated model. Any scoring (for example, a traffic light per dimension) is illustrative and must be built with the operation’s own data. Source: Advisent®.
The second, The Process Redesign Decision by Advisent®, sets out what to do with a process. It isn’t a linear sequence. It always starts by identifying the constraint, continues by asking whether the process should exist and, only then, chooses a path according to the type of problem.
Advisent® conceptual framework, not a validated model. Central rule: don’t automate upstream of the constraint, because it only increases the work waiting in front of it. Source: Advisent®.
Neither tool resolves on its own the counterarguments worth keeping in mind. Some organizations scale successfully by precisely replicating a proven model. Standardization can be a competitive advantage. Some bureaucracy reduces risk, and some critical decisions should remain centralized. Sometimes the constraint is resolved simply by adding capacity, and not everything requires deep redesign. And in highly uncertain operations, resilience can be worth more than efficiency. The criterion isn’t to redesign everything, but to know what to keep, what to change and what not to touch.
What got us here
Organizations are systems. When they grow, their constraints change: what limited a ten-person company isn’t what limits a hundred-person one. Practices that were efficient at one stage (centralized decisions, informal coordination, maximum utilization, the spreadsheet that solved everything) don’t fail because they were bad, but because their cost grows faster than the operation. Adding people, tools or automation without identifying where the limit is tends to produce more activity, not more capacity.
Scaling requires deciding how processes, capacity, decisions, coordination, structure, people, technology and the economics of the operation should evolve. And above all it requires an uncomfortable question for any team that has succeeded: which of the things that got us here no longer serve us for what comes next.
Is our company designed for the scale we want to reach, or does it still run on the mechanisms that got us here?
The next stage of growth doesn’t always require doing more of the same. Sometimes it requires stopping what worked.
Frequently asked questions about how to scale a company
What is the difference between growing and scaling?
Growing means increasing sales, customers or operational volume. Scaling means increasing it without cost, lead times and quality deteriorating in the same proportion or more. A company can grow and become less efficient at the same time, when some costs (coordination, waiting, concentrated decisions) grow faster than volume.
What is a bottleneck in a company?
A bottleneck is the stage, resource or person that limits the flow of the whole system. It can be an operating area, a review step, a system or an executive who concentrates approvals. Improving any other stage doesn’t increase the overall result while the constraint stays in the same place; once it is resolved, the limit usually moves elsewhere.
What is the theory of constraints?
It is a management approach developed by Eliyahu Goldratt, popularized in the novel The Goal (1984), which holds that a system’s performance is limited by one or a few constraints. It proposes five steps: identify the constraint, decide how to exploit it, subordinate everything else to that decision, elevate its capacity and, when it breaks, start again without letting inertia become the new constraint.
When should a process be standardized?
Standardization makes sense when the activity is repeatable, when variability causes costly errors, when there are regulatory requirements, when customer impact is high or when many people need to be trained. It makes less sense when the task requires judgment, when every case is different or when adaptation is part of the value delivered.
How can you tell if a company has too much bureaucracy?
Some signs are approvals that don’t change decisions, overlapping controls, documentation nobody uses, meetings that replace processes and simple decisions that take weeks. The useful distinction, proposed by Adler and Borys, is between enabling bureaucracy, which helps people do their work well, and coercive bureaucracy, which exists mainly to control them.
Which processes should be automated?
It makes sense to automate repeatable, rule-based tasks with structured data, preferably at the system’s constraint or after it. Automating a stage upstream of the constraint can increase accumulated work without increasing capacity. Before automating, it is worth asking whether the activity should exist and whether it can be simplified.
What is process mining?
Process mining is a set of techniques that analyze the event logs of a company’s systems to reconstruct how work actually flows. It shows process variants, repeated steps and waiting times, and compares the real process with the designed one. It requires systems that log events and doesn’t replace the knowledge of the people who run the process.
How do you scale a service company?
Scaling a service company usually requires reducing the dependence on each new client needing proportionally more hours from key people. Common levers are distributing decisions with clear criteria, standardizing what repeats, separating it from what requires judgment, avoiding 100% utilization, managing work in progress and using AI to prepare and review. Not every service should be productized.
Sources and further reading
Academic foundations
- Sutton, R. I., & Rao, H. (2014). Scaling up excellence: Getting to more without settling for less. Crown Business.
- Goldratt, E. M., & Cox, J. (2014). The goal: A process of ongoing improvement (30th anniversary ed.). North River Press. (Original work published 1984)
- Goldratt, E. M. (1990). What is this thing called theory of constraints and how should it be implemented? North River Press.
- Brooks, F. P., Jr. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley.
- Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383–387. doi.org/10.1287/opre.9.3.383
- Kingman, J. F. C. (1961). The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, 57(4), 902–904. doi.org/10.1017/S0305004100036094
- Simon, H. A. (1947). Administrative behavior. Macmillan.
- Galbraith, J. R. (1974). Organization design: An information processing view. Interfaces, 4(3), 28–36. doi.org/10.1287/inte.4.3.28
- Thompson, J. D. (1967). Organizations in action: Social science bases of administrative theory. McGraw-Hill.
- Heath, C., & Staudenmayer, N. (2000). Coordination neglect: How lay theories of organizing complicate coordination in organizations. Research in Organizational Behavior, 22, 153–191. doi.org/10.1016/S0191-3085(00)22005-4
- Adler, P. S., & Borys, B. (1996). Two types of bureaucracy: Enabling and coercive. Administrative Science Quarterly, 41(1), 61–89. doi.org/10.2307/2393986
- Adler, P. S., Goldoftas, B., & Levine, D. I. (1999). Flexibility versus efficiency? A case study of model changeovers in the Toyota production system. Organization Science, 10(1), 43–68. doi.org/10.1287/orsc.10.1.43
- Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, 68(4), 104–112.
- Martini, A., Besker, T., & Bosch, J. (2020). Process debt: A first exploration. In 2020 27th Asia-Pacific Software Engineering Conference (APSEC) (pp. 316–325). IEEE. doi.org/10.1109/APSEC51365.2020.00040
- van der Aalst, W. (2016). Process mining: Data science in action (2nd ed.). Springer. doi.org/10.1007/978-3-662-49851-4
- Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas.
Business and institutional research
- de Kroon, D., de Boer, E., Hou, F., Kleine Büning, M., Shahani, R., Heuss, R., Rosendahl, M., & Muthiah, S. (2026, June 19). Putting AI to work: The operational excellence imperative. McKinsey & Company. mckinsey.com
- Krivkovich, A., Weddle, B., Price, H., & Sohoni, V. (2026, October 5). AI is changing work. Now it has to change the organization. McKinsey Quarterly. mckinsey.com
- Relyea, C., Lunawat, G., Palaniappan, J., Harrysson, M., Linderman, M., & Dixit, P. (2026, August 21). Beyond the copilot: Scaling the agentic product development life cycle. McKinsey & Company. mckinsey.com
- Google Cloud DORA. (2025). 2025 state of AI-assisted software development. blog.google
- Gartner. (2025, June 25). Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027. gartner.com
- Deloitte AI Institute. (2025, July 6). The rise of AI agents and collaborative automation. deloitte.com
- Ammanath, B., & Comstock, A. (2025, October 13). The dawn of agentic AI: Orchestration, governance, and best practices. Deloitte. deloitte.com
- Stanford Graduate School of Business. (2014, January 7). Hayagreeva Rao and Robert Sutton: How do you scale excellence? gsb.stanford.edu
Latin America and Spain
- ECLAC. (n.d.). Acerca de las microempresas y pymes. cepal.org
- Instituto Nacional de Estadística. (2025, October 22). Encuesta sobre el uso de TIC y del comercio electrónico en las empresas 2024–2025. ine.es
- Pauta. (2026, September 25). El 45% de las empresas chilenas usa inteligencia artificial, pero la mayoría aún la ocupa para tareas básicas [Strand Partners study for AWS]. pauta.cl
The Scalability Stress Test by Advisent® and The Process Redesign Decision by Advisent® are proprietary conceptual developments. The integration of Sutton and Rao’s work with the theory of constraints is an Advisent® editorial interpretation. The concepts of the problem of more and the Buddhism versus Catholicism tension (Sutton and Rao), the theory of constraints and its five focusing steps (Goldratt), coordination neglect (Heath and Staudenmayer), enabling and coercive bureaucracy (Adler and Borys) and process debt (Martini, Besker and Bosch) belong to their authors. The McKinsey, DORA and AWS surveys reflect stated perceptions and correlations, not causal relationships.
Last updated:
