I have sat through the offsite. Three days in a hotel with bad coffee and a facilitator who owns too many flip charts. Forty slides come out the other end. The deck gets a launch meeting, a wiki page, and a mug.
Six months later I asked an engineer on the delivery team to name the top three priorities. He named one. He got it wrong.
Nobody needed a better rollout. The plan broke at the point of writing, because the people holding the pen sit furthest from the work.
Nobody Remembers the Plan Anyway
Donald Sull and Rebecca Homkes surveyed 11,000 senior executives, leaders and managers across more than 400 companies. Only a third of them identified their own firm's top three priorities correctly. Given five attempts, about half listed even one priority in common with their peers. London Business School published the numbers in 2015.
Read the sample again. Senior executives. Managers. The people in the room when the deck got built are the ones failing to recall the contents.
If leadership fails to hold the plan in its head, what chance does the backend team have on a Tuesday afternoon with a production incident open?
Strategy written at the top does not survive contact with the code. It never has.
Your Org Chart Already Wrote Your Architecture
Melvin Conway published his law in 1967: any organization designing a system produces a design whose structure copies the organization's communication structure. Martin Fowler has a good summary of it.
Sit with the implication. Separate frontend, backend and database departments produce a three-tier app. Four regional divisions produce four forks of the same service with four deploy pipelines. A team split across two time zones produces an API with a queue in the middle, because a queue is what a nine hour gap looks like in code.
Your architecture already reflects a plan. Not the plan in the deck. The plan drawn in the reporting lines.
Some teams use this on purpose. Fowler describes the inverse Conway maneuver: reshape the teams to get the architecture you want. Small, long-lived teams built around business capabilities, each holding every skill needed to deliver something a customer values. He also warns against expecting a reorg to fix an entrenched system overnight. Move the org and the architecture together, in steps, or you get developers fighting a codebase shaped for a company no longer in existence.
Notice what both directions share. Team shape decides system shape. Not the roadmap. Not the OKRs. Team shape.
So if you want a different plan, change who holds the pen.
The Evidence Points Down, Not Up
DORA has been measuring software delivery for over a decade. One of its core capabilities is loosely coupled teams, and the definition is blunt: teams make large-scale changes to the design of their systems without permission from anyone outside the team and without depending on other teams. DORA links this to delivery performance, along with job satisfaction and a greater appetite for experiment.
Read the permission clause once more. Not "with lightweight approval". Not "via the architecture review board". Without permission.
Our industry has run the opposite experiment at enormous scale, and the results are sitting on the invoice. Pendo studied feature usage across hundreds of software products and found 80 percent of features in the average product are rarely or never used. Twelve percent of features drive 80 percent of daily usage. Public cloud companies poured up to $29.5 billion into features nobody touches.
Every one of those dead features had a plan behind it. A slide. A business case. A confident owner with a title and a forecast. What they lacked was proximity... to the customer, and to the code.
"Then It Would Be Chaos"
This is the objection I hear every time, and I understand where it comes from. Hand the plan to fifteen teams and you get fifteen plans, four languages, three message brokers and a bill from a vendor nobody vetted.
Autonomy without a mechanism is abandonment. The mechanism has a name.
The advice process: anyone makes any decision they need, on one condition. They seek advice from everyone meaningfully affected and from anyone with real expertise, then record the decision publicly along with the reasoning. Nobody holds a veto. Nobody skips the conversation either.
Pair it with architecture decision records. One short document per decision: the context, the choice, the consequences. One team wrote up five years of running this way, and more than 200 records. Their conclusion: mandatory consultation with transparent documentation beats an approval hierarchy.
The architect role survives all of this. It changes shape. The architect stops guarding a gate and starts working as a conduit between teams, spotting the connections and the collisions individual teams miss. Better job, honestly. Fewer meetings about whether someone is allowed to use Postgres.
Five Moves to Hand Over the Pen
Publish constraints, not features. The budget, the latency target, the compliance boundary, the headcount, the date. Constraints are the leadership job. The feature list is not.
Delete the approval step. Keep the advice step. Every approval gate you own is a queue with your name on it. Measure how long decisions sit in it before you defend it.
Write decisions down, not upward. An ADR in the repo beats a status update in a slide. Future you will thank present you around month eighteen.
Fund teams, not projects. Project funding forces someone senior to specify the work in advance, which is where a fat slice of those dead features come from. Fund a durable team against an outcome and let them find the work.
Ask the team to write next quarter's plan. Then ship what they wrote. This is the whole article in one sentence, and it is the step most leaders skip.
What Leaders Still Own
None of this fires the leadership team. It moves them.
You still own direction. You still own the constraints, the customer, the money, and the unglamorous work of clearing the blockers your teams have no power to move themselves.
You still own saying no to work outside the boundary. Saying no is real leadership work, and hardly anyone does it well.
My own research on bad bosses found 99.5 percent of respondents had experienced one or more types of bad boss. Almost nobody escapes. The behavior sitting underneath the worst of them is a refusal to let go of decisions they have no business holding. I wrote more about the patterns over at Step It Up HR.
Control feels like leadership. It is mostly fear with a calendar invite.
Cross It Off
Open your current roadmap. Cross off every item no engineer asked for and no customer requested. Look at what survives.
If the surviving list is short, you have your answer about who should be writing next quarter's plan. Give them the pen.