Tech orgs face a program management problem sometimes misdiagnosed as a communication problem.
Part 1 — Context
The precision gap in a typical tech org
A cross-functional delivery team looks something like this: a program lead who thinks in frameworks, plans, risks and sequenced dependencies. A product owner who translates between business intent and delivery reality. An engineering head who operates on instinct, experience, and velocity. Each is competent. Each is operating at a different level of structural precision.
This is normal. It’s not a hiring failure. It’s an org design reality.
The problem isn’t that people have different orientations. The problem is that most orgs never acknowledge the gap — so nothing is built to bridge it.
In program management, precision matters more than in most disciplines. A “gate” is not a “milestone.” A “program step” is not a “project step.” These distinctions exist because they encode different decision authorities, different review criteria, and different downstream actions. When the terms collapse into each other, the framework collapses with them — and delivery anxiety fills the vacuum.
The org ends up with one person holding the precision and everyone else holding the confusion.
Part 2 — The conflict, diagnosed
Why the framework doesn’t spread
The program lead defines the framework. Documents it. Trains the team. Reinforces it in reviews. And still — in the next meeting — the terms are muddled again.
This is a familiar failure mode. Here’s why it happens.
Documentation is not adoption. Writing a framework down transfers information. It does not change behavior. People don’t resist frameworks because they don’t understand them. They resist because the framework hasn’t become part of how they see their own work. Until it does, they’ll revert to their natural language the moment they’re under pressure.
Correction without consequence teaches avoidance. When terminology errors get flagged in meetings — especially by someone with more seniority or structural authority — people learn to stay quiet, not to get precise. The room gets smaller. The confusion goes underground.
Precision is load-bearing for one person, overhead for others. The person who built the framework feels the cost of imprecision acutely. Everyone else feels the cost occasionally, abstractly, or not at all. That asymmetry explains why the same problem recurs. It’s not carelessness — it’s a difference in felt stakes.
The product owner absorbs the gap. In most orgs, the person positioned between program rigor and engineering execution ends up brokering the difference quietly. That’s unsustainable. It concentrates friction in one role and masks the underlying adoption failure.
The diagnosis: this is a change management problem wearing the clothes of a communication problem. More documentation won’t fix it. Better enforcement won’t fix it. The adoption model needs to change.
Part 3 — A solution using ADKAR
Applying the ADKAR change model to framework adoption
ADKAR is a structured model for individual change: Awareness, Desire, Knowledge, Ability, Reinforcement. It’s typically applied to org-wide transformations. It applies equally well to getting a cross-functional team to actually use a program management framework — because the problem is the same. You’re asking people to change how they think and work.
Most orgs jump straight to Knowledge (documentation, training). ADKAR says that’s the third step. The first two are where adoption breaks down.
A — Awareness
People need to understand why the distinctions matter — not what the terms mean, but what goes wrong when they’re confused.
Make the cost visible. Show a specific example where “gate” and “milestone” were used interchangeably and a decision was delayed or made by the wrong person. Don’t explain the framework. Show the failure it prevents. Awareness is built on consequence, not definition.
What this looks like in practice: A short retrospective item — “here’s what happened last quarter because we didn’t have a clear gate decision” — lands harder than any onboarding document.
D — Desire
People need a reason to care that connects to their own work — not the program lead’s work.
For the engineering head: imprecision creates rework and re-scoping. The framework reduces that. Frame it in his terms. For the product owner: clarity on gates and program steps means she stops absorbing the ambiguity between two functions. The framework protects her, not just the program.
Desire is personal. The same framework needs three different value propositions for three different roles.
What this looks like in practice: One conversation per person — “here’s how this makes your job easier” — before the next framework reinforcement session.
K — Knowledge
This is where documentation belongs. Once Awareness and Desire are in place, people are ready to learn.
Reduce the framework to the minimum decision-relevant terms per role. The program lead needs the full architecture. The eng head needs to know what a gate means for his team. The product owner needs to know when to escalate vs. absorb.
Don’t give everyone the full framework. Give each person the slice that governs their decisions.
What this looks like in practice: Three one-page reference sheets — one per role — instead of one master document.
A — Ability
Understanding the framework is not the same as being able to use it under pressure.
Build practice into real work, not training sessions. When a term gets muddled in a meeting, replace correction with a question: “Which step in the framework does that map to?” That’s not a test — it’s a prompt. It builds retrieval without triggering defensiveness.
Low-stakes repetitions build the muscle. High-stakes corrections create avoidance.
What this looks like in practice: A standing item in the weekly delivery review — “are we aligned on where we are in the program sequence?” — makes the framework operational, not theoretical.
R — Reinforcement
Adoption degrades without reinforcement. But reinforcement works best when it’s distributed — not held by one person.
The goal is for the product owner and eng head to self-correct, and eventually to correct each other. That only happens when they have enough framework fluency to feel the error themselves, not just receive it from outside.
Celebrate precision publicly when it appears. Make the framework the shared language of delivery reviews, not just the program lead’s language.
What this looks like in practice: When the eng head correctly distinguishes a gate from a milestone in a meeting — acknowledge it. Make precision visible as a team behavior, not a compliance requirement.
The shift
The framework is sound. The adoption model is the constraint.
Move the intervention from Knowledge to Awareness and Desire first. Compress the documentation to role-relevant slices. Replace correction with prompting. Distribute reinforcement. The precision doesn’t need to live in one person. It needs to become the team’s shared operating language — and that requires a change management sequence, not a better manual.
Operator-grade thinking for delivery leaders.