Category: Uncategorised

This is the table of contents for the new book.  At least it’s the ToC I am using while I write the first draft.

Table of Contents

Part 1: We aren’t all AI Companies

• Chapter 1: From a Light Bulb to a Disco
• Chapter 2: Imaging Future AI Commodities
• Chapter 3: A Dance of Stability and Change

Part 2: Minds and Reasoning

• Chapter 4: A Mind As An Organisation
• Chapter 5: An Organisational As A Mind
• Chapter 6: Unfamiliar Intelligence

Part 3: Correcting Wrong Turns

• Chapter 7: Do we really know how to manage technology?
• Chapter 8: How well do we really manage people?
• Chapter 9: Are we ever really clear about what we want?

Part 4: Rethinking for Co-Working with AI

• Chapter 10: The Difference Between a Co-Pilot and a Co-Worker
• Chapter 11: Co-working for creativity
• Chapter 12: Co-working with language
• Chapter 13: Co-working with coordination
• Chapter 14: Co-working with deciding

Part 5: Bringing Back Precision (this is SyFi)

• Chapter 15: Learning Down To the Roots
• Chapter 16: We are the words that we speak (precision in language)
• Chapter 17: Manage Without Them (precision in the management function)
• Chapter 18: Organisational Operating Systems (precision in the theory of the firm)

Part 6: Leadership Actions

• Chapter 19: Starting with Workforce Analysis
• Chapter 20: New Competency Centers
• Chapter 21: Leading and Managing For One
• Chapter 22: The New Accountable Executive

Part 7: Introduction to WorkSense Services

• Chapter 22: Why we do what we do

There is also ad associated YouTube channel for this book.  At the moment is it experiments and progress reports on the book itself.  

I’m also collaborating with Julio Graham for this book; as I have for SenseOfWorkPodcast.com.  

Back Cover Text (draft for inspiration while writing first draft)

Preparing for the AI revolution by rethinking organisational design as a metaphor of the mind

Organisational Reasoning rethinks how we design our organisations to incorporate emerging AI capabilities. The organisational challenge of artificial intelligence is not how to manage artificial humans; because we already manage humans today.

Our challenge is to build organisations that have the right mix of all of the available types of intelligence and the communication and control mechanisms required to operate, adapt, and evolve. We have been building our organisations with the assumption that a human-in-the-middle will be sufficient ensure value and mitigate risks.

There is an opportunity for the integration of AI into our organisation to be source of human flourishing, to bring back the intrinsic joy of work, and to shift mundane tasks towards discovery and creativity.

But to capture this opportunity we need to build organisations that transcend traditional structures, envisioning organisations as dynamic, intelligent systems capable of unprecedented adaptability and innovation. The metaphor of an organisation as a reasoning mind might be the best tool we have to start this journey.

We know a lot about how organisations work but have dismissed much of the science of organisation design as we focused on human-centric models. This book reveals how embracing these previously sidelined approaches can dramatically enhance our readiness for AI integration, by designing organisations not just with humans in the loop but as collaborative ecosystems where humans and AI amplify each other’s strengths.

At its heart, this is a manifesto for a transformative shift in workforce planning and organisational design. It’s about reimagining roles, relationships, and structures to create a future where organisations and AI collaborate seamlessly, driving towards shared goals with efficiency and creativity.

“Organisational Reasoning” is a guide to navigating the next frontier in organisational development. Prepare to rethink everything you know about organisation design, workforce planning, and the role of AI in shaping the future of work.

Building a customer-oriented business means going beyond the specific business units that have contact with customers. A customer-oriented business is customer-oriented in the back-end as well as the front-end.

But it’s also not enough to declare slogans – “put the customer in the centre of everything we do” – we must invest in specific business capabilities that keep the organisation aligned to the values of our current and future customers.

These 5 principles must be in place across your organisation – and in each case the business unit(s) responsible for promoting and implementing these principles must be identified.  

1. Systematic Listening to Customers

Surveys are frustrating to your customers. Not only that but they only provide insight after a customer has already had a bad experience. The rest the time they are just reassuring you that the bulk of your customers of course have a positive (or at last not negative) experience.
You need to establish systematic listening platforms that ensure that every customer interaction leaves at foot-print in your customer data system that can be used to proactively measure how you customers are experiencing both your service channels and your products.
Tight integration between your digital channel systems, your partner systems, and your customer data system means your organisation to listen to customers systematically and push those insights into service points, performance management processes, and even businesses cases for new initiatives.

2. Measuring from the Customer’s Perspective

Traditional balanced scorecards attempt to add a customer perspective to your internal, financial, and innovation performance measures. While addressing an important gap in measurement this left the customer perspective as a seperate and distinct dimension competing with other measures.
How you measure your performance should be unique to your operating model, not based on a selection generic or vanity metrics that only measure what you know you are investing to improve. If you have a unique set of performance measure that make specific sense to your business model you are then measuring to differentiate rather than measuring to compare.
For the customer measures this means evaluating all internal, financial, and innovation measures from the customer’s perspective – not just adding new customer-specific measures. We recommend establishing a “customer-return on operations” metric that uses a secret formula, specific to your business, that aggregates these relationships into a single number.

3. Personalisation by Default

Popular agile delivery approaches focus on maximising the ability to change as requirements change. This approach has improved IT / Business alignment and created significant improvements in throughput and cost control.
But the most important feedback loop isn’t between your IT department and your other business units, it’s between your business capabilities and your customers. Focusing on agility at the expense of adaptable products and services means that continuous delivery is the only solution to an evolving understand of customer needs.
Design all processes, systems, and products with the assumption that they will be personalised and must adapt as they are used. This approach extends the techniques your technical teams call “agile” and “DEVOPS” beyond Business / IT alignment to Business / Customer alignment.

4. Double-sided Digital Teams and Channels

First generation “Digital” teams focused on the digital channel. These teams established new digital capabilities that mirrored customer-centric online start-ups. This approach left digitisation of back-end systems and processes to other teams.
Organisations with mature digital channels know that it’s back-end systems and legacy processes that now have the greatest impact on customer engagement. As organisations re-integrate their digital teams into their core operations they can address these legacy challenges and improve both customer and employee engagement.
Double-sided digital teams have customer journeys on one side and employee journey on the other. Digitalisation initiatives then become an orchestration between these two sets of journeys; enabled by data, analytics, and digital backbones connecting both business processes and IT systems.

5. Continuous Delivery Mark II

Organisations that take their agile initiative from the IT department to the enterprise level make a significant change in the approach. Where agility from an IT perspective means maximising throughput and leaving the prioritisation of value to others, an enterprise level approach must address value discovery.
The types of coaches and delivery partners you needed to establish IT-driven agility will be different to the types of coaches you need for Continuous Delivery Mark II. Bottlenecks will no longer be technical, or resource-based. Bottlenecks will be in systems design and in the evaluation of experiments.
“Fail fast” techniques need to be shifted to “fail local” and for some markets and customer segments “don’t fail at all”. This integration of business risk into customer-facing innovation will be the ultimate intersection between human and machine intelligence for modern corporations.

Part of The Beginning and The End of Information Management.  

Organisations have a habit creating silos and then being delighted and self-congratulatory about the value of bringing them back together.  

We forget that “silo” is just another name for “team” and your organisation will always be made up of more than one team.  Sometimes a “silo” is a team that doesn’t play well with other teams, and sometimes a “silo” is just a team that shouldn’t exist.  If you have the wrong portfolio of teams they will all be considered silos but that’s not an attribute of each of the teams it’s an attribute of the structure itself.

This particularly impacts data management because most of the high-value data management effort will be cross-business unit effort.  If data management could be performed in a single business unit it wasn’t be difficult – it’s always something that involves multiple business unit. 

We build functional organisations and then marvel at the value of cross-functional teams.  Henry Mintzberg has mused that we structure our organisations like we structure our business schools.  We have HR departments, and Finance departments largely because we have business schools that make people specialise in Human Resources and finance, and they then want to build organisations that they can shine in.  

This to me is part of a broader problem of organisations managing themselves for the benefits of their managers rather than rationally or at least cohesively.  This is a topic for the Manage Without Them book and ManageWithoutThem.com.  But it’s important to understand the principle, often referred to as the Conway’s Law that “Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure”^⁠1 

Here we address the first problem with typical approaches to information management.  If you haven’t heard it already, lots of people will soon want to talk to you about “metadata”.

In the strictest definition, metadata is simply “data about data”.  It’s descriptive of the content, rather than the content itself.  It’s actually a reasonably useful concept when you first think about it because you need to be able to describe your data; including its features and business context.  

However, there are two problems with the concept of metadata.  I think both of these problems cause the word “metadata” to effectively kill any conversion it’s included in.  

Metadata is broad. So it can be used as shorthand.  This is the first problem.  There are a number of very different types of information that can be classified as “metadata” so any time one of these is referenced, or a question is raised about how it might be managed – it’s summarised as “that’s metadata management”, which is close to meaningless.  

But it gets worse.  Because of Conway’s Law (I presume) we split metadata into “business metadata” and “technical metadata” at the first level.  By “at the first level”, I mean if you were to structure the different types of metadata as a hierarchy with a series of branches, you end up with the first split being “business” versus “technical”.

When you are trying to get two groups to work together, the worst thing you can do is tell them explicitly as your first action that there are things of concern to you and there are things of concern to “them”.  The above view of metadata – splintering in the first instance to “business” and “technical” does exactly that.  

It’s worse when you consider how broad the concept of metadata actually is.  It’s too broad, and again that’s the first problem.  That this breadth of meaning can first be used to encompass just about everything and then be used to split everything down the middle is the second problem.  

If you immediately split everything down the centre, without first creating a set of layers that all groups are obliged to develop a shared understanding of, you destroy collaboration.  You are basically telling business units and I.T. to work in seperate silos.  You’ve used your best chance at promoting collaboration to destroy it.  

The first step is to ban the use of the word “metadata” from your information management initiative.  Kill it now.  This will force you to be specific.  Say what you mean.  Write what the person asked about in your notes rather than abbreviate it to “metadata”.  Never think you are adding clarity be making a vague distinction between “technical” and “business” metadata because you aren’t thinking hard enough when you do this, and you certainly aren’t setting yourself up for effective change and transformation.  

Even though you shouldn’t be saying “metadata” at all, you still need to consider what the uppermost split in concepts should be.  If not “technical” and “business” what should the top levels of a conceptual hierarchy actually be?

For starters you might consider using the top levels of your hierarchy to seperate the different data assets you have!  That would be good start for an information management initiative.  

In reality it’s not helpful to think of a hierarchy at all.  There are more interesting and useful relationships between different parts of your information environment that will feel natural once you understand them.

Though if you wanted to show the top-level split of the sort of “data about data” you need to maintain it would be more like this:

The concept of “your Enterprise Information Model” is covered later in this book.  It covers the areas above – not as a hierarchy but as a set of artefacts that you’ll have to build, revise, and maintain to promote collaboration around your data assets.  

In some ways the above view is more complicated than the first view of metadata split neatly into business and technical metadata.  But it’s also more specific to your organisation, it’s richer in what it conveys.  It also promotes collaboration by not splitting into business and technical categories until the lowest possible point (if at all).

By allowing the complexity of your information to be captured this approach provides you with a valuable tool for managing that complexity.  If you don’t start managing complexity – rather than avoiding it – your information management initiative will fail to deliver the promise of value that initiated it.

1. ¹ 1 Conway, Melvin E. (April 1968), “How do Committees Invent?”, Datamation, 14 (5): 28–31,

Operating model design benefits from an initial workshop to understand the context of the operating model.  These things will come up naturally in any discussion with the executive team.  However, if you want to use a canvas style approach to ensure all areas are covered the below canvas is a good staring point:

Update: I get it now! See comment here: https://statisticsbyjim.com/fun/monty-hall-problem/#comment-9601

Like everybody else, my head spins thinking about the Monty Hall Problem. And like everybody else my intuition gives me the “wrong” answer.

For those not familiar with the problem, the unintuitive solution, and the logic behind the solution, this is a great overview: https://statisticsbyjim.com/fun/monty-hall-problem/

Although that explanation is excellent, I think it’s wrong. I know that means I’ll get lumped into all of the other people who don’t get it – so I’m going to briefly explain why I think it’s wrong.

Everybody who explains the solution goes to great lengths to explain the probabilities at the beginning of the game, the number of possible games, and how it changes because you know the host is going to reveal an empty door at some point in the game.

This is all true and I agree with it all – but I am drawing different conclusions from it. So I think the other explanations are wrong in two ways:

1. It is proposed that at the beginning of the game there is a one in three chance of choosing the correct door. This is true, but also at the beginning of the game you already know you will reach a point where a door is open, it’s not the door you have chosen, it doesn’t contain the prize, and there is only one other door. This means at the beginning of the game you already know you have a one in two chance of having already choose the correct door. This is the staring probability of choosing the correct door.

2. The explanation at the link above also says there are only nine possible games. This isn’t true. There are 12 possible games. If you say there are only nine possible games you are missing three scenarios where and you have already picked the right door, so each scenario has two possible games as the host could open either of the other two doors. So, while you know the host will always open a door you can’t ignore the addition three games. This is because all of the games you are ignoring are the games where changing doors will cause you to loose.

The total 12 possible games are shown below:

As shown above – there are 6 games where staying with the same door wins, and 6 games where staying with the same door looses.

If you start ignoring games “because they don’t matter” then they don’t matter at the beginning of the game and your starting probabilities change.

This is some fairly stock standard copy for the corporate blog…

We were at least 20 years into an Internet-fuelled digital disruption before the COVID-19 pandemic abruptly destroyed all of our excuses to not change. Agile delivery approaches, customer-first investment, data, and cloud-first technologies, were already acknowledged as the critical enablers for digital transformation. The organisations who were the most advanced in their digital capabilities were also the most effective in their response to these sudden changes. Elsewhere, we saw just how fragile our interconnected global supply chains could be when financial and non-financial risk scenarios hadn’t been fully accounted for.

Agile delivery is has been proven as a key component of how organisations innovate and respond to change. But we believe the time is quickly approaching where agile becomes business-as-usual and the competitive advantage that can be derived from agile, “new ways of working” initiatives is reaching diminishing returns.

To survive and then thrive, businesses must not only provide superior experiences for consumers, customers, employees, and citizens, but deliver on their promises in a faster, more innovative, nimble and trustworthy way to meet new expectations and needs.

McKinsey recognised early that “The COVID-19 recovery will be digital”. Their surveys showed that “…we have vaulted five years forward in consumer and business digital adoption in a matter of around eight weeks…”.

But what is even more striking is how these changes have been unbounded by the structural silos within our organisations. McKinsey (see article link above) cites examples of:

• “Banks transitioned to remote sales and service teams”
• “Digital outreach programs launched to customers”
• “Increased flexibility in payment arrangements for loans and mortgages”
• “Shifts to online ordering and delivery as the primary business of supermarkets and grocery stores”
• “Schools and universities shifting to online learning”
• “Doctors delivering telemedicine”
• “Regulatory changes rapidly implemented to enable more flexible employment contracts, trade, and operating model changes”

These types of shifts require all business units to take the lead.

Agile development approaches were developed as a response to the overly complex, document-heavy approaches that once dominated software development. But it’s been over 20 years since The Agile Manifesto was first signed at a ski resort in the Utah in February 2001.

Agile approaches are now the dominant approach in a majority of technology departments, and in some cases specific organisations have developed operating model changes which allow the approach to be extended to other parts of the enterprise.

The level of commitment and success rate of enterprise agile initiatives has been varied. But operating model innovation itself is always difficult and just to see organisations consider the way they work as an important source of competitive advantage has been encouraging.

Missing Alignment

The missing pieces of the agile approach have started to show as adoption spreads and scales. Part of the success of agile for IT and software delivery can be attributed to simply getting out of the way.

Software developers stopped hiding behind elaborate development processes that required top-down agreement of high-level requirements, followed by a sign-off, followed by detailed designed – again, which required a sign-off.

At any point in the old process, if something from a previous step changed the whole process went back to that step. This meant it was often months before any software was even developed.

But the bargain agile makes with other business units is that they will value responsiveness to changes – which is a certain specific type of agility, at best – over trying to predict what is required.

Know what you want? We can do that right now if it’s the highest priority thing you want to do. But ask why it wasn’t done that way in the first place and the answer is likely “nobody told us”.

Agile is a success because it gives somebody else the responsibility of knowing what to do, it doesn’t judge too harshly when mistakes are made, and it responds rapidly when changes are required.

What agile isn’t very good at is acknowledging that it’s difficult be the person that the agile team relies on prioritise the work, to make trade-offs, to know what’s required, to understand dependencies with other teams, and to make the executive commitments that the agile team is unable to make under their approach.

Supporting “product owners”

The person the agile team might call their product owner always has other responsibilities and priorities. They wouldn’t be a good product owner if they didn’t have other responsibilities.

But they might not have the influence over other teams that the agile team wants them to. The perfect product owner doesn’t exist for all the same reasons the perfect design document never existed, and more. Organisations are complex – there is risk, uncertainty, and change.

Reaching for Alignment

Agile teams sometimes take the perspective that the rest of the organisation is there just to provide them with clear requirements, user stories, and priorities so that they can do the risk.

But that’s not why the rest of the organisation exists at all. It exists to serve customers, be accountable, manage risk, implement change, consider the future, manage diverse teams, defend budgets…

Alignment with organisational goals and strategy is almost entirely outsourced by agile approaches and is at the heart of both which capabilities are invested in, and how they are invested in.

Alignment is about taking the organisations market position and strategy, and then deploying that strategy. As part of strategy deployment, any gaps in business capabilities are then addressed via an end-to-end approach the considers the people, process, information, and technology impacts for each business capability.

Powered by Awareness

Our organisations have bifurcated, as they often do, into those deciding what needs to be done and wishing they could be more certain about those decisions, and those doing what needs to be done and striving to be more agile.

We believe that between agility and alignment is a missing competency that combines the power of direct feedback from your customers, and a data-driven approach to decision-making, to continuously optimise how your organisation operates.

Awareness recognises that when people have the right information, they make the right decisions. By removing the idea that some people decide and other people do, you can focus on ensuring the information required to make the right decision is right their when you need it.

But Awareness goes beyond how you make decisions internally. By implementing dynamic, digital-first channels you create a direct feedback loop as you service your customers.

This feedback looks puts the capabilities of your organisation in the hands of your customers. It gets out of the way and allows internal processes to respond and optimise based on customer data that is continuously being integrated from customer channels.

This once seemed far-fetched but is already happening across hundreds of global organisations. What we might call The 3A Enterprise has the foundational capabilities to enable this shift.

Just for the record. I’ve read the proposed legislation and skimmed Facebook’s initial response during the consultation period – and I think they are right to disable the sharing of Australian news on their platform.

In my view, the proposed legislation appears to be saying:

1. We’ll created a government process, administered via the ACCC, to allow news companies to be formally registered

2. Once a news company is registered it can enter into a mandatory bargaining agreement process with a digital platform company (such as Facebook) to resolve issues – including issues relating to renumeration for sharing news content

3. During this mandatory negotiation consideration must be made for how much it costs to produce the news content and that might become part of a proposed compensation paid by the digital platform provider to the news organisation

4. If they can’t negotiate a renumeration between themselves a mechanism exists in the legislation to have both parties submit a proposal and then one of those proposals its chosen and must be complied with

5. There are a number of other obligations for digital platform provides to notify news organisations if they are going to change their algorithms or anything else that might impact how the posts of news organisations are are displayed, the control the news organisations have over comments, and to respond to various information requests from news organisations

Facebook appears to be saying in response:

1. Facebook aren’t using the content of newspapers unless it is shared – either by the news corporation itself or by another Facebook user linking to external content on the news providers website

2. If a news corporation wants control over what is shared that functionality is available on the Facebook platform if they set up a page – and they can choose not to share if they don’t want to

3. If other Facebook users are sharing content owned by a news organisation then this content isn’t scraped or taken from the news site except to show a preview, and all pay walls are respected – so they are sharing a link to the news organisation’s site and they can prevent access to the content if they want

4. Facebook and news organisation are competing for advertising revenue and this legislation is taking sides in that competition

5. It’s not clear that Facebook benefits from the sharing of news; and it believes that it drives traffic to news organisation’s websites to their benefit

So, Facebook has said the wording of the legislation appears to mean that any any point they might be forced to negotiate payment to news organisations even though they don’t believe they get a benefit from sharing. So they choose not to share so they don’t risk being forced into mandatory negotiation.

I might change my mind as I learn more. But at the moment I think they are making the right decision and a decision within their rights.

Update: Good discussion and thoughts from clever folks on LinkedIn where I shared this post.

Update 2: This article and this article are both better than my blog above. 🙂

 

I live in a small seaside town about an hour out of Sydney. My wife and I have lived here for about 12 years. I still get grief from her for not even bargaining the owners of our house down when we made an offer. I just offered to pay them what they asked for. Why wouldn’t I? I wanted to buy their house and I had a healthy libertarian respect for property rights and what it might take to make a family give up their home.

By the time COVID hit we’d lived in the area for over a decade. We didn’t know many people but that was more a function of how my wife and I seperate ourselves from the world than a reflection on the people in the area. Everybody we have connected with is lovely. It’s a great area filled with people who know they made a trade-off living a little further out of the city.

As we get closer to the end of the year we all find ourselves running on fumes. As a consultant I have billable time and non-billable time. So when I found myself in non-billable time just a week before my Christmas leave I knew the chances were I’d be only as busy as I forced myself to be.

So I still spent the morning working on our company’s go-to-market proposition. Part of my job is to ensure the market understands who we are. We don’t have to say it explicitly. Nor do we even have to know who we are. But we need to show it. We need to be transparent about who we are even if we struggle to articulate exactly what that is. It’s a difficult balance but we are committed to it.

After my morning thinking about who we are as a company I spent the afternoon trying to clear my head. I had a few beers – a surprisingly rare lunchtime treat for me during the COVID work-from-home age. Then I had a
wander around our local area.

When I got hungry and wanted to reward the risky “2nd Best Burgers in [my area]” sign-makers I dropped in for something to eat at a tiny bar that had only just opened when COVID lockdowns began.

I consult to medium to large business in Australia and the greater Asia Pacific. So I’m in the habit of knowing how value is created. I casually noted that “you guys started at just the wrong time” when I paid for my delicious burger and pale ale.

But I was wrong. Our local hipster said “No. We didn’t really have an established business model”. He’d started the business with just himself and the chef. He’d made many more meat patties than he expected to when he started the business as the front-of-house guy. But ultimately they were able to pivot faster than the other local businesses.

For three months they ran a successful new takeaway business. Locals who didn’t know who they were before the pandemic were now embracing the business model that they were largely designing and changing as they fought to survive. “We noticed there were local takeaway food outlets but none who sold great burgers”.

My burger was delivered by somebody who understood that they had an advantage. He said “other local businesses had built up this idea that the physical space they occupied was the business”. In saying that he unpacked what we’ve all learnt about what a business actually is, or isn’t.

When technology startups tell you it’s all about pivoting towards the opportunities presented to them you might get the sense that they are faking it until they are making it. But that was a great burger – and everybody else I’ve seen walk into this joint has thought the same. I think the spirit of small businesses, thinking deeply about how they will respond to the needs they see in the market, will save us.

What we can learn from this is that we don’t know everything. Actually “we” know plenty – but we have to bring that knowledge together and recognise that there are those out in the world actually acting on less knowledge than we think we have to make delicious burgers.

In terms of “The Second Best” I also can’t help but think of Matthew Arnold.

 

Part of The Beginning and The End of Information Management.  Now available for pre-order on Amazon.   

---

We live in the future. But we hold onto past ideas for too long. One of these ideas is that we should think of business processes before we think of technology or data.

This isn’t true. We should think of value, outcomes, markets, and a whole bunch of other important things and all of them are more important than technology by itself, data by itself, or business processes by themselves.
We have built functional organisations and filled them with people. So we’re going to get some perverse outcomes. People are good at that. It’s what makes our organisations interesting.

We spend so much time telling each other how business processes are more important than technology and data that it starts to feel like a discussion about value. But it’s not. Business processes, technology, and data are all equally important or unimportant. Each of them is only the most important thing to the functions and silos who are responsible for them. And there are only functions and silos responsible for them because that’s how we design our organisations.

But in modern organisations there are business processes, and types of business processes, and indeed whole business models, that can’t operate the way they are designed without the associated information technology. Likewise, all business processes depend on, generate, or coordinate with other business processes through data.

This means that at some level the idea that business processes “comes before” or are somehow conceptually “above” concerns about technology land data is no longer valid.

Justify the value of data

Imagine talking to the CEO of a nuclear power plant. You might say:
“Look, uranium is obviously critical to what we do around here.”
The CEO would nod in agreement or at least impatiently stare you into making your point.

“Well we’ve done a bit of a review and we’ve found some issues with the handling of the uranium. In fact, every time somebody goes near it we find it spreads. The Geiger counters are picking up radiation all over the plant.”
The obvious analogy here is with data: both critical to the operating model of most companies but also potentially risky if handled in the wrong way.
But if this situation played out like most data governance conversions it would continue like this:

“Okay, I know uranium is important. But what is the business value of it?” CEOs ask these sort of open-ended questions to uncover what you know, so this isn’t unusual.

“We it’s fundamental to how we operate. It’s a critical resource. Actually, because it’s a critical resource the way we manage it should be considered an asset. So these machines help us process it and the plant uses it to make power.” You’d feel like you are rambling now – and it’s not a very satisfactory answer but given this is a fundamental part of the operation of a uranium powered plant it’s actually hard to know where to start.
The CEO isn’t uninformed about the operations of the plant so he offers “So we have a cleanup crew for uranium incidents. I spend hundreds of thousands of dollars on this each year so I hope I’m getting something for it!”

This wasn’t where you’d start the conversation but it’s as a good a place as any so you offer “Yes, well that’s once something goes wrong. We need to be more proactive than that.”

“Yes, we need to be proactive. We want to innovate because our strategy is to be a leader in this area.”

“Great – yes – so the cleanup crew can help us once there is an incident but how do we ensure we handle the uranium in a way that reduces incidents?”
“Well we just switched suppliers so we’ll need to give them time to bed down their processes. They have productivity targets built into the contact so we should expect them to be more productive each year. Well they have to or I’ll cut orders from them! We wont tolerate breach of contract.”

You know that the supplier only handles the uranium to the delivery point, and the delivery points seem to be well controlled. Actually, there are a lot of controls in place, but some of them aren’t being followed, and some just don’t seem feasible to follow.

“Our suppliers aren’t the problem, it’s the way we handle the uranium after its delivered. Actually, there is a regulatory element to this too…”
“We want to be compliant!”

“Yes, but the readings we are getting all over the plant indicate that our handling may not be compliant”

“Darn regulators!”

“So let’s try to get compliant but at the same time let’s see if we can get business value from the compliance. There are a lot of sick days maybe they are related to the poor handling of the uranium.”

“I think that’s a cultural problem” the CEO is again attributing common actions across a large group of people to “culture” when you think he might mean “incentives”. But that’s another conversion. Anyway, he’s still talking.
“We need to get business value out of this initiate. I know uranium is important but what is the business value we are going to get form this initiative!?”

“Well at first we just want to contain the issue”

“What’s the ROI?”

“Well it reduces risk”

“Our risk appetite it low at the moment”

“So just to contain it we’ll need to slow down movement of the uranium at critical points and refurbish these damaged containment areas”

“How much will that cost?”

“$2 million”

“Well that’s a lot we don’t have that sort of budget allocated. These things always blow out we started an initiative 3 years ago and it was supposed to be $500k but it blew out to $800k”

“Well, actually this is just the first thing we need to spend, we’ll need to spend a lot more once we have a roadmap”

“I think we should do a roadmap first before we contain the uranium”
At some point in this conversation it’s the CEO that needs to be removed, not the data management consultant (Sorry, the person responsible for the uranium).

An important point: there is somebody in this fictional tale responsible for the uranium and having this discussion with the CEO.

Even if the conversation isn’t getting anywhere there is at least a significant budget allocation, a policy and process library, and a broad understanding across the plant about the dangers and proper handing of the uranium.
So if you’re having bizarre conversations like the one above – and they are about data, and not uranium – you’re at least trying to ensure that the value of data is understood.

But you’ll get into difficulty if you have to answer questions regarding “the business value of data”. The problem is not finding business value of data, the problem is realising that data has business value.
Data has a primary value.

Data isn’t only valuable because you can do specific things with it. Instead it’s valuable because you can’t do certain things without it. If you aren’t valuing the data you aren’t valuing the things you can do with it. If you have a car, and you want to drive it, you need wheels. The tires on the wheels need to be maintained. The business value of the wheels is the same as the business value of the whole car.

It’s hard to make an organisation think this way without sounding like what might be called “a data geek”. But it’s an important part of the transition you need to make into a data-driven organisation.

No organisation attempts to operate without people, but nobody asks “what is the value of people?”. We do have a variety of ways of managing people; including both disconnected performance management systems as well as a general consensus that all interactions people have with the organisation constitute a continuous feedback loop. But we’d never try answer such a general question as “what’s the value of our people?”

I.T. departments are unfortunately stuck in a service posture. They are stuck in the position of having to justify why something is important. You don’t need to do that for data. People know it’s important – when they ask about the value of data they are just messing with you.