Beyond the build: adoption and developer culture

Table of contents

The three stages of wide-scale change

Plan and align so the change is bounded, understood, and owned before it spreads. Implement in real systems—or coordinate owners so it lands consistently. Evangelize so the change survives contact with real teams and doesn’t die in a folder nobody opens. Skipping planning feels fast until you’re re-explaining the same decision in every retro; skipping implementation leaves you with philosophy; skipping evangelism leaves you with a wiki and a prayer. The sections below unpack each stage.

Change implementation in detail

Organization change is messy in practice; the sections below unpack the same sequence in detail.

1. Make a plan, get consensus, and collaborate

How to approach it

Name the problem plainly: what hurts, for whom, and what would feel different if this worked. Scope a first version on purpose—what’s in, what’s explicitly out, and what you intend to learn next. Talk to someone who has walked a similar path before¹.

Buy-in rarely lands in one meeting: first draft, iterate with collaborators until you’re confident, bring in leadership and broader stakeholders until you’re ready to execute, then define the execution timeline. Sketch:

%%{init: {"flowchart": {"curve": "basis", "padding": 8}, "themeVariables": {"fontFamily": "inherit"}}}%%
flowchart LR
    A[First draft] --> B[Iterate with collaborators]
    B --> C{Confident?}
    C -->|No| B
    C -->|Yes| D[Leadership and broader stakeholders]
    D --> E{Execution ready?}
    E -->|No| D
    E -->|Yes| F[Define execution timeline]

Takeaway: iterate until you’re confident before you widen to leadership and stakeholders; lock an execution timeline only once execution is actually ready.

Write for the audiences you have; staff, leads, and managers rarely need the same document. Build consensus with the people who will live with the consequences—service owners, on-call, release, hiring. Collaboration here isn’t one permission meeting; it’s shared trade-offs, including ugly ones. Before you move on, agree on success criteria you can observe: fewer incidents, faster feedback, fewer exceptions—whatever fits the change.

What you can expect when this step is done

You’ll have a shared why, not only a what. Teams that matter had room to push back, and you folded that in or wrote down why not. You’ll have a credible sequence: who goes first, what depends on what, and what “first” means. The plan should cover pain and cost, the agreed direction, stakeholders, measurable success, and named owners and affected teams.

What can go wrong

Consensus theater — meetings where everyone nods but nobody commits. Mitigate with real buy-in, including from leadership when you can: short, prepared sessions with a concrete proposal and evidence, not a vague ask.

Analysis paralysis — the plan never gets small enough to ship. A shared breakdown (tickets or a sheet) with a couple of devs for a day or two often unsticks it.

Silent veto — people who weren’t in the room block you later. You can’t always avoid it; sometimes the org quietly shelves the work and you regroup. Showing value over time keeps you credible for the next attempt.

Over-promising — the plan assumes every team has the same capacity and skill. Smaller tickets and less ambiguity surface that early; don’t pretend one size fits all.

2. Implement — in code or through coordination

Implementation: put your money where your mouth is

It has to land in real systems: templates, linters, CI defaults, scaffolding, libraries, golden paths—not only a wiki under pressure. Make the right path easier than the old one; where you must, raise the cost of the wrong path with lint, reviews, or gates—but with empathy for migration; shame isn’t a rollout strategy. If teams can’t tell whether they’re “done” adopting, they’ll optimize for whatever is easiest this sprint—which is often the old way.

Instrument enough to see adoption and failure modes: who’s on the new path, what breaks, whether rollbacks are exercised. Pair adoption (coverage over time) with friction (exceptions, workarounds, noisy tickets). If friction climbs while adoption looks flat, you may be measuring theater. Loop in owners and on-call before production behavior changes; bring platform and security in early if pipelines or risk posture shift. Surprise them after the fact and you pay for it in pages and politics.

Two patterns both work; what fails is mixing them without admitting it.

Path 1: Your team implements

You drive the change across the repos that matter, mostly inside your group. You still don’t own every line in the company: treat code owners as partners—interfaces, timelines, review load—before you flood them with diffs. Carry clear milestones and a definition of done per place that people can repeat without improvising, or you get “we shipped in our repo” while the org stays on the old path.

Path 2: You farm work to other teams

You delegate to owners. That only works if they bought in early enough to schedule the work, not just nod. Roadmaps clash; “we agree in principle” isn’t capacity. Negotiate dates and document who owes what by when. Start where momentum is easiest: teams that feel real pain, have a bounded blast radius if you misstep, and opted in—not groups you “volunteer” by surprise. That lines up with starting with sympathetic, innovative cohorts². When someone asks “why them first?”, answer with criteria (pain, readiness, capacity) and a rough order of march for who’s next, so it doesn’t look like favoritism.

Often the main team carries the foundation first; once that track is far enough along, the other two teams pick up their slices in parallel while the main team finishes. The shape is common:

gantt
    dateFormat YYYY-MM-DD
    title Illustrative rollout across teams
    section Main team
    Foundation and core :a1, 2026-01-06, 33d
    Conclusion :a4, 2026-03-20, 10d
    section Team B
    Feature slice B :a2, 2026-02-01, 28d
    section Team C
    Feature slice C :a3, 2026-02-15, 35d

Takeaway: the main team carries foundation and wrap-up; other teams start their slices once the foundation is far enough along—your calendar will differ.

Tickets aren’t fire-and-forget. You’re still accountable for landing the change: unblock, keep the rollout alive, and sign off on completion against agreed criteria—not an endless “almost done.” If you’re always the one explaining the program, you don’t yet have a program—you have a personal tour. Get peers and sponsors carrying the story too. Partial work and silent drops are what you get when you walk away too early.

How to know your change has been fully implemented

There’s working code or infrastructure, not only slides. Teams can apply the pattern with examples they can copy; edge cases are handled or explicitly deferred with a visible plan. If you led implementation, evidence spans the repos you owned and owners aren’t left with surprise debt. If you delegated, each team met its slice and the org-wide picture matches the plan—bounded scope, real exit, so the program doesn’t drift forever.

Possible implementation pitfalls

Partial implementation — one team moves; others don’t; two incompatible worlds. Big-bang failure — a huge switch with no rehearsal or rollback story. Coordination debt — “someone else was supposed to,” but nobody owns the outcome. Tooling without teaching — CI fails people with no path to green, and frustration is all they remember.

3. Evangelize and foster adoption

Communication and hope

Meet people where they are: demos, office hours, posts in channels where team leads actually read. Repeat the why over and over, it may be boring to you but newcomers weren’t in the room when the decisions were made. You need a sponsor who can clear priority and a champion in each pocket of the org who can answer without you—otherwise you’re always the bottleneck.

Map the shadow org chart once: who can quietly block exceptions, which forum actually moves decisions. Make feedback easy and close the loop; black holes kill trust. Celebrate real wins (migrations, metrics) so it feels shared, not mandated. The goal isn’t applause; it’s that asking for help on the new path is easier than routing around it.

When you’re done spreading the word

New hires and existing teams should hit the new default without a private tour from you. Questions get predictable enough to document; surprises shrink. The old way should feel deprecated, not equally valid forever.

Adoption is hard—don’t beat yourself up

Talk isn’t enough; you may need to review work over time so adoption stays real. Mandates produce paper compliance and workarounds. Premature victory is declaring success when only friendly teams moved. Burnout is a tiny group policing everyone—senior allies have to share the load. Scope creep after “go live” erodes trust; if you’re constantly re-litigating in PRs, pause and reset the message. It’s also OK to pause, narrow, or stop when the same objections loop without new learning, no sponsor will own capacity, or teams keep routing around the standard—exit cleanly, document what you learned, and don’t poison the next attempt. The old way will defend itself in review; expect friction that isn’t always technical.

If you get it wrong: risks and common confusions

Risks

Done badly, this wastes time: big builds nobody uses, or shadow processes that pretend alignment while teams do something else. Cynicism follows when “we tried that initiative” becomes shorthand for “don’t bother me with change.” Uneven quality widens when easy adopters pull ahead and stragglers fall behind—sometimes by skill, sometimes by incentives you didn’t mean to create. Security and compliance suffer when auditors see one story and production sees another, because people optimize for what actually hurts when it breaks.

Confusions worth clearing up

“We shipped it” ≠ “it’s adopted.” Shipping is a milestone; adoption is behavior over time. Process isn’t culture—slides don’t change habits; systems and incentives do. Consensus isn’t unanimity—you need enough alignment to move and a clear dissent path, not infinite meetings. This isn’t a hero arc—sponsors, champions, and durable ownership matter when the ADR author is on vacation.

Driving change is build, implement, and adopt—skip a leg and good ideas die quietly. Get the rhythm right and you’ll still have hard days, but fewer where you wonder why nobody uses what you built. The point isn’t perfection; it’s that each stage gets a deliberate slice of your attention before you call the program a win. Next step: pick one initiative you own and score each stage honestly; schedule the smallest concrete fix for the weakest leg—then revisit after the next milestone.