Outfit: Scaling Delivery Without Losing the Plot

The Context

Outfit is a marketing automation platform. My role was to run the services arm: a delivery team responsible for 20+ enterprise clients across food and beverage, financial services, and education. When I joined, the team was three people. By the time I left, it was fifteen full-time across multiple timezones and fifteen external contractors.

That kind of growth sounds like a success story. It is, mostly. It's also an education in everything nobody warns you about.

What the Job Actually Was

The title was Customer Delivery Manager, later Delivery Lead. The actual job was more complicated than either title suggests.

On the surface: manage client relationships, run delivery, keep quality up and timelines honest. Lead standups, governance meetings, workshops. Migrate the team from Trello to Jira, introduce Zephyr for testing, build the processes that let a three-person team scale to thirty without the wheels coming off.

That part I expected.

What I didn't expect was the product problem.

Pandora

Here's the thing about running a delivery team inside a product company: your team's ability to do good work is upstream of the product. When the product roadmap isn't prioritising improvements that directly affect delivery quality, your team absorbs the friction. They slow down, work around limitations, improvise. And they start losing faith that things will get better.

The Outfit product roadmap, at certain points, wasn't moving fast enough in the directions my team needed. I could flag it. I did flag it. But the gap between flagging a problem and shipping a fix has its own timeline, and in the meantime, my team was still dealing with it every day.

So I built Pandora.

Pandora was an internal tool that gave the delivery team the ability to build and test product enhancements in the wild, ahead of official product cycles. It was a controlled workaround: not bypassing the product team, but generating real usage data and proving out improvements before they went into the formal roadmap. Proof of concept meets live environment. When something worked in Pandora, the case for prioritisation became a lot easier to make.

It kept the team moving. It built goodwill with the product team because we were coming with data, not just complaints. And it changed the relationship between delivery and product from reactive to collaborative.

What Scaling Actually Looked Like

Going from 3 to 15 full-time and 15 contractors isn't just a headcount story. It's a systems story.

Every process that worked informally at three people breaks at ten. Communication assumptions that felt obvious become sources of confusion across timezones. Quality standards that one person held in their head need to be written down, documented, and checked. The job became less about doing the work and more about building the conditions for other people to do the work well.

The operational frameworks I put in place weren't exciting. Governance structures, onboarding docs, capacity models, quality checklists. But they were the difference between a team that scaled and a team that fractured. By the time I joined the leadership team to contribute to strategic planning ahead of the 2022 acquisition, the delivery function was running cleanly enough that I could look up from the day-to-day and actually think about where the business was going.

What I'd Take From It

Delivery leadership is product leadership, whether or not the org chart says so. If you're close enough to clients and close enough to execution, you see the product problems before the product team does. The question is whether you build the trust and the tools to do something about it, or whether you just report upward and wait.

Pandora was the answer to that question, for me, in that context. The deeper lesson is that the most valuable thing you can do inside a system that moves slowly is find the lowest-friction way to generate evidence. Then use that evidence to move the system faster.

Outfit, Delivery Lead, 2018–2021