In his essay "What I've Learned from Users", Paul Graham reflects on the patterns he's observed after advising hundreds of startups through Y Combinator[cite: 1]. The essay covers a wide range of lessons — from how founders misjudge the relative importance of their problems, to why startup advice is so often ignored precisely because it's counterintuitive[cite: 1]. But one line in particular stopped me: "Speed defines startups. Focus enables speed. YC improves focus."[cite: 1] That compression — the idea that focus is not a personality trait or a productivity hack but a structural precondition for speed — struck me as something that translates well beyond the startup world[cite: 1]. Specifically, it reframed a tension I've been thinking about for a long time within a corporate Instructional Design setting: why a team can genuinely value efficiency, talk about it constantly, and still feel like it's not getting anywhere[cite: 1].
What follows are two arguments for why an explicit operational strategy — with clearly defined priorities and success criteria — is the missing piece when a team calls for efficiency but hasn't defined what that word actually means[cite: 1].
FOCUS RESOLVES THE EFFICIENCY PARADOX
Our team has consistently identified efficiency as an imperative, but we have never concretely defined what efficiency means in our context — what it measures, what it serves, or what it looks like when achieved[cite: 1]. This is not a minor semantic gap[cite: 1]. When a team treats efficiency as an end in itself rather than as a means to a specified outcome, the concept defaults to its most intuitive interpretation: spending less time to get more done[cite: 1]. And "more done" inevitably gets measured by whatever is most visible — volume of output, speed of delivery, number of requests completed[cite: 1].
The paradox is that this version of efficiency can actively work against the team[cite: 1]. When there is no shared framework for distinguishing high-impact work from low-impact work, everything receives comparable urgency[cite: 1]. The result is a team that appears productive — and may genuinely be working hard — while dispersing its finite energy across tasks of wildly unequal value[cite: 1]. Context-switching is the most visible symptom, but it points to a deeper structural issue: without explicit priorities, the team has no principled basis for deciding where to allocate its effort, and no shared language for explaining those decisions to one another or to leadership[cite: 1].
Graham's observation that "focus enables speed" is instructive here as a principle, not a direct analogy[cite: 1]. A corporate team operates under structural constraints that a startup does not — it works within a broader organization, responds to directives, and serves internal stakeholders[cite: 1]. But most teams do have meaningful authority over how they operate, even when what they're asked to deliver is determined externally[cite: 1]. Defining operational priorities and success criteria is within that scope[cite: 1]. The goal isn't to unilaterally decline work; it's to build a transparent framework — endorsed by leadership — that makes prioritization decisions legible, so the team can direct its energy where it compounds rather than where it merely accumulates[cite: 1].
A reasonable objection is that prioritization is itself contentious[cite: 1]. But the current alternative — leaving "efficiency" undefined and hoping effort self-organizes around the right problems — has already produced the friction teams experience when they call for efficiency without a strategy to anchor it[cite: 1]. The risk of defining priorities imperfectly is lower than the cost of not defining them at all[cite: 1].
CLEAR SUCCESS CRITERIA GUARD AGAINST PROXY OPTIMIZATION
Without structured success criteria, any team risks optimizing for proxies of impact rather than impact itself[cite: 1]. Graham describes this as "hacking the test" — a pattern where people rationally optimize for whatever metric is most legible, regardless of whether it reflects actual value[cite: 1]. In a team context, this doesn't look like deliberate gaming[cite: 1]. It looks like a reasonable response to ambiguous incentives: when success is undefined, the most efficient behavior is to satisfy the most immediate, visible demand — completing a deliverable on time, fulfilling a request as specified, or meeting a compliance threshold[cite: 1].
The problem isn't that these activities lack value[cite: 1]. It's that when they become the sole evidence of performance, the team loses the ability to distinguish between "we delivered" and "our delivery produced the intended result."[cite: 1] These are correlated but not identical, and in the absence of explicit criteria linking effort to outcomes, the team gravitates toward the former because it's measurable and within direct control[cite: 1].
Establishing clear, outcome-oriented KPIs shifts this dynamic[cite: 1]. The specific metrics will vary by team and domain, but the structural effect is the same: when a team is evaluated against results rather than throughput, it creates an incentive to interrogate the quality and targeting of its work, not just the pace[cite: 1]. This doesn't override the legitimate input of stakeholders or leadership — in fact, it strengthens those relationships by grounding conversations about priorities in shared data rather than competing preferences[cite: 1]. When a disagreement arises about what to prioritize, the team can point to measurable outcomes rather than relying on assertion[cite: 1].
The strongest objection to this approach is that outcome metrics are rarely attributable to a single team's efforts[cite: 1]. Results are shaped by organizational context, tooling, leadership decisions, and factors outside anyone's direct control[cite: 1]. This is a valid concern, and it means KPIs should function as directional indicators — signals that inform iteration — rather than as scorecards for isolated accountability[cite: 1]. The goal is not to prove that the team alone caused a given outcome, but to shift the team's orientation from "did we complete the work?" to "is there evidence that the work produced the effect we intended?"[cite: 1] That distinction, even when the evidence is imperfect, is the difference between a team that executes tasks and a team that solves problems[cite: 1].