How to Ship Large Initiatives at Tech Companies

“Who owns Custom Statuses?”

I asked this in a planning meeting at Zendesk. Six people looked at each other. Nobody answered.

Customers had been asking for this feature for eleven years. They’d been relying on a buggy third-party plugin to build workflows that suited their needs.

Every core ticketing team agreed it mattered. Product had it on every roadmap. But the work touched so many systems that no single team could build it, and no single team wanted to be responsible when it broke something.

We shipped it eventually. We also broke search badly, and tickets stopped appearing in views.

Here’s what I learned about shipping work that no single team can own.

The Problem Nobody Wants to Own

When something has been on the roadmap for years, you’d think the issue is prioritization. It’s not.

Our ticketing system was a Rails monolith that had been growing since Zendesk’s early days. Changing how ticket statuses worked meant changing how notifications worked, how search worked, how views worked, how integrations worked. Twelve teams each owned a piece. None of them owned enough to ship it alone.

Every quarter, some team would put it on their roadmap. Then they’d realize they needed three other teams to ship their dependencies first. Those teams had their own priorities. The work would slip.

This pattern continued for two years before customer churn forced us to deal with it.

A Framework for Shipping Cross-Team Initiatives

I’ve since applied variations of this approach to other large initiatives. The specifics change, but the principles hold. Here’s what works.

1. Get Executive Alignment First

If leadership isn’t aligned, teams will deprioritize your initiative. They have roadmaps, OKRs, and their manager’s expectations. Without executive air cover, your initiative dies in committee.

You need a company-wide priority signal that makes clear this work takes precedence. VPs need to agree. When conflicts arise, teams need to know which way the decision goes.

2. Find the People Who Feel the Pain

Don’t start by assigning owners. Start by finding the teams who already live with the problem.

Some teams feel customer pain more than others. They handle support escalations. They hear complaints on customer calls. They see the workarounds users have built.

At Zendesk, the teams closest to enterprise customers felt Custom Statuses most. They became the core of the initiative.

3. Map Dependencies Before You Build the Roadmap

This is where most cross-team initiatives fall apart.

Teams start work in parallel, then discover they’re blocked on each other. Or they ship something that breaks another team’s component because nobody mapped the interactions.

Before you roadmap anything: what work unlocks other work? Which teams are on the critical path? Where are the integration points?

Once you have the map, phase your releases. Early access programs help you validate as you go. Don’t try to ship everything at once, that’s how you break search and have tickets disappear from views.

4. Shared Context, Autonomous Execution

You need coordination across teams, but you can’t micromanage twelve teams through one project plan. Engineers hate it, and it doesn’t work anyway.

Set clear objectives and communicate constraints, then let teams figure out how to execute. Engineers hate being micromanaged through a master project plan, and it doesn’t work anyway.

Here is good read on Aligned Autonomy, which explains the framework many large organizations use.

5. Build Recovery Infrastructure First

You will break things.

Before you ship anything, build the recovery infrastructure: feature flags to roll back quickly, monitoring to detect problems, rollback paths that actually work. Test your rollback before you need it.

When search broke during our Custom Statuses rollout, we didn’t have a clean way to revert. The fix took longer than it should have because we were building recovery tools during the incident.

Have a plan for getting the right people together quickly when something goes wrong. A war room setup helps you make decisions fast when you need to.

6. Feedback Loops

Be ready to change your approach. Teams will find problems you didn’t anticipate. Early access customers will use the feature in ways you didn’t expect.

Build feedback into the process: regular check-ins with teams, input from early access customers, monitoring that catches problems before users report them.

7. The Humans in the Middle

Cross-team initiatives need people who keep everyone aligned (surfacing blockers, solving problems that span team boundaries).

A good program manager is gold here. Not as a project tracker, but as someone who holds context across all the pieces. We ran regular sessions where reps from each team worked through problems together.

Closing Thoughts

There are formal frameworks for organizational change (Kotter’s 8 steps, SAFe, and others). They have value for large transformations.

Frameworks give you a path, but principles keep you consistent: get alignment, find your coalition, map dependencies, communicate often, build recovery paths, stay flexible.

The work that nobody owns is often the most important work in the company. It sits in the gaps between teams, waiting for someone to step into the middle and make it happen.

Further Reading

• Leading Change: Why Transformation Efforts Fail: John Kotter’s foundational 1995 HBR article on why organizational change fails. The eight-step model originated here.

• Cross-functional Alignment with OKRs: November 2021 piece on using OKRs to coordinate dependencies across teams.

• Eliminate Dependencies, Don’t Manage Them: Scrum.org article arguing for architectural and organizational changes over dependency management theater.