Ninety days later, 86% of the people whose names were in that kind of ownership column had not touched their goals once. That is not a casual observations. That is what a systematic review of how organizations track strategic goals actually found. And it describes the standard decay pattern, not the exception.

Data strategy failure is rarely dramatic. It doesn’t announce itself. It accumulates quietly, through structural failures that almost every strategy shares. I’ve been going deep into the research on this, governance frameworks, execution data, post-mortems from organizations that built strategies with genuine intention and watched them dissolve anyway. What strikes me is how consistently the evidence points to the same mechanisms. Not technical gaps. Organizational ones.

Here is what the autopsy shows.

The strategy was a shopping list, not a decision system

Dylan Miyake, co-founder of ClearPoint Strategy, analyzed 20,582 strategic plans and published one finding I keep returning to: plans with more than 60 elements succeed 8% of the time. Plans with fewer than 20 succeed 68% of the time.

The difference is not ambition or resources. It is whether the organization built in a mechanism for deciding what matters when reality interrupts, and reality always interrupts.

Most data strategies do not have that mechanism. They have a list. Attribution model, funnel visibility, customer segmentation, data quality framework, governance documentation, self-service analytics, AI pilots. The list grows through stakeholder alignment sessions and planning workshops. Every addition sounds reasonable in the room. Nobody builds in the logic for what happens when an incident consumes the team for three weeks, or when two initiatives collide with one team’s actual capacity.

Read more

George called on Tuesday morning. A call, not a message. George's messages.

“I need an hour. Bring Arjun.”

In the car, I ran through the scenarios. Christoph had been quiet for a while, the kind of quiet that means he’s forming a view without asking for my version. Werner sits on three other boards in this sector. Between them, they have enough pattern recognition to build a narrative about Stock Dropper that I have no visibility into.

I walked into George’s office already knowing what had moved.

What George said

Christoph, Jim, and Werner had been talking. The €400K incident wasn’t the issue by itself; Incidents happen at scale. The issue was the pattern. Three data incidents in one quarter. A leadership change that hadn’t yet produced visible results. A CEO running an outside engagement instead of demonstrating she could fix the function directly.

“They’re not threatening to walk,” George said. “They’re asking whether the Series C timeline should move. Six to nine months.”

Six months is not a schedule adjustment. It’s a different round, different terms, different dilution, different story about what happened in the gap.

“I need something for the next board conversation,” he said. “Not a roadmap. A number. What this function costs, what we’re getting for it, what structurally changes.”

He looked at Arjun when he said, “What structurally changes?”

Arjun said, “We can show you the cost. Right now.”

PCU lives in the room

Arjun pulled out a single sheet. He’d run the data quality framework through four components using Tina’s incident logs and the support notebooks she’d been keeping for two years.

He put it on the table without framing it. Let George read.

Base Cost: Compute, storage. Knowable. The number George had been approving.

Stability Cost: Incidents. Twelve over eighteen months, ranging from two hours to a full engineer-day. Arjun had priced each one at the fully-loaded hourly cost of a freelancer, not an abstract rate, but also not what reflects the business, the actual number, including benefits and overhead. The kind of number that belongs on a manufacturing downtime report.

The Stability Cost was larger than the Base Cost.

Support Cost: Recurring questions, same requests answered weekly. Two years of the team’s Jira. Consistent, predictable, invisible to George until this moment. But yet Arjun said it’s missing more data, which wasn’t logged, we have partial visibility.

Change Cost: Updates, scope additions. Lower than I expected. I’d read low change activity as stability. Arjun read it as calcification: a product not evolving to fit usage, while maintaining high Stability and Support costs beyond its useful architecture.

Total PCU-V for the data quality framework: significantly above the line item George had been approving quarterly.

George looked at it. He looked at it for a long time.

“That’s what I’ve been paying?”

“That’s what it costs,” Arjun said. “What you’ve been paying is the Base Cost. The rest comes out of the team’s hours without a label.”

I wrote a few notes while George was reading

Point 1: Tina’s notebooks are not an auditable source.

When Christoph asks where these numbers came from, and he will ask — the answer is “a two-year notebook an engineer kept without being asked to.” That is not a board-level answer. That is an answer that invites the follow-up: “Are there other notebooks you haven’t looked at yet? Other costs that aren’t in this number?”

Arjun: “An unaudited estimate beats a confident zero. Zero is the current state.”

I understand the argument. I’m not fully satisfied with it.

Point 2: The methodology manual calls first-cycle numbers “Low confidence by design.” Arjun has explained this. The starting point is directional, confidence builds with each operational cycle; This is the designed state, not a failure.

I hear this, and I know how a board receives “Low confidence.” Christoph doesn’t fund Low confidence. He funds conviction. If I walk into that room and the answer to “how reliable is this number?” is “first reading, directional, Low confidence by design,”
I have handed Werner the exact language he needs to put the timeline question back on the table.

Still open. Arjun says the alternative is no number. I say no number and Low confidence number look the same from Christoph’s chair.

George’s read

He didn’t ask about the methodology. He asked something different.

“This number, why wasn’t it in the Q3 review?”

He said it quietly. Not accusatory. The way George asks questions is when he already knows the answer and needs to hear you say it.

“Because we didn’t have the instrument,” I said.

He wrote something. Then: “Who is responsible for the absence of the instrument?”

We both knew the answer. I built the portfolio. He approved the quarterly reviews. The absence of PCU-V implicates both of us. He wasn’t asking to assign blame. He was calculating what Christoph would do with that answer if it came up in the board call.

He put the pen down. “I need to pre-brief Christoph before he sees this. With or without you.”

“With,” I said.

“Then we have ten days.”

Werner’s question, I wrote it out in my notebook that night

I know what Werner is going to ask. I’ve been in enough investor conversations to hear it before it’s said.

“You didn’t know this number six months ago. You’re presenting it now as evidence of new strategic insight. What changed between then and now, and how do we know your framework won’t produce a materially different number in another six months?”

The honest answer is: we had no instrument. Now we have one. First readings are Low confidence by design; that’s not a disclaimer, that’s the methodology. Confidence builds as we run operational cycles and compare actuals to estimates.

Point 3: “Low confidence by design” is honest. It’s also exactly what Werner will use to argue the methodology isn’t ready for Series C decision-making. I’m about to walk into a board meeting and present numbers built from notebooks and my own rough calculations, and call it a capital allocation framework.

Arjun would say: the framework is sound, the first numbers are directional, the confidence level is transparent and by design. That’s a defensible position.

I would say: defensible and fundable are different things.

Still open.

The governance appendix, the first time I asked

Toward the end of the session, I asked Arjun directly: Is PCU-V a board deliverable or a framework artifact?

He said: “Both, eventually.”

I said, “That’s not an answer about who owns the maintenance after you leave.”

He said the Head of Data owns ongoing PCU-V tracking. The CEO reviews quarterly. The first version is built together.

I wrote in my notebook: There is no permanent Head of Data. Tina is on sixty days. The governance structure he’s describing requires a role that doesn’t exist yet.

Sarah Chen, Stock Dropper. George needs ten days. Werner’s question is written in her notebook. The governance appendix has no owner.

Arjun, Tina, and I met. He explained the concept to me during yesterday's session, and I asked him to run it with Tina. He asked her to map into five categories. On paper.

He wrote them on the whiteboard:

Planned: roadmap work, the list from Monday morning
Incident: something broke, you dropped everything
Support: someone needed help
Ad-hoc: undocumented request, no ticket
Blocked: waiting, couldn’t move

He asked Tina to run it. I think she did not want to be in the room; she was at the back of the room with her notebook next to the door, 4 chairs between us. She looked at the whiteboard, then at him.

“For the whole team?”

“Start with yourself. We will ask the team for their feedback.”

He said one more thing before she started: “We’re measuring the system, not your performance. These numbers are not a report card.”

I was sitting off to the side. Observer position, my choice. I had my own notebook.

What follows is what I wrote while he was in the room.

Attack 1 written during the session

A stressed team, given time measurement, becomes a “no” team.

The moment you start categorizing ad-hoc requests, every ad-hoc request becomes a data point in someone’s case against something. Stakeholders will feel it. They’ll start hearing: “I’m logging this.” The relationship between the data team and the business shifts from service to accounting. People stop asking informally. They formalize everything. You don’t reduce the load, you drive it underground where it’s invisible again.

Arjun says the measurement protects the team by making the load visible. I say the measurement changes the load by making the team defensive. They will still need to answer the three questions; the overhead is a dangerous thing when you work already 60 hours per week.

Still open. I didn’t say this in the room. I wish to see how it develops before I intervene.

Attack 2 written during the session

“Blocked” assumes people know why they’re blocked.

Half the time blocked means: I ran into something hard, I didn’t know who to ask, I quietly moved to the next task, and came back later when I had more context. Nobody files that under “blocked.” They file it under whatever they finished next.

The self-reporting categories will capture the things people are comfortable naming. The things they’re not comfortable naming, the hours spent on work they know is low-value, the time spent managing stakeholder relationships that shouldn’t require management, the rework because a schema changed without notice, those will land in whatever category feels least like an accusation.

Arjun said afterward: “Consistency matters more than precision. The first reading is directional, not auditable.”

I understand this. I’m not convinced it solves the problem. If the categories are systematically biased toward what people are comfortable admitting, the directional signal is also biased. We just won’t know which direction.

Still open.

Attack 3, it will become a blaming game

“We measure the system, not you.”

Arjun said this before the exercise started. He says it again in debriefs. I think he believes it. I also think the team hears something different.

When Deborah was running retrospectives, she said similar things: “This is about process, not performance.” The team participated. And then the retro output went into a document, and the document went into a folder, and in the next performance conversation, those documents existed. Not as evidence. Just, they existed. People remember that.

Trust in a measurement system requires trust in the person who controls what happens to the output. Arjun isn’t permanent. The next person to see these CDSI sheets will be someone I hire, or John, or George, or Christoph, in a board deck. The team knows this even if they don’t say it.

“We measure the system, not you,” is true in Arjun’s hands right now. It depends on what we do with it later.

Still open. This one I’m actually most worried about.

The number, Friday

Arjun spread the sheets on the table. Aggregate, no individual breakdown. The team’s week by category.

38% planned. 62% reactive, incidents, support, ad-hoc, blocked, roughly equal.

Tina looked at the sheet. “That tracks,” she said. Not defensive. The way you confirm something you already knew.

• I circled 38 in my notebook.

Here is the honest version of my reaction, which I didn’t say in the room: I have been reading the team’s ticket velocity for the past few weeks and feeling reasonably good about delivery. The tickets were real. The sprints were real. The delivery happened.

What I had never seen was the 62% around it. The part that consumed the week before the roadmap work could start. The part that doesn’t show up in the sprint report, doesn’t appear in the quarterly review, doesn’t get presented to George as a cost because it doesn’t have a label.

George, before Deborah left, asked her to split the tickets between the build VS. run. She did send the report, but now looking at it, the percentage we saw was the 38%

I ran the rough math last evening after Arjun sent me the results of the entire team. Team weekly cost × 62% = the weekly spend on work nobody approved, and nobody tracked. Per month, it’s a number George has never seen as a line item. It’s not on the hosting bill. It’s not in the delivery report. It just came out this week.

(rough estimate, not audited, I need Tina to sanity-check the loaded cost assumptions)

From the notebook, Tina's conversation, Monday evening

I found Tina after the Friday debrief. Not a formal meeting, she was still at her desk. I sat down.

What I expected: she’d have questions about the methodology, or concerns about how the numbers would be used.

What I got was different.

She’d already run the calculation herself before the session ended. She thought the categories were right. She said: “The framework is solid. The numbers will be accurate.”

Then she was quiet for a moment.

“I knew what they were going to show,” she said. “But they don’t point out which products are generating the reactive load.”

I asked if she was worried.

“Not about the method,” she said. “About what comes after it.”

She meant: some of those products with high reactive load are products she’s been responsible for maintaining. Arjun said, “We measure the system.” The system, in several cases, has her name on it.

Note: She didn’t say she thought CDSI was wrong. She said she was afraid it was right. That’s a different problem, and a harder one. You can fix a wrong methodology. You can’t unfind the right number.

She also said something I’ve been turning over since:

“Deborah had the same picture. She just didn’t have a name for it. She used to call it ‘the tax.’ Every time we said yes to something, the tax went up. She tried to raise it in retros. It ended up on slide four of a deck nobody read to the end.”

Note: CDSI didn’t show Tina anything new. It showed me what she’d been carrying without language to surface it; here are the 60 hours a week gone into it. That’s two years of a picture nobody asked to see.

The John question, not raised, is still waiting

CDSI measures how the team’s week gets allocated. John built the operating model that shaped that allocation together with Deborah. He gave the team its mandate: responsive to the business, deliver on requests, serve the stakeholders.

The team is responsive. CDSI shows exactly how responsive. 62% of the week is the cost of the mandate John built.

He hasn’t seen these numbers. I haven’t told him the CDSI exercise happened.

Attack: When John sees 38%, he’s going to hear: “The team you built is spending most of its week on the wrong things.” His answer will be: “I built exactly what you asked me to build.” And he will be right. The mandate was mine. He executed it.

That’s a conversation I’m not sure I can have productively right now, three weeks before the board call, with Tina holding the seat and the present layer incomplete. But the longer I wait, the more it looks like I ran a diagnostic on his function without telling him.

Still open. No good time. Getting worse with waiting.

What I still don’t have

Marcus’s message is still unanswered; He wants a campaign performance layer by Q3. The Scarcity question Arjun asked me in the room: “What would you stop to make room for it?” I didn’t have an answer then. I don’t have one now.

The team at 38% planned can’t absorb a new initiative without releasing something else. But releasing something requires deciding which of the nine unjustified initiatives to kill first, and that decision requires finishing the present layer, and finishing the present layer requires weeks I’m already short on.

The queue is circular. I’m aware.

Sarah Chen, Stock Dropper. 38% planned. She wrote three objections while Arjun was presenting. None resolved. She still hasn’t replied to Marcus. John doesn’t know yet.

The first thing Arjun asked me to do wasn’t about the data team.

It wasn’t about the fourteen initiatives or the €400K lose or the board pressure. He asked me to walk him through every data leader I’d had since the company was twelve people.

There have been three. In four years.

I told him about the first one. Came from a scaled company, wanted to build everything from scratch before connecting anything to what we actually needed. Six months before John pulled me into a conversation: “He’s not building for us. He’s building for the company he used to work at.” We let him go. We called it a blocker. Too rigid.

The second came with a different profile. More collaborative. Said yes to everything. Built relationships. Delivered less. Eight months before the same conversation with John, different words, same conclusion.

Then Deborah. Eighteen months. The best of the three by any measure I had at the time.

Then the sale incident.

Arjun listened to all three without taking notes. Then asked one question:

“For each of them, what did you hire them to fix?”

The data function, I said.

“What does that mean?”

I didn’t have a specific answer. Reliability. Delivery. Trust from the business. He wrote those three words on the paper between us and looked at them.

“Did any of them know, going in, which of those three mattered most? In what order? By what measure?”

Note: I have been hiring people to fix a function I couldn’t describe. Each time it failed, I assumed the person was wrong. I never asked whether the description was wrong.

The Deborah question

I can’t write this without saying it plainly: Deborah was the best leader I’d had in this function. She was also in the seat when the 400K incident happened.

Both are true. I’m not going to try to resolve them.

Arjun asked: “What was she working on in the weeks before the incident?”

I pulled up the retro notes. Eighteen initiatives in various states of build. A governance model in progress. The migration, which one was it? I am not sure. Three stakeholder escalations. I only learned the reality of their workload after the head of data was gone. Seeing them consistently hit sixty hours a week hit me like a physical blow. I realized then that this wasn’t just ‘hard work.’ It was a desperate, unsustainable scramble, and I felt sick knowing I’d let it go on this long.

“Was she working on the wrong things?”

No. She was working on everything I’d approved and more.

“Was she working on the right things?”

I didn’t answer.

Note: The right things weren’t defined. She couldn’t have worked on them even if she’d known what they were. The incident didn’t happen because Deborah failed. It happened because we built a function with no way to triage what mattered, and when everything is equally urgent, a warehouse sync alert is just another notification in a queue of notifications nobody has time to act on.

The hiring argument is not resolved

This is where the session turned into a disagreement. I want to write it out because I’m not sure he’s right.

Arjun is pushing for a strategic hire. Someone with a product background. Someone who thinks about data as a portfolio, who can own the function’s direction without me in every decision. His argument:

“A technical hire solves the execution problem. But who tells them what to execute? You do. That’s a dependency you’re keeping. A strategic hire owns the question of what to build, and that’s the question that’s been wrong for four years.”

Attack: A strategic hire needs 6 months to understand the business before they can own anything. I don’t have 6 months. Christoph (The investor leading the series C conversation) is already watching this company’s data narrative. If I bring in someone who’s learning for the first half of the year, I’ve effectively gone dark on data leadership at the most-watched moment in this company’s history. The Series C window doesn’t adjust for onboarding curves.

Arjun: “You’ve had four years of execution-first hires. What’s the track record?”

He said it quietly. Didn’t wait for my answer.

Still open. He’s not wrong about the track record. I’m not wrong about the timeline. Both things are true, and we didn’t resolve them.

Attack: There’s something I didn’t say in the session.

Arjun’s argument for a strategic hire is also an argument for reducing my involvement. He said it directly: a strategic head of data takes classification decisions off my plate. Runs the portfolio review without me. Frames the board conversation so I don’t have to translate. My bandwidth recovers.

I hear this, and I don’t fully trust it. Not because it’s wrong, it’s probably right in theory. Because I’ve never actually backed a head of data who said no. The two before Deborah, who set limits, got called blockers. Deborah said yes to everything, and the team broke under the load with sixty hours per week.

If I hire someone strategic and they start pushing back on stakeholder intake, are they going to survive the first time Marcus is annoyed? The first time Elena has a competing priority? The first time Christoph is in the room and wants a number, my new data lead says we can’t confidently produce it yet.

I wrote this in my notebook. I haven’t answered it.

“I crossed out ‘ability to say no’ from my list of what the next leader needs. Then I wrote it back. Then I put a question mark next to it.”

Attack: One more decision. Let’s be clear about what this means.

John sourced and recommended our last three data leaders. When those tenures didn’t yield the results we needed, John and I navigated those tough conversations together. But this time, the dynamic is different. I’ve taken full ownership of this search. It’s a shift that began with Arjun joining, a deliberate choice to personally guide the direction of our data strategy. I am the one presenting this hire to the board, and I am the one who will stand by the outcome, regardless of how it lands.

Fear 1 Christoph: Three data leaders in four years is already a pattern that reads badly from the outside. A fourth wrong call isn’t just slow. It’s the conversation where Christoph decides the CEO can’t build a data function, and proceeds to protect the investment accordingly. Eva won’t be able to hold that room.

Fear 2 John: John hired Deborah. He trusted her. He said, “We both missed it” on the call the night before I let her go. I still don’t know exactly what he meant. The next hire, whoever I choose, however I frame it, lands on John as a signal about whether I trusted his judgment or replaced it. That conversation is waiting.

I asked Arjun before the session ended: “How long does it take for a strategic hire to produce something visible to the board?”

He said: “Faster than you think, if they inherit a present layer that’s already been built.”

Note: We are building the present layer now. He’s also building the case for the hire he believes in. I am aware that those two things are connected. I haven’t decided if that’s a problem.

Next: The CDSI exercise. The team logged their week. I wrote three objections to the methodology while Arjun was presenting it. None of them are fully answered.

Sarah Chen — Stock Dropper. She hasn’t decided on the hire. She knows John’s conversation is waiting. She wrote down that Arjun’s two things are connected.

Marcus caught me in the corridor on Thursday. He didn’t even say hello.

“I know the timing is terrible,” he started, his voice tight, “but the attribution project has been sitting at 60% for three months. My team is making campaign decisions without it, but we built workarounds. I need to know when it comes back online.”

I told him I’d get back to him by the end of the week. Then Elena messaged me about the customer segmentation model. Then John forwarded a complaint from the warehouse team about a forecasting tool they’d been waiting on since January.

I opened the data team’s roadmap that evening. Fourteen initiatives. Most of them were somewhere between “started” and “stuck,” usually with the same post-it note comment: ‘Blocked by migration.’

I sat with it for longer than I’d like to admit. I felt that familiar, low-grade heat in my chest, the kind that comes when you realize you’re paying for a Ferrari that’s been sitting in the shop for a year.

I should be honest about where I was mentally. I was still angry. The €400,000 incident had happened two weeks earlier. I’d told the Board it was a “systems failure.” I used the right corporate language. But underneath, I was reeling from the fact that a single Slack message had gone unread, we’d lost nearly half a million euros, and my Head of Data, Deborah, had agreed to a separation agreement in the same week.

That was my responsibility. I’d prepared for the sales for weeks, but I’d failed to include Deborah in the planning. She only found out after the damage was done.

I’d always treated the data team as an “enablement” function, a service desk that was supposed to make everyone else go faster. John and I had even structured the team around that idea. It sounded clean. It was a mistake.

The Working Session

Arjun and I sat down that Thursday afternoon. I showed him the list of fourteen. He looked at it for a long time, actually reading it, not just scanning the titles. Then he asked me to pick one. Any of them.

I pointed to the attribution model. Marcus had been in my ear about it all week.

“Okay,” Arjun said. “Three questions.

1. What specific decision does this help Marcus make that he can’t make well right now?

2. What does it cost the data team to maintain this thing at 60%? Not in euros, in actual team hours per week?

3. If we turned it off tomorrow and told Marcus it’s not coming back for six months, what actually breaks?

I started to answer, and then I stopped.

The honest answer to the third question? Probably nothing. Marcus’s team was already working around it. They were still hitting their numbers.

Arjun didn’t make a point of it. He just said: “Now ask yourself why that initiative is consuming the same amount of team attention as the other thirteen. Ask yourself if the decision to keep building it was ever actually made, or if it just kept going because nobody decided to stop.”

The Realization

I’m used to thinking about data as a “build” question. What’s next? What’s the priority? I had never once in four years treated “stop” as a real decision that someone accountable had to make.

Arjun called it the ‘build decision trade-off’.

Every time you add something to the list, you’re deciding what doesn’t get done. You’re just making that decision implicitly, by default, without naming it. And implicit decisions have a way of accumulating until their weight breaks something. Like a €400,000 oversight.

It’s smart, but how do I make this decision? How can I decide which initiative will get the attention? How was I supposed to navigate the stakeholders’ toxic water, which was already thick with mistrust?

I also don’t really trust them

I’m starting to think the problem isn’t our execution speed. The problem is the list itself. We are treating our data team like a utility, like the lights or the Wi-Fi, when we should be treating it like capital allocation. We are spending human hours, our most expensive resource, on “zombie” projects because I didn’t have the stomach to kill them.

But yet - how do I know what to stop? Arjun said it will all come in good time, we will structure and build the muscle to make those decisions, but then it feels like everything we did until now was wrong. I am using data-driven leadership. What’s the difference?

I don’t know what to do with that yet. I have a promise to Tina, thirty days to find a real answer, and the clock is ticking. I have Marcus in my corridor. And I have Arjun asking questions about a list I thought I understood, and apparently don’t.

We’re going back through the other eight initiatives next week. I’m not looking forward to it.

Wish to learn more? My new book, “What Dara Really Costs,” is launching soon. Join the mailing list (I will send only three emails by June 10th; it will be deleted) to learn when it’s on pre-sale

George walked into my office on a Tuesday and put a spreadsheet on my desk.

No calendar invite. No “do you have a minute?” Just in, door closed, spreadsheet down. Three columns. Headcount. Total spend, cloud, licenses, contractors, everything. And a third column labeled at the top in red: BOARD-VISIBLE IMPACT.

The third column had four entries in four years.

He didn’t make it a fight. That’s not how George works. He said, “Sarah, I’m going into the Series C prep, and I cannot defend this line. I see the transactions. I see the team. I have zero visibility on what’s coming back out. Help me see what you see.”

The honest answer, which I did not say, was that I couldn’t see it either.

I want to tell you that moment was the wake-up call. I looked at that spreadsheet and immediately understood what had been missing.

That would be a cleaner story. It’s not what happened.

What actually happened was that the same week George put that spreadsheet on my desk, we lost €400,000 in a flash sale gone wrong because our warehouse inventory hadn’t synced with our website for three weeks. And nobody had caught it. A warning had been sent, in a Slack message marked not urgent, three weeks before it became a €400,000 problem. It sat unanswered because the data team was underwater with a migration, and nobody had a system for knowing which warnings could wait and which ones couldn’t.

And in the middle of all of that, I had to let Deborah go.

Deborah was our Head of Data. Eighteen months in the role. She wasn’t the problem, I think I knew that even then, and I know it more clearly now. But the board needed to see a structural change, and I didn’t yet have the language to explain what structure actually needed to change. So I made the most visible move available to me. I changed the person.

It was the third time in four years I’d made that move.

The first two, I told myself different stories about each of them. One was the wrong cultural fit. One was technically brilliant but couldn’t communicate with the business. Both stories were probably true. But here’s what I’ve started to think, sitting with this in the weeks since: was the language problem theirs? Or was it mine?

They couldn’t translate what the team was doing into something the business could measure. That’s real. But I also never gave them a language to translate into. I didn’t know what I was asking for. I just knew I wasn’t getting it, and when I couldn’t describe the gap clearly enough to fix it, I assumed the gap was the person.

Three data leaders in four years. The language was missing on both sides of the table, and none of us could see it clearly enough to say so.

Right now, Tina is holding the function together.

Tina is a senior data engineer. Brilliant. Not remotely interested in being Head of Data, she told me that directly when I asked her, and she was right to say it. But she agreed to step in for thirty days while we figure out the hire, and I promised her: thirty days, and I’ll come back to her with a real answer about what changes.

I’m not sure I have a real answer yet.

What I do know is that Tina is watching me. She worked under three of the leaders I’ve changed. She knows what this chair does to people. And I suspect that part of what she’s calculating, while she holds things together with the lights on, is whether she’s about to watch a fifth person walk into the same conditions, or whether something is actually going to be different this time.

I don’t know how to reassure her of something I’m not sure of myself.

The board approved a hire despite the freeze. One position. That part was easier than I expected.

What’s harder is that John and Arjun don’t agree on what I should be hiring for.

John wants someone technical enough to earn the team’s respect and senior enough to implement the governance model Tina started. His exact words: “We need someone who can finish what was built and then scale it. Product background, data product mindset.” He has a shortlist of three people he’s already spoken to informally.

Arjun’s position is different. He hasn’t given me a profile. He’s given me a question: “What problem are you actually hiring to solve? Because if you don’t know what broke, you’re going to hire the right person for the wrong job again.”

I’ve been sitting with that for a few days now. It’s uncomfortable in a specific way, the way things are uncomfortable when you suspect they’re correct and you’re not ready to act on them yet.

Arjun came in through Eva, a board member who’s watched me struggle with this longer than I knew. I’ll be honest: I expected a consultant. Someone who would come in, assess the situation, and hand me a framework. That’s what I wanted, something I could present to the board that looked like a plan.

Arjun doesn’t work like that.

The first time we had coffee, he listened to me describe the situation for about ten minutes. The €400K. Deborah. Tina. George’s spreadsheet. John’s shortlist. The migration was four weeks behind. He let me get through all of it. Then he said:

“Before we go further, without looking at anything, what can Stock Dropper do today, because of your data function, that it couldn’t do a year ago? Not a project that shipped. Something the business can actually do.”

I started to answer. I got halfway through a sentence and stopped. Tried again. Stopped again.

He didn’t fill the silence. He just waited.

I’ve been thinking about that silence ever since. Not because I found the answer, I haven’t, not fully. But because I realized I’d been asking the wrong question for four years. I’d been asking what are we building? The question underneath it, the one that George was actually asking with his spreadsheet, is what can we do because of it?

I don’t know yet if Arjun has the answer. I’m not sure he does either, or that it works like that. But his questions are starting to point me somewhere I hadn’t thought to look.

I’m writing this from the middle of it, not from the other side.

I still have a function to stabilize, a hire to get right, and a promise to Tina I’m not sure I can keep. I have a CFO who needs a third column filled in before Series C prep, and a board that is watching how I handle this.

What I have, for the first time, is a slightly better question to ask.

That might not sound like much. Right now, it feels like everything.

Next week: the Slack message from three weeks before the crisis. What it said. Why did nobody act on it? And what that told me about something I thought I understood, and didn’t.

Sarah Chen is CEO of Stock Dropper. She’s writing this in real time, which means she doesn’t have all the answers yet. Neither do you. That’s probably why you’re here.

The book What Data Really Costs waiting list is open

A quick note on the past few weeks.

I’ve been quieter than usual here, only two issues instead of four. The reason is simple: I was finishing my second book, “What Data Really Costs.”

It’s a business fable about a CEO who loses €400,000 before realizing the issue wasn’t her data team; it was the system around it that was never built.

The manuscript is now complete.

Before I send it to print, I’m looking for a small group of founders to read the final draft and give direct, critical feedback. If you’re a founder (or work closely with one) and want early access, reply to this email.

In parallel, I’m back to taking on a limited number of fractional engagements. The focus is the same as in the book: not improving dashboards or pipelines, but fixing the system that determines whether data creates impact at all.

I’ll resume regular publishing soon, including the latest iterations of the method behind this.

More to come.

Her CFO didn’t send a calendar invite.

He walked in, closed the door, and put a spreadsheet on the desk. Three columns. Headcount. Total spend, tools, licenses, contractors, everything. Third column, labeled at the top in plain text: board-visible output.

The third column had four entries. In four years.

He didn’t make it confrontational. He said, “I need you to help me understand what we are building here. Because I cannot defend this line in a board conversation with what I can currently see.”

She couldn’t defend it either.

— — —

I’ve been in variations of this room more times than I can count.

The CEO across from me, let’s call her Sarah, which is her name in the story I’m going to tell you over the next few weeks, had done everything right by the standard playbook. Four years. Three data strategies. Real investment, real infrastructure, a team working sixty-hour weeks. Best-in-class tooling, properly architected, properly implemented. She was not negligent. She was not cheap.

She just couldn’t explain what any of it was worth.

The strategies hadn’t failed because they were wrong. They’d described a version of the company worth building. They just had nothing to say about where the company actually was. The present wasn’t in them. Just the destination.

That’s not a management principle, it’s navigation physics. A meaningful course correction starts from where you actually are, not from where you want to be. A strategy that describes only the future gives you beautiful language and zero information for your next decision.

— — —

Here’s what the pattern looks like from the inside, for founders at the B and C stage.

• Year 1: someone builds a dashboard. Things feel more informed. That’s enough.

• Year 2: the team grows, the questions get harder. Analytics becomes a real function.

• Year 3: proper infrastructure. Sprints. A real stack. A governance project is underway. You’ve invested seriously in serious things.

And somewhere between Year 3 and your next funding conversation, the CFO walks in with a spreadsheet.

The third column is almost always the same: very few entries for something that costs a lot. Not because the work wasn’t real. Nobody built the language to connect what the function was producing to the decisions the board needed to make.

The data function is not a cost center because it has to be. It’s a cost center because we never built the language to measure it as anything else.

— — —

Sarah agreed to freeze the new investment until she could answer the CFO’s question. No new hires. No new tools. No new initiatives until the existing ones can be accounted for.

She expected a difficult six months.

What she got was the most clarifying period of her tenure. The freeze removed the option of solving the problem by adding more. And when you remove that option, you find out what you actually have.

What she had was a data team that had been running above capacity for longer than she had known. Not struggling visibly, surviving. The experienced people had learned to make survival look normal.

She did not have the instrument to see it.

— — —

Next issue: the person she eventually called. And the hospital room in Berlin where his story begins.

Impact Operations

In most cases, this is the exact moment every data professional starts counting the days until “the letter” arrives, the one that relieves them of their duties.

It always comes down to one question:

“If I cut your budget by 30% tomorrow, which 30% of your portfolio would you liquidate?”

For a long time, I couldn’t answer it. I know most data leaders still can’t today. It isn’t a lack of competence. It’s because we’ve been taught to treat data as a cost center rather than as an asset. We’ve been given tools to build data products (OKRs/Agile/Scrum), but no system to manage the Capital Asset after it ships.

That gap is turning your data IP into a liability.

Read more

Premium Edition

Reading guide: 50-60 min total | Recognition: 10 min | Method: 20 min | Implementation: 15 min | Action: 15 min

Before You Begin

A quick note before we begin: I wrote this series before fully crystallizing Impact Operations. This newsletter was actually part of the journey that led me there. So while the methodology is solid, the framing isn't perfect. Over the coming weeks, I'll be refining how these pieces connect. For now: bear with me. This isn't the polished version I wanted, but it's packed with value and actionable frameworks.

Now, back to the newsletter, please take 60 seconds. Close your eyes and think about your data ecosystem, dashboards, pipelines, models, and tools.

Write down:

• How many data products do you have? (rough estimate)

• When did you last audit what’s actually used?

• Can you answer with confidence: “What percentage actively drives business decisions?”

Keep these answers. We’ll use them.

Act 1: Recognition, The CFO’s Uncomfortable Question

The quarterly review arrives. Normally, it’s routine. But this time, the CFO is in the room.

You’re asking for €80K for a new real-time analytics capability. It’s in the OKRs. The product team says they can’t move without it. You use the standard line: “The business needs this to stay competitive.”

The CFO doesn’t look at the proposal. They look at you. “Before we spend more,” they ask, “how much of what we already pay for is actually being used?”

You know what exists: the dashboards, the pipelines, the legacy models. But you don’t know the usage with confidence. You don’t know what could be turned off.

That is the moment you realize you are an “Enabler,” not an “Impact Creator.”

You are accountable for running the system, but you don’t own the outcomes. You spend, but you don’t control the value. That weekend, you run a query on your datasets. The results make your stomach drop

The Discovery

When was each dataset last accessed?

The results make your stomach drop.

47% of datasets: Not touched in 6+ months
23% of datasets: Not accessed in over a year
8% of datasets: Never accessed after initial setup

Nearly half of your data infrastructure is serving nobody.

You sit back, processing this. Then you start calculating. That “forgotten” dashboard everyone stopped using:

• Storage: €50/month (”just pennies”)

• Processing: €120/month (daily refreshes nobody sees)

• QA testing: €80/month (still in “production”)

• Monitoring: €60/month (alerts, incident response)

Total: €310/month = €3,720/year

For ONE forgotten dashboard.

You have 20 products like this.

That’s €74,400/year paying rent on a digital storage unit filled with things nobody remembers why they kept.

What’s Actually Happening Here

This is the pattern I see across every organization I work with:

Year 1: Team builds 15 data products (all justified, all needed)
Year 2: Team builds 18 more (+20% growth)
Year 3: Team builds 22 more (+22% growth)
Products sunset: 0

After 3 years: 55 data products, geometric complexity growth, team drowning in maintenance.

Nobody wakes up thinking “Let’s build a data graveyard.” It happens through small decisions:

• “It’s only €50/month, might need it someday.”

• “Stakeholder X might use this for Q4.”

• “Nobody’s complaining, so it must be fine.”

• “We built it, we should maintain i.t”

Each decision seems rational in isolation. But 20 “rational” decisions compound into €74K/year you didn’t notice losing.

In Impact Operations terms:

Your Data Strategy Triangle is unbalanced. The maintenance position has consumed capacity meant for innovation. Your team isn’t slow; they’re paying the Zombie Data Tax.

When we run CDSI diagnostics with teams in this situation, the numbers tell the story:

Constraint: Maintenance overload (>70% capacity)
Primary blocker: Zombie products consuming innovation budget

Your team stress isn’t a people problem. It’s a portfolio management problem.

Where Are You?

Do any of these sound familiar?

• [ ] CFO asked, “How much of our data is actually used?” I couldn’t answer with confidence

• [ ] We track infrastructure costs but can’t connect them to specific products or outcomes

• [ ] Team says they’re at capacity, but I’m not sure why

• [ ] We’ve never systematically audited usage vs. collection

• [ ] We know we have “zombie” products, but haven’t quantified the cost

If you checked any box, Strategic Sunsetting is your constraint relief methodology.

Continue reading to get:

• The True Cost Iceberg (why that €50/month is really €310)

• How does this connect to your Strategy Triangle imbalance

• The 5 Relevance Criteria for evidence-based decisions

• The 15-minute audit that reveals your zombie tax

• The boardroom script for presenting capacity recovery to leadership

• Direct link to the zombie calculator tool

Read more

The Survival Paradox: Data teams are trapped in a reactive delivery cycle that prevents them from discovering high-value opportunities. While drowning in urgent requests, they’re expected to find strategic growth initiatives, but have no capacity to look for them. This isn’t a capability problem; it’s a structural one. Organizations demand innovation while only rewarding firefighting.

The Cost: Lost opportunities that stakeholders can’t articulate, talented team members who resign out of frustration, and millions in potential value that remains invisible because everyone is too busy delivering to observe.

The Reality: You only solve problems people bring you, missing the transformational opportunities hidden in daily workflows, like the creative team spending hours manually analyzing hundreds of ad variations, never realizing algorithmic analysis could save time and improve performance by 23%.

Read more

The Problem

Your data budget is hemorrhaging value. A recent case study reveals the stark reality: one company spending €180,000 annually on data infrastructure discovered that 73% of their collected data was never used in any decision process. Teams took 3.2 weeks to get actionable insights, yet they continued expanding their data collection.

Sound familiar? While 68% of enterprise data goes unused, companies waste $3 trillion annually on poor data quality. Most organizations claiming to be "data-driven" are actually data hoarders—impressive infrastructure, zero business impact.

The Solution: The Data Investment Portfolio Approach

Stop treating data like a pack rat. Start managing it like a portfolio manager.

The breakthrough insight from this deep-dive analysis: successful data transformation requires viewing every data source as an investment that must justify its ROI or face elimination.

The Data Centricity Framework applies the 5 W's to every data point:

• Why: What specific decision will this data improve?

• What: What action triggers when data shows an X pattern?

• Where: Which teams/processes benefit?

• When: What's the optimal collection frequency?

• Who: Who owns accuracy and resulting actions?

Real transformation example: An e-commerce startup eliminated 56 of 79 tracked metrics using this approach. Result: 60% infrastructure cost reduction, decision-making accelerated from 3.2 weeks to 4.5 days, and a data-driven product expansion that contributed 28% of quarterly revenue.

Read more

Your last data initiative was technically perfect but died during rollout. Stakeholders didn't adopt it, users preferred old tools, and your team couldn't explain what went wrong beyond "change resistance." You're not alone—70-95% of digital transformations fail not because of bad technology, but because teams "deploy and hope" instead of systematically planning for the chaos that inevitably hits during implementation.

The Strategic Rollout Solution (90-second read)

When Simone's team discovered 35% data corruption one day before their migration deadline—their "everything falls apart" moment—they didn't spiral into chaos. While the CTO exploded and stakeholders panicked, her team had what most don't: a structured way to work through disaster.

Two framework components that created order in chaos:

Stakeholders & Actions Tracker: Every person knew exactly who to contact for each broken system, what actions each stakeholder needed to take, and current status of every moving part. No "Who's handling this?" confusion—just coordinated response.

Known/Expected Risks & Mitigation Plan: They'd already planned rollback procedures, communication scripts for worst-case scenarios, and resource reallocation for crisis mode. When automation failed, they had pre-built responses instead of panic decisions.

This framework didn't prevent the disaster or magically fix everything. It gave them structure to keep working systematically when everything went wrong. Instead of career-ending chaos, stakeholders saw "clarity and transparency during crisis"—exactly what leadership values during high-pressure moments.

Your Next Action (60-second read)

Next time you start a data initiative, build your Stakeholder Tracker first: map specific individuals (not roles), their required actions, and communication channels. Then document your top three expected risks, along with particular response plans. When your rollout crisis hits, you'll have a framework for a systematic response instead of just hope.

This Week's Implementation

Read the complete Strategic Rollout Framework case study to see all 8 components that saved Simone's team. Reply to this email if you want to discuss how this framework could strengthen your next rollout.

Read more

The Problem

You're investing 5-7 figures in data initiatives, yet basic business dashboards still don't work smoothly.

The hidden culprit? ROI paralysis. Teams avoid ROI discussions because "the numbers are too uncertain," creating a vicious cycle where data initiatives compete on emotion and politics rather than value.

Organizations making billion-dollar decisions based on market projections refuse to estimate the value of a €20,000 dashboard because "we can't be certain of the exact ROI."

The cost: €110,400 in lost opportunity and team frustration, just like Sarah's team experienced before implementing this framework.

Read more