Focus and Prioritisation
The most common improvement failure is not choosing the wrong solution — it is pursuing too many solutions simultaneously. Effort spread across ten priorities produces slow, shallow progress on all of them. The same effort concentrated on the single binding constraint produces rapid, structural change on the one thing that matters. Focus is not a personality trait. It is a system design decision.
☰ Contents
Why spreading effort fails
Every system has a binding constraint — one factor that limits overall throughput. The Theory of Constraints is precise: improving a non-constraint does not improve system throughput. It may improve local efficiency while leaving overall output unchanged. An organisation with ten active improvement priorities is almost certainly improving nine non-constraints and making slow progress on the one that actually matters.
The mathematics of focus are stark. Assume a team has ten units of attention per week. Spread across ten priorities, each gets one unit. Progress on each is slow, each competes with the others for attention when problems arise, and the probability of completing any one before it is deprioritised by the next crisis approaches zero. Concentrated on one priority, that priority gets ten units. Progress is ten times faster. The constraint is addressed and elevated. A new constraint emerges. The team moves to that. Within the same time period, two or three constraints have been addressed rather than zero.
Switching between tasks does not preserve the efficiency of single-tasking. Cal Newport’s research on deep work documents the cognitive cost: every context switch leaves a residue of the previous task in working memory, degrading performance on the new task. For knowledge work — software development, analysis, writing, design — the cost of an interruption is not just the duration of the interruption but the time required to rebuild the context for the original task. A 10-minute support call can cost 40–90 minutes of recovered deep work time. An organisation whose developers answer support calls is not multitasking efficiently — it is operating at a fraction of its creative capacity.
Deep work and the constraint
Cal Newport, in Deep Work (2016), distinguishes two types of professional activity: deep work (cognitively demanding, high-value, distraction-free) and shallow work (logistically necessary but low cognitive demand, easily replicated). His central argument is that deep work is becoming increasingly rare and increasingly valuable, and that the organisations and individuals who protect it will produce disproportionately better outcomes.
In the context of the Theory of Constraints, deep work time is the constraint in most knowledge work organisations. The developers, analysts, clinicians, and researchers who produce the organisation’s core value require sustained, uninterrupted concentration. Every interruption — a support call, an email, a meeting, a question at the desk — is a constraint-consumption event. It consumes the scarcest resource in the system without producing the output the system exists to create.
Shallow work — handling emails, attending status meetings, answering routine queries — does not require the constraint. It can be handled by others, batched, automated, or delegated. The key insight is that shallow work tends to expand to fill available time unless it is actively constrained. Without a structural mechanism to protect deep work time, shallow work will crowd it out entirely.
Shielding — the structural mechanism for focus
Shielding is the organisational practice of protecting the constraint from everything that does not require it. It is not a personal preference or a management style — it is a system design decision. Someone or something absorbs the inbound shallow work so that the constraint can operate at full depth.
Shielding has three components:
- A first line that absorbs all inbound contact. No inbound support call, email, or query reaches the constraint directly. Everything passes through the first line first. The first line handles everything it can. Only what genuinely requires the constraint reaches the constraint.
- A learning loop that reduces what the first line cannot handle. Every query the first line escalates to the constraint is a signal: this query type is not yet handled by scripts, documentation, or tooling. The learning loop captures those signals, directs the creation of the handling tools, and over time reduces the escalation rate. The constraint is consulted less frequently as the first line becomes more capable.
- Ring-fenced time for deep work. Even with a first line in place, the constraint needs scheduled, protected, uninterrupted time. Meetings, check-ins, and ad-hoc requests are batched to specific times. Deep work time is inviolable during its scheduled periods.
The role design for focus
The shielding structure maps to specific roles in a small knowledge work organisation. The names below are from the worked example — a specialist software company — but the pattern applies to any team where a constrained expert role must be protected from inbound shallow work.
Goalies
Handle all inbound contact — support calls, emails, implementation queries. Their function is to shield the Builders. They resolve everything they can using scripts, documentation, and the help library. They escalate only what they cannot resolve.
Builders
Developers, analysts, clinicians — the people who produce the core value. Never answer inbound contact directly. Work in protected deep-work time. Output is new product, new tools, new capability. Their time is the scarcest resource in the system.
Investigator
Owns the pattern analysis. Identifies which query types are consuming Goalie time, conducts root cause analysis on recurring support patterns, directs the creation of help articles and scripts, and escalates fix specifications to Toolmakers. Reduces what Goalies cannot handle over time.
Toolmakers
Build the tools that make Builders more productive and Goalies more capable. Ring-fenced from operational work. Priority: internal tools first (multiply everyone’s capacity), then new product development, then customer-facing features.
In organisations where no shielding structure exists, the first necessary condition is to name the roles — not hire new people, but assign existing people to these functions explicitly. The Investigator appointment is typically the critical enabling event because it creates the learning loop that continuously improves the system. Without it, the Goalies handle queries reactively and the same query types recur indefinitely. With it, the query volume falls structurally over time as failure demand is identified and eliminated.
The Kill discipline
Focus requires not just choosing what to do, but being explicit about what not to do. The PICK model’s Kill quadrant — low impact, high effort — is where this discipline lives. Kill means stop: stop the project, stop the meeting, stop the initiative, stop the product line, stop accepting the type of work.
Kill is the hardest discipline in practice for three reasons:
Sunk cost pressure. Something in the Kill quadrant has usually already consumed significant effort. Stopping it feels like admitting that effort was wasted. The sunk cost is real. The future cost of continuing — effort that should go to the constraint, going instead to a low-impact activity — is larger.
Relationship pressure. Kill decisions often involve stopping work that someone championed, commissioned, or is attached to. The social cost of Kill is real. The improvement cost of not killing it is also real. The facilitator’s role in a PICK session is to make the logic explicit: what is the impact of this relative to the constraint? What would the team achieve if the effort currently going here went to the constraint instead?
Optimism about future impact. Low-impact activities are often defended with future projections: “if we just finish this, it will become high impact.” Apply the same Bootstrap CUSUM test: pre-specify the expected change point and confidence level. If the activity has been running for two years without a Bootstrap CUSUM change point in the relevant outcome measure, the future projections are optimism, not evidence.
Portfolio policy — the written commitment
A portfolio policy is a written statement of what the organisation will and will not take on. It makes Kill decisions in advance, at the policy level, rather than case-by-case at the moment of request. This is important because case-by-case Kill decisions require willpower and create friction. A policy-level Kill decision removes the option — and removes the friction that comes from deciding each time.
A portfolio policy for a software company might state: We deliver standardised implementations of our configured product within a defined scope. We do not write bespoke code to customer specification, develop one-off integrations, or accept projects requiring more than N days of custom development. Requests outside this scope are declined at the scoping stage.
This is a standardisation decision as much as a focus decision. The customisation trap — accepting any work that generates revenue regardless of the impact on the constraint — is the specific failure mode that portfolio policy prevents. See Standardisation vs Customisation for the full analysis.
Bootstrap CUSUM and focus
📊 How Bootstrap CUSUM measures focus
A flat line on the outcome measure despite active improvement work is the signature of unfocused effort. If new product development velocity has been flat despite investment, either the constraint has not been identified correctly, or improvement effort is not concentrated on it. Bootstrap CUSUM confirms the diagnosis: no change point means no structural improvement.
A change point coinciding with the shielding structure implementation confirms focus worked. When the Goalie/Builder separation is established and the Investigator is appointed, developer time available for deep work increases. If the pre-specified Bootstrap CUSUM prediction — an upward change point in new product output within Z periods — appears, the focus mechanism is confirmed.
Compare before and after via Bootstrap CUSUM on multiple measures simultaneously. Support contact volume should show a downward change point (failure demand falling). New product output should show an upward change point. The two change points together, coinciding with the structural change, are the evidence that focus produced the result.
Focus and prioritisation sits at Step 6 of the 7-step improvement method and connects directly to the Theory of Constraints Step 3 (Subordinate). See Why Nothing Changes for the diagnostic framework.