Not two seconds later, the Head of Sales points to her dashboard and says – "Actually, we're at 15.7% growth based on our CRM data."

Uh-oh, I thought to myself.

Then Marketing Guy chimes in, "Well, according to our analytics dashboard, we're actually at 10.2%."

The CEO slowly turns to look at me. Not to the CFO. Not to the Sales Head. Not to Marketing Guy. To Me, the CDO. The supposed "single source of truth" guy.

"So," says the CEO with that dangerously calm voice, "which one is it?"

This total mess wasn't happening because we didn't have data talent. It was happening because we had TOO MUCH data ‘talent’, just all doing their own thing. Every department had secretly built their own little shadow data team.

Finance had hired these four ex-banking quants who built a parallel data warehouse that only Finance could access. Sales had a few “reporting specialist" (read: shadow data engineer) who pulled directly from Salesforce and applied his own custom calculations. And Marketing? They had built a large team who built them a "totally revolutionary" analytics platform that literally no one else knew existed, and the head of marketing paid the platform subscription cost from his corporate credit card!

Each team had their own definition of revenue and no one was sharing any data. The Finance reporting specialist was literally downloading exchange rate data from some random website and marketing was copy-pasting inputs from an email report.

No wonder three different executives have three wildly different numbers!

The reality is - any positive outcomes delivered as a result of data it's because "the business made smart decisions”. But when data goes wrong, as CDO, you're the face of the problem – even if you didn't create it. So you need to lean in and fix it!

Yes it’s not fair, but that is life. This is an occupational hazard of being a data professional, especially for the top dog!

Signal from Noise

• Your company too has shadow data teams

• Your spend on data resources is likely costing more than it should

• Yes - the problem is yours and only yours to fix

• As CDO, you probably have limited ability to fix this problem, and you will likely create a political s**t storm trying to solve it.

Being Brutally Honest (Ouch!)

If you are a CDO of a large or mid-sized company, your current structure would be the organisational equivalent of using Excel as a database – it works (kind of), nobody loves it, but everyone's too scared to change it.

Your "Federated" Model (not really a model) has grown into quite a mess! The Product, Marketing & Customer Service departments each have built their own ‘Business Intelligence Group”, because they wanted dedicated resources and their data needs were ‘unique’. Each department is running their own siloed ‘data warehouse’ (homegrown database) which hadn’t conformed to any architecture principles, and many of your processes are manual and off-system (Excel, local databases etc.).

Your data architects are all busy on ‘strategic’ projects, and your data engineers seemed very content being pipeline builders and transporting data from source to data warehouse, with no regard for fundamentals like data modelling, conformance and data governance.

Your central data team (stood up only 2 years ago) has created a modern data platform and a single source of truth data model, but has struggled to build insights solutions because you are just a data team, and creating reports is the role of the ‘business’. Plus platform adoption has lagged due to resistance from the business intelligence teams.

As a consequence:

• The majority of your reports are manual and untimely, and there are 100’s of Excel reports/models being used to run critical operations and pose a significant risk.

• Data in reports is often wrong, the same question often has different answers depending on which team created the report and which system the data was extracted from. Of course these reports are prepared by business intelligence teams, but the CDO gets blamed for this.

• Data is being hoarded by a small number of people, which means your end users did not have easy access to data. Also, users do not know who to go to for data and analytics requests as there are multiple teams with similar data.

• You don’t have the ability to leverage data as a strategic asset, and your data culture is suffering.

• Your labour cost of data is blowing up - it is likely 3X of what you think the cost is.

Playbook - to transform the business of data

Appoint a single accountable person - your Chief Data Officer (CDO)

An organisation with multiple data teams and multiple data leaders will inevitably face challenges due to its fragmented structure and execution, leading to unaligned teams, conflicting direction, and an inability to harness data strategically. An obvious solution to this problem is to appoint a senior leader as the single accountable leader for data analytics - a Chief Data Officer (CDO). The CDO needs to have centralised oversight over all aspects of the data landscape, including capital allocation and prioritisation decisions, and should be tasked with steering the data organisation in the strategic direction.

Because the role of a CDO is ill-defined and not understood in the industry (e.g. compared to a CFO), you need to take extra efforts to clarify roles & responsibilities, especially in relation to the various Directors or Heads of data, performance monitoring, business intelligence, etc., you have in your company. Chances are many of these Directors or Heads consider themselves to be the de facto CDO (at least for their division) and assert that perceived authority. Make it clear the CDO is the executive leader responsible for data. Like each ship can only have one captain, you should only have one CDO at the helm.

Note that your flavour of data operating model (federated vs. centralised) shouldn’t have a bearing on the appointment of a CDO - the CDO can effectively oversee the data organisation in both a federated and a centralised model, as long as they have the right authority delegated to them. This model can be scaled based on the size of the organisation, e.g. divisional CDO model in larger organisations vs. a central CDO model for mid-sized companies.

Empower your CDO with Analytics & AI responsibilities - don’t confine them to just data.

The CDO role is a business (not technology) leader, and the composition of the CDO organisation needs to reflect this. The worst thing you can do is to restrict your CDO team to technical backend functions like data governance, engineering, etc., without any business-facing functions like analytics, AI, data science, and Business Intelligence. You want your CDO to drive business outcomes - this requires the CDO to own analytics & BI responsibilities.

Some companies also make the CDO responsible for delivering business outcomes by using analytics and AI, but leave analytics and AI teams scattered within business units with no intent to coordinate and oversee these teams. Generative AI has compounded the issue for CDOs with many CIOs having staked their claim on AI in their portfolio - but the risk here is over-focussing on trendy and simple-to-implement AI tools (e.g. Microsoft co-pilot) which certainly has some productivity and other benefits, but ignoring deeper and more meaningful business transformation. The other challenge is Technology departments standing up new AI teams, which adds another siloed team in the company.

Speaking from personal experience, this is the worst possible scenario for a CDO to be put in - all the responsibility but little to no authority. This is one of the key reasons for very high CDO turnover - most CDOs quit in 24-30 months, which is too short to drive real transformation, especially in large, legacy businesses.

Ask your CDO to develop a unified data, analytics, and AI strategy.

Given you have multiple data and analytics teams, you probably have multiple "strategies" floating around. Or worse, no one has a strategy at all. Business units have a smattering of ‘data-driven’ & ‘AI first’ in their business plans, but there is no substance behind the buzzwords.

You need a unified data, analytics, & AI strategy to:

• Provide clear direction on the role of data, analytics, and AI in your company, and how exactly it should be used to deliver to your business strategy.

• Align all data, analytics, and AI initiatives to a single strategic vision (ideally to the company’s strategy).

• Establish priorities that everyone agrees on (yes, this will be painful).

• A strategy without a funded roadmap is just shelfware and pretty useless - so create & fund a single roadmap that balances quick wins with long-term value.

• Define clear success metrics (and no, "being data-driven" isn't specific enough).

Rationalise (but harness) your shadow data & analytics operating model - remove duplication and set them in a single direction.

Your federated data teams are a result of years of departments solving their own problems, either because nobody else would, or they wouldn’t let anyone help. Now you've got to untangle this mess without breaking what actually works.

• Find all the bodies (including hidden ones) - You need to know what you're really dealing with, and it’s probably worse than you think. Conduct an inventory of resources across the entire company - don’t just look for people with ‘data’ or ‘analytics’ in their title, look at unofficial data roles like ‘business analysts’ or ‘strategy lead’ who mostly wrangle data or do data science. Assess skills and willingness to adapt to new ways of working. Define your target state organisation structure, and define a transition plan, including mapping resources to roles in your target state.

• Design a fit-for purpose operating model that’s suitable for your company. Don’t just copy-paste a generic model from a consultancy. Spend time assessing current state maturity, identify pain points in the operating model, and design a structure that not just solves for these problems, but also allows you to achieve your strategic objectives.

• Provide employees with clarity on their roles in the central team, what’s changing and what’s not, and transition timelines. Secure buy-in from employees transitioning from federated teams on the data strategy and the future state.

  • The best data analysts have a combination of data and specialist business/domain expertise, and you typically find them working in federated teams. Identify these folks and treat them especially well as they will play a crucial role in making your data strategy a success.

• Map out shadow reporting processes - you won’t be able to scoop up these reporting analysts as part of your centralisation mission as reporting is usually only one aspect of their roles, but you will be able to unlock productivity savings once you roll out your automation agenda.

• Stop or slow down work on legacy platforms and focus your efforts on strategic priorities. If a legacy process is mission-critical, consider hiring an offshore or low-cost consultant to perform this task (you don’t need a senior data analyst who is paid $200k manually refreshing data in an Excel model). Even better, build a bot to automate the process where possible.

Note: Many people have spent years in their current roles. Be aware that you are dismantling (and rebuilding) entire careers and working relationships, and approach this with empathy. The employees you would like to retain may be exploring external opportunities - implement retention plans, budget for retention bonuses. Be prepared to deal empathetically (but swiftly) with people who may not make the cut, either because they lack the required skills or the willingness to be part of your team.

Deploy reusable data and analytics products and promote collaboration between different teams

3 different models to calculate customer lifetime value, 2 potential sources of sales data, 3 customer satisfaction dashboards - you need to put a stop to solving the same problem ten different ways. You need to create standardised products.

• Catalog all existing data products, even the unofficial ones (especially the unofficial ones) - this is basically your baseline requirement for your target state data products. Your legacy systems contain a whole heap of crap that isn’t relevant anymore. Identify the metrics/reports that actually matter and serve them as standard pre-canned analytics and insights products. Discard unwanted metrics and reports.

• Design standard data products for each business domain (customer, sales, marketing, etc.) and make sure they can talk to each other. Don’t make the mistake of attempting to create a full and comprehensive data model - be agile, prioritise, and build incrementally. Bake in data quality and privacy controls into the data products.

• Target high-visibility use cases, e.g. delivering Executive reporting as a quick win is a great way to get some visibility and CEO sponsorship. Also, make sure you enlist power users in your company to be early adopters of these data products, enable self-service, and put in sensible governance processes to govern data usage.

• Use data & reporting catalogs to help users find, understand, and use data. Provide training to users on accessing and using this data appropriately.

• As you start to migrate reports, actively decommission Excel models & legacy reports currently used. Change manage and transition users to the new platform. Transition employees from the old to new platforms. (I have oversimplified this complex topic; I will look to detail this at a future date).

Prioritise Change Management

I cannot overemphasise the importance of change management in data transformations, especially in organisation redesigns. Change management is the most important factor in the success or failure of your data transformation, not your data platform, not your delivery partner, not the choice of your BI tool.

To be successful in your role as CDO, you will need to transform the way your company fundamentally operates by changing behaviours. You will need to navigate politics at all levels, and will face severe resistance from employees who have spent many years working with existing systems and processes. Without good change management, even the most perfect technical implementation will fail due to low adoption or misuse of your new platform/model. And really great change managers play a dual role and act as the unofficial cheerleader of your team, helping keep morale up and provide creative solutions to resolving problems and conflicts.

A change manager is usually the first key hire I make when I start a new gig. You should do the same. Unlike good data engineers or analysts who are relatively easy to find, good change managers are a rarity, especially ones who have some data transformation experience.

Good change management (and a good change manager) can dramatically improve your chances of success - prioritise this over all else.

Key Takeaways

• Shadow data teams are disruptive. Harness and channel their strength towards a single strategic direction.

• Your ship needs only one Captain - your CDO.

• Deliver visible and high profile use cases early on to get your Executive team on board.

• Invest time and top dollar to hire a solid change manager.

My team had built some genuinely impressive data products for the first time in the company’s history.

But… they wouldn’t release them to the users.

Subscribe now

Every time I asked why, I got the same answer:

“We want to make sure data quality is right.”

“We’re still reconciling the data against the legacy reports.”

“If we release the data now and something data is wrong, users will lose trust.”

They were being overly cautious.

Chasing perfection had gotten in the way of progress.

They had convinced themselves that the data had to be 100% accurate before release, whereas users were happy with ‘good enough’ data now, and improvements on an ongoing basis.

Signal from Noise

Here's what I've learned from years of shipping data products:

1. Unused data decays — if data gets used, problems with the data gets surfaced and fixed, which improves quality and usefulness of data

2. Perfect data quality is a Myth — data quality doesn’t need to be 100%, it needs to be fit-for-purpose for the use case

3. Data quality is a shared responsibility — of the data team and the users of data

Behind the Dashboard

There’s a comforting lie data teams tell themselves:

“We can’t release it yet. It’s not ready. We need to make sure data is 100% accurate.”

I get it.

No one wants to be on the hook for publishing wrong numbers.

But reality is the longer you wait to release data, the less your users trust you.

Here’s the paradox:

Data usage will surface issues in the data, and you can use this feedback to fix the problem. Different usage patterns will give you more/different data quality rules to apply, broadening the use of data. When users use data to drive real business decisions, you will understand what works and what doesn’t.

That’s how trust in data is built. Not by hiding the data until it’s flawless — but by exposing it and improving it iteratively.

Playbook || Data -> Insights -> Action

Here’s a brief playbook I’ve developed you can use to get value from data early and iteratively, improve data quality the right way and gain user trust along the way.

Release early & often. Be transparent on state of the data

• Don’t wait for perfection — launch your data products early but include explicit & visible data quality indicators

• Include clear labels like “Not suitable for regulatory reporting” or "Beta - reconciliation in progress”. My preferred approach is to implement a traffic light system in dashboards & data catalog - Green for production-ready, Yellow for "use with caution," Red for "exploratory only”.

• Explicitly communicate known gaps to set expectations and protect trust.

Define quality in business terms, not technical ones

• Co-define what “high quality” data means with end users: availability? relevance? frequency? actionable? interpretable?

• Prioritise fixing data that directly drives business decision & outcomes

• Include quality indicators (e.g. “last updated,” “source system delay”) directly in your data products

Match data controls to criticality and risk profile

• Define tiers of data assurance and apply controls proportionally — not all data deserves military-grade validation

• Use lightweight governance & controls for exploratory or low-risk products

• Provide clear guidelines on what not to use the data for e.g. ‘Do not use for regulatory reporting, dataset not certified”

• Share results of data controls testing with users

Establish seamless feedback loops

• Make it easy for users to report issues without friction — use tooling to capture, track and make data issues transparent to users

• Treat users as collaborators — enlist them in identifying data issues & prioritizing fixes

• Communicate fixes and iterations publicly to build trust

Focus on fixing data quality issues, not just detection

• Implement processes to fix data issues at the source where possible — partner with upstream owners to correct root causes, not just patch symptoms downstream.

• Assign ownership of data issues and track SLAs — ensure recurring issues have clear accountability and defined resolution timelines.

• Communicate improvements visibly & make progress easy to see — frequently share what’s been fixed and improvements, and also areas where you need support to implement fixes

Make quality a shared responsibility

• Assign data ownership across the pipeline — The central data team alone cannot be responsible for fixing data issues. Identify upstream creators of data, their leaders and data owners, and make them equally responsible for data quality.

• Build shared incentives — align and equip business, ops, and tech teams to understand and act on the real-world impact of poor data quality.

• Embed data quality as a business KPI & make it a standing item in operational reviews. In your data quality dashboards, include the ‘so what’ to articulate impacts of data issues on business operations.

Conclusion

You don’t earn trust by hiding data until it’s flawless. You earn it by releasing it to users early with transparent messaging on its state, enlisting users to help identify issues, fixing what matters to them, and showing progress over time.

Perfection is a trap. Choose Pace over Perfection!

What I saw was a smattering of colours and numbers on a page, in a table, with the table somehow containing tiny graphs within its cells. Each column represented a KPI, but I couldn’t recognise what most of them. The bottom half of the page was filled with point 7 text, and was giving me a splitting headache.

Subscribe now

“Budget, outlook, plan - don’t they all mean the same?” I asked my finance BP. “No, they are different”, and he went on to explain in detail.

“How much money do I have to spend this year? Isn’t this in the budget column?” I asked.

“No”, came the response, “the budget was fixed as part of the planning process, you need to look at the forecast column”.

“Then why have you included the budget number in the dashboard if that is no longer relevant”?

It took the next 60 minutes, plus 2 more meetings, with me and my full leadership team, to understand what each metrics meant, which of these were relevant, and why each mattered. Talk about expensive meetings!

Even after all this explanation, it took me 30 minutes each week to decipher the dashboard, and try and identify things I need to pay attention to.

It drove me nuts!

Signal from Noise

1. Information overload is a real problem for time poor executives. Emphasise simplicity in your dashboards - use a smaller number of metrics that drive real action.

2. Commentary is a powerful tool to highlight the ‘why’ and ‘so what’. Use this to your executive’s advantage.

3. Show visual restraint - use visual elements sparingly to highlight important information and maintain white space for cognitive ease.

Infobesity - The Paradox of Information Overload

Data is truely BIG these days - 400 million terabytes of data are created everyday globally and growing at 26% CAGR. An organisation on average sources data from 400 data sources. Cloud data platforms like AWS & Azure, and tools like PowerBI & Tableau have made it effortless to visualise data & extract insights (remember the good old days when you needed an engineer to create a Business Objects dashboard??).

The consequence of technology advancements is information overload - more data is easily accessible and hence more data is presented to executives. Executives are after all human, and like all other humans, we have limited cognitive capacity. We receive a barrage of information on a daily basis which makes it difficult for us to identify what’s important and filter out what’s not.

I personally have also found the volume of data shared with me causes a lot of stress and takes an emotional toll, which many times manifests itself via physical symptoms.

Information overload often results in analysis paralysis, inability or unwillingness to interrogate and understand information, and ultimately sub-standard decision making.

Why do Business Intelligence (BI) teams keep creating complexity & over share information

Here’s a sneak peek into the mind of a BI analyst (often times encouraged by their Head of BI) -

1. Oooh I want to show off my technical skills, or what my new tool can do

2. A simple table? Nah, much cooler to create an obscure chart even if it’s difficult to read

3. I have so much data available, I don’t want it to go to waste, so let me include more of it in my dashboard

4. What if they wants more information, I don’t want to leave anything out and look stupid

5. If am being real honest - I don’t truly understand what decisions the data needed to support

6. My executive claimed to be a ‘visual person’, so I’ll include colourful charts

Let’s face it - we all have analysts in our teams who are guilty of this, and this problem is only getting worse. Most executives don’t raise a fuss and don’t ask for the unimportant stuff to be stripped away - they get their EA or 2IC to interpret dashboards and email them the top 3 insights that matter, and many just make gut-feel decisions.

Playbook - Making Data Work for Executives

When I was a business intelligence manager (a long time ago when Windows XP was cutting edge), I thought our dashboards weren’t appreciated because our executives weren't sophisticated enough. They would ask for simple tables and often times, reports in Excel! While we would always deliver to the executives wants, I felt I was giving them a faster horse, leaving me frustrated.

My perspective changed completely when I became an executive myself and had to rely on data and insights to run my business unit. As an executive, I had very limited time (usually in between meetings), to read reports and make decisions. I didn’t have the patience to suffer flashy dashboards. I wanted simple numbers. It was my turn to say - “just give data in excel”.

I had understood what was truely important when it comes to information delivery - simplicity and not complexity.

Executives operate in complex environments and are dealing with extreme time pressures. They don’t need oodles of data and colourful graphs. They need information that:

• Can be understood in seconds, not hours

• Provides immediate context for interpreting numbers

• Clearly indicates when their attention is required

• Directly connects to decisions they need to make or problem they need to solve

Here are 5 rules you can use to deliver information clearly and assist your executives in making effective decisions, all based on my real world experience, both as a data analytics professional and as an executive needing to make data driven decisions.

Design for the attention span of a goldfish

I ask for all my dashboards to be designed so I can consume all the important information in 9 seconds, which is the attention span of a goldfish is 9 seconds. Here’s a useful framework to design your dashboards based on my dashboard consumption workflow -

• 9-second scan: Check for anything needs immediate attention

• 5 minute review: understand the story/narrative, ideally through commentary - is there an sleeper problem or a worrying trend I need to pay attention to, understand root causes etc.

• Determine action: Timeframes can vary based on various factors. If I got to the point of knowing I need to take an action, it means my dashboard has achieved its objective.

Include only relevant metrics

Always ask - why does this metric matter? Does this metric tell me something important, or drive a key decision? If a metric doesn’t drive an action, it shouldn’t be in your dashboard. In most cases, 3 metrics is better than 20.

If supporting or detailed information is required, provide them in visual drill downs, and tie back to key executive metrics.

Executives don’t (certainly shouldn’t) care about having the most comprehensive set of metrics, they care about the most consequential metrics.

Avoid naked numbers like a plague

Always provide context to all metrics. Is a 6% increase in customer acquisition cost good or bad? You wouldn’t know unless it was read with contextual information. Here are some useful contextual information to include against your metrics. Just make sure you don’t overdo this and provide more context than necessary.

• Comparison against a forecast, target or benchmark

• Relationship between metrics e.g. increasing acquisition cost together with increasing lifetime value

• Trend over timeframes

• Thresholds indicating when a metric turns bad or good

• Further metrics or insights explaining the ‘why’ behind a metric

• Strategic overlay or expert analysis

Master the Art of Commentary

I used to think I should let the data do the talking itself, and I didn’t want my analysts to introduce bias with their commentary. I was probably put off by the many BI analysts who include pages of commentary which never got consumed.

However my perspective changed once I became a senior manager and then an executive, and I had to rely on reports and dashboards to run my business. I really didn’t have the time to identify which metrics really mattered, and interpret my dashboards to figure out key drivers and impacts of adjusting these drivers.

These days, I prefer my dashboards to come with short and succinct commentary based on the following guidelines -

• Provide a succinct 1 line summary at the dashboard level

• Explain why something has changed

• Explain the impact of the change

• Where possible, highlight key decision, or key question/next step to support decision making

• Assign an owner to produce commentary

The key is providing enough commentary to give context & summary without burying key information in text. When a deeper explanation is needed, you could include this as an appendix. Don’t make the mistake of including pages of commentary.

Hot tip: This is a use case where AI can be used to fundamentally change your approach to executive reporting. Tools like PowerBI have had capability to produce commentary for a while, and these are now augmented with AI capability. There are also other apps, either standalone or add-on’s to tools like PowerBI which have better AI capabilities. While not prefect and requiring humans in the loop, AI is getting better, and can provide a quick way to provide your executive with an ‘executive data translator’.

Show visual restraint

Peacocks are flamboyant and colourful, your dashboards shouldn’t be!

Bright colours, images, gradients, 3D charts, custom icons - all these sounds great. But in reality, these prevent you from seeing the forest for the trees - or in the case of your dashboard, prevent you from seeing the data for the design.

Here are some simple guidelines I insist are incorporated in my dashboards, which makes consuming information much easier.

• Use colour sparingly - only to highlight exceptions or draw attention

• Embrace "boring" bar charts, tables & pie charts (gasp!!) when they communicate most clearly

• Maintain white space to give important information room to breathe - this provides cognitive oxygen for your executive

• Standardise dashboard design and keep visuals consistent

If your metrics don’t fit in one page, you have too many metrics. If a visual element doesn't help a decision or action, it's unnecessary and should be removed.

Visual restraint is important. Not just because it’s better aesthetics, it helps you communicate better.

Key Takeaways

After spending several years on either side of the dashboard, I have come to realise the key to a good dashboard is simplicity. However this is easier said than done - creating a simple dashboard takes more expertise and time compared to creating a complex dashboard.

Anyone can create a dashboard with 20 metrics, but it takes a true master to create one with 5 that actually drives decisions.

Have the courage to show constraint, and focus on simplicity, clarity & actionable insights.

Share

The document had more than 200 pages, with more technical details than required to run a nuclear plant. Pete had included a roadmap but all I saw was a bunch of tech projects for the first 18 months, and no articulation of what business benefits will be delivered, how and when.

Pete was quite proud of his creation, but what I saw was a strategy created around a wish-list of things and lacking a clear vision. The things in the wish-list were low value, non-strategic, and things that would have gotten done despite a strategy.

Pete had listened to stakeholders, created a technically perfect blueprint and delivered a very comprehensive document for sure, but in doing so, had missed an opportunity to drive innovation and strategic impact on the business.

Pete had fallen into the classic ‘give me a faster horse’ trap!

Subscribe now

Signal from Noise

• Your data & AI strategy shouldn't be about data, AI or technology at all — it should be about specific business objectives & driving your business strategy

• Your strategy should be simple and understandable by all - stay away from buzz words and complex articulations

• Culture eats strategy for breakfast - make sure you address cultural and literacy barriers

Behind the Dashboard

Unfortunately, Pete's story isn’t unique in the industry.

His strategy document was packed with technical jargon and complex data architectures but didn’t clearly articulate business outcomes his strategy would deliver. While there was a roadmap, it was a huge waterfall style plan which would take 5 years to implement, filled with mostly technology initiatives, and no clear path to delivering early and incremental business value.

Even with my technical background as an engineer and an architect, I was finding it hard to make sense of the content and flow of the document, let alone understanding what value I would get by spending a cool mid-eight figures.

Worst of all, there was no reference to the change management, uplifting data culture and uplifting skills of users - the strategy simply ignored the significant organisational change required for the strategy to be successful.

So how can you avoid Pete's pitfalls and create a truly impactful data strategy? Here are 6 practical tips, all from my real-life experiences, that will help you navigate common obstacles and develop a data strategy that drives real business transformation.

Playbook || Data -> Insights -> Action

1. Your strategy should contain mostly business stuff, almost zero tech stuff

I remember sitting through many data strategy presentations (and having delivered a fair few myself) where 45 minutes of the presentation was spent in explaining the difference between a data lake and a data warehouse.

Nobody cared. And it didn’t matter.

What matters is how data and analytics can help improve accuracy of liquidity forecasts so cash can be better invested, or how can data analytics reduce churn in your high-income customer segment, or how industry or technology disruptions can be leveraged to improve customer service, increase revenue or create new offerings.

Majority of your strategy needs to focus on big business problems, and how data analytics can help solve these problems. While technology is important, it’s just an enabler.

This sounds pretty obvious, no? Sadly, it is not. It’s amazing how data strategies don’t even mention any business outcomes they are intending to drive using data analytics.

I’ve learnt from painful experiences that Executives don’t fund fancy tech stuff - they fund delivery of business outcomes. If your data strategy is 70% tech content, you have a s**t strategy.

These days I tend to include only 1 slide on technology and architecture in a data strategy pack. And this slide is almost childish—coloured boxes with simple arrows, stripped of all technical sophistication. My former architect self would be horrified, but this simplicity gets just the right amount of detail across to the people signing the check.

2. Keep it simple, stupid!

The most effective strategy I wrote was all of 3 slides long, and it wasn’t even called a strategy.

It didn’t have a single reference to a tech trend, had no unnecessary visuals/diagrams, no case for change and almost none of the obligatory strategy slides.

In contrast, my worst strategy was technically perfect 152 pages long (although we had a summarised 30 pager) - 30 pages on the context and case for change, 20 pages on architecture and another 23 on tech tooling. A big 4 partner would have been proud of this document and would have charged $1m for this, but this was too much, too complex and too technical for it to be effective.

Keep your strategy so dead-simple even your 15 year old will understand.

3. Be Strategic - This is a f***ing strategy after all!

Strategies should strike the right balance between ambition and realism. While there are risks in a strategy being over ambitious - unrealistic goals, lack of buy-in, risk of burning people out etc., to me an unwillingness to be bold, innovate and push boundaries poses much greater risks.

Think what Kodak’s reluctance to embrace digital photography did to them.

A strategy that only focuses on improving operations (See Zone 1 RISE Framework), excludes impactful initiatives because of budget constraints, and avoiding disruptions like AI is a ship anchored in a dry dock while competitors sail into the horizon—secure in the short term, but destined to rust as the tides of innovation rise.

Inject some ambition into your data strategy and set bold ambitions. If data analytics can really help your company make or save more money and you can articulate how, securing funding is possible. If there are cash constraints, think about slowing or staggering execution - not everything needs to be done in year 1.

Don’t restrain your strategy based on your current constraints, optimise for future needs and position data analytics as a strategic driver.

4. Balance internal voices with external insights

Pete over-indexed on feedback from internal stakeholders, many of whom had been at the company for decades (some for as long as 45 years!). Many who provided feedback had no knowledge or experience delivering or being part of data transformations in other companies. They certainly did not know what good looked like.

Company insiders, especially business leaders & long serving employees often can't see the forest for the trees. They tend to focus on current pain points and short-term constraints.

Am not saying you need to ignore internal stakeholder feedback, but this is only one side of the coin.

You should make a concerted effort to incorporate external viewpoints. Talk to your vendors & consultants - they are often miles ahead of your company, and they work with lots of companies and can tell you what works and what doesn’t. Talk to companies in your or other industries - learn from other’s successes and mistakes. Engage with academia and industry groups - they study success stories and often have frameworks you can use to drive a successful strategy.

5. Include a roadmap, but not a monolith

If I had a dollar for each time I heard ‘but I can’t deliver any business outcomes until we build out full data foundations!’, I’d be a gazzillionaire.

Yes, building stuff takes time, especially when you are starting from a low base. But it’s not a great situation where data foundations take 18 months to build and only then will you start building business use cases. No one has the patience to wait for 18 months while you spend millions of dollars.

When designing your roadmap, make sure you find a balance between building foundations and delivering business value. Break work down into smaller chunks and deliver slivers of value along the way. Deliver small units of features and iterate on this towards a full solution. Incorporate wire framing, prototyping and feature demo’s in your delivery lifecycle. Stay close to key business users and release features to them early and make sure you incorporate feedback into the next delivery cycle, creating a virtuous cycle. Instead of building your roadmap once upfront, continually build and update based on real-time user feedback.

I know some people struggle with the idea of not having a 4000-line Microsoft project plan upfront that describes all work packages, activities, dates, milestones and dependencies.

But building adaptable roadmaps that you can iterate on continually will give you the ability to improve time to market, reduce implementation risk and gain executive confidence as they will no longer view your project as a black box.

6. Address cultural and people challenges

For the longest time I ignored the cultural and people aspect of data. I pushed fancy strategies, and brute forced my way through several transformations. I viewed change management as a ‘give users a warm hug and make them feel better’ and frankly unnecessary thing - why did I need to treat my users this way, they were professionals after all.

Ah those were simpler days, when I was young and foolish, and I could blissfully ignore things that I deemed unimportant.

Obsessing over delivering a technically perfect solution is fine, but eventually it is humans who use your solutions. You are not just implementing technology, you are asking people to fundamentally change how they work (make decisions, operate processes etc.). Your transformation project will challenge and change people’s existing identity, autonomy and status (real or perceived).

This is especially true in today’s age of AI where many roles are becoming redundant, ways of working are evolving rapidly and the entire shape of the workforce is changing.

People will feel threatened, and misaligned incentives will need to be identified and changed. If you don’t have your users on your side, you will fail. Hire a competent change manager (usually the first role I hire). And get into the habit of dishing out “warm hugs”.

Your strategy needs to open with culture and people, and address what it takes to align culture and people to your strategy. Technical debt can be refactored or risk accepted. Cultural debt will compound exponentially and ultimately lead to the collapse of your data transformation.

The final word

Look, I’ve been there. I have created data strategies that resembled technical manuals. These six tips I've shared aren't theoretical - they're battle scars from years in the frontlines.

I’ve gone from a tech-obsessed geek to a business-focussed strategist who has learnt (the hard way) that data strategies need to address core business problems, simplicity trumps complexity, and your success almost entirely depends on how well you handle cultural & people change.

Don't be like Pete. Be better. I certainly had to.

Share

Look, I've been in this data analytics game for 20 years now, and honestly? It's just one buzzword rollercoaster after another. I've watched the industry go data warehouses -> In memory databases -> Big Data and Data Lakes where all you had to do was dump data and data modelling was suddenly ‘legacy’ and unnecessary -> then you needed to model data again and the go-to was Data Vault -> then suddenly everyone needed a Data Mesh -> and now its all about GenAI and prompt engineering. The corporate amnesia is very impressive.

I've had front-row seats to some epic fails – like watching a Fortune 500 company flush hundreds of millions down the toilet on a data lake that turned into a “data swamp." Or my personal favourite: a finance company that announced a massive investment on an AI strategy with a straight face while 95% of their reports were still being cobbled together in Excel by Bob in finance who was "pretty good with spreadsheets."

Signal from Noise

• Data transformations are bloody hard, and most fail.

• Transformations often fail as they focus on hot trends and ignore core foundations, and face change resistance.

• Simply implementing new technology or tools does not deliver business transformation.

Subscribe now

Behind the Dashboard

Every CEO wants to be AI first. Every company wants to be ‘data-driven’. Everyone wants to transform their business by doing <insert buzzword of the week>. And yet, many crash and burn spectacularly.

The movie script is pretty much predictable at this stage. It’s early Tuesday morning, you’re caffeinated beyond what's medically advisable, and CEO kicks off the monthly leadership team meeting. Here's how it typically goes down:

CEO: "We need to be 'AI-First'! The board is breathing down my neck about this!"

CDO: "Great, we should start by addressing our legacy systems and fixing our data quality issues. Remember that 20% of our critical customer data attributes are inconsistent or incomplete, not to mention this data is spread across 3 CRM’s and 2 marketing systems, none of which have any common identifiers. We need to start by cleaning and consolidating our Customer data in one spot - we need a Customer360.”

CEO (looking annoyed): "Yeah yeah, but I need quick wins. McKinsey says early AI adopters gain an 'unfair advantage.' The board wants us to be an AI-First company by Q4."

CMO (jumping in): "Absolutely. We have recently announced our ‘AI Driven personalisation’ strategy - we need an AI model that tells us what Bob in Tasmania will eat for breakfast this Sunday. Can I have an MVP deployed for next month's board presentation."

Me (buckling under pressure): "Sure!… Let me mobilise a transformation project.”

Sound familiar? I've buckled under this pressure more times than I'd like to admit. My personal low point: green-lighting a $2M project to build a mass personalisation model knowing full well our customer data was scattered across 17 different systems, none of which shared common identifiers. The result: six months later, our consultants had built us a beautiful dashboard, sitting on an array of spreadsheets that were guesstimating connecting incomplete information about customers. Yikes! We tried recovering the situation by hastily setting up a skunkworks BAU project in the background to fix the our data in the spreadsheets which obviously didn’t work! What worked was intentionally focussing on building scalable data foundations - investing in a Customer 360, defining how data from different systems connect and identifying and resolving data quality issues. Something that I had suggested in the first place!

Here's the raw truth: Executives want quick results with minimal investments. They don’t understand why data foundations matter, and they absolutely hate how long building them takes. Can you blame them? They're being bombarded with articles screaming that "AI laggards will die!" while their board members return from Davos asking why competitors are doing cool AI things and they aren't.

The second ugly reality? Most "data transformations" are just glorified IT projects. This usually happens when technology leaders drive the agenda. With vendors constantly coming out with shiny new tools and selling FOMO, it's easy to mistake buying tech for actual transformation.

I've seen companies drop millions on data lakes, visualisation tools and data mesh platforms only to end up with data swamps, low platform expansion and expanding their spreadsheet farm by adding Tableau/PowerBI reports. Tech & tools matters, but they are just enablers.

Let's be brutally honest: transformations are hard. McKinsey says 70% fail. For data transformations? I reckon it's closer to 80-85%.

What separates winners from losers? The successful data transformations I've witnessed weren't about technology at all—they were fundamentally change initiatives. While AI is genuinely disruptive (and I'm not downplaying its potential), the real challenge isn't implementing AI models or turning on Microsoft Co-pilot. It's rewiring how people make decisions, redesigning core business processes, and sometimes completely transforming business models.

Playbook || Data -> Insights -> Action

After watching a few data/analytics/AI transformation projects implode spectacularly (and cleaning up the wreckage of many more), I've put together this playbook that actually works. Nothing fancy – just an approach and practical tips that I have learnt from my experience. While many of these may seem obvious, it’s surprising how many companies ignore the obvious and chase the exotic.

Building the case - Clearly define the “Why”

Your CEO doesn’t really care about a data lake or an AI model. What they really care about is to make more money, stop bleeding money, and keep customers & stakeholders happy. Everything in your company should be in service of those goals, including your data transformation.

As CDO, your first job is to figure out what problem you're really solving. Your problem statement can’t be a motherhood statement like "become data-driven”; you need to find real business problems that keep executives up at night (am sure there are plenty around).

The formula is pretty simple

1. Pick the biggest specific business problems in your company (revenue drop, customer churn, operational bottlenecks, regulatory scrutiny)

2. Quantify the pain ($$ lost, time wasted, opportunities missed, fines incurred, reputational damage)

3. Get specific about how data/analytics/AI will actually fix it, inc. defining clear success metrics

Bonus points if the metrics in your business case should be tied to your CEO’s bonus.

You also need to find a way to frame and articulate the business case in very simple terms and create an elevator pitch. And you need to communicate this to everyone involved again and again and again. When someone asks "why are we doing this?”, everyone from your data analyst to your CEO should be able to answer this question, hopefully with the same answer.

Side note on technology disruptions: It’s perfectly fine to want to jump on the bandwagon and position your company as an early adopter, even when the strategy and benefits case is not 100% clear. To be successful, the trick is to clearly define how these technology disruptions can be harnessed towards business value.

As an example, frame your GenAI initiative as ‘To address service performance issues, use GenAI to automate sentiment analysis & service quality analysis in real-time from voice calls made to the call centre, and implement a workflow to provide real-time feedback to the contact centre agent and team leader. Expected improvements include 15% increase in first time resolution, resulting in reduction of $1.75m agent time, and 20% improvement in NPS’.

The strongest business cases aren't about the technology at all – they're all about connecting data analytics capabilities to tangible business outcomes in ways even your most technically ignorant executive can understand and care about.

Executive sponsorship - Get authority from the right person

Now that you've built a solid business case that connects data & analytics to actual business outcomes, you need someone with enough organisational firepower to make it happen. Even the most brilliant business case if useless if you don’t have the right executive sponsoring it.

Directors of Analytics or mid-level management sponsoring a project driving change across customer, marketing and sales is like a Stockman on an Australian cattle station trying to muster cattle with a feather. Sounds harsh, but it’s true. Weak sponsors kills projects. Weak sponsorship can take form of absent sponsors, sponsors without enough power to influence the organisation, or sponsors who aren’t bought into the need for the project.

I learned this lesson the expensive way. Five years ago, I led a data governance initiative with the enthusiastic backing of our Head of Marketing. We had quantified the business case perfectly (as I outlined above)—poor data quality was costing us $3.2M annually in wasted marketing spend. Everything was great until we needed IT to change their data collection processes. The CTO, who hadn't been brought in early, simply said "not a priority”. The Sponsor, our Head of Marketing, tried his best but he was too organisationally weak to make any difference. And that was that. Project flatlined. Three months and $400K down the drain because I had the wrong sponsor.

The ideal Sponsor is one who has influence over all impacted parts of your company. For many data analytics projects, this in theory translates to the CEO being the sponsor. But is the CEO really going to care about your piddly customer segmentation project when they have a large company to run and shareholders to satisfy - realistically, no. In most cases, your CEO would be an absent sponsor which you don’t want.

Your best option is a C-level executive with both political capital and staying power. This needs to be someone who benefits directly from your project so they have a vested interest in the success of your project. Also, don’t pick a shared services Chief (e.g. Chief Strategy Officer, Chief Operations Officer etc.) to deliver a project that delivers benefits across business units. In my experience, this is the worst thing you can do and this often results in the change project being executed (or at least perceived) as an ivory tower, and lack of buy-in from the business units.

Meet with your sponsor and make sure they understand what they are signing up for. Your sponsor needs to act as your cheerleader and must be willing to defend you and your project in times of crisis, make sure you explain this and they are willing to sign up for this. Explain what changes your project may deliver, especially if it involves people changes and get their support. Set clear expectations and outline and the level of commitment you require, and agree on a cadence, roles and responsibilities and ways of working between you and your sponsor.

In case you can’t find a single executive to sponsor your project, have two executives to act as joint sponsors. While am not a huge fan of multiple sponsors and I believe strongly having only one decision maker, having joint sponsors can sometimes be the only way to secure executive commitment to your project. You just need to make sure you set expectations from the two sponsors clearly and define a RACI if required. Be prepared to negotiate outcomes between the sponsors in cases of conflict. A co-sponsorship model can be used effectively to drive transformation, but it often means more work for you, so keep this in mind.

Push back hard against any notion of having more than one or two sponsors. I once led a transformation project that was co-sponsored by 4 out of the 7 Chief’s in our company - needless to say the project didn’t go well and my mental and physical health suffered greatly during this period.

Remember: weak sponsors = expensive failure + poor mental wellbeing. Strong and supportive sponsors = probable success + a good night’s sleep.

Get the right leadership in place

Your next job is to assemble your leadership team. You need a balanced group of specialists who can tackle different aspects of this complex challenge. Don’t be tempted to set up roles that wear multiple hats.

I've usually start with the following key roles while initiating a project:

1. Data Transformation Lead

• What they do: Overall accountability for delivery, stakeholder management, roadmap ownership

• Key traits: Political savvy, executive presence, communication skills, decision-making ability

• Background: Often an external hire, previous experience as an executive or Senior Director. I usually do not recruit generalist project managers.

• Red flags: Avoids conflict, gets lost in technical details, can't communicate with executives

• Reality check: This person should spend 60% of their time managing up and across, not down

2. Business Lead

• What they do: Ensures solutions actually solve business problems, manages expectations

• Key traits: Domain expertise, credibility with business users, analytical thinking

• Background: experience in frontline and senior operational roles in the business, passion and experience in using data and analytics in business operations. This person has to come from within the business and cannot be an external hire.

• Red flags: Can't challenge what the business think they want vs what they really need (everyone wants a faster horse), doesn't understand data analytics technicalities and limitations

• Reality check: This person will save you from building technically brilliant solutions nobody uses

3. Data & Analytics Product Manager

• What they do: Define products strategy and roadmap, design reusable and fit-for-purpose products and manage lifecycle from development to launch to ongoing maintenance

• Key traits: Deep data analytics acumen, product mindset, domain expertise

• Background: This is an upcoming role in the industry. I usually look for people who can demonstrate experience delivering business outcomes with data analytics. This is typically not a data engineer, but a business aligned data/business analyst, business lead, or a business operations leader. Prior product management experience is not essential as this can be taught.

• Red flags: Analysis paralysis, emphasis on technical features as opposed to business features

• Reality check: Balancing innovation vs data governance/risk is a constant challenge.

3. Data Architect

• What they do: Technical strategy, architecture decisions, platform selection

• Key traits: Systems thinking, pragmatism, ability to simplify technical complexity

• Background: previous background in hands-on engineering roles and experience working at a program level. I usually avoid hiring candidates who resemble ‘enterprise architects’ as they operate at a very high level and aren’t willing/able to deign practical solutions and clear blockers

• Red flags: overcomplicated solutions, "perfect" being the enemy of "good”, inability to communicate plainly

• Reality check: You want someone who's built and scrapped several architectures, not a theorist

4. Change & Adoption Manager

• What they do: User adoption, changing behaviours and mindsets, implementing new ways of working

• Key traits: Empathy, high EQ, enthusiastic and high energy, ability to deal with people (harder than you think)

• Background: Change managers stump me! I haven’t yet been able come up with a consistent way to find great change managers. All I know is finding great change mangers is more challenging than finding any other role in my teams. So my approach these days is to cast a wide net and be open to candidates from any background.

• Red flags: over focussing on delivery aspects of change (ticking checkboxes) and not enough on people

• Reality check: Without this role, you'll build things nobody uses or understands.

Did you notice a pattern in how I recruit key leaders - I tend to avoid people who are just capability experts. Instead I look for domain experts who have experience in applying capability to deliver business outcomes. As an example in interviews, most change managers will focus on developing change management strategies, change plans, stakeholder maps, organisational change load and change resistence heat maps. All these are no doubt very important but I look for change managers who will talk about how they improved their company’s ‘near miss incidents reporting rate’ by 20% in their first 3 months. Guess which one you want.

Realistically assess your company for change readiness

On my first day in my new company, 3 people make the following comment - ‘we have tried running a data change project 3 times in the past 5 years, all led by accomplished leaders, which have failed. The state of our data is still abysmal. Why do you think it’s going to be different this time?’. I quipped - ‘it’s going to be different this time because I am leading the project’. Needless to say I didn’t inspire much confidence.

The reality was my company was burnt by previous unsuccessful attempts to transform the way they use data. They were very cynical and had really low expectations. In its current state, my company wasn’t change ready!

You need to remove your rose tinted glasses and critically assess the following aspects of your company, and factor limitations into delivery of your project -

1. Readiness to Change

• Past transformation scars: If your company is littered with failed transformation attempts, expect resistance.

• Incentive alignment & decision making culture: Do performance metrics support data-driven decision making? If sales leaders get bonuses based on gut feelings, your fancy prediction models won't matter.

Change fatigue: Is your company already juggling multiple transformation initiatives? Adding another might just result in organisational exhaustion.

2. People Capability

• Are your data experts just Excel jockeys? Do they still hoard data and are resistant to a self-service model?

• Do people have basic data literacy skills and understanding of basic data concepts?

• Do your data teams have enough domain expertise or do they just have technical skills?

• Do you have enough people with skills to use modern tools e.g. cloud data platforms, pyspark, PowerBI

• Do you have people who are strong in data governance, risk and regulations? Not just on the policy side but also on the operational side

3. Technical Reality

• Data quality truth: Run actual data profiling on critical systems and understand how quality of data may impact your outcomes. If this is a real issue, you are better off starting with a data quality remediation program as the first step

• Integration complexity: Map data flows between systems to understand the real spaghetti mess you're dealing with. What looks like three systems on PowerPoint is usually fifteen with manual handoffs between them.

• Technical debt: Some legacy systems are duct-taped together so precariously that touching them causes cascading failures. Identify these landmines early.

4. Cultural assessment

Should you adapt your transformation to fit your culture, or push to change the culture? In my experience, you need to do both. The trick is finding the right balance.

Where culture is strong and positive: Design your approach to work within existing strengths. If your company excels at cross-functional collaboration, leverage that for data governance.

Where culture is toxic or counterproductive: Be explicit about the behaviours that need to change and build them into your transformation plan. If hoarding information is rewarded, you'll need specific interventions to enable data sharing.

Your assessment doesn't need to be perfect, but it needs to be honest. False optimism is your enemy, and in particular plagues people who have been at a company for a long time and hence are institutionalised - avoid this at all costs.

5. Define a Realistic implementation roadmap

The glossy roadmap your consulting vendor created might have helped you sell your business case, but you can be assured this is worthless for implementation purposes. The other risk you need to watch out for is overly positive assumptions in your roadmap - most things in enterprise companies take much longer than you expect, so you need to make sure you don’t commit to unrealistic timelines that ignore operational realities.

A viable roadmap acknowledges that Rome wasn't built in a day—and your data transformation project won't be either. The organisations that succeed understand that transformation is a marathon disguised as a series of program increments and sprints.

Here are some practical tips based on my experience -

• Run a 2 speed delivery process: one that focusses on delivering quick wins and the other that delivers foundational, complex and medium-long term objectives based on rigorous planning and project management. Delivering value quickly and consistently keeps the wolves at bay while you properly mobilise and plan your project for delivery.

• Align your roadmap to business outcomes and not technical features. Do this even in cases where extended time is required for building foundations.

• Always have a ‘plan on a page (PoaP)’ that shows all moving parts and dependencies at a high level, and tie detailed implementation plans to this PoaP.

• Use dates and milestones: dates and milestones can be used very effectively to drive a sense of urgency and galvanise teams to come together. However use these sparingly, as you risk burning people out.

• Make work and outcomes visible: Use tools like Jira to make work and priorities transparent to everyone, and implement simple & consistent reporting that shows progress against business outcomes. This should be consumable by both technical and non-technical stakeholders to maintain support

• Build shock absorption into your roadmap: keep some buffer up your sleeve to protect against delays. The risk is every person and team will likely build fat in their estimates. Make sure detailed plans are as fat free as possible, and bubble up as much fat as possible to the program level.

• Build in explicit recovery periods: After each major deployment, schedule 2-3 weeks for stabilization before starting the next phase. Teams that rush from milestone to milestone burn out by Phase 2.

• Allow time for transition to BAU and hypercard: a 2 week hypercard and transition plan is not sufficient for even the most simple of projects. A key part of your transformation project is transitioning capability into BAU, and making sure this is well embedded. Incorporate time for training, parallel runs, vendor transitions etc.

6. Change management strategy

You can create the best analytics models and you can execute the best transformation project, but they mean absolutely nothing if Elaine from finance is still exporting all data to her Excel models because "that's how she’s always done it."

Here are few practical tips to make sure you don’t end up building expensive shelf-ware -

• Map your organisational antibodies: Every organisation has "antibodies" that attack change. Identify who stands to lose power, budget, or comfort if your project succeeds.

• Speak stakeholder’s languages: Your data engineers care about CI/CD. Your CFO cares about cost reduction. Your sales team cares about closing deals faster. Translate your project benefits into whatever currency matters to each group. Lesson I learnt the hard way - don’t explain the benefits of data modelling to the marketing team!

• Create a coalition of the willing: Find and nurture your early adopters. Give them extra attention, training, and resources. Their success stories will create FOMO and convert the skeptics better than any slick slide deck.

• Build a communication drumbeat: Silence breeds rumours, and rumours breed resistance. Establish regular touch points—weekly emails, monthly town halls, whatever—even when you think there's nothing to report. "We're still on track" is valuable information to people whose work lives will be disrupted.

• Anticipate the Valley of Despair: You start your transformation at the top and there’s excitement and optimism. As the reality of the challenges sets in, progress seems slow, and frustration increases, leading to a "valley" of low morale. Plan for this dip and keep morale up by providing your team with required support, consciously celebrate small wins, introducing small team events, reinforce your vision and make sure key leaders are visible and motivating people.

• Don't mistake training for adoption: Just because people attended your training doesn't mean they'll use your new system. Build adoption metrics into your roadmap and track them religiously. I've seen beautiful dashboards with precisely zero unique visitors after the launch meeting.

Change management is by far the most important factor that determines benefits realisation (or not). As the CDO, you need to pay special attention to this aspect of your transformation. Because when your project ultimately succeeds or fails, it'll rarely be because of your perfect data platform. It'll be because you either won or lost the battle with human behaviour.

Key Takeaways

Tie Data Initiatives to Real Business Value

Don’t start with tech. Build your case around tangible business problems, quantify the pain ($$, risk, reputation), and explain in plain language how data/AI will fix it. Your transformation pitch should resonate with both your CEO and frontline teams.

Secure Strong, Vested Executive Sponsorship

The right sponsor can make or break your project. Pick a C-level executive with authority, skin in the game, and staying power. Clarify expectations, commitment, and ways of working early.

Treat Change Management as a core activity

The biggest risk isn’t your tech stack—it’s human behaviour. Map resistance, build a “coalition of the willing,” align messaging to what stakeholders care about, and track adoption relentlessly. Change doesn’t fail because of tools—it fails because of people.

Share

This newsletter isn’t written by a fresh-faced consultant or a vendor pushing their latest tool.

It’s written by me, a real Chief Data Officer with 20 years of experience leading data, analytics, and AI transformations in large, complex enterprises.

I’ve delivered real value and transformed businesses. I’ve made hard mistakes. I’ve driven data transformations in financial services, utilities, industrials & consulting — in organisations where political savvy often mattered more than technical brilliance.

Why this newsletter?

I couldn’t find anything I liked that was written by a practicing CDO for practicing CDOs — so I started writing the newsletter I wish I’d had access to.

No fluff. No theory. No vendor or analyst spin.

Just brutal, battle-tested lessons from the frontlines of enterprise data. I’ll write about:

• War stories from the CDO frontlines

• Playbooks that actually work in large complex organisations

• Practical advice on AI, analytics, strategy, and culture

Who is this for?

You’re in the right place if you are -

• An executive wanting to use data to drive real business transformation

• A Chief Data Officer or Chief Technology Officer tired of surface-level conversations

• Or an aspiring CDO who wants to understand what this job actually takes