Skip to main content

Command Palette

Search for a command to run...

What platform and enablement work taught me about leverage

Published
2 min read
A

I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.

I once worked at a business where multiple teams needed to process payments across different journeys. We enforced a payment framework for teams to follow.

Due to limited flexibility, product teams built workarounds to accommodate their workflows. We ended up with 5 different currency conversion endpoints.

This created a nightmare: reconciliation problems, treasury headaches, hours of repetitive work at month-end, not just for product teams, but for colleagues in finance as well.

The solution was enablement, not more enforcement.

We spun out a new payment microservice that teams could plug into. With that one piece of work, we eliminated 5 currency conversions, removed grunt work, and unblocked teams to be more productive.

The hidden advantage: the shared microservice let us proxy-enforce the framework without teams feeling constrained.

That experience changed how I think about leverage.

Before working on platforms, I thought leverage came from scope.

More users. Bigger products. Larger teams.

Platform work taught me leverage is something else entirely.

Leverage is about how many outcomes a single decision can influence, not how visible that decision is.

In feature work, impact tends to be linear. You ship something, it affects a specific user journey, then you move to the next problem.

In platform work, the relationship is exponential:

  • One decision can unblock multiple teams

  • A small improvement compounds across products

  • The same constraint affects everyone until it's removed

The trade-off is visibility.

Platform work rarely has a clean launch moment. Success is measured in what doesn't happen:

  • Fewer workarounds

  • Less duplication

  • Teams moving faster without noticing why

That can be uncomfortable, especially in organisations that reward shipping over system health.

Another lesson is that leverage often comes from saying no.

Not every request should be supported. Not every use case belongs on the platform. Strong enablement work creates clarity as much as capability.

The biggest shift for me was realising that leverage isn't about doing more work.

It's about doing the work that makes other work easier.

Once you see that, it's hard to unsee.

Leverage compounds quietly.

Platforms succeed when teams stop thinking about them.

More from this blog

L

Leverage Points - Product & Tech

39 posts

Insights on product strategy, platform thinking, and career decisions that create disproportionate impact. For PMs who want to understand where effort matters most.