Tag: product culture

  • How Leaders Turn Organizational Storytelling Into Execution

    How Leaders Turn Organizational Storytelling Into Execution

    When product, engineering, sales, and support give different explanations for the same priority, the problem is rarely a lack of communication. Each group may be communicating frequently and clearly. They are simply working from different stories about the customer, the strategy, and what matters now.

    Your job as a leader is not to make everyone memorize a polished pitch. It is to give the organization a shared causal model: who is struggling, what changed, which outcome matters, what the company has chosen to do, and which trade-offs follow from that choice. When the story is specific enough to govern decisions, alignment becomes visible in the work.

    Treat the story as decision infrastructure

    An organizational story is not the company origin story, a collection of values, or the opening slide in a strategy presentation. It is a repeatable explanation of how the organization expects to create change for a particular customer or stakeholder.

    The distinction matters because communication and management have different standards. Communication succeeds when people understand a message. Management succeeds when people can use that message to make a good decision without sending every ambiguity back up the hierarchy.

    This becomes especially important when certainty is unavailable. Product leaders rarely receive a complete answer before they must act. The useful leadership move is to make the next defensible decision, explain the trade-offs, and keep learning. A credible story gives that decision continuity without pretending that an informed bet is a proven fact.

    You can tell whether the story is functioning as decision infrastructure by asking whether a team can answer these questions:

    • Which customer or stakeholder receives priority when needs conflict?
    • What observable change is the team trying to create for that person?
    • Why is this problem important now rather than merely interesting?
    • Which capabilities or principles will the organization rely on?
    • What will the organization deliberately decline, delay, or stop?
    • Which assumption would cause the strategy to change if it proved false?

    If the answers are missing, a slogan will not repair the gap. If the answers exist but leaders respond differently, the organization has a strategy disagreement disguised as a messaging problem. Resolve the disagreement before asking a communications team to make the language more memorable.

    Write a narrative that can survive a hard decision

    A useful first draft should fit on one page. The constraint forces the leadership team to expose choices that a long presentation can hide. Build it in six parts, and make every part concrete enough to reject at least one plausible alternative.

    1. Name the person and context. Avoid a market label such as mid-market companies or modern teams. Identify the person making or experiencing the decision and the situation in which the problem appears. Different people inside the same account can have conflicting needs.
    2. Describe the struggle and its consequence. State what the person is trying to accomplish, what obstructs progress, and what happens if the obstruction remains. Do not smuggle the proposed feature into the problem statement.
    3. Explain what changed. A strategy needs a reason to act now. The change might be in customer expectations, technology, regulation, economics, company capability, or competitive context. If nothing material changed, the supposed urgency may be internal enthusiasm rather than customer need.
    4. Commit to an outcome. Describe the improvement the customer or stakeholder should experience. Shipping a capability is an activity; changing the quality, speed, cost, confidence, or accessibility of an important task is an outcome.
    5. State the strategic choice. Name the mechanism, capability, or principle the organization believes will create that outcome. This is where the narrative becomes more than a problem description. The choice should explain why some initiatives belong on the roadmap and others do not.
    6. Expose boundaries and uncertainty. List a consequential non-goal, the assumption carrying the most risk, and the evidence that would strengthen or weaken the belief. A story that includes no boundary is a wish list. A story that includes no uncertainty is certainty theater.

    The compact template is: For a specific person in a specific context, a defined struggle causes a meaningful consequence. A relevant change makes the current approach inadequate. The product or organization will create a named outcome through a deliberate strategic choice. It will not pursue a stated non-goal. The strategy depends on an explicit assumption, which will be tested with relevant evidence.

    Consider a hypothetical support product. For regional support managers whose agents search several systems during customer calls, fragmented guidance slows the path to an approved answer. The product will put governed guidance inside the agent workflow. It will not automate exception decisions. The initial bet is that easier access to trusted guidance will improve resolution, and discovery must test both access and trust.

    That example is intentionally unpolished. Its value comes from the decisions it enables. A roadmap item that does not improve access to trusted guidance is suspect. A proposal to automate exceptions conflicts with the boundary. Research showing that trust, rather than access, is the dominant obstacle would force the strategy to change. The narrative has done managerial work before anyone turns it into a presentation.

    Read your draft aloud and remove any sentence that could describe a competitor without changing a word. Phrases such as seamless experience, customer obsession, and intelligent platform often sound agreeable because they contain no meaningful choice. Replace them with the customer, consequence, mechanism, and boundary that only this strategy would produce.

    Install the story in product and people management

    A story that appears only at an annual kickoff will decay into corporate folklore. Reinforcement does not mean repeating the same speech more often. It means embedding the narrative in the places where priorities, resources, and careers are decided.

    Translate the narrative into product work

    • Roadmaps: Require every initiative to identify the narrative clause it advances, the customer change it should create, and the work displaced by choosing it. If an initiative connects only to a broad aspiration, the connection is too weak.
    • Planning: Begin with the customer condition the team intends to change, not the inventory of tickets. Then ask which work is necessary for that change and which work merely preserves momentum from the previous plan.
    • Discovery: Use recurring customer conversations to test the language, assumptions, and causal logic behind the story. Continuous discovery is valuable partly because it can reveal an assumption the team did not know it was making. Capture contradictions, not just supporting quotations.
    • Decision records: For a consequential choice, record the decision, the relevant narrative clause, the trade-off accepted, the evidence used, and the condition that would reopen the decision. This preserves context after the meeting ends.
    • Executive reviews: Start with the expected customer or business change and compare it with what has been observed. A review organized around the gap between expectation and evidence produces a better conversation than a tour of completed activity.

    One prompt can improve almost any decision meeting: What customer change must this decision create? Before the meeting closes, capture what was chosen, what was rejected, which assumption remains exposed, and what evidence would justify revisiting the choice.

    Translate the narrative into management behavior

    Organizational storytelling belongs in the same operating toolkit as executive hiring and management development. The story tells people what the organization claims to value. Management systems reveal what it actually values.

    • Hiring: Give candidates a real strategic tension and ask how they would reason through it. The goal is not agreement with the current answer. Look for the ability to identify the customer, surface assumptions, make a choice, and explain a trade-off.
    • Onboarding: Teach the story before distributing a catalogue of processes. Then ask each new leader to translate it for the decisions their function owns. Story-first onboarding, recurring rituals, and asynchronous video can reinforce the same logic without turning every explanation into another meeting.
    • Delegation: Transfer a decision boundary, not just a task. State the outcome, constraints, evidence standard, and escalation condition. Leaders who consciously hand off ownership and invest in strong performers reduce bottlenecks while creating room for other people to grow.
    • One-to-ones: Ask where the employee sees a conflict between the stated narrative and current priorities. This question surfaces strategic drift and gives high performers a substantive problem to help solve.
    • Recognition and rewards: Match incentives to the story. If leadership says outcomes matter but celebrates feature volume, the feature count is the real narrative. If leadership says focus matters but never stops work, the backlog is the real strategy.
    • Retention: Do not use an inspiring mission to rationalize unsustainable expectations. Loyalty without boundaries can become burnout, and recognition, growth paths, compensation, and workload expectations need attention before an exit forces the conversation.

    This is the integrity test for organizational storytelling: can an employee predict what leaders will fund, stop, delegate, recognize, and protect? If leadership behavior repeatedly contradicts the narrative, more storytelling will make the contradiction easier to see. Change the behavior or change the story.

    Keep the story credible under uncertainty and pressure

    The strongest organizational story is not the most confident one. It is the one that separates conviction from evidence without leaving the organization directionless. A leader still has to choose; transparency about uncertainty does not outsource judgment to the team.

    Label facts, assumptions, and choices

    Review the narrative line by line and assign each claim to one of three categories:

    • Fact: Something directly observed or established, with enough context to understand its limits.
    • Assumption: A causal belief or expectation that remains open to testing.
    • Choice: A leadership commitment about where to focus, what to build, or what to decline.

    Teams get into trouble when a choice is presented as an inevitable fact or an assumption is treated as settled evidence. The labels make disagreement more productive. A disputed fact needs better evidence. A disputed assumption needs a test. A disputed choice needs accountable leadership and a clear rationale.

    Pressure-test the narrative before reality does

    1. Invert the outcome. Ask what would most likely be true if the strategy failed. This inversion prompt exposes hidden dependencies, weak evidence, and attractive work that does not address the main risk.
    2. Replay the customer’s language. Check whether internal terms mean the same thing to the person experiencing the problem. Even an apparently ordinary instruction can expose a hidden interpretation. Do not resolve the ambiguity by explaining what the customer should have understood; revise the language and the underlying model.
    3. Audit narrative drift. Ask several leaders, separately, to name the priority customer, the customer outcome, the strategic mechanism, and the clearest non-goal. Do not score them on identical wording. Compare the decisions their answers would produce.
    4. Define revision triggers. Decide which evidence would change an assumption, which leadership decision would change a strategic choice, and which contextual change would require a new story. Without triggers, a narrative either changes with every opinion or survives long after its logic has failed.

    You may have accumulated story debt when routine decisions require executive escalation, functions optimize incompatible outcomes, customer-facing teams make conflicting promises, or each planning cycle restarts the same strategic debate. Those are not requests for a better slogan. They are signals that the causal model is incomplete, contested, or absent from operating mechanisms.

    Keep the purpose stable enough to coordinate action, but keep the mechanism open to evidence. That balance gives people a direction they can trust without asking them to defend a narrative that customers or results have already contradicted.

    Key takeaways

    • An organizational story earns its place when teams can use it to make decisions without escalating every ambiguity.
    • The minimum useful narrative names the person, struggle, changed context, outcome, strategic choice, boundary, and exposed assumption.
    • Alignment means compatible decisions, not identical wording.
    • Roadmaps, discovery, hiring, onboarding, delegation, rewards, and retention must reinforce the same logic.
    • Facts, assumptions, and choices should be labeled differently because each kind of disagreement requires a different response.
    • If leadership behavior conflicts with the story, fix the behavior or revise the story before increasing communication.

    Before your next planning review, put the current strategy into the compact narrative template. Ask the leaders who own product, engineering, sales, and customer outcomes to translate it into the decisions they expect to make. Find the disagreement with the largest operational consequence, resolve it, and record the resulting trade-off. That is where organizational storytelling stops being presentation craft and starts becoming leadership.

    References

  • Engineering Org Design That Creates Real Ownership

    Engineering Org Design That Creates Real Ownership

    You are considering a reorg because delivery feels slower than it should. Work crosses too many teams, routine decisions climb the management chain, and reliability loses every argument against the next visible feature. The boxes on the org chart look reasonable, yet nobody can give a clean answer when you ask who owns the result.

    Changing reporting lines may relieve some pressure, but ownership comes from a wider system: durable team boundaries, explicit decision rights, measurable outcomes, lifecycle obligations, and a cadence that exposes reality early. Design those elements first, and you can tell whether you need a reorg at all.

    Diagnose the ownership failure before moving teams

    An org chart tells you who manages whom. It rarely tells you who can change a roadmap, accept a technical trade-off, resolve a dependency, lead an incident, or retire a service. Those are the decisions through which ownership becomes visible.

    Start with a recent outcome that slipped, not with the current reporting structure. Trace the work from the original goal to the final decision and ask:

    • Which customer or business outcome was supposed to change?
    • Which team was accountable for moving it?
    • Which decisions could that team make without seeking permission?
    • Where did the work wait for another team, manager, or committee?
    • Who owned quality, operation, measurement, and follow-through after release?
    • What evidence would have caused the team to change or stop the plan?

    The answers usually expose a more precise problem than lack of ownership:

    • Outcome ambiguity: several teams delivered components, but no team owned the end result.
    • Authority ambiguity: a team was held accountable for an outcome while another group controlled the important decisions.
    • Scope ambiguity: two teams believed they owned the same capability, or each assumed the other did.
    • Interface ambiguity: dependencies existed, but there was no agreed way to prioritize requests or resolve conflicts.
    • Lifecycle ambiguity: the launch had an owner, while reliability, support, instrumentation, and retirement did not.

    A useful diagnostic is to inspect a team as a black box. Look at the priorities and constraints going in, the decisions and releases coming out, and whether the intended outcome moved. High output with a flat outcome is not evidence that the team needs more velocity. It may mean the bet was wrong, the feedback loop was weak, or the team lacked authority to change course.

    Do not redraw the boxes until you can name the failure in one sentence. A structural response is useful when the boundary itself creates the problem. It is expensive theater when the real issue is an unclear priority, an absent decision rule, or a manager who will not delegate.

    Give every team an explicit ownership contract

    A team charter should be a compact operating contract, not a mission statement nobody uses. A new engineer, product manager, or executive should be able to read it and understand what the team exists to change, what it controls, and where its authority stops.

    Include these fields:

    • Mission: the durable problem the team exists to solve.
    • Customer: the external user or internal consumer whose result matters.
    • Outcomes: the behavior, business result, or system condition the team is expected to improve.
    • Scope: the products, workflows, services, data, or capabilities it owns.
    • Decision rights: the product and technical choices it can make independently.
    • Lifecycle obligations: operation, instrumentation, security, reliability, documentation, migration, and retirement.
    • Interfaces: the teams it depends on, the teams that depend on it, and how conflicts are resolved.
    • Signals: the outcome and health measures that reveal whether the team is succeeding.

    Weak charters name a noun: own onboarding, own the API, or own the platform. Strong charters connect a durable scope to an outcome. A stronger onboarding charter, for example, would identify the customer segment, define the meaningful activation result, include the workflow and its instrumentation, and state which identity or billing decisions remain outside the team. The exact language matters less than whether it closes the obvious escape routes.

    Decision rights need three levels:

    • Decide: choices the team can make and communicate without approval.
    • Consult: choices the team owns but must make with input from affected groups.
    • Escalate: choices that change another team’s commitments, create material cross-company risk, or violate a shared constraint.

    This prevents two opposite failures. A vague instruction to collaborate can turn every decision into consensus-seeking. A vague instruction to move fast can let one team export cost and risk to everyone around it. Explicit consultation and escalation rules preserve speed without pretending dependencies do not exist.

    Shared outcomes do not require blurred roles. One practical product-engineering split is to make product leadership accountable for problem framing and priority, engineering leadership accountable for technical design and operability, and the cross-functional team accountable for outcome evidence and trade-offs. Adjust that split to your context, but do not leave a consequential decision unassigned because everyone is jointly responsible.

    For cross-team bets, name one accountable leader. This is the useful part of single-threaded leadership: there is one person responsible for maintaining the goal, forcing unresolved decisions, and reporting the state of the outcome. It does not make that person the sole decision-maker, replace specialist judgment, or turn collaborating teams into an order-taking queue.

    Draw boundaries around durable outcomes, not temporary projects

    Projects end. Ownership persists. If a team’s identity disappears whenever the roadmap changes, the team is probably a temporary delivery group rather than a durable organizational unit.

    Test a proposed boundary with a cancellation question: if the current initiatives stopped, would this team still have a coherent customer, mission, system, and set of health obligations? If not, keep the project temporary and preserve the durable homes of the people and systems involved.

    Boundary patternUseful whenCommon failure modeOwnership test
    Customer journeyOne outcome spans several screens, services, or stepsComponent teams optimize their parts while the end-to-end experience degradesCan the team improve the complete customer result without negotiating every routine change?
    Product areaA stable set of customer needs maps to a coherent product surfaceThe area becomes a feature factory with no outcome definitionCan the team explain the behavior or business result its area should change?
    Platform capabilitySeveral teams need a shared technical primitive or internal serviceThe platform becomes a backlog of requests with no product judgmentAre the consumers, adoption goal, reliability obligations, and prioritization rules explicit?
    System health or riskReliability, security, integrity, or another cross-cutting condition needs sustained expertiseOther teams assume the specialist group owns every local implementation and consequenceIs the central team’s role separated clearly from each product team’s obligations?

    No boundary removes dependencies. The aim is to place the people who make frequent, tightly coupled decisions close enough to make them quickly. For each remaining dependency, define what is provided, how work enters the relationship, how priorities are negotiated, and who decides when commitments conflict. Dependencies become expensive when they are anonymous and unmanaged, not merely because they exist.

    For an AI product, I would reject a boundary that owns only the interface while model behavior, evaluation, telemetry, fallback behavior, latency, and cost have no end-to-end owner. A platform team may own shared model access or evaluation infrastructure. The product team still needs to own the customer result, integrate the relevant signals, and initiate the diagnosis when that result deteriorates.

    Use that same test outside AI: when the outcome degrades, can one named team start the investigation, bring the right partners together, and remain accountable until the problem is understood? If the answer depends entirely on which layer failed, the organization owns components but not the result.

    Build an operating cadence that protects autonomy

    Autonomy without feedback becomes drift. Feedback without decision rights becomes micromanagement. Ownership needs sharp priorities, explicit decision rights, and fast feedback loops at the same time.

    Give each planning artifact one job:

    • Strategy explains where the organization will compete, why the problem matters, and which constraints are non-negotiable.
    • Outcome or OKR states the change the team is trying to create. It should not be a renamed feature list.
    • Roadmap records the bets the team currently believes can produce that change, along with the important assumptions.
    • Sprint plan selects the next work needed to deliver, learn, or reduce material risk.
    • Review examines evidence and decides whether to continue, change, stop, or escalate a bet.

    When strategy, roadmapping, delivery, and review collapse into one document, every change looks like broken execution. Separating them lets the team preserve a stable outcome while changing its bets as evidence improves. A roadmap can change without casually abandoning the goal; a sprint can change without reopening the entire strategy.

    Product and engineering should run one shared operating rhythm. Separate status systems encourage product to report launches while engineering reports tickets, incidents, and technical milestones. Neither view alone explains whether the team improved the customer result sustainably.

    A short weekly narrative update is enough to keep the system honest. Use the same prompts each time:

    • Outcome: what changed in the result, including no meaningful movement.
    • Evidence: what the team learned from customers, usage, delivery, or system behavior.
    • Decision: what the team decided because of that evidence.
    • Risk: what could invalidate the plan or damage system health.
    • Ask: which constraint the team cannot remove with its current authority.

    No movement is a valid update. Hiding it behind a list of completed work is not. The point is to expose the gap between effort and effect while there is still time to change the plan.

    Use a balanced set of signals rather than one metric that can be optimized in isolation:

    • An outcome signal showing whether customer or business behavior changed.
    • A delivery signal showing whether the team can move work through its system predictably.
    • A health signal showing whether reliability, security, cost, or maintainability is deteriorating.
    • A learning signal showing whether a material assumption was validated, rejected, or remains unknown.

    The manager’s job in this cadence is to clarify priorities, remove constraints, improve decisions, and hold the team to the outcome. Rewriting the solution from above may accelerate one decision, but it teaches the organization to wait for the manager the next time ambiguity appears.

    Treat ownership as a system you maintain

    Make lifecycle work part of the mission

    A team does not own a product if it owns only feature delivery. The ownership contract must include the work that appears after the launch and the work that prevents a launch from becoming unsafe or unsustainable.

    • Instrumentation and alerting
    • Reliability and incident follow-through
    • Security and privacy obligations
    • Product-specific technical debt
    • Documentation and internal support
    • Migrations, deprecations, and retirement
    • Cost and capacity trade-offs

    Give reliability, security, and platform health explicit capacity and visible trade-offs during planning. If this work must compete as an unnamed remainder after feature commitments are made, it does not have real ownership.

    A generic technical-debt bucket is difficult to prioritize. Bring each material item into planning with a concrete case:

    • The failure mode or constraint that exists now
    • The customer, business, or operational exposure it creates
    • The way it slows or limits future change
    • The proposed response and the opportunity cost of doing it
    • The signal that would show the risk or constraint has improved
    • The team that will own the result after the work is complete

    Central platform teams should own genuinely shared capabilities. Product teams should retain responsibility for how they use those capabilities and for the downstream customer result. Otherwise, the platform becomes the default owner of every local quality problem while product teams remain accountable only for visible launches.

    Align the people system with the ownership model

    Ownership language collapses when the career system rewards something else. If engineers advance only through individual output, managers are praised for personally solving the hardest problems, and cross-team stewardship is invisible, people will rationally optimize against the operating model.

    The IC-to-manager transition is especially important. The new manager’s unit of performance is no longer personal velocity. It is the team’s ability to make sound decisions, deliver sustainably, learn from evidence, and grow people who can handle broader scope. A manager who remains the required technical or product decision-maker has increased the team’s bus factor without increasing its ownership.

    • Evaluate managers on clarity, delegation, organizational throughput, talent development, and outcome health.
    • Evaluate senior individual contributors on technical judgment, scope, leverage, and the quality of decisions they enable across the system.
    • Reward product and engineering leaders for joint outcomes instead of encouraging each function to defend its own output.
    • Make expectations visible enough that broader ownership translates into career growth rather than unrecognized extra work.

    A titleless organization may reduce status friction, but removing titles does not remove hierarchy, compensation decisions, or the need for career clarity. Do not copy that design unless leveling, pay, performance expectations, and the path between individual contribution and management remain explicit. Titles are optional; a legible growth system is not.

    Prune the structure before drift becomes a reorg

    Even a sound design degrades as products, people, and dependencies change. Make regular pruning and shaping part of the operating cadence rather than waiting for a dramatic reorganization.

    During each planning cycle, inspect the ownership map:

    • Are two teams pursuing overlapping missions?
    • Does an important outcome have contributors but no accountable owner?
    • Are routine decisions repeatedly escalating beyond the team?
    • Has a temporary dependency become a permanent operating relationship?
    • Does a manager oversee unrelated missions that require different context and cadences?
    • Has a platform accumulated consumers without a clear prioritization model?
    • Does any team still measure success mainly by features or tickets completed?

    Prefer the smallest intervention that fixes the observed failure. Clarify a decision right, rewrite a charter, move a tightly coupled capability, split an incoherent mission, or consolidate duplicate ownership. Change reporting lines when reporting lines are actually blocking coaching, prioritization, or accountability.

    When you do move ownership, treat the transition as real work. Name the transition owner, inventory the services and roadmap commitments being transferred, document unresolved risks and dependencies, and publish the point at which accountability changes. Until that transfer is complete, the current owner remains accountable. A silent handoff creates exactly the ambiguity the reorg was meant to remove.

    Key takeaways

    • An org chart defines reporting relationships; an ownership system defines outcomes, authority, scope, interfaces, and lifecycle obligations.
    • Diagnose a missed outcome before choosing a structural fix. Ambiguous priorities and weak delegation do not require a reorg.
    • Give every durable team a written charter with a customer, outcome, decision rights, boundaries, health obligations, and dependency rules.
    • Organize around enduring customer results, product areas, platform capabilities, or system conditions rather than temporary projects.
    • Protect autonomy with a shared product-engineering cadence that connects strategy, outcomes, roadmap bets, sprint work, and evidence.
    • Include reliability, security, technical debt, operation, and retirement in ownership instead of treating them as leftover work.
    • Maintain the design through routine pruning and explicit ownership transfers.

    Start with the team where cross-functional friction is most visible. Draft its ownership contract with the people doing the work, run the next planning cycle against it, and trace every delayed decision or operational surprise back to a missing field. If the charter becomes clear but the reporting structure still prevents the team from acting on it, you now have a precise reason to reorganize.

    References

  • Build a Leadership, Talent, and Culture System That Scales

    Build a Leadership, Talent, and Culture System That Scales

    You may recognize the failure pattern. The company hires stronger leaders, adds management layers, publishes values, and runs more surveys – yet decisions get slower, good people become uncertain about their future, and culture feels less consistent with every new team.

    Those are rarely three separate problems. They are usually one systems problem. Leadership defines who can decide. Talent determines which capabilities enter and grow inside the company. Culture shapes how people behave when the process cannot tell them exactly what to do. If those mechanisms send different signals, adding another program will create more noise. You need one operating system that connects the role you design, the person you hire, the way you onboard them, the behavior you reward, and the feedback you use to improve the system.

    Key takeaways

    • Design leadership roles backward from the business you expect to have in 12-24 months. A title is not a role definition; outcomes, decision rights, interfaces, and required capabilities are.
    • Use one evidence chain from the hiring scorecard through interviews, references, onboarding, and performance reviews. Changing the standard after someone joins is a common source of executive failure.
    • Define culture through difficult trade-offs and observable behavior. A value that cannot alter a hiring decision, product decision, or performance conversation is still only a slogan.
    • Treat conflict, 360 feedback, retention, and career development as signals from the same system. Each one can reveal unclear ownership, weak capabilities, misaligned incentives, or leadership behavior that needs to change.
    • Fix contradictions between mechanisms before launching new programs. Coherence compounds; disconnected rituals consume attention without building trust.

    Design the leadership role from the business trajectory

    A leadership search often starts too late in the reasoning process. Someone proposes a title, the title produces a familiar job description, and interviewers begin looking for people who have already held it. That sequence selects for resemblance. It does not establish what the business needs.

    Start with a 12-24 month view of the company. Identify the outcomes that must become possible, the organizational bottlenecks likely to emerge, and the decisions that currently depend on a founder or overloaded executive. Then work backward into the role.

    A useful leadership charter answers six questions:

    1. Why does the role exist now? Name the business constraint it removes, not the collection of functions it supervises.
    2. Which outcomes does it own? Choose results the leader can materially influence. Avoid activity lists disguised as accountability.
    3. Which capabilities must improve? Examples might include turning ambiguity into a product strategy, building an executive bench, connecting design to go-to-market execution, or creating a repeatable operating cadence.
    4. Which decisions belong to the role? Specify what the leader owns, recommends, shares, must consult on, and is merely informed about.
    5. Which interfaces must work? Name the peers and functions with whom the leader must repeatedly resolve trade-offs. An executive can perform well inside a function and still fail at its boundaries.
    6. What should be measurably better after the first year? Describe durable organizational changes, not the personal effort you expect to see.

    Compress the charter into a sentence that can survive repetition: "This role exists to [create an outcome] by [building capabilities], owns [critical decisions], and succeeds when [business and organizational evidence] changes." Use that sentence with candidates, peers, and the team. If those groups hear different explanations, the ambiguity will eventually surface as conflict.

    This exercise also exposes stage mismatch. A leader who is excellent at optimizing an established system may struggle when the system does not exist. A strong specialist may lose effectiveness when the job requires building across several functions. Conversely, hiring a celebrated executive far ahead of the company’s actual complexity can add process before there is enough repeatable work to support it. The right question is not whether a candidate is impressive. It is whether their operating range matches the next set of constraints.

    Use the same clarity when adding a leader above an early employee. Explain the business capability the new layer supplies, which decisions will move, what the current leader will continue to own, and which growth path remains open. Presenting the change as a vague need for "more experience" invites people to translate it into a judgment about their worth. Clear scope preserves dignity and gives both leaders a fair chance to work.

    Use one evidence chain from hiring through onboarding

    The best hiring process is not the one with the most interviews. It is the one in which each stage tests a defined requirement, produces comparable evidence, and prepares the company to support the person after the offer.

    Build the scorecard before selecting interviewers. For a product or functional leader, I would usually separate five kinds of evidence:

    • Stage outcomes: Has the person delivered work comparable to what this company needs next, under similar constraints?
    • Operating judgment: Can they frame choices, expose trade-offs, make a decision, and stay accountable for the result?
    • Learning velocity: Can they show where new evidence changed a strongly held view, including what they did after recognizing the mistake?
    • Cross-functional leverage: Do peers become more effective around them, or does the candidate succeed by absorbing every important decision?
    • Talent multiplication: Have they developed successors, expanded other people’s scope, and raised standards without making the organization dependent on them?

    Replace broad prompts such as "How do you lead?" with decision reconstruction. Ask the candidate to walk through a consequential choice from context to outcome: what they knew, which options they considered, who disagreed, which trade-off they accepted, what they measured, and what they would change. Ask what broke as their organization moved from one stage to another. Ask who could take over their previous role and what they did to prepare that person. Specific sequences are harder to manufacture than leadership philosophy.

    A work sample can add signal when it resembles the job. Use a real but sanitized problem, keep the exercise time-boxed, and tell the candidate what is being assessed. The useful evidence is how they clarify the problem, request missing context, prioritize, communicate uncertainty, and work with other people. A large take-home presentation often measures available time and presentation polish more than day-to-day operating ability.

    Score independently before the debrief. Require interviewers to attach examples to their ratings. "Strong culture fit" and "not strategic enough" are conclusions without evidence. Translate them into observed behavior tied to the scorecard. This makes disagreement discussable and reduces the chance that the most senior interviewer becomes the rubric.

    Run references with the same structure and with appropriate candidate permission. Ask what the leader improved that remained better after they moved on, how they responded to a miss, whether the reference would rehire them for this particular stage, and what is most likely to make the first 90 days difficult. Do not treat the predicted difficulty as automatic disqualification. Turn it into an onboarding guardrail and test whether your organization can provide the support it requires.

    Once the person accepts, do not replace rigor with a calendar full of introductions. A 30/60/90 plan should extend the hiring thesis:

    1. By day 30: Confirm the role charter, map the system, understand the customer and business context, and surface where actual decision rights differ from the documented ones.
    2. By day 60: Own a meaningful decision or operating problem with the relevant peers. The goal is not a theatrical quick win; it is evidence that the new leader can use the company’s interfaces.
    3. By day 90: Deliver an initial outcome and establish at least one mechanism that can repeat without personal heroics, such as a decision cadence, quality review, talent process, or customer feedback loop.

    Identify the first 10 relationships the leader needs to cement. For each one, clarify the shared outcome, recurring decisions, likely tension, and preferred escalation path. Include customer-facing partners, not only executives. Pairing product or design leaders with someone in solutions, sales, support, or implementation often compresses the time needed to understand how product choices meet the market.

    Schedule explicit feedback at weeks 2, 6, and 12. Early feedback should focus on integration signals: where the leader is importing assumptions, bypassing a decision owner, moving too slowly, or misunderstanding a cultural norm. Waiting for a formal review allows those behaviors to harden and turns correctable friction into a story about the person’s character.

    Give the new leader a living "Dear New Leader" document as well. Include how decisions actually get made, which forums serve which purpose, what good escalation looks like, how disagreement is handled, and which organizational history still shapes current behavior. Tribal knowledge will exist whether you document it or not. Writing it down makes it possible to challenge, update, and teach.

    Turn values into behavioral and operating rules

    Values become useful at the moment of tension: speed versus quality, autonomy versus consistency, candor versus harmony, customer urgency versus platform health. If a value only describes universally pleasant behavior, it cannot help someone choose between legitimate competing interests.

    I treat a value as unfinished until it has five parts:

    • The trade-off: What hard choice is this value meant to resolve?
    • The expected behavior: What would another person observe when someone applies it well?
    • The counterbehavior: What tempting action violates it, even if that action produces a short-term result?
    • The operating hooks: Where does it appear in hiring, onboarding, decisions, performance, recognition, product reviews, or roadmaps?
    • The evidence: How will you notice whether the behavior is becoming more or less common?

    Consider a value such as "Every minute counts". Repeating the phrase does not tell a team whether it permits skipping discovery, taking on quality risk, or escalating a blocked decision. The behavioral definition must explain which delays are waste, which forms of rigor prevent expensive rework, and who can accept a risk. That is where a memorable phrase becomes an operating rule.

    Embed the rule across the employee journey. Use scenario prompts in interviews. Tell a concrete values story during onboarding, including the cost or trade-off involved. Add the relevant value to decision records and postmortems. Recognize choices that uphold the value when doing so is inconvenient. Address violations even when the person delivered a desirable result. People learn culture from what leadership rewards and tolerates, not from what leadership publishes.

    Decision logs are especially useful because they make the invisible part of culture inspectable. A lightweight entry can capture the decision owner, context, options, criteria, dissent, choice, and revisit condition. Over time, the log reveals whether the company actually delegates, whether decisions repeatedly reopen without new evidence, and whether stated principles influence trade-offs.

    Measure culture with both broad and local signals. An engagement score or eNPS can reveal that something changed, but it rarely tells you which operating mechanism is responsible. Pair pulse surveys with skip-level conversations, anonymous asynchronous channels for difficult feedback, onboarding observations, exit themes, and decision postmortems. Segment the signal by context when you can: a behavior may work inside one team while breaking at cross-functional boundaries.

    Close the feedback loop publicly. State what was heard, what leadership has decided, what will not change, who owns the response, and when people can expect an update. Silence teaches employees that providing feedback is ceremonial. A visible decision – including a reasoned decision not to act – makes participation consequential.

    A useful way to lower the emotional temperature is to let anyone file a culture bug report. Keep the format concrete: expected behavior, observed behavior, context, impact, and the mechanism that may have produced the gap. The point is not to pretend people are software. It is to move the conversation from "this place is political" toward a condition that can be examined, reproduced, and assigned.

    Watch for drift when early employees and newcomers begin using different unwritten rules, when hierarchy overrides documented ownership, or when leaders become so cautious about micromanagement that teams receive no timely feedback. Hands-off leadership can feel like autonomy to the leader and abandonment to the team. Office hours, clear review points, and explicit quality standards create alignment without pulling every decision upward.

    When the company changes quickly, re-onboard existing employees to the current operating system. Explain which values have not changed, which behaviors must evolve, how decision rights have moved, and which old habits no longer fit. Otherwise, tenure becomes access to a private rulebook, and culture turns into a source of status instead of coordination.

    Make feedback, conflict, and growth one learning loop

    Leaders receive less candid information as their authority grows. People edit bad news, turn behavioral feedback into careful abstractions, or wait until a problem is too visible to ignore. A deliberate multi-source loop helps counter that effect.

    Ask peers, direct reports, and cross-functional partners for specific situations rather than personality judgments. Useful prompts include which behavior the leader should begin, stop, or preserve; when the leader was most and least effective; and which single change would most improve their impact. Ask for the setting and the respondent’s confidence in the observation. A behavior that appears across several close observers deserves more weight than an isolated comment from someone far from the work.

    When reviewing 360 feedback, separate four things: the observable event, the effect on the respondent, the respondent’s interpretation, and the requested change. Look for patterns across sources, but do not use frequency alone. One credible observation can matter when the potential impact is large. Conversely, repeated discomfort may reflect a necessary decision rather than a harmful behavior. The leader’s job is to understand the signal before accepting or rejecting the conclusion.

    Convert a theme into a small behavioral experiment. If people experience decisions as opaque, publish the criteria before the next consequential decision. If meetings suppress dissent, collect independent views before discussion. If urgency produces surprise, require earlier escalation when a commitment becomes uncertain. Name what another person should be able to observe and choose a point to review whether the change helped.

    A ten-minute end-of-day reflection can keep the loop active between formal reviews. Ask what mattered, what you learned, and what you will do differently the next day. The value is not introspection for its own sake. It is shortening the distance between recognizing a leadership pattern and testing a better behavior.

    Conflict needs its own lightweight protocol. Unstructured discussion often rewards speed, status, and verbal confidence. Use a sequence that gives the disagreement somewhere to go:

    1. State the shared outcome and the decision or working relationship that needs repair.
    2. Let each person describe observations, impact, and request without assigning a motive to the other person.
    3. Ask the listener to mirror what they heard before responding. Agreement is not required; accurate understanding is.
    4. Name any emotion or concern that is shaping the exchange before jumping to a solution. Unnamed fear about status, trust, or risk often reappears as an argument about process.
    5. Clarify the decision owner, the input still required, and what disagree-and-commit means in this case.
    6. Run a short retrospective after the decision. Repair the interface, not only the immediate issue.

    Shared norms such as assume positive intent and no surprises are helpful only when paired with accountability. Positive intent should not erase harmful impact. Disagree-and-commit should not become a way to avoid hearing dissent. No surprises should define when escalation is expected, not punish people for delivering unwelcome information.

    The same loop should feed career development. Retention depends less on adding perks than on preserving momentum, meaning, and mastery. Write a growth contract with each person that answers three questions: Which capability are they building during the current planning period? What scope becomes available if they demonstrate it? What support, practice, or feedback will the company provide? Add the evidence both sides will use, so advancement does not depend on a retrospective story.

    Do not make management the automatic reward for strong individual contribution. Before an IC becomes a manager, let them expand the size of the outcome they own and practice leading a cross-functional program without formal authority. Then determine whether the organization needs a manager and whether the person wants to create impact through coaching, coordination, and talent decisions. A strong IC path should offer meaningful scope, status, and leverage without requiring direct reports.

    Careers are not one-way doors. Someone can move from IC work into management and later return to deeper individual contribution as their strengths, energy, or organizational context changes. Treat the move as a change in the mechanism of impact, not a verdict on ambition.

    When a person is asked to hire or report to a more experienced leader, make the learning exchange explicit. Define what the new leader will teach, what scope the existing person retains, and which evidence would justify broader ownership later. Trading a title for a teacher can accelerate a career, but only when the promise is backed by real access, coaching, and opportunity.

    At each planning cycle, inspect the seams of the system. Does the role charter match the decisions the person actually owns? Does the interview scorecard match what performance reviews reward? Does onboarding teach the culture leaders enforce? Do feedback and conflict patterns identify a capability gap, an ownership gap, or an incentive problem? Does each high-performing person know what they can learn and own next?

    If you do one thing this week, choose the leadership role creating the most friction and place its charter, hiring scorecard, onboarding plan, values, and performance expectations side by side. Find the first contradiction and repair that seam. A coherent leadership, talent, and culture system will do more for trust and execution than another isolated initiative.

    References

  • How Product Leaders Build Agency Without Lowering Ambition

    How Product Leaders Build Agency Without Lowering Ambition

    Your PM presents a bold strategy, but every difficult decision still comes back to you. Or the team ships reliably, yet the work rarely changes an important customer or business outcome.

    These are different leadership problems. The first is an agency gap. The second is an ambition gap. Treating both as a generic performance issue leads to vague coaching, more oversight, and little improvement. You need to identify which capability is missing, change the conditions around it, and ask for observable evidence of progress.

    Separate ambition from agency before you coach

    Ambition is the drive to pursue greater impact, wider scope, or meaningful growth. Agency is the willingness and ability to own a problem, make decisions, and create momentum without repeatedly waiting for permission. Strong product managers need both capabilities, but one does not guarantee the other.

    A confident presenter may have ambition without agency. A dependable delivery manager may have agency without ambition. If you praise the first person for vision and the second for output, you can reinforce the exact limitation you need each person to overcome.

    PatternWhat you are likely to noticeYour leadership response
    High ambition, high agencyThe PM pursues consequential outcomes, reduces uncertainty, makes sound decisions, and creates momentum.Protect autonomy, widen the problem space, and keep the outcome bar high.
    High ambition, low agencyThe PM describes a compelling future but stalls when evidence is incomplete, trade-offs appear, or stakeholders disagree.Clarify decision rights, narrow the next reversible decision, and require a recommendation rather than another escalation.
    High agency, low ambitionThe PM delivers steadily but optimizes small requests or predetermined scope without questioning the size of the opportunity.Reconnect the work to customer and business impact, then ask for a more consequential hypothesis.
    Low ambition, low agencyThe PM waits for tasks, avoids ownership, and cannot explain the outcome the work should produce.Check the environment and expectations first. If clarity, access, and coaching do not change the pattern, examine role fit.

    Do not assign someone to a quadrant from reputation or personality. Inspect recent work. Ask four questions:

    <!– wp:list {