For the past two years, I taught that data utilization rate and ROI were the right anchor KPIs for a data operation’s success layer. Utilization tells you how efficiently the data is being used. ROI tells you what you’re getting back. Both sound defensible. Both sounded defensible to me when I was building the original Vision Board framework.

They’re wrong. And this session is about why and what replaces them.

What the Success Layer Is Actually For

If you’ve been following the Vision Board series, you know we’ve covered the Present Layer, where the organization is today, what it’s costing in FTE Debt, what’s working, and what isn’t. Then the Future Layer, where we define the capabilities the organization needs to build over three years, and how PCU and FTE Debt help us choose between competing options.

The Success Layer is the third and final piece. Its job is to answer one question: how do we know we’re moving from the present toward the future?

Read more

This Week’s Live Session

In Monday’s live session, I walked through how the Present Layer of the Data Ecosystem Vision Board has evolved inside the Impact Operations system, and why the original version, while correct, was missing its instruments.

The newsletter below adds the framework precision the live format naturally drifts from. Watch first, or read first. Both work.

The CEO Who Had Ten Analysts and Waited Four Days for an Answer

I walked into a gaming company that had just finished a portfolio-wide analytics standardization project.

On paper, they had solved fragmentation. Dashboards unified, reporting consistent, everyone on the same platform. The CEO expected decision speed to improve.

Instead, he was waiting an average of four days for answers to basic business questions. He had ten data analysts on payroll.

When we ran the Present Layer audit, here is what we found: four of those ten analysts were spending the majority of their time maintaining shadow dashboards that had emerged after the standardization project. The six left were in capacity of 40-50% only. The product teams did not trust the centralized dashboards for operational decisions, so they built their own using the GA data. The analysts, hired to produce insight, had become shadow infrastructure maintenance engineers.

Nobody decided this was a good use of their time. It happened because the official system stopped serving the people who needed to make real decisions.

The CEO’s framing of the problem was: “Why is my data team slow?”

The actual problem was: he had never seen the real picture of his present state.

Read more

Reading guide: 15 min | Framework: 10 min | Examples: 5 min

Part 2 Preview: Implementation toolkit, workshop guide, connection to Triangle Strategy

Before You Begin

Take 60 seconds to think about your last strategic planning session.

When your team talked about “what we need to build,” did everyone leave with the same mental picture? Or did the marketing lead imagine one thing, the engineering lead another, and you something entirely different?

Write down: One capability your team agreed to build. Now ask yourself: Could you explain to a new hire exactly when that capability would be “done”?

Keep that example in mind. We’ll come back to it.

The Vision Board: What It’s Supposed to Do

The Data Ecosystem Vision Board has three layers:

Present Layer: Where you are today (users, gaps, capabilities, costs)
Future Layer: Where you’re going in three years (capabilities that will exist)
Success Metrics: How you measure progress (KPIs, principles, change management)

The Future Layer should be your north star - the capabilities that will exist in three years that don’t exist today. It’s the piece that should give strategic direction. The anchor that prevents your team from drifting into firefighting mode.

At least, that’s what it’s supposed to do.

I Noticed Something Going Wrong

It’s Tuesday afternoon, October 2025. The last Data Ecosystem Vision Board workshop of the year. We’re three hours in with the data leadership team and C-level. Everyone’s engaged, sticky notes are flowing, and the energy is good.

We’re in the Future Layer. Everyone’s writing capabilities paint the picture of where the data ecosystem will be in three years.

The CPO writes on the whiteboard: “Real-time analytics capability.”

Heads nod around the room. I write it down. It feels strategic. It sounds important.

Then I ask: “What does ‘done’ look like for this capability?”

Silence.

I try again: “When should we start building this? Can we wait until 2028?”

More silence. The marketing analyst finally says, “Well, marketing needs it soon for campaigns, but engineering probably needs different real-time stuff...”

I’ve hit the wall. The same wall I’ve hit in dozens of workshops.

The word “capability” is too abstract. Everyone thinks they understand it. No one actually does.

Read more

I had a different idea for the #20th edition of Data Flavors. However, a discussion with , about the two sides of data leadership changed my momentum.

John argues that data leadership has two distinct parts:

• Internal leadership: How you run the work and people, backlog structure, priority decisions, mentoring, and setting “good enough” standards. When this is weak, teams live in fire-drill mode. Everyone’s busy, but nobody can explain what moved the business.

• External leadership: How you show up in the wider organization, positioning analytics with peers, which problems you take on, and ensuring data work actually changes decisions. When this is weak, your team becomes a well-run service desk nobody listens to.

But as I looked closer at the teams I work with, I realized the Internal part is being swallowed by a “Bermuda Triangle,” a dead zone where the connection between technical code and business vision simply vanishes.

To understand why, we have to look at the two roles we expect to lead us, and the structural paradoxes that are currently breaking them.

The Bermuda Triangle of Data Teams

In the North Atlantic, the Bermuda Triangle is a “dead zone” where ships and planes famously disappear. In data organizations, a similar phenomenon occurs in the structural void between the Strategist (who defines the What) and the Architect (who defines the technical How).

The Lead Paradox: The Internal Failure

The Lead Paradox describes a structural failure where leadership interventions intended to stabilize a team actually become the primary drivers of inefficiency and burnout. In geochemistry, the “Lead Paradox” refers to a mismatch between expected radioactive decay and observed signatures. In data, it’s the mismatch between your team’s high-cost talent and their low-impact output.

Without a shared “Language of Capacity,” the Team Lead is forced into two specific failure modes:

The Psychologist Trap (Emotional Shock Absorption)

This occurs when a team has no objective way to communicate workload limits.

• The Mechanism: The Lead becomes an “emotional shock absorber” for upstream failures, like sales over-promising or product shifts.

• The Cost: Energy allocation becomes a zero-sum game. When energy is spent on emotional labor Eemotional approaches 80%, it leaves virtually no bandwidth for strategic Direction or operational rhythm Operations.

• The Result: The team is “redlining,” operating at maximum RPM without the cooling effect of a structured process. Stability is tied to the Lead’s ability to listen, not the team’s ability to self-regulate.

The Solution Signer Trap (The Technical Bottleneck)

This occurs when a Lead asserts themselves as the “ultimate technical authority” to resolve friction.

• The Mechanism: When Product pushes for speed and Engineers push for perfection, the Lead steps in to make the final technical call.

• The Cost: This pulls the Lead into the “technical weeds.” By focusing on the content of solutions rather than the process of decision-making, they fail to establish a sustainable rhythm.

• The Result: Engineers stop developing consensus-building skills because they know the Lead will eventually “sign off.” The Lead becomes a single point of failure and a scaling bottleneck.

“The expected output of a high-functioning team, efficiency, innovation, and technical excellence, is undermined by the very leadership behaviors meant to ensure them.”

The PM Paradox: The External Failure

If the Lead is the Architect of the Code, the PM is the Strategist of the Vision. Their mandate is the “External” frame: aligning the product with the “North Star.” But here, a separate, equally dangerous disequilibrium occurs.

The Ontological Duality

The Architect focuses on Verification (does the system conform to specs?), while the Strategist focuses on Validation (does the scope satisfy the stakeholder?). The PM Paradox arises when the Strategist fails to internalize the Architect’s constraints.

The Stakeholder Trap (The Requirement Vacuum)

Because the PM often lacks visibility into the “Execution How,” they default to the Requirement Gatherer persona.

• The Mechanism: The PM becomes a “Requirement Vacuum,” sucking in every executive whim to appease the external organization.

• The FLICC Fallacy: PMs are inundated with stakeholder demands built on “Impossible Expectations” and “Cherry-picked Data.” Without a Language of Capacity, they cannot debunk these fallacies.

• The Silent Mode Death Spiral: To manage the pressure, the PM promises results. The team, unable to push back, enters “Silent Mode” for weeks. By the time they emerge, market conditions have shifted, and the brilliant technical solution no longer matches the business need.

“A PM who prioritizes the ‘External’ scoreboard at the expense of ‘Internal’ integrity is fundamentally undermining the product’s long-term viability.”

The Missing Link: Why Both Roles Are Failing

The Lead is hand-tuning the engine valves (Internal). The PM is arguing with air traffic control (External). But no one is looking at the navigation instruments, the fuel levels, the wind speed, or the sustainable flight rhythm.

This is where the “Bermuda Triangle” exists. We have the Architect (Lead) buried in the code, and the Strategist (PM) buried in the stakeholders.

Neither of them is flying the plane.

The Architect is hand-tuning the engine valves. The Strategist is arguing with air traffic control. But no one is looking at the navigation instruments, the fuel levels, or the flight rhythm. This is the Operator function.

Why This is a Catastrophe (The Data)

When the Operator is missing, the “Bermuda Triangle” swallows your ROI. The research confirms it:

• 87% of projects never reach production.

• 97% of data engineers report burnout.

• 85% of projects fail to deliver a measurable ROI.

It is not a technical problem. It is an operational problem. We keep buying better “engines” (Modern Data Stacks), but we don’t have anyone sitting in the driver’s seat managing the “transmission.”

The Question for 2026: Who Owns the Rhythm?

This is where I’m genuinely stuck. If the Team Lead is drowning in emotional labor and the PM is overwhelmed by stakeholder requests, where does operational leadership emerge?

• Can the Team Lead evolve? They would have to shift from being a “Solution Signer” to an “Operator.” They would have to stop caring about the code and start caring about the system that produces the code.

• Can the PM evolve? They would need “Product Ops” skills, process design, workflow coordination, and capacity protection, which are rarely taught in traditional PM training.

• Do we need a new role? At Idealo, our non-technical leads acted as Operators. They couldn’t dive into the technical weeds, so they had to focus on the rhythm. Was that the secret?

What I’m asking you:

1. Leads: Are you tired of being a high-paid psychologist?

2. PMs: Are you tired of promising outcomes that the internal “redlining” prevents you from delivering?

3. Everyone: Who in your organization actually owns the “Language of Capacity”?

Share your thoughts in the comments. Let’s find a way to move the life raft from the shore into the water.

Further Reading:

• What Does Data Leadership Actually Mean? - John Cook’s framework on internal vs. external leadership

• Why So Many Data Science Projects Fail to Deliver - MIT Sloan on organizational vs. technical failures

• Beyond the Hype: Data Teams Have a Burnout Problem - Ben Rogojan on the emotional toll of invisible work

• Product Ops Overview - Marty Cagan on when Product Ops helps vs. fragments teams

Read more

Three years ago, I watched a brilliant team drown.

Not slowly. Not quietly. Publicly, painfully, with everyone watching.

The Director saw it. The stakeholders saw it. I saw it. Most importantly, the team saw it.

But none of us could stop it.

They kept pushing. “If we just finish this migration...” Migration finished. Still drowning. “If we just ship this dashboard...” Dashboard shipped. Still underwater.

I tried to help. I said “you’re drowning,” but they couldn’t hear me. They were too busy trying to stay above water for one more breath.

The real problem? None of us had the language to describe what was actually happening.

They thought their cadence would save them (daily standups, sprint planning, retrospectives, demos). What they needed was rhythm: the ability to stop, assess, and completely change direction.

Read more

Take 60 seconds and think about your data team’s last month:

• How many hours did you spend firefighting versus building?

• How many “urgent” requests interrupted planned work?

• What strategic initiative got delayed again?

Write down the percentage: ___% firefighting vs ___% strategic work

Keep this number. We’ll come back to it.

The Pattern I Keep Seeing

It’s 3:47 PM on a Tuesday. Your team finally carved out time to work on that analytics platform everyone’s been waiting for. The calendar is blocked. The energy is there. Everyone’s ready.

Then Slack lights up.

Dashboard broken. Pipeline failed. The CFO needs numbers by 5 PM, which are different from yesterday’s numbers. And somehow, they don’t match what Marketing reported.

By Thursday, that strategic project is still sitting exactly where it was Tuesday morning. Untouched.

By quarter-end, you’re explaining again why the “game-changing initiative” is now Q2. Maybe Q3.

Here’s what research shows: Data teams spend 50-70% of their time firefighting. But here’s what’s worse - almost nobody measures it. No cost calculation. No impact analysis. No strategic response.

Just exhaustion, frustration, and the slow erosion of team morale.

What We Actually Built This Year

When I started writing in January 2025, I wasn’t sure how to address this systematically. The problem felt too big, too entrenched, too... everywhere.

So I did what data people do: I broke it down into components.

We explored the where and what (Data Ecosystem Vision Board). We tackled the how (Data Strategy Triangle). We refined what to measure (The 5 W’s of KPIs).

But recently, talking with readers who’ve followed the journey all year, I realized something:

We weren’t just building frameworks. We were building a complete operating system.

Let me introduce what you’ve been learning all year:

Impact Operations for Data Teams

This isn’t a new word for “process.” It’s not rebranded data governance or data mesh principles.

Impact Operations is an integrated system designed to address where traditional delivery models break down in data work.

It has three reinforcing layers:

1. The Philosophy: Wabi-Sabi (Intentional Imperfection)

In engineering, bugs are failures.
In data, waiting for perfection is often the real failure.

Wabi-Sabi is the operating principle that accepts imperfection in the service of momentum and relevance. It allows teams to say:

“We will ship this ROI analysis with 60% confidence today, rather than 95% confidence next year, after the decision has already been made.”

This isn’t cultural fluff. It’s an execution constraint that shapes how decisions are made under uncertainty.

2. The Signal: Cooking Data Stress Index (CDSI)

Traditional delivery models optimize for output (velocity, story points, features shipped).

Impact Operations optimizes for system health.

The CDSI measures team stress not as a soft concern, but as a leading indicator of structural failure.

Three operating zones:

• Zone 1 (Dysfunctional): High stress, reactive work, fragile delivery

• Zone 2 (Mature): Controlled stress, sustained impact

• Zone 3 (Overextended): High ambition, unstable execution

If you don’t measure stress in the system, you cannot predict when the impact will collapse.

3. The Engine: Rhythm (Not Cadence)

Cadence is doing standups because it’s Tuesday at 10:00.

Rhythm is changing priorities because the market, strategy, or constraints have changed.

Impact Operations replaces rigid delivery schedules with a Rhythm of Impact:

• Strategy is revisited when assumptions shift

• Capacity is rebalanced when stress signals rise

• Execution adapts without falling into chaos

Rhythm governs when the system moves and why.

How The Frameworks Connect

Look back at that percentage you wrote down. That’s your current operating reality.

Now let’s see how the frameworks you learned this year form a complete system:

The Vision Board answers: Where are we going? What do we need to build?

• Creates strategic alignment

• Defines capabilities needed

• Sets 3-year direction

The Strategy Triangle answers: How do we balance the work?

• Maintenance (keep things running)

• Innovation (explore new capabilities)

• Roll-out (deliver value)

The 5 W’s of KPIs answer: What tells us we’re winning?

• Why we measure

• What actions result

• Where impact happens

• When to check

• Who owns it

Together, they form Impact Operations:

Vision Board (Direction) 
    ↓
Strategy Triangle (Execution Balance)
    ↓
5 W's (Impact Measurement)
    ↓
CDSI (System Health Signal)
    ↓
Wabi-Sabi (Decision Philosophy)
    ↓
Rhythm (Adaptive Movement)

This isn’t theory. This is how you move from 70% firefighting to 30%.

Not by working harder. By operating differently.

Where You Are Now

If you’ve been reading all year, you’ve evolved from:

January 2025: “We need a better data strategy, but everything feels theoretical...”

December 2025: “I have frameworks I can implement Monday morning, tools to diagnose team health, and a system to measure what matters.”

The shift wasn’t just philosophical to tactical.

It was from inspiration to implementation. From frameworks to operating systems.

You now have:

• ✅ The Initiative Priority Calculator (know what to work on)

• ✅ The Team Stress formula (predict collapse before it happens)

• ✅ The Vision Board process (create 3-year direction)

• ✅ The Triangle method (balance your work)

• ✅ The 5 W’s framework (measure impact, not activity)

More importantly, you understand how they connect.

What’s Coming in 2026

On January 7th, I’ll publish the formal introduction to Impact Operations, the complete methodology with diagnostic tools and implementation path.

But throughout 2026, we’re going deeper into the three questions that make this work:

Question 1: How do we connect the data mindset with Wabi-Sabi?

How do you make “intentional imperfection” a decision-making framework, not just a philosophy? When do you ship at 60% confidence versus waiting for 95%?

Question 2: How do we make things measurable and clear?

Beyond CDSI, what are the leading indicators of impact? How do you quantify the cost of firefighting? How do you measure rhythm versus cadence?

Question 3: How do we create a culture that follows rhythm, not cadence?

How do you build teams that adapt when assumptions change, rather than rigidly following a process? How do you make this sustainable?

Your Turn

Take 5 minutes right now:

1. Look at that firefighting percentage you wrote at the start

2. Calculate the cost: (Team size × Avg salary × % firefighting × 50 weeks)

3. Write down the number in euros/dollars/other

That’s what reactive mode costs you annually. Just in salary.

Now add:

• Delayed strategic initiatives

• Missed opportunities

• Team burnout and turnover

• Lost competitive advantage

The real cost is 3-5x that number.

Impact Operations is how you get that time back. That money back. That momentum is back.

One More Thing

This year wasn’t just about frameworks. It was about building something new together.

You sent feedback. You caught the math error in the Stress Index. You shared your implementation stories. You asked the questions that refined the methodology.

Impact Operations exists because you participated in creating it.

Thank you for being part of this journey.

2026 is when we go deeper. When we refine the discipline. When we help more teams move from reactive to strategic.

Subscribe now if you haven’t; next year will be worth it.

May your data flow with purpose,
Lior

P.S. Reply with your firefighting percentage. I’ll share how it compares to the 50-70% average and what that means for your next step.

Read more

Happy New Year, thank you for your support and for being paid users. This means the world to me, and I hope to see you around next year as well as we grow together.

Reading guide: 15 min total • One framework, one realization, one honest correction

Before You Begin

Take 60 seconds and think about the last time someone on your team said “just a quick thing...”

What was supposed to take 30 minutes? How long did it actually take? And here’s the question nobody asks: what else didn’t get done that day because of it?

Write these down. Not because I’m going to give you a worksheet, but because in five minutes you’re going to see your own patterns reflected at you, and it helps to have the specific memory fresh.

Read more

A one-week diagnostic that reveals where your team’s capacity actually goes versus where you think it goes. Most teams discover a 30-40% gap between belief and reality.

Read more

Hello, data Shokunin-deshi!

In my garden, there’s a ritual I practice every time I start seedlings. After planting, I check them at specific intervals: Day 3 for signs of germination, Day 7 for the appearance of the first true leaves, and Day 14 for transplant readiness. These aren’t arbitrary numbers; they’re carefully chosen checkpoints that reveal whether the seed is thriving or struggling.

Early in my gardening journey, I’d plant seeds and then wait weeks before checking. By the time I discovered problems, poor soil, incorrect depth, or pest damage, it was too late to adjust. I’d invested time, resources, and hope into plants that were doomed from the start.

Now, with my checkpoint system, I catch issues when they’re still correctable. Weak germination at Day 3? I can reseed immediately. Yellowing leaves at Day 7? I adjust nutrients before they become critical. Each checkpoint gives me the option to continue confidently, adjust my approach, or cut my losses early.

Most data teams operate like my early gardening days, they plant requirements, develop in isolation for months, and only discover problems at delivery. What they need is a validation rhythm that reveals issues while there’s still time to adjust.

📍 Where We Are in the Journey

This is part 2 of our Requirements to Relationships series. In part 1, we learned to understand stakeholder needs through the Dynamic Stakeholder Canvas. Today, we focus on validating those needs through rapid iteration. In part 3, we’ll explore immersion techniques, and in part 4, we’ll show how validated solutions connect to organizational adoption.

Canvas → 3-5-7 Validation ← YOU ARE HERE → Immersion → Strategic Adoption
(Understand) (Build right) (Deepen insight) (Deploy widely)

But first, let’s ensure you’re building the right thing.

Executive Summary

This edition shows how to replace long development cycles with fast validation loops through the 3-5-7 framework, a rhythm that keeps stakeholders engaged, proves value early, and aligns teams around measurable impact.

Read more

I apologize for the delay and appreciate your flexibility as we prioritize this major new project. The 3-minute reading of this article will be sent on Friday. In the meantime, you can catch up on the podcast here

Why Static Requirements Create Moving Problems

May 14, 2025 • Issue #13 • 15 minutes

Hello, data Shokunin-deshi!

Last November, as winter approached, I planted garlic cloves in our garden beds. For years, I’d followed traditional advice: “Plant in late fall, trust the process, harvest in summer.” But year after year, I’d lose 30-40% of my garlic between planting and harvesting. The uncertainty was frustrating; I’d plant, wait through winter, and only discover failures when it was too late to adjust.

This year, I changed my approach. I planted in September, early enough to see the green shoots establish before winter dormancy. Those visible signs gave me confidence that the underground work was happening. I could spot problems early, weak shoots that needed extra mulching, and areas where nothing emerged that required replanting.

The difference was remarkable: continuous feedback instead of blind faith.

Most data teams approach stakeholder requirements like my old garlic planting: capture once, develop in isolation, hope for the best. What they need is continuous validation that proves the solution is taking root.

Executive Summary

In this edition, we transform static requirements gathering into dynamic stakeholder partnerships by:

• ✅ Moving from feature requests to impact conversations using the seven essential questions framework

• ✅ Creating the Dynamic Stakeholder Canvas that evolves with business needs while maintaining focus

• ✅ Preventing $200K+ dashboard graveyard projects through continuous stakeholder validation

• ✅ Transforming data teams from order-takers into strategic business partners

Read more

Hello, data Shokunin-deshi!

A few years back, I sat across from a CTO who was beaming with pride about their "data-driven company." Whenever someone tells me they're data-driven, it raises red flags with a very high-pitched noise in my head. What does "data-driven" actually mean? Are you using data, or are you using the right data? Are you operating with excellence when it comes to leveraging it?

Executive Summary

In this edition, we transform your approach from data hoarding to data-centric thinking by:

• ✅ Applying the 5 W's framework to evaluate every piece of data before collection, not after

• ✅ Building a practical data decision framework that connects raw data to business impact

• ✅ Creating cost-aware data strategies that maximize signal while minimizing noise

• ✅ Implementing tools and processes that make data centricity the default organizational behavior

No framework artifact in this newsletter today, I am planning to share with the Figma board I use in the coming days, latest September 15.

👉 Not yet a premium member? Join now to access these exclusive implementation resources and accelerate your transformation.

Read more