Matthew De George

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. 🙂