I’ve always had a habit of pulling things apart to understand how they work. Not just the thing itself, but what's happening around it. Why does it behave the way it does and what influences it that isn't immediately obvious. That instinct is something that I’ve carried with me into product.
Early in my career, I focused on shipping features, improvements, and solving what looked like the problem in front of me. But after a while, a pattern kept showing up. Great engineers and designers doing solid work, but things still felt harder than they should be.
These days, I spend less time looking at the work itself, and more time looking at how the work happens. How decisions get made, where things slow down, and why issues tend to show up when they are most expensive to fix. Because that's usually where the real leverage is. Most teams don't have a delivery problem; they have a flow problem.
From the outside, things can look fine. Inside, it’s a different story. Decisions happen a bit too late. Work loops back when it shouldn’t. Too much is in motion at once.
For a while, I thought this came down to planning or clarity, but it was a flow problem. When too much is in motion, and key decisions are left late, the system creates exactly what you'd expect: rework, interruptions, and a constant sense of catching up.
What’s worked better for me is treating flow as something you can actually shape. To pull decisions forward, reduce how much is happening at once, and create clearer moments where work is challenged early.
They aren't big changes, but they compound. Work becomes more predictable, the noise drops, and teams get the space to actually do the job well.
The hardest decisions usually aren't about the solution. Some of the most persistent blockers I have seen are not technical but are decision problems.
Everyone has a reasonable view, no one is clearly wrong, but nothing moves. Those situations used to frustrate me more than they should have because it feels like you’re stuck on something that should be solvable.
What I've learned is that better arguments rarely fix it—better framing does. Instead of asking what the right answer is, I bring it back to what it costs to wait. That shift changes the conversation; it turns opinion into trade-offs. You do not always get perfect alignment, but you get movement. And in most environments, momentum matters more than precision.
When nothing changes, it is telling you something. If something goes out and nothing happens, I don’t treat that as neutral; it is a signal. Especially in optimisation work, where everything can look correct on paper.
In one case, we realised we had built an AI-driven optimisation that was technically sound, but too constrained to have real impact. The safeguards were working, but just a bit too well.
That changed how I approached these systems. The question stopped being whether it was working, and became how much room it had to move. Because value rarely sits in the safest version of a system. It sits closer to the edge, just before the risk outweighs the benefit. The job is knowing where that line is, and adjusting with intent.
Most problems aren't isolated; they are produced by the system around them. So that is where I focus: how work flows, how decisions are made, and how risk is handled when things aren't clear. Get that right, and a lot of the usual problems don't disappear, but they do become far more manageable. And that is usually what separates teams that struggle from teams that scale.