Beyond the Microsoft Adoption Framework- The Reality of M365 Success

1
00:00:00,000 --> 00:00:02,520
Before we look at why your adoption framework is failing,

2
00:00:02,520 --> 00:00:05,160
hit subscribe on M365FM, we track this stuff every day.

3
00:00:05,160 --> 00:00:07,240
Most companies think their co-pilot rollout failed

4
00:00:07,240 --> 00:00:08,440
because of change management.

5
00:00:08,440 --> 00:00:09,120
It didn't.

6
00:00:09,120 --> 00:00:11,400
It failed because of the model underneath it.

7
00:00:11,400 --> 00:00:13,840
Here is the tension nobody wants to name out loud.

8
00:00:13,840 --> 00:00:17,240
The cloud adoption framework and the M365 adoption guide

9
00:00:17,240 --> 00:00:19,800
both promise to eliminate common failure points.

10
00:00:19,800 --> 00:00:21,320
That is the actual language they use.

11
00:00:21,320 --> 00:00:24,520
And yet, most organizations still hit the exact same wall,

12
00:00:24,520 --> 00:00:27,440
the same governance mess, the same stall team's rollout,

13
00:00:27,440 --> 00:00:29,680
the same co-pilot licenses sitting unused

14
00:00:29,680 --> 00:00:31,000
by the end of this episode,

15
00:00:31,000 --> 00:00:32,480
you are going to understand the difference

16
00:00:32,480 --> 00:00:35,440
between deploying M365 and actually integrating it

17
00:00:35,440 --> 00:00:36,880
into how your business works.

18
00:00:36,880 --> 00:00:38,960
You will see why 73% of deployments

19
00:00:38,960 --> 00:00:41,000
make the exact same governance mistake.

20
00:00:41,000 --> 00:00:43,440
Over and over, regardless of company size or industry,

21
00:00:43,440 --> 00:00:45,320
here are the stakes.

22
00:00:45,320 --> 00:00:47,520
If you do not fix the model underneath your rollout,

23
00:00:47,520 --> 00:00:48,880
co-pilot cannot fix it for you.

24
00:00:48,880 --> 00:00:51,240
It just runs the same dysfunction faster.

25
00:00:51,240 --> 00:00:52,640
The promise.

26
00:00:52,640 --> 00:00:54,400
Nobody reads past the headline.

27
00:00:54,400 --> 00:00:56,920
Go read the Microsoft documentation right now

28
00:00:56,920 --> 00:00:58,480
and you will find this line.

29
00:00:58,480 --> 00:01:01,040
"Proven guidance to be successful in Azure."

30
00:01:01,040 --> 00:01:03,000
It sounds solid, it feels battle tested,

31
00:01:03,000 --> 00:01:05,880
thousands of deployments, best practices baked in,

32
00:01:05,880 --> 00:01:07,240
and it is not wrong exactly,

33
00:01:07,240 --> 00:01:08,680
but it is also not the whole story

34
00:01:08,680 --> 00:01:10,120
because being successful in Azure

35
00:01:10,120 --> 00:01:11,640
and being successful as a business

36
00:01:11,640 --> 00:01:13,280
are two completely different outcomes.

37
00:01:13,280 --> 00:01:15,920
The framework assumes you will figure out the gap yourself.

38
00:01:15,920 --> 00:01:17,760
Barbara Forbes is an Azure MVP

39
00:01:17,760 --> 00:01:20,000
who has watched a lot of these rollouts go sideways.

40
00:01:20,000 --> 00:01:22,240
She uses a specific comparison for this.

41
00:01:22,240 --> 00:01:24,040
On-prem used to work like a policeman

42
00:01:24,040 --> 00:01:25,800
standing in an intersection.

43
00:01:25,800 --> 00:01:27,520
Every request went through a person

44
00:01:27,520 --> 00:01:29,680
that person said yes or no, and it was slow.

45
00:01:29,680 --> 00:01:30,800
But it was controlled.

46
00:01:30,800 --> 00:01:33,040
The cloud replaced that policeman with a roundabout.

47
00:01:33,040 --> 00:01:34,880
No one is stopping you at a light anymore.

48
00:01:34,880 --> 00:01:36,320
You get freedom, you get speed,

49
00:01:36,320 --> 00:01:37,880
you get delegated responsibility,

50
00:01:37,880 --> 00:01:40,160
but there are still guardrails, still lanes,

51
00:01:40,160 --> 00:01:42,200
still a structure you are supposed to follow,

52
00:01:42,200 --> 00:01:43,120
but here is the problem.

53
00:01:43,120 --> 00:01:44,720
Just because you build a roundabout

54
00:01:44,720 --> 00:01:47,040
does not mean people know how to drive through one.

55
00:01:47,040 --> 00:01:49,120
You can put up the signs, you can paint the lines,

56
00:01:49,120 --> 00:01:52,160
you can follow every design spec in the documentation

57
00:01:52,160 --> 00:01:54,920
and you will still end up with cars stuck in the middle

58
00:01:54,920 --> 00:01:57,280
because nobody taught the drivers what a yield actually means.

59
00:01:57,280 --> 00:01:58,400
The structure existed,

60
00:01:58,400 --> 00:02:00,240
but the behavior never changed to match it.

61
00:02:00,240 --> 00:02:02,480
That is exactly what happens with M365.

62
00:02:02,480 --> 00:02:04,040
Microsoft hands you the roundabout,

63
00:02:04,040 --> 00:02:07,080
teams, sharepoint, copilot.

64
00:02:07,080 --> 00:02:08,480
A whole stack of governance tools

65
00:02:08,480 --> 00:02:09,800
are sitting there ready to go.

66
00:02:09,800 --> 00:02:11,760
And the assumption baked into the rollout

67
00:02:11,760 --> 00:02:14,720
is that people will just know they will know where files go,

68
00:02:14,720 --> 00:02:17,600
they will know which tool to use for which conversation,

69
00:02:17,600 --> 00:02:20,440
they will know that share with anyone is a decision,

70
00:02:20,440 --> 00:02:22,600
not a default, nobody forces anyone to learn

71
00:02:22,600 --> 00:02:23,600
the traffic rules.

72
00:02:23,600 --> 00:02:24,800
So people drive through, however,

73
00:02:24,800 --> 00:02:26,720
they used to drive through the old intersection.

74
00:02:26,720 --> 00:02:28,480
Now you have the same bad habits,

75
00:02:28,480 --> 00:02:30,680
just running on a new platform with better branding.

76
00:02:30,680 --> 00:02:32,480
This is the core idea of this channel.

77
00:02:32,480 --> 00:02:34,920
I'm going to keep coming back to it all episode.

78
00:02:34,920 --> 00:02:36,560
The model don't not the framework,

79
00:02:36,560 --> 00:02:37,560
the model the framework,

80
00:02:37,560 --> 00:02:39,720
KF the M365 adoption guide,

81
00:02:39,720 --> 00:02:41,000
none of that is what is breaking.

82
00:02:41,000 --> 00:02:43,760
What is breaking is the assumption sitting underneath the framework.

83
00:02:43,760 --> 00:02:46,480
It is the quiet belief that structure alone changes behavior.

84
00:02:46,480 --> 00:02:47,320
It does not.

85
00:02:47,320 --> 00:02:49,720
A roundabout does not teach anyone to yield.

86
00:02:49,720 --> 00:02:52,720
A landing zone does not teach anyone what data belongs where.

87
00:02:52,720 --> 00:02:54,000
A license does not teach anyone

88
00:02:54,000 --> 00:02:56,560
why they should change how they have worked for the last 10 years.

89
00:02:56,560 --> 00:02:58,400
So if the framework is not the problem,

90
00:02:58,400 --> 00:02:59,840
and the tools are not the problem,

91
00:02:59,840 --> 00:03:01,720
what exactly is everyone getting wrong?

92
00:03:01,720 --> 00:03:03,040
That is section two.

93
00:03:03,040 --> 00:03:04,560
Why adoption fails?

94
00:03:04,560 --> 00:03:06,000
It's never the technology.

95
00:03:06,000 --> 00:03:09,280
Here's the finding that shows up in every piece of research on this topic.

96
00:03:09,280 --> 00:03:10,560
It isn't subtle.

97
00:03:10,560 --> 00:03:12,920
M365 rarely fails because of the tools,

98
00:03:12,920 --> 00:03:14,240
not once in the data does,

99
00:03:14,240 --> 00:03:16,720
SharePoint is confusing or teams is buggy,

100
00:03:16,720 --> 00:03:19,000
show up as the root cause of a failed rollout.

101
00:03:19,000 --> 00:03:20,720
The tools work, they have always worked.

102
00:03:20,720 --> 00:03:22,160
That is not where the breakdown happens.

103
00:03:22,160 --> 00:03:25,000
Microsoft's own adoption guidance admits this directly,

104
00:03:25,000 --> 00:03:27,000
and it is worth sitting with that for a second.

105
00:03:27,000 --> 00:03:28,400
Their documentation says,

106
00:03:28,400 --> 00:03:33,200
"Adoption projects fail when people do not understand why they need to change their behavior."

107
00:03:33,200 --> 00:03:35,000
Read that again.

108
00:03:35,000 --> 00:03:37,320
Not when people don't understand the interface.

109
00:03:37,320 --> 00:03:39,120
Not when training is insufficient.

110
00:03:39,120 --> 00:03:40,640
When they don't understand why.

111
00:03:40,640 --> 00:03:43,240
That is Microsoft, the company selling you the tools,

112
00:03:43,240 --> 00:03:44,960
telling you the tools were never the bottleneck.

113
00:03:44,960 --> 00:03:46,960
So if it is not the tools, where is the gap?

114
00:03:46,960 --> 00:03:49,760
It is in how differently everyone inside the organization

115
00:03:49,760 --> 00:03:51,480
interprets the same rollout.

116
00:03:51,480 --> 00:03:53,640
IT treats go live as a deployment event.

117
00:03:53,640 --> 00:03:57,040
Boxes checked, tenant configured, licenses assigned, done.

118
00:03:57,040 --> 00:04:00,040
Employees experience the exact same rollout as a UI update,

119
00:04:00,040 --> 00:04:02,040
new buttons, new logos, same job.

120
00:04:02,040 --> 00:04:04,440
Executives see it as a line item, money spent,

121
00:04:04,440 --> 00:04:05,640
checked off in a board deck,

122
00:04:05,640 --> 00:04:08,840
three groups, three completely different definitions of finished.

123
00:04:08,840 --> 00:04:11,440
And none of the match what adoption actually requires,

124
00:04:11,440 --> 00:04:16,040
the real failure sits in the space between license activated and behavior changed.

125
00:04:16,040 --> 00:04:18,040
That gap is invisible on a dashboard.

126
00:04:18,040 --> 00:04:22,040
You can have 100% license activation and 0% behavior change,

127
00:04:22,040 --> 00:04:24,840
and from the license report everything looks perfect.

128
00:04:24,840 --> 00:04:28,240
This is the gap where entire transformation budgets quietly disappear.

129
00:04:28,240 --> 00:04:32,440
And here is a number that should change how you read every rollout report you have ever received.

130
00:04:32,440 --> 00:04:35,440
Unmanaged rollouts, the kind where IT flips the switch

131
00:04:35,440 --> 00:04:38,840
and hopes for the best plateau around 30% effective adoption,

132
00:04:38,840 --> 00:04:40,440
structured change programs,

133
00:04:40,440 --> 00:04:43,240
the ones that actually address behavior instead of access,

134
00:04:43,240 --> 00:04:44,840
hit 70% or higher,

135
00:04:44,840 --> 00:04:47,440
same tools, same licenses, same company size.

136
00:04:47,440 --> 00:04:49,440
The only variable that moves the needle that much

137
00:04:49,440 --> 00:04:52,240
is whether anyone designed for behavior change on purpose.

138
00:04:52,240 --> 00:04:55,840
Now here is the moment that should actually break something in how you think about this.

139
00:04:55,840 --> 00:04:58,840
Usage numbers going up can still mean adoption is failing.

140
00:04:58,840 --> 00:05:01,440
Say that sits wrong with you for a second because it should.

141
00:05:01,440 --> 00:05:04,640
You can watch Teams messages climb, watch SharePoint edits climb

142
00:05:04,640 --> 00:05:07,640
and watch every chart in your reporting toolpoint up and to the right

143
00:05:07,640 --> 00:05:09,640
and still be looking at a failed adoption.

144
00:05:09,640 --> 00:05:12,840
Because rising activity does not tell you whether people changed how they work.

145
00:05:12,840 --> 00:05:15,840
It just tells you they are doing something inside the tool.

146
00:05:15,840 --> 00:05:17,640
Confusion generates activity too.

147
00:05:17,640 --> 00:05:18,840
So does duplicated effort.

148
00:05:18,840 --> 00:05:23,440
So does five people recreating the same file because nobody agreed on where it should live in the first place.

149
00:05:23,440 --> 00:05:27,640
This is the belief most leaders walk into these rollouts holding and it is wrong.

150
00:05:27,640 --> 00:05:29,440
The belief that activity is the finish line.

151
00:05:29,440 --> 00:05:31,040
It is not.

152
00:05:31,040 --> 00:05:34,240
Activity is just noise until you know what it is actually measuring.

153
00:05:34,240 --> 00:05:37,840
So if the tools are not the problem and activity is not proof of success,

154
00:05:37,840 --> 00:05:42,840
you are probably wondering what Microsoft's own framework actually tells you to do about any of this.

155
00:05:42,840 --> 00:05:46,440
Strategy the step everyone skips or fakes.

156
00:05:46,440 --> 00:05:50,640
So here is what the framework actually says to do first before you touch a single as your resource

157
00:05:50,640 --> 00:05:52,640
before you provision the single tenant setting.

158
00:05:52,640 --> 00:05:56,840
You are supposed to answer one question why are we moving at all that is it that is step one

159
00:05:56,840 --> 00:06:01,240
and here is the part that should bother you half the company is going through this skip it completely.

160
00:06:01,240 --> 00:06:05,240
Not because they are careless but because they already have the technology sitting in front of them

161
00:06:05,240 --> 00:06:08,640
and we have the technology starts feeling like a reason on its own.

162
00:06:08,640 --> 00:06:09,640
It is not.

163
00:06:09,640 --> 00:06:11,840
It is just an excuse dressed up as momentum.

164
00:06:11,840 --> 00:06:15,440
Barbara Forbes calls this out with a pattern she has seen over and over.

165
00:06:15,440 --> 00:06:19,640
A company's hardware is running out of support in three months so suddenly everyone is scrambling

166
00:06:19,640 --> 00:06:22,440
to migrate and the whole thing gets framed as strategy.

167
00:06:22,440 --> 00:06:26,840
It is not strategy it is a deadline wearing a strategies clothes nobody sat down and asked

168
00:06:26,840 --> 00:06:31,840
what they wanted the business to look like on the other side they just knew the old servers were about to become a liability

169
00:06:31,840 --> 00:06:36,640
and moving fast felt like the only option that is not direction that is panic with a project plan attached.

170
00:06:36,640 --> 00:06:41,440
The framework actually gives you a real vocabulary for this and it is worth using instead of guessing.

171
00:06:41,440 --> 00:06:45,240
There are migration triggers these are about cost complexity and agility.

172
00:06:45,240 --> 00:06:50,440
Basically getting out from under something that is slowing you down and there are innovation triggers.

173
00:06:50,440 --> 00:06:56,440
These are about scale new markets and capability you cannot build on your own like AI features you would never develop in house.

174
00:06:56,440 --> 00:07:03,240
Neither one is better but you have to know which one you are actually chasing because the plan looks completely different depending on the answer.

175
00:07:03,240 --> 00:07:09,640
A migration trigger once you moving fast and cutting cost and innovation trigger once you experimenting and building new capability.

176
00:07:09,640 --> 00:07:15,040
Confuse the two and you will build the wrong thing efficiently and here is where it gets expensive if you skip this step.

177
00:07:15,040 --> 00:07:21,640
If leadership does not know why you are doing this somebody with budget authority is going to ask that question halfway through the project.

178
00:07:21,640 --> 00:07:28,640
Usually right when costs start climbing past the first estimate and if there is no answer sitting ready funding gets pulled.

179
00:07:28,640 --> 00:07:34,440
Not because the project failed technically but because nobody upstairs ever agreed on what success was supposed to look like.

180
00:07:34,440 --> 00:07:40,840
You cannot defend a number nobody understands the purpose of this is why business justification is not optional paperwork.

181
00:07:40,840 --> 00:07:53,440
It is the thing that ties the whole strategy together you are supposed to build an actual financial model here not a guess tools like the tco calculator let you compare what your current infrastructure actually costs against what the cloud would cost side by side with real numbers.

182
00:07:53,440 --> 00:08:03,840
The pricing calculator gives you a monthly estimate before you commit to anything and once you're actually running cost management gives you live visibility into what you are spending versus what you projected.

183
00:08:03,840 --> 00:08:11,840
None of this is decoration it is the thing that turns we think this will save money into here is the model showing exactly how.

184
00:08:11,840 --> 00:08:31,840
So if you take nothing else from this section take this strategy was never about the cloud it is not about which tools you pick or how fast you can deploy them strategy is direction a destination that everyone in the room it finance the business site actually agrees on before anyone starts building anything once you know why you are doing this you still have not answered who is actually going to carry it.

185
00:08:31,840 --> 00:08:51,840
Planning centralized shared or total chaos now you're actually planning and the first decision on the table is who runs this thing the framework gives you three models to pick from centralized means one team controls everything every deployment every policy every approval it's that policeman standing in the intersection again shared management is the roundabout model you delegate responsibility.

186
00:08:51,840 --> 00:09:14,840
But you do it inside guard rails everyone agreed on ahead of time then there's decentralized this is basically where everyone gets a piece of Azure and figures it out on their own but here's the thing about decentralized that surprises people it's not automatically the wrong choice if you're a startup with 10 people and no legacy baggage decentralized can actually make sense the problem isn't the model itself the problem is that almost nobody picks it on purpose it's not a decision it's what happens when nobody makes a decision at all.

187
00:09:14,840 --> 00:09:37,840
The team needed resources nobody said no and six months later that's just how the company operates that's not planning that's an accident with a name attached after the fact once you've picked a model you have to figure out what happens to your applications this is where the six hours come in and they're worth understanding by what they actually do not just as a list of words rehost means you move it as is no code changes same setup just running somewhere new

188
00:09:37,840 --> 00:10:04,840
re platform means smaller adjustments you move into a managed database or a web app service without touching much code refactor goes further you make actual code changes so you can take advantage of platform features re architect means redesigning the whole thing maybe you break it into microservices maybe you move it to containers rebuild means starting over from scratch because the existing code isn't worth saving and retain or replace means you either leave it alone or you drop it for something that already does the job but here's a bias worth correcting

189
00:10:04,840 --> 00:10:26,840
rehost the lift and shift option gets treated like the embarrassing choice people think you only pick it if you didn't have time to do it properly that reputation isn't fair if your hardware is failing and you only have three months lift and shift isn't lazy it's the correct call for the constraints you're actually working under you don't get the full benefit of the platform right away but you get out of danger you can modernize later once you aren't in crisis mode

190
00:10:26,840 --> 00:10:55,840
none of this technical planning matters if the people side gets ignored this is where skills readiness plans come in they aren't a nice to have they are part of the plan itself you need to know who needs to understand what and at what level before anyone starts touching as your resources skipping this doesn't save time it just moves the confusion from the planning phase into production where it's much more expensive to fix this is where most organizations think they're ready they're not because there's a stage nobody plans enough time for the ready the landing zone isn't the finish line so you're finally at the stage where you build something real

191
00:10:55,840 --> 00:11:24,840
and this is where most technical teams feel like they've arrived you haven't what you're building here is called a landing zone the name tells you exactly what it is if you listen to it it's the structure everything else lands on it's not the goal it's not the win it's the ground floor you build so the actual workloads have some way safe to go but here's where teams get this wrong because a landing zone gives you access to management groups and policies there's a pull to what building every single piece just because it's available you can create 10 management groups you can write 40 policies that doesn't mean you should every extra

192
00:11:24,840 --> 00:11:52,840
layer you build because you can is one more thing someone has to understand later it's one more piece of structure that has to make sense to a person who wasn't in the room when you built it overbuilding doesn't make you safer it makes the whole thing harder to reason about and confusion at this level costs you later usually right when you can least afford it one of the more useful distinctions here is the split between corporate and online landing zones it comes down to a single question for every resource you place does this thing need to talk to everything else or does it just need a path outside that's the whole decision

193
00:11:52,840 --> 00:12:16,840
a resource that only needs external access doesn't need to be wired into your entire internal network giving it that access anyway isn't generous its exposure you didn't need to create and here's the principle underneath all of it the safest connection is no connection at all if something doesn't need to talk to your core network don't connect it every connection you add is a door and every door you don't need is a door someone eventually walks through by accident or worse on purpose

194
00:12:16,840 --> 00:12:40,840
the instinct to connect everything just in case is exactly what this phase is supposed to train you out of now here's where perfectionism quietly kills momentum there's a trap in the stage where teams ask are we ever really ready if you let that question run unchecked the honest answer is no you will never have perfect governance you will never close every policy gap before shipping something if you wait for that state you don't launch slower you don't launch at all

195
00:12:40,840 --> 00:13:08,840
teams sit in this exact phase for months they refine a structure nobody has actually used yet because ready kept moving further away the more they looked at it the fix isn't complicated even if it feels uncomfortable launch small learn fast keep improving you don't need flawless governance before workload one goes live you need enough governance that workload one is safe then you adjust as you learn what workload one actually needed perfect is not a prerequisite for shipping it's usually the excuse for not shipping

196
00:13:08,840 --> 00:13:11,580
and this is the part almost everyone gets backwards.

197
00:13:11,580 --> 00:13:13,860
The sequencing mistake that breaks everything.

198
00:13:13,860 --> 00:13:18,220
Most teams building in the Cloud start with a floor assumption, they assume there is a correct order,

199
00:13:18,220 --> 00:13:20,900
build the platform first, get it solid, get it clean,

200
00:13:20,900 --> 00:13:25,380
then hand it off to the people who actually build things, that assumption is the mistake.

201
00:13:25,380 --> 00:13:29,060
Barbara Forbes has watched these rollouts for years, and her insight is blunt,

202
00:13:29,060 --> 00:13:32,380
platform and workload have to move together, not one after the other.

203
00:13:32,380 --> 00:13:37,760
Not platform, then a pause, then the workload at the same time, that is the part nobody wants to hear.

204
00:13:37,760 --> 00:13:42,760
It sounds messier than a clean handoff, because in reality it is messier.

205
00:13:42,760 --> 00:13:46,600
But messy and working beats clean and empty every single time.

206
00:13:46,600 --> 00:13:49,180
Here's what the sequential version looks like in practice.

207
00:13:49,180 --> 00:13:52,300
A company decides they are finally serious about the Cloud.

208
00:13:52,300 --> 00:13:55,800
Their first move is standing up a Cloud Centre of Excellence that sounds responsible.

209
00:13:55,800 --> 00:13:59,600
You get the experts in a room, you define the standards, you build the governance model,

210
00:13:59,600 --> 00:14:03,000
you do it properly before anyone starts deploying real work.

211
00:14:03,000 --> 00:14:06,560
But here's the problem, nobody in that room has actually run a workload

212
00:14:06,560 --> 00:14:08,480
through that environment yet.

213
00:14:08,480 --> 00:14:10,880
They are designing rules for a game they haven't played.

214
00:14:10,880 --> 00:14:15,960
And the experts building it usually treat the moment the landing zone ships as the finish line.

215
00:14:15,960 --> 00:14:18,440
So what actually happens is teams end up stuck.

216
00:14:18,440 --> 00:14:20,760
You have a landing zone with gorgeous documentation.

217
00:14:20,760 --> 00:14:23,600
Every policy is defined, every management group is in place,

218
00:14:23,600 --> 00:14:28,360
it is a genuinely impressive piece of architecture, and it has zero applications running through it.

219
00:14:28,360 --> 00:14:32,480
Nobody has touched it because nobody built it with a real workloads actual needs in mind.

220
00:14:32,480 --> 00:14:35,760
It is a beautiful empty building, all structure, no tenants.

221
00:14:35,760 --> 00:14:39,160
The model that actually works looks different, it is supposed to look overlapping.

222
00:14:39,160 --> 00:14:42,000
You build the landing zone, but you don't stop there to admire it.

223
00:14:42,000 --> 00:14:47,000
You immediately push a first workload through, that is the only way you find out what the landing zone actually got wrong.

224
00:14:47,000 --> 00:14:49,600
Then you figure out how to connect that workload to what it needs.

225
00:14:49,600 --> 00:14:52,960
Then you bring in the next 10 workloads, not because 10 is a magic number,

226
00:14:52,960 --> 00:14:56,480
but because at that scale you start seeing patterns the first one couldn't reveal.

227
00:14:56,480 --> 00:14:59,240
Then you secure what you have built based on what you now know.

228
00:14:59,240 --> 00:15:03,160
Instead of what you guessed, only then do you call something a production workload.

229
00:15:03,160 --> 00:15:05,040
Every one of those steps bleeds into the next.

230
00:15:05,040 --> 00:15:07,480
That overlap isn't slopping as it is the design.

231
00:15:07,480 --> 00:15:09,840
And here is the part that breaks most governance work.

232
00:15:09,840 --> 00:15:11,280
One size fits none.

233
00:15:11,280 --> 00:15:14,480
If your center of excellence hands every team the exact same standard,

234
00:15:14,480 --> 00:15:17,440
you haven't created consistency, you have created friction.

235
00:15:17,440 --> 00:15:20,240
The whole reason the cloud was worth adopting was flexibility.

236
00:15:20,240 --> 00:15:24,520
Treating every workload identically is how you quietly kill the thing you were trying to gain.

237
00:15:24,520 --> 00:15:29,520
And this is exactly where M365 rollouts fall into the same trap, it just has a different name.

238
00:15:29,520 --> 00:15:31,800
The M365 version of the same failure,

239
00:15:31,800 --> 00:15:36,760
take that same sequencing mistake and translate it into M365 language, you will recognize it immediately.

240
00:15:36,760 --> 00:15:39,000
I'd lead the teams and SharePoint migration.

241
00:15:39,000 --> 00:15:41,160
They move the mailboxes, they provision the sites,

242
00:15:41,160 --> 00:15:43,560
they point the old file shares at new locations.

243
00:15:43,560 --> 00:15:46,840
Then somebody sends the email that says, "Cut over complete."

244
00:15:46,840 --> 00:15:49,800
As far as the project plan is concerned, that is the finish line.

245
00:15:49,800 --> 00:15:51,800
Everyone gets a badge for shipping on time.

246
00:15:51,800 --> 00:15:55,000
Except cut over isn't adoption, cut over is just the technical move.

247
00:15:55,000 --> 00:15:57,000
Nobody's behavior has changed yet.

248
00:15:57,000 --> 00:16:02,360
Treating that email as the finish line is the same mistake as calling a landing zone "Done" the day it ships.

249
00:16:02,360 --> 00:16:05,800
The research pattern here is consistent enough that it is almost boring.

250
00:16:05,800 --> 00:16:08,840
Adoption gets treated as a technical project from the start.

251
00:16:08,840 --> 00:16:11,560
Success is defined as "Everyone has an account."

252
00:16:11,560 --> 00:16:15,160
That is the bar, not "Everyone changed how they store a document."

253
00:16:15,160 --> 00:16:17,640
Not "Everyone knows where a decision should live."

254
00:16:17,640 --> 00:16:21,560
Just "Account exists?" license assigned? Box checked.

255
00:16:21,560 --> 00:16:24,440
It is the same trap as license activated from earlier.

256
00:16:24,440 --> 00:16:29,000
Except now it is dressed up as a completed migration instead of a completed deployment.

257
00:16:29,000 --> 00:16:31,000
And here is what is missing every single time.

258
00:16:31,000 --> 00:16:34,200
There is no adoption workstream running next to the technical rollout.

259
00:16:34,200 --> 00:16:36,760
Not a smaller one, not a rushed one, none at all.

260
00:16:36,760 --> 00:16:39,800
There is no behavioral reinforcement built into the plan.

261
00:16:39,800 --> 00:16:44,280
No champions network seated before go live to carry momentum into teams that IT will never reach.

262
00:16:44,280 --> 00:16:45,720
The technical team does its job.

263
00:16:45,720 --> 00:16:48,440
The migration succeeds by every metric they are tracking.

264
00:16:48,440 --> 00:16:51,480
And then everyone assumes behavior will follow the tools on its own.

265
00:16:51,480 --> 00:16:52,920
It won't, it never has.

266
00:16:52,920 --> 00:16:54,680
So what actually happens is predictable.

267
00:16:54,680 --> 00:16:58,120
Users take their old file share habits and rebuild them inside SharePoint,

268
00:16:58,120 --> 00:17:03,320
same folder structures, same final V2 really final naming conventions, same permissions chaos.

269
00:17:03,320 --> 00:17:05,400
Just a different logo on the sharing dialogue.

270
00:17:05,400 --> 00:17:08,120
Nothing about how people manage information actually improved.

271
00:17:08,120 --> 00:17:11,320
You spent real money moving the mess into a nicer container.

272
00:17:11,320 --> 00:17:13,080
The shell changed, the behavior didn't.

273
00:17:13,080 --> 00:17:16,760
And because nobody was watching for that specific failure,

274
00:17:16,760 --> 00:17:19,160
it goes unnoticed for months, sometimes years.

275
00:17:19,160 --> 00:17:23,560
Until someone stumbles into a governance nightmare during an audit and asks how it got this bad,

276
00:17:23,560 --> 00:17:26,600
I made this point on LinkedIn recently and it is worth repeating.

277
00:17:26,600 --> 00:17:30,680
Most M365 deployments fail before anyone even starts measuring activity,

278
00:17:30,680 --> 00:17:32,520
not during the measurement before it.

279
00:17:32,520 --> 00:17:35,640
The failure is baked in at the design stage.

280
00:17:35,640 --> 00:17:37,960
The plan only accounts for the technical migration.

281
00:17:37,960 --> 00:17:41,000
It never builds in a way to track whether behavior is actually shifting.

282
00:17:41,000 --> 00:17:44,520
By the time someone opens a usage dashboard, the failure already happened.

283
00:17:44,520 --> 00:17:46,440
The dashboard just hasn't caught up yet.

284
00:17:46,440 --> 00:17:49,560
Co-pilot makes this exact failure worse and it makes it faster.

285
00:17:49,560 --> 00:17:52,200
Here is the pattern showing up right now in real rollouts.

286
00:17:52,200 --> 00:17:57,000
Licenses get enabled across the organization before anyone has defined the use cases.

287
00:17:57,000 --> 00:18:00,040
Nobody has decided which workflows co-pilot is supposed to touch first.

288
00:18:00,040 --> 00:18:01,480
Nobody knows which teams need it most.

289
00:18:01,480 --> 00:18:03,400
Nobody knows what a good outcome even looks like.

290
00:18:03,400 --> 00:18:04,280
That isn't one failure.

291
00:18:04,280 --> 00:18:06,280
That is two failures stacked on top of each other.

292
00:18:06,280 --> 00:18:09,960
It is a governance failure because nobody decided what data co-pilot should touch.

293
00:18:09,960 --> 00:18:14,920
And it isn't adoption failure because nobody told anyone what problem this is supposed to solve.

294
00:18:14,920 --> 00:18:18,680
Enable first, figure it out later, isn't a rollout strategy.

295
00:18:18,680 --> 00:18:21,560
It is the lift and shift instinct applied to AI.

296
00:18:21,560 --> 00:18:24,680
Minus the lucky part where lift and shift at least gets your working server.

297
00:18:24,680 --> 00:18:26,920
So if activity isn't the signal, what is?

298
00:18:26,920 --> 00:18:28,200
Let's talk about measurement.

299
00:18:28,200 --> 00:18:30,280
Structural adoption versus feature usage.

300
00:18:30,280 --> 00:18:31,960
Research draws a hard line here.

301
00:18:31,960 --> 00:18:34,120
Most reporting tools completely blur it.

302
00:18:34,120 --> 00:18:38,440
Structural adoption measures if your organization is built to sustain a new way of working.

303
00:18:38,440 --> 00:18:42,040
Feature usage measures if people are clicking buttons, those are not the same thing.

304
00:18:42,040 --> 00:18:43,480
If you treat them as the same,

305
00:18:43,480 --> 00:18:47,400
you end up celebrating a rollout that is quietly falling apart underneath the surface.

306
00:18:47,400 --> 00:18:49,640
Feature usage is what every dashboard shows you.

307
00:18:49,640 --> 00:18:53,720
Monthly active users, teams messages sent, sharepoint edits logged,

308
00:18:53,720 --> 00:18:57,400
co-pilot prompts fired off, it is real data, it is easy to pull,

309
00:18:57,400 --> 00:18:59,320
but it cannot prove transformation on its own.

310
00:18:59,320 --> 00:19:01,880
These numbers never tell you why someone opened teams.

311
00:19:01,880 --> 00:19:04,360
Maybe they collaborated brilliantly on a project,

312
00:19:04,360 --> 00:19:08,680
or maybe they just could not find a file and send four messages asking where it went.

313
00:19:08,680 --> 00:19:10,360
The number looks identical either way.

314
00:19:10,360 --> 00:19:13,000
Structural metrics ask a different question entirely.

315
00:19:13,000 --> 00:19:16,760
They are harder to pull because most organizations never bother setting them up.

316
00:19:16,760 --> 00:19:18,280
Training completion is a big one.

317
00:19:18,280 --> 00:19:21,400
Not just did we offer it, but did people actually finish it?

318
00:19:21,400 --> 00:19:22,840
Survey sentiment matters.

319
00:19:22,840 --> 00:19:25,000
Do people feel confident using the system?

320
00:19:25,000 --> 00:19:27,960
Or are they quietly working around it because it is too hard?

321
00:19:27,960 --> 00:19:29,720
Champion participation is another signal.

322
00:19:29,720 --> 00:19:33,640
Are the people meant to carry momentum into their teams actually showing up and doing that job?

323
00:19:33,640 --> 00:19:35,080
Then there is governance clarity.

324
00:19:35,080 --> 00:19:39,000
Can someone explain who owns a specific site or channel without having to guess?

325
00:19:39,000 --> 00:19:41,160
Support ticket trends tell the real story.

326
00:19:41,160 --> 00:19:44,680
Are the same confused questions still coming in six months after launch?

327
00:19:44,680 --> 00:19:47,480
Or did they taper off because people actually learned the system?

328
00:19:47,480 --> 00:19:49,240
These numbers move slower.

329
00:19:49,240 --> 00:19:51,320
They are less flattering in a slide deck.

330
00:19:51,320 --> 00:19:56,600
And that is exactly why so many organizations skip them and go straight to the feature usage numbers instead.

331
00:19:56,600 --> 00:19:57,720
But here is the problem.

332
00:19:57,720 --> 00:20:02,600
Rising usage numbers can mean confusion just as easily as they can mean success.

333
00:20:02,600 --> 00:20:05,560
More teams messages does not automatically mean better collaboration.

334
00:20:05,560 --> 00:20:08,600
It might mean communication got more fragmented and scattered across channels.

335
00:20:08,600 --> 00:20:13,080
It might mean more people are asking the same question five different ways because there is no clear

336
00:20:13,080 --> 00:20:14,280
place to get an answer.

337
00:20:14,280 --> 00:20:16,520
A chart going up and to the right feels like proof.

338
00:20:16,520 --> 00:20:17,240
It isn't.

339
00:20:17,240 --> 00:20:19,240
It is just proof that something is happening.

340
00:20:19,240 --> 00:20:20,520
Not that the something is good.

341
00:20:20,520 --> 00:20:22,440
I want to be honest about adoption score here.

342
00:20:22,440 --> 00:20:24,600
It gets treated like a verdict in reality.

343
00:20:24,600 --> 00:20:25,640
It is just a signal.

344
00:20:25,640 --> 00:20:29,960
Adoption score is a useful benchmark for comparing your usage to similar organizations.

345
00:20:29,960 --> 00:20:31,480
That comparison has value.

346
00:20:31,480 --> 00:20:33,240
But it is not proof of business value.

347
00:20:33,240 --> 00:20:35,800
It is a usage number wearing a success costume.

348
00:20:35,800 --> 00:20:40,680
It is dressed up to look like an outcome when it is actually just an activity count with better branding.

349
00:20:40,680 --> 00:20:44,680
Leaning on it alone is the same mistake as leaning on team's messages alone.

350
00:20:44,680 --> 00:20:46,040
Just with a friendly name attached.

351
00:20:46,040 --> 00:20:46,920
So here is the fix.

352
00:20:46,920 --> 00:20:48,120
It is not complicated.

353
00:20:48,120 --> 00:20:49,320
It is just rarely done.

354
00:20:49,320 --> 00:20:52,280
Pay usage telemetry with surveys and actual business KPIs.

355
00:20:52,280 --> 00:20:54,120
Never trust one metric family by itself.

356
00:20:54,120 --> 00:20:55,560
Usage tells you what is happening.

357
00:20:55,560 --> 00:20:58,040
Surveys tell you how people feel about what is happening.

358
00:20:58,040 --> 00:21:01,800
Business KPIs tell you if any of it moved the outcomes leadership cares about.

359
00:21:01,800 --> 00:21:03,320
You need all three in the room together.

360
00:21:03,320 --> 00:21:04,920
If you use them in isolation.

361
00:21:04,920 --> 00:21:06,920
They will lie to you in different directions.

362
00:21:06,920 --> 00:21:09,240
Usage alone over-states activity as success.

363
00:21:09,240 --> 00:21:11,720
Surveys alone cannot prove behavior actually changed.

364
00:21:11,720 --> 00:21:14,520
And KPIs alone will not tell you why the number moved.

365
00:21:14,520 --> 00:21:15,960
Or why it stayed flat.

366
00:21:15,960 --> 00:21:18,280
Now let's talk about the part nobody wants to own.

367
00:21:18,280 --> 00:21:19,160
Governance.

368
00:21:19,160 --> 00:21:21,400
Governance bolted on its governance that fails.

369
00:21:21,400 --> 00:21:23,800
Here is the number that ties everything back together.

370
00:21:23,800 --> 00:21:29,240
73% of Microsoft 365 deployments make the exact same governance mistake.

371
00:21:29,240 --> 00:21:30,280
Not similar mistakes.

372
00:21:30,280 --> 00:21:31,160
The same one.

373
00:21:31,160 --> 00:21:33,800
It happens across companies that have nothing else in common.

374
00:21:33,800 --> 00:21:34,600
Different industries.

375
00:21:34,600 --> 00:21:35,400
Different sizes.

376
00:21:35,400 --> 00:21:36,120
Different budgets.

377
00:21:36,120 --> 00:21:38,200
The mistake is this.

378
00:21:38,200 --> 00:21:39,560
They govern the tools.

379
00:21:39,560 --> 00:21:41,880
Instead of governing the platform as a system.

380
00:21:41,880 --> 00:21:44,600
Tool-centric governance is easy to miss from the inside.

381
00:21:44,600 --> 00:21:46,440
Permissions get configured app by app.

382
00:21:46,440 --> 00:21:47,800
Teams gets one set of rules.

383
00:21:47,800 --> 00:21:49,000
SharePoint gets another.

384
00:21:49,000 --> 00:21:52,200
One drive gets whatever the default happened to be the day it rolled out.

385
00:21:52,200 --> 00:21:55,080
There is no unified identity model tying it together.

386
00:21:55,080 --> 00:21:58,360
Because of that, the same person can end up with completely different access logic

387
00:21:58,360 --> 00:22:00,840
depending on which app they opened that morning.

388
00:22:00,840 --> 00:22:02,680
Ownership of individual teams and sites.

389
00:22:02,680 --> 00:22:04,200
Turns ambiguous fast.

390
00:22:04,200 --> 00:22:05,800
Someone spins up a team for a project.

391
00:22:05,800 --> 00:22:07,400
That project ends six months later.

392
00:22:07,400 --> 00:22:08,440
The team just sits there.

393
00:22:08,440 --> 00:22:09,240
It stays active.

394
00:22:09,240 --> 00:22:10,920
It holds whatever got shared inside it.

395
00:22:10,920 --> 00:22:13,560
This happens because nobody was ever assigned to close it out.

396
00:22:13,560 --> 00:22:15,720
When you multiply that by a few hundred sites.

397
00:22:15,720 --> 00:22:19,720
You get a sprawling mess with no single person accountable for any piece of it.

398
00:22:19,720 --> 00:22:22,520
System-level governance treats this completely differently.

399
00:22:22,520 --> 00:22:23,400
Identity.

400
00:22:23,400 --> 00:22:24,200
Life cycle.

401
00:22:24,200 --> 00:22:25,080
Automation.

402
00:22:25,080 --> 00:22:26,280
And policy.

403
00:22:26,280 --> 00:22:30,040
All of it gets handled as one connected model that spans every workload.

404
00:22:30,040 --> 00:22:34,760
It is not four separate decisions made by four separate teams on four separate timelines.

405
00:22:34,760 --> 00:22:38,040
The team gets created with a life cycle attached to it from day one.

406
00:22:38,040 --> 00:22:39,080
An owner is assigned.

407
00:22:39,080 --> 00:22:41,240
An expiration policy is set to trigger.

408
00:22:41,240 --> 00:22:44,200
Identity rules apply the same way whether someone is in teams.

409
00:22:44,200 --> 00:22:45,880
SharePoint or Outlook.

410
00:22:45,880 --> 00:22:47,480
It is not glamorous work.

411
00:22:47,480 --> 00:22:50,280
But it is the difference between a platform you can understand.

412
00:22:50,280 --> 00:22:54,440
And one way every question requires digging through a different admin panel to get an answer.

413
00:22:54,440 --> 00:22:57,000
If you get this wrong, the consequences are not abstract.

414
00:22:57,000 --> 00:22:58,840
They show up as real exposure.

415
00:22:58,840 --> 00:23:02,360
Data gets overexposed because sharing defaults never got locked down.

416
00:23:02,360 --> 00:23:06,840
Anyone with the link becomes the path of least resistance for people who just want to get their work done

417
00:23:06,840 --> 00:23:09,240
without asking IT for permission first.

418
00:23:09,240 --> 00:23:13,080
Compliance gaps sit there quietly until someone finds them during an audit.

419
00:23:13,080 --> 00:23:15,880
And an audit is exactly the wrong moment to discover a problem.

420
00:23:15,880 --> 00:23:17,240
By then, it is not a fix.

421
00:23:17,240 --> 00:23:18,520
It is a disclosure.

422
00:23:18,520 --> 00:23:20,920
This connects back to the conversation we had about Azure.

423
00:23:20,920 --> 00:23:24,600
Remember the network engineer who said the safest connection is no connection at all.

424
00:23:24,600 --> 00:23:27,000
That logic does not stay inside the network layer.

425
00:23:27,000 --> 00:23:31,080
It applies just as hard to sharing an access inside Microsoft 365.

426
00:23:31,080 --> 00:23:34,600
Every link said to anyone is a connection you did not need to create.

427
00:23:34,600 --> 00:23:38,840
Every guest account with standing access to more than they are using is a door left open.

428
00:23:38,840 --> 00:23:42,600
It stays open because closing it felt like extra work nobody signed up for.

429
00:23:42,600 --> 00:23:45,960
The instinct that protects a network, which is to default to the minimum necessary,

430
00:23:45,960 --> 00:23:47,880
is the exact same instinct that protects a tenant.

431
00:23:47,880 --> 00:23:49,560
So what does good actually look like here?

432
00:23:49,560 --> 00:23:52,120
Baseline policies get defined before the rollout.

433
00:23:52,120 --> 00:23:55,960
They are not retrofitted after the fact once something has already gone wrong,

434
00:23:55,960 --> 00:23:59,480
sharing defaults, retention rules, identity requirements.

435
00:23:59,480 --> 00:24:01,800
All of it is decided while the tenant is still empty.

436
00:24:01,800 --> 00:24:06,600
You do not want to patch these in after 300 sites already exist within consistent settings.

437
00:24:06,600 --> 00:24:09,480
Governance built this way is not a reaction to a problem.

438
00:24:09,480 --> 00:24:12,680
It is the thing that prevents the problem from having a chance to start.

439
00:24:12,680 --> 00:24:15,240
This is where the accountability question comes in.

440
00:24:15,240 --> 00:24:17,160
And it is uglier than most leaders admit.

441
00:24:17,160 --> 00:24:20,840
Accountability gaps when everyone owns nothing.

442
00:24:20,840 --> 00:24:22,920
Research keeps surfacing a specific pattern.

443
00:24:22,920 --> 00:24:26,440
It is an uncomfortable one to sit with if you are the person who signed off on the budget.

444
00:24:26,440 --> 00:24:28,200
Sponsors exist to fund the project.

445
00:24:28,200 --> 00:24:31,720
They don't exist to own the behavior change that project was supposed to produce.

446
00:24:31,720 --> 00:24:33,240
What typically happens is simple.

447
00:24:33,240 --> 00:24:35,480
Someone in finance or leadership approves the spend.

448
00:24:35,480 --> 00:24:38,360
They get the project moving, they show up for the kickoff, and then,

449
00:24:38,360 --> 00:24:40,920
functionally, they disappear.

450
00:24:40,920 --> 00:24:43,960
They leave the part of the work that actually determines whether anything changes.

451
00:24:43,960 --> 00:24:46,680
Because budget approval isn't the same as accountability.

452
00:24:46,680 --> 00:24:50,280
Treating it that way is how a rollout ends up fully paid for and half adopted.

453
00:24:50,280 --> 00:24:54,520
Once that gap opens up at the top, it spreads through the rest of the organization fast.

454
00:24:54,520 --> 00:24:59,240
IT assumes collaboration design and data protection belong to security.

455
00:24:59,240 --> 00:25:04,200
Security assumes it belongs to whoever is managing the Microsoft 365 tenant day to day.

456
00:25:04,200 --> 00:25:07,880
HR assumes it's an IT function because it lives inside software.

457
00:25:07,880 --> 00:25:10,760
Operations assumes someone already decided this month ago,

458
00:25:10,760 --> 00:25:12,280
and they just never got the memo.

459
00:25:12,280 --> 00:25:16,360
Every single group has a reasonable sounding excuse for why it's not their job.

460
00:25:16,360 --> 00:25:20,120
And every one of those excuses is technically true from where they're standing.

461
00:25:20,120 --> 00:25:21,240
Nobody is lying.

462
00:25:21,240 --> 00:25:26,200
They're just all looking at each other, waiting for the person who's supposed to own this to step forward.

463
00:25:26,200 --> 00:25:27,800
But that person doesn't exist yet.

464
00:25:27,800 --> 00:25:30,520
This is exactly where the center of excellence quietly fails.

465
00:25:30,520 --> 00:25:32,760
It's a subtler failure than most people expect.

466
00:25:32,760 --> 00:25:35,720
On paper, the COE is supposed to be the group that owns this.

467
00:25:35,720 --> 00:25:39,800
In practice, it exists as documentation, a wiki page, a set of slides from the kickoff,

468
00:25:39,800 --> 00:25:42,360
a folder full of standards nobody is required to follow.

469
00:25:42,360 --> 00:25:44,520
It was never built as an enforced control plane.

470
00:25:44,520 --> 00:25:48,360
It has no actual authority to approve, block, or redirect decisions.

471
00:25:48,360 --> 00:25:52,440
It's a reference, not a rule book, and reference material doesn't stop anyone from doing something risky.

472
00:25:52,440 --> 00:25:56,280
It just sits there so people can point to it after the fact and say the guidance existed.

473
00:25:56,280 --> 00:25:58,520
This is the Gaparassi model is built to close.

474
00:25:58,520 --> 00:26:01,160
It's worth being plain about what those letters actually mean,

475
00:26:01,160 --> 00:26:02,760
instead of treating it like jargon.

476
00:26:02,760 --> 00:26:04,520
Responsible is the person doing the work.

477
00:26:04,520 --> 00:26:07,240
Accountable is the person who answers for whether it got done right.

478
00:26:07,240 --> 00:26:09,640
There should only ever be one of those per decision.

479
00:26:09,640 --> 00:26:12,680
Consulted is everyone whose input matters before a call gets made.

480
00:26:12,680 --> 00:26:15,480
Informed is everyone who just needs to know once it has.

481
00:26:15,480 --> 00:26:17,880
If you skip this structure, you don't get flexibility.

482
00:26:17,880 --> 00:26:19,080
You get paralysis.

483
00:26:19,080 --> 00:26:23,720
Decisions stall because three different people think they're the one who's supposed to approve something.

484
00:26:23,720 --> 00:26:25,880
Or worse, none of them think it's them.

485
00:26:25,880 --> 00:26:30,200
Instructions conflict because two different teams gave two different answers to the same question.

486
00:26:30,200 --> 00:26:33,160
Nobody above them noticed until a user got caught in the middle.

487
00:26:33,160 --> 00:26:35,480
You can see this play out in real time with co-pilot.

488
00:26:35,480 --> 00:26:38,200
Rollout stole constantly for exactly this reason.

489
00:26:38,200 --> 00:26:41,320
A team wants to use it for a new workflow that is genuinely useful,

490
00:26:41,320 --> 00:26:42,600
but the request just sits there.

491
00:26:42,600 --> 00:26:44,680
It isn't because the technology can't support it.

492
00:26:44,680 --> 00:26:48,680
It's because nobody can say with confidence who's allowed to approve a new AI use case.

493
00:26:48,680 --> 00:26:49,880
Is it securities call?

494
00:26:49,880 --> 00:26:51,960
Legal's it's the business unit's own.

495
00:26:51,960 --> 00:26:55,720
In an organization without clear accountability, the answer is often,

496
00:26:55,720 --> 00:26:58,120
let's set up a meeting to figure out who decides.

497
00:26:58,120 --> 00:27:00,200
And that meeting takes three weeks to schedule.

498
00:27:00,200 --> 00:27:03,560
So let's go back to the model that actually works when this is done right.

499
00:27:03,560 --> 00:27:06,040
What good actually looks like the adopt loop.

500
00:27:06,040 --> 00:27:09,880
The path barbre forbs lays out when things go right is worth stating plainly.

501
00:27:09,880 --> 00:27:12,360
It's simpler than the failure mode we just walk through.

502
00:27:12,360 --> 00:27:16,440
Landing zone, first workload, connect, first 10 workloads, secure,

503
00:27:16,440 --> 00:27:18,520
first production workload, six steps.

504
00:27:18,520 --> 00:27:21,160
And none of them wait politely for the one before it to be finished.

505
00:27:21,160 --> 00:27:24,200
Why does this loop actually work when the sequential version doesn't?

506
00:27:24,200 --> 00:27:28,520
Because it forces platform teams and workload teams to keep talking to each other the whole way through.

507
00:27:28,520 --> 00:27:31,800
They don't just meet once it kick off and then again at the post mortem.

508
00:27:31,800 --> 00:27:33,960
When a workload goes through the connect phase,

509
00:27:33,960 --> 00:27:37,480
the platform team learns something real about what their landing zone got wrong.

510
00:27:37,480 --> 00:27:40,440
Now there's an actual application sending actual traffic through it.

511
00:27:40,440 --> 00:27:43,240
That's better than a policy document describing traffic in the abstract.

512
00:27:43,240 --> 00:27:47,640
That feedback has nowhere to go if the platform team already packed up and moved on.

513
00:27:47,640 --> 00:27:50,120
The loop only works if both sides are still in the room.

514
00:27:50,120 --> 00:27:52,280
And here's exactly what happens when they're not.

515
00:27:52,280 --> 00:27:55,080
Platform engineers ship the landing zone, call it done,

516
00:27:55,080 --> 00:27:57,160
and shift their attention elsewhere.

517
00:27:57,160 --> 00:27:58,680
From there side, the job is complete.

518
00:27:58,680 --> 00:28:01,960
The structure exists, the policies are attached, box checked.

519
00:28:01,960 --> 00:28:04,120
Except nobody has actually run a workload through it yet.

520
00:28:04,120 --> 00:28:07,240
So nobody has found the gaps or the awkward permission boundaries.

521
00:28:07,240 --> 00:28:10,360
Nobody found the policy that blocks a legitimate use case

522
00:28:10,360 --> 00:28:12,120
because nobody thought to test for it.

523
00:28:12,120 --> 00:28:14,520
Six months later, a workload team hits that wall.

524
00:28:14,520 --> 00:28:17,160
And there's no one left who considers it their problem to fix.

525
00:28:17,160 --> 00:28:19,240
The workload team didn't build the landing zone

526
00:28:19,240 --> 00:28:21,160
so they don't feel empowered to change it.

527
00:28:21,160 --> 00:28:24,840
The platform team already moved on, so they don't feel responsible for touching it again.

528
00:28:24,840 --> 00:28:26,040
That's not a technical gap.

529
00:28:26,040 --> 00:28:27,160
That's an ownership gap.

530
00:28:27,160 --> 00:28:30,280
It's the same shape as the accountability problem we just looked at.

531
00:28:30,280 --> 00:28:32,040
It's just showing up one layer down.

532
00:28:32,040 --> 00:28:36,120
The fix isn't complicated to describe even if it takes discipline to hold on to.

533
00:28:36,120 --> 00:28:37,320
Shared responsibility.

534
00:28:37,320 --> 00:28:38,760
Designs get built together.

535
00:28:38,760 --> 00:28:41,880
Platform and workload people stay in the same conversation.

536
00:28:41,880 --> 00:28:44,200
You stop one side from finishing their piece

537
00:28:44,200 --> 00:28:47,080
and lobbing it over a wall for the other side to deal with.

538
00:28:47,080 --> 00:28:49,560
When a workload team pushes back on a policy

539
00:28:49,560 --> 00:28:51,560
that isn't friction to root around.

540
00:28:51,560 --> 00:28:55,000
That is the exact signal the landing zone needs to actually improve.

541
00:28:55,000 --> 00:28:57,480
You have to treat it as data, not as a complaint.

542
00:28:57,480 --> 00:28:59,960
This maps directly onto Microsoft 365.

543
00:28:59,960 --> 00:29:03,320
The shape is identical even though the players have different job titles.

544
00:29:03,320 --> 00:29:05,240
Instead of platform and workload teams,

545
00:29:05,240 --> 00:29:08,440
you've got a champions network, IT and business ownership.

546
00:29:08,440 --> 00:29:10,200
The principle applies word for word.

547
00:29:10,200 --> 00:29:12,280
These groups need to work the loop continuously.

548
00:29:12,280 --> 00:29:14,440
They cannot hand off to each other in sequence.

549
00:29:14,440 --> 00:29:17,240
I can't build the tenant, declare the cutover complete

550
00:29:17,240 --> 00:29:19,400
and hand a stack of documentation to champions.

551
00:29:19,400 --> 00:29:21,800
They can't expect the champions to carry it from there.

552
00:29:21,800 --> 00:29:25,160
Champions can't operate in isolation from business ownership either.

553
00:29:25,160 --> 00:29:27,080
They need real workflows to anchor training around.

554
00:29:27,080 --> 00:29:30,520
They don't need generic modules built for nobody in particular.

555
00:29:30,520 --> 00:29:33,320
All three groups have to stay in the same ongoing conversation.

556
00:29:33,320 --> 00:29:37,080
It's the same way platform and workload teams do in the Azure version of this loop.

557
00:29:37,080 --> 00:29:39,320
The moment any one of them checks out early,

558
00:29:39,320 --> 00:29:41,480
you get the exact same empty landing zone problem.

559
00:29:41,480 --> 00:29:44,440
It's just wearing a share point site instead of a subscription.

560
00:29:44,440 --> 00:29:47,320
None of this works without training that actually changes behavior.

561
00:29:47,320 --> 00:29:49,080
It can't just be about awareness.

562
00:29:49,080 --> 00:29:51,320
Training is not awareness, it's behavior change.

563
00:29:51,320 --> 00:29:54,840
Let's be direct about something most companies fudge on their rollout slides.

564
00:29:54,840 --> 00:29:56,360
A luncheon learn is not training.

565
00:29:56,360 --> 00:29:59,800
Getting 40 people into a room for 30 minutes to watch a co-pilot demo

566
00:29:59,800 --> 00:30:02,920
while they eat a sandwich is just an announcement with catering.

567
00:30:02,920 --> 00:30:05,080
It builds awareness that a tool exists.

568
00:30:05,080 --> 00:30:07,960
But it does not build the skill to use it inside a real workflow.

569
00:30:07,960 --> 00:30:09,880
Those are two completely different outcomes.

570
00:30:09,880 --> 00:30:12,680
And yet, they keep getting reported as the same line item.

571
00:30:12,680 --> 00:30:15,800
Here is the pattern showing up across co-pilot rollouts right now.

572
00:30:15,800 --> 00:30:18,360
Licenses get pushed out to an entire department at once.

573
00:30:18,360 --> 00:30:20,680
Then the training gets reduced to a vendor demo.

574
00:30:20,680 --> 00:30:23,880
Someone from Microsoft or a partner walks through a polished set of slides

575
00:30:23,880 --> 00:30:25,240
and shows a few canned examples.

576
00:30:25,240 --> 00:30:27,880
They say some version of this will save you time.

577
00:30:27,880 --> 00:30:31,960
But there are no concrete examples tied to what that specific team actually does all day.

578
00:30:31,960 --> 00:30:34,440
There is no walkthrough using their real documents.

579
00:30:34,440 --> 00:30:36,600
They are real emails or real meeting notes.

580
00:30:36,600 --> 00:30:40,600
It is just a general promise that time will be saved once people figure it out on their own.

581
00:30:40,600 --> 00:30:42,600
The fix is almost embarrassingly simple.

582
00:30:42,600 --> 00:30:47,080
You have to define 5 to 7 high value use cases per business unit before you deploy.

583
00:30:47,080 --> 00:30:49,880
Don't say co-pilot can help with a lot of things.

584
00:30:49,880 --> 00:30:52,840
Instead, say, here are the 5 things it does for finance

585
00:30:52,840 --> 00:30:55,160
or here are the 5 things it does for legal.

586
00:30:55,160 --> 00:30:58,520
These must be concrete tasks that someone already does every single week.

587
00:30:58,520 --> 00:31:00,920
That is the difference between a demo and training.

588
00:31:00,920 --> 00:31:03,240
A demo shows you what is possible in general.

589
00:31:03,240 --> 00:31:08,040
Training shows you exactly what to do with the work you are already stuck doing on Tuesday afternoon.

590
00:31:08,040 --> 00:31:10,920
And here is a detail that changes how adoption actually spreads.

591
00:31:10,920 --> 00:31:13,160
Deploy co-pilot to teams, not individuals.

592
00:31:13,160 --> 00:31:16,920
When you hand out licenses one person at a time across an org chart,

593
00:31:16,920 --> 00:31:19,560
you leave everyone to figure it out alone at their desk.

594
00:31:19,560 --> 00:31:23,240
But when you deploy it to an intact team, social learning kicks in.

595
00:31:23,240 --> 00:31:25,720
Someone finds a prompt that works for a weekly report

596
00:31:25,720 --> 00:31:28,280
and the person sitting three seats over copies it.

597
00:31:28,280 --> 00:31:31,960
Peer validation drives real adoption better than any training deck ever will.

598
00:31:31,960 --> 00:31:36,520
People trust what they see their co-workers doing more than they trust a slide that says it should work.

599
00:31:36,520 --> 00:31:39,160
There is one more piece that has to be built in as policy.

600
00:31:39,160 --> 00:31:41,800
It is what the research calls the review habit.

601
00:31:41,800 --> 00:31:43,880
Nobody should trust AI output blindly.

602
00:31:43,880 --> 00:31:46,520
This is not a nice to have you get to if you have extra time.

603
00:31:46,520 --> 00:31:47,960
It is a structural requirement.

604
00:31:47,960 --> 00:31:51,560
Just like MFA is a structural requirement and not an optional security tip.

605
00:31:51,560 --> 00:31:55,000
Every piece of co-pilot output must be checked by a human

606
00:31:55,000 --> 00:31:57,160
before it goes anywhere that matters.

607
00:31:57,160 --> 00:31:57,960
Every time.

608
00:31:57,960 --> 00:31:59,320
No exceptions for being in a hurry.

609
00:31:59,320 --> 00:32:01,720
If you skip that habit, you don't have an adoption problem.

610
00:32:01,720 --> 00:32:04,440
You have a governance failure with an AI logo on it.

611
00:32:04,440 --> 00:32:07,960
Now, here is where culture eats every framework alive if you let it.

612
00:32:07,960 --> 00:32:10,200
Culture and mental models.

613
00:32:10,200 --> 00:32:11,720
The layer frameworks ignore.

614
00:32:11,720 --> 00:32:14,360
Microsoft makes an admission in its own adoption guidance

615
00:32:14,360 --> 00:32:16,920
that is more honest than most companies are willing to be.

616
00:32:16,920 --> 00:32:20,040
Adoption fails when organizations focus on visible events

617
00:32:20,040 --> 00:32:22,200
and ignore culture and mental models.

618
00:32:22,200 --> 00:32:24,520
It doesn't fail because the tool is broken.

619
00:32:24,520 --> 00:32:26,440
It doesn't fail because training was skipped.

620
00:32:26,440 --> 00:32:31,000
It fails because leadership spends all its energy on the launch and the announcement.

621
00:32:31,000 --> 00:32:33,800
But never touches the actual thing sitting underneath it.

622
00:32:33,800 --> 00:32:36,440
They never touch how people think work is supposed to happen.

623
00:32:36,440 --> 00:32:37,880
Let's make that concrete.

624
00:32:37,880 --> 00:32:41,400
Mental models sounds abstract until you watch it play out in a real inbox.

625
00:32:41,400 --> 00:32:45,240
People have spent decades thinking about work in terms of email and shared drives.

626
00:32:45,240 --> 00:32:48,120
If someone needs a decision, they email the person who can make it.

627
00:32:48,120 --> 00:32:51,480
If someone finishes a document, they save it to a drive and email a link.

628
00:32:51,480 --> 00:32:53,000
At this point, that is not a habit.

629
00:32:53,000 --> 00:32:53,960
It is an instinct.

630
00:32:53,960 --> 00:32:56,440
So when teams shows up, it does not replace that instinct.

631
00:32:56,440 --> 00:32:57,880
It just gets absorbed into it.

632
00:32:57,880 --> 00:32:59,240
Teams becomes chat.

633
00:32:59,240 --> 00:33:01,880
A slightly faster way to ping someone instead of emailing them.

634
00:33:01,880 --> 00:33:04,840
Meanwhile, the actual decision still happens in someone's inbox.

635
00:33:04,840 --> 00:33:09,000
Nothing about where authority lives or how information moves has actually changed.

636
00:33:09,000 --> 00:33:11,720
You have a new interface sitting on top of an old assumption.

637
00:33:11,720 --> 00:33:15,240
And the old assumption always wins if nobody challenges it directly.

638
00:33:15,240 --> 00:33:18,600
This is why quick wins and cherry-pick pilots don't fix the actual problem.

639
00:33:18,600 --> 00:33:21,160
You can run a pilot with one enthusiastic team

640
00:33:21,160 --> 00:33:23,400
and get them using teams channels beautifully.

641
00:33:23,400 --> 00:33:26,040
You can show a slide with a nice usage chart and call it proof.

642
00:33:26,040 --> 00:33:28,920
But a pilot like that does not touch how the rest of the organization

643
00:33:28,920 --> 00:33:30,120
thinks about ownership.

644
00:33:30,120 --> 00:33:32,520
It does not change the assumption about transparency

645
00:33:32,520 --> 00:33:34,920
or where information is supposed to live by default.

646
00:33:34,920 --> 00:33:37,160
It is just one team performing well inside a system

647
00:33:37,160 --> 00:33:39,240
that everyone else is still quietly ignoring.

648
00:33:39,240 --> 00:33:42,600
Cherry picking a good result is not the same as changing the underlying belief

649
00:33:42,600 --> 00:33:44,600
that produced the bad ones everywhere else.

650
00:33:44,600 --> 00:33:49,240
This is the moment where the model earns its place as the core idea of this episode.

651
00:33:49,240 --> 00:33:51,160
You can install every single tool correctly.

652
00:33:51,160 --> 00:33:53,800
You can activate the licenses, provision the sites,

653
00:33:53,800 --> 00:33:55,000
and configure the permissions.

654
00:33:55,000 --> 00:33:57,480
You can schedule the training and name the champions.

655
00:33:57,480 --> 00:33:59,080
And you can still fail completely

656
00:33:59,080 --> 00:34:01,960
because the underlying assumption about how people actually work

657
00:34:01,960 --> 00:34:03,000
never got challenged.

658
00:34:03,000 --> 00:34:04,360
The tools were never the obstacle.

659
00:34:04,360 --> 00:34:06,920
The obstacle was always the belief sitting underneath them

660
00:34:06,920 --> 00:34:09,880
and beliefs do not update just because the software around them did.

661
00:34:09,880 --> 00:34:11,800
Think back to the roundabout one last time.

662
00:34:11,800 --> 00:34:14,200
The structure was never the problem. Roundabouts work.

663
00:34:14,200 --> 00:34:16,440
They are a genuinely better system than a traffic light

664
00:34:16,440 --> 00:34:19,560
with someone standing in the middle, directing every car by hand.

665
00:34:19,560 --> 00:34:21,480
The problem was the missing instructions.

666
00:34:21,480 --> 00:34:24,040
It was the assumption that people would just look at the new structure

667
00:34:24,040 --> 00:34:25,640
and understand it without being taught how.

668
00:34:25,640 --> 00:34:27,240
M365 is the same shape.

669
00:34:27,240 --> 00:34:28,520
The platform works.

670
00:34:28,520 --> 00:34:29,560
Teams works.

671
00:34:29,560 --> 00:34:30,760
SharePoint works.

672
00:34:30,760 --> 00:34:32,120
Co-pilot works.

673
00:34:32,120 --> 00:34:33,160
What is missing?

674
00:34:33,160 --> 00:34:36,440
Every single time this fails is someone actually teaching the organization

675
00:34:36,440 --> 00:34:38,920
the new rules for how information is supposed to move.

676
00:34:38,920 --> 00:34:40,840
You cannot assume the interface will explain itself.

677
00:34:40,840 --> 00:34:42,520
So does that mean we scrapped the framework?

678
00:34:42,520 --> 00:34:43,160
No.

679
00:34:43,160 --> 00:34:44,600
Here is what it is actually for.

680
00:34:44,600 --> 00:34:47,160
The framework still works, but only as a guide.

681
00:34:47,160 --> 00:34:51,000
Let's be honest about what CAF and the M365 adoption guide actually are.

682
00:34:51,000 --> 00:34:52,680
Everything we've walked through so far

683
00:34:52,680 --> 00:34:55,000
could sound like an argument to throw them both out.

684
00:34:55,000 --> 00:34:56,040
But that's not the point.

685
00:34:56,040 --> 00:34:59,000
These are proven, battle-tested pieces of guidance.

686
00:34:59,000 --> 00:35:02,600
Built from thousands of real deployments across companies of every size.

687
00:35:02,600 --> 00:35:05,560
They aren't wrong, but they aren't a single truth either.

688
00:35:05,560 --> 00:35:07,560
And that distinction matters more than it sounds.

689
00:35:07,560 --> 00:35:10,840
The right posture to what all of it is the same phrase we used for landing zones.

690
00:35:10,840 --> 00:35:12,120
One size fits none.

691
00:35:12,120 --> 00:35:13,720
That isn't a criticism of the framework.

692
00:35:13,720 --> 00:35:15,320
It's an instruction for how to use it.

693
00:35:15,320 --> 00:35:17,000
You take the structure Microsoft built,

694
00:35:17,000 --> 00:35:20,360
and you adapt it hard to your own org's actual size and actual maturity.

695
00:35:20,360 --> 00:35:21,960
Not the maturity you wish you had.

696
00:35:21,960 --> 00:35:24,200
Or the one a CAF study assumed you'd have.

697
00:35:24,200 --> 00:35:25,240
Applied is written.

698
00:35:25,240 --> 00:35:26,200
Without adjustment.

699
00:35:26,200 --> 00:35:27,880
It fits almost nobody perfectly.

700
00:35:27,880 --> 00:35:29,080
Adjusted with intention.

701
00:35:29,080 --> 00:35:30,840
It fits almost everybody well enough.

702
00:35:30,840 --> 00:35:32,280
But here's the problem.

703
00:35:32,280 --> 00:35:37,400
A small company with 30 employees does not need the full enterprise-scale landing zone.

704
00:35:37,400 --> 00:35:39,080
With every management group and policy tier,

705
00:35:39,080 --> 00:35:41,960
the framework describes for a 5,000 person organization

706
00:35:41,960 --> 00:35:43,720
building all of that anyway isn't thoroughness.

707
00:35:43,720 --> 00:35:46,680
It's over-engineering, wearing the costume of best practice.

708
00:35:46,680 --> 00:35:51,400
And it costs that small company real-time and real confusion for protection it doesn't need yet.

709
00:35:51,400 --> 00:35:56,040
Meanwhile, a large enterprise that skips that same rigor because it seems like overkill

710
00:35:56,040 --> 00:36:00,440
is skipping the exact governance that keeps the company at size from quietly falling apart.

711
00:36:00,440 --> 00:36:04,760
What looks suffocating at 30 people is basic hygiene at 5,000.

712
00:36:04,760 --> 00:36:06,520
The framework doesn't fail either company.

713
00:36:06,520 --> 00:36:09,000
Applying it without adjusting for scale does.

714
00:36:09,000 --> 00:36:11,160
There's a smaller detail worth sitting with here.

715
00:36:11,160 --> 00:36:14,040
Because it says something about the framework's own trajectory.

716
00:36:14,040 --> 00:36:17,560
The documentation itself used to run about 3,600 pages,

717
00:36:17,560 --> 00:36:19,640
but it's roughly 1,300 now.

718
00:36:19,640 --> 00:36:22,840
That isn't because the guidance got worse or thinner in substance.

719
00:36:22,840 --> 00:36:27,240
It's because the people maintaining it got more disciplined about what actually needed to be said.

720
00:36:27,240 --> 00:36:32,120
And even at 1,300 pages, nobody's realistically reading that cover to cover

721
00:36:32,120 --> 00:36:34,920
before they touch a single resource nobody's expected to.

722
00:36:34,920 --> 00:36:37,480
So here's the honest use case stated plainly.

723
00:36:37,480 --> 00:36:38,920
Use it as a map for direction.

724
00:36:38,920 --> 00:36:42,200
Not a rulebook you follow line by line expecting a perfect outcome

725
00:36:42,200 --> 00:36:43,800
if you just comply closely enough.

726
00:36:43,800 --> 00:36:45,400
A map tells you where north is.

727
00:36:45,400 --> 00:36:47,480
It doesn't walk every step of the road for you.

728
00:36:47,480 --> 00:36:51,560
And it definitely doesn't know your specific terrain better than you do once you're standing on it.

729
00:36:51,560 --> 00:36:55,320
So if you're starting from scratch or you're fixing a rollout that's already broken.

730
00:36:55,320 --> 00:36:57,080
Here's the sequence that actually holds up.

731
00:36:57,080 --> 00:36:58,840
M&A and systemic integration.

732
00:36:58,840 --> 00:37:00,520
Where this gets tested hardest.

733
00:37:00,520 --> 00:37:03,800
There's one place where everything we've talked about stops being theoretical

734
00:37:03,800 --> 00:37:06,200
and starts showing up directly on a balance sheet.

735
00:37:06,200 --> 00:37:07,320
Mergers and acquisitions.

736
00:37:07,320 --> 00:37:12,120
When two companies combine and their M365 environments have to become one.

737
00:37:12,120 --> 00:37:15,800
Every structural weakness we've walked through gets tested at the same time.

738
00:37:15,800 --> 00:37:18,680
Under a deadline with money attached to the outcome.

739
00:37:18,680 --> 00:37:22,120
Post-merger integration is where structural adoption failure stops being a slow,

740
00:37:22,120 --> 00:37:23,720
quiet drag on productivity.

741
00:37:23,720 --> 00:37:26,520
And turns into a number someone in finance has to explain.

742
00:37:26,520 --> 00:37:29,320
The research on this breaks measurement into three domains.

743
00:37:29,320 --> 00:37:30,840
It's worth naming all three.

744
00:37:30,840 --> 00:37:33,000
Because most integration teams only track one.

745
00:37:33,000 --> 00:37:34,920
First, there's technical integration health.

746
00:37:34,920 --> 00:37:37,800
Did the tenants, the identities and the data actually merge cleanly?

747
00:37:37,800 --> 00:37:41,000
Second, there's user adoption and behavior change.

748
00:37:41,000 --> 00:37:43,960
Are people from both companies actually working the new way?

749
00:37:43,960 --> 00:37:46,760
Or are they still quietly running two separate systems side-by-side

750
00:37:46,760 --> 00:37:48,440
because nobody forced the decision?

751
00:37:48,440 --> 00:37:51,000
And third, there's business synergies and risk.

752
00:37:51,000 --> 00:37:54,520
Is any of this technical and behavioral work translating into the financial outcome

753
00:37:54,520 --> 00:37:57,320
the deal was actually built to produce track only the first one?

754
00:37:57,320 --> 00:38:00,680
And you'll have a beautifully merged tenant that nobody's using correctly.

755
00:38:00,680 --> 00:38:01,880
Track only the second.

756
00:38:01,880 --> 00:38:06,360
And you'll have happy users with no idea whether the merger is actually paying for itself.

757
00:38:06,360 --> 00:38:09,000
Here's a detail from that research that deserves to be said plainly.

758
00:38:09,000 --> 00:38:11,640
It's a gut check for anyone who assumes a migration when fine,

759
00:38:11,640 --> 00:38:12,840
just because nobody complained.

760
00:38:13,400 --> 00:38:17,480
20 to 30% of migrated records typically need some kind of remediation after the fact.

761
00:38:17,480 --> 00:38:19,800
That isn't a failure, that's the expected range.

762
00:38:19,800 --> 00:38:24,680
Duplicate entries, broken metadata, permissions that didn't map cleanly from one system to the other.

763
00:38:24,680 --> 00:38:28,200
This is just the normal friction of moving real data between real environments.

764
00:38:28,200 --> 00:38:32,600
But once that number climbs above 40%, you're not looking at normal friction anymore.

765
00:38:32,600 --> 00:38:34,760
You're looking at a migration that got rushed,

766
00:38:34,760 --> 00:38:36,760
where corners got cut to hit a deadline.

767
00:38:36,760 --> 00:38:39,880
And the cleanup bill is going to land on someone's desk eventually.

768
00:38:39,880 --> 00:38:43,880
And this is where the financial expectations get set wrong almost every time.

769
00:38:43,880 --> 00:38:47,880
Revenue synergies, the actual new value the combined company is supposed to generate

770
00:38:47,880 --> 00:38:50,120
like costs synergies by 6 to 12 months.

771
00:38:50,120 --> 00:38:51,560
Cost savings show up fast.

772
00:38:51,560 --> 00:38:55,480
Cutting duplicate licenses and shutting down redundant systems is mechanical work.

773
00:38:55,480 --> 00:38:57,800
But revenue growth from better collaboration.

774
00:38:57,800 --> 00:38:59,000
Faster deal cycles.

775
00:38:59,000 --> 00:39:01,480
And shared customer data actually being used well.

776
00:39:01,480 --> 00:39:04,040
That takes people time to build into their daily behavior.

777
00:39:04,040 --> 00:39:06,920
So if leadership is only measuring results in the first 100 days,

778
00:39:06,920 --> 00:39:09,720
they're measuring the part of the story that was always going to look good.

779
00:39:09,720 --> 00:39:13,160
And they are completely missing the part that actually proves the deal worked.

780
00:39:13,160 --> 00:39:15,800
This is the lesson worth carrying past M&A entirely.

781
00:39:15,800 --> 00:39:19,400
It applies to any org running any kind of structural integration, merger or not.

782
00:39:19,400 --> 00:39:24,600
This kind of change takes longer to show real value than leadership wants to admit.

783
00:39:24,600 --> 00:39:25,960
And that isn't a problem to solve.

784
00:39:25,960 --> 00:39:27,480
That's just the honest timeline.

785
00:39:27,480 --> 00:39:28,840
The fix isn't rushing the number.

786
00:39:28,840 --> 00:39:31,160
It's setting the expectation correctly upfront.

787
00:39:31,160 --> 00:39:34,440
It's telling the people funding this that month three will look different from month 12.

788
00:39:34,440 --> 00:39:37,160
Judging the whole effort by the early numbers alone

789
00:39:37,160 --> 00:39:41,080
is how good integrations get killed before they had a chance to prove themselves.

790
00:39:41,080 --> 00:39:44,760
Let's pull this together into what you actually do Monday morning.

791
00:39:44,760 --> 00:39:47,800
The governance first sequence that actually prevents failure.

792
00:39:47,800 --> 00:39:49,320
So here's what you actually do.

793
00:39:49,320 --> 00:39:50,360
It is a sequence.

794
00:39:50,360 --> 00:39:53,160
And the order matters because it has to hold up under pressure.

795
00:39:53,160 --> 00:39:54,600
Governance ordered first.

796
00:39:54,600 --> 00:39:57,640
Not after the rollout, not as a cleanup project six months later

797
00:39:57,640 --> 00:39:59,800
when the sprawl becomes impossible to ignore.

798
00:39:59,800 --> 00:40:03,640
You need to answer four unglamorous questions before you build a single workload.

799
00:40:03,640 --> 00:40:05,640
First, where does identity come from?

800
00:40:05,640 --> 00:40:09,480
Is it one clean source or five systems stitched together with duct tape?

801
00:40:09,480 --> 00:40:11,480
Second, who holds admin roles right now?

802
00:40:11,480 --> 00:40:13,960
And can anyone actually explain why they have that access?

803
00:40:13,960 --> 00:40:16,760
Third, what is your default sharing posture?

804
00:40:16,760 --> 00:40:21,160
Is it locked down or is it wide open because nobody changed the Microsoft default settings?

805
00:40:21,160 --> 00:40:23,080
Fourth, what are your retention assumptions?

806
00:40:23,080 --> 00:40:25,480
Are they written down or are they just vibes and hope?

807
00:40:25,480 --> 00:40:27,560
If you answer those four questions honestly,

808
00:40:27,560 --> 00:40:30,520
you avoid the mistake that catches most companies from there.

809
00:40:30,520 --> 00:40:32,440
Security requirements are not negotiable.

810
00:40:32,440 --> 00:40:34,120
They are not complicated either.

811
00:40:34,120 --> 00:40:36,040
Which is why skipping them is hard to excuse.

812
00:40:36,040 --> 00:40:37,160
MFA everywhere.

813
00:40:37,160 --> 00:40:39,640
No carve-outs for the executive who finds it annoying.

814
00:40:39,640 --> 00:40:42,360
Conditional access rules that check device health and location.

815
00:40:42,360 --> 00:40:43,480
Not just a password.

816
00:40:43,480 --> 00:40:44,680
Roll separation.

817
00:40:44,680 --> 00:40:47,320
The person who approves the policy should not be the same person

818
00:40:47,320 --> 00:40:49,320
that policy is supposed to constrain.

819
00:40:49,320 --> 00:40:51,720
And classification tied to actual record categories.

820
00:40:51,720 --> 00:40:54,600
Your labels need to match real data your company handles.

821
00:40:54,600 --> 00:40:56,600
Not a generic template nobody customized.

822
00:40:56,600 --> 00:40:57,560
This is the floor.

823
00:40:57,560 --> 00:40:58,600
Not the ambition.

824
00:40:58,600 --> 00:40:59,560
The floor.

825
00:40:59,560 --> 00:41:00,760
Once that is solid,

826
00:41:00,760 --> 00:41:02,520
build the operating model before you scale.

827
00:41:02,520 --> 00:41:03,480
Who owns what?

828
00:41:03,480 --> 00:41:04,440
Spelled out by name.

829
00:41:04,440 --> 00:41:05,560
Not by department.

830
00:41:05,560 --> 00:41:08,120
Which group actually approves a new service request?

831
00:41:08,120 --> 00:41:11,000
You need this so it doesn't turn into a three week scheduling nightmare

832
00:41:11,000 --> 00:41:12,680
where use cases just stall out.

833
00:41:12,680 --> 00:41:15,320
What is the escalation path look like when something breaks?

834
00:41:15,320 --> 00:41:17,960
And who is empowered to say yes or no on the spot?

835
00:41:17,960 --> 00:41:19,480
Instead of promising to circle back?

836
00:41:19,480 --> 00:41:22,600
Only after all of that is sitting on solid ground,

837
00:41:22,600 --> 00:41:25,400
do you move to the part everyone wants to start with?

838
00:41:25,400 --> 00:41:26,520
Define use cases.

839
00:41:26,520 --> 00:41:27,800
Assign champions.

840
00:41:27,800 --> 00:41:29,960
Build a training curriculum around the workflows

841
00:41:29,960 --> 00:41:31,720
people actually run every day.

842
00:41:31,720 --> 00:41:34,040
The ordering matters more than it looks like on paper.

843
00:41:34,040 --> 00:41:37,640
Because skipping straight to use cases without the governance underneath

844
00:41:37,640 --> 00:41:40,040
is how you end up with enthusiastic pilot teams

845
00:41:40,040 --> 00:41:41,960
sitting on top of an ungoverned mess.

846
00:41:41,960 --> 00:41:45,240
And this is worth tying back to something Barbara Forbes said about policy.

847
00:41:45,240 --> 00:41:46,920
It applies just as hard here.

848
00:41:46,920 --> 00:41:49,320
Policies are not a set it and forget it task.

849
00:41:49,320 --> 00:41:51,560
Most companies land in one of two failure modes.

850
00:41:51,560 --> 00:41:55,000
Two few policies so there is no structure or too many policies.

851
00:41:55,000 --> 00:41:58,760
Layered on top of each other until nobody knows what is actually enforced.

852
00:41:58,760 --> 00:42:00,680
Either way, the maintenance stops.

853
00:42:00,680 --> 00:42:01,880
Someone writes the policy.

854
00:42:01,880 --> 00:42:04,760
Feels good about it and never opens that document again.

855
00:42:04,760 --> 00:42:07,560
Governance that isn't revisited isn't governance.

856
00:42:07,560 --> 00:42:08,760
It's an artifact.

857
00:42:08,760 --> 00:42:12,440
And once governance holds, here is how you know if adoption is actually working.

858
00:42:12,440 --> 00:42:14,760
Building your actual scorecard.

859
00:42:14,760 --> 00:42:15,880
Here is the scorecard.

860
00:42:15,880 --> 00:42:17,560
It is laid out in three layers.

861
00:42:17,560 --> 00:42:18,760
And none of them work alone.

862
00:42:18,760 --> 00:42:20,520
That is the whole point of building it this way.

863
00:42:20,520 --> 00:42:22,200
The structural layer comes first.

864
00:42:22,200 --> 00:42:24,840
It tells you if the foundation can actually hold weight.

865
00:42:24,840 --> 00:42:25,800
Training completion.

866
00:42:25,800 --> 00:42:26,600
The real number.

867
00:42:26,600 --> 00:42:27,880
Not training was offered.

868
00:42:27,880 --> 00:42:29,800
But what percentage of people actually finished it?

869
00:42:30,520 --> 00:42:32,440
Survey sentiment, pulled it intervals.

870
00:42:32,440 --> 00:42:34,840
Not just once at launch when everyone is still excited.

871
00:42:34,840 --> 00:42:35,720
Champion activity.

872
00:42:35,720 --> 00:42:39,160
Are the people assigned to carry this into their teams actually showing up?

873
00:42:39,160 --> 00:42:41,720
Or did that title stop meaning anything after week two?

874
00:42:41,720 --> 00:42:45,640
And ticket trends are the same confused questions landing in the queue six months out?

875
00:42:45,640 --> 00:42:48,680
Or have they tapered off because people actually learned the system?

876
00:42:48,680 --> 00:42:50,120
The usage layer sits on top of that.

877
00:42:50,120 --> 00:42:52,040
This is where most companies start and stop.

878
00:42:52,040 --> 00:42:55,320
Which is exactly the mistake we spent the last several sections dismantling.

879
00:42:55,320 --> 00:42:57,480
MAU by workload do not lump teams.

880
00:42:57,480 --> 00:42:58,200
SharePoint.

881
00:42:58,200 --> 00:42:59,640
And one drive into one number.

882
00:42:59,640 --> 00:43:02,280
A spike in one can hide a total collapse in another.

883
00:43:02,280 --> 00:43:04,200
FeatureDepth matters more than log-in counts.

884
00:43:04,200 --> 00:43:08,280
Someone opening teams once a day to check a notification is not the same as someone actually

885
00:43:08,280 --> 00:43:10,840
running meetings and co-authoring documents.

886
00:43:10,840 --> 00:43:12,360
And co-pilot prompt frequency.

887
00:43:12,360 --> 00:43:13,320
Paired with satisfaction.

888
00:43:13,320 --> 00:43:14,840
Do not report these alone.

889
00:43:14,840 --> 00:43:18,120
A high prompt count from someone who hates the output isn't adoption.

890
00:43:18,120 --> 00:43:19,640
It's frustration with extra steps.

891
00:43:19,640 --> 00:43:22,520
The outcome layer is the one almost nobody builds.

892
00:43:22,520 --> 00:43:25,480
And it is the one that actually matters to the people funding this.

893
00:43:25,480 --> 00:43:29,240
Cycle time reduction is a process that used to take four days now taking two

894
00:43:29,240 --> 00:43:31,560
times saved, measured against a real baseline,

895
00:43:31,560 --> 00:43:33,640
not a vendor's estimate of what should be possible.

896
00:43:33,640 --> 00:43:38,440
Resolution speed for support tickets, customer requests, or internal approvals.

897
00:43:38,440 --> 00:43:42,360
Every single one of these has to tie back to a real business KPI.

898
00:43:42,360 --> 00:43:45,000
Something leadership already tracks and already cares about.

899
00:43:45,000 --> 00:43:48,360
Not a vanity metric invented to make the rollout look good on a slide.

900
00:43:48,360 --> 00:43:50,680
Here is the rule that ties all three layers together.

901
00:43:50,680 --> 00:43:53,880
It is the one thing worth writing down if you remember nothing else.

902
00:43:53,880 --> 00:43:55,560
Never trust one layer alone.

903
00:43:55,560 --> 00:43:57,160
A structural layer that looks great.

904
00:43:57,160 --> 00:43:58,840
With a usage layer that is flat.

905
00:43:58,840 --> 00:44:01,560
Means people are trained and happy and still not using the thing.

906
00:44:01,560 --> 00:44:03,160
That is its own kind of failure.

907
00:44:03,160 --> 00:44:06,760
A usage layer that is climbing with an outcome layer that is flat

908
00:44:06,760 --> 00:44:08,360
is the most dangerous combination of all.

909
00:44:08,360 --> 00:44:11,640
It looks like success everywhere except in the place that actually counts.

910
00:44:11,640 --> 00:44:14,040
Rising usage with flat outcomes is not a win.

911
00:44:14,040 --> 00:44:15,080
It is a warning sign.

912
00:44:15,080 --> 00:44:17,880
It is dressed up in a chart that goes up and to the right.

913
00:44:17,880 --> 00:44:21,320
And it is exactly the kind of number that gets celebrated in a leadership meeting

914
00:44:21,320 --> 00:44:23,480
while the actual problem sits there unnoticed.

915
00:44:23,480 --> 00:44:25,800
Let's bring this back to the one sentence that matters most.

916
00:44:26,600 --> 00:44:28,120
The real transformation.

917
00:44:28,120 --> 00:44:29,560
Nobody puts on a slide.

918
00:44:29,560 --> 00:44:31,320
Strip away the framework diagrams.

919
00:44:31,320 --> 00:44:33,000
Forget the governance checklists.

920
00:44:33,000 --> 00:44:35,320
Here is the one sentence that actually matters.

921
00:44:35,320 --> 00:44:36,840
The framework was never the point.

922
00:44:36,840 --> 00:44:39,560
The model behind how your organization assumes people work.

923
00:44:39,560 --> 00:44:40,520
That is the point.

924
00:44:40,520 --> 00:44:42,360
It has been the point this entire episode.

925
00:44:42,360 --> 00:44:45,720
Even when we were deep in the weeds talking about landing zones and russy charts.

926
00:44:45,720 --> 00:44:47,480
Let's take one last pass at the roundabout.

927
00:44:47,480 --> 00:44:48,920
This time it's not a metaphor.

928
00:44:48,920 --> 00:44:50,840
It's the reality of your environment.

929
00:44:50,840 --> 00:44:51,640
The structure works.

930
00:44:51,640 --> 00:44:56,120
Roundabouts move more traffic with less waiting than a cop standing in an intersection.

931
00:44:56,120 --> 00:44:56,920
Ever could.

932
00:44:56,920 --> 00:45:00,680
Teams, SharePoint and Copilot are built on that same logic.

933
00:45:00,680 --> 00:45:01,960
Freedom with guardrails.

934
00:45:01,960 --> 00:45:04,440
Instead of someone manually approving every single move.

935
00:45:04,440 --> 00:45:08,440
But that structure only works for people who were actually taught how to enter it.

936
00:45:08,440 --> 00:45:09,720
They have to know how to yield.

937
00:45:09,720 --> 00:45:12,280
They have to know how to merge without causing a pile-up.

938
00:45:12,280 --> 00:45:14,280
Nobody is born knowing how to use a roundabout.

939
00:45:14,280 --> 00:45:17,960
And nobody is born knowing that a team needs an owner and an expiration date.

940
00:45:17,960 --> 00:45:20,360
Both of those things have to be taught deliberately.

941
00:45:20,360 --> 00:45:24,200
Or the structure just becomes a more elegant way to create the exact same confusion.

942
00:45:24,200 --> 00:45:26,920
Here is why this matters more right now than it did two years ago.

943
00:45:26,920 --> 00:45:28,680
Copilot does not fix a broken model.

944
00:45:28,680 --> 00:45:31,480
It just moves faster through whatever model already exists.

945
00:45:31,480 --> 00:45:33,160
If your organization has clear ownership,

946
00:45:33,160 --> 00:45:35,640
Copilot multiplies the good version of how you work.

947
00:45:35,640 --> 00:45:37,240
But if ownership is already fuzzy,

948
00:45:37,240 --> 00:45:40,840
if nobody can tell you who owns a site or why a workload move to the cloud,

949
00:45:40,840 --> 00:45:42,840
Copilot does not slow down to wait for you.

950
00:45:42,840 --> 00:45:45,080
It just runs the dysfunction at a higher speed.

951
00:45:45,080 --> 00:45:46,680
Bad hand-off skates are automated.

952
00:45:46,680 --> 00:45:49,160
Unclear approvals get skipped instead of clarified.

953
00:45:49,160 --> 00:45:52,760
Whatever gap existed before AI finds it and drives straight through it.

954
00:45:52,760 --> 00:45:53,800
That is the stake.

955
00:45:53,800 --> 00:45:55,480
State it as plain as I can put it.

956
00:45:55,480 --> 00:45:58,120
The organizations that fix the model now are the ones who will survive.

957
00:45:58,120 --> 00:46:00,600
They are the ones who actually assign ownership,

958
00:46:00,600 --> 00:46:02,520
who actually build the operating model.

959
00:46:02,520 --> 00:46:06,680
And who actually teach people the new rules instead of assuming the interface will explain itself.

960
00:46:06,680 --> 00:46:09,560
Those companies will absorb the next wave of AI change

961
00:46:09,560 --> 00:46:11,400
without living through another failed rollout.

962
00:46:11,400 --> 00:46:14,600
Everyone else is going to keep doing the same exercise every 18 months.

963
00:46:14,600 --> 00:46:18,200
New tool, same governance gaps, same accountability confusion,

964
00:46:18,200 --> 00:46:20,360
just a different logo on the announcement email.

965
00:46:20,360 --> 00:46:22,520
So what do you actually do with this on Monday?

966
00:46:22,520 --> 00:46:24,120
Here is what you are walking away with.

967
00:46:24,120 --> 00:46:27,640
You now know why adoption fails structurally, not just technically.

968
00:46:27,640 --> 00:46:29,880
You know what actually predicts success in the data.

969
00:46:29,880 --> 00:46:31,640
Governance built before rollout.

970
00:46:31,640 --> 00:46:33,880
Accountability that is named instead of assumed.

971
00:46:33,880 --> 00:46:37,800
Matrix that measure all three layers instead of just the one that looks best on a slide.

972
00:46:37,800 --> 00:46:39,240
So here is the actual homework.

973
00:46:39,240 --> 00:46:42,120
This week, ordered one workload's governance model, just one.

974
00:46:42,120 --> 00:46:45,160
Pick something running in your tenant right now and ask two questions.

975
00:46:45,160 --> 00:46:46,360
Who owns this?

976
00:46:46,360 --> 00:46:50,360
And could anyone in your organization actually explain why it moved to the cloud in the first place?

977
00:46:50,360 --> 00:46:53,640
If the answer to either one is silence, you have found where to start.

978
00:46:53,640 --> 00:46:56,120
If this changed how you think about your own rollout,

979
00:46:56,120 --> 00:46:58,520
follow me, Mirko Peters, on LinkedIn,

980
00:46:58,520 --> 00:47:00,360
send me your messiest adoption story.

981
00:47:00,360 --> 00:47:02,120
The one you would never put in a case study,

982
00:47:02,120 --> 00:47:03,480
it might be the next episode.

983
00:47:03,480 --> 00:47:04,840
And if you want more of this,

984
00:47:04,840 --> 00:47:06,840
leave a review, it helps more people find it.