The wrong side of Pareto
Sunday, April 12, 2026
On impact, value, and what data analytics work actually looks like in mature data functions.
Job hunting forces you into a ritual. You take every project you have ever touched and make it sound like it moved mountains. Quantify the impact. Show the value. "Improved manufacturing efficiency by 10%." "Reduced reporting time by 30%." "Saved X hours per week."
I have been doing this : editing every cover letter, adapting my CV for each role. And somewhere in that process, I realised the framework for measuring impact is broken.
The easy wins are gone
In most mature data functions, the low-hanging fruit has been picked. The first analyst who walked in and built a dashboard from nothing: transformative. The team that automated the monthly reporting that used to take three days: game-changing. Those were left-side-of-the-Pareto projects: high impact, low effort, visible results. Easy to put on a resume.
Those projects are real. I have done them. But they represent maybe a quarter of my career. The rest is on the right side of the pareto: scraping incremental value in organisations that have already done the obvious things, where even the form of a report matters as much as the numbers inside it.
Sometimes you drive a fast sports car on an open road. You feel it. The acceleration is obvious, the distance covered is measurable. But most of the time, you are going from point A to B in dense end-of-day traffic.
Different skill set. Different kind of discipline. And delivering consistently in traffic: without drama, without anyone noticing, is also valuable. It is also impactful. We just don't have good language for it.
So what does delivering in heavy traffic actually look like?
1. Telling the business something true about itself
I have lost count of the conversations that go like this: a stakeholder is absolutely certain about how their process works.
Completely certain.
And the data shows something different: not marginally different, but fundamentally different.
"This never happens."
Except it does.
Regularly.
This kind of work upgrades the mental model the business operates with. Better decisions follow, sometimes immediately, sometimes over months.
But you can't draw a straight line from that conversation to a revenue figure.
So we self-censor.
No number, no bullet point.
The work disappears from our resume, because we have stopped believing it counts.
2. Non-heroic reliability
The most valuable systems are the ones nobody talks about.
They just run.
No emergency calls on weekends, no heroic saves at 2am.
This is an achievement that actively erases its own evidence: if it works perfectly, there is nothing to point to.
We celebrate the engineer who saved the day. We don't celebrate the one who built something that never needed saving.
The absence of heroics is the achievement.
But you cannot put the absence of an incident on a resume.
3. Boring architecture
This follows directly from the previous point, but it deserves its own space because the failure mode is different, and sadly, more common.
The analyst or engineer who builds whatever is asked, no questions, no pushback, looks productive.
They say yes to every whim, prop up flimsy solutions, and keep themselves busy.
In a sprint review, they shine.
What they leave behind is tech debt, maintenance burden, and systems that need constant heroic intervention to survive.
The one who asks "do we actually need this?", who pushes back, who advocates for the simplest solution that solves the actual problem, looks obstructive. They are the ones who create real assets: things worth the effort to build, and worth the effort to maintain.
This discipline has a political cost. Asking why is rarely popular. But it is the difference between building a company's infrastructure and building your own job security at the company's expense.
Saying no doesn't show up in a sprint report. Neither does the debt you prevented.
4. Delivery is not adoption
The graveyard of analytics work is full of dashboards that were technically excellent and functionally ignored.
Getting operational stakeholders to genuinely adopt something, to change how they actually make decisions day to day, is hard, underrated, and nearly impossible to quantify.
It requires understanding how they think, what they trust, and what would make them open a report every Monday morning instead of once and never again.
There is no metric for the dashboard that changed a Monday morning routine.
5. Making yourself redundant
The highest version of adoption is when they no longer need you. Not because the work was trivial, but because you transferred capability.
Part of my work has been generating genuine enthusiasm in business users for their own data: getting them curious, getting them comfortable interpreting data and anchoring decisions in it.
Sometimes this meant building something, teaching people to use it, and watching them run with it independently.
Making yourself redundant is the best outcome and the hardest to put in a resume.
***
The job market rewards impact theater. Clean numbers, bold claims. It's time to stop pretending we are all driving sports cars. Most of us are going from A to B in dense traffic.
So here is the test I now apply to my projects.
If the answer to any of these is yes, it counts. It goes in. Number or no number.
- Did this make something more stable: a system, a process, a report that just runs?
- Did it change how someone thinks or works: a decision made differently, a mental model upgraded, a dashboard that actually gets opened?
- Did it make someone more capable without me: a team that adopted the tools and the data mindset, and moved forward on their own?
So from now on, here is what goes on my resume.
The system that ran for two years without a single incident.
The stakeholder who changed how they made decisions.
The team that no longer needs me.
No percentages. No claims. Just the work.
No comments yet
Join The Simplicity Stack
The unactionable newsletter. For people tired of doing everything.