Lessons from Fixing Delivery Challenges in Large Organisations

Lately, I've been chatting with a few big organisations about delivery challenges - and one of the most common questions I get is: "How do we fix our delivery issues?" It's a great question, but there's never a simple answer.

Every company is different, but over the years, I've seen some patterns that separate the teams who move fast and deliver real impact from the ones constantly battling delays. Some lessons I've learned the hard way:

1. Great people want to work with great people

This one's huge. Your best people will leave if they feel like they're carrying low performers. Setting high standards isn't about being ruthless - it's about creating an environment where everyone pushes each other to do their best work.

2. Project thinking to product thinking

Most teams are stuck in project mode - scope locked in, deadlines locked in, "just get it done." But the best teams operate like a continuous product engine. They ship, learn, and adapt in real-time - because the market doesn't care about your roadmap, it cares about what actually works.

3. Small teams, big impact

One of the fastest ways to slow things down? Big teams. I've seen time and time again that small, cross-functional squads with clear ownership move 10x faster than large teams with too many handoffs.

4. Alignment first, then execution

Most companies think they have a speed problem. What they really have is a clarity problem. Before worrying about "how fast are we going?" - ask: Why does this matter? What is the real priority? How do we get there in the simplest way? When this is clear, execution takes care of itself.

5. Use an objective-driven framework

I don't care if it's OKR (Objectives & Key Results) or NCT (Narratives, Commitments, Tasks) - the goal is the same: give teams clear, measurable outcomes to chase. Otherwise, you're just shipping features with no strategy.

6. Break down silos with shared goals

Some of the best transformations I've seen came from simply getting marketing, product, and engineering to own the same outcomes. It's amazing what happens when teams stop thinking about "my project" and start thinking about "our goal."

7. Fake it before you make it

Most ideas don't fail because they're bad - they fail because they're built too soon, too big, and with too many assumptions. Test the smallest possible version first. If no one cares, congrats, you just saved millions in dev costs.

---

At the end of the day, fixing delivery isn't about hiring more people, pushing harder, or adding more process. It's about creating the right environment where teams can move fast, learn fast, and stay focused on what matters.