Scaling an operating organization is not simply a matter of adding process. It requires leaders to decide where the company needs control, where teams need discretion, and how much capacity must remain available for opportunities that cannot be predicted.
First Round’s conversation with Plaid COO Eric Sager offers a useful operating model for making those choices. His experience at Plaid, following leadership roles at Bluevine and Square, connects organizational resilience, customer ownership, executive leverage, and employee onboarding into one coherent discipline.
Key takeaways for operating leaders
Preserve capacity for unexpected, strategically important work instead of scheduling every team to its theoretical limit.
Give each customer relationship one accountable owner, supported by specialists who can enter when their expertise is needed.
Evaluate speed alongside risk and cost; faster execution is not automatically the better business decision.
Measure an executive’s impact partly by whether the organization can function without constant executive intervention.
Use direct contact with new employees to test how onboarding and culture are experienced, not merely how they were designed.
Operating slack is a strategic resource
Sager argues against running an organization at 100% capacity. First Round reports that retaining flexibility helped Plaid respond to opportunities involving OpenAI, Perplexity, and Replit. The broader lesson is not that teams should operate without discipline. It is that a plan consuming every available hour leaves no room for high-value work that appears after planning is complete.
This is especially relevant to product and go-to-market leaders. A team optimized entirely for utilization can look efficient while becoming slow to respond. Spare capacity acts like an option: the company incurs a visible short-term cost in exchange for the ability to pursue an important customer, solve an urgent problem, or adapt to a market shift.
The practical challenge is protecting that slack from becoming unowned time. Leaders still need clear priorities and decision rights. Capacity should be available for defined classes of work, such as strategic deals, urgent customer risks, or emerging product opportunities, with explicit authority over who can redirect it.
Customer ownership should remain simple as expertise grows
As a company scales, generalist roles often give way to specialized customer segments and expert functions. That specialization can improve the quality of advice while making the customer’s experience fragmented. Plaid’s reported answer is a quarterback model: one person owns the full relationship while specialists remain available to contribute.
The distinction between accountability and expertise matters. Specialists may understand a product, industry, or technical issue more deeply, but the customer should not have to coordinate the internal organization. A single owner maintains context, aligns the contributors, and remains responsible for the overall outcome.
This model also exposes weak handoffs. When ownership is shared ambiguously, teams can complete their individual tasks while the customer’s larger problem remains unresolved. A named quarterback makes escalation clearer without requiring that person to solve every issue personally.
Speed, risk, and cost belong in the same decision
The source describes Sager treating speed, risk, and cost as a three-way trade-off. This is a more useful framing than a blanket instruction to move faster. Accelerating work may require more people, introduce operational exposure, or reduce the time available to validate a consequential choice.
A sound operating review therefore asks what the company gains by acting sooner, what can go wrong, and what additional resources acceleration requires. Reversible decisions can often move quickly because errors are easier to correct. Decisions with material customer, regulatory, or organizational consequences may justify a slower path. The objective is not maximum speed; it is an appropriate speed for the consequences involved.
That discipline becomes more important during turbulence. According to First Round, Sager helped lead Plaid through the pandemic, the collapse of its planned Visa acquisition, a fintech downturn, and the AI boom. The source also says Plaid remained focused after the Visa transaction fell through and later raised at nearly three times the price. These are reported outcomes, but the transferable insight is the importance of separating a changed circumstance from a changed mission.
An effective COO reduces organizational dependency
Sager’s view that strong COOs deliberately make themselves obsolete challenges the image of the executive as permanent chief problem-solver. If routine decisions repeatedly rise to the same leader, the organization may be borrowing that person’s judgment without developing its own.
Reducing dependency does not make the role irrelevant. It shifts executive attention toward the ecosystem, the business, and the team – the three areas First Round says shape Sager’s working week. The COO can then concentrate on cross-functional constraints, leadership quality, and new operating problems instead of repeatedly compensating for missing ownership.
A useful test is whether teams have the context, authority, and mechanisms to proceed when the executive is unavailable. Delegation without context produces guesswork; context without authority produces escalation. Both must travel together.
Cold-calling new hires turns onboarding into evidence
One of Sager’s more unusual practices is personally cold-calling brand-new employees. The source does not provide enough detail to judge the full method or its results, but the practice points to a valuable principle: senior leaders need unfiltered signals from people experiencing the organization for the first time.
New hires notice unclear language, missing context, and mismatches between stated culture and everyday behavior. Direct outreach can reveal whether onboarding is creating confidence or merely completing administrative steps. It can also make leadership more tangible, although leaders should avoid turning the conversation into a test in which employees feel pressured to give reassuring answers.
The forward-looking opportunity is to connect those conversations to operating improvement. When recurring confusion becomes visible, leadership can clarify ownership, revise onboarding, or remove unnecessary process. That is how a personal executive habit becomes a scalable management system.
You open a portfolio review and find an AI request from nearly every direction. One team wants an assistant. Another wants an agent. A third has a promising prototype that now needs production funding. Every request sounds plausible, yet approving all of them would spread the company across disconnected experiments.
This isn’t primarily a prioritization problem. It is a leadership-system problem. Your job as CPO is to define the customer advantage worth pursuing, concentrate attention on a few coherent bets, specify the evidence that earns more investment, and make it clear what the company will stop doing. The roadmap should record those choices. It should not make them for you.
Allocate attention before you allocate roadmap space
AI expands the number of things a product team can plausibly build. It does not expand engineering capacity, customer attention, management bandwidth, or the company’s tolerance for operational risk at the same rate. That mismatch is why an orderly backlog can still represent a deeply unfocused strategy.
A prototype adds to the confusion because it compresses the distance between an idea and a convincing demonstration. A good demo shows that a capability may be technically possible under selected conditions. It does not establish that customers will adopt it, that it will perform reliably across real workflows, that its economics will work, or that competitors cannot reproduce it.
Before discussing priority, force each proposed investment through four decisions:
Customer advantage: What will a specific customer be able to do materially better, faster, or more safely?
Behavioral outcome: What observable change would show that the advantage matters, such as stronger activation, repeated use, retention, or expansion?
Business consequence: Which company outcome should move if the customer behavior changes, such as NRR, gross margin, payback, or cost-to-serve?
Opportunity cost: Which existing initiative, workflow, or commitment will receive less attention if this bet is funded?
The fourth decision is where focus becomes real. If a proposal enters the portfolio without displacing time, money, or executive attention somewhere else, the company has not prioritized it. It has merely added it.
A shared driver tree makes these trade-offs visible. Start with the company outcome. Connect it to the customer behavior that must change, the product lever expected to change that behavior, and the evidence required from the current initiative. If a team cannot draw a credible path through those layers, pause the funding discussion until it can. That is more useful than arguing about whether the item belongs near the top or middle of a feature list.
Your leadership context changes how you create this clarity. In a founder-led company, you often need to influence without becoming deferential: preserve the ambition in the founder’s vision while pressure-testing assumptions with customer evidence, data, and portfolio consequences. Under a hired CEO, the emphasis shifts toward explicit investment theses, capital allocation, and a tighter connection among product, financial, and go-to-market plans.
In either setting, ambition must be more precise than a mandate to become an AI company. Name the customer capability you want to own, the workflow in which it matters, and the durable advantage the company can build around it. Technology is an ingredient. Customer advantage is the strategic claim.
Turn AI feature requests into testable investment theses
A feature request arrives with a solution already embedded in it. An investment thesis keeps the solution open long enough to test whether the opportunity deserves capital. That distinction matters when models, interfaces, and implementation patterns are changing faster than an annual plan can absorb.
Rewrite each material AI proposal using this structure:
I hear the same refrain from product leadership peers everywhere: we’re overwhelmed. Shrinking headcount, constant AI disruption, economic uncertainty, and relentless context switching make it feel like we’re carrying two jobs—setting strategy while shielding our teams. I recently listened to an episode of All Things Product that zeroes in on what a real support system for product leaders looks like, and it resonated deeply with my day-to-day.
Want to listen to the conversation yourself? Find it on Spotify or Apple Podcasts.
Here’s the core tension I see (and felt early in my own leadership journey): product leaders tend to underinvest in themselves. We hold onto work because it feels faster, safer, or “just easier if I do it.” But that pattern quietly taxes strategy, slows learning, and caps team throughput. The hidden cost of “doing it all yourself” is real.
Early in my tenure leading product, I tried to keep every plate spinning—roadmap reviews, stakeholder prep, user research, executive updates—while protecting my team’s focus. I was busy and useful, but not maximally valuable. The turning point came when I started building a lightweight support stack: a few hours of executive assistant help each week, targeted research support for bet sizing, and a personal cadence with a leadership coach. The result wasn’t just more time; it was better time.
One provocative point that landed hard: product leaders rarely have executive assistants—and that’s a problem. If your calendar is your operating system, an EA is an extension of your leverage. Mine now handles scheduling, meeting hygiene, prep packets, and post-meeting artifacts. That shift moved me from “calendar triage” to “strategic curation.” It also reinforced a core principle: delegation is a leadership skill, not a weakness. When I delegate outcomes (not just tasks), my team learns, ownership grows, and we ship decisions faster.
Support for strategy work shouldn’t stop at the calendar. Research and data enable better bets. Lightweight research ops, access to product analytics, and brief synthesis sprints keep me anchored in evidence without drowning in artifacts. Paired with a strong community of practice, I get a steady stream of comparative patterns—how other leaders delegate, scope advisory boards, or run decision reviews—which short-circuits trial-and-error.
Coaches were framed as shortcuts for clarity, accountability, and skill-building—and I agree. A good coach compresses cycles, sharpens decision quality, and holds the mirror up when you drift into doer mode. Two quotes captured the mindset perfectly: “You are a pro athlete. It makes sense to think about how you scale your impact without adding more to your calendar.” — Petra Wille. “As you get busier, it becomes more important to focus on the value only you can bring.” — Teresa Torres.
There’s also a helpful nudge to let go of perfectionism: “80% done by someone else is 100% awesome.” — Dan Martell (quoted). In practice, that means I accept great drafts from others, then add the 10–20% only I can contribute—context, narrative, and the sharp edges of the decision.
What about AI? The conversation hits a practical middle ground I share: use AI where it compounds leverage—meeting summaries, research synthesis starters, doc outlines, and backlog triage. But keep humans where judgment, alignment, and context truly matter—strategy framing, stakeholder management, and the final decision-making loops. In other words, apply an AI Strategy that respects product leadership’s uniquely human work.
Key themes I took away: why product leaders struggle to scale themselves; the true cost of “doing it all yourself”; why not having executive assistants limits impact; delegation as a core leadership capability; how to identify and protect the work only you can uniquely do; using research and data to inform strategy; coaches as accelerators for clarity and accountability; communities of practice as a force multiplier; adopting a “professional athlete” mindset; when AI helps—and when humans still matter; and the liberating mantra that “80% done by someone else is 100% awesome.”
If you’re wondering where to begin, start small and practical. Audit your time: what work truly requires you? Experiment with small amounts of support (even a few hours a week). Delegate outcomes, not just tasks. Keep the hands-on work you love—but be intentional. Use peers, coaches, and communities to learn how others delegate. Don’t wait until burnout to build your support system.
Resources mentioned if you want to go deeper: Follow Teresa Torres: https://ProductTalk.org. Follow Petra Wille: https://Petra-Wille.com. Petra’s Coaching for Product Leaders: https://www.petra-wille.com/coaching-packages. Dan Martell’s book Buy Back Your Time: https://www.buybackyourtime.com.
I’m curious: what’s one outcome you’ll delegate this week, and what support would make it stick? Share your thoughts in the comments—your playbook might be exactly what another product leader needs right now.
Your calendar is full of approvals, but the problem probably isn’t that your team lacks initiative. The organization has learned that an important decision becomes safe only after you touch it.
You don’t fix that by telling people to be more empowered. You fix it by making authority, context, constraints, evidence, and escalation explicit. The goal is not to remove yourself from every decision. It is to ensure that your involvement is triggered by risk or abnormal variance, not by habit.
Delegation fails when you transfer work but retain judgment
A leader says, "You own this," but still expects to approve the plan, resolve every cross-functional conflict, and make the final tradeoff. The team receives responsibility without authority. It can prepare options, but it cannot truly decide.
The opposite failure is just as common. A leader transfers a decision with so little context that the owner must reconstruct the strategy, risk tolerance, and success criteria from scattered conversations. What looks like autonomy is actually abandonment.
Effective delegation sits between those extremes. You retain accountability for the quality of the operating system while another leader gains authority over a defined class of decisions. That person should know what outcome matters, which constraints are real, what evidence to use, and when the decision must return to you.
This is the transition many managers struggle with when they begin managing managers. Your value can no longer come primarily from supplying the best answer. It comes from installing mechanisms through which other leaders can repeatedly reach good answers.
Key takeaways
Delegate a decision domain, not merely the tasks required to prepare a decision.
Give each recurring decision one clearly named owner with enough authority to act.
Define constraints and escalation triggers before the owner encounters pressure.
Teach the reasoning behind past decisions so people can handle cases you did not anticipate.
Review outcomes and assumptions without reopening every decision you would have made differently.
Increase authority when judgment is consistently sound; intervene when risk, ownership, or evidence breaks down.
A useful test is to step away mentally and ask three questions: Would the priority remain intact? Would the relevant metrics continue to be watched? Would the team make approximately the same tradeoff without waiting for me? A no to any of them points to a missing mechanism, not automatically a weak employee.
Build a minimum decision contract
Before delegating a consequential decision, write a short decision contract. This is not a policy manual. It is the minimum context another capable leader needs in order to act without repeatedly requesting permission.
The contract should answer the following questions:
What decision is being delegated? Name the decision class precisely. "Own onboarding" is vague. "Choose and sequence onboarding experiments within the agreed quarterly outcome" is actionable.
Who decides? Assign one decision owner. Other people may contribute expertise, execute the work, or challenge assumptions, but shared input should not create ambiguous ownership.
What outcome governs the tradeoff? Connect the decision to an outcome and its driver tree. Without that connection, the owner will optimize for the loudest stakeholder or the most visible output.
What is inside the owner’s authority? State the product area, customer segment, time horizon, resources, and dependencies covered by the delegation.
Which constraints are real? Separate non-negotiable boundaries from preferences. If every preference is presented as a constraint, authority remains fictional.
What evidence is expected? Identify the metrics, customer evidence, technical inputs, or operating assumptions that should inform the choice.
What requires escalation? Define the conditions that change the decision from local to executive. Use observable triggers where possible.
When will the result be reviewed? Set the review around the availability of meaningful evidence, not the leader’s desire for reassurance.
Decision rights also need a verb. "Involved" is not a decision right. Use language such as recommend, decide, approve, execute, or advise. If two people both believe they approve, the real decision will drift upward when disagreement appears.
For a recurring product decision, the contract might say that a product leader decides which discovery opportunities to pursue, design and engineering advise on feasibility, and the executive is informed through the normal review cadence. Escalation occurs only if the choice changes the agreed strategy, creates an existential risk, lacks a credible metric owner, or exposes a material contradiction between the operating narrative and the numbers.
That final distinction matters. Notification is not permission. If a leader must wait for your reaction after every update, the supposed decision owner will learn to delay action until you respond.
Use a one-page decision brief for consequential choices
A decision brief makes judgment inspectable without forcing you into every working session. Keep it short enough to use under normal operating pressure:
Decision to make and why it must be made now
Owner and affected teams
Desired outcome and relevant driver-tree nodes
Options considered
Recommendation and rejected alternatives
Critical assumptions and evidence
Constraints and downstream consequences
Escalation triggers
Date or signal for reviewing the result
The brief should expose reasoning, not reward document production. If the owner cannot state the governing outcome, the most fragile assumption, and the reason for rejecting the strongest alternative, more pages will not solve the problem.
Teach judgment through driver trees and decision records
Rules cover familiar situations. Judgment covers the cases no rule anticipated. If you want delegated decisions to survive ambiguity, you have to make your mental models visible.
Start with the outcome. Decompose it into the controllable levers that could plausibly move it, instrument those levers, and assign each one a single-threaded owner. Document the assumptions that connect one level of the tree to the next. This forces a team to distinguish a desired result from the mechanism expected to produce it.
Suppose the desired outcome is stronger customer expansion. A team might initially examine the eligible expansion base, adoption of additional capabilities, realized usage, retention, and the acceptance of relevant offers. That is a hypothesis about causality, not a permanent truth. The team should test whether those nodes actually explain movement in the outcome and revise the tree when the evidence disagrees.
This changes the delegation conversation. Instead of asking, "Do I like this roadmap?" you can ask:
Which driver is the decision intended to move?
What evidence connects the proposed work to that driver?
Which assumption would invalidate the recommendation?
How quickly would the team detect that the assumption was wrong?
Who owns the metric after the decision is made?
What other driver might deteriorate as a result of this choice?
Those questions teach a reusable method. Simply giving the answer teaches the team that your presence is the method.
Record why the decision made sense at the time
A lightweight decision record should preserve the recommendation, assumptions, evidence, expected effect, owner, and review trigger. Its purpose is not to create an audit trail for blame. It is to make organizational learning possible.
Without the original assumptions, a later review is distorted by hindsight. A good outcome can hide poor reasoning, while a bad outcome can follow a sound decision made with incomplete information. Evaluate the process and the result separately.
Decision records also reveal patterns that coaching conversations miss. You may discover that a leader consistently underweights second-order effects, treats weak signals as conclusive, escalates too late, or avoids choices that create short-term metric pressure. That is actionable feedback because it concerns a repeatable reasoning pattern rather than one disputed answer.
Shared metric definitions matter here. If product, sales, marketing, and customer success use different meanings for activation, retention, or expansion, their decisions can appear aligned while optimizing different realities. Define the metric, its data source, its owner, and the assumptions beneath it. Shared language reduces the amount of executive translation required at every cross-functional seam.
Review variance without taking the decision back
A review cadence can scale judgment, or it can quietly recreate centralized approval. The difference lies in what the meeting is designed to do.
Monthly business reviews and quarterly business reviews should connect narrative to numbers. They should reveal whether assumptions still hold, where performance has deviated, who owns the response, and whether the deviation crosses an agreed threshold. They should not become ceremonies in which every team waits for an executive to rewrite its plan.
I use variance as the cue for changing altitude. A stable system with credible owners deserves space. An existential risk, an unowned metric, or a conflict between the explanation and the data warrants a deeper dive.
Signal
Leadership response
What to avoid
Metrics remain within agreed control limits and the owner explains the drivers credibly
Stay at the outcome level and let the owner act
Re-litigating tactics because you have a different preference
A leading indicator departs from its expected range
Ask for a focused diagnostic, owner, and next decision point
Changing the entire strategy before identifying the affected driver
The narrative and the numbers conflict
Inspect definitions, data sources, assumptions, and causal reasoning
Accepting a persuasive story without resolving the contradiction
A material metric has no credible owner
Clarify ownership before debating solutions
Becoming the permanent owner by default
The downside could threaten the business
Enter the decision directly and make the risk explicit
Preserving the appearance of delegation at the expense of accountability
The same class of mistake keeps recurring
Repair the decision mechanism and coach the reasoning pattern
Correcting each incident as though it were isolated
When you dive deep, tell the team why. Otherwise, a risk-based intervention can be interpreted as a permanent withdrawal of authority. Say which trigger fired, what part of the decision you are entering, and what authority the owner still retains.
When you step back, do that explicitly too. Silence is ambiguous. The owner needs to know whether you trust the decision, missed the update, or expect another approval request.
Run post-decisions, not blame sessions
After meaningful evidence arrives, compare the result with the original decision record. Ask what happened, which assumptions held, which failed, what signal appeared first, and how the decision mechanism should change.
Do not use the review to prove that your preferred option would have worked. That teaches leaders to protect themselves through escalation and excessive consensus. The useful output is a better assumption, threshold, driver tree, or decision right that improves the next choice.
Grow authority as leaders demonstrate judgment
Delegation should expand with evidence. A leader may begin by developing options and making a recommendation. As the leader demonstrates sound framing, timely escalation, and consistent tradeoffs, the role can move toward deciding within guardrails and then owning the domain with routine visibility rather than prior approval.
The progression should depend on decision quality, not confidence, tenure, or presentation skill. Look for observable behavior:
The leader frames the decision around an outcome rather than a preferred deliverable.
The strongest alternatives are represented fairly before being rejected.
Assumptions are made explicit and matched to evidence.
Short-term gains are weighed against longer-term consequences.
Cross-functional effects are surfaced before they become escalation points.
Bad news moves upward early enough to preserve options.
Results and learnings are documented without defensiveness.
The leader improves the mechanism after a miss instead of merely promising more effort.
This is where demanding and supportive leadership must coexist. Set an unambiguous bar for reasoning and ownership. Then provide fast feedback, coaching, access to context, and the resources required to meet that bar. High expectations without mechanisms create anxiety. Support without a clear bar creates dependence.
Ask leaders to bring a proposed path with the problem, but do not turn that expectation into a penalty for early escalation. The useful behavior is: "Here is what changed, here is my current diagnosis, here are the options, and here is where I need help." Requiring a polished solution before escalation delays the moment when executive context is most valuable.
Repeated escalations are diagnostic data. If capable people keep returning the same decision to you, inspect the system before questioning their courage. The constraint may be a disputed metric, incompatible incentives, an absent owner, an unclear strategic boundary, or a consequence they lack the authority to absorb.
You should also inspect your own behavior. If you routinely reverse reasonable decisions without explaining the mental model, demand visibility that functions as approval, or punish a well-reasoned miss, the organization will rationally centralize around you.
Know when the system is working
A delegated decision system is becoming durable when priorities survive your absence, tradeoffs remain legible across functions, and teams escalate exceptions instead of routine choices. Leaders can explain not only what they decided but why the decision fits the strategy, metrics, time horizon, and risk boundaries.
Your calendar should change as a consequence. Less time goes to status translation and habitual approvals. More time goes to strategy, architecture, resourcing, talent, and the small number of deviations that genuinely need executive attention.
Start with one recurring decision that currently waits for you. Name its owner, write the minimum decision contract, define the escalation triggers, and schedule a review around evidence. Then resist the urge to improve the decision by taking it back. Improve the system that produced it.
References
Shivam.Consulting Blog — Mastering 30,000-Foot Vision and Ground-Level Execution: Systems That Decide Without You
