We are surrounded by a tempting promise: give people better AI tools and the business will become better, too.

Sometimes the tools do help. A report takes less time to draft. A developer gets to a first implementation faster. A service representative finds an answer without searching through ten pages. These improvements can be real and useful.

But imagine that every one of those faster tasks still feeds the same overloaded approval queue, the same conflicting databases, and the same decisions that nobody clearly owns. We have accelerated the activities without necessarily improving the system.

My view is that the most important change in the AI era is not a new tool. It is the willingness to question how work is designed in the first place.

That is what I mean by a mindset shift. Not enthusiasm. Not an instruction to “embrace AI.” A practical change in the questions leaders and teams are prepared to ask.

We can adopt a tool without changing the business

The distinction is visible in the available research. In McKinsey’s 2025 State of AI survey, 88% of respondents said their organizations used AI in at least one business function, but only about one-third said their companies were scaling AI programs across the organization. These are different self-reported measures, not a controlled study of what caused business results. Still, they illustrate the distance between using a capability somewhere and integrating it across an enterprise. [1]

The first question a leader should ask is not “Which AI tools have we introduced?” It is “What is meaningfully different because we introduced them?”

If a team creates documents 40% faster but customers wait just as long, the improvement may be trapped inside one step. The 40% is a hypothetical example, not a claimed result from my work or a figure from that survey. The business may need something other than a faster document.

That leads to three mindset changes I think are worth making.

1. From choosing tools to defining outcomes

A tool-first conversation begins with what a model can do. An outcome-first conversation begins with an unresolved business problem.

Take a customer-support process. We could ask AI to summarize incoming tickets. That might save effort. But what is the actual problem: slow first response, incorrect routing, incomplete knowledge, repeat contacts, or customers not getting a resolution?

Those are not interchangeable. An excellent summarizer may do little for a team whose main constraint is waiting for another department’s approval.

Start with a precise outcome: reduce the time from first contact to a correct, complete resolution without increasing reopens or customer harm. Then examine where AI could help—and where data quality, permissions, handoffs, or policy are the real constraint.

The point is not to reject AI tools. It is to give them a business job.

2. From accelerating tasks to redesigning the workflow

When AI makes an individual task easier, the instinct is to automate more tasks. But a business outcome usually crosses several steps and teams.

Consider an illustrative support workflow:

• Before: a customer submits a request → someone reads it → someone routes it → an agent searches for context → another person approves an exception → the agent replies.

• Possible redesign: classify the request → retrieve trusted information → suggest a response or next action → apply clear confidence and risk rules → route sensitive cases to a responsible human → record whether the customer was actually helped.

This is a design example, not a claim that I deployed it or that it works without testing. The redesigned flow may be better, or it may expose new failure modes. It must be validated against real customers and real constraints.

The hard part is rarely drawing the boxes. It is agreeing who owns the outcome, which information can be trusted, where the human check belongs, and what happens when the model is wrong.

McKinsey’s survey found that organizations its researchers classified as higher AI performers were much more likely than others to report substantial workflow redesign. That is an association, not evidence that redesign alone caused the difference. But it is consistent with a useful operating hypothesis: changing a process can matter more than adding another assistant to an unchanged process. [1]

3. From confident plans to disciplined learning

AI changes quickly. That creates pressure to have an AI strategy that sounds decisive and complete.

I prefer a strategy that is clear about the business objective and honest about what has not been proven.

For a reversible, low-risk experiment, I would rather ask “What is the smallest test that could change our decision?” than demand a perfect architecture before anyone learns from the work. For a high-stakes application, I would demand more rigorous controls before exposing people to harm. Those two positions are compatible.

A useful mindset allows both exploration and restraint. Teams should be able to challenge existing processes, test new possibilities, and also stop an initiative when costs, reliability, security, compliance or user outcomes do not justify it.

The U.S. National Institute of Standards and Technology offers a helpful reminder: its AI Risk Management Framework organizes risk work around govern, map, measure and manage. It treats risk management as an ongoing practice rather than a one-time approval. [2]

Mindset matters. It is not enough.

This is where conversations about “AI culture” often become too vague.

A willingness to experiment is useful. But enthusiasm cannot repair unusable data. It cannot settle unclear decision rights, create a missing escalation route, or resolve contradictory incentives.

For an AI-driven improvement to survive contact with real work, several elements need to connect:

Mindset: Are people willing to challenge the current method and consider a different one?

Workflow: Can we redesign the end-to-end journey instead of optimizing an isolated task?

Capabilities: Do we have reliable information, integration points, skills, and a maintainable technical foundation?

Guardrails: Who owns the decision, reviews risk, handles exceptions, and can stop the system?

Evidence: Did the result improve for customers, employees and the business, net of cost and quality trade-offs?

If one of these is missing, more powerful models may not fix it. For leaders, that is the uncomfortable—and productive—part of AI transformation. It is an organizational design problem as much as a technology decision.

A practical starting point for a leadership team

I would begin with one recurring workflow, not an enterprise-wide declaration that everything must change.

1. Name the outcome. What matters at the end: resolution time, error rate, customer effort, throughput, quality or cost?

2. Map the real work. Include the waiting, handoffs, rework, decisions and exceptions—not only the visible task.

3. Locate the constraint. Is AI the likely solution, or does the problem sit in rules, incentives, unclear ownership, or missing data?

4. Design a bounded test. Decide what will change, who is accountable, how errors are reviewed, and when the experiment stops.

5. Compare the result. Look at the end-to-end outcome and unintended costs. Keep, adapt, or discontinue the experiment based on what you learn.

This is not a universal five-step implementation method. It is a useful way to expose the decisions that a tool demonstration can hide.

The leadership question behind the technology

After years working in software delivery and product development, I have become increasingly interested in the distance between producing output and creating value.

AI makes that distinction harder to ignore. We can now produce more first drafts, code, analyses and proposals than before. Some of that output will be valuable. Some will create more decisions, reviews or rework downstream.

I do not think the answer is to slow down innovation. I think it is to be more ambitious about what we are trying to improve—and more precise about how we will know whether we did.

The next competitive advantage may not be who has the most AI tools. It may be who learns fastest how to redesign work around real customer and business outcomes.

The question I would leave with any leadership team is simple: If we removed the AI tool from our presentation, could we still explain what needs to change in the business—and why?

I write about AI, products, strategy and what it takes to turn ideas into real value. If this is the kind of question you work through, you can follow the publication for future essays and practical field notes.

Sources and reading

1. McKinsey, The state of AI in 2025: Agents, innovation, and transformation (5 November 2025). Respondent survey conducted June–July 2025; adoption, scaling and performer comparisons are self-reported, associative measures.

2. NIST, AI Risk Management Framework Core. The voluntary 2023 framework is undergoing revision as of October 2026.

3. Stanford HAI, 2026 AI Index: Economy. Provides additional adoption context and cautions about self-reported organizational survey results.

Editorial note: The support-workflow scenarios and example percentages explicitly identified above are illustrations. They are not claims of outcomes achieved at Onsday or in an employer’s systems.

Call it the acceleration trap. Legacy operating models were built around simple realities: information was slow to gather, testing ideas was expensive, and changing direction took weeks. AI flips those rules on their head. When a team can test a hypothesis in an afternoon or spin up a functional prototype before lunch, holding onto rigid sprint cycles and monthly steering committees isn’t governance anymore—it’s organizational self-sabotage. You aren’t transforming the business; you’re just putting a fresh coat of paint on an old carriage.

Real adoption isn’t about doing the same tasks faster. It’s about tearing down and rebuilding how work actually flows.

When you look past the hype, three structural shifts happen almost immediately:

First, your decision-making breaks down. When evidence takes hours to gather instead of weeks, traditional approval gates stop protecting quality and start acting as massive traffic jams. Fast information slammed against slow bureaucracy always creates chaos.

Second, job boundaries blur. Generalists armed with the right tools can suddenly handle work that used to require dedicated specialists. The org chart starts to look absurd, and the core operational question shifts from “Who owns this department?” to “Where does a human actually need to step in?”

Third, evaluation becomes your biggest bottleneck. Generating raw material—code, copy, wireframes—is practically free now. But knowing if that material is actually any good? That’s hard. The most valuable people in an AI-heavy company aren’t the ones pumping out content; they’re the ones with the taste, judgment, and domain knowledge required to critique, verify, and filter it.

This forces a deep realignment. Winning companies aren’t just buying better software. They’re trading rigid functional handoffs for fast, outcome-focused loops. They’re ditching episodic gate reviews for continuous assessment. They’re prioritizing critical evaluation over raw execution speed, and measuring success by actual business impact rather than the sheer volume of work produced.

None of this feels comfortable. It threatens existing corporate turf, messes with org charts, and forces leaders to admit that the playbook they spent their careers mastering has become a liability.

Speed by itself is no longer a moat—anyone can buy the same software subscriptions you have. The real competitive advantage lies in structural redesign. Stop asking how AI can make your current process 10% faster. Start asking what your team would look like if 80% of routine execution vanished overnight. If you aren’t willing to redesign the system around that reality, you’re just paying for expensive software to keep doing things the old way.

You have a choice to make in that moment. You can treat the wound — find help, clean the bite, get the antivenom. Or you can turn to the snake and begin building your case. You document the bite. You tell the other animals what the snake did. You find ways to work around the snake’s territory without ever crossing it again. You become very, very skilled at avoiding the snake.

Meanwhile, the venom spreads.

This is not a story about snakes. This is a story about what fear does to otherwise intelligent, well-meaning people inside organizations — and how that behavior, modeled from the top, becomes the culture everyone inherits whether they wanted it or not.

The Anatomy of Avoidance

When something goes wrong between people in a low-trust organization — a missed expectation, a dropped handoff, a decision that landed badly — there is a fork in the road.

One path leads toward the problem. It requires a conversation, which requires vulnerability, which requires the belief that the other person is capable of hearing feedback and that the relationship can survive honesty. It is uncomfortable and direct and usually short.

The other path leads around the problem. It involves processing the situation with third parties, building alignment with allies, documenting what happened in case it becomes relevant later, and finding subtle ways to reduce your dependence on the person who disappointed you — all without ever speaking to them directly. It feels strategic. It feels safe. It feels, if you squint at it right, like professionalism.

It is none of those things. It is fear with good posture.

And in organizations where leadership consistently chooses the second path, everyone eventually learns to walk it too. Not because they are cowardly. Because they are watching. Because culture is not what you put in a handbook — it is what you see rewarded and what you see survive.

How the Venom Spreads

Here is the pattern, and it is worth naming precisely because it is so easy to be inside it without seeing it.

Something goes wrong. It might be a product decision, a missed deadline, a communication breakdown. The facts of what happened are, in isolation, recoverable. But instead of addressing what happened, the energy goes into assigning what happened. Who dropped it. Whose fault. Who should have known better.

The search for the villain begins.

And here is the insidious part: finding the villain feels productive. It has the shape of problem-solving — investigation, evidence, conclusion. It produces something: a narrative, a consensus, a shared understanding of who is responsible. Teams bond over it. Leaders feel decisive.

But nothing has actually been solved. The problem that created the situation in the first place — the unclear ownership, the misaligned expectation, the process gap, the unspoken tension — is still there, untouched, waiting to produce the next incident.

Villain-seeking is not problem-solving. It is problem-postponing dressed in problem-solving’s clothes.

The Snake Doesn’t Know

Here is the part of the story that is hardest to sit with.

When you go around someone, when you quietly reroute work to avoid them, when you have the conversation about them rather than with them — they usually know. Not the details, perhaps. But they feel the temperature drop. They notice the slight rerouting of information. They register the absence of feedback that should have come.

And they are confused. Because nobody told them anything was wrong.

So they do what people do when they sense something is off but have no information to work with: they fill in the gap themselves. They develop their own narrative. They become, in response to your silence, defensive — not because they were defensive to begin with, but because defensiveness is the rational response to threat you can’t see clearly.

Now you have a defensive snake. And you point to the defensiveness as evidence that the direct conversation was never possible. The avoidance has created the very outcome it was trying to avoid.

This is how distrust compounds. Not through dramatic betrayals, but through small silences that harden over time into walls neither person remembers building.

Management as Mirror

In the organizations where this pattern is most entrenched, it almost always flows downward.

Leaders who avoid difficult conversations model avoidance as sophistication. Leaders who seek villains instead of solving problems teach their teams that the right response to failure is prosecution, not repair. Leaders who work around people rather than with them demonstrate, clearly and repeatedly, that this is how adults handle conflict.

Employees are not naive. They watch what actually happens, not what the values poster says. And what they see, they learn.

The junior developer who watches their manager respond to a production incident by immediately identifying who is responsible — rather than who can fix it — learns something that no onboarding document can undo. The team that watches leadership handle an interdepartmental conflict through political maneuvering rather than direct conversation learns that honesty is for people who don’t understand how things work.

And so the culture reproduces itself. Every new person who joins finds the pattern already in place, already rewarded, already the path of least resistance. Most of them adapt. Some of them leave. A very few try to change it and find out how deep the roots go.

The tragedy is that nobody in this organization thinks of themselves as the problem. The leader avoids the conversation because the stakes are too high to risk it. The manager seeks the villain because accountability matters. The employee works around the colleague because the direct approach has never worked here. Everyone has a reason. Everyone is doing what makes sense given what they’ve been shown.

And the venom keeps spreading.

What Feedback Silence Actually Costs

There is a version of this that gets talked about in psychological safety research, but it deserves to be said plainly.

When people cannot give honest feedback — when the culture makes directness dangerous and silence strategic — the organization loses access to its own reality. Problems are known, but not spoken. Risks are felt, but not raised. The gap between what people say in meetings and what they say in private grows wider, and all that unspoken information has nowhere to go except into the rumor economy, the resignation letter, and the postmortem where everyone admits they saw it coming.

The cost is not abstract. It is the product decision nobody challenged because challenging things here gets you labeled a problem. It is the toxic dynamic that persisted for eighteen months because everyone could see it except the person with the authority to address it, and nobody told them directly. It is the resignation of the person who had tried, twice, to raise something important and had been handled rather than heard.

Silence is not neutral. Silence is a tax on every decision the organization makes — because every decision is made with incomplete information, and the missing information is sitting, unspoken, in the minds of people who have learned that speaking it is not safe.

The Turn: What Good Actually Looks Like

Here is the hopeful part, and it is genuinely hopeful because none of this is complicated. It is just uncomfortable, and uncomfortable is not the same as hard.

The conversation is almost always shorter than the avoidance.

The difficult conversation that you have been constructing in your head for three weeks — the one with all the possible objections and the imagined defensiveness and the narrative you’ve been building to support your position — that conversation, when actually held, almost never goes the way you feared. Not because the other person is easy. But because they are also carrying the unspoken thing, and they also feel the temperature, and when someone creates the space to address it directly, most people meet that with relief rather than hostility.

Not always. But far more often than fear predicts.

Feedback is a gift that compounds.

The team that can tell each other the truth — about the work, about the dynamics, about the decisions — gets smarter faster than the team that can’t. Every piece of honest feedback is a correction that prevents a larger error downstream. The manager who can hear “that decision landed badly and here’s why” can adjust. The manager who never hears it keeps making the same decision until the evidence is too large to ignore, by which point it is much more expensive to fix.

Feedback is not comfortable. But comfort is not the goal. Growth is the goal, and growth requires information, and information requires safety, and safety requires someone to go first.

The villain search ends when the question changes.

The single most powerful shift available to a leader in a low-trust culture is changing the first question after something goes wrong. Not “who is responsible?” but “what happened, and what do we need to change so it doesn’t happen again?”

This is not about avoiding accountability. People should own their decisions and their impact. But accountability in service of learning is entirely different from accountability in service of blame. One produces a better system. The other produces a better alibi.

The team that asks “what do we change?” after a failure becomes, over time, a team that fails less. The team that asks “who dropped it?” becomes, over time, a team that hides failures better.

How to Build Something Different

If you lead people, you are the culture. Not the culture you intend — the culture you model.

Go first. The direct conversation, the honest feedback, the admission that something didn’t land the way you meant it — these have to come from the top before they become possible at any other level. Every time a leader chooses the hard conversation over the workaround, they move the culture slightly. It is slow and it is unspectacular and it is the only thing that works.

Name the pattern when you see it. When a team meeting turns into a villain search, name what’s happening. Not as an accusation — as a redirect. “We’ve spent twenty minutes on who dropped this. Let’s spend twenty minutes on what we change.” Said once, it’s a correction. Said consistently, it becomes the new norm.

Make feedback safe by receiving it well. People will give you the feedback that your response history has told them is safe to give. If honest feedback has been met with defensiveness, rationalization, or subtle retaliation — people will stop giving it. The way to rebuild a feedback culture is to receive the next uncomfortable thing you hear with genuine curiosity rather than self-protection. Not once. Consistently, until people believe it.

Treat the wound before you investigate the bite. When something goes wrong, the first question is always: what do we need to do right now to make this better? The retrospective — the honest, blameless examination of what happened — comes after the immediate need is addressed. This sequence matters. It signals that outcomes matter more than narratives.

The Forest After the Snake

Back to the forest.

You were bitten. It hurt. And the snake — whatever the snake represents in your organization — may or may not have intended harm. That part doesn’t actually matter for what you do next.

What matters is the venom. What matters is treating it quickly, directly, with the people who can help. What matters is that you don’t spend your recovery time building a case, because the case won’t heal you and the wound won’t wait.

The organizations that build something worth building are not the ones without snakes. Every organization has conflict, failure, misalignment, people who disappoint each other. The difference is what they do in the moment after the bite.

Do they turn to the wound, or do they turn to each other?

The answer to that question, played out in a thousand small moments across a thousand interactions, is the culture. Not the values. Not the handbook. Not the all-hands speech about psychological safety.

The answer to that question, in the moment, every time.

The Series in Two Sentences

Build a culture where the tracker serves the team, not the team’s anxiety. Build a culture where the conversation happens before the workaround, the feedback before the silence, the question “what do we fix?” before the question “who do we blame?”

That culture doesn’t happen by accident. It is built, one behavior at a time, by leaders who understand that the most expensive thing in any organization is not the tools, not the process, not even the people who leave.

It is the truth that nobody said.

Part 1: If It’s Not in the Tracker, It Didn’t Happen — how distrust turns process into a tax on every team.

Then you open the tracking tool.

And you spend the next two hours creating an epic, breaking it into stories, writing acceptance criteria for work that is already done, already deployed, already delivering value. You’re not building anything. You’re not fixing anything. You’re filing paperwork for a reality that already exists — because the system needs the record more than the users needed the feature.

This is what distrust looks like in practice. Not surveillance cameras. Not micromanagement. Just a quiet, institutionalized insistence that work doesn’t count unless it’s been processed through the right tool, in the right order, with the right labels.

And it is costing you more than you think.

The Two Realities Problem

Every low-trust team lives in two worlds simultaneously.

There’s the world where work actually happens — in Slack threads, whiteboard sessions, judgment calls at 4pm, a developer noticing something broken and just fixing it because it was obviously the right thing to do. This is the world of value. Things get built here. Problems get solved. Users get helped.

Then there’s the world where work is supposed to happen — epics, stories, sprints, velocity charts, acceptance criteria, sign-offs. This world exists not for users, but for the organization. It’s the institutional record. The alibi.

Trusted teams live in one reality. Distrusted teams spend enormous energy translating between the two.

Every feature that was built in world one needs to be retrofitted into world two. Every decision made through judgment needs to be reverse-engineered into a process artifact. Every act of initiative becomes a compliance problem.

The tracker stopped tracking. It became a theater stage.

Agile Said It First — We Just Stopped Listening

There’s deep irony here that shouldn’t go unacknowledged.

Agile’s fourth value — one of the original four, written in 2001 by people who had watched process eat teams alive — is individuals and interactions over processes and tools.

Not instead of. Over. As in: when they conflict, we know which one wins.

The organization that requires you to retrofit the tracking tool after shipping believes it is doing Agile. It has the sprints. It has the retrospectives. It has the velocity dashboard. But it has quietly inverted the core value: the tool has become the proof of the individual’s work. The process has become more real than the delivery.

This isn’t a tooling problem. It’s a values problem wearing a tooling costume.

What It Does to Your Body

Here’s what nobody puts in the project post-mortem.

Chronic justification is a chronic stressor. When you spend your working hours not just doing your job but continuously proving you are doing your job — updating trackers, attending status meetings, writing summaries of work already done — your nervous system reads that as a low-grade, permanent threat.

You are never just building. You are building and defending the building. You are performing competence while also exercising it. That is cognitively exhausting in a way that is qualitatively different from hard work.

Hard work is tiring. Hard work with constant surveillance is depleting.

The research on psychological safety — Google’s Project Aristotle being the most cited — shows that the highest performing teams are not the ones with the most process. They are the ones where people feel safe enough to act without pre-authorization, to raise problems without political risk, to ship without having laid a paper trail first.

Distrust doesn’t just slow teams. Over time, it breaks the people on them. The best ones leave first — because they have options, and they know what good feels like. What stays behind is a team that has learned to optimize for tracker hygiene over shipping value. A team that has been trained, slowly, to ask permission instead of exercising judgment.

The Legitimate Line

Let’s be honest about something, because a good argument can hold its own counter-argument.

Process is not the enemy. Tracking is not the enemy. The team that ships everything based on vibes and never writes anything down is not a high-trust team — it’s a liability waiting to materialize in six months when the one person who understood the system quits.

The question is not whether to track. The question is who the tracking serves.

Tracking that serves the team is a tool. It helps you see what’s in flight, catch things that are stuck, remember what you decided and why. It lives in the world where work happens. It is updated because it’s useful, not because it’s required.

Tracking that serves anxiety is a tax. It exists to give management legibility over a process they don’t trust, to create an audit trail nobody asked for, to make the intangible tangible for people who are uncomfortable with intangibility. It lives in the second world — the record world — and it pulls energy away from the first.

The test is simple: if the tool disappeared tomorrow, would the team work better or worse?

If the answer is worse — the tool is serving the team. If the answer is better, or if people quietly admit “we’d probably move faster” — you don’t have a tracking system. You have a distrust monument.

What Trust Actually Looks Like

Trust is not naive. Trust is not absence of visibility. Trust is not letting teams do whatever they want with no accountability.

Trust is a bet that the people you hired to exercise judgment are capable of exercising judgment. And it compounds.

When a developer doesn’t have to pre-justify a decision, they make the decision faster. When they don’t have to retroactively document what they shipped, they ship the next thing instead. When they don’t have to attend a meeting proving the work is happening, they use that hour doing the work. None of these are dramatic. Each one is small. But they compound across every person on the team, every day, every sprint.

The same team, trusted, ships disproportionately more over time. Not because they’re working harder. Because they’re not spending 20% of their energy maintaining a second reality.

And there is something more important than velocity: trusted people stay. They bring their full capability to work instead of a compliance-minimized version of it. They raise problems early because they’re not afraid of being blamed for them. They do the thing that wasn’t in the user story because the user clearly needs it and they trust their own judgment enough to act.

That is not a soft benefit. That is the compounding return on a cultural investment.

Where to Start

Culture is the villain here, which means nobody owns it and nobody can fix it on Monday morning. But culture is made of behaviors, and behaviors can be changed one at a time.

If you lead a team: The next time someone ships something that wasn’t in the plan but was obviously right — celebrate it before you ask them to document it. The sequence matters enormously. Document second. Acknowledge first. The message you send in that moment outlasts any process you could write.

If you’re on a team: Distinguish between updating a tracker because it helps you and your teammates, and updating it because someone will ask if you didn’t. Do the first without being asked. Push back — gently, consistently — on the second. Name what you’re doing: “I’m going to spend an hour on this retroactive story. I want us to notice that.”

For the organization: Ask honestly: what decisions require approval that could be made by the person closest to the work? What documentation exists because it’s useful, and what exists because it’s comfortable? Where are you asking for proof when you could be asking for outcomes?

The tracker is not the problem. The tracker is a symptom. The problem is an organization that decided, somewhere along the way, that it couldn’t trust the people it hired — and then built systems to manage that distrust at scale.

And here is the part that should worry you most: that culture doesn’t stay at the top. It travels. It seeps into every team meeting, every Slack message, every decision about whether to just fix something or wait for permission first. Distrust, left unaddressed, becomes the water everyone swims in — until nobody remembers what dry land felt like.

That is what Part 2 is about.

The Real Cost

The retroactive epic is two hours. The status meeting is one hour. The sign-off chain is half a day. The documentation of the decision that was already made is another hour.

Multiply by a team of eight. Multiply by fifty-two weeks. Multiply by the cognitive overhead of context-switching between building and proving. Multiply by the two senior engineers who left last year because they were tired of justifying themselves to a system that didn’t trust them.

Distrust is not free. It has a line item. You just haven’t been putting it on the spreadsheet.

Trust, on the other hand, costs almost nothing to extend — and it returns almost everything.

The work is done. Ship the next thing.

Continue to Part 2: The Snake and the Silence — what happens when distrust stops being about process and starts being about people.

It is the ability to shield a team from pressure that looks legitimate but is not — and to do that with enough domain understanding to tell the difference.

The pressure problem in product delivery

In most organisations, pressure flows downward. An executive has a commitment. That commitment becomes a deadline. That deadline lands on a product team as a fixed date with a fixed scope, often set before anyone fully understood the complexity of what was being built.

A product owner sitting in the middle of that flow has two choices. They can pass the pressure downstream — which looks like urgency, sounds like alignment, and feels like leadership — but is actually just transmission. Or they can absorb the pressure, interrogate it, and give the team back something more useful than a deadline: clarity.

The difference between those two choices is not process or methodology. It is judgement. And judgement in a specific domain, about a specific problem, is something that no AI tool available today can reliably replace.

What shielding actually looks like in practice

Here is a pattern I have seen play out more times than I can count. A stakeholder sets a deadline. The deadline feels urgent and real. A product team starts building toward it under pressure. Halfway through, someone discovers that the deadline was not actually driven by a hard external constraint — it was a comfort buffer, or a misremembered dependency, or a date that made sense six months ago but no longer does.

By that point, the team has made architectural decisions, cut corners, and accumulated technical debt in service of a deadline that did not need to exist in the form it was stated. The cost of that false urgency is invisible in the moment and very visible six months later — in the exhausted team, the system that needs rebuilding, the features that shipped but never quite worked.

The product owner who catches this — who goes back to the stakeholder and asks the right question at the right moment — saves the team weeks of misdirected work. But to ask the right question, you need to understand the domain well enough to know which constraints are real and which are assumed. That distinction lives in domain knowledge, not in any tool.

Where AI genuinely helps — and where it stops

I want to be fair here, because AI has genuinely changed what is possible in product delivery. The ability to synthesise large amounts of information quickly, to draft and iterate on requirements, to spot patterns in data that would take a human analyst days to surface — these are real and meaningful capabilities that I use regularly in my own work. AI absolutely belongs in product teams.

But AI operates on information it is given. It cannot walk into an organisation and sense that the urgency behind a request is political rather than operational. It cannot read the body language of a stakeholder who is under board pressure and translating that pressure into an unrealistic product demand. It cannot know that a particular deadline was set by someone who has since left the company and that nobody has revisited whether it still makes sense.

Organisational pressure is almost never explicit. AI is very good at processing what is explicit. That is the gap.

These things require presence, relationship, domain understanding, and the kind of accumulated organisational knowledge that comes from being in the room over time. They require a human who is specifically positioned and trusted to hold that line.

The skill that does not show up in job descriptions

When companies hire product owners and product managers, they typically list the usual things — backlog management, stakeholder communication, agile methodology, data-driven decision making. These are real and important. But the skill that actually determines whether a product team can sustain healthy delivery over time rarely appears in job descriptions, because it is hard to name and harder to measure.

It is also, in my experience, the skill that separates product leaders who build high-performing teams from those who simply manage high-stress ones. The difference between those two outcomes is significant — not just for the team’s wellbeing, but for the quality and speed of what actually gets delivered.

AI will keep getting better. The tools available to product teams in two years will be meaningfully more capable than what exists today. But the judgement layer — the human in the middle who understands the domain, reads the organisational dynamics, and protects the conditions for good work — is not going away. If anything, as AI handles more of the execution, that judgement layer becomes more valuable, not less.

The teams that will thrive are not the ones that replace that judgement with automation. They are the ones that free it up to do the things only it can do.

A question for you

Have you experienced the cost of false urgency in your own team? I would genuinely like to hear how it played out — and whether anyone had the standing to push back on it.

If this resonated, consider sharing it with someone navigating this right now. They probably need the permission to name it. ↗

Written by Alexander Ivan

#productmanagement #productleadership #aistrategy #engineeringmanagement #teamculture

LLM pricing is per token. Input tokens (your prompt + context) and output tokens (the response) each have a rate. A 100k-token context at $1.75/1M input costs $0.175 per call—before the model generates a single word. Scale that to hundreds of queries a day and the bill adds up fast.

Most teams don’t think about it until the invoice lands. By then, the pattern is baked in: “We just stuff everything into the prompt.”

The basics: token economics

• Input vs output — Output is usually 5–10× more expensive than input. Short, focused prompts with concise answers cost less.

• Context size — Bigger context = more input tokens. If you’re sending 80k tokens when 4k would do, you’re paying 20× for no gain.

• Model choice — gpt-4o-mini is a fraction of gpt-4o. For retrieval, summarization, or simple Q&A, the cheaper model often suffices.

The lever that matters most: what you put in the prompt.

When RAG pays off

RAG (retrieval-augmented generation) shrinks context by fetching only relevant chunks. Instead of 80k tokens of product docs, you send 4k. Same quality of answer, 20× less input.

Rule of thumb: if your context is large and you query often, RAG pays for itself quickly. The break-even is low—a few dozen queries at scale.

We run compare_cost before committing to a workflow: “For this question, full context = X tokens, RAG = Y. At current pricing, that’s $Z vs $W per query.” No API calls, no guesswork.

A simple decision framework

1. Small, static context — A few KB of instructions. Full context is fine. Don’t over-engineer.

2. Large, growing context — Product docs, knowledge bases. RAG.

3. High query volume — Even small savings compound. Measure. Optimize.

4. Sensitive to latency — Fewer tokens = faster. RAG can help there too.

Takeaway

AI costs are predictable if you treat them as token economics. Lead with context size. Use RAG when context is large. Choose the cheapest model that meets quality. And measure before you scale.

“I use ChatGPT” or “I use Claude” is fine for one-off tasks. But when you’re iterating on product specs, drafting landing copy, or refining roadmap items, you need consistency. The same context, the same constraints, the same workflow—every time. Ad-hoc prompts in a chat window don’t get you there.

What does “AI-ready” look like when you’re serious about repeatability?

The approach: versioned, structured guidance

My setup lives in git. Not prompts in a doc—actual rules, skills, and commands that the AI reads automatically.

• Domain rules — .cursor/rules/ files that tell the AI: “This folder is product docs. Use Flixup voice. Don’t mix in other domains.” When I’m in business-flixup/, the AI knows the context.

• Skills — Step-by-step workflows. E.g. “Create a landing page from business markdown”: config file, persona, messaging, then 11ty + Tailwind. The AI follows the skill, not a vague “make a landing page.”

• Commands — Slash commands. /compare-cost "What is our positioning?" runs our RAG cost estimator and shows full vs RAG tokens and cost. No typing, no context switch.

Rules scope the AI. Skills standardize the workflow. Commands wire tools into the editor.

Why it beats “prompts in a chat”

1. Versioned — Change a rule, commit it. Everyone gets the update. No “which version of the prompt did you use?”

2. Discoverable — New team members (or future you) see the structure. Rules and skills document how we work.

3. Composable — A landing-page skill can call a product RAG query. Commands can chain. Ad-hoc prompts don’t compose.

4. Testable — Run the same command with the same input. Compare outputs. Iterate.

One concrete workflow

Product docs → roadmap items. I have the AI read our product markdown, extract features and initiatives, and draft Linear issues. The AI sees our backlog via Linear MCP. It can refine issue titles and descriptions so intent stays clear. The loop: docs define intent, AI drafts, human prioritizes. Rules keep the AI in our product domain. Skills define the extraction format. No manual copy-paste.

Takeaway

“AI-ready” isn’t about using the latest model. It’s about rules, skills, and commands in version control. Structure beats prompts. When you care about consistency and scale, put it in git.

Product strategy lives in docs. Roadmaps and backlogs live in Linear. In theory they align. In practice they drift. Someone updates the spec; no one updates Linear. Or the other way around. The source of truth becomes unclear. Manual sync is tedious and error-prone. Copy-paste from markdown to Linear invites mistakes, and when you scale across multiple initiatives and projects, the drift compounds.

We needed a single source of truth—markdown—that could flow into Linear in a structured way, with AI assistance for the mechanical sync work.

The approach: six-file hierarchy + MCP

We use a six-file markdown hierarchy that runs from idea to issues. Markdown is the source of truth; Linear is the execution layer. We sync via the Linear MCP (Model Context Protocol) as the primary path. For steps MCP can’t do—creating initiatives, setting project dependencies—we use the Linear UI or GraphQL API as fallback. The hierarchy keeps strategy and delivery aligned; MCP keeps the sync fast and consistent.

The hierarchy

Execute in order. Each file feeds the next:

Idea → Initiatives → OKRs → Metrics Mapping → Projects → Issues

Fill 01 before 02, 02 before 03, and so on. IDs (INIT-xxx, PROJ-xxx, ISSUE-xxx) are the contract between markdown and Linear.

Step 1: Idea (01-idea)

The idea file captures the problem, hypothesis, and scope. It’s the source of truth for the “why” behind delivery. Fill this first.

Problem statement — Who experiences the problem? What pain or opportunity is unaddressed?

Hypothesis — Use this formula: We believe that [CHANGE] for [AUDIENCE] will result in [OUTCOME]. We’ll know when [VALIDATION_SIGNAL].

Example from a B2B feedback tool idea:

We believe that an AI-powered async feedback tool that runs sessions and summarizes insights for B2B product and ops teams will result in reduced meeting load, higher response rates, and faster insight delivery. We’ll know when 10 design partners complete 70%+ of sessions and report 50%+ reduction in feedback-related meetings.

Scope (in/out) — A simple table. What’s in scope this quarter? What’s explicitly out?

Assumptions and constraints — Timeline, budget, team size. These shape what you can ship.

Step 2: Initiatives (02-initiatives)

Initiatives are outcome-focused, not feature-focused. Each initiative is a strategic objective that groups projects. Aim for 3–7 per quarter; they span months.

Each initiative has: objective, success criteria (measurable), owner, target date, and linked projects. Use exact names in the “Linear Initiative Names” section—MCP links projects to initiatives by name.

Important: Linear MCP does not create initiatives. You must create them manually in Linear or via the GraphQL API first. MCP then links projects to existing initiatives.

Step 3: OKRs (03-objectives-key-results)

Objectives and Key Results map to initiatives. O1, O2 for objectives; KR1, KR2 for key results. Each KR should be measurable (e.g., “10 design partners onboarded”, “70%+ session completion rate”). Map each OKR to an initiative and to metrics in the next file.

Step 4: Metrics mapping (04-metrics-mapping)

Define your North Star metric, input metrics, and how initiatives/projects map to them. When OKRs or success criteria change, update this file. Include instrumentation notes: what events or properties need to be instrumented? This ensures success criteria are measurable and tied to real data.

Step 5: Projects (05-projects)

Projects are time-bound deliverables. Each has milestones (e.g., Design, Alpha, Beta, Launch), success criteria, and dependencies. Use blocks and blockedBy to express project dependencies. MCP can create projects and milestones; project dependencies are set in Linear UI or GraphQL (MCP doesn’t expose them).

Step 6: Issues (06-issues)

Issues are 1–5 days of work, one owner. Sub-issues decompose when multiple people or smaller shippable pieces are needed. Each issue has project, milestone, success criteria, and optional blocks / blockedBy. Create parent issues first, then sub-issues (using parentId). Set dependencies after all issues exist.

Example: AI Feedback Collector in Practice

Here’s how the six-file hierarchy looks when applied to a real idea. We’ll walk through an “AI Feedback Collector for B2B” concept—a tool that runs async feedback sessions and summarizes insights with AI. The reader can see how each file feeds the next and how IDs link strategy to execution.

Idea → Initiatives

The idea file defines the problem and hypothesis:

• Problem: B2B teams spend excessive time on manual feedback collection; response rates are low, insights arrive too late.

• Hypothesis: We believe that an AI-powered async feedback tool that runs sessions and summarizes insights for B2B product and ops teams will result in reduced meeting load, higher response rates, and faster insight delivery. We’ll know when 10 design partners complete 70%+ of sessions and report 50%+ reduction in feedback-related meetings.

• Scope (in): Async session creation, AI summarization, basic dashboard, design partner onboarding.

• Scope (out): Live meeting transcription, full qualitative research platform, Enterprise SSO (Phase 2).

• Constraints: 10 partners, 3-month window; 1–2 engineers; Alpha in 8 weeks.

That idea becomes two initiatives:

IDNameSuccess CriteriaTargetINIT-001Launch MVP feedback product10 partners onboarded; 70%+ session completion2025-06-30INIT-002Prove enterprise readinessSOC2 prep; SSO; 3+ enterprise pilots2025-09-30

Initiatives → OKRs

OKRs make the initiatives measurable:

• O1 (Ship MVP) → INIT-001: KR1: 10 design partners onboarded; KR2: 70%+ session completion; KR3: 50%+ report reduced feedback meetings.

• O2 (Enterprise fit) → INIT-002: KR1: SOC2 prep complete; KR2: SSO available.

Each KR maps to a metric in the metrics file (design partners onboarded, session completion rate, etc.).

Metrics → North Star + Inputs

The metrics file ties outcomes to instrumentation:

• North Star: Weekly active feedback sessions (count of completed sessions per week); target 50+ by end of Q2.

• Input metrics: Session completion rate (70%+), time to first insight (<24h), design partners onboarded (10).

• Instrumentation: session_created, session_completed, response_received, summary_generated—events that the product DB must track.

Initiatives → Projects

Projects are time-bound deliverables under each initiative:

IDNameInitiativeMilestonesPROJ-001Core feedback flowINIT-001Design → Alpha → BetaPROJ-002AI summarizationINIT-001Model → Integration → PolishPROJ-003Enterprise dashboardINIT-002Dashboard → SSO → Pilot

Dependency: PROJ-002 blocks PROJ-003. The enterprise dashboard needs AI summarization before it can show complete session data. That dependency flows through to issues.

Projects → Issues

Issues break projects into 1–5 day work units. Example from PROJ-002 (AI summarization):

• ISSUE-002: Add AI summarization — Project: PROJ-002, Milestone: Integration. Success: summary displayed within 30s of last response.

• Sub-issues: ISSUE-002a (BE: Summarization API endpoint), ISSUE-002b (FE: Display summary in session view), ISSUE-002c (Prompt engineering for structured summary).

• Blocks: ISSUE-002 blocks ISSUE-003 (Enterprise dashboard overview)—the dashboard depends on summarization being in place.

The Chain in One View

Idea: "AI feedback tool reduces meeting load"
  → INIT-001: Launch MVP (10 partners, 70% completion)
    → PROJ-001: Core feedback flow
    → PROJ-002: AI summarization
      → ISSUE-002: Add AI summarization
        → ISSUE-002a: BE endpoint
        → ISSUE-002b: FE display
        → ISSUE-002c: Prompt engineering
  → INIT-002: Enterprise readiness (blocked by PROJ-002)
    → PROJ-003: Enterprise dashboard
      → ISSUE-003: Dashboard overview (blocked by ISSUE-002)

IDs (INIT-001, PROJ-002, ISSUE-002a) are the contract. When you sync to Linear, MCP links projects to initiatives by name, creates milestones per project, and creates issues with project and milestone. The markdown stays the source of truth; Linear reflects it.

The runbook: syncing to Linear

MCP is the primary path. Manual steps cover what MCP cannot do.

Sync order:

1. Initiatives — Manual or GraphQL. Use exact names from 02-initiatives.

2. Projects — save_project. Link to initiatives by name.

3. Milestones — save_milestone per project.

4. Parent issues — save_issue (no parentId, blocks, or blockedBy yet).

5. Sub-issues — save_issue with parentId.

6. Issue dependencies — Update issues with blocks and blockedBy.

7. Project dependencies — Set in Linear UI: Project → Settings → Dependencies.

MCP tools quick reference:

ToolKey paramssave_projectname, team, initiatives, targetDate, descriptionsave_milestoneproject, name, targetDatesave_issuetitle, team, project, milestone, parentId, blocks, blockedBy, description

Best practices

• Fill in order — 01 before 02, 02 before 03. Dependencies flow downward.

• IDs as contract — INIT-xxx, PROJ-xxx, ISSUE-xxx link markdown to Linear. Keep them stable.

• Sync log — Maintain _linear-sync-log.md with last sync date and ID mapping (Markdown ID → Linear ID). Use this for idempotent updates: pass id to save_project or save_issue to update instead of create.

Takeaway

Strategy and execution don’t have to drift. Markdown as source of truth, Linear as execution layer, and a six-file hierarchy from idea to issues keeps them aligned. Use Linear MCP for the mechanical sync; fall back to the Linear UI for initiatives and project dependencies. The hierarchy scales. The IDs are the contract. Fill in order, sync when ready.

We have hundreds of markdown files: personas, product specs, market research, marketing copy. Throwing it all into every LLM call meant 80,000+ tokens per query. At GPT-5.2 pricing ($1.75/1M input, $14/1M output), that’s real money. And it scales with every question.

The business driver wasn’t “let’s try RAG.” It was: we’re going to ask this a lot. What does it cost?

The approach: chunk, embed, retrieve

We built a simple RAG pipeline over our product docs:

1. Chunk by section — Markdown files split at `##` and `###`, ~300–600 tokens per chunk. Sections preserve meaning; random splits don’t.

2. Local embeddings — sentence-transformers (all-MiniLM-L6-v2). No API key, no per-chunk cost. Index once, query freely.

3. Retrieve top-k — For “What is our positioning for Persona 4?” we pull 8–12 chunks, not 80k tokens.

4. Build the prompt — Question + retrieved chunks only. The LLM sees what matters.

Indexing is free. Query retrieval is free. The only paid part is the LLM call—and that call is 10–20× smaller.

The numbers

I built a `compare_cost` script that estimates both paths without making API calls. For a typical product question:

=== LLM + full context ===

input_tokens: ~80,000

output_tokens: ~400

cost: ~$0.14 per query

=== LLM + RAG ===

input_tokens: ~4,000

output_tokens: ~400

cost: ~$0.01 per query

RAG uses ~20× fewer input tokens and costs ~14× less per query.

Run it yourself: `python3 -m rag.compare_cost “What are our pricing tiers?”` — no API key needed.

Design choices that matter

- Domain filters — We can restrict retrieval to `personas` or `product` or `marketing`. Smaller context, faster and cheaper.

- Section-based chunking — Keeps “Positioning” with “Persona 4” in one chunk instead of splitting mid-paragraph.

- Local embeddings — Embedding APIs add latency and cost. For internal docs, local models are fine.

## Takeaway

RAG isn’t magic. It’s cost control. When your product context is large and you’re querying often, full context doesn’t scale. Chunk, embed, retrieve—and measure the difference. The numbers will tell you when it’s worth it.

The stack (exact tools)

• Perplexity (in Safari) for answers you copy.

• Safari as the reading/asking surface.

• Obsidian as the Markdown knowledge base (vault stored in iCloud Drive).

• Apple Shortcuts as the glue that takes your clipboard and appends it to a daily note.

• Optional: Actions for Obsidian if you want deeper Obsidian-specific actions like “append below heading” and “create if missing” more reliably.actions+1

Vault setup (once)

1. Put your Obsidian vault in iCloud Drive (Obsidian → choose store in iCloud).

2. Inside the vault create a folder:

   • Daily/

3. Your daily notes will be saved as:

   • iCloud Drive/Obsidian/<VaultName>/Daily/YYYY-MM-DD.md

Why iCloud Drive? It keeps one shared .md file set across iPhone/iPad/Mac, and Shortcuts can write to it. (Just be aware iCloud sometimes delays refresh; Obsidian may not show changes instantly.)[forum.obsidian]​

The Shortcut (exact actions)

Create a Shortcut named: Save Clipboard → Obsidian Daily.

Variables used

• Today = current date formatted yyyy-MM-dd

• Now = current date/time formatted yyyy-MM-dd HH:mm

Shortcut actions (in order)

1. Get Clipboard

2. If Clipboard does not have any value

• Show Notification “Clipboard is empty”

• Stop This Shortcut

3. Current Date

4. Format Date (input: Current Date)

• Format: Custom → yyyy-MM-dd

• Save to variable: Today

5. Format Date (input: Current Date)

• Format: Custom → yyyy-MM-dd HH:mm

• Save to variable: Now

6. Text (this is what will be appended)

## Perplexity — {{Now}}

{{Clipboard}}

---

7. Get File from Folder

• Folder: pick in the Files picker: iCloud Drive/Obsidian/<VaultName>/Daily/

• Path: {{Today}}.md

• Toggle Error If Not Found: OFF (so you can create the file if needed)

8. If file does not have any value

• Text:

# Daily — {{Today}}

• Save File

  • Destination folder: same Daily/ folder

  • Name: {{Today}}.md

  • Overwrite: ON

• Get File from Folder again (same settings as step 7)

• End If

9. Get Text from Input (input: the file from step 7/8)

10. Combine Text

• Text 1: existing content

• Text 2: the Markdown block from step 6

• Separator: \n\n

11. Save File

• Destination folder: Daily/

• Name: {{Today}}.md

• Overwrite: ON
  Important note: Shortcuts is picky about base locations and overwriting; selecting the folder explicitly (not passing it as text) is the reliable pattern.[reddit]​

12. (Optional) Show Notification “Saved to {{Today}}.md”

That’s the whole “append-to-daily-markdown” pipeline.

Perplexity prompt tip (so clipboard is clean Markdown)

When you ask Perplexity, add:
“Format the answer in Markdown with headings and bullet points.”
Then copy the response and run the shortcut.

Trigger it on iPhone (fastest)

Use Back Tap to run the shortcut:

1. Settings → Accessibility → Touch → Back Tap.

2. Choose Double Tap or Triple Tap → under “Shortcuts” select Save Clipboard → Obsidian Daily.

Flow: copy in Safari → double tap back → saved.

Trigger it on iPad (best options)

iPad doesn’t give you the same Back Tap workflow, so use a widget:

1. Home Screen → long press → + → add Shortcuts widget.

2. Edit widget → choose Save Clipboard → Obsidian Daily as the shortcut shown.

Flow: copy → tap the widget → saved.

(If you want even less friction, put that widget in your Dock/Home Screen first page so it’s always one tap away.)

Trigger it on Mac (best: keyboard shortcut)

On macOS, assign a global hotkey:

1. Open Shortcuts app → open your shortcut → Shortcut Details.

2. Click Add Keyboard Shortcut and set a combo.apple+1

3. Now in any app: copy text → press hotkey → appended to the same iCloud .md daily note.

You can also enable Quick Actions (Finder Services) if you want to run it from Finder menus.

Optional: Actions for Obsidian (when it’s worth it)

If you later want Obsidian-specific features—append below a specific heading, use the current periodic note, or “create note if necessary” with fewer file edge cases—Actions for Obsidian provides dedicated actions like “Append to note” with options for headline placement and creating missing notes.

This is optional; your plain iCloud .md method is already solid once configured.

Summary (the workflow in one line)

Perplexity in Safari → copy Markdown → run “Save Clipboard → Obsidian Daily” via iPhone Back Tap, iPad widget, or Mac keyboard shortcut → your learning is stored as real Markdown in your iCloud-synced Obsidian vault.

This manifests in several ways:

1. Quality Time Over Meetings

• Focused 1:1s that develop people, not status updates

• Pair programming and mentoring sessions

• Off-sites that build relationships, not just plan roadmaps

2. Autonomy Over Control

• Define the goal and explain the context

• Let people figure out how to get there

• Trust their judgment and support their decisions

3. Connection Over Alignment

• Help people understand how their work connects to company purpose

• Share the why, not just the what

• Make meaning visible

4. Development Over Replacement

• Invest in growing your team

• Offer opportunities to learn new skills

• Create paths for career growth

Why This Matters Operationally

When people feel valued and trusted:

• Engagement increases - They bring more than their contracted hours

• Quality improves - They care about the outcome

• Velocity increases - Less overhead, more flow state

• Retention improves - They stay and build expertise

• Culture compounds - Great people attract great people

When people feel transactional:

• Engagement decreases - They do the minimum

• Quality suffers - Careless mistakes

• Velocity is inconsistent - Context switching and rework

• Turnover increases - Your best people leave first

• Culture decays - Cynicism and disengagement spread

The economic case for people-first leadership is overwhelming.

The Scaling Principle: Dunbar’s Number

As organizations grow, trust becomes harder. Dunbar’s number suggests:

• 4-8 people - Direct relationships, high trust

• ~50 people - Effective as a subgroup

• ~150 people - Maximum “tribal” group with shared culture

• 500+ people - Requires deliberate structure and values

At each level, you must:

• Maintain psychological safety and trust

• Preserve the culture and values

• Enable autonomy while maintaining alignment

• Give people opportunities for connection

This is why team structure matters. Small, stable teams preserve the conditions for high performance.

The Cognitive Capacity Principle

As products grow, so does maintenance burden. Teams hit a cognitive capacity ceiling:

• They’re optimizing for stability instead of innovation

• Technical debt grows faster than they can reduce it

• Burnout increases as problems multiply

• Motivation decreases because new features are rare

This is team expansion, not team failure.

At this point, leaders must:

1. Acknowledge the ceiling - “We’ve hit the complexity limit with the current team”

2. Invest in technical foundation - Reduce the maintenance burden

3. Expand strategically - Hire or split into smaller teams

4. Preserve people-first culture - New people need the same investment

Psychological Safety: The Foundation

Before any of this works, you need psychological safety:

• Can people speak up about problems without fear?

• Can people admit mistakes and learn from them?

• Can people propose ideas without judgment?

• Can people ask for help?

Without psychological safety, every other principle fails.

Building People-First Culture

In your 1:1s:

• Ask about growth aspirations, not just current work

• Offer perspective and connections, not just feedback

• Celebrate learning and reasonable failures

In team meetings:

• Share the why behind decisions

• Discuss hard problems and trade-offs transparently

• Highlight how individual work contributed to outcomes

In retrospectives:

• Focus on systems and processes, not blame

• Celebrate what worked and what was learned

• Follow through on improvements

In hiring and promotion:

• Look for potential and values alignment, not just credentials

• Invest in developing people into roles

• Promote based on impact and growth, not just tenure

The Anti-Pattern: Burnout Culture

I’ve seen organizations where:

• Heroic effort is celebrated over sustainable pace

• Mistakes are punished instead of learned from

• Growth opportunities only come through exhaustion

• People are replaced instead of developed

These organizations always lose their best people.

Implementation

This quarter:

1. Audit your 1:1s - Are they developmental or transactional?

2. Review your team celebrations - What are you rewarding?

3. Assess psychological safety - Can people speak up?

4. Plan a team experience - Build connection and meaning

This year:

1. Develop 2-3 people for bigger roles

2. Reduce burnout indicators (turnover, sick days, engagement scores)

3. Create visibility into career paths

4. Build a culture where people want to stay and grow

The Compound Effect

Organizations that prioritize people don’t just build better culture—they build better products:

• Smarter decisions (diverse, experienced team)

• Higher quality (people who care)

• Faster delivery (less rework and overhead)

• Sustainable growth (not burnout-driven)

People first isn’t a nice-to-have. It’s your competitive advantage.

Real empowerment is structural, not philosophical.

What Empowerment Actually Requires

Empowered teams need:

1. Clear Purpose - They understand what problem they’re solving and why it matters

2. Sufficient Autonomy - They can make decisions without constant approval

3. Adequate Information - They have data to make good decisions

4. Psychological Safety - They can fail without punishment

5. Appropriate Accountability - They own outcomes, not just effort

Most organizations get 2-3 of these right. Empowerment requires all five.

The Structural Framework

1. Purpose Through Vision-OKR-KPI Alignment

Empowered teams start with crystal-clear purpose:

• How does our work connect to company vision?

• What OKRs are we driving?

• What KPIs measure our success?

Without this, teams make decisions based on guesswork.

2. Autonomy Through Defined Governance

Counterintuitive: Clear governance enables autonomy.

Define:

• What needs approval? (Company strategy, external commitments, major architecture changes)

• What needs consultation? (Cross-team dependencies, resource allocation)

• What’s delegated? (Daily prioritization, implementation details, ceremonies)

Teams don’t need to ask permission for delegated decisions.

3. Information Through Transparency

Empowered teams need:

• Roadmap visibility - What are we building and why?

• Dependency visibility - Where are we blocked?

• Metric visibility - How are we doing against success criteria?

• Customer visibility - Who are we serving and what do they need?

If teams don’t have this, they can’t make good autonomous decisions.

4. Psychological Safety Through Explicit Commitment

Leaders must say and mean:

• “We expect you to make mistakes while learning.”

• “Your job is to solve problems, not to guess what I want.”

• “I’ll support you when things don’t go as planned.”

Then actually do it.

5. Accountability Through Clear Outcomes

Accountability isn’t about blame—it’s about ownership:

• “This is your area of ownership.”

• “Here’s how we’ll measure success.”

• “You’re responsible for delivering value, and I’m responsible for removing obstacles.”

The Empowerment Checklist

Before calling a team “empowered,” verify:

1. Team can articulate how their work drives company OKRs

2. Team understands success criteria and can measure progress

3. Team makes daily prioritization decisions without approval

4. Team has visibility into customer needs and feedback

5. Team can propose architectural solutions without long approval cycles

6. Team escalates blockers; doesn’t wait for permission to solve them

7. Team retrospectives result in adopted improvements

8. Team feels safe experimenting and occasionally failing

If you score less than 7/8, you have authority-delegated teams, not empowered teams.

The Leadership Shift

Empowering teams requires leaders to shift:

From “Tell me your plan for approval” To “What data do you need to decide?”

From “Let’s have a meeting to align” To “Here’s the shared context; what would you do?”

From “Document the requirements” To “What problem are you solving?”

From “Report on your progress daily” To “What support do you need?”

From “Follow this process” To “What process would make you faster?”

Common Pitfalls

Empowerment Theater:

• Leaders say “Be autonomous” but override decisions regularly

• Teams nominally own outcomes but lack real authority

• Result: Cynicism and disengagement

Under-Structure:

• “Full autonomy” with no alignment or guardrails

• Teams optimize locally, break globally

• Result: Chaos and conflict

The balance: Clear, tight alignment on purpose and outcomes. Loose, delegated authority on how to get there.

Implementation: The Three-Month Plan

Month 1: Establish Clarity

• Define team purpose, OKRs, success criteria

• Map team structure to system architecture

• Document what’s delegated vs. needs consultation

Month 2: Build Transparency

• Create shared visibility into dependencies, metrics, customer needs

• Establish regular cadence for data sharing

• Ensure all team members understand the roadmap

Month 3: Prove Capability

• Have teams make autonomous decisions

• Support them through the rough patches

• Celebrate wins; learn from misses

The Payoff

Truly empowered teams:

• Move 2-3x faster (less approval delay)

• Build better solutions (more context and ownership)

• Have higher engagement and lower turnover

• Develop leaders within the team

• Attract better talent

Empowerment isn’t something you grant. It’s something you build through clarity, transparency, and trust.

Dependencies are predictability killers:

• When Epic #1 in Team A blocks Epic #2 in Team B, delivery is unpredictable

• Cross-team coordination meetings multiply

• Context-switching increases

• Blame games emerge when one team slips

• Confidence in commitments drops

Yet most organizations don’t systematically manage dependencies.

The Visibility Principle

To be transparent about dependencies, you must apply the same clarity to Epics as you do to User Stories.

Most teams do this:

• Epics: vague, large, unprioritized ❌

• Stories: well-defined, sized, ready ✓

Do this instead:

• Epics: prioritized, sized, with clear dependencies ✓

• Stories: well-defined, sized, ready ✓

The Framework: Story → Epic → Quarterly Structure

Granularity is the key.

Your sizing should follow: Day - Person - Story for individual contributions Scaling up: Sprint - Team - Epic for team contributions Scaling up: Quarter - Organization - Initiative for organizational contributions

Think of it as matryoshka dolls—each level is self-contained and independently deliverable.

Dependency Mapping for Quarterly Planning

Before a quarter starts:

1. List all Epics in your roadmap for the quarter

2. Prioritize them by business impact

3. Estimate duration (in weeks, not story points—be concrete)

4. Draw dependencies - Which Epics depend on which others?

5. Visualize the flow - Can your teams deliver without constant blockers?

Example:
Epic #1 (Team A) - Week 1-3 - No dependencies
  ↓
Epic #2 (Team B) - Week 2-4 - Depends on Epic #1 API
  ↓
Epic #3 (Team A) - Week 4-6 - Independent
Epic #4 (Team B) - Week 5-7 - Depends on Epic #3 data

Reducing Dependencies Through Architecture

Conway’s Law states: “Systems architecture mirrors organizational structure.”

The inverse is true: Organizational structure should mirror system architecture.

If your architecture has hard dependencies, your team structure should too. If you want independent delivery, your system should be loosely coupled.

Questions to ask:

• Which teams could deliver independently if we redesigned the architecture?

• Where do we have unnecessary cross-team handoffs?

• Can we create stable interfaces that allow teams to work in parallel?

The Granularity Lever

Smaller chunks = shorter potential blocker duration

If you have a 4-week Epic that’s blocked by another team:

• You lose 4 weeks of velocity from the blocking team AND

• The blocked team idles for part of the month

If you break it into 1-week Epics:

• Shorter individual blocking periods

• More opportunities to find parallel work

• Faster feedback loops

Success Metrics for Visibility

Track these:

• Percentage of work blocked by dependencies - Goal: < 10%

• Average blocker resolution time - Goal: < 1 day

• On-time Epic delivery rate - Goal: > 90%

• Cross-team coordination meetings per week - Goal: < 3

Implementation

Quarter 1:

1. Map all dependencies explicitly

2. Measure current state (what % of work is blocked?)

3. Identify top 3 architectural/organizational changes needed

Quarter 2-3:

1. Break large Epics into smaller, more independent chunks

2. Adjust team boundaries to align with architecture

3. Build new capabilities or interfaces to decouple systems

Ongoing:

1. Review dependency patterns monthly

2. Celebrate decoupling wins

3. Continuously experiment with granularity

The Payoff

Organizations with excellent dependency visibility see:

• 30-50% improvement in predictability

• Fewer surprises and missed deadlines

• Reduced cross-team friction

• Improved team autonomy and morale

• Faster overall delivery

Dependencies don’t disappear, but making them visible turns them from hidden killers into managed constraints.

Most organizations have:

• Clear company vision and mission ✓

• Well-defined OKRs and KPIs ✓

• A detailed roadmap ✓

But they often lack:

• Clear translation from company OKRs to team-level success criteria ✗

This translation is everything.

The Gap

Without team-level success criteria:

• Teams optimize for the wrong things (activity instead of impact)

• Decisions are made by whoever speaks loudest

• Scope creeps because “success” isn’t defined

• Burnout increases when teams don’t see meaning in their work

• Executives are surprised when teams deliver the wrong solution

How to Define Criteria of Success

Step 1: Map Company Objectives to Team Impact

Start with your KPIs. For each one, ask:

• “How does our team contribute to this?”

• “What’s our specific part of the equation?”

• “What can we measure that demonstrates our contribution?”

Example:

• Company KPI: “Increase customer booking conversion by 8%”

• Team contribution: “Reduce checkout friction by improving form usability”

• Team success criterion: “Checkout completion rate +5% OR form abandonment -3%”

Step 2: Define Behavioral and Technical Success Criteria

Success isn’t only about metrics. Include:

• Behavioral: “Checkout time under 60 seconds”

• Technical: “Core Web Vitals: LCP < 2.5s, CLS < 0.1”

• Quality: “Error rate < 0.1%, uptime > 99.99%”

• Operational: “Support ticket volume for checkout < 5 per day”

Step 3: Create Autonomy Through Clarity

The ultimate test: “Could this team complete their mission without constant guidance?”

If the answer is no, your success criteria aren’t clear enough.

The Antipattern: Activity-Based Success

Too many teams define success as:

• “Complete all sprint stories” ❌

• “Achieve velocity of X story points” ❌

• “Deploy 4x per week” ❌

These are activities, not outcomes. Better questions:

• “Did we improve the metric we’re targeting?”

• “Did we reduce customer pain?”

• “Did we improve system reliability or developer experience?”

Why This Matters at Scale

As you add teams, criteria of success become critical:

• Alignment - Teams working toward the same north star

• Autonomy - Teams make decisions consistent with success criteria

• Accountability - Clear criteria make outcomes measurable

• Reduced conflict - When priorities clash, success criteria break ties

Implementation

1. Extract each team’s contribution from company KPIs

2. Translate into 3-5 measurable success criteria per team

3. Make them visible in your backlog and sprint planning

4. Review progress monthly and adjust

5. Celebrate when teams move the needle

The Result

Teams with clear success criteria:

• Ship faster (fewer clarification delays)

• Build better solutions (they understand the problem)

• Feel more motivated (they see their impact)

• Make smarter trade-offs (they understand what matters)

When your team understands what success looks like, execution becomes obvious.

Scrum isn’t a checklist of ceremonies. It’s a structure for predictable delivery:

Sprint Planning → Sprint (with Daily Standups) → Sprint Review → Sprint Retrospective → Backlog Grooming

What Actually Matters

Definition of Ready (DoR) - Before Sprint Planning

• Work is groomed enough to start development

• Success criteria are clear

• Dependencies are identified

• It’s sized appropriately for the sprint

Sprint Planning - Pulling Work

• Teams pull stories that meet DoR

• Capacity constraints are realistic

• Commitment is made with confidence

Daily Standup - Staying Unblocked

• What did I complete yesterday?

• What am I working on today?

• What impediments do I face?

• Note: Solve problems after standup, not during it

Definition of Done (DoD) - Completion Standards

• Code review completed

• Tests written and passing

• Documentation updated

• Integrated and deployable

Backlog Grooming - Preparation

• Preparing stories for future sprints

• Breaking down epics into deliverable units

• Adding acceptance criteria

• Identifying risks and dependencies

The Ceremony That Closes the Loop

Sprint Review + Sprint Retrospective

• Review: Demonstrate completed work to customers. Gather feedback.

• Retrospective: Team reflects on how to improve delivery in the next sprint.

The Key Questions to Ask Yourself

1. Are your DoR and DoD criteria actually meaningful? Or are they checkbox exercises?

2. Does every team member understand why each ceremony exists? If not, they feel like overhead.

3. Are you measuring what matters? (Delivery, quality, morale) rather than activity?

4. Do teams feel empowered to adapt the framework? Or do they feel constrained by rigid process?

Red Flags That Your Scrum Isn’t Working

• Sprints consistently overcommit or underdeliver

• Retrospectives identify the same problems every sprint with no improvement

• Daily standups feel like status reports to management

• Stories constantly move to the next sprint or fail DoD

• Teams view ceremonies as interruptions rather than value-add

The Reframe

Scrum ceremonies exist to answer one question: Are we delivering value predictably?

If you’re following perfect Scrum but shipping slowly, your framework isn’t the problem—your execution is. Examine:

• Are DoR criteria preventing bloat?

• Are DoD criteria ensuring quality?

• Are dependencies surfaced early enough?

• Is the team empowered to solve problems?

The Payoff

Teams that use Scrum effectively for delivery see:

• Predictable sprint outcomes

• Fewer surprises and blocker-induced delays

• Higher code quality and fewer defects

• Better team morale (they see their work impact)

Process serves people. People deliver value. Always optimize for delivery.

Engineering leaders often face this dilemma:

• Product work needs to expand (new features, innovation)

• Maintenance and technical debt are necessary but consume 40-60% of capacity

• On-call responsibilities pull resources unpredictably

• Meanwhile, teams feel they’re “always firefighting”

This isn’t a team problem. It’s a backlog structure problem.

The Three-Pillar Backlog Framework

Effective backlogs balance three streams:

1. Contribution to Vision (Product Work)

• Features that drive OKRs and expand value proposition

• Should grow through better prioritization and focus

• Connected to customer success criteria

2. Maintenance

• Operational work that keeps systems running

• Necessary but often invisible

• Often underestimated in capacity planning

3. Technical Solution (Technical Debt & Quality)

• Automation that reduces future maintenance burden

• Refactoring that improves system resilience

• Architecture improvements that enable faster delivery

The Critical Question: What Customers Are You Serving?

Most teams overlook this: Every backlog item comes from a customer or stakeholder channel.

• External customers with feature requests

• Internal customers (support, sales, operations)

• Infrastructure and platform needs

• Regulatory and compliance requirements

Identify all your channels. For each one, ask:

• Why does this customer want this from us?

• How does it connect to our success criteria?

• Could we reduce this load through automation or clear communication?

The Balancing Act

Here’s the framework that works:

• Expand your product work by improving prioritization and focus

• Reduce maintenance burden by prioritizing strong technical solutions and automation

• Measure success through criteria aligned with vision

Implementation Steps

1. Map your backlog channels - Where do items originate?

2. Define customer needs - Not just what they ask for, but why they need it

3. Set clear success criteria - How do backlog items contribute to OKRs?

4. Balance the three pillars - Allocate capacity deliberately across product, maintenance, and technical solution

5. Get it under control - Ruthless prioritization means saying no

The Payoff

Teams with mastered backlogs report:

• Clearer sense of purpose and meaning in their work

• Reduced context-switching and firefighting

• Better technical quality and maintainability

• Higher morale and lower burnout

Your backlog isn’t just a to-do list—it’s your team’s declaration of what matters.

Many organizations struggle because they fail to connect organizational strategy to team-level work. This disconnect creates:

• Unclear priorities and competing initiatives

• Teams working on features that don’t drive business value

• Reduced engineering morale due to lack of meaning in their work

• Predictability challenges that surprise executives

The solution: Establish a clear representation of Vision → OKRs → KPIs → Roadmap → Team Backlogs.

Why This Matters

Your roadmap serves three critical functions:

1. Provides Predictability - It defines stages with quality criteria (input, flow, output), setting clear expectations for what “done” looks like at each level

2. Enables Executive Visibility - Executives see company priorities and understand what can be negotiated vs. what’s fixed

3. Ensures Deliverability - Teams have sufficient detail to start work without constant clarification

Implementing the Promise

Quarterly Planning (Q Planning):

• Create a prioritized set of work with “good enough” detail to start delivery

• Define clear criteria of ready (input) and criteria of done (output)

• Ensure the roadmap is actually doable within your capacity

• Answer the fundamental question: “Is it doable?” with real data

The alignment equation: Roadmap + Capacity + Criteria of Success (KPIs) = Team Understanding of Contribution

Key Takeaway

Stop treating your roadmap as just a project plan. Instead, view it as the bridge between what your company needs to achieve and what your teams execute. This alignment is what separates engineering organizations that deliver predictably from those that constantly disappoint.

When your teams understand how their work contributes to company OKRs, delivery becomes easier, predictability improves, and motivation increases.

This is where the Objective and Key Results (OKR) framework comes in. Originally pioneered by Intel and later popularized by companies like Google, OKRs help businesses define ambitious goals and track measurable outcomes to drive growth and innovation.

What Are OKRs?

OKRs consist of two essential components:

1. Objective – A clear and inspiring goal that defines what you want to achieve.

2. Key Results – Measurable outcomes that indicate whether you are making progress toward your objective.

Unlike traditional goal-setting methods, OKRs focus on outcomes rather than outputs, ensuring that teams work on what truly matters. OKRs promote transparency, alignment, and accountability within an organization.

How Can OKRs Be Used?

The OKR framework can be applied at different levels:

1. Company-Level OKRs – High-level goals that align with the company’s mission.

2. Team-Level OKRs – Department-specific objectives that contribute to company-wide goals.

3. Individual OKRs – Personal goals that support team and company objectives.

Typically, OKRs are set on a quarterly basis to keep teams agile and responsive to change. They encourage employees to aim high, fostering a culture of continuous improvement.

A Simple Example of OKRs in Action

Let’s say you run a growing SaaS business and want to improve customer retention. Your OKR might look like this:

Objective: Enhance customer satisfaction and retention.

Key Results:

1. Increase Net Promoter Score (NPS) from 45 to 60.

2. Reduce customer churn from 5% to 3% per quarter.

3. Improve customer support response time from 24 hours to 6 hours.

This structure ensures that everyone understands what success looks like and can measure progress effectively.

Ready to Implement OKRs in Your Business?

Adopting OKRs can transform the way your company sets and achieves goals. If you’re looking for expert guidance on implementing OKRs and aligning your team for success, I can help!

Click Exceed.sk to learn more about my OKR consulting services and take your business to the next level.

Join me on this journey to transform your business outcomes and achieve success.