The Designed Organization: Why Optimization is the Enemy of Performance

1
00:00:00,000 --> 00:00:06,040
Hello, my name is Mirko Peters and I translate how technology actually shapes business reality.

2
00:00:06,040 --> 00:00:09,920
Optimization sounds like a smart, disciplined move that defines strong leadership,

3
00:00:09,920 --> 00:00:15,440
but inside most organizations it is exactly how performance becomes slower and more political over time.

4
00:00:15,440 --> 00:00:19,240
When you improve one specific part without redesigning the entire system,

5
00:00:19,240 --> 00:00:22,880
you don't actually create flow and instead you just end up with local excellence

6
00:00:22,880 --> 00:00:25,320
surrounded by massive organizational drag.

7
00:00:25,320 --> 00:00:28,720
I want to make a very direct case in this episode because you cannot fix performance

8
00:00:28,720 --> 00:00:30,880
by simply polishing the individual pieces.

9
00:00:30,880 --> 00:00:34,080
True performance comes from designing decision flow, data movement,

10
00:00:34,080 --> 00:00:37,000
human interaction and power as a single operating model.

11
00:00:37,000 --> 00:00:40,840
And only after that structure is set, does AI actually become useful.

12
00:00:40,840 --> 00:00:43,720
If this system's level view helps you navigate your work,

13
00:00:43,720 --> 00:00:47,240
please subscribe as this episode closes out a much larger arc.

14
00:00:47,240 --> 00:00:52,640
Let me take one step back to explain why optimization became the wrong goal for so many leaders.

15
00:00:52,640 --> 00:00:57,040
The optimization trap, most leaders never wake up with a plan to fragment their company,

16
00:00:57,040 --> 00:01:01,560
but they often fall into a trap by making moves that sound completely reasonable on the surface.

17
00:01:01,560 --> 00:01:05,520
They might tighten up a governance policy or rollout co-pilot to a specific team

18
00:01:05,520 --> 00:01:09,600
and then they build a power automate flow to remove some manual work

19
00:01:09,600 --> 00:01:12,000
or standardize how files are named in SharePoint.

20
00:01:12,000 --> 00:01:15,240
Every one of those moves looks like a win when you view it in isolation,

21
00:01:15,240 --> 00:01:17,520
but that is exactly where the danger hides.

22
00:01:17,520 --> 00:01:20,640
Local intelligence is not the same thing as total system performance

23
00:01:20,640 --> 00:01:24,640
and from a system's perspective, optimization usually happens only at the edge

24
00:01:24,640 --> 00:01:26,480
of what a leader can actually see.

25
00:01:26,480 --> 00:01:29,040
A department head focuses on their own output,

26
00:01:29,040 --> 00:01:31,160
while IT improves security controls,

27
00:01:31,160 --> 00:01:35,920
and meanwhile, finance pushes for reporting discipline while HR focuses on policy compliance.

28
00:01:35,920 --> 00:01:38,920
Each function gets much better at protecting its own internal logic,

29
00:01:38,920 --> 00:01:42,160
but an organization is not just a collection of protected silos.

30
00:01:42,160 --> 00:01:44,760
The real value exists in the flow between those functions,

31
00:01:44,760 --> 00:01:46,320
and if that flow is badly designed,

32
00:01:46,320 --> 00:01:49,440
then every optimization starts acting like structural interference.

33
00:01:49,440 --> 00:01:53,280
One team might get faster only to hand their work off into a massive queue,

34
00:01:53,280 --> 00:01:58,240
or perhaps one function produces cleaner data that nobody downstream actually trusts or understands.

35
00:01:58,240 --> 00:02:02,720
We see platforms get better governed while decisions wait three extra days for approval,

36
00:02:02,720 --> 00:02:06,640
and departments automate tasks while the actual problem still bounds between inboxes

37
00:02:06,640 --> 00:02:09,360
because nobody redefined who owns the result.

38
00:02:09,360 --> 00:02:14,880
The business feels heavier and slower even though every individual team is claiming a major improvement.

39
00:02:14,880 --> 00:02:19,360
You have likely seen this in organizations with very mature Microsoft 365 environments

40
00:02:19,360 --> 00:02:20,920
where everything looks perfect on paper.

41
00:02:20,920 --> 00:02:24,360
They have clear governance docs, well-defined team structures,

42
00:02:24,360 --> 00:02:26,440
and dashboards covering every possible metric,

43
00:02:26,440 --> 00:02:29,080
yet execution still feels like waiting through deep mud.

44
00:02:29,080 --> 00:02:32,200
Decisions take too long, and context gets lost constantly,

45
00:02:32,200 --> 00:02:36,040
which leads to people rebuilding the same information in every meeting they attend.

46
00:02:36,040 --> 00:02:39,240
Reporting numbers change depending on who exported the data,

47
00:02:39,240 --> 00:02:43,160
and ownership becomes a blurry mess the second a project crosses a functional boundary.

48
00:02:43,160 --> 00:02:45,000
This isn't a contradiction or mistake,

49
00:02:45,000 --> 00:02:49,400
it is a clear design signal that the system is doing exactly what it was set up to do.

50
00:02:49,400 --> 00:02:53,800
The problem is that the system wasn't set up for the outcomes that leadership actually wants to achieve.

51
00:02:53,800 --> 00:02:57,640
This matters because most organizations still mistake visible maturity

52
00:02:57,640 --> 00:02:59,800
for actual operational capability,

53
00:02:59,800 --> 00:03:02,440
and they assume that if the tooling looks sophisticated,

54
00:03:02,440 --> 00:03:04,680
the organization must be sophisticated too.

55
00:03:04,680 --> 00:03:07,560
They believe that if governance exists, then control must exist,

56
00:03:07,560 --> 00:03:10,760
and they assume that if they have automation, they must have efficiency.

57
00:03:10,760 --> 00:03:15,560
None of that is automatically true because performance doesn't come from the quality of isolated components.

58
00:03:15,560 --> 00:03:18,360
It comes from the alignment between those components,

59
00:03:18,360 --> 00:03:22,280
but that reality is hard to see because local optimization provides immediate,

60
00:03:22,280 --> 00:03:23,960
tangible proof of success.

61
00:03:23,960 --> 00:03:27,640
A team can point to improved SLA numbers or a reduced manual workload,

62
00:03:27,640 --> 00:03:32,280
and a project sponsor can show a 100% rollout completion rate to prove they did their job.

63
00:03:32,280 --> 00:03:35,320
Those are real improvements, but they are still only partial truths

64
00:03:35,320 --> 00:03:38,520
because the business reality sits one level above those metrics.

65
00:03:38,520 --> 00:03:41,320
Performance lives in the questions we often forget to ask,

66
00:03:41,320 --> 00:03:44,200
like how long it takes to turn a signal into a concrete action,

67
00:03:44,200 --> 00:03:46,680
or how many times context has to be rebuilt.

68
00:03:46,680 --> 00:03:49,160
Before a leader feels safe making a choice.

69
00:03:49,160 --> 00:03:52,760
We have to look at how often people ask for permission because authority is unclear,

70
00:03:52,760 --> 00:03:55,400
and we have to measure how much work is happening through side channels

71
00:03:55,400 --> 00:03:57,960
because the formal route is simply too slow.

72
00:03:57,960 --> 00:04:00,520
That is where the health of your organization lives,

73
00:04:00,520 --> 00:04:03,480
and it isn't found in a dashboard showing a completed workflow.

74
00:04:03,480 --> 00:04:07,560
It is found in whether that workflow actually helped the organization move forward.

75
00:04:07,560 --> 00:04:11,240
This is exactly why AI is causing so much disappointment right now

76
00:04:11,240 --> 00:04:14,920
because we hear constant praise for smart models and fast outputs

77
00:04:14,920 --> 00:04:16,920
yet very little changes on the bottom line.

78
00:04:16,920 --> 00:04:21,320
The models aren't weak, but the organizations receiving the output are fundamentally slow.

79
00:04:21,320 --> 00:04:24,040
If an AI can generate a complex answer in three seconds

80
00:04:24,040 --> 00:04:28,520
while your business still needs three days to validate context and root approvals,

81
00:04:28,520 --> 00:04:30,440
then your constraint isn't a lack of intelligence.

82
00:04:30,440 --> 00:04:32,280
Your constraint is architecture,

83
00:04:32,280 --> 00:04:34,920
and this is where optimization becomes truly dangerous

84
00:04:34,920 --> 00:04:36,680
because it gives you the illusion of progress

85
00:04:36,680 --> 00:04:39,880
while protecting the very structures that create the drag.

86
00:04:39,880 --> 00:04:42,360
You keep improving the parts and the parts keep getting stronger,

87
00:04:42,360 --> 00:04:44,120
but the whole just keeps getting heavier.

88
00:04:44,120 --> 00:04:48,040
Once you recognize that pattern, the real question changes from what should we improve?

89
00:04:48,040 --> 00:04:50,520
To what kind of system are we actually running?

90
00:04:50,520 --> 00:04:52,200
What an organization really is.

91
00:04:52,200 --> 00:04:53,880
So let's answer that question directly.

92
00:04:53,880 --> 00:04:56,680
What are we actually running when we say we run an organization?

93
00:04:56,680 --> 00:04:59,000
Most people point to the obvious layer first,

94
00:04:59,000 --> 00:05:00,840
which usually includes the org chart,

95
00:05:00,840 --> 00:05:03,000
the departments, and the leadership team.

96
00:05:03,000 --> 00:05:06,280
They look at the tech stack, the policies, the governance model,

97
00:05:06,280 --> 00:05:08,920
and the set of tools everyone logs into every morning.

98
00:05:08,920 --> 00:05:11,240
But that visible layer is not the organization.

99
00:05:11,240 --> 00:05:12,440
It is just the packaging.

100
00:05:12,440 --> 00:05:14,680
The organization itself is a flow architecture.

101
00:05:14,680 --> 00:05:17,320
It is the way signals move, the way decisions move,

102
00:05:17,320 --> 00:05:19,160
and the way data moves through the system.

103
00:05:19,160 --> 00:05:22,760
It is how context travels between people and how authority shapes

104
00:05:22,760 --> 00:05:25,320
what is allowed to happen when those flows collide.

105
00:05:25,320 --> 00:05:27,240
That is what produces business reality.

106
00:05:27,240 --> 00:05:29,320
When a leader says they have a performance issue

107
00:05:29,320 --> 00:05:30,520
or an accountability problem,

108
00:05:30,520 --> 00:05:33,640
I usually take one step back because those are rarely separate issues.

109
00:05:33,640 --> 00:05:35,480
They are symptoms of the same design.

110
00:05:35,480 --> 00:05:36,680
From a structural perspective,

111
00:05:36,680 --> 00:05:39,240
an organization runs on at least three core flows.

112
00:05:39,240 --> 00:05:40,600
First, we have decision flow.

113
00:05:40,600 --> 00:05:43,000
This is the path from a signal to a judgment,

114
00:05:43,000 --> 00:05:45,320
then to a commitment, and finally to action.

115
00:05:45,320 --> 00:05:47,080
You have to ask who sees the issue first

116
00:05:47,080 --> 00:05:49,320
and who has enough context to actually decide.

117
00:05:49,320 --> 00:05:52,600
We need to know who must be consulted, who can say yes,

118
00:05:52,600 --> 00:05:55,160
and who has the power to stop the move entirely.

119
00:05:55,160 --> 00:05:57,000
The time a decision sits in uncertainty

120
00:05:57,000 --> 00:05:59,560
before something happens, matters more than most

121
00:05:59,560 --> 00:06:01,160
formal operating models admit.

122
00:06:01,160 --> 00:06:03,160
Strategy is not executed through intent,

123
00:06:03,160 --> 00:06:06,120
but through repeated decisions made under real conditions.

124
00:06:06,120 --> 00:06:07,160
Second is data flow.

125
00:06:07,160 --> 00:06:08,840
This is where truth lives and how it moves,

126
00:06:08,840 --> 00:06:10,360
yet we often forget to ask

127
00:06:10,360 --> 00:06:11,560
who gets to interpret it.

128
00:06:11,560 --> 00:06:14,040
We need to identify the source where the data is changed

129
00:06:14,040 --> 00:06:16,600
and who owns the definition before duplication begins.

130
00:06:16,600 --> 00:06:18,920
Often, data gets exported into slides

131
00:06:18,920 --> 00:06:21,480
because the system itself cannot carry trust,

132
00:06:21,480 --> 00:06:23,720
which makes data flow a political topic

133
00:06:23,720 --> 00:06:25,480
rather than a technical one.

134
00:06:25,480 --> 00:06:27,560
Once multiple versions of truth exist,

135
00:06:27,560 --> 00:06:29,160
people stop debating reality

136
00:06:29,160 --> 00:06:30,840
and start defending positions,

137
00:06:30,840 --> 00:06:33,480
and that is when reporting turns into a negotiation.

138
00:06:33,480 --> 00:06:35,080
Third, there is interaction flow.

139
00:06:35,080 --> 00:06:37,320
This is the part many organizations underestimate

140
00:06:37,320 --> 00:06:39,320
because it gets pushed into the language of culture,

141
00:06:39,320 --> 00:06:41,560
but structurally it is not soft at all.

142
00:06:41,560 --> 00:06:44,600
Interaction flow determines how context travels between people,

143
00:06:44,600 --> 00:06:45,880
where work gets clarified,

144
00:06:45,880 --> 00:06:47,560
and where ambiguity gets reduced.

145
00:06:47,560 --> 00:06:49,160
It is where decisions are discussed

146
00:06:49,160 --> 00:06:50,360
and where history is stored,

147
00:06:50,360 --> 00:06:52,600
so that handoffs either retain meaning

148
00:06:52,600 --> 00:06:53,640
or lose it completely.

149
00:06:53,640 --> 00:06:55,320
Coordination alone is not enough

150
00:06:55,320 --> 00:06:57,240
and you can coordinate tasks perfectly

151
00:06:57,240 --> 00:06:59,000
while still failing as an organization.

152
00:06:59,000 --> 00:07:00,280
If the people inside the system

153
00:07:00,280 --> 00:07:02,440
do not share enough context and trust,

154
00:07:02,440 --> 00:07:05,000
then every handoff becomes reconstruction work.

155
00:07:05,000 --> 00:07:07,160
That is why so many organizations feel busy

156
00:07:07,160 --> 00:07:08,680
and informed while acting slowly.

157
00:07:08,680 --> 00:07:10,280
There is a lot of communication happening,

158
00:07:10,280 --> 00:07:12,520
but the context transfer is weak.

159
00:07:12,520 --> 00:07:13,960
Beneath those three flows

160
00:07:13,960 --> 00:07:16,200
sits a fourth force that shapes all of them.

161
00:07:16,200 --> 00:07:16,840
Power.

162
00:07:16,840 --> 00:07:18,120
This is where things become real

163
00:07:18,120 --> 00:07:19,480
because formal process is one thing,

164
00:07:19,480 --> 00:07:21,320
but actual authority is another.

165
00:07:21,320 --> 00:07:23,320
Power determines who can override a process,

166
00:07:23,320 --> 00:07:24,120
delay a decision,

167
00:07:24,120 --> 00:07:26,280
or ignore the agreed root without any consequences.

168
00:07:26,280 --> 00:07:27,640
If the org chart says one thing,

169
00:07:27,640 --> 00:07:29,880
but everybody knows a different person really decides,

170
00:07:29,880 --> 00:07:32,120
then the real operating model is the power map.

171
00:07:32,120 --> 00:07:33,800
Behavior is a system outcome.

172
00:07:33,800 --> 00:07:35,160
People are not acting randomly.

173
00:07:35,160 --> 00:07:36,360
They are responding rationally

174
00:07:36,360 --> 00:07:38,360
to the environment the organization creates.

175
00:07:38,360 --> 00:07:41,080
If approvals are vague, people escalate early,

176
00:07:41,080 --> 00:07:43,880
and if ownership is unclear, they add more meetings.

177
00:07:43,880 --> 00:07:45,080
When truth is fragmented,

178
00:07:45,080 --> 00:07:46,920
people build private spreadsheets,

179
00:07:46,920 --> 00:07:48,280
and when power is hidden,

180
00:07:48,280 --> 00:07:51,000
they spend more energy reading politics than reading process.

181
00:07:51,000 --> 00:07:52,520
That is not a motivation failure.

182
00:07:52,520 --> 00:07:53,880
It is a design outcome.

183
00:07:53,880 --> 00:07:55,480
Once you see the organization this way,

184
00:07:55,480 --> 00:07:56,920
a lot of confusion disappears.

185
00:07:56,920 --> 00:07:59,480
You stop asking why smart people produce slow results

186
00:07:59,480 --> 00:08:01,160
and start asking what kind of flow architecture

187
00:08:01,160 --> 00:08:02,760
would make that result inevitable.

188
00:08:02,760 --> 00:08:04,920
If decisions are delayed and data is disputed,

189
00:08:04,920 --> 00:08:06,680
underperformance is not surprising.

190
00:08:06,680 --> 00:08:07,800
It is predictable.

191
00:08:07,800 --> 00:08:10,200
Most transformation work fails because it starts

192
00:08:10,200 --> 00:08:12,680
at the visible layer with a new tool or a new policy.

193
00:08:12,680 --> 00:08:16,360
The visible layer is not where organizational reality begins.

194
00:08:16,360 --> 00:08:18,520
It is just where it becomes visible.

195
00:08:18,520 --> 00:08:20,360
If we redesign only what can be seen

196
00:08:20,360 --> 00:08:21,800
without fixing the underlying flows,

197
00:08:21,800 --> 00:08:23,400
we just formalize the confusion.

198
00:08:23,400 --> 00:08:24,760
Before we talk about better design,

199
00:08:24,760 --> 00:08:26,280
we have to deal with the assumption

200
00:08:26,280 --> 00:08:29,400
that governance can rescue a misdesigned organization.

201
00:08:29,400 --> 00:08:31,800
Why governance doesn't save a misdesigned system?

202
00:08:31,800 --> 00:08:34,280
Governance matters, but it is not an operating model.

203
00:08:34,280 --> 00:08:35,640
It is a control framework.

204
00:08:35,640 --> 00:08:37,400
It tells us what should be allowed,

205
00:08:37,400 --> 00:08:38,440
what should be reviewed,

206
00:08:38,440 --> 00:08:40,200
and what should be protected or stopped.

207
00:08:40,200 --> 00:08:41,560
That has value in environments

208
00:08:41,560 --> 00:08:43,800
with high compliance pressure or regulatory risk,

209
00:08:43,800 --> 00:08:46,920
but governance cannot compensate for structural confusion.

210
00:08:46,920 --> 00:08:48,600
If decision parts are unclear,

211
00:08:48,600 --> 00:08:50,360
governance does not create clarity.

212
00:08:50,360 --> 00:08:53,160
It just adds checkpoints to unclear movement.

213
00:08:53,160 --> 00:08:54,520
If ownership is weak,

214
00:08:54,520 --> 00:08:56,520
governance does not create accountability.

215
00:08:56,520 --> 00:08:59,560
It just creates forms that move through the same ambiguity.

216
00:08:59,560 --> 00:09:00,840
When data is fragmented,

217
00:09:00,840 --> 00:09:03,240
governance creates rules around that fragmentation

218
00:09:03,240 --> 00:09:04,280
instead of creating truth.

219
00:09:04,280 --> 00:09:06,360
I see this constantly in Microsoft 365

220
00:09:06,360 --> 00:09:07,880
and power platform environments.

221
00:09:07,880 --> 00:09:09,720
A company realizes things feel messy

222
00:09:09,720 --> 00:09:11,560
because there are too many teams, too many sites,

223
00:09:11,560 --> 00:09:12,440
and too many apps.

224
00:09:12,440 --> 00:09:14,440
The response is almost always more governance

225
00:09:14,440 --> 00:09:16,360
like new templates, approval boards,

226
00:09:16,360 --> 00:09:17,400
and naming standards.

227
00:09:17,400 --> 00:09:18,840
While these are often necessary,

228
00:09:18,840 --> 00:09:20,920
if the underlying work design stays broken,

229
00:09:20,920 --> 00:09:22,920
governance just formalizes the friction.

230
00:09:22,920 --> 00:09:24,760
Now, the people don't just have unclear flow.

231
00:09:24,760 --> 00:09:26,760
They have unclear flow with paperwork.

232
00:09:26,760 --> 00:09:28,360
Governance feels like control,

233
00:09:28,360 --> 00:09:30,840
which gives leadership the sense of visible action.

234
00:09:30,840 --> 00:09:32,360
There is a policy and a board,

235
00:09:32,360 --> 00:09:35,000
so it looks like the organization is becoming more mature.

236
00:09:35,000 --> 00:09:37,480
Sometimes it is, but often it is just becoming slower

237
00:09:37,480 --> 00:09:38,840
in a more official way.

238
00:09:38,840 --> 00:09:41,400
Real resilience is not the same thing as administrative weight.

239
00:09:41,400 --> 00:09:44,200
Too much governance often creates default no behavior.

240
00:09:44,200 --> 00:09:46,200
This doesn't happen because people are resistant,

241
00:09:46,200 --> 00:09:49,240
but because the system gives them no safe path to say yes.

242
00:09:49,240 --> 00:09:51,400
If authority is fuzzy, they escalate,

243
00:09:51,400 --> 00:09:53,560
and if risk is undefined, they delay.

244
00:09:53,560 --> 00:09:55,800
When the consequences of a wrong move are visible,

245
00:09:55,800 --> 00:09:57,880
but the consequences of delay are invisible,

246
00:09:57,880 --> 00:09:59,800
people protect themselves with caution.

247
00:09:59,800 --> 00:10:01,080
Requests sit in loops,

248
00:10:01,080 --> 00:10:02,040
exceptions multiply,

249
00:10:02,040 --> 00:10:04,600
and meetings become the place where real decisions happen,

250
00:10:04,600 --> 00:10:06,280
because the formal route is too brittle,

251
00:10:06,280 --> 00:10:07,640
then shadow governance appears.

252
00:10:07,640 --> 00:10:09,400
This is the unofficial operating layer

253
00:10:09,400 --> 00:10:11,240
where a trusted person speeds things up

254
00:10:11,240 --> 00:10:13,240
or a side-chat settles the real decision.

255
00:10:13,240 --> 00:10:15,240
That is not an exception to the system.

256
00:10:15,240 --> 00:10:18,120
It is the system compensating for its own flaws.

257
00:10:18,120 --> 00:10:19,800
When shadow governance becomes the norm,

258
00:10:19,800 --> 00:10:21,960
formal governance loses all credibility.

259
00:10:21,960 --> 00:10:23,400
People stop seeing it as support

260
00:10:23,400 --> 00:10:24,840
and start seeing it as drag.

261
00:10:24,840 --> 00:10:28,120
Governance is only critical when it is attached to clear flow.

262
00:10:28,120 --> 00:10:29,880
It should protect movement, not replace it,

263
00:10:29,880 --> 00:10:33,080
and it should create trust rather than distributing hesitation.

264
00:10:33,080 --> 00:10:35,640
Leaders need a standard of minimum viable friction.

265
00:10:35,640 --> 00:10:37,400
You should place deliberate checkpoints

266
00:10:37,400 --> 00:10:40,760
only where uncertainty or material risk are actually high.

267
00:10:40,760 --> 00:10:42,760
If a decision is easy to reverse,

268
00:10:42,760 --> 00:10:44,440
do not govern it like a merger,

269
00:10:44,440 --> 00:10:46,120
and if the people closest to the work

270
00:10:46,120 --> 00:10:47,160
hold the right context,

271
00:10:47,160 --> 00:10:49,080
do not pull the decision upward.

272
00:10:49,080 --> 00:10:50,200
From a system perspective,

273
00:10:50,200 --> 00:10:52,120
that isn't maturity, it's latency.

274
00:10:52,120 --> 00:10:54,520
The question is whether your governance

275
00:10:54,520 --> 00:10:55,880
supports the real operating flow

276
00:10:55,880 --> 00:10:57,240
or quietly competes with it.

277
00:10:57,240 --> 00:10:59,240
When governance and flow are misaligned,

278
00:10:59,240 --> 00:11:00,920
the organization pays twice.

279
00:11:00,920 --> 00:11:03,560
Once in delay, and once again, in compensation.

280
00:11:03,560 --> 00:11:05,160
Misdesign was always expensive,

281
00:11:05,160 --> 00:11:07,880
but AI is making the bill impossible to ignore.

282
00:11:07,880 --> 00:11:10,280
The research signal leaders shouldn't ignore.

283
00:11:10,280 --> 00:11:11,480
Let's look at the signal.

284
00:11:11,480 --> 00:11:13,720
At this point, we aren't just having a philosophical debate

285
00:11:13,720 --> 00:11:15,400
about better organizational design

286
00:11:15,400 --> 00:11:17,640
because the market is now producing hard evidence

287
00:11:17,640 --> 00:11:19,880
that misdesigned companies simply cannot capture

288
00:11:19,880 --> 00:11:22,120
the value of the technology they buy.

289
00:11:22,120 --> 00:11:24,520
The clearest signal is that around 95%

290
00:11:24,520 --> 00:11:26,760
of generative AI pilots fail to create

291
00:11:26,760 --> 00:11:28,600
any measurable impact on the bottom line.

292
00:11:28,600 --> 00:11:30,440
That number matters because it doesn't actually

293
00:11:30,440 --> 00:11:31,800
say AI is weak,

294
00:11:31,800 --> 00:11:33,800
but rather it shows that most organizations

295
00:11:33,800 --> 00:11:36,200
are trying to accelerate work inside structures

296
00:11:36,200 --> 00:11:39,160
that are physically unable to absorb that acceleration.

297
00:11:39,160 --> 00:11:40,760
Most people here are failure rate like that

298
00:11:40,760 --> 00:11:43,000
and assume the issue must be model quality,

299
00:11:43,000 --> 00:11:45,400
poor prompting, or perhaps a lack of user adoption.

300
00:11:45,400 --> 00:11:46,760
When you look more closely,

301
00:11:46,760 --> 00:11:48,360
the pattern is much more structural

302
00:11:48,360 --> 00:11:50,120
than a simple technical glitch.

303
00:11:50,120 --> 00:11:51,960
Pilots happen and the demos look impressive,

304
00:11:51,960 --> 00:11:53,800
but then the value stalls somewhere between

305
00:11:53,800 --> 00:11:55,800
the output and the actual business action.

306
00:11:55,800 --> 00:11:57,480
Teams get excited as use cases

307
00:11:57,480 --> 00:11:59,400
multiply across the department.

308
00:11:59,400 --> 00:12:01,480
Yet the hard part was never actually generating

309
00:12:01,480 --> 00:12:02,600
an answer from the machine.

310
00:12:02,600 --> 00:12:04,840
The real challenge is integrating that answer

311
00:12:04,840 --> 00:12:06,600
into real workflows,

312
00:12:06,600 --> 00:12:09,000
clear ownership, and established trust boundaries.

313
00:12:09,000 --> 00:12:10,520
In other words, the limiting factor

314
00:12:10,520 --> 00:12:13,400
isn't model intelligence, its organizational intelligence.

315
00:12:13,400 --> 00:12:16,360
There's another signal here that leaders should take seriously,

316
00:12:16,360 --> 00:12:19,000
which is that only a small minority of organizations

317
00:12:19,000 --> 00:12:21,160
are actually scaling AI in a meaningful way.

318
00:12:21,160 --> 00:12:23,240
We have broad enthusiasm at the edge of the company,

319
00:12:23,240 --> 00:12:25,960
but we see very limited structural absorption at the core.

320
00:12:25,960 --> 00:12:27,960
The bottleneck is not access, it is design.

321
00:12:27,960 --> 00:12:30,360
You can see the same gap when you look at leadership readiness,

322
00:12:30,360 --> 00:12:33,000
where CEOs and technology leaders aren't even looking

323
00:12:33,000 --> 00:12:34,360
at the same reality.

324
00:12:34,360 --> 00:12:37,160
A much smaller share of CEOs acknowledge integration

325
00:12:37,160 --> 00:12:39,320
as the real challenge compared to IT leaders

326
00:12:39,320 --> 00:12:41,640
who are much closer to the day-to-day constraints.

327
00:12:41,640 --> 00:12:44,520
This gap matters because strategy gets announced at the top,

328
00:12:44,520 --> 00:12:46,520
while the friction is experienced at the bottom

329
00:12:46,520 --> 00:12:49,480
and the organization starts speaking two different languages.

330
00:12:49,480 --> 00:12:51,480
Leadership says they are adopting AI,

331
00:12:51,480 --> 00:12:53,480
but operation says they still can't move

332
00:12:53,480 --> 00:12:55,160
a decision across three teams

333
00:12:55,160 --> 00:12:57,240
without rebuilding the context twice.

334
00:12:57,240 --> 00:12:59,160
While the board asks for more use cases,

335
00:12:59,160 --> 00:13:00,760
the people inside the system are struggling

336
00:13:00,760 --> 00:13:02,280
because they don't even have an agreement

337
00:13:02,280 --> 00:13:03,720
on which data source is trusted.

338
00:13:03,720 --> 00:13:06,520
This isn't a communication issue, it's a design split.

339
00:13:06,520 --> 00:13:08,760
The most revealing part is that workflow redesign

340
00:13:08,760 --> 00:13:10,600
keeps showing up as the strongest predictor

341
00:13:10,600 --> 00:13:12,760
of whether a company captures AI value.

342
00:13:12,760 --> 00:13:15,720
It isn't about tool access or the number of pilots you run,

343
00:13:15,720 --> 00:13:19,480
yet redesign remains one of the least adopted moves in the playbook.

344
00:13:19,480 --> 00:13:21,640
Redesign is slower to announce than a pilot

345
00:13:21,640 --> 00:13:23,640
and it's much harder to package or celebrate

346
00:13:23,640 --> 00:13:25,000
in a steering committee meeting.

347
00:13:25,000 --> 00:13:27,240
It forces leadership to confront handoffs,

348
00:13:27,240 --> 00:13:29,480
power dynamics and role ambiguity,

349
00:13:29,480 --> 00:13:31,240
which is work that feels less glamorous

350
00:13:31,240 --> 00:13:33,240
but is exactly where the value comes from.

351
00:13:33,240 --> 00:13:35,880
Organizations that actually redesign specific workflows

352
00:13:35,880 --> 00:13:38,520
are seeing dramatic gains in speed and productivity.

353
00:13:38,520 --> 00:13:41,320
Training cycles are being cut from days to minutes

354
00:13:41,320 --> 00:13:43,160
and decision cycles are being compressed

355
00:13:43,160 --> 00:13:45,400
so that reporting happens in near real time.

356
00:13:45,400 --> 00:13:47,560
These outcomes didn't come from sprinkling AI

357
00:13:47,560 --> 00:13:48,920
on top of old ways of working,

358
00:13:48,920 --> 00:13:50,280
but from redesigning the work

359
00:13:50,280 --> 00:13:52,920
so the AI had a stable path to operate inside.

360
00:13:52,920 --> 00:13:56,200
If you missed that sequence, AI starts acting like an amplifier

361
00:13:56,200 --> 00:13:57,400
for your design debt.

362
00:13:57,400 --> 00:14:00,040
It exposes fragmented truth and reveals approval drag

363
00:14:00,040 --> 00:14:01,960
much faster than a human ever could.

364
00:14:01,960 --> 00:14:04,360
It scales bad handoffs and makes power misalignment

365
00:14:04,360 --> 00:14:06,120
more expensive because distorted decisions

366
00:14:06,120 --> 00:14:07,880
can now propagate at machine speed.

367
00:14:07,880 --> 00:14:10,280
When leaders ask why they aren't seeing value,

368
00:14:10,280 --> 00:14:13,000
the honest answer is usually that the value is being blocked

369
00:14:13,000 --> 00:14:14,280
by the organization itself.

370
00:14:14,280 --> 00:14:16,840
The people aren't incapable and the technology isn't immature

371
00:14:16,840 --> 00:14:19,080
but the operating model underneath is too fragmented

372
00:14:19,080 --> 00:14:20,920
to convert intelligence into action.

373
00:14:20,920 --> 00:14:23,000
AI is not creating the design problem,

374
00:14:23,000 --> 00:14:25,720
it is simply revealing the problem that was already there.

375
00:14:25,720 --> 00:14:27,640
Once you see that, the conversation changes

376
00:14:27,640 --> 00:14:30,200
because the real constraint is no longer model speed,

377
00:14:30,200 --> 00:14:31,560
its organizational speed.

378
00:14:31,560 --> 00:14:34,760
And decision velocity is the real performance metric.

379
00:14:34,760 --> 00:14:37,240
If organizational speed is the real constraint,

380
00:14:37,240 --> 00:14:38,920
then we need a better performance metric

381
00:14:38,920 --> 00:14:40,360
than just output or activity.

382
00:14:40,360 --> 00:14:42,120
We need to look at decision velocity

383
00:14:42,120 --> 00:14:44,760
which is the time between a meaningful signal appearing

384
00:14:44,760 --> 00:14:46,680
and the organization actually acting on it.

385
00:14:46,680 --> 00:14:48,760
I'm not talking about when the dashboard updated

386
00:14:48,760 --> 00:14:50,760
or when the AI generated a recommendation

387
00:14:50,760 --> 00:14:52,520
but when that signal was judged,

388
00:14:52,520 --> 00:14:55,080
committed to and translated into a real business move.

389
00:14:55,080 --> 00:14:56,920
That is the metric that matters now

390
00:14:56,920 --> 00:15:00,600
because AI has changed one side of the equation completely.

391
00:15:00,600 --> 00:15:02,360
The system can now generate predictions,

392
00:15:02,360 --> 00:15:05,000
classifications and recommendations in seconds,

393
00:15:05,000 --> 00:15:08,200
effectively compressing analysis and reducing search time.

394
00:15:08,200 --> 00:15:10,360
If the organization still needs three meetings

395
00:15:10,360 --> 00:15:12,360
to interpret that output and two more approvals

396
00:15:12,360 --> 00:15:13,400
to validate ownership,

397
00:15:13,400 --> 00:15:16,120
then the actual operating speed hasn't improved at all.

398
00:15:16,120 --> 00:15:17,080
The model got faster,

399
00:15:17,080 --> 00:15:19,480
but the organization stayed exactly where it was.

400
00:15:19,480 --> 00:15:21,320
This is where a lot of executive reporting

401
00:15:21,320 --> 00:15:23,160
becomes misleading for the business.

402
00:15:23,160 --> 00:15:25,160
We measure model quality and prompt volume

403
00:15:25,160 --> 00:15:26,520
and those numbers can all go up

404
00:15:26,520 --> 00:15:29,160
while decision velocity stays almost completely unchanged.

405
00:15:29,160 --> 00:15:31,400
The business feels stuck even though the dashboard says

406
00:15:31,400 --> 00:15:33,560
there is progress and from a system perspective

407
00:15:33,560 --> 00:15:35,000
that makes perfect sense.

408
00:15:35,000 --> 00:15:36,840
Model performance and operational performance

409
00:15:36,840 --> 00:15:37,880
are not the same thing

410
00:15:37,880 --> 00:15:39,480
and a model can be fast and accurate

411
00:15:39,480 --> 00:15:41,240
without the business ever moving an inch.

412
00:15:41,240 --> 00:15:43,400
If the surrounding architecture cannot absorb

413
00:15:43,400 --> 00:15:44,600
what the AI produces,

414
00:15:44,600 --> 00:15:47,400
then the value remains trapped inside the recommendation layer.

415
00:15:47,400 --> 00:15:49,480
Decision velocity is a much more honest metric

416
00:15:49,480 --> 00:15:52,360
because it forces us to measure the full path from signal to action.

417
00:15:52,360 --> 00:15:54,840
We have to look at where the path slows down

418
00:15:54,840 --> 00:15:56,600
and it's usually in very familiar places

419
00:15:56,600 --> 00:15:58,680
like approval chains or unclear ownership.

420
00:15:58,680 --> 00:16:00,040
Teams often wait for alignment

421
00:16:00,040 --> 00:16:02,200
because no one knows whether a decision is reversible

422
00:16:02,200 --> 00:16:04,280
and these aren't just minor administrative issues.

423
00:16:04,280 --> 00:16:06,840
They are velocity drains that have become more obvious

424
00:16:06,840 --> 00:16:10,280
because the old gap between analysis and execution was smaller.

425
00:16:10,280 --> 00:16:12,120
When humans produced analysis slowly,

426
00:16:12,120 --> 00:16:13,960
the rest of the organization could pretend

427
00:16:13,960 --> 00:16:17,080
the pace was normal but now the front end of the process has accelerated.

428
00:16:17,080 --> 00:16:18,760
The rest of the system is now exposed

429
00:16:18,760 --> 00:16:20,440
because AI gives you the answer quickly

430
00:16:20,440 --> 00:16:23,560
which means every structural delay after that point becomes visible.

431
00:16:23,560 --> 00:16:25,400
You can no longer hide weak design

432
00:16:25,400 --> 00:16:27,640
behind slow information production

433
00:16:27,640 --> 00:16:30,360
and that is why so many leaders feel this tension today.

434
00:16:30,360 --> 00:16:32,360
The technology isn't just ahead of the business.

435
00:16:32,360 --> 00:16:36,600
It is showing the business how slow its internal decision architecture really is.

436
00:16:36,600 --> 00:16:38,600
Competitive advantage is shifting away

437
00:16:38,600 --> 00:16:42,040
from simple access to information or scale of execution.

438
00:16:42,040 --> 00:16:44,520
Once intelligence becomes cheaper and faster,

439
00:16:44,520 --> 00:16:46,520
the advantage moves toward the organization

440
00:16:46,520 --> 00:16:49,400
that can convert that intelligence into action with less delay.

441
00:16:49,400 --> 00:16:51,880
This is a design issue rather than a tool issue

442
00:16:51,880 --> 00:16:54,760
and the winner won't be the company with the most co-pilots.

443
00:16:54,760 --> 00:16:57,080
The winner will be the company where the path

444
00:16:57,080 --> 00:17:00,360
from knowing to doing is structurally clean and authority is clear.

445
00:17:00,360 --> 00:17:02,840
In those organizations, context travels with the work

446
00:17:02,840 --> 00:17:06,200
and not every decision gets dragged into the same heavy governance gravity.

447
00:17:06,200 --> 00:17:07,560
Trust in the data is high enough

448
00:17:07,560 --> 00:17:11,240
that teams don't have to renegotiate reality every time they try to move forward.

449
00:17:11,240 --> 00:17:12,760
If I were looking at performance today,

450
00:17:12,760 --> 00:17:15,880
I would ask how long it takes to act on a known issue

451
00:17:15,880 --> 00:17:18,840
or how many handoffs happened before a commitment is made.

452
00:17:18,840 --> 00:17:21,400
We need to know how often a recommendation stalls

453
00:17:21,400 --> 00:17:23,480
because nobody knows who actually decides

454
00:17:23,480 --> 00:17:27,080
and whether that delay is caused by real risk or just simple ambiguity.

455
00:17:27,080 --> 00:17:28,840
That is the real operating picture

456
00:17:28,840 --> 00:17:31,000
because once you understand decision velocity,

457
00:17:31,000 --> 00:17:33,880
you stop treating slowness as a vague culture problem.

458
00:17:33,880 --> 00:17:36,040
You see it for what it really is, a design problem.

459
00:17:36,040 --> 00:17:39,480
Decision flow, design for clarity, speed and minimal friction.

460
00:17:39,480 --> 00:17:41,880
Let's start with the concept of decision flow itself

461
00:17:41,880 --> 00:17:45,160
because this is exactly where performance either compounds or gets trapped.

462
00:17:45,160 --> 00:17:47,160
Most organizations operate under the assumption

463
00:17:47,160 --> 00:17:50,120
that decisions happen where the org chart says they should,

464
00:17:50,120 --> 00:17:52,280
but that is rarely the case in reality.

465
00:17:52,280 --> 00:17:54,920
In a functioning system, decisions actually happen

466
00:17:54,920 --> 00:17:58,120
where context, trust, risk and authority intersect in real time

467
00:17:58,120 --> 00:18:00,760
and those four elements are not always found in the same office.

468
00:18:00,760 --> 00:18:04,360
You might have a senior leader who holds the formal accountability on paper

469
00:18:04,360 --> 00:18:08,360
but the real judgment often sits with the person closest to the daily work.

470
00:18:08,360 --> 00:18:11,720
Sometimes the opposite happens where a team appears to be empowered

471
00:18:11,720 --> 00:18:14,440
but every meaningful move still gets pulled upward

472
00:18:14,440 --> 00:18:17,400
because nobody actually trusts the boundaries of that empowerment.

473
00:18:17,400 --> 00:18:20,600
This gap between where a decision is supposed to happen

474
00:18:20,600 --> 00:18:24,440
and where it actually lands is where institutional drag begins to take hold.

475
00:18:24,440 --> 00:18:28,440
When we design for flow, our first job isn't to ask who needs to be kept in the loop

476
00:18:28,440 --> 00:18:31,160
but rather to ask where the decision should actually live.

477
00:18:31,160 --> 00:18:33,560
We have to identify who has the best context

478
00:18:33,560 --> 00:18:36,040
and who carries the ultimate consequence of the choice.

479
00:18:36,040 --> 00:18:39,480
We need to know who can act without creating downstream confusion

480
00:18:39,480 --> 00:18:41,960
and we must distinguish between who needs visibility

481
00:18:41,960 --> 00:18:43,400
and who actually needs control.

482
00:18:43,400 --> 00:18:45,880
Most organizations blur those two things together

483
00:18:45,880 --> 00:18:48,120
and treat visibility like a form of entitlement.

484
00:18:48,120 --> 00:18:50,440
They assume that if someone is affected by a change,

485
00:18:50,440 --> 00:18:53,160
that person must also approve it or if someone is senior,

486
00:18:53,160 --> 00:18:54,680
they must be the one to decide.

487
00:18:54,680 --> 00:18:57,000
There is a common belief that if something feels important,

488
00:18:57,000 --> 00:18:58,600
it naturally needs more friction

489
00:18:58,600 --> 00:19:00,920
but from a system perspective that isn't disciplined.

490
00:19:00,920 --> 00:19:02,600
That is just delay logic.

491
00:19:02,600 --> 00:19:05,400
A more resilient design starts by separating decisions

492
00:19:05,400 --> 00:19:07,400
into different types based on their impact.

493
00:19:07,400 --> 00:19:10,440
Some choices are reversible meaning you can test an idea,

494
00:19:10,440 --> 00:19:13,400
learn from the result and adapt or recover if it fails.

495
00:19:13,400 --> 00:19:17,000
These decisions should move as close to the point of work as possible,

496
00:19:17,000 --> 00:19:20,040
moving fast with light structure and clear intent.

497
00:19:20,040 --> 00:19:22,040
Other decisions are much harder to reverse

498
00:19:22,040 --> 00:19:24,440
because they affect trust, regulatory exposure

499
00:19:24,440 --> 00:19:26,360
or long term operating architecture.

500
00:19:26,360 --> 00:19:27,640
These deserve more friction

501
00:19:27,640 --> 00:19:29,480
but it shouldn't be the kind of vague friction

502
00:19:29,480 --> 00:19:31,400
that slows things down for no reason.

503
00:19:31,400 --> 00:19:34,920
We want deliberate friction or what I call "minimum viable friction"

504
00:19:34,920 --> 00:19:37,480
which provides just enough structure to test assumptions

505
00:19:37,480 --> 00:19:39,880
and scan for impact before making a commitment.

506
00:19:39,880 --> 00:19:41,480
This doesn't require 10 people in a room

507
00:19:41,480 --> 00:19:44,600
or three layers of signatures born out of a fear of being blamed later.

508
00:19:44,600 --> 00:19:46,040
It can be as simple as asking

509
00:19:46,040 --> 00:19:47,800
"what must be true for this to work?"

510
00:19:47,800 --> 00:19:50,120
and "who is materially affected by the outcome?"

511
00:19:50,120 --> 00:19:52,040
That is friction in service of quality

512
00:19:52,040 --> 00:19:55,480
rather than friction in service of institutional anxiety.

513
00:19:55,480 --> 00:19:57,160
The problem is that many organizations

514
00:19:57,160 --> 00:19:59,400
put the heaviest friction in the wrong places

515
00:19:59,400 --> 00:20:02,360
leaving routine decisions stuck in approval gravity

516
00:20:02,360 --> 00:20:04,360
while strategic moves happen too fast.

517
00:20:04,920 --> 00:20:06,920
Teams might spend days getting permission

518
00:20:06,920 --> 00:20:08,280
for a low-risk action

519
00:20:08,280 --> 00:20:12,040
yet they launch high-risk changes with unclear accountability

520
00:20:12,040 --> 00:20:14,600
just because the project had executive energy behind it.

521
00:20:14,600 --> 00:20:16,520
That isn't a framework for success.

522
00:20:16,520 --> 00:20:18,760
It is just inconsistency at scale.

523
00:20:18,760 --> 00:20:22,120
To improve this flow, you need to make a few specific design moves

524
00:20:22,120 --> 00:20:24,360
starting with the clear definition of decision owners.

525
00:20:24,360 --> 00:20:25,720
We aren't talking about committees

526
00:20:25,720 --> 00:20:27,160
or vague leadership alignment

527
00:20:27,160 --> 00:20:28,600
but rather one specific role

528
00:20:28,600 --> 00:20:30,600
that carries the responsibility to make the call.

529
00:20:30,600 --> 00:20:33,000
Input can be as broad as you want

530
00:20:33,000 --> 00:20:34,600
but ownership must remain singular.

531
00:20:34,600 --> 00:20:37,080
Next, you have to define contributor roles

532
00:20:37,080 --> 00:20:38,680
separately from approval roles

533
00:20:38,680 --> 00:20:41,560
to prevent every discussion from turning into a hidden veto process.

534
00:20:41,560 --> 00:20:43,560
Many people need to inform a decision

535
00:20:43,560 --> 00:20:45,960
but very few should actually be able to block it.

536
00:20:45,960 --> 00:20:48,440
You also need to set explicit escalation thresholds

537
00:20:48,440 --> 00:20:50,280
so people know exactly what stays local

538
00:20:50,280 --> 00:20:51,560
and what moves upward.

539
00:20:51,560 --> 00:20:53,560
Without these markers, people will escalate

540
00:20:53,560 --> 00:20:54,840
based on fear or habit

541
00:20:54,840 --> 00:20:57,160
and your organizational speed will collapse.

542
00:20:57,160 --> 00:20:59,800
Finally, you have to remove performative approvals

543
00:20:59,800 --> 00:21:02,200
that exist only to signal a sense of control.

544
00:21:02,200 --> 00:21:04,520
Everyone knows these steps add very little judgment

545
00:21:04,520 --> 00:21:07,480
but they stay in place because they make the system feel governed.

546
00:21:07,480 --> 00:21:09,800
In reality, they just create traffic

547
00:21:09,800 --> 00:21:11,240
without adding quality,

548
00:21:11,240 --> 00:21:13,800
leading people to stop trusting the formal route entirely.

549
00:21:13,800 --> 00:21:15,640
None of this is about removing human judgment

550
00:21:15,640 --> 00:21:17,640
which actually becomes more important as AI

551
00:21:17,640 --> 00:21:19,640
becomes more available in our workflows.

552
00:21:19,640 --> 00:21:22,200
But that judgment has to be structurally placed

553
00:21:22,200 --> 00:21:24,920
so the organization knows exactly where discernment lives

554
00:21:24,920 --> 00:21:26,520
when the data is incomplete.

555
00:21:26,520 --> 00:21:28,040
Who evaluates the edge cases

556
00:21:28,040 --> 00:21:30,600
and who owns the call when trade-offs are required?

557
00:21:30,600 --> 00:21:32,360
That is the heart of decision design.

558
00:21:32,360 --> 00:21:33,960
Once you understand flow this way,

559
00:21:33,960 --> 00:21:35,560
you realize that many organizations

560
00:21:35,560 --> 00:21:37,000
don't actually have a decision problem

561
00:21:37,000 --> 00:21:39,000
what they really have is a data design problem

562
00:21:39,000 --> 00:21:40,360
because even with clear authority,

563
00:21:40,360 --> 00:21:41,960
decisions slow down when nobody agrees

564
00:21:41,960 --> 00:21:43,400
on where the truth lives.

565
00:21:43,400 --> 00:21:46,040
Data flow, where truth lives, and how trust moves.

566
00:21:46,040 --> 00:21:48,280
Let's go one layer deeper into the infrastructure

567
00:21:48,280 --> 00:21:50,840
because even when decision rights are perfectly clear,

568
00:21:50,840 --> 00:21:53,880
the system breaks down if the underlying data flow is weak.

569
00:21:53,880 --> 00:21:56,440
This is where many leaders confuse simple data access

570
00:21:56,440 --> 00:21:58,040
with actual data design.

571
00:21:58,040 --> 00:22:00,360
They assume that if a person can open a report

572
00:22:00,360 --> 00:22:01,480
or export a file,

573
00:22:01,480 --> 00:22:03,000
then the truth is available to them

574
00:22:03,000 --> 00:22:06,120
but being available is not the same thing as being trusted.

575
00:22:06,120 --> 00:22:07,160
From a system perspective,

576
00:22:07,160 --> 00:22:10,520
data flow is about much more than just storage or cloud capacity.

577
00:22:10,520 --> 00:22:12,200
It involves the source, the movement,

578
00:22:12,200 --> 00:22:14,360
the ownership, and the timing of information

579
00:22:14,360 --> 00:22:16,120
as it travels through the organization.

580
00:22:16,120 --> 00:22:17,720
We have to know where the data begins

581
00:22:17,720 --> 00:22:19,960
and at what point it stops being operational truth

582
00:22:19,960 --> 00:22:21,720
and starts becoming a local translation.

583
00:22:21,720 --> 00:22:22,920
That last part is critical

584
00:22:22,920 --> 00:22:25,000
because the moment teams start translating data

585
00:22:25,000 --> 00:22:27,160
for their own use without shared definitions,

586
00:22:27,160 --> 00:22:29,240
organizational trust starts to fracture.

587
00:22:29,240 --> 00:22:30,360
It doesn't happen all at once,

588
00:22:30,360 --> 00:22:33,080
but it happens quietly as sales uses one number,

589
00:22:33,080 --> 00:22:35,560
while finance and operations use two others.

590
00:22:35,560 --> 00:22:37,560
When leadership asks for a single report

591
00:22:37,560 --> 00:22:39,160
and gets three different stories,

592
00:22:39,160 --> 00:22:41,480
the problem is no longer about reporting quality.

593
00:22:41,480 --> 00:22:43,640
It is about a total loss of coherence.

594
00:22:43,640 --> 00:22:46,760
This fragmented truth creates massive amounts of rework

595
00:22:46,760 --> 00:22:49,320
as people build their own extracts and spend meetings,

596
00:22:49,320 --> 00:22:51,080
reconciling numbers manually.

597
00:22:51,080 --> 00:22:53,400
They delay action because nobody wants to move on

598
00:22:53,400 --> 00:22:54,680
disputed information

599
00:22:54,680 --> 00:22:56,280
and the decision flow slows down

600
00:22:56,280 --> 00:22:58,280
because the organization cannot establish

601
00:22:58,280 --> 00:22:59,800
a shared reality.

602
00:22:59,800 --> 00:23:02,280
This is where traditional governance usually enters the chat

603
00:23:02,280 --> 00:23:04,600
with metadata policies, data catalogs,

604
00:23:04,600 --> 00:23:05,640
and lineage diagrams.

605
00:23:05,640 --> 00:23:06,760
These tools are all useful,

606
00:23:06,760 --> 00:23:09,480
but only if they actually connect to the way people work.

607
00:23:09,480 --> 00:23:12,120
Data governance without usable pathways

608
00:23:12,120 --> 00:23:14,120
often creates a situation where the chart says

609
00:23:14,120 --> 00:23:15,160
the data has an owner,

610
00:23:15,160 --> 00:23:17,000
but the business still doesn't know who to call

611
00:23:17,000 --> 00:23:18,120
when a metric changes.

612
00:23:18,120 --> 00:23:19,800
When I talk about a line to data flow,

613
00:23:19,800 --> 00:23:22,680
I am describing something much more operational and visible.

614
00:23:22,680 --> 00:23:23,880
In a well-designed system,

615
00:23:23,880 --> 00:23:25,800
core business objects like customers,

616
00:23:25,800 --> 00:23:26,920
projects, or orders

617
00:23:26,920 --> 00:23:28,600
have real accountability behind them.

618
00:23:28,600 --> 00:23:29,960
Definitions stay stable enough

619
00:23:29,960 --> 00:23:32,680
that teams don't have to renegotiate basic meanings every week.

620
00:23:32,680 --> 00:23:34,200
And while everyone might see the data,

621
00:23:34,200 --> 00:23:35,880
not everyone is allowed to redefine it.

622
00:23:35,880 --> 00:23:37,880
Trust moves through legibility.

623
00:23:37,880 --> 00:23:40,600
And if people cannot trace the path of a number,

624
00:23:40,600 --> 00:23:43,560
they will compensate for that lack of clarity with skepticism.

625
00:23:43,560 --> 00:23:45,000
In most corporate environments,

626
00:23:45,000 --> 00:23:47,560
that skepticism turns into politics very quickly.

627
00:23:47,560 --> 00:23:50,120
Now, if you map that reality to the rise of AI,

628
00:23:50,120 --> 00:23:52,680
you'll see that these models don't fix contradictions.

629
00:23:52,680 --> 00:23:53,880
They actually amplify them.

630
00:23:53,880 --> 00:23:55,960
If your environment is already full of duplicate

631
00:23:55,960 --> 00:23:57,960
truth sources and unstable labels,

632
00:23:57,960 --> 00:24:00,120
a tool like Copilot will simply surface

633
00:24:00,120 --> 00:24:03,080
those inconsistencies faster and at a much greater scale.

634
00:24:03,080 --> 00:24:04,600
The model cannot create clarity

635
00:24:04,600 --> 00:24:07,080
where the architecture has preserved ambiguity,

636
00:24:07,080 --> 00:24:08,280
and it will only accelerate

637
00:24:08,280 --> 00:24:10,520
whatever truth structure already exists.

638
00:24:10,520 --> 00:24:13,400
This is exactly why so many AI outputs feel impressive,

639
00:24:13,400 --> 00:24:16,840
but ultimately unreliable when used inside a large enterprise.

640
00:24:16,840 --> 00:24:19,240
The issue is rarely the quality of the sentences

641
00:24:19,240 --> 00:24:20,520
the AI generates,

642
00:24:20,520 --> 00:24:23,240
but rather the trust substrate underneath those sentences.

643
00:24:23,240 --> 00:24:25,160
We have to be able to verify the path

644
00:24:25,160 --> 00:24:28,040
and ensure that permissions reflect real accountability.

645
00:24:28,040 --> 00:24:30,920
These are data flow questions, not prompt engineering questions.

646
00:24:30,920 --> 00:24:32,120
If you want better performance,

647
00:24:32,120 --> 00:24:34,520
you have to stop treating data as a passive asset

648
00:24:34,520 --> 00:24:36,920
and start treating it as an active operating layer.

649
00:24:36,920 --> 00:24:38,360
Once truth becomes fragmented,

650
00:24:38,360 --> 00:24:40,360
every other flow in the system gets weaker

651
00:24:40,360 --> 00:24:43,480
and your best people end up carrying context in their heads

652
00:24:43,480 --> 00:24:46,200
because the architecture can no longer carry it for them.

653
00:24:46,200 --> 00:24:47,960
But even with clear truth,

654
00:24:47,960 --> 00:24:50,040
people still need a way to move meaning together.

655
00:24:50,040 --> 00:24:54,440
Interaction model, connection over coordination.

656
00:24:54,440 --> 00:24:57,480
Now we come to a layer that many leaders still try to dismiss

657
00:24:57,480 --> 00:24:58,360
with soft language.

658
00:24:58,360 --> 00:25:02,200
They talk about communication, collaboration and culture,

659
00:25:02,200 --> 00:25:04,120
or they focus on ways of working.

660
00:25:04,120 --> 00:25:05,320
While those things are important,

661
00:25:05,320 --> 00:25:08,200
if you look closely, you'll see this isn't just about culture.

662
00:25:08,200 --> 00:25:09,640
It is an interaction model,

663
00:25:09,640 --> 00:25:13,400
and interaction models are what actually produce execution outcomes.

664
00:25:13,400 --> 00:25:16,520
Most organizations today are designed for coordination.

665
00:25:16,520 --> 00:25:18,280
They make sure tasks can be assigned

666
00:25:18,280 --> 00:25:20,040
and meetings can be scheduled,

667
00:25:20,040 --> 00:25:22,680
while ensuring messages are sent and files are shared.

668
00:25:22,680 --> 00:25:24,920
They build infrastructure so comments can be added

669
00:25:24,920 --> 00:25:26,760
and approvals can be requested.

670
00:25:26,760 --> 00:25:28,600
This coordination infrastructure matters,

671
00:25:28,600 --> 00:25:31,000
but coordination is not the same thing as connection.

672
00:25:31,000 --> 00:25:33,720
Coordination moves tasks, but connection moves meaning.

673
00:25:33,720 --> 00:25:34,920
That is the real distinction.

674
00:25:34,920 --> 00:25:36,440
A team can be highly coordinated

675
00:25:36,440 --> 00:25:39,400
and still fail repeatedly because the people inside the flow

676
00:25:39,400 --> 00:25:43,080
don't share enough context to make good decisions together.

677
00:25:43,080 --> 00:25:45,080
They might know exactly what to do next,

678
00:25:45,080 --> 00:25:46,600
but they don't know why it matters

679
00:25:46,600 --> 00:25:48,280
or what changed upstream.

680
00:25:48,280 --> 00:25:50,440
They are blind to the trade-offs that were made

681
00:25:50,440 --> 00:25:52,600
or the assumptions the last team was working with.

682
00:25:52,600 --> 00:25:55,480
The result is that every handoff becomes thinner than it should be.

683
00:25:55,480 --> 00:25:56,760
Once those handoffs get thin,

684
00:25:56,760 --> 00:25:59,080
the organization starts paying a hidden tax.

685
00:25:59,080 --> 00:26:01,160
People find themselves re-explaning things

686
00:26:01,160 --> 00:26:02,680
and opening extra meetings,

687
00:26:02,680 --> 00:26:04,280
or they ask for status updates

688
00:26:04,280 --> 00:26:06,680
that should have been unnecessary from the start.

689
00:26:06,680 --> 00:26:09,240
They begin using chat as a repair mechanism

690
00:26:09,240 --> 00:26:12,760
because the formal work surface no longer carries enough context

691
00:26:12,760 --> 00:26:13,880
to get the job done.

692
00:26:13,880 --> 00:26:15,720
That isn't the case of overcommunication.

693
00:26:15,720 --> 00:26:17,480
It is structural compensation.

694
00:26:17,480 --> 00:26:19,640
When you map that to how we work today,

695
00:26:19,640 --> 00:26:21,160
you see collaboration environments

696
00:26:21,160 --> 00:26:23,560
that are dense with activity but shallow on substance.

697
00:26:23,560 --> 00:26:25,960
We have teams, messages, channels and loop components

698
00:26:25,960 --> 00:26:28,360
along with emails, meeting notes and planet asks.

699
00:26:28,360 --> 00:26:30,360
From the outside, the system looks connected

700
00:26:30,360 --> 00:26:32,520
but often it is only transaction-rich.

701
00:26:32,520 --> 00:26:34,760
There is a lot of movement without much continuity

702
00:26:34,760 --> 00:26:38,200
because the system was designed to help people exchange units of work

703
00:26:38,200 --> 00:26:40,760
rather than preserving the meaning around that work.

704
00:26:40,760 --> 00:26:42,760
Context leaks out of the system constantly.

705
00:26:42,760 --> 00:26:44,200
A decision happens in a call,

706
00:26:44,200 --> 00:26:46,760
but the rationale stays trapped in one person's memory

707
00:26:46,760 --> 00:26:48,440
while the file is stored somewhere else

708
00:26:48,440 --> 00:26:50,840
and the action is tracked in a third location.

709
00:26:50,840 --> 00:26:53,400
When someone new joins the thread three days later,

710
00:26:53,400 --> 00:26:56,040
the whole context has to be rebuilt from scratch.

711
00:26:56,040 --> 00:26:59,080
From a system perspective, that isn't a communication failure.

712
00:26:59,080 --> 00:27:00,600
It's an architectural one.

713
00:27:00,600 --> 00:27:03,160
The interaction model simply fail to carry enough context

714
00:27:03,160 --> 00:27:05,400
across time, roles and platforms.

715
00:27:05,400 --> 00:27:07,640
This becomes even more expensive in hybrid

716
00:27:07,640 --> 00:27:09,480
and asynchronous work environments.

717
00:27:09,480 --> 00:27:11,080
When people aren't sharing the same room

718
00:27:11,080 --> 00:27:12,360
or the same informal cues,

719
00:27:12,360 --> 00:27:14,280
interaction design has to become explicit.

720
00:27:14,280 --> 00:27:16,200
You can no longer rely on hallway repair

721
00:27:16,200 --> 00:27:17,880
or proximity to fix the gaps

722
00:27:17,880 --> 00:27:19,960
and you can't assume someone will over here

723
00:27:19,960 --> 00:27:22,200
a missing piece of information to correct the flow.

724
00:27:22,200 --> 00:27:24,360
The system has to do more of that heavy lifting.

725
00:27:24,360 --> 00:27:27,160
A designed interaction model answers practical questions

726
00:27:27,160 --> 00:27:29,400
about where decisions are discussed and documented.

727
00:27:29,400 --> 00:27:31,160
It defines where rational leaves

728
00:27:31,160 --> 00:27:32,840
and where exceptions should surface

729
00:27:32,840 --> 00:27:34,680
while clarifying what belongs in chat

730
00:27:34,680 --> 00:27:36,760
and what must survive beyond it.

731
00:27:36,760 --> 00:27:38,840
These questions sound operational because they are

732
00:27:38,840 --> 00:27:40,200
and when they stay unanswered,

733
00:27:40,200 --> 00:27:42,440
organizations drift into a very common pattern

734
00:27:42,440 --> 00:27:44,600
of being highly responsive but poorly aligned.

735
00:27:44,600 --> 00:27:46,600
Everyone is available and everyone is reacting,

736
00:27:46,600 --> 00:27:48,200
yet the meaning of the work fragments

737
00:27:48,200 --> 00:27:49,640
across a dozen different channels.

738
00:27:49,640 --> 00:27:51,720
This is why some teams look collaborative

739
00:27:51,720 --> 00:27:53,400
while producing unreliable results.

740
00:27:53,400 --> 00:27:55,800
They aren't lacking effort, they are lacking connective tissue.

741
00:27:55,800 --> 00:27:57,880
When I talk about connection over coordination,

742
00:27:57,880 --> 00:28:00,200
I don't mean replacing structure with human warmth.

743
00:28:00,200 --> 00:28:02,280
I mean designing interaction so that trust

744
00:28:02,280 --> 00:28:04,760
and context can move alongside the work.

745
00:28:04,760 --> 00:28:07,480
This usually requires fewer surfaces and clearer rules

746
00:28:07,480 --> 00:28:09,800
along with a more deliberate placement of conversation.

747
00:28:09,800 --> 00:28:12,040
Not every message deserves a meeting

748
00:28:12,040 --> 00:28:14,120
and not every meeting deserves a channel.

749
00:28:14,120 --> 00:28:15,880
The point is to reduce the number of places

750
00:28:15,880 --> 00:28:17,560
where meaning can fall apart.

751
00:28:17,560 --> 00:28:19,080
Once interaction quality improves,

752
00:28:19,080 --> 00:28:21,160
execution reliability improves with it.

753
00:28:21,160 --> 00:28:24,040
You see fewer rebuilds, fewer duplicate conversations

754
00:28:24,040 --> 00:28:25,160
and much cleaner handoffs.

755
00:28:25,160 --> 00:28:28,200
The meeting load drops and context becomes more durable.

756
00:28:28,200 --> 00:28:30,120
For anyone responsible for systems,

757
00:28:30,120 --> 00:28:32,680
this is where it becomes relevant.

758
00:28:32,680 --> 00:28:34,840
Interaction quality isn't soft overhead.

759
00:28:34,840 --> 00:28:36,520
It determines whether decisions hold

760
00:28:36,520 --> 00:28:38,680
and whether teams can act without constantly repairing

761
00:28:38,680 --> 00:28:40,280
the flow by hand.

762
00:28:40,280 --> 00:28:43,000
Power alignment, the hidden operating system.

763
00:28:43,000 --> 00:28:45,640
Power is the layer most organizations feel every day

764
00:28:45,640 --> 00:28:47,640
but describe the least accurately.

765
00:28:47,640 --> 00:28:49,560
They prefer to talk about process, governance

766
00:28:49,560 --> 00:28:51,720
and accountability yet underneath those words,

767
00:28:51,720 --> 00:28:54,120
power is what actually decides what moves.

768
00:28:54,120 --> 00:28:56,280
It determines who can override a decision,

769
00:28:56,280 --> 00:28:57,720
who can delay a project,

770
00:28:57,720 --> 00:29:00,760
and who has the standing to redefine an issue entirely.

771
00:29:00,760 --> 00:29:03,320
Power is the ability to ignore the agreed route

772
00:29:03,320 --> 00:29:05,080
and still be seen as reasonable.

773
00:29:05,080 --> 00:29:07,000
It's the capacity to force an extra review

774
00:29:07,000 --> 00:29:08,360
or create a sense of urgency

775
00:29:08,360 --> 00:29:11,000
and sometimes it's the ability to make something disappear

776
00:29:11,000 --> 00:29:12,760
simply by not responding to it.

777
00:29:12,760 --> 00:29:14,760
If you want to understand the real operating model

778
00:29:14,760 --> 00:29:17,080
of an organization, don't look at the formal process map.

779
00:29:17,080 --> 00:29:19,400
Instead, look at what happens when tension appears,

780
00:29:19,400 --> 00:29:22,280
when a deadline slips or a customer escalates,

781
00:29:22,280 --> 00:29:25,480
or when an AI output conflicts with someone's intuition.

782
00:29:25,480 --> 00:29:27,480
You have to ask who wins in that moment.

783
00:29:27,480 --> 00:29:29,160
Does the documented process win,

784
00:29:29,160 --> 00:29:30,840
or does the person with enough influence

785
00:29:30,840 --> 00:29:32,280
to bend it take control?

786
00:29:32,280 --> 00:29:34,280
That answer tells you more about the organization

787
00:29:34,280 --> 00:29:36,280
than any governance deck ever will.

788
00:29:36,280 --> 00:29:37,800
Power is the hidden operating system

789
00:29:37,800 --> 00:29:39,320
that determines which flows are real

790
00:29:39,320 --> 00:29:40,600
and which ones are just decorative.

791
00:29:40,600 --> 00:29:43,000
You can have a clean approval structure on paper

792
00:29:43,000 --> 00:29:46,040
but if one senior stakeholder can bypass it with a single message

793
00:29:46,040 --> 00:29:48,520
then the real system is influence based

794
00:29:48,520 --> 00:29:49,800
rather than approval based.

795
00:29:49,800 --> 00:29:52,360
You might have role clarity in a racey matrix

796
00:29:52,360 --> 00:29:55,320
but if teams still wait for someone unofficial to bless a move

797
00:29:55,320 --> 00:29:57,880
then authority is not sitting where accountability sits.

798
00:29:57,880 --> 00:30:00,360
Authority is sitting where political safety sits

799
00:30:00,360 --> 00:30:02,520
and that misalignment is incredibly expensive.

800
00:30:02,520 --> 00:30:04,920
When power and responsibility drift apart

801
00:30:04,920 --> 00:30:06,840
shadow governance begins to expand.

802
00:30:06,840 --> 00:30:08,760
People stop asking what the right route is

803
00:30:08,760 --> 00:30:10,440
and start asking who support they need

804
00:30:10,440 --> 00:30:12,280
so the project doesn't get blocked later.

805
00:30:12,280 --> 00:30:14,600
This shift changes behavior immediately.

806
00:30:14,600 --> 00:30:17,080
Meetings get larger and emails get more careful

807
00:30:17,080 --> 00:30:18,840
while decisions are delayed until enough

808
00:30:18,840 --> 00:30:20,920
invisible alignment has happened behind the scenes.

809
00:30:20,920 --> 00:30:23,480
Ownership becomes symbolic because the person

810
00:30:23,480 --> 00:30:25,560
named as the owner isn't the real decider.

811
00:30:25,560 --> 00:30:27,720
From a system perspective this isn't just frustrating

812
00:30:27,720 --> 00:30:28,920
it is a structural defect.

813
00:30:28,920 --> 00:30:30,920
Access should map to responsibility

814
00:30:30,920 --> 00:30:33,400
and authority should map to accountability.

815
00:30:33,400 --> 00:30:35,960
Influence should not be allowed to quietly replace ownership

816
00:30:35,960 --> 00:30:37,080
without being named.

817
00:30:37,080 --> 00:30:39,800
Once hidden influence becomes stronger than formal design

818
00:30:39,800 --> 00:30:40,920
clarity collapses.

819
00:30:40,920 --> 00:30:42,920
This gets much worse in platform environments

820
00:30:42,920 --> 00:30:45,480
like Microsoft 365 or Power Platform.

821
00:30:45,480 --> 00:30:47,880
In these systems access isn't a side issue

822
00:30:47,880 --> 00:30:49,240
it is executable power.

823
00:30:49,240 --> 00:30:52,600
The system is defined by who can see data

824
00:30:52,600 --> 00:30:55,080
who can automate a flow and who has the right

825
00:30:55,080 --> 00:30:56,760
to approve or trigger an action.

826
00:30:56,760 --> 00:31:00,040
These are power questions expressed through digital permissions.

827
00:31:00,040 --> 00:31:02,520
When permissions and accountability are misaligned

828
00:31:02,520 --> 00:31:04,680
the digital environment starts reflecting

829
00:31:04,680 --> 00:31:06,440
that organizational distortion.

830
00:31:06,440 --> 00:31:07,960
The wrong people store the work

831
00:31:07,960 --> 00:31:10,200
while the right people find they cannot act.

832
00:31:10,200 --> 00:31:13,320
Sensitive decisions begin to travel through side channels

833
00:31:13,320 --> 00:31:15,800
an automation gets built by those with access

834
00:31:15,800 --> 00:31:17,400
rather than those with responsibility.

835
00:31:17,400 --> 00:31:19,560
Leaders then wonder why the environment feels fragmented

836
00:31:19,560 --> 00:31:22,040
but the reason is that the power model was fragmented first.

837
00:31:22,040 --> 00:31:25,240
This is also why AI raises the stakes so significantly.

838
00:31:25,240 --> 00:31:27,080
When power is unclear in a manual system

839
00:31:27,080 --> 00:31:29,080
the damage is usually slow and localized.

840
00:31:29,080 --> 00:31:31,640
However when AI and automation enter the picture

841
00:31:31,640 --> 00:31:33,640
scale multiplies the distortion.

842
00:31:33,640 --> 00:31:36,200
A weak approval logic becomes a scaled approval logic

843
00:31:36,200 --> 00:31:37,960
and an unclear ownership boundary

844
00:31:37,960 --> 00:31:40,760
becomes a machine assisted ambiguity generator.

845
00:31:40,760 --> 00:31:42,680
AI doesn't remove power issues.

846
00:31:42,680 --> 00:31:45,320
It just makes their cost visible much faster.

847
00:31:45,320 --> 00:31:47,960
Power alignment has to be treated as design work

848
00:31:47,960 --> 00:31:50,760
rather than an uncomfortable cultural topic we avoid.

849
00:31:50,760 --> 00:31:53,240
It is political but it is also architectural.

850
00:31:53,240 --> 00:31:55,240
We have to be clear about who has authority,

851
00:31:55,240 --> 00:31:58,040
who has access and who carries the consequence of a failure.

852
00:31:58,040 --> 00:32:00,360
If those answers are hidden performance will always be unstable

853
00:32:00,360 --> 00:32:02,760
because people will optimize for survival instead of flow.

854
00:32:02,760 --> 00:32:05,160
They will escalate early and copy everyone on emails

855
00:32:05,160 --> 00:32:07,560
or they will delay commitment and build private buffers

856
00:32:07,560 --> 00:32:08,360
to protect themselves.

857
00:32:08,360 --> 00:32:10,760
This isn't a people problem, it is a system outcome.

858
00:32:10,760 --> 00:32:14,520
The goal isn't to eliminate power which is a fantasy but to align it.

859
00:32:14,520 --> 00:32:16,840
We need to make it visible where authority really sits

860
00:32:16,840 --> 00:32:18,760
and match permissions to accountable roles.

861
00:32:18,760 --> 00:32:20,760
By removing the gap between formal ownership

862
00:32:20,760 --> 00:32:23,880
and actual control we reduce single points of failure.

863
00:32:23,880 --> 00:32:26,360
Once power alignment improves the organization

864
00:32:26,360 --> 00:32:29,160
becomes easier to trust and that trust reduces drag

865
00:32:29,160 --> 00:32:31,000
across every other part of the system.

866
00:32:31,000 --> 00:32:34,760
Now let's map that to what leaders often call transformation.

867
00:32:34,760 --> 00:32:36,840
Why most transformation programs stall?

868
00:32:36,840 --> 00:32:41,240
Now let's map those system principles to what leaders usually call transformation.

869
00:32:41,240 --> 00:32:43,640
Most of these programs stall for one simple reason.

870
00:32:43,640 --> 00:32:45,640
They try to swap out the tools without changing

871
00:32:45,640 --> 00:32:47,640
the operating logic those tools are entering.

872
00:32:47,640 --> 00:32:50,040
You can have a rollout that looks successful on a spreadsheet

873
00:32:50,040 --> 00:32:52,840
while producing almost zero change in your actual business reality.

874
00:32:52,840 --> 00:32:55,640
The platform is live and the licenses are assigned

875
00:32:55,640 --> 00:32:59,240
but the organization still feels exactly the same as it did before the investment.

876
00:32:59,240 --> 00:33:02,040
Training sessions happen and governance boards meet yet

877
00:33:02,040 --> 00:33:06,040
the needle doesn't move because deployment is being mistaken for true redesign.

878
00:33:06,040 --> 00:33:08,840
A new tool doesn't magically become a new operating model

879
00:33:08,840 --> 00:33:11,640
just because you made it available to everyone on the payroll.

880
00:33:11,640 --> 00:33:14,840
Copilot doesn't change how decisions move through your hierarchy

881
00:33:14,840 --> 00:33:18,040
and power automate won't fix a culture of unclear ownership.

882
00:33:18,040 --> 00:33:20,840
A modern internet cannot repair a fragmented truth

883
00:33:20,840 --> 00:33:22,440
just as a collaboration platform

884
00:33:22,440 --> 00:33:24,840
won't automatically create better human interaction.

885
00:33:24,840 --> 00:33:28,440
These tools simply give your existing organization a new surface

886
00:33:28,440 --> 00:33:30,040
to express the same old design,

887
00:33:30,040 --> 00:33:32,440
sometimes faster and occasionally with better branding

888
00:33:32,440 --> 00:33:34,040
but it is still the same design.

889
00:33:34,040 --> 00:33:38,040
This is why so many transformation efforts end up increasing visible activity

890
00:33:38,040 --> 00:33:40,840
while leaving the structural friction completely untouched.

891
00:33:40,840 --> 00:33:43,640
We see a few specific patterns behind this failure.

892
00:33:43,640 --> 00:33:47,240
Starting with pilot logic that lacks any real architectural follow-through.

893
00:33:47,240 --> 00:33:50,840
A small team proves a use case where reporting gets faster

894
00:33:50,840 --> 00:33:54,440
or onboarding gets smoother and suddenly everyone in leadership gets excited

895
00:33:54,440 --> 00:33:57,240
but that pilot usually sits inside a protected pocket of clarity

896
00:33:57,240 --> 00:34:00,040
that doesn't exist in the wider messier business.

897
00:34:00,040 --> 00:34:04,040
Once that solution needs to cross functions or handle shared data dependencies

898
00:34:04,040 --> 00:34:07,640
the gains collapse because the surrounding organization was never redesigned

899
00:34:07,640 --> 00:34:08,840
to absorb the change.

900
00:34:08,840 --> 00:34:11,240
The second pattern involves process mapping

901
00:34:11,240 --> 00:34:13,640
based on intended workflows instead of lived behavior

902
00:34:13,640 --> 00:34:16,040
which is a massive trap for most architects.

903
00:34:16,040 --> 00:34:18,840
Organizations love to document how work is supposed to happen

904
00:34:18,840 --> 00:34:22,040
by defining which roles have myths in which system updates the record.

905
00:34:22,040 --> 00:34:26,040
It looks clean on a slide but the real work often happens in the shadows of that diagram.

906
00:34:26,040 --> 00:34:28,440
The exceptions get handled in a quick chat,

907
00:34:28,440 --> 00:34:31,640
missing context gets rebuilt in an unscheduled meeting

908
00:34:31,640 --> 00:34:35,640
and the actual decision waits for someone who isn't even shown on the official map.

909
00:34:35,640 --> 00:34:38,440
When transformation is built around procedural fiction,

910
00:34:38,440 --> 00:34:43,640
reality eventually pushes back and leaders often mistake that friction for employee resistance.

911
00:34:43,640 --> 00:34:48,040
Usually it isn't resistance at all, it is simply the system refusing to behave like a map

912
00:34:48,040 --> 00:34:49,240
that doesn't match the terrain.

913
00:34:49,240 --> 00:34:53,240
The third pattern is about incentives and this matters more than many leaders are willing to admit

914
00:34:53,240 --> 00:34:54,440
during a board meeting.

915
00:34:54,440 --> 00:34:59,240
If your organization still rewards effort and compliance theatre over actual results

916
00:34:59,240 --> 00:35:02,840
then your transformation will naturally optimize for visible busyness.

917
00:35:02,840 --> 00:35:06,440
People will attend every training and generate every required dashboard

918
00:35:06,440 --> 00:35:08,840
yet they won't actually improve the business outcomes

919
00:35:08,840 --> 00:35:12,440
because the reward structure is attached to participation rather than performance

920
00:35:12,440 --> 00:35:16,840
the system learns to appear transformed without actually becoming more capable.

921
00:35:16,840 --> 00:35:21,240
Finally, a fourth pattern emerges where exception handling is completely ignored

922
00:35:21,240 --> 00:35:22,840
during the design phase.

923
00:35:22,840 --> 00:35:25,240
The standard happy path is designed beautifully

924
00:35:25,240 --> 00:35:27,640
but real organizations don't run on standard paths

925
00:35:27,640 --> 00:35:30,040
they run on variation and judgment calls made under pressure.

926
00:35:30,040 --> 00:35:33,240
If your transformation only accounts for the perfect scenario

927
00:35:33,240 --> 00:35:37,240
the very first missing data point will push people back into manual coordination

928
00:35:37,240 --> 00:35:38,440
and political fallbacks.

929
00:35:38,440 --> 00:35:41,640
Once that happens often enough trust in the new model disappears

930
00:35:41,640 --> 00:35:44,040
and people return to their old survival habits

931
00:35:44,040 --> 00:35:46,440
like side channels and informal approvals.

932
00:35:46,440 --> 00:35:49,240
The transformation technically exists on the IT roadmap

933
00:35:49,240 --> 00:35:52,440
but the real operating model stays exactly where it was 10 years ago.

934
00:35:52,440 --> 00:35:54,840
This is why stalled transformations

935
00:35:54,840 --> 00:35:57,240
leave a footprint of more dashboards and more meetings

936
00:35:57,240 --> 00:36:00,440
but significantly less clarity and less trust.

937
00:36:00,440 --> 00:36:03,240
From a system perspective that isn't a failure of adoption

938
00:36:03,240 --> 00:36:05,640
it is a case of misaligned redesign.

939
00:36:05,640 --> 00:36:08,040
The organization changed the layer people could see

940
00:36:08,040 --> 00:36:11,240
while leaving the underlying flow architecture mostly untouched

941
00:36:11,240 --> 00:36:13,640
if we want to understand what real transformation looks like

942
00:36:13,640 --> 00:36:15,640
we have to stop looking at launch plans

943
00:36:15,640 --> 00:36:17,240
and start looking at live behavior.

944
00:36:17,240 --> 00:36:20,040
The most useful work doesn't happen during implementation

945
00:36:20,040 --> 00:36:21,640
it happens during observation.

946
00:36:21,640 --> 00:36:24,440
From fragmented to designed before the redesign

947
00:36:24,440 --> 00:36:27,640
let's make this concrete because these concepts can sound abstract

948
00:36:27,640 --> 00:36:30,440
until you see them playing out inside a real environment.

949
00:36:30,440 --> 00:36:32,440
I'm thinking of one specific organization

950
00:36:32,440 --> 00:36:34,440
that looked incredibly mature from the outside

951
00:36:34,440 --> 00:36:37,240
they had a strong Microsoft 365 footprint,

952
00:36:37,240 --> 00:36:38,840
clear investment in governance,

953
00:36:38,840 --> 00:36:41,640
and a power platform environment that was already in active use.

954
00:36:41,640 --> 00:36:44,440
They had documented processes and security controls

955
00:36:44,440 --> 00:36:47,640
representing a serious effort from both IT and business leaders

956
00:36:47,640 --> 00:36:49,240
to create a sense of order.

957
00:36:49,240 --> 00:36:52,040
No one would have described this company as careless

958
00:36:52,040 --> 00:36:54,840
and if anything they looked more disciplined than most of their competitors.

959
00:36:54,840 --> 00:36:56,840
This wasn't a story about chaos.

960
00:36:56,840 --> 00:36:58,840
It was a story about fragmentation,

961
00:36:58,840 --> 00:37:01,240
wearing the expensive clothes of corporate maturity.

962
00:37:01,240 --> 00:37:03,240
The people inside the system were highly competent

963
00:37:03,240 --> 00:37:05,240
their platform choices were reasonable

964
00:37:05,240 --> 00:37:06,840
and their intent was genuinely good.

965
00:37:06,840 --> 00:37:08,040
Despite all of that,

966
00:37:08,040 --> 00:37:10,840
the business kept feeling slower than it should have

967
00:37:10,840 --> 00:37:13,640
and that slowness wasn't happening in one dramatic place.

968
00:37:13,640 --> 00:37:15,240
It was happening everywhere in small ways

969
00:37:15,240 --> 00:37:17,240
that added up like a decision pausing

970
00:37:17,240 --> 00:37:20,040
because a team lacked the context that was never carried forward.

971
00:37:20,040 --> 00:37:22,040
A report would circulate through the office

972
00:37:22,040 --> 00:37:23,640
then immediately lose credibility

973
00:37:23,640 --> 00:37:26,040
because the receiving group used a different source

974
00:37:26,040 --> 00:37:27,640
and a different definition.

975
00:37:27,640 --> 00:37:30,040
An automation might remove one manual step

976
00:37:30,040 --> 00:37:32,840
but the exceptions it created still had nowhere clean to go

977
00:37:32,840 --> 00:37:34,440
within the existing structure.

978
00:37:34,440 --> 00:37:36,840
Ownership looked clear inside a specific department

979
00:37:36,840 --> 00:37:38,040
yet it dissolved the moment

980
00:37:38,040 --> 00:37:40,040
where across the boundary into another territory

981
00:37:40,040 --> 00:37:42,440
the system started showing up in the language people used

982
00:37:42,440 --> 00:37:44,440
with constant complaints about too many meetings

983
00:37:44,440 --> 00:37:45,640
and repeated escalations.

984
00:37:45,640 --> 00:37:46,940
Everyone could see the friction

985
00:37:46,940 --> 00:37:48,140
but they were naming the problem

986
00:37:48,140 --> 00:37:50,940
based on the specific angle they happened to own.

987
00:37:50,940 --> 00:37:52,640
When organizations are fragmented,

988
00:37:52,640 --> 00:37:55,740
every function tends to diagnose the issue locally

989
00:37:55,740 --> 00:37:57,340
rather than looking at the whole system.

990
00:37:57,340 --> 00:37:59,340
IT says the issue is uncontrolled growth

991
00:37:59,340 --> 00:38:02,940
while operations claims the problem is a lack of process discipline.

992
00:38:02,940 --> 00:38:04,940
Business teams complain about slow support

993
00:38:04,940 --> 00:38:06,540
leaders point to a lack of accountability

994
00:38:06,540 --> 00:38:08,940
and the users just say the tools are too complex.

995
00:38:08,940 --> 00:38:10,940
All of those observations can be true

996
00:38:10,940 --> 00:38:12,540
at the same time while still missing

997
00:38:12,540 --> 00:38:14,540
the structural reality of the situation.

998
00:38:14,540 --> 00:38:17,340
In this case the dominant explanation from leadership

999
00:38:17,340 --> 00:38:20,540
was adoption assuming that if people just use the tools better

1000
00:38:20,540 --> 00:38:21,740
things would improve.

1001
00:38:21,740 --> 00:38:23,340
They believe that more consistency

1002
00:38:23,340 --> 00:38:24,940
or another automated workflow

1003
00:38:24,940 --> 00:38:27,740
would finally fix the underlying drag on performance.

1004
00:38:27,740 --> 00:38:31,340
That logic is common because it protects the basic architecture by

1005
00:38:31,340 --> 00:38:33,740
assuming the design is right and the people are the problem.

1006
00:38:33,740 --> 00:38:35,740
When you looked at the actual business reality

1007
00:38:35,740 --> 00:38:37,340
that explanation didn't hold up

1008
00:38:37,340 --> 00:38:39,340
because the environment had already been optimized

1009
00:38:39,340 --> 00:38:40,940
with more controls and more structure.

1010
00:38:40,940 --> 00:38:42,540
The gains were strangely local

1011
00:38:42,540 --> 00:38:44,940
meaning teams got better at managing their own silos

1012
00:38:44,940 --> 00:38:47,740
but the organization didn't get better at moving as a whole.

1013
00:38:47,740 --> 00:38:51,340
Local optimization had increased administrative sophistication

1014
00:38:51,340 --> 00:38:53,740
without producing any kind of integrated performance.

1015
00:38:53,740 --> 00:38:54,940
The tech stack looked mature

1016
00:38:54,940 --> 00:38:56,940
but the operating model stayed fragmented

1017
00:38:56,940 --> 00:39:00,140
and once that happens, the people inside the system begin compensating.

1018
00:39:00,140 --> 00:39:02,940
They carry context manually and remember what the process

1019
00:39:02,940 --> 00:39:06,140
forgot building side channels just to preserve some sense of momentum.

1020
00:39:06,140 --> 00:39:08,540
They join extra meetings because the formal flow

1021
00:39:08,540 --> 00:39:11,740
no longer gives them enough confidence to act without checking three times.

1022
00:39:11,740 --> 00:39:13,340
The organization keeps functioning

1023
00:39:13,340 --> 00:39:16,540
but it does so at a massive cost because the tools didn't fail.

1024
00:39:16,540 --> 00:39:17,340
The design did.

1025
00:39:17,340 --> 00:39:19,340
The people were acting as human middleware

1026
00:39:19,340 --> 00:39:22,140
between misaligned parts which is the phrase I keep coming back to

1027
00:39:22,140 --> 00:39:23,740
when I see these systems.

1028
00:39:23,740 --> 00:39:26,140
Human middleware consists of highly capable people

1029
00:39:26,140 --> 00:39:28,940
stitching together a system that looks complete on paper

1030
00:39:28,940 --> 00:39:30,940
but cannot carry authority on its own.

1031
00:39:30,940 --> 00:39:34,540
From the outside, leadership saw a mature digital workplace.

1032
00:39:34,540 --> 00:39:36,540
But from the inside, the people doing the work

1033
00:39:36,540 --> 00:39:38,140
were still bridging gaps by hand.

1034
00:39:38,140 --> 00:39:40,140
That is the before state we have to understand

1035
00:39:40,140 --> 00:39:42,140
if we want to build something better.

1036
00:39:42,140 --> 00:39:44,140
It isn't dysfunction in the obvious sense

1037
00:39:44,140 --> 00:39:47,740
it is a well-intentioned environment that has become structurally heavy

1038
00:39:47,740 --> 00:39:49,340
without becoming structurally clear.

1039
00:39:49,340 --> 00:39:50,940
Once that became visible to us,

1040
00:39:50,940 --> 00:39:52,940
the work stopped being about implementation

1041
00:39:52,940 --> 00:39:55,740
and became an observation of how the system actually lived

1042
00:39:55,740 --> 00:39:58,540
from fragmented to designed seeing reality.

1043
00:39:58,540 --> 00:40:00,140
The next step in this journey

1044
00:40:00,140 --> 00:40:01,740
wasn't about another software rollout,

1045
00:40:01,740 --> 00:40:03,340
a new set of governance documents

1046
00:40:03,340 --> 00:40:05,740
or a loud internal adoption campaign

1047
00:40:05,740 --> 00:40:08,140
instead the real work started when we decided to look at

1048
00:40:08,140 --> 00:40:09,740
what was actually happening on the ground,

1049
00:40:09,740 --> 00:40:11,740
which sounds simple until you realize

1050
00:40:11,740 --> 00:40:14,940
how many official stories organizations tell themselves

1051
00:40:14,940 --> 00:40:16,540
about how work moves.

1052
00:40:16,540 --> 00:40:18,940
In the official version, a request enters the system

1053
00:40:18,940 --> 00:40:20,940
and approval happens at a specific desk

1054
00:40:20,940 --> 00:40:23,340
and the record gets updated before the handoff is complete

1055
00:40:23,340 --> 00:40:24,540
and the workflow closes.

1056
00:40:24,540 --> 00:40:26,940
It looks clean, rational and perfectly presentable

1057
00:40:26,940 --> 00:40:28,140
on a slide deck,

1058
00:40:28,140 --> 00:40:30,540
but formal process maps usually describe

1059
00:40:30,540 --> 00:40:32,540
how leadership intends for things to work

1060
00:40:32,540 --> 00:40:34,540
rather than how they are actually executed

1061
00:40:34,540 --> 00:40:35,740
by the people doing the job.

1062
00:40:35,740 --> 00:40:38,540
So instead of asking how the process was supposed to function,

1063
00:40:38,540 --> 00:40:40,540
we started asking a much more direct question,

1064
00:40:40,540 --> 00:40:42,540
what actually happens from the moment work

1065
00:40:42,540 --> 00:40:45,340
enters the system to the moment something real gets done?

1066
00:40:45,340 --> 00:40:48,140
That shift in perspective changed everything

1067
00:40:48,140 --> 00:40:50,540
because once we started tracing actual human behavior,

1068
00:40:50,540 --> 00:40:52,140
the hidden architecture of the organization

1069
00:40:52,140 --> 00:40:54,140
became visible almost immediately.

1070
00:40:54,140 --> 00:40:56,540
We discovered that decisions were not really waiting

1071
00:40:56,540 --> 00:40:58,140
where the documentation said they were

1072
00:40:58,140 --> 00:40:59,740
but were instead stuck in places

1073
00:40:59,740 --> 00:41:02,140
where context had to be rebuilt from scratch.

1074
00:41:02,140 --> 00:41:04,940
A team would receive a request without enough rationale

1075
00:41:04,940 --> 00:41:07,740
so they would pause, ask clarifying questions,

1076
00:41:07,740 --> 00:41:10,140
schedule a call and recreate the missing history

1077
00:41:10,140 --> 00:41:12,140
before they could finally decide.

1078
00:41:12,140 --> 00:41:14,940
On paper, this looked like a short and simple approval step,

1079
00:41:14,940 --> 00:41:17,740
but in reality, it was a massive context recovery loop

1080
00:41:17,740 --> 00:41:20,140
that drained time and energy from everyone involved.

1081
00:41:20,140 --> 00:41:22,540
That distinction matters because the delay wasn't caused

1082
00:41:22,540 --> 00:41:24,540
by a lack of will or a slow employee

1083
00:41:24,540 --> 00:41:27,340
but was a direct result of the flow design itself.

1084
00:41:27,340 --> 00:41:29,340
We saw the same pattern in the data

1085
00:41:29,340 --> 00:41:32,140
where reports looked stable until they crossed team boundaries

1086
00:41:32,140 --> 00:41:35,740
and people started checking the numbers against their own local extracts.

1087
00:41:35,740 --> 00:41:38,700
Different teams were using different versions of the same business objects

1088
00:41:38,700 --> 00:41:40,300
not because they wanted fragmentation

1089
00:41:40,300 --> 00:41:43,740
but because the system gave them no single operational path

1090
00:41:43,740 --> 00:41:45,740
they could actually trust under pressure.

1091
00:41:45,740 --> 00:41:47,740
To survive, they built compensations

1092
00:41:47,740 --> 00:41:50,940
like manual exports, private trackers and reference files

1093
00:41:50,940 --> 00:41:53,740
which meant that what looked like wasteful duplication

1094
00:41:53,740 --> 00:41:56,140
was actually a necessary trust workaround.

1095
00:41:56,140 --> 00:41:57,740
Then we found the hand of dead zones,

1096
00:41:57,740 --> 00:41:59,740
those places where work was technically transferred

1097
00:41:59,740 --> 00:42:03,740
but structurally abandoned because no one person clearly owned the next move.

1098
00:42:03,740 --> 00:42:05,740
Everyone was included in the email chain

1099
00:42:05,740 --> 00:42:07,340
but no one was truly accountable

1100
00:42:07,340 --> 00:42:09,340
so the item sat in a procedural fog

1101
00:42:09,340 --> 00:42:12,940
until someone with enough seniority or memory eventually pushed it forward.

1102
00:42:12,940 --> 00:42:15,340
From the outside, this looked like slow execution

1103
00:42:15,340 --> 00:42:17,340
but from the inside, it was an ownership vacuum

1104
00:42:17,340 --> 00:42:20,540
that forced people to work harder just to keep things moving.

1105
00:42:20,540 --> 00:42:23,740
We also found the same approval logic appearing multiple times

1106
00:42:23,740 --> 00:42:26,540
across a single flow where different people were asked to validate

1107
00:42:26,540 --> 00:42:28,940
slightly different versions of the same thing.

1108
00:42:28,940 --> 00:42:31,340
This didn't happen because each review added new judgment

1109
00:42:31,340 --> 00:42:33,740
but because nobody had enough confidence in the upstream decision

1110
00:42:33,740 --> 00:42:36,940
to let the work travel cleanly without checking it again.

1111
00:42:36,940 --> 00:42:39,340
Approval had become a form of structural reassurance

1112
00:42:39,340 --> 00:42:41,340
and reassurance is incredibly expensive

1113
00:42:41,340 --> 00:42:44,140
especially when the organization pretends it is a form of control

1114
00:42:44,140 --> 00:42:46,540
what made this phase of the project important

1115
00:42:46,540 --> 00:42:48,540
was the total removal of blame

1116
00:42:48,540 --> 00:42:50,940
which was critical because if you look for underperformance

1117
00:42:50,940 --> 00:42:54,540
at the individual level, you will miss the systemic pattern every time.

1118
00:42:54,540 --> 00:42:56,940
The people inside the system were not the problem

1119
00:42:56,940 --> 00:43:00,140
in many cases they were the only reason the system still functioned at all.

1120
00:43:00,140 --> 00:43:02,940
They were remembering the context the tools failed to preserve

1121
00:43:02,940 --> 00:43:05,340
translating between teams with different definitions

1122
00:43:05,340 --> 00:43:08,140
and spotting exceptions before the workflows could break.

1123
00:43:08,140 --> 00:43:10,540
They were using meetings, chats and personal relationships

1124
00:43:10,540 --> 00:43:12,540
as a form of structural compensation

1125
00:43:12,540 --> 00:43:15,340
which isn't inefficiency in the human sense

1126
00:43:15,340 --> 00:43:17,740
but rather a form of resilience at the human layer

1127
00:43:17,740 --> 00:43:19,740
because the design layer is incomplete.

1128
00:43:19,740 --> 00:43:22,540
This matters for leaders because once you see reality clearly

1129
00:43:22,540 --> 00:43:26,140
the narrative changes from why are people creating workarounds

1130
00:43:26,140 --> 00:43:30,940
to what kind of design makes those workarounds necessary for basic continuity.

1131
00:43:30,940 --> 00:43:33,340
Once that question is visible

1132
00:43:33,340 --> 00:43:35,740
redesign stops being a theoretical exercise

1133
00:43:35,740 --> 00:43:37,940
and you can finally point to the exact spots

1134
00:43:37,940 --> 00:43:42,140
where context collapses, trust breaks, and ownership disappears.

1135
00:43:42,140 --> 00:43:44,940
You see where power quietly overrides the process

1136
00:43:44,940 --> 00:43:48,540
and where the people inside the system are keeping the whole thing alive by hand.

1137
00:43:48,540 --> 00:43:49,740
That was the turning point

1138
00:43:49,740 --> 00:43:51,340
because once reality became visible

1139
00:43:51,340 --> 00:43:53,340
nobody needed another maturity story

1140
00:43:53,340 --> 00:43:56,540
they needed a redesign story that moved from describing symptoms

1141
00:43:56,540 --> 00:43:58,540
to changing the structure.

1142
00:43:58,540 --> 00:44:00,940
From fragmented to designed, what changed?

1143
00:44:00,940 --> 00:44:02,940
Once the reality of the system was visible

1144
00:44:02,940 --> 00:44:06,540
the work didn't actually get bigger but it did become much sharper.

1145
00:44:06,540 --> 00:44:07,740
This is an important distinction

1146
00:44:07,740 --> 00:44:09,940
because many organizations respond to these moments

1147
00:44:09,940 --> 00:44:12,540
by launching a massive transformation machine

1148
00:44:12,540 --> 00:44:14,940
full of work streams, steering groups

1149
00:44:14,940 --> 00:44:16,940
and complex change roadmaps.

1150
00:44:16,940 --> 00:44:19,740
In our case the useful move was the exact opposite

1151
00:44:19,740 --> 00:44:22,140
focusing on reducing the number of moving parts

1152
00:44:22,140 --> 00:44:26,540
and tightening the architecture to make the real path easier to see and carry.

1153
00:44:26,540 --> 00:44:28,940
The first major change was in the decision parts

1154
00:44:28,940 --> 00:44:32,140
where we stopped treating every decision as if it had the same weight and impact.

1155
00:44:32,140 --> 00:44:36,940
We separated decisions by type, moving reversible choices closer to the actual work

1156
00:44:36,940 --> 00:44:38,940
with clearer owners and fewer approval points.

1157
00:44:38,940 --> 00:44:42,140
A reversible or high impact decisions kept more friction

1158
00:44:42,140 --> 00:44:43,740
but it became a deliberate form of friction

1159
00:44:43,740 --> 00:44:45,340
designed to test assumptions

1160
00:44:45,340 --> 00:44:48,140
rather than a habit inherited from old processes.

1161
00:44:48,140 --> 00:44:50,540
This alone reduced the surprising amount of drag

1162
00:44:50,540 --> 00:44:53,740
because people no longer had to guess whether they were allowed to move.

1163
00:44:53,740 --> 00:44:55,340
They knew exactly where they stood

1164
00:44:55,340 --> 00:44:58,540
and where to escalate if they couldn't move alone.

1165
00:44:58,540 --> 00:45:00,540
The second shift focused on data ownership

1166
00:45:00,540 --> 00:45:02,540
where instead of trying to solve trust issues

1167
00:45:02,540 --> 00:45:05,340
with more reporting, the organization started aligning ownership

1168
00:45:05,340 --> 00:45:07,340
around core business objects.

1169
00:45:07,340 --> 00:45:10,540
This changed the conversation from who built this report

1170
00:45:10,540 --> 00:45:12,140
to who owns the meaning of this number

1171
00:45:12,140 --> 00:45:14,540
and which source is the operational truth.

1172
00:45:14,540 --> 00:45:17,340
Once those answers were clear the duplication started falling away

1173
00:45:17,340 --> 00:45:18,540
not because we banned spreadsheets

1174
00:45:18,540 --> 00:45:22,940
but because fewer people needed private reconciliations just to feel safe enough to act.

1175
00:45:22,940 --> 00:45:26,140
That is the fundamental difference between control and design.

1176
00:45:26,140 --> 00:45:27,740
One punishes the work around

1177
00:45:27,740 --> 00:45:31,340
while the other removes the reason for the work around to exist in the first place.

1178
00:45:31,340 --> 00:45:32,940
Then we looked at the interaction layer

1179
00:45:32,940 --> 00:45:35,340
which wasn't about telling people to communicate better

1180
00:45:35,340 --> 00:45:38,140
but about being explicit about where context actually belongs.

1181
00:45:38,140 --> 00:45:41,340
We defined what gets decided in meetings versus what stays in chat

1182
00:45:41,340 --> 00:45:43,740
and we ensured that rationale lived in a place

1183
00:45:43,740 --> 00:45:45,740
where someone entering the project late

1184
00:45:45,740 --> 00:45:48,940
could recover the state of the work without reopening the whole discussion.

1185
00:45:48,940 --> 00:45:52,140
This redesign sounds small until you see the effect

1186
00:45:52,140 --> 00:45:54,940
because once context starts traveling with the work

1187
00:45:54,940 --> 00:45:57,340
the coordination load on the team drops almost immediately.

1188
00:45:57,340 --> 00:46:00,140
There are fewer repair meetings, fewer duplicated explanations

1189
00:46:00,140 --> 00:46:04,940
and fewer moments where progress depends entirely on the memory of the most informed person in the room.

1190
00:46:04,940 --> 00:46:07,340
We then connected this to permissions and access

1191
00:46:07,340 --> 00:46:10,940
treating it as an operating model decision rather than just a simple admin task.

1192
00:46:10,940 --> 00:46:13,340
We mapped access directly to accountable roles

1193
00:46:13,340 --> 00:46:16,540
asking who should be able to trigger a flow, who should approve

1194
00:46:16,540 --> 00:46:20,140
and who should see sensitive context based on their actual responsibility.

1195
00:46:20,140 --> 00:46:22,940
This mattered because once access reflects responsibility,

1196
00:46:22,940 --> 00:46:24,940
the platform becomes structurally cleaner

1197
00:46:24,940 --> 00:46:29,740
and people stop improvising around blocked paths or overpowered roles that shouldn't exist.

1198
00:46:29,740 --> 00:46:32,540
We also removed a lot of overlapping procedural language,

1199
00:46:32,540 --> 00:46:34,940
cutting out parallel routes and duplicate controls

1200
00:46:34,940 --> 00:46:37,340
that were only there to compensate for a lack of trust.

1201
00:46:37,340 --> 00:46:39,740
This made the operating model easier to read

1202
00:46:39,740 --> 00:46:42,940
and readability is vital because if people cannot understand the path

1203
00:46:42,940 --> 00:46:45,340
they cannot execute it with any level of confidence.

1204
00:46:45,340 --> 00:46:47,340
The redesign didn't add sophistication,

1205
00:46:47,340 --> 00:46:50,140
it removed ambiguity which is why the result felt different

1206
00:46:50,140 --> 00:46:53,740
very quickly without being more digital or more governed.

1207
00:46:53,740 --> 00:46:56,940
It was simply more coherent, allowing the existing tools

1208
00:46:56,940 --> 00:47:00,940
like Microsoft 365 and the Power Platform to support a cleaner flow

1209
00:47:00,940 --> 00:47:03,340
instead of competing with one another for attention.

1210
00:47:03,340 --> 00:47:06,740
From a system perspective, that is the only change that matters.

1211
00:47:06,740 --> 00:47:09,340
Finding a better fit between the flow of decisions,

1212
00:47:09,340 --> 00:47:12,140
the flow of data and the rules of interaction.

1213
00:47:12,140 --> 00:47:16,540
Once that fit improved, the people inside the system no longer had to keep the whole thing alive

1214
00:47:16,540 --> 00:47:18,540
through constant structural compensation.

1215
00:47:18,540 --> 00:47:21,340
That is the moment when the outcomes finally started to change

1216
00:47:21,340 --> 00:47:23,740
because the system was finally designed to sustain the work

1217
00:47:23,740 --> 00:47:25,740
rather than drain the people doing it.

1218
00:47:25,740 --> 00:47:28,140
So, from fragmented to design, what improved?

1219
00:47:28,140 --> 00:47:29,740
So, what actually got better?

1220
00:47:29,740 --> 00:47:31,740
It wasn't a magical overnight transformation

1221
00:47:31,740 --> 00:47:34,140
and it certainly didn't happen because the leadership team

1222
00:47:34,140 --> 00:47:36,540
stumbled upon some perfect management framework.

1223
00:47:36,540 --> 00:47:38,140
The real shift was much more fundamental.

1224
00:47:38,140 --> 00:47:40,940
What improved was the direct relationship between effort and outcome,

1225
00:47:40,940 --> 00:47:44,940
which is always the first sign that the system is finally being designed correctly.

1226
00:47:44,940 --> 00:47:48,140
Before we started the redesign, people were working themselves to the bone

1227
00:47:48,140 --> 00:47:50,140
just to keep things moving at all.

1228
00:47:50,140 --> 00:47:52,940
After the changes took hold, that same level of energy

1229
00:47:52,940 --> 00:47:54,940
started producing much cleaner progress.

1230
00:47:54,940 --> 00:47:56,940
Instead of wasting hours on constant translation,

1231
00:47:56,940 --> 00:47:59,740
endless reassurance and fixing broken handoffs,

1232
00:47:59,740 --> 00:48:02,940
the team could finally focus on actually moving the business forward.

1233
00:48:02,940 --> 00:48:04,940
The first thing to speed up was decision making.

1234
00:48:04,940 --> 00:48:07,740
This didn't happen because everyone suddenly became more courageous.

1235
00:48:07,740 --> 00:48:11,740
It happened because the system stopped treating every single choice like a high-stakes crisis.

1236
00:48:11,740 --> 00:48:14,940
Teams started acting within much clearer boundaries.

1237
00:48:14,940 --> 00:48:16,940
Escalation points became obvious

1238
00:48:16,940 --> 00:48:21,340
and fewer decisions sat rotting in hidden cues while waiting for an unofficial blessing.

1239
00:48:21,340 --> 00:48:24,540
When that latency drops, the entire rhythm of the company changes.

1240
00:48:24,540 --> 00:48:27,740
And when latency drops, something else usually follows.

1241
00:48:27,740 --> 00:48:29,740
Escalation volume starts to plummet.

1242
00:48:29,740 --> 00:48:32,940
That might sound like a minor detail, but it's a massive structural win.

1243
00:48:32,940 --> 00:48:36,140
Constant escalation is almost always a symptom of a deeper problem,

1244
00:48:36,140 --> 00:48:40,540
signaling that local authority is weak or that people simply don't trust the path they're on.

1245
00:48:40,540 --> 00:48:44,540
Once the flow of decisions became clear, fewer issues had to be kicked upstairs

1246
00:48:44,540 --> 00:48:46,140
just to gain a sense of legitimacy.

1247
00:48:46,140 --> 00:48:48,540
Ownership also became something people could actually use.

1248
00:48:48,540 --> 00:48:52,140
I'm not talking about ownership as a slogan or a line in a job description.

1249
00:48:52,140 --> 00:48:53,340
I mean, usable ownership.

1250
00:48:53,340 --> 00:48:56,140
Most organizations already have plenty of racey models

1251
00:48:56,140 --> 00:48:58,140
and governance charters gathering digital dust,

1252
00:48:58,140 --> 00:49:01,740
but usable ownership means every person knows exactly who decides,

1253
00:49:01,740 --> 00:49:04,940
who contributes and who deals with the consequences when things change.

1254
00:49:04,940 --> 00:49:07,740
That clarity lowers the coordination load immediately.

1255
00:49:07,740 --> 00:49:10,540
We saw fewer check-ins just to confirm who was responsible,

1256
00:49:10,540 --> 00:49:13,740
fewer reply-all messages sent as professional protection,

1257
00:49:13,740 --> 00:49:16,540
and far fewer situations where everyone was involved,

1258
00:49:16,540 --> 00:49:18,140
but nobody was truly accountable.

1259
00:49:18,140 --> 00:49:19,540
Then we saw the data effect.

1260
00:49:19,540 --> 00:49:23,340
Once the core business objects had clear owners and fewer conflicting parts,

1261
00:49:23,340 --> 00:49:26,140
the quality of reporting improved in a very practical way.

1262
00:49:26,140 --> 00:49:28,540
It wasn't that every metric suddenly became perfect,

1263
00:49:28,540 --> 00:49:32,540
but teams finally stopped arguing about which version of reality was the right one.

1264
00:49:32,540 --> 00:49:35,340
Reconciliation efforts dropped reporting disputes vanished

1265
00:49:35,340 --> 00:49:38,540
and downstream action improved because trust arrived much faster than before.

1266
00:49:38,540 --> 00:49:42,540
This is easily one of the most overlooked gains in any redesign project.

1267
00:49:42,540 --> 00:49:45,340
Better data trust isn't just a win for the analytics team.

1268
00:49:45,340 --> 00:49:47,740
It completely changes your operational confidence.

1269
00:49:47,740 --> 00:49:52,140
People move significantly faster when they no longer have to renegotiate the basic facts

1270
00:49:52,140 --> 00:49:53,740
before they can even start responding to them.

1271
00:49:53,740 --> 00:49:55,740
The way people interacted also got a lot lighter.

1272
00:49:55,740 --> 00:49:57,340
I don't mean softer or more polite.

1273
00:49:57,340 --> 00:50:00,140
I mean, the actual weight of collaboration decreased.

1274
00:50:00,140 --> 00:50:04,540
We had fewer repair meetings because the context of a project was actually surviving the handoff

1275
00:50:04,540 --> 00:50:06,140
from one person to the next.

1276
00:50:06,140 --> 00:50:08,940
Someone entering a decision late could catch up on the logic

1277
00:50:08,940 --> 00:50:12,540
without forcing everyone to restart the entire conversation from scratch.

1278
00:50:12,540 --> 00:50:15,740
Chad stopped being a place where people went to recover lost information

1279
00:50:15,740 --> 00:50:18,140
and became a useful support surface instead.

1280
00:50:18,140 --> 00:50:20,540
Documentation finally started carrying the continuity

1281
00:50:20,540 --> 00:50:23,740
that used to live exclusively inside the heads of a few reliable veterans.

1282
00:50:23,740 --> 00:50:26,140
That shift reduced a massive amount of dependency risk,

1283
00:50:26,140 --> 00:50:27,740
and why does that matter so much?

1284
00:50:27,740 --> 00:50:30,540
Because concentrated memories are a single point of failure.

1285
00:50:30,540 --> 00:50:34,540
If your execution depends on the same three informal translators or context holders

1286
00:50:34,540 --> 00:50:38,140
every time we're crosses a department line, your organization isn't resilient.

1287
00:50:38,140 --> 00:50:41,340
It's just being held together by a few overloaded humans.

1288
00:50:41,340 --> 00:50:44,140
Better interaction design creates redundancy.

1289
00:50:44,140 --> 00:50:48,140
And redundancy is exactly what gives the system its structural resilience.

1290
00:50:48,140 --> 00:50:49,740
Now map all of that to AI.

1291
00:50:49,740 --> 00:50:52,940
This is where the improvement became strategically visible for the board.

1292
00:50:52,940 --> 00:50:55,740
AI outcomes improved not because we bought better models

1293
00:50:55,740 --> 00:51:00,140
because the organization underneath finally stopped fighting the automation.

1294
00:51:00,140 --> 00:51:02,140
The outputs had clear roots into action.

1295
00:51:02,140 --> 00:51:04,140
Permissions were aligned with real roles

1296
00:51:04,140 --> 00:51:06,540
and the trust in source data was finally there.

1297
00:51:06,540 --> 00:51:09,340
Human judgments stayed in the loop where it actually mattered

1298
00:51:09,340 --> 00:51:12,140
rather than being used to manually fix data errors.

1299
00:51:12,140 --> 00:51:14,140
AI stopped behaving like a chaos multiplier

1300
00:51:14,140 --> 00:51:16,140
and started acting like a genuine accelerator

1301
00:51:16,140 --> 00:51:18,940
that is a very different role for technology to play

1302
00:51:18,940 --> 00:51:20,940
and is the biggest lesson from this entire case.

1303
00:51:20,940 --> 00:51:24,140
They didn't get better results by stacking more tools on top of a mess.

1304
00:51:24,140 --> 00:51:27,740
They got better results by redesigning how the work actually moved through the pipes.

1305
00:51:27,740 --> 00:51:30,540
This is the part I think leaders really need to sit with for a moment.

1306
00:51:30,540 --> 00:51:34,940
Most organizations are still trying to buy performance through isolated, shiny improvements.

1307
00:51:34,940 --> 00:51:38,540
Another dashboard, another automation, or another governance layer.

1308
00:51:38,540 --> 00:51:42,140
But in a complex environment, performance doesn't come from what you stack on top.

1309
00:51:42,140 --> 00:51:44,940
It comes from how you design the flow underneath.

1310
00:51:44,940 --> 00:51:47,740
Once that flow is clean, speed improves naturally.

1311
00:51:47,740 --> 00:51:49,740
Clarity and trust follow right behind it.

1312
00:51:49,740 --> 00:51:53,740
Only then does your technology finally have something stable enough to actually accelerate.

1313
00:51:53,740 --> 00:51:57,340
To make this useful for you, we need to turn this story into a practical model

1314
00:51:57,340 --> 00:51:58,940
you can apply to your own system.

1315
00:51:58,940 --> 00:52:00,540
Step one, see reality.

1316
00:52:00,540 --> 00:52:02,940
If you want to apply this to your own organization,

1317
00:52:02,940 --> 00:52:04,940
the first step isn't actually redesign.

1318
00:52:04,940 --> 00:52:06,540
It's its reality.

1319
00:52:06,540 --> 00:52:10,540
I start there because most redesign work is doomed before it even begins.

1320
00:52:10,540 --> 00:52:12,940
It fails because it starts from a place of aspiration

1321
00:52:12,940 --> 00:52:14,940
rather than honest observation.

1322
00:52:14,940 --> 00:52:16,940
Leaders will describe the intended process.

1323
00:52:16,940 --> 00:52:18,940
Teams will point to the approved workflow

1324
00:52:18,940 --> 00:52:21,740
and platform owners will show you the configured environment.

1325
00:52:21,740 --> 00:52:24,940
All of those descriptions can be technically true on paper

1326
00:52:24,940 --> 00:52:28,140
while having absolutely nothing to do with how work actually moves.

1327
00:52:28,140 --> 00:52:32,140
The first discipline of a systems thinker is to stop asking what the process should be

1328
00:52:32,140 --> 00:52:34,940
and start asking what the organization is actually running right now.

1329
00:52:34,940 --> 00:52:36,940
That means you have to follow the work itself.

1330
00:52:36,940 --> 00:52:40,940
Don't look at the slide deck, the policy manual, or the architecture diagram.

1331
00:52:40,940 --> 00:52:42,140
Just look at the work.

1332
00:52:42,140 --> 00:52:45,740
Pick one high friction flow that has a visible impact on the business.

1333
00:52:45,740 --> 00:52:50,140
Maybe it's a customer escalation, a budget approval, or a cross-functional change request.

1334
00:52:50,140 --> 00:52:53,340
It needs to be something painful enough that people feel it every day

1335
00:52:53,340 --> 00:52:56,540
and important enough that leadership can't just dismiss it as noise.

1336
00:52:56,540 --> 00:52:58,140
Then you trace it from end to end.

1337
00:52:58,140 --> 00:53:00,140
Where does the work actually begin?

1338
00:53:00,140 --> 00:53:02,140
And who is the first person to touch it?

1339
00:53:02,140 --> 00:53:06,140
You need to see what information arrives with that task and what gets lost along the way.

1340
00:53:06,140 --> 00:53:10,140
Find out where the work pauses and where someone has to rebuild the context

1341
00:53:10,140 --> 00:53:12,140
from their own memory or a private chat thread.

1342
00:53:12,140 --> 00:53:14,940
You are looking for the exact spot where the formal route ends

1343
00:53:14,940 --> 00:53:16,940
and the unofficial shadow route begins.

1344
00:53:16,940 --> 00:53:18,940
This level of observation is mandatory

1345
00:53:18,940 --> 00:53:23,340
because system truth lives in the gap between the documented path and the lived path.

1346
00:53:23,340 --> 00:53:24,940
And here is a critical rule.

1347
00:53:24,940 --> 00:53:26,540
Do this without an ounce of blame.

1348
00:53:26,540 --> 00:53:30,140
If you find people relying on side channels, messy spreadsheets,

1349
00:53:30,140 --> 00:53:33,340
or undocumented workarounds, do not treat that as a personal failure,

1350
00:53:33,340 --> 00:53:34,540
treat it as evidence.

1351
00:53:34,540 --> 00:53:39,340
Those workarounds are telling you that the formal system wasn't strong enough to carry the work to the finished line.

1352
00:53:39,340 --> 00:53:40,540
The workaround isn't the problem.

1353
00:53:40,540 --> 00:53:43,340
It's a signal and a predictable system outcome.

1354
00:53:43,340 --> 00:53:45,740
As you look, a few things will become visible very quickly.

1355
00:53:45,740 --> 00:53:48,140
You'll see the real decision paths, not who's on the chart,

1356
00:53:48,140 --> 00:53:50,140
but who the work is actually waiting for.

1357
00:53:50,140 --> 00:53:52,140
You'll see the real collaboration routes,

1358
00:53:52,140 --> 00:53:54,540
which usually happen wherever the time pressure is highest.

1359
00:53:54,540 --> 00:53:58,940
You'll discover the real data dependencies by seeing which numbers people actually trust

1360
00:53:58,940 --> 00:54:00,140
enough to put their names on.

1361
00:54:00,140 --> 00:54:02,540
This is also where you see how exceptions are handled.

1362
00:54:02,540 --> 00:54:05,740
Most flows look fine until something unusual happens,

1363
00:54:05,740 --> 00:54:08,940
like missing information or conflicting sense of ownership.

1364
00:54:08,940 --> 00:54:12,140
That is where the real design of your company reveals itself.

1365
00:54:12,140 --> 00:54:14,540
I would map this out in the planist terms possible.

1366
00:54:14,540 --> 00:54:17,740
Ask yourself where the item stopped and why it had to stop.

1367
00:54:17,740 --> 00:54:20,940
Identify who had to get involved, who wasn't part of the formal plan.

1368
00:54:20,940 --> 00:54:23,740
Figure out which system held the context and which one dropped it.

1369
00:54:23,740 --> 00:54:28,540
Most importantly, look for where people switched from following a process to relying on personal trust.

1370
00:54:28,540 --> 00:54:32,940
When a flow depends on specific people to translate or manually reconnect the pieces,

1371
00:54:32,940 --> 00:54:35,340
you aren't looking at a stable operating model.

1372
00:54:35,340 --> 00:54:38,940
You are looking at human compensation for a broken architecture.

1373
00:54:38,940 --> 00:54:43,740
This is why observation is a thousand times more valuable than broad documentation at this stage.

1374
00:54:43,740 --> 00:54:46,940
You aren't trying to create a massive inventory of every process in the company.

1375
00:54:46,940 --> 00:54:50,140
You are trying to establish enough operational truth to say,

1376
00:54:50,140 --> 00:54:52,940
"This is how work really moves, this is where the friction lives,

1377
00:54:52,940 --> 00:54:55,340
and this is where our design and our reality diverge."

1378
00:54:55,340 --> 00:54:58,140
Once you can see that, the entire conversation changes.

1379
00:54:58,140 --> 00:55:00,140
You stop arguing about adoption in the abstract

1380
00:55:00,140 --> 00:55:03,340
and you stop assuming that another software rollout will fix the underlying rod.

1381
00:55:03,340 --> 00:55:08,540
You stop coaching people to perform better inside a structure that was literally designed to make them fail.

1382
00:55:08,540 --> 00:55:10,140
Now you have a visible pattern.

1383
00:55:10,140 --> 00:55:13,340
Friction stops being emotional language and starts being structural evidence.

1384
00:55:13,340 --> 00:55:16,540
That is the move you have to make, because if you cannot see the real path,

1385
00:55:16,540 --> 00:55:18,540
you cannot redesign the real system.

1386
00:55:18,540 --> 00:55:20,540
You will only ever optimize the official story

1387
00:55:20,540 --> 00:55:23,740
and official stories are usually where performance goes to hide.

1388
00:55:23,740 --> 00:55:25,740
Step 2, identify friction.

1389
00:55:25,740 --> 00:55:28,140
Once you've made the reality of your workflow visible,

1390
00:55:28,140 --> 00:55:30,140
the next step is to identify friction.

1391
00:55:30,140 --> 00:55:32,140
But we have to do this the right way.

1392
00:55:32,140 --> 00:55:35,740
I'm not talking about friction as a general mood or a vague complaint

1393
00:55:35,740 --> 00:55:37,740
that people are tired and overwhelmed.

1394
00:55:37,740 --> 00:55:41,740
While those feelings are usually true, they are symptoms of a deeper structural issue

1395
00:55:41,740 --> 00:55:43,340
rather than the root cause itself.

1396
00:55:43,340 --> 00:55:47,340
From a system's design perspective, friction is much more precise than a bad vibe.

1397
00:55:47,340 --> 00:55:50,540
It is the measurable resistance inside a flow that slows down movement,

1398
00:55:50,540 --> 00:55:52,940
increases the effort required for simple tasks

1399
00:55:52,940 --> 00:55:56,540
and forces people to manually compensate just to keep the wheels turning.

1400
00:55:56,540 --> 00:56:00,140
This level of precision matters because if you mislabel every problem

1401
00:56:00,140 --> 00:56:02,540
as resistance to change or skill gaps,

1402
00:56:02,540 --> 00:56:06,540
you end up coaching your people to work around fundamental design flaws.

1403
00:56:06,540 --> 00:56:09,340
That is one of the most expensive mistakes I see leaders make

1404
00:56:09,340 --> 00:56:12,140
and it's a massive drain on organizational energy.

1405
00:56:12,140 --> 00:56:16,140
So what does this friction actually look like when you're standing inside an organization?

1406
00:56:16,140 --> 00:56:19,740
It usually shows up in a few repeatable patterns that are easy to spot

1407
00:56:19,740 --> 00:56:20,940
once you know what to look for.

1408
00:56:20,940 --> 00:56:24,940
You'll see delays where works it's untouched, duplicate efforts across different teams

1409
00:56:24,940 --> 00:56:27,340
and constant waiting states that kill momentum.

1410
00:56:27,340 --> 00:56:30,140
You might notice people constantly reconstructing context

1411
00:56:30,140 --> 00:56:31,740
or performing repeated validations

1412
00:56:31,740 --> 00:56:33,740
because nobody trusts the data they were handed.

1413
00:56:33,740 --> 00:56:35,740
These are the footprints of a broken system.

1414
00:56:35,740 --> 00:56:38,940
A request enters the queue and then waits two days before anyone even looks at it

1415
00:56:38,940 --> 00:56:41,740
or a report gets rebuilt three times by three different teams.

1416
00:56:41,740 --> 00:56:45,740
Using slightly different definitions, you might see meetings that exist solely

1417
00:56:45,740 --> 00:56:49,740
to restore a shared understanding that should have traveled with the work in the first place.

1418
00:56:49,740 --> 00:56:53,740
Sometimes an extra approval is added simply because one group doesn't trust the

1419
00:56:53,740 --> 00:56:57,740
previous group's judgment and that is a clear signal of structural friction.

1420
00:56:57,740 --> 00:56:59,740
Now I want to be clear, not all friction is bad.

1421
00:56:59,740 --> 00:57:01,740
That distinction is vital for building a resilient system

1422
00:57:01,740 --> 00:57:04,940
because some resistance actually serves a purpose.

1423
00:57:04,940 --> 00:57:08,940
If a decision is hard to reverse or carries a high level of material risk,

1424
00:57:08,940 --> 00:57:12,540
you actually want a bit of resistance there to prevent a single point of failure.

1425
00:57:12,540 --> 00:57:16,940
This is where the concept of "minimum viable" friction becomes a tool for quality.

1426
00:57:16,940 --> 00:57:20,940
A short assumption check or a visible judgment statement can improve the final outcome

1427
00:57:20,940 --> 00:57:22,940
without completely collapsing your momentum.

1428
00:57:22,940 --> 00:57:26,140
But destructive friction is a different animal entirely.

1429
00:57:26,140 --> 00:57:30,540
It adds significant cost to the process without adding any real confidence to the result.

1430
00:57:30,540 --> 00:57:33,740
It slows down routine work, multiplies unnecessary handoffs

1431
00:57:33,740 --> 00:57:37,340
and encourages political safety behaviors where people ask for more meetings

1432
00:57:37,340 --> 00:57:38,540
just to cover their tracks.

1433
00:57:38,540 --> 00:57:42,140
The structure gets weaker, so people compensate by adding more eyes and more layers

1434
00:57:42,140 --> 00:57:44,540
which only makes the system more fragile over time.

1435
00:57:44,540 --> 00:57:48,540
Your job as a leader is to separate the useful friction from the destructive drag.

1436
00:57:48,540 --> 00:57:51,340
The easiest way to do that is to ask one simple question.

1437
00:57:51,340 --> 00:57:53,740
What is this specific step protecting us from?

1438
00:57:53,740 --> 00:57:56,540
If the answer is clear, specific and proportionate to the risk,

1439
00:57:56,540 --> 00:57:59,340
the friction might be doing useful work for the organization.

1440
00:57:59,340 --> 00:58:02,540
But if the answer is vague, historical or purely political,

1441
00:58:02,540 --> 00:58:04,940
then you are looking at pure drag that needs to be removed.

1442
00:58:04,940 --> 00:58:08,140
This is where redesigning your business reality starts to get practical.

1443
00:58:08,140 --> 00:58:10,940
You stop saying this process feels heavy and start saying

1444
00:58:10,940 --> 00:58:13,340
this step duplicates a review we already did.

1445
00:58:13,340 --> 00:58:16,540
You can point to an approval that adds no new judgment or a cue

1446
00:58:16,540 --> 00:58:19,340
that only exists because ownership of the task is unclear.

1447
00:58:19,340 --> 00:58:22,940
That level of specificity changes the entire conversation

1448
00:58:22,940 --> 00:58:26,140
from a complaint into a technical problem we can actually solve.

1449
00:58:26,140 --> 00:58:28,940
It also gives you concrete signals that you can measure over time.

1450
00:58:28,940 --> 00:58:30,140
Cycle time is a big one.

1451
00:58:30,140 --> 00:58:32,540
Not how long the formal manual says a task should take

1452
00:58:32,540 --> 00:58:35,340
but how long it actually takes from entry to action in the real world.

1453
00:58:35,340 --> 00:58:38,940
You should also watch for overwrite frequency, which is how often

1454
00:58:38,940 --> 00:58:41,740
the formal process gets bypassed because someone with enough

1455
00:58:41,740 --> 00:58:43,340
influence forces are faster route.

1456
00:58:43,340 --> 00:58:45,740
If the official design is constantly being ignored,

1457
00:58:45,740 --> 00:58:47,740
it's a sign the system isn't trusted.

1458
00:58:47,740 --> 00:58:51,340
Support load and exception volume are also critical indicators of friction.

1459
00:58:51,340 --> 00:58:54,140
If people are repeatedly asking for manual intervention

1460
00:58:54,140 --> 00:58:56,540
or if the work constantly falls off the standard path,

1461
00:58:56,540 --> 00:58:59,340
you don't have a people issue, you have a flow issue.

1462
00:58:59,340 --> 00:59:01,340
The process isn't stable enough to automate

1463
00:59:01,340 --> 00:59:03,340
because it relies on human rescue to function.

1464
00:59:03,340 --> 00:59:06,540
When you see a handful of overpowered admins or one manager

1465
00:59:06,540 --> 00:59:10,540
who has to bless every move, you found a bottleneck disguised as control.

1466
00:59:10,540 --> 00:59:12,540
Friction isn't some abstract concept.

1467
00:59:12,540 --> 00:59:15,740
It leaves a physical footprint in your rework, your escalations,

1468
00:59:15,740 --> 00:59:20,140
and the volume of compensating behavior your team needs just to survive the week.

1469
00:59:20,140 --> 00:59:22,140
Once you can see that footprint clearly,

1470
00:59:22,140 --> 00:59:23,740
the pain stops being a mystery.

1471
00:59:23,740 --> 00:59:26,940
You can finally stop trying to motivate people to survive a broken system

1472
00:59:26,940 --> 00:59:30,140
and start redesigning the flow, so the system actually works for them.

1473
00:59:30,140 --> 00:59:34,140
Step 3 - redesign flows.

1474
00:59:34,140 --> 00:59:37,740
Once you've identified where the friction lives, your next move is redesign.

1475
00:59:37,740 --> 00:59:39,340
I want to be very specific here.

1476
00:59:39,340 --> 00:59:42,140
I'm talking about redesign, not optimization.

1477
00:59:42,140 --> 00:59:44,940
Optimization assumes the current path is basically correct

1478
00:59:44,940 --> 00:59:46,940
and just needs to run a little bit faster,

1479
00:59:46,940 --> 00:59:50,940
but redesign asks if this is even the right path to achieve the outcome we want.

1480
00:59:50,940 --> 00:59:53,740
Many organizations avoid this question

1481
00:59:53,740 --> 00:59:56,140
because it feels disruptive to the status quo.

1482
00:59:56,140 --> 00:59:58,140
They would much rather tune a few handoffs,

1483
00:59:58,140 --> 01:00:00,940
add a fancy new automation, or tighten an approval process,

1484
01:00:00,940 --> 01:00:02,940
then rethink the entire structure.

1485
01:00:02,940 --> 01:00:06,140
But if your flow is carrying too many transfers and too much ambiguity,

1486
01:00:06,140 --> 01:00:09,740
then all you're doing is making a weak root slightly more efficient.

1487
01:00:09,740 --> 01:00:12,940
From a system's perspective, that isn't an improvement.

1488
01:00:12,940 --> 01:00:16,140
It's just structural compensation with better branding.

1489
01:00:16,140 --> 01:00:18,540
Redesign starts by aggressively simplifying the root.

1490
01:00:18,540 --> 01:00:20,940
You want fewer handoffs, fewer decision points,

1491
01:00:20,940 --> 01:00:23,740
and fewer places where the context of the work can fall apart.

1492
01:00:23,740 --> 01:00:26,740
Every time work changes hands, you aren't just transferring a task.

1493
01:00:26,740 --> 01:00:29,540
You are transferring meaning, responsibility, and timing.

1494
01:00:29,540 --> 01:00:31,940
If those three things don't move together perfectly,

1495
01:00:31,940 --> 01:00:34,340
the next person in line inherits confusion.

1496
01:00:34,340 --> 01:00:38,340
And they slow down because the architecture handed them on certainty instead of clarity.

1497
01:00:38,340 --> 01:00:41,340
That's why your first redesign question should always be about the minimum.

1498
01:00:41,340 --> 01:00:44,940
Ask yourself, what is the minimum number of transitions required for this work

1499
01:00:44,940 --> 01:00:46,540
to reach a reliable outcome?

1500
01:00:46,540 --> 01:00:50,140
Don't worry about the maximum number of stakeholders who might want visibility.

1501
01:00:50,140 --> 01:00:52,140
Focus on the leanest path to the result.

1502
01:00:52,140 --> 01:00:55,540
That shift in perspective changes everything about how you build your infrastructure.

1503
01:00:55,540 --> 01:00:59,340
The next principle is to place context as close to the action as possible.

1504
01:00:59,340 --> 01:01:02,140
If a decision maker has to hunt through Slack, old emails,

1505
01:01:02,140 --> 01:01:04,340
and various dashboards just to understand a request,

1506
01:01:04,340 --> 01:01:06,340
your flow is badly designed.

1507
01:01:06,340 --> 01:01:08,740
Context should arrive with the work.

1508
01:01:08,740 --> 01:01:12,940
The history, the assumptions, and the rationale should all be right there.

1509
01:01:12,940 --> 01:01:16,940
This reduces the coordination tax that drains so much productivity in modern business environments.

1510
01:01:16,940 --> 01:01:20,740
You also have to stop designing only for the happy path where everything goes perfectly.

1511
01:01:20,740 --> 01:01:24,940
Most process efforts fail because they build elegant models for ideal conditions

1512
01:01:24,940 --> 01:01:26,940
and then break the moment reality hits.

1513
01:01:26,940 --> 01:01:28,740
Real work is messy and full of exceptions,

1514
01:01:28,740 --> 01:01:31,340
so if your redesign cannot absorb variation,

1515
01:01:31,340 --> 01:01:34,340
it's just a pretty diagram, not a functional system.

1516
01:01:34,340 --> 01:01:39,540
Exceptional handling, knowing exactly where a case goes when data is missing or rules conflict

1517
01:01:39,540 --> 01:01:42,140
must be part of the architecture from day one.

1518
01:01:42,140 --> 01:01:46,340
In my experience, a good redesign should actually create fewer pathways rather than more.

1519
01:01:46,340 --> 01:01:48,540
When organizations face complexity,

1520
01:01:48,540 --> 01:01:53,140
they often react by layering on more local workarounds and special branches for every edge case.

1521
01:01:53,140 --> 01:01:57,140
Very quickly the system becomes unreadable and unreadable systems are impossible to scale

1522
01:01:57,140 --> 01:01:59,740
because nobody knows which path is real under pressure.

1523
01:01:59,740 --> 01:02:02,740
The better move is to create one clear primary path

1524
01:02:02,740 --> 01:02:06,340
and a small number of explicit exception routes that everyone can see.

1525
01:02:06,340 --> 01:02:10,140
Finally, you must design for redundancy where it actually matters for the business.

1526
01:02:10,140 --> 01:02:12,340
If only one person can unblock a critical flow,

1527
01:02:12,340 --> 01:02:14,940
or only one team understands how a specific route works,

1528
01:02:14,940 --> 01:02:16,540
you've built a single point of failure.

1529
01:02:16,540 --> 01:02:18,940
Redesign is about removing that concentration of risk

1530
01:02:18,940 --> 01:02:20,940
so that your performance isn't just about speed,

1531
01:02:20,940 --> 01:02:23,140
but about speed that survives under pressure.

1532
01:02:23,140 --> 01:02:26,940
The goal of this entire step isn't to make the work look elegant on a slide deck.

1533
01:02:26,940 --> 01:02:30,540
It's to make the movement of work clearer, thinner and more reliable

1534
01:02:30,540 --> 01:02:33,340
under the real world conditions your team faces every day.

1535
01:02:33,340 --> 01:02:37,740
When you achieve that, people stop spending all their energy navigating the route

1536
01:02:37,740 --> 01:02:40,540
and start using that energy to actually drive the outcome.

1537
01:02:40,540 --> 01:02:46,540
But remember, even the best redesign flow will collapse if the power and access still sit in the wrong places.

1538
01:02:46,540 --> 01:02:49,140
Step 4. Align access and ownership.

1539
01:02:49,140 --> 01:02:52,540
We've reached the point where most redesign efforts quietly fall apart

1540
01:02:52,540 --> 01:02:55,740
even when the workflow itself looks cleaner on paper.

1541
01:02:55,740 --> 01:02:58,740
The reason is simple. Access and ownership remain misaligned.

1542
01:02:58,740 --> 01:03:01,540
If you don't fix that structural gap, your new design won't last

1543
01:03:01,540 --> 01:03:04,740
because while flow is about movement, authority is about power.

1544
01:03:04,740 --> 01:03:08,940
You can simplify a route, cut out handoffs and bring context closer to the action,

1545
01:03:08,940 --> 01:03:13,140
but if the people responsible for the outcome can't actually act inside the system,

1546
01:03:13,140 --> 01:03:16,540
the organization will slide right back into its old broken habits.

1547
01:03:16,540 --> 01:03:21,940
The result is a system defined by waiting, escalating and creating manual workarounds.

1548
01:03:21,940 --> 01:03:26,340
People end up asking for permission from managers who don't carry any of the actual consequences,

1549
01:03:26,340 --> 01:03:30,940
which is why matching permissions to accountability is the most critical part of this step.

1550
01:03:30,940 --> 01:03:33,740
You have to align them directly rather than loosely.

1551
01:03:33,740 --> 01:03:38,140
Access isn't just a technical checkbox for the IT department, it is operational power.

1552
01:03:38,140 --> 01:03:41,940
When we look at a system, we have to ask who can create the record,

1553
01:03:41,940 --> 01:03:45,140
who can change the status and who has the right to approve an exception.

1554
01:03:45,140 --> 01:03:48,540
These aren't just administrative settings, they are fundamental design choices

1555
01:03:48,540 --> 01:03:50,540
that dictate how work actually happens.

1556
01:03:50,540 --> 01:03:55,540
If the person who is supposedly accountable for a result cannot move the work forward,

1557
01:03:55,540 --> 01:03:57,140
their ownership is fake.

1558
01:03:57,140 --> 01:04:01,140
Conversely, if someone can intervene in a process without carrying the risk of the outcome,

1559
01:04:01,140 --> 01:04:02,740
your control model is distorted.

1560
01:04:02,740 --> 01:04:05,140
The goal here isn't to give more people more access,

1561
01:04:05,140 --> 01:04:07,540
because that's usually how fragmentation starts to scale.

1562
01:04:07,540 --> 01:04:11,140
Instead, you want to create a sharp, clean relationship between a person's role

1563
01:04:11,140 --> 01:04:12,740
and their ability to take action.

1564
01:04:12,740 --> 01:04:16,540
I like to break this down into four distinct categories, who decides, who advises,

1565
01:04:16,540 --> 01:04:17,940
who executes and who audits.

1566
01:04:17,940 --> 01:04:21,340
These four functions should never blow into each other by accident.

1567
01:04:21,340 --> 01:04:25,140
And while they need to interact, they shouldn't collapse into a muddy permission set

1568
01:04:25,140 --> 01:04:28,340
where everyone participates, but nobody truly owns the result.

1569
01:04:28,340 --> 01:04:32,940
In my experience, Microsoft 365 and Power Platform environments are incredibly revealing

1570
01:04:32,940 --> 01:04:36,740
because the platform mirrors organizational ambiguity with painful honesty.

1571
01:04:36,740 --> 01:04:39,740
If your ownership structure is vague, your permissions will be vague,

1572
01:04:39,740 --> 01:04:41,740
and if power is driven by politics.

1573
01:04:41,740 --> 01:04:43,340
Access becomes a political tool.

1574
01:04:43,340 --> 01:04:46,140
When leadership avoids making hard calls about authority,

1575
01:04:46,140 --> 01:04:51,340
the digital environment fills up with shared mailboxes, broad member rights, and unofficial automation.

1576
01:04:51,340 --> 01:04:54,140
From the outside, this might look like a collaborative culture,

1577
01:04:54,140 --> 01:04:58,540
but from a system perspective, it's just unresolved ownership expressed through software.

1578
01:04:58,540 --> 01:05:04,140
To fix this, you have to ask some uncomfortable questions about who is truly accountable for business outcomes.

1579
01:05:04,140 --> 01:05:08,340
You need to find out if those roles have the system access they need to do their jobs,

1580
01:05:08,340 --> 01:05:12,140
or if people are holding access without any corresponding responsibility.

1581
01:05:12,140 --> 01:05:16,740
Often you'll find that approvals are being done out of habit rather than necessity,

1582
01:05:16,740 --> 01:05:21,740
or that employees are building workarounds because the right action is blocked by a legacy permission model.

1583
01:05:21,740 --> 01:05:24,940
There is one more question that matters more than most teams realize

1584
01:05:24,940 --> 01:05:28,140
where has the organization confused visibility with control?

1585
01:05:28,140 --> 01:05:32,340
These are not the same thing and failing to distinguish between them slows everything down.

1586
01:05:32,340 --> 01:05:35,540
A leader might need to see a flow without being the one who approves it,

1587
01:05:35,540 --> 01:05:40,340
just as a governance team, might need to audit a process without being part of the daily handoff.

1588
01:05:40,340 --> 01:05:45,740
When these lines are blurred, you end up with too many editors and too many people copied on emails for safety,

1589
01:05:45,740 --> 01:05:47,740
which isn't resilience, it's just diffusion.

1590
01:05:47,740 --> 01:05:50,140
Diffusion is the fastest way to kill accountability,

1591
01:05:50,140 --> 01:05:52,740
so the best move in a redesign is usually subtraction.

1592
01:05:52,740 --> 01:05:55,740
You want to remove those zones of ambiguous ownership

1593
01:05:55,740 --> 01:06:00,140
and cut out the unnecessary layers of approval that don't add value.

1594
01:06:00,140 --> 01:06:03,740
Give the accountable roles the rights they need to act limit override permissions

1595
01:06:03,740 --> 01:06:07,740
where they are actually justified and make your escalation paths explicit.

1596
01:06:07,740 --> 01:06:10,340
When you document responsibility in the language of action,

1597
01:06:10,340 --> 01:06:13,340
asking who can trigger a flow or who can be audited afterward,

1598
01:06:13,340 --> 01:06:15,740
you rebuild trust across the entire organization.

1599
01:06:15,740 --> 01:06:18,140
Once authority finally sits where the consequence sits,

1600
01:06:18,140 --> 01:06:21,140
the platform stops feeling like a confusing maze of permissions.

1601
01:06:21,140 --> 01:06:23,740
It starts behaving like a coherent operating model,

1602
01:06:23,740 --> 01:06:26,340
which is the real shift required for a system to scale.

1603
01:06:26,340 --> 01:06:28,940
Only after you've achieved this structural clarity,

1604
01:06:28,940 --> 01:06:33,540
does automation become a true force multiplier instead of just amplifying the existing chaos?

1605
01:06:33,540 --> 01:06:38,940
Step 5. Layar AI and automation last.

1606
01:06:38,940 --> 01:06:42,140
Now we finally get to the part that everyone wants to lead with AI,

1607
01:06:42,140 --> 01:06:44,340
co-pilots and the promise of total automation.

1608
01:06:44,340 --> 01:06:47,740
It's tempting to start here because these tools offer incredible speed,

1609
01:06:47,740 --> 01:06:50,940
but they should always be the final layer of your architecture.

1610
01:06:50,940 --> 01:06:54,340
AI is not a repair tool that fixes broken processes.

1611
01:06:54,340 --> 01:06:58,340
It is an acceleration layer that makes whatever you already have move faster.

1612
01:06:58,340 --> 01:07:00,140
If your decision paths are a mess,

1613
01:07:00,140 --> 01:07:03,940
AI will simply help you make bad decisions at a higher velocity.

1614
01:07:03,940 --> 01:07:07,540
If your data is fragmented and your permissions are politically distorted,

1615
01:07:07,540 --> 01:07:10,940
automation will scale that distortion across your entire enterprise.

1616
01:07:10,940 --> 01:07:14,940
When you ask an agent to operate in an environment where exception handling is vague,

1617
01:07:14,940 --> 01:07:18,340
that agent will hit a wall of uncertainty and fail more often.

1618
01:07:18,340 --> 01:07:20,140
The system isn't broken in that scenario,

1619
01:07:20,140 --> 01:07:21,940
it's doing exactly what it was designed to do,

1620
01:07:21,940 --> 01:07:23,540
but it's being pushed to a speed,

1621
01:07:23,540 --> 01:07:26,140
the underlying organization can't actually support.

1622
01:07:26,140 --> 01:07:29,540
Most AI disappointments don't happen because the technology is bad.

1623
01:07:29,540 --> 01:07:34,340
They happen because the organization tried to use AI to pay off design debt.

1624
01:07:34,340 --> 01:07:37,340
That debt doesn't just go away when you add intelligence,

1625
01:07:37,340 --> 01:07:40,340
it actually compounds and becomes more expensive to manage.

1626
01:07:40,340 --> 01:07:42,340
When I say you should layer AI last,

1627
01:07:42,340 --> 01:07:44,140
I'm talking about the sequence of the work.

1628
01:07:44,140 --> 01:07:46,740
You have to make the flow legible and the ownership clear

1629
01:07:46,740 --> 01:07:48,740
before you ever touch an automation tool.

1630
01:07:48,740 --> 01:07:52,340
Once you've stabilized the data path and defined where human judgment still matters,

1631
01:07:52,340 --> 01:07:55,940
you can finally decide what should be automated and what should be augmented.

1632
01:07:55,940 --> 01:07:57,340
This is a vital distinction

1633
01:07:57,340 --> 01:08:00,340
because stable repeatable tasks are great for automation,

1634
01:08:00,340 --> 01:08:04,140
while high variability work with real consequences is better for augmentation.

1635
01:08:04,140 --> 01:08:05,340
If you ignore this difference,

1636
01:08:05,340 --> 01:08:07,540
you'll either automate something unstable

1637
01:08:07,540 --> 01:08:09,740
and create a nightmare of manual exceptions

1638
01:08:09,740 --> 01:08:13,140
or you'll waste human talent on work the system could have handled alone.

1639
01:08:13,140 --> 01:08:14,740
In a well-sequenced system,

1640
01:08:14,740 --> 01:08:16,340
you know exactly where the work starts,

1641
01:08:16,340 --> 01:08:19,340
who owns the next move and which data source holds the truth.

1642
01:08:19,340 --> 01:08:21,540
You understand which cases can flow straight through

1643
01:08:21,540 --> 01:08:24,740
and which ones require a human to pause and review the edge cases.

1644
01:08:24,740 --> 01:08:28,340
This creates a structural boundary where AI has a safe place to land

1645
01:08:28,340 --> 01:08:30,740
and human in the loop stops being a feel-good phrase

1646
01:08:30,740 --> 01:08:32,740
and starts being a strategic decision.

1647
01:08:32,740 --> 01:08:36,140
Human judgment stays where risk and values require interpretation

1648
01:08:36,140 --> 01:08:39,540
while the machine handles the patent recognition and repetitive execution.

1649
01:08:39,540 --> 01:08:42,540
The real question for leaders isn't about how fast they can adopt AI

1650
01:08:42,540 --> 01:08:46,740
but rather what kind of organization they are asking that AI to accelerate.

1651
01:08:46,740 --> 01:08:49,740
AI cannot create clarity where none exists.

1652
01:08:49,740 --> 01:08:52,540
It only reveals the quality of your existing architecture.

1653
01:08:52,540 --> 01:08:55,740
I've seen companies roll out co-pilot into messy environments

1654
01:08:55,740 --> 01:08:57,940
where truth was contested and rights were unclear

1655
01:08:57,940 --> 01:08:59,940
and while individuals got slightly faster,

1656
01:08:59,940 --> 01:09:02,340
the organization as a whole didn't get any smarter.

1657
01:09:02,340 --> 01:09:03,940
That isn't a digital transformation,

1658
01:09:03,940 --> 01:09:05,540
it's just velocity without alignment.

1659
01:09:05,540 --> 01:09:08,940
The strategic move is always architecture first followed by design,

1660
01:09:08,940 --> 01:09:11,140
then optimization and finally automation.

1661
01:09:11,140 --> 01:09:15,540
When you let AI sit on top as the final multiplier of a coherent operating model,

1662
01:09:15,540 --> 01:09:19,540
it stops being a distraction or a workaround for a broken structure.

1663
01:09:19,540 --> 01:09:22,740
It becomes a force multiplier for clarity and that is the exact moment

1664
01:09:22,740 --> 01:09:25,740
when your technology stops fighting the business and starts reinforcing it.

1665
01:09:25,740 --> 01:09:29,740
What this means for Microsoft 365 co-pilot and power platform.

1666
01:09:29,740 --> 01:09:31,740
So what does all of this actually mean?

1667
01:09:31,740 --> 01:09:36,140
If your daily environment is built on Microsoft 365 co-pilot and the power platform,

1668
01:09:36,140 --> 01:09:39,740
it means you have to stop thinking about these tools as simple productivity products

1669
01:09:39,740 --> 01:09:42,940
because they aren't just software packages you install to check a box.

1670
01:09:42,940 --> 01:09:47,340
They are operating surfaces that expose exactly how work moves through your company,

1671
01:09:47,340 --> 01:09:50,740
where context lives and who actually has the power to act.

1672
01:09:50,740 --> 01:09:54,740
When you look at these platforms, they reveal whether your organization has clean relationships

1673
01:09:54,740 --> 01:09:57,940
between information, responsibility and action,

1674
01:09:57,940 --> 01:09:59,940
or if things are just tangled together.

1675
01:09:59,940 --> 01:10:04,940
This is exactly why Microsoft 365 maturity can be so misleading for leadership teams.

1676
01:10:04,940 --> 01:10:08,140
An organization can have teams, sharepoint, power automate,

1677
01:10:08,140 --> 01:10:11,940
and co-pilot running with strong security controls and active governance

1678
01:10:11,940 --> 01:10:14,140
yet still remains structurally slow.

1679
01:10:14,140 --> 01:10:19,140
None of those technical milestones guarantee coherence because they only prove that capability is available

1680
01:10:19,140 --> 01:10:22,140
which is never the same thing as having a high quality operating model.

1681
01:10:22,140 --> 01:10:25,940
If you are leading in this space, the question isn't whether you've deployed the platform well

1682
01:10:25,940 --> 01:10:29,740
but rather what kind of organizational logic that platform is currently reinforcing.

1683
01:10:29,740 --> 01:10:33,140
Let's look at Microsoft 365 more broadly as an operating substrate

1684
01:10:33,140 --> 01:10:34,940
where your business reality lives.

1685
01:10:34,940 --> 01:10:39,140
It is the place where communication happens, files move and decisions are discussed,

1686
01:10:39,140 --> 01:10:42,940
and the permissions within it shape who has access to vital context.

1687
01:10:42,940 --> 01:10:46,940
When M365 feels noisy, fragmented or politically heavy,

1688
01:10:46,940 --> 01:10:51,940
that usually isn't a tool problem but an organizational design problem showing up through the software.

1689
01:10:51,940 --> 01:10:54,740
Too many teams channels often reflect unclear boundaries,

1690
01:10:54,740 --> 01:10:58,740
while too many chats carrying key decisions show that your interaction design is weak.

1691
01:10:58,740 --> 01:11:01,540
The platform isn't causing this behavior out of nowhere.

1692
01:11:01,540 --> 01:11:05,140
It is simply making the underlying business reality visible to everyone.

1693
01:11:05,140 --> 01:11:08,540
Now map that same logic to co-pilot which only becomes truly valuable

1694
01:11:08,540 --> 01:11:14,940
when your context and truth sources are aligned enough for AI assistance to land inside a coherent flow.

1695
01:11:14,940 --> 01:11:16,740
If the underlying environment is clean,

1696
01:11:16,740 --> 01:11:20,340
co-pilot can reduce search time and help people recover their state quickly

1697
01:11:20,340 --> 01:11:22,540
which is incredibly useful for daily operations.

1698
01:11:22,540 --> 01:11:27,740
But if your source landscape is contradictory and your collaboration patterns vary rationale in private channels,

1699
01:11:27,740 --> 01:11:32,340
co-pilot will still generate output, it just won't reliably generate organizational clarity.

1700
01:11:32,340 --> 01:11:35,940
That is the trap where leaders see individual productivity gains

1701
01:11:35,940 --> 01:11:40,140
and assume the whole organization is transforming when really people are just producing faster

1702
01:11:40,140 --> 01:11:42,140
inside a fragmented architecture.

1703
01:11:42,140 --> 01:11:45,740
Success with co-pilot isn't mainly a question of how well you can write a prompt

1704
01:11:45,740 --> 01:11:47,740
but a question of how you design your information.

1705
01:11:47,740 --> 01:11:50,940
You have to ask if the tool can access the right context

1706
01:11:50,940 --> 01:11:55,940
and if the human receiving the output can actually act inside clear decision boundaries.

1707
01:11:55,940 --> 01:11:59,140
If those structural pieces are missing, the value stays local

1708
01:11:59,140 --> 01:12:01,340
and never scales to the rest of the business.

1709
01:12:01,340 --> 01:12:02,940
This brings us to Power Automate

1710
01:12:02,940 --> 01:12:07,340
which is where fragmentation gets dangerous because the tool scales so beautifully.

1711
01:12:07,340 --> 01:12:10,140
While it can scale efficiency, it can also scale brittleness

1712
01:12:10,140 --> 01:12:14,340
if the process underneath is unstable or dependent on invisible human judgment.

1713
01:12:14,340 --> 01:12:16,540
When an unstable workflow gets automated,

1714
01:12:16,540 --> 01:12:18,940
the manual effort doesn't actually disappear.

1715
01:12:18,940 --> 01:12:22,940
It just moves into exception handling admin intervention and support tickets.

1716
01:12:22,940 --> 01:12:25,740
The flow might run technically while failing operationally,

1717
01:12:25,740 --> 01:12:29,940
creating a false sense of maturity that eventually erodes trust across the team.

1718
01:12:29,940 --> 01:12:35,340
Power Platform governance matters here too, but only if it supports the flow of work instead of just slowing it down.

1719
01:12:35,340 --> 01:12:39,340
Good governance should clarify ownership and make approved pathways easier to follow

1720
01:12:39,340 --> 01:12:40,740
than shadow IT solutions.

1721
01:12:40,740 --> 01:12:43,740
If your governance adds delay without adding any clarity,

1722
01:12:43,740 --> 01:12:46,740
it isn't strengthening the platform, it's just increasing latency.

1723
01:12:46,740 --> 01:12:48,740
The executive implication is straightforward.

1724
01:12:48,740 --> 01:12:54,340
Stop buying isolated gains and stop treating M365 as a bundle of apps or co-pilot as a miracle layer.

1725
01:12:54,340 --> 01:12:57,140
You need to start designing a platform supported operating model

1726
01:12:57,140 --> 01:13:00,540
where decision flow is clear and access reflects real accountability.

1727
01:13:00,540 --> 01:13:02,940
Then the Microsoft stack becomes powerful,

1728
01:13:02,940 --> 01:13:07,540
not because the tools got smarter, but because the organization became coherent enough to use them.

1729
01:13:07,540 --> 01:13:09,740
The metrics of a designed organization.

1730
01:13:09,740 --> 01:13:12,140
If we are serious about designing organizations,

1731
01:13:12,140 --> 01:13:14,940
then we also need to get serious about what we actually measure.

1732
01:13:14,940 --> 01:13:19,540
This is where most leadership teams drift back into old habits by talking about transformation

1733
01:13:19,540 --> 01:13:22,740
while only measuring license adoption or meeting counts.

1734
01:13:22,740 --> 01:13:24,940
Those things are signals, but they aren't proof

1735
01:13:24,940 --> 01:13:28,340
that the organization is becoming structurally better or more resilient.

1736
01:13:28,340 --> 01:13:32,140
You need metrics that describe how the organization behaves as a system

1737
01:13:32,140 --> 01:13:34,740
rather than just reporting that activity happened.

1738
01:13:34,740 --> 01:13:37,540
The first category you should focus on is decision flow,

1739
01:13:37,540 --> 01:13:39,540
specifically looking at decision latency.

1740
01:13:39,540 --> 01:13:42,140
You want to measure how much time passes between a signal,

1741
01:13:42,140 --> 01:13:44,140
the judgment, the commitment and the final action.

1742
01:13:44,140 --> 01:13:47,140
It's not about when the request was logged or when the deck was presented

1743
01:13:47,140 --> 01:13:49,140
but when the organization actually moved.

1744
01:13:49,140 --> 01:13:52,940
You should also track escalation frequency to see how often work gets pushed upward

1745
01:13:52,940 --> 01:13:55,340
because local authority or confidence is missing.

1746
01:13:55,340 --> 01:13:57,140
If your escalations are high,

1747
01:13:57,140 --> 01:13:59,540
it's a sign the system doesn't trust its own design

1748
01:13:59,540 --> 01:14:04,340
and your reversible decisions are likely facing the same friction as irreversible ones.

1749
01:14:04,340 --> 01:14:06,140
The second category is data trust

1750
01:14:06,140 --> 01:14:09,740
because if people don't trust the data path, they will manually rebuild the truth

1751
01:14:09,740 --> 01:14:11,140
every time the pressure rises.

1752
01:14:11,140 --> 01:14:13,940
You can measure this by looking at duplicate source creation

1753
01:14:13,940 --> 01:14:18,540
where teams create local versions of key data just to feel safe enough to act.

1754
01:14:18,540 --> 01:14:20,340
Look at the reconciliation effort as well,

1755
01:14:20,340 --> 01:14:22,740
calculating how much human time is spent,

1756
01:14:22,740 --> 01:14:25,540
comparing reports and resolving definition disputes.

1757
01:14:25,540 --> 01:14:28,540
If teams can't trace where a metric came from or who owns it,

1758
01:14:28,540 --> 01:14:32,340
then your trust is weak even if your dashboards look polished and professional.

1759
01:14:32,340 --> 01:14:34,540
Next we have to look at interaction quality

1760
01:14:34,540 --> 01:14:37,540
and I mean quality in a structural sense rather than an emotional one.

1761
01:14:37,540 --> 01:14:40,340
Track how many handoffs require a full re-explanation

1762
01:14:40,340 --> 01:14:44,540
and how much response lag appears when work crosses a departmental boundary.

1763
01:14:44,540 --> 01:14:47,540
A great signal here is documentation reuse.

1764
01:14:47,540 --> 01:14:51,540
If people keep asking questions that should be answerable from the recorded path,

1765
01:14:51,540 --> 01:14:53,340
your interaction model is leaking meaning.

1766
01:14:53,340 --> 01:14:57,340
When meetings exist mainly to restore missing context that should have been there already,

1767
01:14:57,340 --> 01:14:59,340
your system is failing to sustain itself.

1768
01:14:59,340 --> 01:15:01,340
The fourth category is power alignment,

1769
01:15:01,340 --> 01:15:03,340
which is the one most organizations avoid

1770
01:15:03,340 --> 01:15:05,940
because it gets politically uncomfortable very quickly.

1771
01:15:05,940 --> 01:15:09,340
You need to track approval concentration to see how many critical flows

1772
01:15:09,340 --> 01:15:11,540
depend on a very small number of people

1773
01:15:11,540 --> 01:15:13,940
which reveals your single points of failure.

1774
01:15:13,940 --> 01:15:15,340
Watch for override patterns

1775
01:15:15,340 --> 01:15:18,740
where the formal process gets bypassed by influence or urgency

1776
01:15:18,740 --> 01:15:22,340
because if overrides are common, your official model isn't the real one.

1777
01:15:22,340 --> 01:15:26,740
You also need to spot access mismatches where people hold permissions without responsibility

1778
01:15:26,740 --> 01:15:30,540
or where accountable roles lack the access they need to actually do their jobs.

1779
01:15:30,540 --> 01:15:33,940
These metrics matter because they shift the conversation away from performance,

1780
01:15:33,940 --> 01:15:36,340
theatre and toward structural reality.

1781
01:15:36,340 --> 01:15:38,940
An organization can look digitally mature on paper

1782
01:15:38,940 --> 01:15:40,740
and still have terrible decision latency

1783
01:15:40,740 --> 01:15:43,340
or spend huge amounts of time reconciling the truth.

1784
01:15:43,340 --> 01:15:46,540
The point isn't to look modern, the point is to become structurally capable

1785
01:15:46,540 --> 01:15:50,540
by measuring the things that reveal if flow is cleaner and trust is stronger.

1786
01:15:50,540 --> 01:15:52,540
If I were starting with a simple scorecard,

1787
01:15:52,540 --> 01:15:55,140
I would want to see decision latency, escalation rates

1788
01:15:55,140 --> 01:15:57,740
and reconciliation effort visible every single week.

1789
01:15:57,740 --> 01:16:01,340
These numbers tell you whether the organization is becoming easier to move through

1790
01:16:01,340 --> 01:16:03,140
which is the only test that actually matters.

1791
01:16:03,140 --> 01:16:05,540
It's not about whether the platform is busy

1792
01:16:05,540 --> 01:16:07,540
or if the licenses are assigned

1793
01:16:07,540 --> 01:16:10,340
but whether the business can act with clarity under pressure.

1794
01:16:10,340 --> 01:16:14,140
Mature organizations aren't defined by how much process they have on the books.

1795
01:16:14,140 --> 01:16:19,140
They are defined by how much coordinated movement their design allows when things get difficult.

1796
01:16:19,140 --> 01:16:23,140
If you audited your organizational design the same way you audit your technical systems

1797
01:16:23,140 --> 01:16:27,140
you might find that your current structure is actually designed to slow you down.

1798
01:16:27,140 --> 01:16:29,740
The counterintuitive truth about high performance.

1799
01:16:29,740 --> 01:16:32,340
So here's the counterintuitive part of the whole equation.

1800
01:16:32,340 --> 01:16:34,940
The organizations that look the most advanced on paper

1801
01:16:34,940 --> 01:16:38,140
are not always the ones that actually perform the best in the real world.

1802
01:16:38,140 --> 01:16:40,940
In fact, I've seen that sometimes the exact opposite is true.

1803
01:16:40,940 --> 01:16:42,540
The more complex your environment becomes,

1804
01:16:42,540 --> 01:16:45,940
the more dangerous that kind of superficial sophistication gets for the business.

1805
01:16:45,940 --> 01:16:49,340
You can have a modern platform stack and strong governance language

1806
01:16:49,340 --> 01:16:53,540
while keeping AI pilots in motion and cross-functional steering groups on the calendar.

1807
01:16:53,540 --> 01:16:56,540
You might have detailed reporting and a polished transformation narrative

1808
01:16:56,540 --> 01:17:00,940
yet still find yourself slower, heavier and less reliable than a simpler organization

1809
01:17:00,940 --> 01:17:02,740
with better structural alignment.

1810
01:17:02,740 --> 01:17:03,540
And why is that?

1811
01:17:03,540 --> 01:17:06,140
It's because sophistication is not the same thing as coherence.

1812
01:17:06,140 --> 01:17:10,740
A lot of leaders still assume that performance improves whenever you add more capability to the mix.

1813
01:17:10,740 --> 01:17:14,340
They add more tools, more controls, more specialist functions and more dashboards

1814
01:17:14,340 --> 01:17:18,340
until the system is buried under process layers and departmental optimization.

1815
01:17:18,340 --> 01:17:20,540
That feels disciplined and it certainly feels mature

1816
01:17:20,540 --> 01:17:23,540
but if those additions aren't aligned into one operating logic

1817
01:17:23,540 --> 01:17:24,740
they don't increase performance.

1818
01:17:24,740 --> 01:17:27,140
Instead they just increase internal drag.

1819
01:17:27,140 --> 01:17:30,740
The truth isn't that advanced organizations are inherently bad

1820
01:17:30,740 --> 01:17:34,940
but rather that advancement without alignment becomes expensive very quickly.

1821
01:17:34,940 --> 01:17:38,140
Every extra layer creates another point where work can pause

1822
01:17:38,140 --> 01:17:42,740
meaning can split and responsibility can blur until power distorts the path entirely.

1823
01:17:42,740 --> 01:17:45,340
That is why I keep coming back to the concept of design.

1824
01:17:45,340 --> 01:17:49,140
High performance is not the outcome of endless improvement activity.

1825
01:17:49,140 --> 01:17:51,140
It is the outcome of architectural fit.

1826
01:17:51,140 --> 01:17:53,140
When the decision flow fits the pace of the business

1827
01:17:53,140 --> 01:17:58,140
and the data flow fits the need for trust, performance rises even if the environment isn't flashy.

1828
01:17:58,140 --> 01:18:02,140
Interaction must fit the complexity of coordination and power must fit

1829
01:18:02,140 --> 01:18:05,140
the people accountable for outcomes for the system to actually work

1830
01:18:05,140 --> 01:18:10,540
when those things don't fit performance falls even if the organization looks digitally impressive from the outside.

1831
01:18:10,540 --> 01:18:14,740
This is a hard truth for leadership teams because it challenges a very common instinct

1832
01:18:14,740 --> 01:18:16,340
to optimize whatever is visible.

1833
01:18:16,340 --> 01:18:19,740
If approvals feel slow, they optimize approvals and if meetings feel heavy

1834
01:18:19,740 --> 01:18:23,140
or reporting feels messy they try to optimize those specific points.

1835
01:18:23,140 --> 01:18:26,940
Even when AI value is weak, the instinct is to optimize prompting, training

1836
01:18:26,940 --> 01:18:29,340
or use case selection to fix the immediate gap.

1837
01:18:29,340 --> 01:18:31,940
But here's the thing, those interventions might help locally.

1838
01:18:31,940 --> 01:18:36,140
But they won't solve the deeper issue when the organization is fragmented at the design level.

1839
01:18:36,140 --> 01:18:40,940
You cannot optimize your way into coherence because you have to design for it from the ground up.

1840
01:18:40,940 --> 01:18:44,740
That shift in perspective changes how we think about high performance entirely.

1841
01:18:44,740 --> 01:18:49,140
High performing organizations are not just better managed collections of parts.

1842
01:18:49,140 --> 01:18:54,340
They are aligned systems designed to reduce unnecessary interpretation at the point of action.

1843
01:18:54,340 --> 01:18:57,540
They are designed so people know where truth lives and routine decisions

1844
01:18:57,540 --> 01:18:59,940
don't have to pretend to be strategic theatre.

1845
01:18:59,940 --> 01:19:05,340
These systems ensure that technology reinforces the path instead of exposing the confusion inside it

1846
01:19:05,340 --> 01:19:08,740
which is why alignment beats sophistication every time complexity rises.

1847
01:19:08,740 --> 01:19:14,740
Complexity multiplies the cost of every inconsistency, turning a small annoyance into a massive structural failure.

1848
01:19:14,740 --> 01:19:17,140
One week handoff in a small organization is annoying,

1849
01:19:17,140 --> 01:19:20,940
but that same handoff in a highly connected AI accelerated organization

1850
01:19:20,940 --> 01:19:22,740
becomes a destructive chain reaction.

1851
01:19:22,740 --> 01:19:25,740
An unclear owner in a simple process creates a delay,

1852
01:19:25,740 --> 01:19:31,340
while an unclear owner in an automated cross-platform flow creates stalled work and a total loss of confidence at scale.

1853
01:19:31,340 --> 01:19:37,140
If complexity is increasing then structural resilience matters more than any isolated best practice you could implement.

1854
01:19:37,140 --> 01:19:42,340
They use the phrase structural resilience because it describes the actual requirement for a modern business to survive.

1855
01:19:42,340 --> 01:19:45,340
Can the organization keep moving clearly under pressure and speed

1856
01:19:45,340 --> 01:19:49,140
or does it collapse into meetings and manual repair the moment an exception occurs?

1857
01:19:49,140 --> 01:19:52,940
Can it handle acceleration without multiplying confusion across the entire stack?

1858
01:19:52,940 --> 01:19:57,140
That is what high performance really means now, not maximum activity or looking transformed,

1859
01:19:57,140 --> 01:19:58,740
but being structurally capable.

1860
01:19:58,740 --> 01:20:01,740
Once you see that the sequence of work becomes much clearer.

1861
01:20:01,740 --> 01:20:05,140
Design first, optimize second, and automate last.

1862
01:20:05,140 --> 01:20:06,740
That is the order you have to follow.

1863
01:20:06,740 --> 01:20:09,940
If you reverse it, you usually end up amplifying instability,

1864
01:20:09,940 --> 01:20:14,140
but if you respect that order, then optimization finally lands in the right place.

1865
01:20:14,140 --> 01:20:17,340
It sharpens a coherent path instead of just decorating a broken one

1866
01:20:17,340 --> 01:20:22,340
and automation finally becomes a strategic tool that accelerates a system that already knows how to move.

1867
01:20:22,340 --> 01:20:25,540
The most effective organizations are not the ones doing the most.

1868
01:20:25,540 --> 01:20:29,540
They are the ones with the cleanest fit between architecture and business reality.

1869
01:20:29,540 --> 01:20:31,140
Where leaders should start on Monday.

1870
01:20:31,140 --> 01:20:34,540
So if you are leading a team, a function, or a platform environment,

1871
01:20:34,540 --> 01:20:36,540
where do you actually start on Monday morning?

1872
01:20:36,540 --> 01:20:39,740
You don't start with a transformation office, a new AI pilot,

1873
01:20:39,740 --> 01:20:44,140
or a broad maturity assessment that produces 47 recommendations nobody can absorb.

1874
01:20:44,140 --> 01:20:48,140
You start with one flow, specifically one high friction decision flow,

1875
01:20:48,140 --> 01:20:51,740
with a visible business impact that your organization feels every single week.

1876
01:20:51,740 --> 01:20:56,140
Maybe it's a budget approval that always stalls or a customer issue that keeps escalating,

1877
01:20:56,140 --> 01:20:59,940
or perhaps it's a reporting cycle that triggers arguments instead of action.

1878
01:20:59,940 --> 01:21:02,940
You might have a project intake path that looks governed,

1879
01:21:02,940 --> 01:21:04,340
but moves like wet concrete.

1880
01:21:04,340 --> 01:21:06,740
So just pick one and do something very simple.

1881
01:21:06,740 --> 01:21:08,740
Map the real path, not the official one,

1882
01:21:08,740 --> 01:21:11,940
and sit with the people inside the flow to trace what actually happens.

1883
01:21:11,940 --> 01:21:14,140
You need to see where it starts, where it pauses,

1884
01:21:14,140 --> 01:21:17,340
and who really makes the final decision when things get complicated.

1885
01:21:17,340 --> 01:21:21,140
Ask which data gets questioned, where chat replaces the official process,

1886
01:21:21,140 --> 01:21:24,540
and where someone with unofficial authority steps into change the route.

1887
01:21:24,540 --> 01:21:28,540
That exercise alone will tell you more than another status tech ever could,

1888
01:21:28,540 --> 01:21:32,540
and then you can identify three specific things, one ownership ambiguity,

1889
01:21:32,540 --> 01:21:34,940
one truth conflict, and one interaction bottleneck.

1890
01:21:34,940 --> 01:21:36,340
That is enough to get started.

1891
01:21:36,340 --> 01:21:39,340
You do not need a full organizational redesign to begin this process.

1892
01:21:39,340 --> 01:21:42,940
You just need one piece of visible reality you are willing to treat seriously.

1893
01:21:42,940 --> 01:21:46,540
Redesign that one flow by clarifying the decision owner,

1894
01:21:46,540 --> 01:21:50,540
reducing one unnecessary approval, and moving context closer to the point of action.

1895
01:21:50,540 --> 01:21:54,140
Remove one duplicate report, and align one permission with one accountable role

1896
01:21:54,140 --> 01:21:55,940
to see how the system responds.

1897
01:21:55,940 --> 01:22:00,140
That may sound small, but it isn't, because once one important flow becomes clearer,

1898
01:22:00,140 --> 01:22:02,540
the people inside it feel the difference immediately.

1899
01:22:02,540 --> 01:22:04,340
They experience less waiting, less guessing,

1900
01:22:04,340 --> 01:22:07,540
and less of that protective communication that eats up so much time.

1901
01:22:07,540 --> 01:22:11,340
This creates credibility, which is something most transformation programs struggle to produce

1902
01:22:11,340 --> 01:22:13,740
because they focus on announcements rather than results.

1903
01:22:13,740 --> 01:22:15,740
The system starts behaving differently,

1904
01:22:15,740 --> 01:22:19,140
and that is the kind of momentum you want, a designed system outcome,

1905
01:22:19,140 --> 01:22:20,740
rather than a corporate slogan.

1906
01:22:20,740 --> 01:22:23,540
Once you have one success, you can repeat the method.

1907
01:22:23,540 --> 01:22:26,940
See the reality, identify the friction, redesign the flow,

1908
01:22:26,940 --> 01:22:29,740
and align access before layering automation last.

1909
01:22:29,740 --> 01:22:34,140
This sequence scales because it is based on operational truth instead of blind optimism.

1910
01:22:34,140 --> 01:22:37,340
If you are working in the Microsoft 365 world specifically,

1911
01:22:37,340 --> 01:22:39,340
this approach is even more practical.

1912
01:22:39,340 --> 01:22:44,940
Choose one flow already touching teams, sharepoint, power automate, and approvals,

1913
01:22:44,940 --> 01:22:48,740
because those environments already contain all the evidence you need.

1914
01:22:48,740 --> 01:22:53,540
You do not need more abstraction, you just need better observation of how work actually moves.

1915
01:22:53,540 --> 01:22:56,140
So here is the question I would bring into the office on Monday,

1916
01:22:56,140 --> 01:23:00,740
where in our organization is important work still being held together by human compensation,

1917
01:23:00,740 --> 01:23:05,340
find that point of failure where people are working around the system just to get things done.

1918
01:23:05,340 --> 01:23:07,340
That is where your design work should begin.

1919
01:23:07,340 --> 01:23:11,540
Adding more capability to a fragmented model won't build a better organization

1920
01:23:11,540 --> 01:23:16,940
because real growth only happens when you design how work, truth, and authority actually move together.

1921
01:23:16,940 --> 01:23:21,940
If this perspective changed how you see performance, I'd appreciate a review or a connection on LinkedIn.

1922
01:23:21,940 --> 01:23:27,940
Subscribe to the podcast for more deep dives on Microsoft 365 Copilot and the modern workplace.