Frontline training & performance
Senior Analyst, Product & Operations
Operations, made legible.
Analysis and systems for people who run the parts of the business that don't show up on a slide.
The problems worth finding aren't hidden. They're the ones everyone stopped mentioning.
A diagram of six connected parts of any system: people, process, business, product, outcome and decision, arranged in a ring and cross-linked to each other. People feed process, process drives business, business builds product, product creates outcomes, outcomes inform decisions, and decisions change the conditions people experience next, completing the cycle. The less obvious cross-connections, such as business to outcome and process to decision, matter just as much as the obvious ones. Each point below can be selected to show how it connects to the rest.
Six parts of any system. The lines that matter aren't always the obvious ones.
Start here
What are you trying to make work better?
About
Nothing improves by accident.
Most systems don't fail loudly, they just quietly stop getting better. A process survives long after the reason for it is gone. A team keeps doing the workaround instead of fixing what needed the workaround in the first place.
I'm interested in the discipline underneath that: finding where a system stalled, working out what actually needs to change, and building whatever gets it growing again, a process, a decision, sometimes a product. Improvement isn't a phase. It's the job.
How I think
Six moves, roughly in this order.
-
Something feels slower, costlier, or more frustrating than it should be, and I don't yet know why.
For example: a support queue that's "just always been like this."
-
I ask why the current process exists at all, and whether the reason it started is still true.
For example: a step added for a rule that changed years ago, and nobody removed.
-
I map who actually touches the process, what they really do, not what the manual says, and where the friction sits.
For example: the workaround a team uses every day but never writes down.
-
Problems that look separate often share one root cause. I look for the pattern before I look for the fix.
For example: slow replies and repeat complaints, tracing back to the same missing handoff.
-
A rough, testable version beats a polished guess. I'd rather be wrong quickly than right slowly.
For example: a one-page workflow sketch before anyone builds a tool.
-
Most first attempts are partly wrong. The job is finding out which part, then adjusting.
For example: what a small pilot group actually did, compared to what was expected.
A short demonstration
Connect the thought.
Four things a business might notice separately. Pick at least two.
Case studies
Selected work.
These are still early. Say what caught your attention and I'll share what's actually there.
Ride-hailing driver readiness
DriveRight
Performance & accountability
Merava
Private gratitude, gamified
Yippie
Writing
Notes on operations, product, and building things properly.
Published when there's a real argument to make, not on a schedule.
Right now
- Building
- Products and systems shaped around how people actually work.
- Diagnosing
- The decisions, processes and incentives behind the visible problem.
- Testing
- Better ways forward through data, prototypes and real feedback.
Latest writing
A True Number Can Still Mislead You
The same twelve cancellations produce four different, correct percentages depending on who gets counted. Here's how eligibility, exposure, timing and weighting decide the answer.
Read article →Share your pain
What's not working?
Doesn't need to be polished. A sentence is enough. Vague is fine too.
Contact
Get in touch.
Email is the fastest way to reach me. The conversations worth having are usually about a real operating problem, not an introduction.