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].