Now Reading: How to Fix Bad Microsoft 365 Tenants with Practical Governance S…
-
01
How to Fix Bad Microsoft 365 Tenants with Practical Governance S…
1
00:00:00,000 –> 00:00:01,960
I’m not the most technical person in the room.
2
00:00:01,960 –> 00:00:03,280
I don’t write production code.
3
00:00:03,280 –> 00:00:04,840
I don’t tune infrastructure.
4
00:00:04,840 –> 00:00:07,640
But I spend time inside large Microsoft environments,
5
00:00:07,640 –> 00:00:10,440
the kind where thousands of people collaborate daily,
6
00:00:10,440 –> 00:00:12,600
where financial transactions flow through teams,
7
00:00:12,600 –> 00:00:14,680
where compliance auditors show up asking questions
8
00:00:14,680 –> 00:00:16,120
about who can access what.
9
00:00:16,120 –> 00:00:17,240
And here’s what I’ve learned.
10
00:00:17,240 –> 00:00:20,160
The biggest problems I see are never technical problems.
11
00:00:20,160 –> 00:00:21,560
They’re governance problems.
12
00:00:21,560 –> 00:00:23,200
Technology rarely fails.
13
00:00:23,200 –> 00:00:25,120
Organizations fail to structure it.
14
00:00:25,120 –> 00:00:27,880
Most people think Microsoft 365 is email, teams,
15
00:00:27,880 –> 00:00:30,080
SharePoint and OneDrive stitch together.
16
00:00:30,080 –> 00:00:31,360
It’s not. At enterprise scale,
17
00:00:31,360 –> 00:00:34,480
it’s the operating system for how your organization actually works.
18
00:00:34,480 –> 00:00:37,120
And when you treat an operating system like a tool collection,
19
00:00:37,120 –> 00:00:39,240
things break in ways that are hard to see coming.
20
00:00:39,240 –> 00:00:41,160
This confession isn’t a blame exercise.
21
00:00:41,160 –> 00:00:42,880
The engineers in these stories were brilliant.
22
00:00:42,880 –> 00:00:45,840
The problem is that brilliance applied to the wrong problem
23
00:00:45,840 –> 00:00:48,360
creates systems that are technically perfect
24
00:00:48,360 –> 00:00:50,920
and operationally impossible.
25
00:00:50,920 –> 00:00:54,040
Redefining Microsoft 365 as an operating system.
26
00:00:54,040 –> 00:00:57,840
Let me start by reframing how we think about Microsoft 365 entirely.
27
00:00:57,840 –> 00:00:59,720
Most organizations see it this way.
28
00:00:59,720 –> 00:01:03,160
Email, real-time collaboration, file storage, identity management,
29
00:01:03,160 –> 00:01:06,680
separate tools, separate problems, separate governance models.
30
00:01:06,680 –> 00:01:08,120
But that’s not what it is anymore.
31
00:01:08,120 –> 00:01:11,040
Microsoft 365 is not a collection of applications.
32
00:01:11,040 –> 00:01:14,360
At enterprise scale, it is the operating system for how people work.
33
00:01:14,360 –> 00:01:15,960
Think about what an operating system does.
34
00:01:15,960 –> 00:01:17,480
It manages resources.
35
00:01:17,480 –> 00:01:19,360
It enforces access control.
36
00:01:19,360 –> 00:01:22,280
It orchestrates how different applications interact.
37
00:01:22,280 –> 00:01:24,240
It determines what runs, when it runs,
38
00:01:24,240 –> 00:01:27,200
who can see what output and what happens if something fails.
39
00:01:27,200 –> 00:01:29,480
That’s not a metaphor for Microsoft 365.
40
00:01:29,480 –> 00:01:30,800
That’s what it actually is.
41
00:01:30,800 –> 00:01:33,920
When you deploy teams, you’re not just installing a chat application.
42
00:01:33,920 –> 00:01:35,520
You’re deploying a communication layer
43
00:01:35,520 –> 00:01:38,240
that determines how information flows through your organization.
44
00:01:38,240 –> 00:01:41,520
When you deploy SharePoint, you’re not just building a file repository.
45
00:01:41,520 –> 00:01:43,880
You’re building the institutional memory system
46
00:01:43,880 –> 00:01:45,520
where knowledge lives, who can find it,
47
00:01:45,520 –> 00:01:47,920
how long it persists whether it’s protected or exposed.
48
00:01:47,920 –> 00:01:50,080
When you deploy Power Platform on top of that,
49
00:01:50,080 –> 00:01:51,840
you’re creating automation pathways
50
00:01:51,840 –> 00:01:55,160
that touch financial systems, customer data, compliance processes.
51
00:01:55,160 –> 00:01:56,800
You’re no longer just deploying tools.
52
00:01:56,800 –> 00:01:59,240
You’re architecting the nervous system of your organization.
53
00:01:59,240 –> 00:01:59,920
Here’s the problem.
54
00:01:59,920 –> 00:02:02,480
Most organizations understand this intellectually.
55
00:02:02,480 –> 00:02:04,280
They don’t internalize it operationally.
56
00:02:04,280 –> 00:02:06,720
A tenant starts small, a few teams.
57
00:02:06,720 –> 00:02:09,760
Some SharePoint sites, a Power Automate flow or two,
58
00:02:09,760 –> 00:02:12,840
because someone figured out they could automate a manual process.
59
00:02:12,840 –> 00:02:14,960
In year one, everything feels manageable.
60
00:02:14,960 –> 00:02:17,360
The technical team understands what exists.
61
00:02:17,360 –> 00:02:20,160
Governance is informal because the scope is small,
62
00:02:20,160 –> 00:02:21,800
then the organization grows.
63
00:02:21,800 –> 00:02:23,480
Or adoption accelerates.
64
00:02:23,480 –> 00:02:26,840
Or leadership decides everyone needs teams and modern collaboration.
65
00:02:26,840 –> 00:02:29,320
By year three, the tenant is unrecognizable.
66
00:02:29,320 –> 00:02:31,440
Thousands of teams with unclear ownership,
67
00:02:31,440 –> 00:02:33,680
SharePoint sites that nobody remembers creating.
68
00:02:33,680 –> 00:02:37,000
External sharing enabled in ways that were never explicitly decided.
69
00:02:37,000 –> 00:02:39,520
It just happened because defaults are permissive.
70
00:02:39,520 –> 00:02:41,640
Power Automate flows triggering other flows,
71
00:02:41,640 –> 00:02:44,720
independency chains that only one person understood.
72
00:02:44,720 –> 00:02:46,520
Sensitivity labels that nobody applies,
73
00:02:46,520 –> 00:02:48,800
retention policies that conflict with each other,
74
00:02:48,800 –> 00:02:51,560
guest accounts from partnerships that ended two years ago.
75
00:02:51,560 –> 00:02:55,000
Admin roles sprawled across 30 people who all have global admin access
76
00:02:55,000 –> 00:02:57,680
because it was easier than designing role-based controls.
77
00:02:57,680 –> 00:02:59,760
And then something breaks or an audit happens.
78
00:02:59,760 –> 00:03:02,320
Or a competitor data breach makes leadership nervous.
79
00:03:02,320 –> 00:03:04,920
The moment organizations believe they have a technical problem,
80
00:03:04,920 –> 00:03:07,440
is the moment they actually have an architectural problem.
81
00:03:07,440 –> 00:03:10,000
They call a consulting firm, they hire a technical lead,
82
00:03:10,000 –> 00:03:11,800
they invest in advanced security tools,
83
00:03:11,800 –> 00:03:14,800
they implement stricter policies, they build better automation.
84
00:03:14,800 –> 00:03:16,880
None of that fixes what’s actually broken.
85
00:03:16,880 –> 00:03:19,200
The real challenge isn’t understanding the technology.
86
00:03:19,200 –> 00:03:22,120
Microsoft 365 is well engineered, the controls exist,
87
00:03:22,120 –> 00:03:23,400
the documentation is thorough.
88
00:03:23,400 –> 00:03:26,440
The problem is designing systems that humans can operate sustainably.
89
00:03:26,440 –> 00:03:28,480
That distinction matters because here’s what happens.
90
00:03:28,480 –> 00:03:32,320
Technical solutions applied to governance problems create more governance problems.
91
00:03:32,320 –> 00:03:35,240
You implement aggressive conditional access policies.
92
00:03:35,240 –> 00:03:38,640
Users find workarounds, you block power platform usage.
93
00:03:38,640 –> 00:03:40,560
Citizen developers move to personal clouds,
94
00:03:40,560 –> 00:03:42,800
you require sensitivity labels on everything.
95
00:03:42,800 –> 00:03:44,200
Nobody applies them correctly,
96
00:03:44,200 –> 00:03:46,560
so you get false positives and alert fatigue.
97
00:03:46,560 –> 00:03:49,760
You’ve treated an architectural problem as if it were a technical problem.
98
00:03:49,760 –> 00:03:52,440
And when you do that, you push the friction somewhere else.
99
00:03:52,440 –> 00:03:57,160
The goal of Microsoft 365 architecture isn’t to build systems that work on day one.
100
00:03:57,160 –> 00:04:01,440
It’s to design systems that organizations can still operate five years from now.
101
00:04:01,440 –> 00:04:04,200
That requires thinking differently about what success means.
102
00:04:04,200 –> 00:04:07,400
It means asking whether every technical decision can be maintained
103
00:04:07,400 –> 00:04:09,360
when the technical person who built it leaves,
104
00:04:09,360 –> 00:04:11,960
it means building governance into the architecture from the beginning,
105
00:04:11,960 –> 00:04:13,600
not layering it on after the chaos.
106
00:04:13,600 –> 00:04:16,160
That’s what we’re going to explore in this conversation.
107
00:04:16,160 –> 00:04:18,800
Why technical excellence becomes a liability?
108
00:04:18,800 –> 00:04:20,760
This is where the confession gets uncomfortable.
109
00:04:20,760 –> 00:04:23,760
The best engineers are often the worst architects for enterprise governance.
110
00:04:23,760 –> 00:04:25,160
And I say that without judgment.
111
00:04:25,160 –> 00:04:26,600
I’ve worked with brilliant people,
112
00:04:26,600 –> 00:04:28,760
people who understand architecture deeply,
113
00:04:28,760 –> 00:04:32,760
who can design role-based access control models that are mathematically elegant,
114
00:04:32,760 –> 00:04:36,760
who build power platform solutions that solve real problems with elegant elegance.
115
00:04:36,760 –> 00:04:38,160
These are not mediocre people.
116
00:04:38,160 –> 00:04:39,760
These are people who could work anywhere.
117
00:04:39,760 –> 00:04:43,760
The problem is that technical depth creates a blindness to systemic durability.
118
00:04:43,760 –> 00:04:46,360
A brilliant engineer solves for, can we do this?
119
00:04:46,360 –> 00:04:49,360
A governance architect has to solve for, should we do this?
120
00:04:49,360 –> 00:04:51,360
And who manages it in three years?
121
00:04:51,360 –> 00:04:52,960
Those are different problems.
122
00:04:52,960 –> 00:04:54,560
And they require different thinking.
123
00:04:54,560 –> 00:04:57,560
Technical people optimize for capability that they ask,
124
00:04:57,560 –> 00:05:00,160
what’s the most advanced thing we can build with this platform?
125
00:05:00,160 –> 00:05:02,960
How can we automate the maximum number of processes?
126
00:05:02,960 –> 00:05:06,160
How do we design identity controls that are theoretically perfect?
127
00:05:06,160 –> 00:05:09,160
The answer to each of those questions is often technically correct.
128
00:05:09,160 –> 00:05:13,160
But technical correctness and operational sustainability are not the same thing.
129
00:05:13,160 –> 00:05:14,960
Here’s the pattern I’ve seen over and over.
130
00:05:14,960 –> 00:05:18,960
A brilliant architect designs a Microsoft 365 environment.
131
00:05:18,960 –> 00:05:20,560
The tenant is perfectly configured.
132
00:05:20,560 –> 00:05:23,360
Conditional access policies are granular and risk-aware.
133
00:05:23,360 –> 00:05:26,960
Role-based access control is implemented down to the SharePoint side level.
134
00:05:26,960 –> 00:05:29,960
Power platform governance includes environment separation,
135
00:05:29,960 –> 00:05:32,760
flow ownership tracking and connector restrictions.
136
00:05:32,760 –> 00:05:35,760
As your AD is clean, retention policies are consistent.
137
00:05:35,760 –> 00:05:38,160
External sharing is controlled. It’s a masterpiece.
138
00:05:38,160 –> 00:05:40,360
On day one, it works beautifully.
139
00:05:40,360 –> 00:05:42,360
By year three, it’s collapsing silently.
140
00:05:42,360 –> 00:05:45,160
Why? Because the organization didn’t internalize the governance model.
141
00:05:45,160 –> 00:05:48,760
Nobody remembers why the conditional access policies were written that way.
142
00:05:48,760 –> 00:05:52,360
The architect who understood the entire role-based access control model
143
00:05:52,360 –> 00:05:53,560
left for another job.
144
00:05:53,560 –> 00:05:56,360
The power platform governance structure created such friction
145
00:05:56,360 –> 00:05:59,960
that citizen developers started building flows in personal environments.
146
00:05:59,960 –> 00:06:01,960
The retention policies make sense on paper,
147
00:06:01,960 –> 00:06:04,360
but conflict with how business units actually work.
148
00:06:04,360 –> 00:06:05,160
So they’re ignored.
149
00:06:05,160 –> 00:06:08,960
The external sharing controls are so strict that legitimate partners can’t collaborate.
150
00:06:08,960 –> 00:06:10,760
So users find workarounds.
151
00:06:10,760 –> 00:06:13,560
The system didn’t fail because it was poorly designed.
152
00:06:13,560 –> 00:06:17,960
It failed because it was designed for a different organization than the one actually operating it.
153
00:06:17,960 –> 00:06:22,160
This is the fundamental split, configuration thinking versus intent-based design.
154
00:06:22,160 –> 00:06:25,960
Configuration thinking asks, “What settings should we configure?”
155
00:06:25,960 –> 00:06:27,560
It’s tactical. It’s specific.
156
00:06:27,560 –> 00:06:29,160
You set conditional access policies.
157
00:06:29,160 –> 00:06:30,760
You define role assignments.
158
00:06:30,760 –> 00:06:33,760
You configure retention labels. You implement DLP rules.
159
00:06:33,760 –> 00:06:36,360
All of it is technically sound. All of it works on day one.
160
00:06:36,360 –> 00:06:39,760
But configuration thinking treats governance as a problem you solve once.
161
00:06:39,760 –> 00:06:42,160
You configure the controls. You document the policies.
162
00:06:42,160 –> 00:06:44,560
You hand it off. Done.
163
00:06:44,560 –> 00:06:49,760
Intent-based design asks, “What behavior do we want the system to enforce over time?”
164
00:06:49,760 –> 00:06:53,960
That’s architectural. A brilliant technical architect can design perfect configurations.
165
00:06:53,960 –> 00:06:57,360
A governance architect has to ask whether those configurations will survive
166
00:06:57,360 –> 00:06:59,360
when the technical person isn’t in the room anymore.
167
00:06:59,360 –> 00:07:01,760
Will they survive when business requirements change?
168
00:07:01,760 –> 00:07:04,560
Will they survive when a new technology gets integrated?
169
00:07:04,560 –> 00:07:08,760
Will they survive when the organization acquires another company and needs to merge tenants?
170
00:07:08,760 –> 00:07:12,160
The most dangerous architecture is the one that works perfectly on day one
171
00:07:12,160 –> 00:07:13,960
and collapses silently by year three.
172
00:07:13,960 –> 00:07:16,560
It collapses quietly because there is no dramatic failure.
173
00:07:16,560 –> 00:07:19,360
Things still run, but the system has become un-maintainable.
174
00:07:19,360 –> 00:07:20,560
The governance has drifted.
175
00:07:20,560 –> 00:07:23,560
The configurations no longer align with organizational reality.
176
00:07:23,560 –> 00:07:25,960
The controls require constant manual intervention.
177
00:07:25,960 –> 00:07:28,560
The compliance audit uncovers dozens of policy exceptions
178
00:07:28,560 –> 00:07:30,160
that nobody documents anymore.
179
00:07:30,160 –> 00:07:31,960
And then you discover the real problem.
180
00:07:31,960 –> 00:07:36,960
The original architects solved for technical perfection instead of organizational sustainability.
181
00:07:36,960 –> 00:07:38,360
This isn’t a blame exercise.
182
00:07:38,360 –> 00:07:40,160
The engineers in those stories were brilliant.
183
00:07:40,160 –> 00:07:43,160
That’s the point. The problem is that brilliance applied to the wrong problem
184
00:07:43,160 –> 00:07:46,560
creates systems that are technically perfect and operationally impossible.
185
00:07:46,560 –> 00:07:49,960
An organization can’t operate a perfectly optimized technical solution
186
00:07:49,960 –> 00:07:52,560
if nobody understands why the optimization exists.
187
00:07:52,560 –> 00:07:55,760
That’s the confession. The best technical minds in the room often create
188
00:07:55,760 –> 00:07:58,560
the worst governance outcomes, not because they’re incompetent,
189
00:07:58,560 –> 00:08:02,760
but because they’re answering a different question than the organization needs answered.
190
00:08:02,760 –> 00:08:04,560
The three governance zones framework.
191
00:08:04,560 –> 00:08:07,960
Before we dive into the failures, let me introduce the framework that prevents them.
192
00:08:07,960 –> 00:08:10,160
Most organizations treat all data the same way.
193
00:08:10,160 –> 00:08:12,960
They apply one set of governance rules across everything.
194
00:08:12,960 –> 00:08:14,160
That’s the fundamental mistake.
195
00:08:14,160 –> 00:08:16,360
Microsoft 365 isn’t a single system.
196
00:08:16,360 –> 00:08:18,960
It’s three different systems operating at different scales,
197
00:08:18,960 –> 00:08:22,160
serving different purposes, requiring different governance models.
198
00:08:22,160 –> 00:08:23,560
Once you see those three zones,
199
00:08:23,560 –> 00:08:25,960
the entire governance problem becomes simpler.
200
00:08:25,960 –> 00:08:28,960
Zone one is personal work, one drive, personal teams chats,
201
00:08:28,960 –> 00:08:32,360
the stuff you’re working on that doesn’t need to be shared with anyone.
202
00:08:32,360 –> 00:08:34,960
This zone should be user controlled with minimal governance.
203
00:08:34,960 –> 00:08:36,360
The person owns their content.
204
00:08:36,360 –> 00:08:38,160
They can organize it however they want.
205
00:08:38,160 –> 00:08:39,960
They can share it with whoever they want.
206
00:08:39,960 –> 00:08:43,160
Nobody needs to label it or review it or enforce retention.
207
00:08:43,160 –> 00:08:46,560
The organizational overhead on zone one should be almost zero.
208
00:08:46,560 –> 00:08:48,160
Zone two is collaborative work.
209
00:08:48,160 –> 00:08:53,160
Teams channels, project sites, marketing campaigns, product launches, customer engagements.
210
00:08:53,160 –> 00:08:56,560
This is where teams collaborate on things that matter but aren’t regulated.
211
00:08:56,560 –> 00:08:59,360
This zone should be team managed with moderate governance.
212
00:08:59,360 –> 00:09:00,760
You need owner accountability.
213
00:09:00,760 –> 00:09:02,360
You need life cycle rules.
214
00:09:02,360 –> 00:09:05,960
If a project ends, the site gets archived, not left often forever.
215
00:09:05,960 –> 00:09:07,760
You need clear sharing policies.
216
00:09:07,760 –> 00:09:11,760
You need someone to own the space and be responsible for whether the right people have access.
217
00:09:11,760 –> 00:09:15,560
But you don’t need the operational burden of treating every team’s channel
218
00:09:15,560 –> 00:09:17,160
like it contains financial records.
219
00:09:17,160 –> 00:09:18,760
Zone three is enterprise records.
220
00:09:18,760 –> 00:09:21,760
HR data, finance, regulated content,
221
00:09:21,760 –> 00:09:25,160
anything that has compliance implications or legal hold requirements.
222
00:09:25,160 –> 00:09:27,360
This is where you need strict governance.
223
00:09:27,360 –> 00:09:29,360
Sensitivity labels are mandatory.
224
00:09:29,360 –> 00:09:30,960
Retention policies are enforced.
225
00:09:30,960 –> 00:09:32,560
Access is reviewed regularly.
226
00:09:32,560 –> 00:09:34,160
External sharing is restricted.
227
00:09:34,160 –> 00:09:35,160
Everything is logged.
228
00:09:35,160 –> 00:09:36,360
Everything is auditable.
229
00:09:36,360 –> 00:09:36,960
That’s it.
230
00:09:36,960 –> 00:09:38,560
Three zones, three governance models.
231
00:09:38,560 –> 00:09:40,960
This model instantly simplifies governance design.
232
00:09:40,960 –> 00:09:42,160
It prevents scope creep.
233
00:09:42,160 –> 00:09:46,160
It prevents the situation where you build a governance framework designed for enterprise records.
234
00:09:46,160 –> 00:09:49,960
Then try to apply it to personal work and suddenly your organization can’t function
235
00:09:49,960 –> 00:09:52,960
because people can’t organize their own files without approval chains.
236
00:09:52,960 –> 00:09:57,560
Most failures occur when organizations treat all three zones with identical governance.
237
00:09:57,560 –> 00:09:59,760
They build a perfect governance model for zone three.
238
00:09:59,760 –> 00:10:02,760
Strict controls, careful oversight, compliance driven.
239
00:10:02,760 –> 00:10:04,560
Then they apply it to zone two.
240
00:10:04,560 –> 00:10:06,160
Suddenly teams becomes friction.
241
00:10:06,160 –> 00:10:07,360
Collaboration slows down.
242
00:10:07,360 –> 00:10:08,560
People find workarounds.
243
00:10:08,560 –> 00:10:09,960
They apply it to zone one.
244
00:10:09,960 –> 00:10:14,360
People start using personal cloud storage because organizational one drive is too controlled.
245
00:10:14,360 –> 00:10:16,160
You’ve just created shadow IT.
246
00:10:16,160 –> 00:10:17,960
Not solve the governance problem.
247
00:10:17,960 –> 00:10:21,760
The framework works because it separates three things that most organizations conflate.
248
00:10:21,760 –> 00:10:23,560
Presentation, logic and data.
249
00:10:23,560 –> 00:10:25,160
Presentation is what users see.
250
00:10:25,160 –> 00:10:28,360
The interface, the experience that should adapt to the zone.
251
00:10:28,360 –> 00:10:29,960
Zone one should feel frictionless.
252
00:10:29,960 –> 00:10:32,160
Zone three should feel controlled and auditable.
253
00:10:32,160 –> 00:10:33,560
Logic is governance.
254
00:10:33,560 –> 00:10:36,960
The rules, the policies, the controls, that should be appropriate to the zone,
255
00:10:36,960 –> 00:10:38,560
not uniform across all zones.
256
00:10:38,560 –> 00:10:40,160
Data is the actual content.
257
00:10:40,160 –> 00:10:42,760
That should be protected according to its sensitivity,
258
00:10:42,760 –> 00:10:45,160
not according to which zone it happens to sit in.
259
00:10:45,160 –> 00:10:47,160
Intent-based governance asks,
260
00:10:47,160 –> 00:10:50,360
“What behavior do we want the system to enforce over time?”
261
00:10:50,360 –> 00:10:54,760
In zone one, we want to enable personal productivity without organizational overhead.
262
00:10:54,760 –> 00:10:57,760
In zone two, we want to enable collaboration with clear ownership.
263
00:10:57,760 –> 00:11:00,760
In zone three, we want compliance and auditability.
264
00:11:00,760 –> 00:11:04,360
Configuration thinking asks, “What settings should we configure?”
265
00:11:04,360 –> 00:11:05,560
That’s where chaos begins.
266
00:11:05,560 –> 00:11:09,560
You configure policies, you layer them, you create exceptions, you document them.
267
00:11:09,560 –> 00:11:14,160
Six months later, the actual behavior of the system no longer matches any documentation.
268
00:11:14,160 –> 00:11:15,960
Intent-based governance survives.
269
00:11:15,960 –> 00:11:17,760
Configuration thinking collapses.
270
00:11:17,760 –> 00:11:19,560
This framework is the foundation.
271
00:11:19,560 –> 00:11:21,560
Every governance decision flows from it,
272
00:11:21,560 –> 00:11:23,960
which is why most organizations get governance so wrong.
273
00:11:23,960 –> 00:11:25,160
They never define the zones.
274
00:11:25,160 –> 00:11:28,160
They never make explicit what behavior they actually want.
275
00:11:28,160 –> 00:11:31,160
So they end up with a configuration mess that nobody can maintain.
276
00:11:31,160 –> 00:11:34,760
Case study one, the automation hydra.
277
00:11:34,760 –> 00:11:37,560
Let’s start with the first failure pattern I’ve seen repeatedly.
278
00:11:37,560 –> 00:11:39,160
I call it the automation hydra.
279
00:11:39,160 –> 00:11:41,360
This one starts with a legitimate business problem.
280
00:11:41,360 –> 00:11:44,360
A mid-market organization has a manual process that’s slow.
281
00:11:44,360 –> 00:11:46,360
Sales collateral needs to go through approval.
282
00:11:46,360 –> 00:11:48,960
In voices need to be rooted to the right cost center.
283
00:11:48,960 –> 00:11:51,560
Customer data needs to sync between systems.
284
00:11:51,560 –> 00:11:53,560
Someone says we could automate this.
285
00:11:53,560 –> 00:11:55,360
A brilliant automation engineer.
286
00:11:55,360 –> 00:11:56,960
Or in modern organizations.
287
00:11:56,960 –> 00:12:00,760
A citizen developer with power platform training builds a power automate flow.
288
00:12:00,760 –> 00:12:03,560
It works. It solves the problem processing time drops.
289
00:12:03,560 –> 00:12:06,160
Manual errors drop. It’s a success.
290
00:12:06,160 –> 00:12:07,960
Success breeds expansion.
291
00:12:07,960 –> 00:12:09,560
Can we automate this other process?
292
00:12:09,560 –> 00:12:10,360
Yes, we can.
293
00:12:10,360 –> 00:12:11,960
Another flow. This one’s more complex.
294
00:12:11,960 –> 00:12:12,960
It touches more systems.
295
00:12:12,960 –> 00:12:16,760
It reads data from SharePoint writes the dynamics sends approvals through teams.
296
00:12:16,760 –> 00:12:19,360
Still works beautifully.
297
00:12:19,360 –> 00:12:22,360
Six months in, the automation program is seen as a win.
298
00:12:22,360 –> 00:12:25,960
Leadership wants more business units request flows for their own processes.
299
00:12:25,960 –> 00:12:27,960
The citizen developer ecosystem explodes.
300
00:12:27,960 –> 00:12:30,160
30 flows, 50 flows, 100 flows.
301
00:12:30,160 –> 00:12:32,560
By this point, something has changed fundamentally,
302
00:12:32,560 –> 00:12:35,160
but nobody notices yet because the flow still work.
303
00:12:35,160 –> 00:12:37,160
The problem isn’t that the flows are broken.
304
00:12:37,160 –> 00:12:41,160
The problem is that they’ve become interdependent in ways nobody explicitly designed.
305
00:12:41,160 –> 00:12:42,560
Flow A triggers flow B.
306
00:12:42,560 –> 00:12:45,160
Flow B modifies data that flow C depends on.
307
00:12:45,160 –> 00:12:47,760
Flow C writes to a list that flow D reads from.
308
00:12:47,760 –> 00:12:50,560
These dependencies accumulate invisibly
309
00:12:50,560 –> 00:12:54,160
because they emerge from individual business problems being solved locally,
310
00:12:54,160 –> 00:12:56,360
not from a system being designed holistically.
311
00:12:56,360 –> 00:12:57,760
Then something changes.
312
00:12:57,760 –> 00:12:59,360
A business requirement shifts.
313
00:12:59,360 –> 00:13:01,960
Someone updates flow A to handle a new case type.
314
00:13:01,960 –> 00:13:03,960
That update ripples through the dependency chain.
315
00:13:03,960 –> 00:13:06,760
Flow B breaks because it wasn’t expecting the new data format.
316
00:13:06,760 –> 00:13:08,560
Flow C starts generating errors.
317
00:13:08,560 –> 00:13:11,960
Three hours later, business processes are failing across the organization.
318
00:13:11,960 –> 00:13:16,360
The person who built flow A is trying to debug why downstream systems are broken.
319
00:13:16,360 –> 00:13:20,360
But they never explicitly documented that flow A was connected to flow B.
320
00:13:20,360 –> 00:13:21,760
They just knew it in their head.
321
00:13:21,760 –> 00:13:24,760
This is the moment most organizations realize they have a problem.
322
00:13:24,760 –> 00:13:25,960
The symptoms are chaos.
323
00:13:25,960 –> 00:13:28,360
Business processes breaking unexpectedly.
324
00:13:28,360 –> 00:13:29,960
IT scrambling to restore service.
325
00:13:29,960 –> 00:13:31,960
Nobody knowing the actual ownership chain.
326
00:13:31,960 –> 00:13:35,160
Rollbacks that take hours because you can’t just revert flow A.
327
00:13:35,160 –> 00:13:38,960
You have to understand how it cascades through the entire automation ecosystem.
328
00:13:38,960 –> 00:13:42,960
I’ve seen organizations report hundreds of flows with no clear ownership.
329
00:13:42,960 –> 00:13:45,560
Thousands of flows with undocumented dependencies.
330
00:13:45,560 –> 00:13:50,160
A single update that cascaded through dozens of flows in ways nobody predicted.
331
00:13:50,160 –> 00:13:54,960
The core problem is simple automation without lifecycle governance creates a system that nobody can maintain.
332
00:13:54,960 –> 00:13:56,360
This isn’t a technical problem.
333
00:13:56,360 –> 00:13:57,560
The flows are well written.
334
00:13:57,560 –> 00:13:58,960
The platform works perfectly.
335
00:13:58,960 –> 00:14:00,160
The issue is architectural.
336
00:14:00,160 –> 00:14:02,760
Citizen developers were empowered to build solutions.
337
00:14:02,760 –> 00:14:03,360
That’s good.
338
00:14:03,360 –> 00:14:04,960
But nobody owned the system as a whole.
339
00:14:04,960 –> 00:14:06,360
There was no lifecycle governance.
340
00:14:06,360 –> 00:14:08,360
No one was tracking what flows existed.
341
00:14:08,360 –> 00:14:08,960
Who built them?
342
00:14:08,960 –> 00:14:09,960
What they depended on?
343
00:14:09,960 –> 00:14:11,360
Whether they were still needed.
344
00:14:11,360 –> 00:14:15,760
There was no continuous monitoring of the automation ecosystem as a living system.
345
00:14:15,760 –> 00:14:17,960
Power platform governance requires three things.
346
00:14:17,960 –> 00:14:18,760
Ownership.
347
00:14:18,760 –> 00:14:21,560
Life cycle management and continuous monitoring.
348
00:14:21,560 –> 00:14:27,960
Ownership means every flow has a documented owner who understands what it does and what it depends on.
349
00:14:27,960 –> 00:14:29,960
Not a generic IT owns this.
350
00:14:29,960 –> 00:14:31,960
A person, someone accountable.
351
00:14:31,960 –> 00:14:34,960
Life cycle management means flows have a defined lifespan.
352
00:14:34,960 –> 00:14:38,160
When the business process changes, the flow gets updated or archived.
353
00:14:38,160 –> 00:14:41,360
When the person who built it leaves, someone else becomes responsible.
354
00:14:41,360 –> 00:14:44,560
You don’t accumulate orphaned flows that run forever.
355
00:14:44,560 –> 00:14:46,560
Because nobody remembers what they do.
356
00:14:46,560 –> 00:14:50,360
Continuous monitoring means you’re watching the automation ecosystem as a system.
357
00:14:50,360 –> 00:14:51,560
You’re tracking dependencies.
358
00:14:51,560 –> 00:14:52,960
You’re measuring failure rates.
359
00:14:52,960 –> 00:14:55,560
You’re understanding how changes in one flow affect others.
360
00:14:55,560 –> 00:14:58,960
You’re treating automation as infrastructure that requires oversight.
361
00:14:58,960 –> 00:15:02,360
Not just as a collection of individual problems solved independently.
362
00:15:02,360 –> 00:15:05,360
Without these three things, automation becomes entropy.
363
00:15:05,360 –> 00:15:06,760
The system still works.
364
00:15:06,760 –> 00:15:08,560
Technically, the flows keep running.
365
00:15:08,560 –> 00:15:09,960
But nobody controls it anymore.
366
00:15:09,960 –> 00:15:13,360
You’ve created a black box of automation that the organization is now dependent on
367
00:15:13,360 –> 00:15:14,560
but can’t actually manage.
368
00:15:14,560 –> 00:15:16,880
And here’s the uncomfortable part, the technical solution,
369
00:15:16,880 –> 00:15:20,360
building more automation, adding more flows, deploying more sophisticated logic,
370
00:15:20,360 –> 00:15:21,760
makes the problem worse.
371
00:15:21,760 –> 00:15:25,760
Each new flow increases the complexity and interdependency of the system.
372
00:15:25,760 –> 00:15:27,760
You haven’t solved the governance problem.
373
00:15:27,760 –> 00:15:28,760
You’ve expanded it.
374
00:15:28,760 –> 00:15:32,760
This is why brilliant automation architects can create the worst governance outcomes.
375
00:15:32,760 –> 00:15:34,760
They solve the technical problem beautifully.
376
00:15:34,760 –> 00:15:38,160
They just never ask who’s going to maintain the system when I’m not here.
377
00:15:38,160 –> 00:15:40,160
Why automation entropy happens?
378
00:15:40,160 –> 00:15:42,560
The automation hydra doesn’t appear overnight.
379
00:15:42,560 –> 00:15:44,160
Let me walk you through how it develops.
380
00:15:44,160 –> 00:15:45,960
It starts with the legitimate business need.
381
00:15:45,960 –> 00:15:47,560
Some manual process is slow.
382
00:15:47,560 –> 00:15:50,360
Invoices sit in inboxes waiting for approval.
383
00:15:50,360 –> 00:15:52,360
Customer data doesn’t sync between systems.
384
00:15:52,360 –> 00:15:55,760
Someone notices the inefficiency and says, we could automate this.
385
00:15:55,760 –> 00:15:59,560
A citizen developer or sometimes a brilliant technical architect who’s been tasked
386
00:15:59,560 –> 00:16:03,160
with modernizing legacy processes, builds a power automate flow.
387
00:16:03,160 –> 00:16:04,160
It’s straightforward.
388
00:16:04,160 –> 00:16:07,960
Read data from one system, apply business logic, write to another system,
389
00:16:07,960 –> 00:16:08,960
send notifications.
390
00:16:08,960 –> 00:16:09,460
It works.
391
00:16:09,460 –> 00:16:10,760
It solves the actual problem.
392
00:16:10,760 –> 00:16:13,760
Processing time drops, manual errors disappear.
393
00:16:13,760 –> 00:16:15,560
The organization sees immediate value.
394
00:16:15,560 –> 00:16:17,060
That’s not where the failure begins.
395
00:16:17,060 –> 00:16:20,360
That’s where success begins and success creates the conditions for failure.
396
00:16:20,360 –> 00:16:23,560
Because once leadership sees that automation works, the question changes.
397
00:16:23,560 –> 00:16:25,360
It’s no longer should we automate this.
398
00:16:25,360 –> 00:16:28,160
It becomes how many more processes can we automate?
399
00:16:28,160 –> 00:16:30,160
Citizen developers start getting requests.
400
00:16:30,160 –> 00:16:32,160
Finance wants to automate invoice routing.
401
00:16:32,160 –> 00:16:34,160
Sales wants to automate collateral approvals.
402
00:16:34,160 –> 00:16:36,160
HR wants to automate onboarding.
403
00:16:36,160 –> 00:16:37,760
Each request is legitimate.
404
00:16:37,760 –> 00:16:39,560
Each flow solves a real problem.
405
00:16:39,560 –> 00:16:42,160
But here’s what’s happening underneath that success.
406
00:16:42,160 –> 00:16:44,160
Dependencies are accumulating invisibly.
407
00:16:44,160 –> 00:16:45,560
The first few flows are simple.
408
00:16:45,560 –> 00:16:46,560
Independent.
409
00:16:46,560 –> 00:16:47,560
They don’t interact.
410
00:16:47,560 –> 00:16:49,760
But by the 10th flow, something has shifted.
411
00:16:49,760 –> 00:16:51,760
Flow A reads from a SharePoint list.
412
00:16:51,760 –> 00:16:53,360
Flow B writes to the same list.
413
00:16:53,360 –> 00:16:55,560
Nobody explicitly decided they should interact.
414
00:16:55,560 –> 00:16:59,160
It just happened because both flows needed access to the same data.
415
00:16:59,160 –> 00:17:01,960
But now FlowB’s output is becoming FlowA’s input.
416
00:17:01,960 –> 00:17:03,560
FlowC joins the ecosystem.
417
00:17:03,560 –> 00:17:07,760
It monitors an email inbox and creates tasks in a list that FlowD depends on.
418
00:17:07,760 –> 00:17:11,760
FlowD triggers FlowE, which modifies records that FlowA reads.
419
00:17:11,760 –> 00:17:14,360
You now have five flows, and they’re connected in ways
420
00:17:14,360 –> 00:17:16,760
that only the developers who built them understand.
421
00:17:16,760 –> 00:17:17,960
And only in their heads.
422
00:17:17,960 –> 00:17:19,760
Nobody has mapped these dependencies.
423
00:17:19,760 –> 00:17:20,560
There’s no diagram.
424
00:17:20,560 –> 00:17:22,960
There’s no documentation that says if you change FlowB,
425
00:17:22,960 –> 00:17:25,560
you need to check whether FlowA will still work.
426
00:17:25,560 –> 00:17:28,960
The connections emerged organically from individual problem solving.
427
00:17:28,960 –> 00:17:32,560
Each flow was designed to solve a specific business problem in isolation.
428
00:17:32,560 –> 00:17:34,960
Nobody designed how they interact as a system.
429
00:17:34,960 –> 00:17:37,560
This is the definition of technical debt in the automation space.
430
00:17:37,560 –> 00:17:38,760
It’s not a broken flow.
431
00:17:38,760 –> 00:17:41,160
It’s invisible coupling.
432
00:17:41,160 –> 00:17:44,360
Most organizations lack visibility into what flows exist.
433
00:17:44,360 –> 00:17:45,360
Who owns them?
434
00:17:45,360 –> 00:17:46,760
Or what data they touch?
435
00:17:46,760 –> 00:17:49,160
They know flows are running, they see the business value.
436
00:17:49,160 –> 00:17:50,760
But they don’t know the actual architecture.
437
00:17:50,760 –> 00:17:52,360
If a citizen developer leaves,
438
00:17:52,360 –> 00:17:54,560
that person’s flows become orphaned knowledge.
439
00:17:54,560 –> 00:17:58,160
If a business requirement changes and someone needs to update a flow,
440
00:17:58,160 –> 00:18:00,360
they don’t know what else might break downstream.
441
00:18:00,360 –> 00:18:02,560
The governance failure isn’t building the flows.
442
00:18:02,560 –> 00:18:04,960
It’s failing to design a system that can sustain them.
443
00:18:04,960 –> 00:18:07,760
Technical people, whether citizen developers or architects,
444
00:18:07,760 –> 00:18:09,560
were solving the right problem locally.
445
00:18:09,560 –> 00:18:11,360
They were automating manual processes.
446
00:18:11,360 –> 00:18:12,560
They were reducing errors.
447
00:18:12,560 –> 00:18:13,960
They were delivering business value.
448
00:18:13,960 –> 00:18:16,160
But they were solving the wrong problem globally.
449
00:18:16,160 –> 00:18:17,160
They weren’t asking,
450
00:18:17,160 –> 00:18:20,360
how will the organization maintain this automation ecosystem in two years?
451
00:18:20,360 –> 00:18:24,160
What happens when 500 flows exist and nobody can trace the dependencies?
452
00:18:24,160 –> 00:18:26,960
What happens when a critical flow breaks at two in the morning?
453
00:18:26,960 –> 00:18:28,960
And the person who built it is unreachable.
454
00:18:28,960 –> 00:18:32,160
Most organizations discover they have an automation entropy problem
455
00:18:32,160 –> 00:18:33,560
only when something breaks.
456
00:18:33,560 –> 00:18:37,160
And by that point, the system is complex enough that fixing it requires
457
00:18:37,160 –> 00:18:41,760
either reverse engineering the entire flow ecosystem or rebuilding it from scratch.
458
00:18:41,760 –> 00:18:44,760
The path to the automation hydra is paved with good intentions
459
00:18:44,760 –> 00:18:46,760
and incremental local decisions.
460
00:18:46,760 –> 00:18:47,960
Each flow was the right choice.
461
00:18:47,960 –> 00:18:50,360
None of them individually created the problem.
462
00:18:50,360 –> 00:18:54,360
The problem emerged from treating automation as a collection of independent solutions
463
00:18:54,360 –> 00:18:57,360
instead of treating it as infrastructure that needs governance.
464
00:18:57,360 –> 00:19:00,360
That’s why the most dangerous automation programs are the successful ones.
465
00:19:00,360 –> 00:19:03,760
Success hides the structural problem until it’s too late to fix it easily.
466
00:19:03,760 –> 00:19:06,360
Case study 2, the security fortress.
467
00:19:06,360 –> 00:19:08,760
Now let’s look at the second failure pattern.
468
00:19:08,760 –> 00:19:11,560
When security architecture becomes operational friction.
469
00:19:11,560 –> 00:19:13,760
This one starts differently. There’s no gradual drift.
470
00:19:13,760 –> 00:19:15,360
There’s no accumulated legacy.
471
00:19:15,360 –> 00:19:17,560
This one is designed from the ground up to be secure.
472
00:19:17,560 –> 00:19:19,960
A technically brilliant security architect.
473
00:19:19,960 –> 00:19:22,560
Someone who understands zero trust principles deeply.
474
00:19:22,560 –> 00:19:26,560
Who can explain conditional access policies and device compliance in detail?
475
00:19:26,560 –> 00:19:29,960
Who knows the NIST Cybersecurity Framework called gets tasked
476
00:19:29,960 –> 00:19:31,960
with designing a modern security model?
477
00:19:31,960 –> 00:19:33,560
And they design something perfect.
478
00:19:33,560 –> 00:19:37,960
Aggressive conditional access policies that evaluate risk on every authentication attempt.
479
00:19:37,960 –> 00:19:39,960
Strict device compliance requirements
480
00:19:39,960 –> 00:19:43,360
that only allow managed devices to access corporate resources.
481
00:19:43,360 –> 00:19:46,160
MFA required for everything enforced consistently.
482
00:19:46,160 –> 00:19:49,360
External sharing restricted to pre-approved domains.
483
00:19:49,360 –> 00:19:51,760
Heavy controls on what applications can be installed.
484
00:19:51,760 –> 00:19:53,760
Careful monitoring of data movement.
485
00:19:53,760 –> 00:19:56,160
All technically sound. All best practice aligned.
486
00:19:56,160 –> 00:19:58,760
All defensible in an audit. It’s a fortress.
487
00:19:58,760 –> 00:20:00,360
On day one, it works beautifully.
488
00:20:00,360 –> 00:20:03,160
The security baseline is tighter than it’s ever been.
489
00:20:03,160 –> 00:20:05,360
Threat intelligent systems light up fewer threats
490
00:20:05,360 –> 00:20:07,360
because the attack surface is reduced.
491
00:20:07,360 –> 00:20:08,960
The security team feels confident.
492
00:20:08,960 –> 00:20:10,560
Leadership feels protected.
493
00:20:10,560 –> 00:20:13,560
The architecture is exactly what Microsoft and every security framework
494
00:20:13,560 –> 00:20:14,760
recommends by month three.
495
00:20:14,760 –> 00:20:16,560
The organization has quietly disabled it.
496
00:20:16,560 –> 00:20:19,560
Not officially. Nobody announces that the fortress is coming down.
497
00:20:19,560 –> 00:20:22,160
Instead, users start finding workarounds.
498
00:20:22,160 –> 00:20:23,560
Personal drop box.
499
00:20:23,560 –> 00:20:27,160
WhatsApp file transfers to send documents outside the secure system.
500
00:20:27,160 –> 00:20:30,160
Shadow SAS tools where collaborative work actually happens.
501
00:20:30,160 –> 00:20:32,960
Employees access work email from personal devices.
502
00:20:32,960 –> 00:20:36,560
Because the compliance requirements on corporate devices are too onerous.
503
00:20:36,560 –> 00:20:38,760
Project teams maintain Google Drive folders
504
00:20:38,760 –> 00:20:41,360
because SharePoint access is too restricted.
505
00:20:41,360 –> 00:20:43,560
Sales uses a personal Slack workspace
506
00:20:43,560 –> 00:20:45,360
because the corporate team’s implementation
507
00:20:45,360 –> 00:20:47,960
requires too many approvals for external guest access.
508
00:20:47,960 –> 00:20:49,760
The security architecture was perfect.
509
00:20:49,760 –> 00:20:51,360
The human behavior defeated it.
510
00:20:51,360 –> 00:20:52,360
Here’s the paradox.
511
00:20:52,360 –> 00:20:54,360
Security that ignores human behavior
512
00:20:54,360 –> 00:20:56,160
eventually weakens security.
513
00:20:56,160 –> 00:20:57,960
You’ve designed a system so restrictive
514
00:20:57,960 –> 00:20:59,560
that it makes people’s jobs harder.
515
00:20:59,560 –> 00:21:00,960
They don’t become more secure.
516
00:21:00,960 –> 00:21:02,160
They become creative.
517
00:21:02,160 –> 00:21:05,160
And their creativity bypasses your controls entirely.
518
00:21:05,160 –> 00:21:06,560
The research is clear on this.
519
00:21:06,560 –> 00:21:11,160
Around 80% of SAS breaches originate from misconfiguration or user behavior
520
00:21:11,160 –> 00:21:14,160
not from platform vulnerabilities or sophisticated attacks.
521
00:21:14,160 –> 00:21:16,360
Users circumventing security controls.
522
00:21:16,360 –> 00:21:17,760
Misconfigured permissions.
523
00:21:17,760 –> 00:21:20,560
Oversharing because approval processes are too slow.
524
00:21:20,560 –> 00:21:22,960
Shadow IT because official channels can’t keep up.
525
00:21:22,960 –> 00:21:24,560
But here’s what’s important to understand.
526
00:21:24,560 –> 00:21:26,560
Users don’t circumvent security
527
00:21:26,560 –> 00:21:28,360
because they’re reckless or incompetent.
528
00:21:28,360 –> 00:21:31,360
They circumvent it because the system makes their job impossible.
529
00:21:31,360 –> 00:21:33,760
A sales team that can’t share documents with a customer
530
00:21:33,760 –> 00:21:35,360
without a three day approval process
531
00:21:35,360 –> 00:21:38,160
will email the files to personal accounts instead.
532
00:21:38,160 –> 00:21:41,560
A finance team that can’t get access to a critical tool
533
00:21:41,560 –> 00:21:43,960
in time for month and closes will find a workaround.
534
00:21:43,960 –> 00:21:45,960
A project team that can’t invite a contractor
535
00:21:45,960 –> 00:21:48,760
without IT involvement will use personal cloud storage.
536
00:21:48,760 –> 00:21:50,560
The architect who designed the fortress
537
00:21:50,560 –> 00:21:52,960
designed it for a theoretical organization.
538
00:21:52,960 –> 00:21:54,960
The organization that actually operates
539
00:21:54,960 –> 00:21:57,560
requires flexibility that the fortress doesn’t allow.
540
00:21:57,560 –> 00:21:59,760
Shadow IT isn’t a security problem.
541
00:21:59,760 –> 00:22:00,960
It’s a governance problem.
542
00:22:00,960 –> 00:22:03,560
It’s the symptom of a system that’s optimized for control
543
00:22:03,560 –> 00:22:05,760
instead of optimized for sustainable operation.
544
00:22:05,760 –> 00:22:07,560
You can make security tighter and tighter.
545
00:22:07,560 –> 00:22:09,360
You can reduce the attack surface.
546
00:22:09,360 –> 00:22:10,760
You can enforce more policies.
547
00:22:10,760 –> 00:22:14,160
But if the cost of compliance is higher than the cost of circumvention
548
00:22:14,160 –> 00:22:15,560
people will circumvent.
549
00:22:15,560 –> 00:22:17,560
The most dangerous security architecture is the one
550
00:22:17,560 –> 00:22:19,960
that’s technically perfect but operationally impossible.
551
00:22:19,960 –> 00:22:21,360
Because it forces a choice.
552
00:22:21,360 –> 00:22:23,160
Follow the rules and don’t work or work
553
00:22:23,160 –> 00:22:24,360
and don’t follow the rules.
554
00:22:24,360 –> 00:22:25,560
Most people choose to work.
555
00:22:25,560 –> 00:22:27,560
This is where the confession gets uncomfortable.
556
00:22:27,560 –> 00:22:30,360
The brilliant security architect designed a perfect fortress.
557
00:22:30,360 –> 00:22:32,160
But the organization didn’t need a fortress.
558
00:22:32,160 –> 00:22:33,160
It needed a city.
559
00:22:33,160 –> 00:22:36,560
It needed a system where security existed within the actual work flow
560
00:22:36,560 –> 00:22:39,160
of how people work, not as friction layered on top of it.
561
00:22:39,160 –> 00:22:41,960
It needed conditional access policies that evaluated risk
562
00:22:41,960 –> 00:22:44,160
but didn’t require users to re-authenticate
563
00:22:44,160 –> 00:22:46,560
every time they switched between applications.
564
00:22:46,560 –> 00:22:49,360
It needed device compliance that was enforced intelligently,
565
00:22:49,360 –> 00:22:50,760
not with blanket restrictions
566
00:22:50,760 –> 00:22:52,360
that made remote work impossible.
567
00:22:52,360 –> 00:22:54,560
It needed external sharing controls
568
00:22:54,560 –> 00:22:55,960
that protected sensitive data
569
00:22:55,960 –> 00:22:58,560
without making legitimate collaboration impossible.
570
00:22:58,560 –> 00:23:00,160
The technical solution wasn’t wrong.
571
00:23:00,160 –> 00:23:02,360
The problem was solving for the wrong organization.
572
00:23:02,360 –> 00:23:03,960
The architect solved for an organization
573
00:23:03,960 –> 00:23:05,960
that valued security above all else.
574
00:23:05,960 –> 00:23:09,360
But the actual organization valued security and productivity.
575
00:23:09,360 –> 00:23:10,960
And when those two things conflict,
576
00:23:10,960 –> 00:23:13,560
governance has to make a choice about which one wins.
577
00:23:13,560 –> 00:23:16,560
That choice can’t be made by a perfect technical control.
578
00:23:16,560 –> 00:23:18,760
It has to be made by an architect who understands
579
00:23:18,760 –> 00:23:22,160
both the security requirement and the organizational reality.
580
00:23:22,160 –> 00:23:24,560
Why security friction creates shadow it?
581
00:23:24,560 –> 00:23:27,360
This pattern repeats in organizations across industries.
582
00:23:27,360 –> 00:23:28,760
Let me explain why it happens.
583
00:23:28,760 –> 00:23:32,360
Technical security architects optimize for control and risk reduction.
584
00:23:32,360 –> 00:23:33,360
That’s their job.
585
00:23:33,360 –> 00:23:35,360
They’re asked to make the environment more secure.
586
00:23:35,360 –> 00:23:37,360
So they asked the right question from a security perspective.
587
00:23:37,360 –> 00:23:39,960
What’s the most restrictive policy we can enforce
588
00:23:39,960 –> 00:23:41,560
while still allowing work?
589
00:23:41,560 –> 00:23:43,160
But they don’t ask the follow-up question
590
00:23:43,160 –> 00:23:45,360
that governance architects need to ask.
591
00:23:45,360 –> 00:23:48,160
What will users do when they can’t work within these restrictions?
592
00:23:48,160 –> 00:23:51,160
Those are different questions and they lead to different answers.
593
00:23:51,160 –> 00:23:53,960
Conditional access policies that require specific devices
594
00:23:53,960 –> 00:23:54,960
like a corporate laptop,
595
00:23:54,960 –> 00:23:56,160
managed through Intune
596
00:23:56,160 –> 00:23:58,160
with specific security configurations,
597
00:23:58,160 –> 00:24:00,360
sound reasonable from a security standpoint.
598
00:24:00,360 –> 00:24:03,360
Your controlling which devices can access corporate resources.
599
00:24:03,360 –> 00:24:05,760
But if you exclude remote workers on home networks
600
00:24:05,760 –> 00:24:08,560
or contractors who don’t have access to corporate hardware
601
00:24:08,560 –> 00:24:10,160
or employees traveling internationally,
602
00:24:10,160 –> 00:24:11,360
you’ve created a problem.
603
00:24:11,360 –> 00:24:12,960
Those people still need to work.
604
00:24:12,960 –> 00:24:14,360
So they find workarounds.
605
00:24:14,360 –> 00:24:17,360
MFA prompts that trigger to frequently create a lured fatigue.
606
00:24:17,360 –> 00:24:18,960
The user sees the MFA notification.
607
00:24:18,960 –> 00:24:20,560
They approve it without thinking.
608
00:24:20,560 –> 00:24:22,560
Then they see another one and another one.
609
00:24:22,560 –> 00:24:25,560
Pretty soon they’re approving MFA prompts on autopilot
610
00:24:25,560 –> 00:24:28,760
without actually verifying that they initiated the request.
611
00:24:28,760 –> 00:24:31,760
An attacker sends a MFA push notification
612
00:24:31,760 –> 00:24:34,760
during a phishing attack the user approves it in muscle memory
613
00:24:34,760 –> 00:24:36,960
and you’ve just defeated your own security control.
614
00:24:36,960 –> 00:24:40,160
External sharing restrictions that prevent legitimate collaboration
615
00:24:40,160 –> 00:24:43,360
sound protective until you realize that a sales team actually needs
616
00:24:43,360 –> 00:24:45,160
to share documents with customers.
617
00:24:45,160 –> 00:24:47,960
A consultant needs to collaborate with a partner firm.
618
00:24:47,960 –> 00:24:49,960
A nonprofit needs to work with their board.
619
00:24:49,960 –> 00:24:51,960
You’ve restricted sharing so heavily
620
00:24:51,960 –> 00:24:53,960
that the business can’t actually operate
621
00:24:53,960 –> 00:24:57,360
so people use personal email or dropbox or Google Drive Sharedfolders
622
00:24:57,360 –> 00:25:00,960
or one drive links that they email from their personal Gmail account
623
00:25:00,960 –> 00:25:02,960
because corporate email has restrictions.
624
00:25:02,960 –> 00:25:06,560
The core insight is this, security that ignores operational reality
625
00:25:06,560 –> 00:25:08,360
creates operational insecurity.
626
00:25:08,360 –> 00:25:10,960
You’re designing controls for a theoretical organization
627
00:25:10,960 –> 00:25:12,960
that value security above all else.
628
00:25:12,960 –> 00:25:14,560
The actual organization needs to work.
629
00:25:14,560 –> 00:25:16,560
And when your security controls prevent work,
630
00:25:16,560 –> 00:25:18,560
you haven’t made the organization more secure.
631
00:25:18,560 –> 00:25:20,560
You forced it to operate outside your controls.
632
00:25:20,560 –> 00:25:22,360
Research tells us something interesting.
633
00:25:22,360 –> 00:25:24,560
Organizations estimate their employees use
634
00:25:24,560 –> 00:25:26,960
about 37 approved applications.
635
00:25:26,960 –> 00:25:30,760
The actual number they use is around 625 different apps.
636
00:25:30,760 –> 00:25:32,760
That’s a 17-fold discrepancy.
637
00:25:32,760 –> 00:25:33,960
That’s not a user problem.
638
00:25:33,960 –> 00:25:35,960
That’s a governance architecture problem.
639
00:25:35,960 –> 00:25:37,960
The technical solution of restricting access
640
00:25:37,960 –> 00:25:39,360
and implementing tighter controls
641
00:25:39,360 –> 00:25:40,960
doesn’t address the underlying problem.
642
00:25:40,960 –> 00:25:44,160
It makes it worse because when approval processes are too slow
643
00:25:44,160 –> 00:25:46,960
or technically rigid or require expertise
644
00:25:46,960 –> 00:25:48,960
users don’t have users solve their own problems.
645
00:25:48,960 –> 00:25:50,560
They find tools that work faster.
646
00:25:50,560 –> 00:25:53,560
They use SAS applications that don’t require IT approval.
647
00:25:53,560 –> 00:25:55,960
They adopt AI tools that make their job easier.
648
00:25:55,960 –> 00:25:57,160
They bypass the system.
649
00:25:57,160 –> 00:25:58,360
And here’s the uncomfortable part.
650
00:25:58,360 –> 00:26:00,360
The technical solution, more restrictions,
651
00:26:00,360 –> 00:26:03,360
actually increases the attack surface you’re trying to protect
652
00:26:03,360 –> 00:26:05,760
because now you have unknown applications
653
00:26:05,760 –> 00:26:06,760
accessing corporate data.
654
00:26:06,760 –> 00:26:08,960
You have unapproved integrations, you can’t monitor.
655
00:26:08,960 –> 00:26:11,760
You have file storage systems, you didn’t choose and can’t control.
656
00:26:11,760 –> 00:26:14,960
You have communication channels, you didn’t architect and can’t secure.
657
00:26:14,960 –> 00:26:17,160
An employee is using their personal Gmail,
658
00:26:17,160 –> 00:26:19,760
their personal Dropbox, their personal Slack workspace,
659
00:26:19,760 –> 00:26:21,560
their personal chat GPT account.
660
00:26:21,560 –> 00:26:23,760
If their personal account gets compromised,
661
00:26:23,760 –> 00:26:26,160
the attacker has access to corporate information
662
00:26:26,160 –> 00:26:28,560
and you have no visibility into where that data went
663
00:26:28,560 –> 00:26:30,160
or how it’s being used.
664
00:26:30,160 –> 00:26:32,760
The fortress didn’t make the organization more secure.
665
00:26:32,760 –> 00:26:34,560
It fragmented the security architecture.
666
00:26:34,560 –> 00:26:36,760
It pushed sensitive information outside the systems
667
00:26:36,760 –> 00:26:38,160
you can monitor and control.
668
00:26:38,160 –> 00:26:39,960
It created a shadow IT ecosystem
669
00:26:39,960 –> 00:26:41,760
that your security tools can’t see.
670
00:26:41,760 –> 00:26:43,560
That’s the paradox of security friction.
671
00:26:43,560 –> 00:26:45,560
The tighter you make legitimate workflows,
672
00:26:45,560 –> 00:26:47,560
the more you drive work outside those workflows.
673
00:26:47,560 –> 00:26:49,560
And the more work happens outside your controls,
674
00:26:49,560 –> 00:26:51,360
the more risk you’ve actually introduced.
675
00:26:51,360 –> 00:26:53,960
This is where intent-based governance becomes essential.
676
00:26:53,960 –> 00:26:56,960
Instead of asking what’s the most restrictive policy we can enforce,
677
00:26:56,960 –> 00:26:59,360
ask how do we protect sensitive data
678
00:26:59,360 –> 00:27:01,360
while enabling the organization to work?
679
00:27:01,360 –> 00:27:04,360
Those lead to completely different architecture.
680
00:27:04,360 –> 00:27:05,960
Case study 3.
681
00:27:05,960 –> 00:27:07,160
The co-pilot stall.
682
00:27:07,160 –> 00:27:09,160
The third failure pattern is newer,
683
00:27:09,160 –> 00:27:10,360
but it’s becoming the most common.
684
00:27:10,360 –> 00:27:11,760
I call it the co-pilot stall.
685
00:27:11,760 –> 00:27:13,960
Organizations pilot co-pilot with enthusiasm.
686
00:27:13,960 –> 00:27:15,760
Week 1, adoption metrics are impressive.
687
00:27:15,760 –> 00:27:18,160
Employees are excited about an AI assistant
688
00:27:18,160 –> 00:27:19,960
that understands their organization.
689
00:27:19,960 –> 00:27:21,560
Leadership approves the investment.
690
00:27:21,560 –> 00:27:22,560
The pilot expands.
691
00:27:22,560 –> 00:27:23,760
More users get licenses.
692
00:27:23,760 –> 00:27:24,960
More use cases emerge.
693
00:27:24,960 –> 00:27:27,760
Meeting recaps, email drafting, document generation.
694
00:27:27,760 –> 00:27:28,960
It all works.
695
00:27:28,960 –> 00:27:30,760
And then, between week 6 and 12,
696
00:27:30,760 –> 00:27:31,760
the rollout stops.
697
00:27:31,760 –> 00:27:33,160
Not because co-pilot is broken.
698
00:27:33,160 –> 00:27:34,760
Not because the technology failed.
699
00:27:34,760 –> 00:27:38,560
The rollout stops because AI instantly surfaces governance debt
700
00:27:38,560 –> 00:27:40,960
that the organization has been accumulating for years.
701
00:27:40,960 –> 00:27:42,960
Co-pilot doesn’t just answer questions.
702
00:27:42,960 –> 00:27:44,160
It aggregates data.
703
00:27:44,160 –> 00:27:45,160
It reads emails.
704
00:27:45,160 –> 00:27:46,560
It searches teams.
705
00:27:46,560 –> 00:27:48,160
It accesses SharePoint.
706
00:27:48,160 –> 00:27:49,560
It crawls one drive.
707
00:27:49,560 –> 00:27:53,760
It understands context across the entire Microsoft 365 environment.
708
00:27:53,760 –> 00:27:55,560
And when it starts surfacing information,
709
00:27:55,560 –> 00:27:58,360
it reveals things that were previously hidden by obscurity.
710
00:27:58,360 –> 00:27:59,760
Broken permissions.
711
00:27:59,760 –> 00:28:03,560
SharePoint sites where access is set to everyone in the organization.
712
00:28:03,560 –> 00:28:05,960
Documents shared via anyone with the link
713
00:28:05,960 –> 00:28:07,960
that have been circulating for two years.
714
00:28:07,960 –> 00:28:09,960
External sharing that was supposed to be restricted
715
00:28:09,960 –> 00:28:11,760
but never was because the defaults were permissive
716
00:28:11,760 –> 00:28:12,960
and no one enforced it.
717
00:28:12,960 –> 00:28:15,160
Guest accounts from partnerships that ended years ago
718
00:28:15,160 –> 00:28:17,560
still retaining access to sensitive files.
719
00:28:17,560 –> 00:28:19,760
Sensitivity labels that were never applied,
720
00:28:19,760 –> 00:28:21,760
retention policies that conflict with each other,
721
00:28:21,760 –> 00:28:23,760
all of this existed before co-pilot.
722
00:28:23,760 –> 00:28:25,160
The governance debt was real.
723
00:28:25,160 –> 00:28:27,560
But it was invisible because finding the information was hard.
724
00:28:27,560 –> 00:28:29,560
A document shared with everyone in the organization
725
00:28:29,560 –> 00:28:31,760
wasn’t a problem if nobody thought to search for it.
726
00:28:31,760 –> 00:28:33,960
An external link that exposed customer data
727
00:28:33,960 –> 00:28:35,760
wasn’t visible to the security team
728
00:28:35,760 –> 00:28:38,360
if they didn’t audit SharePoint links specifically.
729
00:28:38,360 –> 00:28:39,560
Permission sprawl existed,
730
00:28:39,560 –> 00:28:41,760
but it didn’t manifest as an operational problem
731
00:28:41,760 –> 00:28:43,660
because accessing that data at scale
732
00:28:43,660 –> 00:28:45,060
required deliberate effort.
733
00:28:45,060 –> 00:28:47,060
Co-pilot changes that calculus.
734
00:28:47,060 –> 00:28:50,060
An AI system can access and surface all of that information
735
00:28:50,060 –> 00:28:50,660
instantly.
736
00:28:50,660 –> 00:28:54,060
If an account is compromised and an attacker has co-pilot access,
737
00:28:54,060 –> 00:28:55,860
they can accelerate internal reconnaissance
738
00:28:55,860 –> 00:28:57,860
and sensitive data harvesting at scale.
739
00:28:57,860 –> 00:28:59,460
Ask co-pilot for customer contracts.
740
00:28:59,460 –> 00:29:01,760
Co-pilot searches SharePoint and OneDrive in Teams
741
00:29:01,760 –> 00:29:04,860
and finds them because access controls haven’t been enforced.
742
00:29:04,860 –> 00:29:06,660
Ask co-pilot for financial forecasts.
743
00:29:06,660 –> 00:29:10,060
Co-pilot surfaces them from shared drives and email attachments
744
00:29:10,060 –> 00:29:11,760
because they’ve been shared too broadly.
745
00:29:11,760 –> 00:29:14,660
Most organizations don’t discover they have permissions sprawl
746
00:29:14,660 –> 00:29:16,560
until co-pilot exposes it.
747
00:29:16,560 –> 00:29:19,860
Research tells us that around 73% of AI agent deployments
748
00:29:19,860 –> 00:29:22,360
fail to scale beyond pilots due to governance failures.
749
00:29:22,360 –> 00:29:24,660
Not technical failures, governance failures.
750
00:29:24,660 –> 00:29:27,060
The organizations running the pilots realize
751
00:29:27,060 –> 00:29:29,560
they have deeper infrastructure problems than they thought.
752
00:29:29,560 –> 00:29:30,760
Permissions sprawl,
753
00:29:30,760 –> 00:29:32,360
unmanaged external sharing,
754
00:29:32,360 –> 00:29:34,660
data that’s sensitive but classified as public.
755
00:29:34,660 –> 00:29:36,060
Files that should be restricted
756
00:29:36,060 –> 00:29:38,060
but are accessible to contractors or partners
757
00:29:38,060 –> 00:29:39,760
from years old partnerships
758
00:29:39,760 –> 00:29:41,660
and at that point leadership gets nervous.
759
00:29:41,660 –> 00:29:43,060
Security teams get nervous.
760
00:29:43,060 –> 00:29:44,660
If co-pilot can see this information,
761
00:29:44,660 –> 00:29:45,760
what can attack us see?
762
00:29:45,760 –> 00:29:47,560
What happens if an account gets compromised?
763
00:29:47,560 –> 00:29:50,160
What happens if external partners retain access to data
764
00:29:50,160 –> 00:29:51,660
we forgot about?
765
00:29:51,660 –> 00:29:52,660
The rollout stalls,
766
00:29:52,660 –> 00:29:55,660
while the organization tries to fix underlying governance problems
767
00:29:55,660 –> 00:29:57,660
but those problems are bigger and more pervasive
768
00:29:57,660 –> 00:29:58,660
than anyone realized,
769
00:29:58,660 –> 00:30:01,660
cleaning up permissions sprawl across thousands of SharePoint sites
770
00:30:01,660 –> 00:30:02,760
takes months.
771
00:30:02,760 –> 00:30:06,160
Auditing and removing inappropriate external sharing takes months.
772
00:30:06,160 –> 00:30:09,560
Enforcing sensitivity labels on existing content takes months
773
00:30:09,560 –> 00:30:11,960
by the time the organization is ready to scale co-pilot
774
00:30:11,960 –> 00:30:13,260
the pilot momentum is gone.
775
00:30:13,260 –> 00:30:15,660
Leadership has moved on to other priorities.
776
00:30:15,660 –> 00:30:17,060
The core inside is this.
777
00:30:17,060 –> 00:30:18,960
AI doesn’t create governance problems.
778
00:30:18,960 –> 00:30:20,460
It reveals them instantly.
779
00:30:20,460 –> 00:30:22,760
Most organizations have years of permissions sprawl
780
00:30:22,760 –> 00:30:24,160
that technical people ignored
781
00:30:24,160 –> 00:30:25,860
because the system was functioning.
782
00:30:25,860 –> 00:30:26,960
From a technical perspective,
783
00:30:26,960 –> 00:30:28,960
if people could access the files they needed,
784
00:30:28,960 –> 00:30:30,160
the system was working,
785
00:30:30,160 –> 00:30:32,560
permission management seemed like a compliance problem,
786
00:30:32,560 –> 00:30:33,660
not an operational one.
787
00:30:33,660 –> 00:30:35,760
So it was deferred, push to the next year.
788
00:30:35,760 –> 00:30:37,660
Treated as something to address eventually,
789
00:30:37,660 –> 00:30:38,660
then co-pilot arrives
790
00:30:38,660 –> 00:30:40,360
and makes the deferred problem urgent.
791
00:30:40,360 –> 00:30:42,260
The technical teams build co-pilot perfectly.
792
00:30:42,260 –> 00:30:43,460
The AI works beautifully.
793
00:30:43,460 –> 00:30:45,860
The integration with Microsoft 365 is seamless.
794
00:30:45,860 –> 00:30:47,060
The capability is real.
795
00:30:47,060 –> 00:30:49,760
But the organization wasn’t ready to operate it safely.
796
00:30:49,760 –> 00:30:51,560
The governance foundation wasn’t solid enough
797
00:30:51,560 –> 00:30:54,060
to support an AI system that could access everything.
798
00:30:54,060 –> 00:30:56,960
This is why the most dangerous moment in technology adoption
799
00:30:56,960 –> 00:30:59,260
is right before the capability gets deployed.
800
00:30:59,260 –> 00:31:01,960
That’s when your governance debt becomes visible.
801
00:31:01,960 –> 00:31:03,460
The permissions sprawl reality.
802
00:31:03,460 –> 00:31:04,860
To understand the co-pilot stall,
803
00:31:04,860 –> 00:31:06,560
you need to understand permissions sprawl
804
00:31:06,560 –> 00:31:07,960
and to understand permissions sprawl
805
00:31:07,960 –> 00:31:09,860
you have to understand how it accumulates.
806
00:31:09,860 –> 00:31:11,760
It’s not the result of a single bad decision.
807
00:31:11,760 –> 00:31:14,660
It’s the result of years of small, reasonable decisions
808
00:31:14,660 –> 00:31:16,460
that all point in the same direction.
809
00:31:16,460 –> 00:31:19,560
Someone creates a share point side for a project.
810
00:31:19,560 –> 00:31:21,760
The site privacy settings default to
811
00:31:21,760 –> 00:31:24,260
everyone in the organization can access this.
812
00:31:24,260 –> 00:31:25,760
That seems reasonable at the time.
813
00:31:25,760 –> 00:31:27,760
The project is organization wide.
814
00:31:27,760 –> 00:31:29,260
Everyone should be able to find it.
815
00:31:29,260 –> 00:31:30,660
So nobody changes the setting.
816
00:31:30,660 –> 00:31:32,260
Years later, the project is done.
817
00:31:32,260 –> 00:31:33,360
The site gets archived.
818
00:31:33,360 –> 00:31:34,560
But before it gets archived,
819
00:31:34,560 –> 00:31:37,060
someone uploads the latest customer contract there.
820
00:31:37,060 –> 00:31:38,960
Someone else stores the project budget.
821
00:31:38,960 –> 00:31:41,760
Another person archives client communications.
822
00:31:41,760 –> 00:31:44,960
All in a site set to everyone in the organization.
823
00:31:44,960 –> 00:31:46,760
Meanwhile, in one drive,
824
00:31:46,760 –> 00:31:49,560
a user shares a folder with anyone with the link.
825
00:31:49,560 –> 00:31:51,860
They’re collaborating with a consultant on a proposal.
826
00:31:51,860 –> 00:31:53,260
The link makes it easy to share.
827
00:31:53,260 –> 00:31:54,360
Both of them can edit.
828
00:31:54,360 –> 00:31:55,560
It works beautifully.
829
00:31:55,560 –> 00:31:57,460
The consultant finishes the engagement.
830
00:31:57,460 –> 00:31:59,760
The link gets forwarded to a friend at another company
831
00:31:59,760 –> 00:32:01,060
who’s starting a similar project.
832
00:32:01,060 –> 00:32:02,260
Nobody revokes the link
833
00:32:02,260 –> 00:32:04,060
because nobody remembers it exists.
834
00:32:04,060 –> 00:32:05,660
It’s still active, still accessible,
835
00:32:05,660 –> 00:32:09,060
still sharing whatever files the user added to that folder.
836
00:32:09,060 –> 00:32:11,860
In Teams, a channel is set to public by default.
837
00:32:11,860 –> 00:32:14,660
Team owners don’t have to explicitly allow access.
838
00:32:14,660 –> 00:32:16,860
Everyone in the organization can join.
839
00:32:16,860 –> 00:32:19,060
Someone posts a sensitive internal analysis.
840
00:32:19,060 –> 00:32:21,460
Someone else shares competitive intelligence.
841
00:32:21,460 –> 00:32:23,660
Someone posts salary information by accident.
842
00:32:23,660 –> 00:32:25,860
The default permissions don’t prevent any of this.
843
00:32:25,860 –> 00:32:27,560
Nobody has enforced a policy about
844
00:32:27,560 –> 00:32:30,560
what should be shared in public channels versus private channels.
845
00:32:30,560 –> 00:32:32,260
Permission inheritance in SharePoint
846
00:32:32,260 –> 00:32:34,860
gets broken through routine administrative tasks.
847
00:32:34,860 –> 00:32:36,660
The IT team creates a site template.
848
00:32:36,660 –> 00:32:38,460
They set permissions at the site level.
849
00:32:38,460 –> 00:32:40,960
A team adds a subfolder for sensitive documents.
850
00:32:40,960 –> 00:32:43,560
They think they’ve restricted access to that subfolder.
851
00:32:43,560 –> 00:32:45,360
But the permissions inheritance is broken.
852
00:32:45,360 –> 00:32:47,560
The folder inherits permissions from the parent site
853
00:32:47,560 –> 00:32:48,960
which is set to broad access.
854
00:32:48,960 –> 00:32:51,260
Nobody notices because the system is functioning.
855
00:32:51,260 –> 00:32:52,560
Files are accessible.
856
00:32:52,560 –> 00:32:53,660
People can do their jobs.
857
00:32:53,660 –> 00:32:54,660
These aren’t failures.
858
00:32:54,660 –> 00:32:56,860
Each decision made sense locally.
859
00:32:56,860 –> 00:32:58,760
Opening the site to everyone in the organization
860
00:32:58,760 –> 00:33:00,460
was the right call for that project.
861
00:33:00,460 –> 00:33:01,860
Using anyone with the link sharing
862
00:33:01,860 –> 00:33:03,760
was the right choice for that collaboration.
863
00:33:03,760 –> 00:33:05,660
Public teams channels are useful.
864
00:33:05,660 –> 00:33:08,960
Site level permissions are simpler than granular folder permissions.
865
00:33:08,960 –> 00:33:11,160
But over time, something that made sense
866
00:33:11,160 –> 00:33:13,660
individually becomes a problem systemically.
867
00:33:13,660 –> 00:33:15,660
Permissions sprawl is the accumulated result
868
00:33:15,660 –> 00:33:18,460
of years of just share it with everyone decisions
869
00:33:18,460 –> 00:33:19,960
layered on top of each other.
870
00:33:19,960 –> 00:33:22,160
The research is sobering.
871
00:33:22,160 –> 00:33:25,260
15% or more of business critical files are at risk
872
00:33:25,260 –> 00:33:27,660
due to oversharing or misconfigured access.
873
00:33:27,660 –> 00:33:28,760
That’s not a small number.
874
00:33:28,760 –> 00:33:29,860
That’s a structural problem.
875
00:33:29,860 –> 00:33:32,060
It means that across most large organizations
876
00:33:32,060 –> 00:33:33,960
a significant portion of sensitive data
877
00:33:33,960 –> 00:33:36,860
is accessible to people who shouldn’t have access to it.
878
00:33:36,860 –> 00:33:39,960
Not because of a breach, not because of a security vulnerability,
879
00:33:39,960 –> 00:33:41,260
because of permissions sprawl.
880
00:33:41,260 –> 00:33:43,660
Here’s what makes permissions sprawl invisible.
881
00:33:43,660 –> 00:33:45,460
When data is difficult to find,
882
00:33:45,460 –> 00:33:47,060
access doesn’t become a problem.
883
00:33:47,060 –> 00:33:49,960
A customer contract shared with everyone in the organization
884
00:33:49,960 –> 00:33:52,660
isn’t dangerous if finding that contract requires
885
00:33:52,660 –> 00:33:54,660
knowing the exact sharepoint site
886
00:33:54,660 –> 00:33:56,160
navigating to the right folder
887
00:33:56,160 –> 00:33:58,260
and searching through dozens of files.
888
00:33:58,260 –> 00:34:01,260
The access exists, but the information is practically hidden.
889
00:34:01,260 –> 00:34:03,460
So the security problem remains theoretical.
890
00:34:03,460 –> 00:34:06,060
But co-pilot makes all of it discoverable instantly.
891
00:34:06,060 –> 00:34:08,860
Ask co-pilot to summarize all customer contracts.
892
00:34:08,860 –> 00:34:10,660
Co-pilot searches, co-pilot finds them,
893
00:34:10,660 –> 00:34:12,460
co-pilot surfaces the information.
894
00:34:12,460 –> 00:34:14,060
The permission sprawl that was invisible
895
00:34:14,060 –> 00:34:15,760
becomes operationally obvious.
896
00:34:15,760 –> 00:34:18,160
Technical people often ignored permission sprawl
897
00:34:18,160 –> 00:34:19,460
for exactly this reason.
898
00:34:19,460 –> 00:34:20,660
The system was functioning.
899
00:34:20,660 –> 00:34:22,260
Users could access what they needed.
900
00:34:22,260 –> 00:34:23,460
Performance was fine.
901
00:34:23,460 –> 00:34:25,760
From a technical standpoint, everything was working.
902
00:34:25,760 –> 00:34:27,260
From a governance standpoint,
903
00:34:27,260 –> 00:34:29,360
the system had catastrophically failed.
904
00:34:29,360 –> 00:34:30,560
That distinction is crucial.
905
00:34:30,560 –> 00:34:32,460
A system that functions but can’t be controlled
906
00:34:32,460 –> 00:34:33,460
is not actually functioning.
907
00:34:33,460 –> 00:34:35,460
Permission sprawl isn’t a technical problem.
908
00:34:35,460 –> 00:34:36,960
It’s an architectural failure.
909
00:34:36,960 –> 00:34:38,860
The failure to design access controls
910
00:34:38,860 –> 00:34:41,660
that remain maintainable as the organization evolves.
911
00:34:41,660 –> 00:34:42,760
Case study 4.
912
00:34:42,760 –> 00:34:44,160
The identity collapse.
913
00:34:44,160 –> 00:34:46,660
The fourth failure pattern is perhaps the most insidious
914
00:34:46,660 –> 00:34:49,160
because it’s invisible until it becomes catastrophic.
915
00:34:49,160 –> 00:34:50,660
I call it the identity collapse.
916
00:34:50,660 –> 00:34:52,660
This one starts with good intentions.
917
00:34:52,660 –> 00:34:55,760
An organization builds out there as your AD instance.
918
00:34:55,760 –> 00:34:57,960
Now called EntraID with care.
919
00:34:57,960 –> 00:35:00,860
A few applications get integrated, a few hundred user accounts.
920
00:35:00,860 –> 00:35:02,560
Some basic administrative structure.
921
00:35:02,560 –> 00:35:03,560
Everything is clean.
922
00:35:03,560 –> 00:35:04,960
Everything is documented.
923
00:35:04,960 –> 00:35:06,560
Then the organization grows.
924
00:35:06,560 –> 00:35:08,160
Or they acquire another company.
925
00:35:08,160 –> 00:35:10,360
Or they integrate a new application ecosystem.
926
00:35:10,360 –> 00:35:11,860
And as your AD grows with it,
927
00:35:11,860 –> 00:35:12,660
five years later,
928
00:35:12,660 –> 00:35:15,460
the tenant has hundreds of applications integrated.
929
00:35:15,460 –> 00:35:18,360
Guest accounts from partnerships, contractors, vendors,
930
00:35:18,360 –> 00:35:19,460
thousands of them.
931
00:35:19,460 –> 00:35:21,960
Many from partnerships that ended years ago,
932
00:35:21,960 –> 00:35:24,360
Global Admin roles are scattered across the organization.
933
00:35:24,360 –> 00:35:25,360
The CIO has one.
934
00:35:25,360 –> 00:35:26,560
The IT director has one.
935
00:35:26,560 –> 00:35:28,060
The infrastructure lead has one.
936
00:35:28,060 –> 00:35:30,660
A couple of contractors who build custom integrations have one.
937
00:35:30,660 –> 00:35:32,960
Someone in finance who manages integrations has one.
938
00:35:32,960 –> 00:35:36,160
Someone in HR who manages employee lifecycle processes has one.
939
00:35:36,160 –> 00:35:37,260
Why so many global admins?
940
00:35:37,260 –> 00:35:41,360
Because Azure AD and Microsoft 365 use a centralized admin model.
941
00:35:41,360 –> 00:35:42,460
It’s all or nothing.
942
00:35:42,460 –> 00:35:45,660
You either have global admin rights and can do anything to anyone
943
00:35:45,660 –> 00:35:48,060
or you have limited permissions and can’t do your job.
944
00:35:48,060 –> 00:35:50,260
There’s no middle ground without significant effort.
945
00:35:50,260 –> 00:35:52,560
So when someone needs the ability to create security groups,
946
00:35:52,560 –> 00:35:54,860
the quickest solution is to give them global admin.
947
00:35:54,860 –> 00:35:57,760
When someone needs to manage app permissions, global admin.
948
00:35:57,760 –> 00:36:01,460
When someone needs to reset a password for a VIP global admin,
949
00:36:01,460 –> 00:36:04,360
pretty soon you have 10 or 15 people with global admin access.
950
00:36:04,360 –> 00:36:07,160
And the problem isn’t that these people are incompetent or malicious.
951
00:36:07,160 –> 00:36:11,260
The problem is that identity complexity has become invisible technical debt.
952
00:36:11,260 –> 00:36:12,560
Here’s the core issue.
953
00:36:12,560 –> 00:36:15,060
Technical people often grant global admin rights,
954
00:36:15,060 –> 00:36:16,360
not because it’s the right choice,
955
00:36:16,360 –> 00:36:21,060
but because the alternative designing granular role-based access control
956
00:36:21,060 –> 00:36:22,260
is too complex.
957
00:36:22,260 –> 00:36:25,160
A brilliant architect could sit down and design a perfect model.
958
00:36:25,160 –> 00:36:26,960
They could use Azure AD’s built in roles.
959
00:36:26,960 –> 00:36:29,860
They could create custom roles with granular permissions.
960
00:36:29,860 –> 00:36:31,460
They could design a delegation model
961
00:36:31,460 –> 00:36:34,660
where admins have just enough privilege to do their jobs and nothing more.
962
00:36:34,660 –> 00:36:36,860
That model would be theoretically perfect,
963
00:36:36,860 –> 00:36:40,460
but it would take weeks to design and months to implement and maintain.
964
00:36:40,460 –> 00:36:44,160
And the person who designed it would have to stay around to explain it to everyone else.
965
00:36:44,160 –> 00:36:46,760
It’s easier to just give people global admin and move on.
966
00:36:46,760 –> 00:36:50,460
That decision creates a system where anyone with global admin can do anything to anyone.
967
00:36:50,460 –> 00:36:53,460
They can read anyone’s email, they can access anyone’s files,
968
00:36:53,460 –> 00:36:56,260
they can change password policies, they can disable MFA,
969
00:36:56,260 –> 00:36:59,660
they can create new admin accounts, they can integrate malicious applications,
970
00:36:59,660 –> 00:37:02,160
they can modify conditional access policies.
971
00:37:02,160 –> 00:37:06,560
A single compromised GA account means the entire organization is compromised.
972
00:37:06,560 –> 00:37:07,660
And here’s what happens next.
973
00:37:07,660 –> 00:37:09,460
When admin complexity increases,
974
00:37:09,460 –> 00:37:11,760
organizations don’t grant less privilege.
975
00:37:11,760 –> 00:37:16,860
They grant more because the only way to solve the problem of too many admins with too much power is to
976
00:37:16,860 –> 00:37:19,860
give more people too much power so you have redundancy.
977
00:37:20,860 –> 00:37:23,060
Research tells us something striking.
978
00:37:23,060 –> 00:37:27,660
90% of organizations grant excessive administrative privileges in Microsoft 365.
979
00:37:27,660 –> 00:37:29,260
90% that’s not an outlier.
980
00:37:29,260 –> 00:37:30,060
That’s the norm.
981
00:37:30,060 –> 00:37:34,760
That’s the natural outcome of the centralized admin model combined with the complexity of the platform.
982
00:37:34,760 –> 00:37:36,960
The identity collapse isn’t a technical failure.
983
00:37:36,960 –> 00:37:40,060
It’s an architectural failure to design sustainable delegation.
984
00:37:40,060 –> 00:37:42,860
A brilliant architect can design role-based access control.
985
00:37:42,860 –> 00:37:44,560
That’s theoretically perfect.
986
00:37:44,560 –> 00:37:47,060
But if the organization can’t sustain that design,
987
00:37:47,060 –> 00:37:51,260
if it requires constant maintenance, if it’s too complex for other admins to understand,
988
00:37:51,260 –> 00:37:54,460
if it creates bottlenecks that force people to work around it,
989
00:37:54,460 –> 00:37:55,860
then the design has failed.
990
00:37:55,860 –> 00:37:57,960
The collapse identity architecture is the symptom.
991
00:37:57,960 –> 00:38:02,260
The root cause is an admin model that forces a choice between perfect controls
992
00:38:02,260 –> 00:38:06,060
that are un-maintainable or simple controls that are dangerously permissive.
993
00:38:06,060 –> 00:38:07,960
Most organizations choose permissive.
994
00:38:07,960 –> 00:38:10,060
And they pay for it with identity sprawl.
995
00:38:10,060 –> 00:38:15,260
This is different from the other failures because it’s not about a specific capability implemented poorly.
996
00:38:15,260 –> 00:38:20,260
It’s about a fundamental architectural assumption that didn’t survive contact with organizational reality.
997
00:38:20,260 –> 00:38:23,060
Microsoft 365 assumes you’ll design granular delegation.
998
00:38:23,060 –> 00:38:28,260
It gives you the tools, but it doesn’t acknowledge that designing those controls requires expertise and ongoing effort.
999
00:38:28,260 –> 00:38:31,460
So most organizations just hand out global admin and hope nothing goes wrong.
1000
00:38:31,460 –> 00:38:33,660
By the time the organization realizes they have a problem,
1001
00:38:33,660 –> 00:38:37,960
usually because an admin account gets compromised or an audit reveals excessive privilege,
1002
00:38:37,960 –> 00:38:42,060
the identity architecture has collapsed so far that fixing it requires months of work.
1003
00:38:42,060 –> 00:38:44,560
And the worst part, the original architects weren’t wrong.
1004
00:38:44,560 –> 00:38:46,160
They were solving the problem they were given.
1005
00:38:46,160 –> 00:38:50,060
They were just solving it in a way that created a bigger problem down the line.
1006
00:38:50,060 –> 00:38:52,560
Why technical people misgovernance problems?
1007
00:38:52,560 –> 00:38:56,560
Now let’s step back and understand why brilliant technical people create these failures.
1008
00:38:56,560 –> 00:38:58,760
It’s not malice, it’s not incompetence.
1009
00:38:58,760 –> 00:39:02,760
It’s a difference in how technical minds and governance minds frame problems.
1010
00:39:02,760 –> 00:39:06,760
Technical thinking is optimized for solving defined problems with measurable solutions.
1011
00:39:06,760 –> 00:39:11,260
You have a problem. You analyze it, you design a solution, you implement it, you measure whether it works.
1012
00:39:11,260 –> 00:39:16,260
Success is binary, either it works or it doesn’t, either the flow processes invoices correctly or it doesn’t.
1013
00:39:16,260 –> 00:39:20,260
Either the conditional access policy blocks unauthorized access or it doesn’t.
1014
00:39:20,260 –> 00:39:24,260
Either the role-based access control model grants the right permissions or it doesn’t.
1015
00:39:24,260 –> 00:39:26,160
Governance is fundamentally different.
1016
00:39:26,160 –> 00:39:30,360
Governance is about preventing undefined future problems through architectural design.
1017
00:39:30,360 –> 00:39:34,660
The problem isn’t defined yet, you’re trying to anticipate what might go wrong three years from now.
1018
00:39:34,660 –> 00:39:38,560
You’re trying to design structures that will survive when requirements change.
1019
00:39:38,560 –> 00:39:43,460
You’re trying to create systems that people you’ve never met will be able to understand and maintain.
1020
00:39:43,460 –> 00:39:47,260
These are fundamentally different cognitive tasks and they require different thinking.
1021
00:39:47,260 –> 00:39:51,460
Technical excellence creates a particular blindness when you’ve designed something perfectly.
1022
00:39:51,460 –> 00:39:55,960
When the configuration is elegant, when the logic is sound, when the system works beautifully on day one,
1023
00:39:55,960 –> 00:39:57,660
you have confidence in that solution.
1024
00:39:57,660 –> 00:40:03,460
That confidence is justified. You’ve done your job well, but that same confidence can mask governance blindness
1025
00:40:03,460 –> 00:40:06,360
because technically the solution is correct. Performance is optimal.
1026
00:40:06,360 –> 00:40:10,160
The controls work as designed. It’s easy to conclude that the problem is solved.
1027
00:40:10,160 –> 00:40:12,960
But here’s the truth. A perfectly configured tenant is seductive.
1028
00:40:12,960 –> 00:40:17,260
It creates the impression that you’ve solved a governance problem when you’ve only solved a technical problem.
1029
00:40:17,260 –> 00:40:20,060
Governance isn’t solved. It’s continuously maintained.
1030
00:40:20,060 –> 00:40:22,560
You don’t build a governance model and declare it complete.
1031
00:40:22,560 –> 00:40:27,960
You build a governance model and then you spend the next five years adapting it as the organization evolves.
1032
00:40:27,960 –> 00:40:30,160
Requirements change. Technology changes.
1033
00:40:30,160 –> 00:40:33,460
People leave and new people arrive. Business units reorganize.
1034
00:40:33,460 –> 00:40:35,260
New applications get integrated.
1035
00:40:35,260 –> 00:40:40,560
New compliance requirements emerge. A governance architecture that doesn’t evolve is a governance architecture that’s failing.
1036
00:40:40,560 –> 00:40:46,060
Technical people often treat governance as a checklist, create policies, document them, move on.
1037
00:40:46,060 –> 00:40:50,860
You’ve done your job. Now governance is someone else’s responsibility, but that’s not how governance works.
1038
00:40:50,860 –> 00:40:55,360
Governance is a living system. It requires continuous oversight. It requires regular adaptation.
1039
00:40:55,360 –> 00:40:57,860
It requires someone to ask, is this policy still working?
1040
00:40:57,860 –> 00:41:00,460
Not just was this policy created?
1041
00:41:00,460 –> 00:41:03,860
The best technical architects I’ve worked with are the ones who learn to think in systems.
1042
00:41:03,860 –> 00:41:07,460
They didn’t stop thinking technically. They didn’t become less competent engineers.
1043
00:41:07,460 –> 00:41:09,260
But they learn to ask a different question.
1044
00:41:09,260 –> 00:41:12,260
A brilliant architect asks, does this work today?
1045
00:41:12,260 –> 00:41:15,760
A governance architect asks, what will this decision look like in three years?
1046
00:41:15,760 –> 00:41:19,060
That’s the shift. Will this be maintainable when the person who built it leaves?
1047
00:41:19,060 –> 00:41:22,260
Will this make sense to someone reading the documentation six months from now?
1048
00:41:22,260 –> 00:41:26,660
Will this decision scale to 200 SharePoint sites or 200 Power Automate flows?
1049
00:41:26,660 –> 00:41:28,860
What happens when the business requirement changes?
1050
00:41:28,860 –> 00:41:30,760
What happens when the technology gets updated?
1051
00:41:30,760 –> 00:41:34,960
What happens when the organization grows? Those are governance questions. They’re not sexy.
1052
00:41:34,960 –> 00:41:37,160
They don’t require deep technical knowledge.
1053
00:41:37,160 –> 00:41:39,360
They require thinking about operational reality.
1054
00:41:39,360 –> 00:41:43,960
They require humble acknowledgement that perfect technical solutions often create imperfect human problems.
1055
00:41:43,960 –> 00:41:48,560
The shift from technical thinking to architectural thinking is the shift from, can we do this?
1056
00:41:48,560 –> 00:41:51,860
To, should we do this? And who manages it in three years?
1057
00:41:51,860 –> 00:41:55,060
Most technical people never make that shift. They’re not taught to.
1058
00:41:55,060 –> 00:41:58,660
The incentive systems reward technical excellence, not governance durability.
1059
00:41:58,660 –> 00:42:04,160
A brilliant architecture that works beautifully for three years and collapses in year four doesn’t get credit for the three years.
1060
00:42:04,160 –> 00:42:05,960
It gets blamed for the collapse.
1061
00:42:05,960 –> 00:42:13,460
But the architects who learn to think about organizational reality instead of just technical perfection are the ones who create systems that actually survive.
1062
00:42:13,460 –> 00:42:17,060
They design for the organization that exists, not the one they wish existed.
1063
00:42:17,060 –> 00:42:19,960
They ask uncomfortable questions about maintainability.
1064
00:42:19,960 –> 00:42:24,260
They accept that perfect technical solutions sometimes need to be compromised to be sustainable.
1065
00:42:24,260 –> 00:42:33,160
That distinction between technical excellence and governance durability is the line between creating great systems and creating systems that organizations can actually operate.
1066
00:42:33,160 –> 00:42:34,860
The intent-based governance shift.
1067
00:42:34,860 –> 00:42:37,860
This is where we move from diagnosing failures to preventing them.
1068
00:42:37,860 –> 00:42:41,460
Most organizations approach governance backwards. They start with implementation.
1069
00:42:41,460 –> 00:42:44,860
They ask, what settings should we configure? What policies should we write?
1070
00:42:44,860 –> 00:42:46,360
What controls should we deploy?
1071
00:42:46,360 –> 00:42:52,860
And they end up with a document that describes the configuration along with a set of controls that will drift from that documentation within six months
1072
00:42:52,860 –> 00:42:55,660
because the world changed and the documentation didn’t.
1073
00:42:55,660 –> 00:42:58,060
Intent-based governance inverts that question.
1074
00:42:58,060 –> 00:43:00,660
Instead of starting with implementation, you start with intent.
1075
00:43:00,660 –> 00:43:03,660
You ask, what behavior do we want the system to enforce?
1076
00:43:03,660 –> 00:43:05,460
Not forever, because forever is a lie.
1077
00:43:05,460 –> 00:43:08,660
But over the time horizon, that matters for your organization.
1078
00:43:08,660 –> 00:43:11,860
Over the next three years, over the next business cycle.
1079
00:43:11,860 –> 00:43:14,860
This shift changes everything about how architecture is designed.
1080
00:43:14,860 –> 00:43:18,460
Configuration thinking leads to policy documents that drift from reality.
1081
00:43:18,460 –> 00:43:22,860
You write a policy, you say external sharing is restricted to approved domains.
1082
00:43:22,860 –> 00:43:24,660
That’s specific. That’s measurable.
1083
00:43:24,660 –> 00:43:26,260
That’s a configuration you can implement.
1084
00:43:26,260 –> 00:43:30,860
But six months later, a business unit needs to share with a partner that’s not on the approved list.
1085
00:43:30,860 –> 00:43:32,860
The request and exception, you add the exception.
1086
00:43:32,860 –> 00:43:35,460
Six months later, another request, another exception.
1087
00:43:35,460 –> 00:43:41,160
After a year, your approved domains list has grown to include so many domains that it’s functionally unrestricted.
1088
00:43:41,160 –> 00:43:42,660
The policy document says one thing.
1089
00:43:42,660 –> 00:43:44,260
The configuration does something else.
1090
00:43:44,260 –> 00:43:46,660
The actual behavior is a third thing entirely.
1091
00:43:46,660 –> 00:43:50,660
Intent-based thinking leads to principles that guide decision making over time.
1092
00:43:50,660 –> 00:43:54,260
Instead of saying external sharing is restricted to approved domains,
1093
00:43:54,260 –> 00:43:59,260
ask, how do we enable legitimate collaboration while protecting sensitive data?
1094
00:43:59,260 –> 00:44:01,560
That’s a principle. It’s not a specific configuration.
1095
00:44:01,560 –> 00:44:04,460
It’s a question that should guide every external sharing decision.
1096
00:44:04,460 –> 00:44:08,560
How do we balance the business need for collaboration with the security need for protection?
1097
00:44:08,560 –> 00:44:10,660
That principle can be implemented in multiple ways.
1098
00:44:10,660 –> 00:44:15,860
You could use approved domains. You could use sensitivity labels to restrict what data can be shared externally.
1099
00:44:15,860 –> 00:44:19,560
You could use conditional access to verify the external user’s identity.
1100
00:44:19,560 –> 00:44:24,360
You could use DLP policies to prevent sensitive data from leaving the organization.
1101
00:44:24,360 –> 00:44:26,260
You could use a combination of all of these.
1102
00:44:26,260 –> 00:44:29,360
The principle doesn’t prescribe the implementation. It guides it.
1103
00:44:29,360 –> 00:44:33,460
The first statement, external sharing is restricted to approved domains.
1104
00:44:33,460 –> 00:44:37,760
Is a configuration that will be circumvented the moment it conflicts with a business need.
1105
00:44:37,760 –> 00:44:41,860
The second statement, we enable collaboration while protecting sensitive data,
1106
00:44:41,860 –> 00:44:44,660
is an intent that can guide multiple configurations.
1107
00:44:44,660 –> 00:44:48,060
And when you need to change the configuration because a business requirement evolved,
1108
00:44:48,060 –> 00:44:50,460
you can adapt it without changing the principle.
1109
00:44:50,460 –> 00:44:55,460
Intent-based governance is more durable than configuration thinking because it survives configuration changes.
1110
00:44:55,460 –> 00:44:59,860
When you know the intent, you can adapt the implementation as the organization evolves.
1111
00:44:59,860 –> 00:45:01,960
A new business partner joins your organization.
1112
00:45:01,960 –> 00:45:05,660
They’re not on the approved domains list, but they’re a legitimate collaborator.
1113
00:45:05,660 –> 00:45:09,560
The principle says enable collaboration while protecting sensitive data.
1114
00:45:09,560 –> 00:45:12,060
So you add the domain. You haven’t violated the principle.
1115
00:45:12,060 –> 00:45:16,460
You’ve applied it to a new circumstance. Configuration thinking can’t do that without creating policy drift.
1116
00:45:16,460 –> 00:45:20,260
Intent-based thinking can do it without abandoning the governance model.
1117
00:45:20,260 –> 00:45:24,460
This is the fundamental shift from technical architecture to governance architecture.
1118
00:45:24,460 –> 00:45:26,960
Technical architecture optimizes for capability.
1119
00:45:26,960 –> 00:45:29,060
How do we build the most sophisticated system?
1120
00:45:29,060 –> 00:45:30,860
How do we automate the most processes?
1121
00:45:30,860 –> 00:45:33,460
How do we create the most granular access controls?
1122
00:45:33,460 –> 00:45:35,860
Governance architecture optimizes for durability.
1123
00:45:35,860 –> 00:45:36,860
How do we build a system?
1124
00:45:36,860 –> 00:45:39,060
The organization can still operate in three years.
1125
00:45:39,060 –> 00:45:42,260
How do we design governance that survives when requirements change?
1126
00:45:42,260 –> 00:45:46,860
How do we create principles that guide decision making when we can’t predict every future scenario?
1127
00:45:46,860 –> 00:45:49,060
Most organizations never make this shift.
1128
00:45:49,060 –> 00:45:53,060
They hire a brilliant technical architect that architect designs perfect configurations.
1129
00:45:53,060 –> 00:45:55,360
They document them meticulously. They hand it off.
1130
00:45:55,360 –> 00:45:59,260
And the organization tries to operate that perfect system in the real world
1131
00:45:59,260 –> 00:46:03,460
where business requirements change every quarter and technology evolves every month.
1132
00:46:03,460 –> 00:46:07,260
The system gradually becomes un maintainable, not because the original design was flawed,
1133
00:46:07,260 –> 00:46:11,460
but because the design was optimized for a fictional organization, not the real one.
1134
00:46:11,460 –> 00:46:15,460
Intent-based governance works because it acknowledges a fundamental truth.
1135
00:46:15,460 –> 00:46:19,860
You can’t predict the future. You don’t know what business requirements will emerge three years from now.
1136
00:46:19,860 –> 00:46:23,660
You don’t know what new technology will need to integrate with Microsoft 365.
1137
00:46:23,660 –> 00:46:26,260
You don’t know what compliance requirement will be imposed.
1138
00:46:26,260 –> 00:46:30,460
But you can define principles that will guide good decisions even when circumstances change.
1139
00:46:30,460 –> 00:46:31,460
That’s the shift.
1140
00:46:31,460 –> 00:46:37,660
From how do we configure this perfectly today to how do we design principles that will guide this organization sustainably?
1141
00:46:37,660 –> 00:46:38,660
Hmm.
1142
00:46:38,660 –> 00:46:41,060
Designing for durability, not just capability.
1143
00:46:41,060 –> 00:46:44,060
Durability is the metric that technical people often miss.
1144
00:46:44,060 –> 00:46:48,460
And it’s the metric that determines whether a system survives or whether it quietly collapses.
1145
00:46:48,460 –> 00:46:51,860
A system is durable if the organization can still operate it in three years.
1146
00:46:51,860 –> 00:46:54,060
Not on day one, not with perfect conditions.
1147
00:46:54,060 –> 00:46:57,860
Three years from now with different people with change requirements with evolved technology,
1148
00:46:57,860 –> 00:47:03,060
can the organization still maintain this system? Can someone who didn’t build it understand how it works?
1149
00:47:03,060 –> 00:47:06,260
Can it adapt when circumstances change? That’s durability.
1150
00:47:06,260 –> 00:47:09,060
Durability requires clarity about three things.
1151
00:47:09,060 –> 00:47:09,860
Ownership.
1152
00:47:09,860 –> 00:47:13,660
Someone must be accountable for this system, not just initially but continuously.
1153
00:47:13,660 –> 00:47:17,460
Life cycle management, the system must have mechanisms to age gracefully,
1154
00:47:17,460 –> 00:47:21,060
to archive what’s no longer needed to retire, what’s obsolete.
1155
00:47:21,060 –> 00:47:22,460
And continuous monitoring.
1156
00:47:22,460 –> 00:47:25,860
Someone must be watching whether the system is still achieving its intent,
1157
00:47:25,860 –> 00:47:29,260
not just whether it’s technically functioning. Here’s where the tension emerges.
1158
00:47:29,260 –> 00:47:32,460
Technical excellence and durability are often in opposition.
1159
00:47:32,460 –> 00:47:34,860
The most capable system is often the least durable.
1160
00:47:34,860 –> 00:47:37,460
Why? Because it requires constant technical intervention.
1161
00:47:37,460 –> 00:47:40,060
It requires the architect who designed it to stay engaged.
1162
00:47:40,060 –> 00:47:41,860
It requires specialized expertise.
1163
00:47:41,860 –> 00:47:46,060
It requires people to understand subtle dependencies and complex configurations.
1164
00:47:46,060 –> 00:47:50,860
A perfectly optimized system that only the original architect understands is brilliant on day one
1165
00:47:50,860 –> 00:47:53,660
and unmentainable on day 431.
1166
00:47:53,660 –> 00:47:58,260
The most durable system is often less capable. It trades some functionality for simplicity.
1167
00:47:58,260 –> 00:48:00,860
It accepts good enough instead of perfect. It asks,
1168
00:48:00,860 –> 00:48:03,660
“Do we need this feature if it doubles the complexity?”
1169
00:48:03,660 –> 00:48:06,460
It designs for the lowest common denominator of expertise.
1170
00:48:06,460 –> 00:48:09,460
It documents extensively because it knows the person maintaining it
1171
00:48:09,460 –> 00:48:11,060
won’t have the designer’s context.
1172
00:48:11,060 –> 00:48:14,460
Governance architecture finds the balance between those two extremes.
1173
00:48:14,460 –> 00:48:17,060
Not maximum capability, not maximum simplicity,
1174
00:48:17,060 –> 00:48:18,860
the right capability for the organization,
1175
00:48:18,860 –> 00:48:21,060
the right complexity the organization can sustain.
1176
00:48:21,060 –> 00:48:23,660
And that balance is different for every organization.
1177
00:48:23,660 –> 00:48:28,660
A small organization that’s growing fast might need more capability and can tolerate less durability
1178
00:48:28,660 –> 00:48:31,860
because the person who built the system is still there, they can adapt quickly.
1179
00:48:31,860 –> 00:48:35,460
A large enterprise organization that moves slowly might need less capability
1180
00:48:35,460 –> 00:48:38,860
but much more durability because the person who built the system left years ago
1181
00:48:38,860 –> 00:48:42,660
and the system is operated by people who have 800 other responsibilities.
1182
00:48:42,660 –> 00:48:45,660
Technical people often push toward maximum capability
1183
00:48:45,660 –> 00:48:47,660
without considering the durability cost.
1184
00:48:47,660 –> 00:48:51,460
They ask, “What’s possible? What’s the most sophisticated thing we can build?
1185
00:48:51,460 –> 00:48:53,060
What’s the most elegant solution?”
1186
00:48:53,060 –> 00:48:55,860
Those are good questions, but they’re not governance questions.
1187
00:48:55,860 –> 00:48:57,860
Governance architects ask a different question.
1188
00:48:57,860 –> 00:49:00,060
They ask, “What’s the minimum capability we need?
1189
00:49:00,060 –> 00:49:01,660
Not what’s possible? What’s necessary?”
1190
00:49:01,660 –> 00:49:05,260
And then they ask, “What’s the maximum complexity we can sustain?”
1191
00:49:05,260 –> 00:49:06,060
Not forever.
1192
00:49:06,060 –> 00:49:08,660
Over the next three to five years with the people we have,
1193
00:49:08,660 –> 00:49:10,860
with the expertise we can realistically maintain,
1194
00:49:10,860 –> 00:49:12,860
how much complexity can we actually manage?
1195
00:49:12,860 –> 00:49:13,660
Those two questions,
1196
00:49:13,660 –> 00:49:16,460
minimum capability and maximum sustainable complexity
1197
00:49:16,460 –> 00:49:18,060
completely reframe the architecture.
1198
00:49:18,060 –> 00:49:20,860
Instead of asking, “How sophisticated can we make this?”
1199
00:49:20,860 –> 00:49:24,660
you ask, “How simple can we make this while still solving the problem?”
1200
00:49:24,660 –> 00:49:29,060
Instead of designing for an ideal state where everything is perfectly configured and optimized,
1201
00:49:29,060 –> 00:49:32,660
you design for the realistic state where things degrade over time
1202
00:49:32,660 –> 00:49:36,860
and someone needs to be able to fix them without calling the original architect.
1203
00:49:36,860 –> 00:49:39,260
This reframing prevents the failures we’ve discussed.
1204
00:49:39,260 –> 00:49:41,260
The automation hydra doesn’t emerge if you ask,
1205
00:49:41,260 –> 00:49:44,460
“What’s the maximum number of flows we can sustain and actually monitor?”
1206
00:49:44,460 –> 00:49:47,260
Not unlimited, not as many as we want.
1207
00:49:47,260 –> 00:49:49,660
A specific number that the organization can manage,
1208
00:49:49,660 –> 00:49:51,260
500 flows? Maybe,
1209
00:49:51,260 –> 00:49:52,960
5,000 flows with no ownership?
1210
00:49:52,960 –> 00:49:56,060
No, that exceeds the organization’s capacity to maintain it.
1211
00:49:56,060 –> 00:49:58,460
The security fortress doesn’t get built if you ask,
1212
00:49:58,460 –> 00:50:02,060
“What’s the minimum control we need while still protecting sensitive data?”
1213
00:50:02,060 –> 00:50:03,260
Not maximum control.
1214
00:50:03,260 –> 00:50:07,260
Minimum. What’s the simplest policy that achieves the security goal while staying operable?
1215
00:50:07,260 –> 00:50:09,060
The copilot stall doesn’t happen if you ask,
1216
00:50:09,060 –> 00:50:11,860
“What’s our governance capacity before we deploy AI at scale?”
1217
00:50:11,860 –> 00:50:14,660
Not what’s technically possible. What can we actually sustain?
1218
00:50:14,660 –> 00:50:16,660
Do we have permission governance under control?
1219
00:50:16,660 –> 00:50:18,660
Do we have sensitivity labels applied?
1220
00:50:18,660 –> 00:50:21,060
Do we have a process for managing external access?
1221
00:50:21,060 –> 00:50:24,660
If not, scale the AI slower while you build the governance foundation.
1222
00:50:24,660 –> 00:50:27,060
The identity collapse doesn’t occur if you ask,
1223
00:50:27,060 –> 00:50:29,860
“What delegation model can we actually maintain?”
1224
00:50:29,860 –> 00:50:32,260
Not the theoretically perfect R-back model,
1225
00:50:32,260 –> 00:50:35,860
a model that’s simple enough that other people can understand it and sustain it.
1226
00:50:35,860 –> 00:50:37,460
Durability changes everything.
1227
00:50:37,460 –> 00:50:39,060
It converts the question from,
1228
00:50:39,060 –> 00:50:42,660
“How good can we make this to how good can we make this and still manage it?”
1229
00:50:42,660 –> 00:50:46,660
And that’s the question that separates architects who build systems from architects
1230
00:50:46,660 –> 00:50:49,460
who build systems that organizations can actually operate.
1231
00:50:49,460 –> 00:50:51,460
The role of organizational readiness.
1232
00:50:51,460 –> 00:50:53,860
Technical failures, often mask organizational failures.
1233
00:50:53,860 –> 00:50:54,660
Let me explain.
1234
00:50:54,660 –> 00:50:58,860
When a Microsoft 365 deployment goes sideways,
1235
00:50:58,860 –> 00:51:01,460
the first instinct is to blame the technology.
1236
00:51:01,460 –> 00:51:03,060
The system is too complex.
1237
00:51:03,060 –> 00:51:04,660
The platform has too many features.
1238
00:51:04,660 –> 00:51:06,060
The configuration is difficult.
1239
00:51:06,060 –> 00:51:07,460
Those are real frustrations.
1240
00:51:07,460 –> 00:51:09,060
But they’re often not the actual problem.
1241
00:51:09,060 –> 00:51:13,060
The actual problem is that the organization wasn’t ready to operate the capability.
1242
00:51:13,060 –> 00:51:16,260
An organization is ready for a capability when it can sustain it over time.
1243
00:51:16,260 –> 00:51:18,260
Not on day one with perfect conditions
1244
00:51:18,260 –> 00:51:21,060
and the person who designed it standing by to explain everything.
1245
00:51:21,060 –> 00:51:23,460
Three months in, six months in, a year in.
1246
00:51:23,460 –> 00:51:26,660
When the original project team has moved on to other priorities
1247
00:51:26,660 –> 00:51:29,060
and someone new is trying to understand how it works.
1248
00:51:29,060 –> 00:51:30,260
That’s when readiness matters.
1249
00:51:30,260 –> 00:51:32,260
Readiness includes five specific things.
1250
00:51:32,260 –> 00:51:33,460
First, clear ownership.
1251
00:51:33,460 –> 00:51:36,260
Someone is explicitly responsible for this system.
1252
00:51:36,260 –> 00:51:37,860
Not IT generally.
1253
00:51:37,860 –> 00:51:39,860
Not a team that has eight other responsibilities.
1254
00:51:39,860 –> 00:51:43,860
A person or a small team that owns this capability
1255
00:51:43,860 –> 00:51:45,860
and knows they’ll be held accountable if it fails.
1256
00:51:45,860 –> 00:51:47,860
Second, documented processes.
1257
00:51:47,860 –> 00:51:49,060
Not just the configuration.
1258
00:51:49,060 –> 00:51:51,460
But the process, how do people request access?
1259
00:51:51,460 –> 00:51:53,060
How do you onboard a new user?
1260
00:51:53,060 –> 00:51:54,260
What’s the approval workflow?
1261
00:51:54,260 –> 00:51:56,660
Who decides whether something is working or not?
1262
00:51:56,660 –> 00:51:57,860
Third, training.
1263
00:51:57,860 –> 00:52:00,260
People who operate the system understand it.
1264
00:52:00,260 –> 00:52:01,460
They know what it’s supposed to do.
1265
00:52:01,460 –> 00:52:03,460
They know how to troubleshoot basic problems.
1266
00:52:03,460 –> 00:52:05,460
They know who to call when something breaks.
1267
00:52:05,460 –> 00:52:06,660
Fourth, monitoring.
1268
00:52:06,660 –> 00:52:08,660
Someone is continuously watching the system.
1269
00:52:08,660 –> 00:52:09,460
Usage metrics.
1270
00:52:09,460 –> 00:52:10,660
Configuration drift.
1271
00:52:10,660 –> 00:52:11,860
Policy exceptions.
1272
00:52:11,860 –> 00:52:12,660
Performance.
1273
00:52:12,660 –> 00:52:15,060
Someone’s job includes keeping an eye on this.
1274
00:52:15,060 –> 00:52:16,260
Fifth, governance.
1275
00:52:16,260 –> 00:52:18,660
There’s a governance model that guides decisions.
1276
00:52:18,660 –> 00:52:20,260
It’s not just policy documents.
1277
00:52:20,260 –> 00:52:22,660
It’s a living framework that helps people
1278
00:52:22,660 –> 00:52:25,460
make the right decision when circumstances change.
1279
00:52:25,460 –> 00:52:27,460
Most organizations deploy capabilities
1280
00:52:27,460 –> 00:52:29,860
before they’re ready for any of those five things.
1281
00:52:29,860 –> 00:52:32,660
Technical people often deploy because the technology is ready.
1282
00:52:32,660 –> 00:52:34,260
The configuration is perfect.
1283
00:52:34,260 –> 00:52:35,460
The feature works beautifully.
1284
00:52:35,460 –> 00:52:37,460
From a technical standpoint, you can deploy.
1285
00:52:37,460 –> 00:52:38,260
So you do.
1286
00:52:38,260 –> 00:52:39,860
But the organization isn’t ready.
1287
00:52:39,860 –> 00:52:41,060
Nobody’s been assigned to own it.
1288
00:52:41,060 –> 00:52:43,860
There’s no documented process for how it’s going to be used.
1289
00:52:43,860 –> 00:52:45,860
Training happened in a two-hour demo.
1290
00:52:45,860 –> 00:52:47,860
Nobody’s monitoring whether it’s actually working.
1291
00:52:47,860 –> 00:52:50,660
And there’s no governance model for how decisions will be made
1292
00:52:50,660 –> 00:52:52,260
when the configuration needs to change.
1293
00:52:52,260 –> 00:52:55,460
This creates a gap, a gap between deployment and adoption.
1294
00:52:55,460 –> 00:52:57,060
Between the technical capability existing
1295
00:52:57,060 –> 00:52:59,860
and the organization being able to actually operate it.
1296
00:52:59,860 –> 00:53:01,060
That gap doesn’t stay empty.
1297
00:53:01,060 –> 00:53:03,460
It gets filled with shadow IT, workarounds,
1298
00:53:03,460 –> 00:53:04,660
and technical debt.
1299
00:53:04,660 –> 00:53:06,260
Users can’t figure out how to use the system.
1300
00:53:06,260 –> 00:53:07,660
So they use something else.
1301
00:53:07,660 –> 00:53:10,660
They can’t get access because the approval process is undefined.
1302
00:53:10,660 –> 00:53:12,260
So they find a workaround.
1303
00:53:12,260 –> 00:53:14,660
They can’t maintain the system because there’s no owner.
1304
00:53:14,660 –> 00:53:16,060
So they let it degrade.
1305
00:53:16,060 –> 00:53:17,860
They can’t make decisions about how to adapt it
1306
00:53:17,860 –> 00:53:19,460
because there’s no governance model.
1307
00:53:19,460 –> 00:53:20,660
So they just let it drift.
1308
00:53:20,660 –> 00:53:22,660
The gap between readiness and deployment
1309
00:53:22,660 –> 00:53:24,660
becomes invisible technical debt.
1310
00:53:24,660 –> 00:53:25,860
Here’s the research on this.
1311
00:53:25,860 –> 00:53:29,060
82% of IT leaders describe managing Microsoft 365
1312
00:53:29,060 –> 00:53:30,660
as a severe operational burden.
1313
00:53:30,660 –> 00:53:32,260
That statistic isn’t surprising
1314
00:53:32,260 –> 00:53:35,060
if you understand organizational readiness.
1315
00:53:35,060 –> 00:53:36,660
They’re trying to operate a capability
1316
00:53:36,660 –> 00:53:38,260
the organization was never ready for.
1317
00:53:38,260 –> 00:53:40,460
The burden isn’t because the technology is complex.
1318
00:53:40,460 –> 00:53:42,460
The burden is because the organization is trying
1319
00:53:42,460 –> 00:53:44,660
to maintain something without clear ownership,
1320
00:53:44,660 –> 00:53:46,660
without documented processes,
1321
00:53:46,660 –> 00:53:49,460
without dedicated monitoring, without a governance model.
1322
00:53:49,460 –> 00:53:51,060
This is why technical excellence
1323
00:53:51,060 –> 00:53:54,860
without governance creates the worst Microsoft 365 tenants.
1324
00:53:54,860 –> 00:53:57,860
A brilliant architect can deploy the most sophisticated capability.
1325
00:53:57,860 –> 00:53:59,660
The configuration can be perfect.
1326
00:53:59,660 –> 00:54:01,460
The system can be elegantly designed.
1327
00:54:01,460 –> 00:54:03,660
But if the organization isn’t ready to own it,
1328
00:54:03,660 –> 00:54:05,260
to maintain it, to govern it,
1329
00:54:05,260 –> 00:54:07,260
then that beautiful technical system
1330
00:54:07,260 –> 00:54:08,660
becomes an operational burden.
1331
00:54:08,660 –> 00:54:11,260
Governance architecture includes organizational readiness
1332
00:54:11,260 –> 00:54:13,660
as a prerequisite for capability deployment.
1333
00:54:13,660 –> 00:54:15,860
You don’t deploy until the organization is ready.
1334
00:54:15,860 –> 00:54:18,660
You don’t deploy until you have someone assigned to own it.
1335
00:54:18,660 –> 00:54:21,260
You don’t deploy until you have documented processes.
1336
00:54:21,260 –> 00:54:23,060
You don’t deploy until you have a governance model.
1337
00:54:23,060 –> 00:54:25,260
You deploy when the organization has the capacity
1338
00:54:25,260 –> 00:54:26,460
to sustain the capability.
1339
00:54:26,460 –> 00:54:28,660
That’s a completely different deployment model
1340
00:54:28,660 –> 00:54:30,460
than most organizations use.
1341
00:54:30,460 –> 00:54:33,260
But it’s the only model that prevents the failures we’ve discussed.
1342
00:54:33,260 –> 00:54:35,460
It’s the only model where technical excellence
1343
00:54:35,460 –> 00:54:37,660
actually translates into organizational value
1344
00:54:37,660 –> 00:54:39,460
instead of organizational burden.
1345
00:54:39,460 –> 00:54:42,060
Identifying governance debt in your tenant.
1346
00:54:42,060 –> 00:54:44,060
If you want to know whether your Microsoft tenant
1347
00:54:44,060 –> 00:54:45,660
will survive the next five years,
1348
00:54:45,660 –> 00:54:47,060
start with this assessment.
1349
00:54:47,060 –> 00:54:49,260
Governance debt is different from technical debt.
1350
00:54:49,260 –> 00:54:50,860
Technical debt is something you see.
1351
00:54:50,860 –> 00:54:53,060
A broken feature, a performance issue,
1352
00:54:53,060 –> 00:54:54,260
a security vulnerability.
1353
00:54:54,260 –> 00:54:55,260
You can point to it.
1354
00:54:55,260 –> 00:54:56,260
You can measure it.
1355
00:54:56,260 –> 00:54:59,460
Governance debt is invisible until it manifests as a crisis.
1356
00:54:59,460 –> 00:55:01,460
Governance debt accumulates silently.
1357
00:55:01,460 –> 00:55:03,660
A team is created without a documented owner.
1358
00:55:03,660 –> 00:55:05,060
That’s fine. It’s one team.
1359
00:55:05,060 –> 00:55:07,260
But six months later, the owner leaves the organization
1360
00:55:07,260 –> 00:55:08,260
and nobody notices.
1361
00:55:08,260 –> 00:55:09,460
The team is now orphaned.
1362
00:55:09,460 –> 00:55:11,260
No one knows who should be maintaining it.
1363
00:55:11,260 –> 00:55:12,660
No one knows what data lives there.
1364
00:55:12,660 –> 00:55:14,860
No one knows if external users still have access.
1365
00:55:14,860 –> 00:55:15,860
That’s governance debt.
1366
00:55:15,860 –> 00:55:16,660
It’s not visible.
1367
00:55:16,660 –> 00:55:17,860
The team still exists.
1368
00:55:17,860 –> 00:55:19,460
It’s still taking up storage.
1369
00:55:19,460 –> 00:55:20,860
But it’s no longer being governed.
1370
00:55:20,860 –> 00:55:22,660
Multiply that across hundreds of teams.
1371
00:55:22,660 –> 00:55:24,260
Thousands of SharePoint sites.
1372
00:55:24,260 –> 00:55:25,060
Millions of files.
1373
00:55:25,060 –> 00:55:27,260
Governance debt becomes invisible technical debt
1374
00:55:27,260 –> 00:55:29,660
that’s slowly consuming organizational resources
1375
00:55:29,660 –> 00:55:30,660
and creating risk.
1376
00:55:30,660 –> 00:55:33,460
Here are the key categories of governance debt to look for.
1377
00:55:33,460 –> 00:55:35,060
Identity debt is the most dangerous.
1378
00:55:35,060 –> 00:55:36,460
How many global admins do you have?
1379
00:55:36,460 –> 00:55:38,460
Microsoft recommends fewer than five.
1380
00:55:38,460 –> 00:55:40,460
If you have 20, you have identity debt.
1381
00:55:40,460 –> 00:55:43,060
How many guest accounts exist in your organization?
1382
00:55:43,060 –> 00:55:44,460
Are you actively managing them?
1383
00:55:44,460 –> 00:55:46,260
Or are they accumulating from partnerships
1384
00:55:46,260 –> 00:55:47,260
that ended years ago?
1385
00:55:47,260 –> 00:55:48,260
That’s identity debt.
1386
00:55:48,260 –> 00:55:49,860
How many app registrations do you have?
1387
00:55:49,860 –> 00:55:51,260
Do you know what permissions they have?
1388
00:55:51,260 –> 00:55:52,860
Do you know if they’re still being used?
1389
00:55:52,860 –> 00:55:54,460
That’s identity debt.
1390
00:55:54,460 –> 00:55:56,260
Collaboration debt is pervasive.
1391
00:55:56,260 –> 00:55:58,260
Do all your teams have documented owners?
1392
00:55:58,260 –> 00:56:01,260
If you have 500 teams and only 80% have documented owners
1393
00:56:01,260 –> 00:56:03,260
that’s 100 teams with unclear ownership.
1394
00:56:03,260 –> 00:56:04,460
That’s governance debt.
1395
00:56:04,460 –> 00:56:06,660
Do you have inactive teams that should be archived?
1396
00:56:06,660 –> 00:56:08,460
A team that hasn’t had a message in a year
1397
00:56:08,460 –> 00:56:10,060
still consumes storage?
1398
00:56:10,060 –> 00:56:11,460
It still shows up in search results.
1399
00:56:11,460 –> 00:56:14,060
It’s still a place where external access might be lingering.
1400
00:56:14,060 –> 00:56:15,060
That’s debt.
1401
00:56:15,060 –> 00:56:17,060
Do you have SharePoint sites that nobody can explain?
1402
00:56:17,060 –> 00:56:19,660
Sites that were created for a project that ended years ago
1403
00:56:19,660 –> 00:56:20,860
but never got archived?
1404
00:56:20,860 –> 00:56:21,660
That’s debt.
1405
00:56:21,660 –> 00:56:23,660
Do you have clear policies about external sharing?
1406
00:56:23,660 –> 00:56:26,060
Or have external sharing restrictions drifted
1407
00:56:26,060 –> 00:56:27,860
so far from the original policy
1408
00:56:27,860 –> 00:56:30,060
that you don’t even recognize the configuration anymore?
1409
00:56:30,060 –> 00:56:31,060
That’s debt.
1410
00:56:31,060 –> 00:56:32,860
Automation debt accumulates fast.
1411
00:56:32,860 –> 00:56:35,260
How many power-automate flows exist in your organization?
1412
00:56:35,260 –> 00:56:36,260
Can you list them?
1413
00:56:36,260 –> 00:56:37,260
Do you know who owns each one?
1414
00:56:37,260 –> 00:56:38,660
Do you know what data they access?
1415
00:56:38,660 –> 00:56:40,660
Do you know the dependencies between flows?
1416
00:56:40,660 –> 00:56:43,060
If you have 500 flows and nobody can explain them,
1417
00:56:43,060 –> 00:56:44,660
you have massive automation debt.
1418
00:56:44,660 –> 00:56:46,660
Data debt is often the most consequential.
1419
00:56:46,660 –> 00:56:48,860
What percentage of your files have sensitivity labels?
1420
00:56:48,860 –> 00:56:51,460
If most of your sensitive data is unlabeled,
1421
00:56:51,460 –> 00:56:52,660
you have data debt.
1422
00:56:52,660 –> 00:56:54,460
Do you have retention policies applied?
1423
00:56:54,460 –> 00:56:56,260
Or are files living indefinitely
1424
00:56:56,260 –> 00:56:58,660
because nobody defined how long they should be kept?
1425
00:56:58,660 –> 00:56:59,460
That’s debt.
1426
00:56:59,460 –> 00:57:01,460
Do you have uncontrolled external sharing?
1427
00:57:01,460 –> 00:57:04,260
Links that say anyone with this link can access it?
1428
00:57:04,260 –> 00:57:07,060
Shared folders that have been forwarded to third parties?
1429
00:57:07,060 –> 00:57:08,060
That’s data debt.
1430
00:57:08,060 –> 00:57:10,060
Here’s what the research tells us.
1431
00:57:10,060 –> 00:57:12,260
45% of large organizations experience
1432
00:57:12,260 –> 00:57:14,060
the security or compliance incident
1433
00:57:14,060 –> 00:57:16,660
caused by misconfiguration in the past 12 months.
1434
00:57:16,660 –> 00:57:18,060
That’s not a technical incident.
1435
00:57:18,060 –> 00:57:20,260
That’s governance debt manifesting as a crisis.
1436
00:57:20,260 –> 00:57:22,860
Someone deployed co-pilot and it exposed oversharing.
1437
00:57:22,860 –> 00:57:25,660
Someone was compromised and had excessive permissions.
1438
00:57:25,660 –> 00:57:27,060
Someone tried to do an access review
1439
00:57:27,060 –> 00:57:29,860
and discovered they had no idea what permissions actually existed.
1440
00:57:29,860 –> 00:57:32,860
That’s governance debt that became operationally visible.
1441
00:57:32,860 –> 00:57:34,660
The earlier you identify governance debt,
1442
00:57:34,660 –> 00:57:36,060
the easier it is to address.
1443
00:57:36,060 –> 00:57:38,660
Governance debt discovered in a pilot program is fixable.
1444
00:57:38,660 –> 00:57:41,060
Governance debt discovered during a breach investigation
1445
00:57:41,060 –> 00:57:42,260
is catastrophic.
1446
00:57:42,260 –> 00:57:44,460
Most organizations don’t measure governance debt
1447
00:57:44,460 –> 00:57:45,660
until it becomes a crisis.
1448
00:57:45,660 –> 00:57:48,060
They’re operating in darkness, hoping nothing breaks,
1449
00:57:48,060 –> 00:57:49,060
until something does.
1450
00:57:49,060 –> 00:57:51,460
This is where the non-technical perspective becomes essential.
1451
00:57:51,460 –> 00:57:54,660
You don’t need to be a technical expert to identify governance debt.
1452
00:57:54,660 –> 00:57:56,260
You need to ask simple questions.
1453
00:57:56,260 –> 00:57:57,060
Who owns this?
1454
00:57:57,060 –> 00:57:58,060
Is there a process?
1455
00:57:58,060 –> 00:57:59,060
Is someone monitoring it?
1456
00:57:59,060 –> 00:58:00,660
Can someone explain how it works?
1457
00:58:00,660 –> 00:58:03,460
If you can’t answer those questions, you have governance debt.
1458
00:58:03,460 –> 00:58:04,860
That’s your baseline assessment.
1459
00:58:04,860 –> 00:58:06,260
Honest answers to those questions
1460
00:58:06,260 –> 00:58:08,060
tell you whether your tenant is managed
1461
00:58:08,060 –> 00:58:09,860
or whether it’s quietly accumulating debt
1462
00:58:09,860 –> 00:58:12,460
that will eventually become a crisis.
1463
00:58:12,460 –> 00:58:14,260
The tenant durability checklist.
1464
00:58:14,260 –> 00:58:16,260
Here’s a practical tool you can use immediately
1465
00:58:16,260 –> 00:58:18,060
to assess your governance architecture.
1466
00:58:18,060 –> 00:58:19,660
This isn’t a compliance checklist.
1467
00:58:19,660 –> 00:58:21,860
This isn’t something you’re doing to pass an audit.
1468
00:58:21,860 –> 00:58:23,460
This is a durability assessment.
1469
00:58:23,460 –> 00:58:26,060
It tells you whether your tenant will survive the next five years.
1470
00:58:26,060 –> 00:58:27,060
Start with identity.
1471
00:58:27,060 –> 00:58:28,460
How many global admins do you have?
1472
00:58:28,460 –> 00:58:30,260
Microsoft recommends fewer than five.
1473
00:58:30,260 –> 00:58:32,260
If you can’t answer that question with certainty,
1474
00:58:32,260 –> 00:58:33,260
you have a problem.
1475
00:58:33,260 –> 00:58:34,260
If the answer is more than ten,
1476
00:58:34,260 –> 00:58:35,860
you have a serious problem.
1477
00:58:35,860 –> 00:58:38,060
Do you have a privileged access management strategies?
1478
00:58:38,060 –> 00:58:39,460
If the answer is what’s that,
1479
00:58:39,460 –> 00:58:40,460
then you don’t.
1480
00:58:40,460 –> 00:58:41,460
And you need one.
1481
00:58:41,460 –> 00:58:44,860
How many unmanaged guest accounts exist in your environment?
1482
00:58:44,860 –> 00:58:46,660
The number should be declining, not growing.
1483
00:58:46,660 –> 00:58:48,660
If you have guest accounts from partnerships
1484
00:58:48,660 –> 00:58:49,860
that ended three years ago,
1485
00:58:49,860 –> 00:58:51,260
still sitting in your directory,
1486
00:58:51,260 –> 00:58:52,860
that’s identity debt you need to address.
1487
00:58:52,860 –> 00:58:54,060
Move to collaboration.
1488
00:58:54,060 –> 00:58:55,860
Do all your teams have documented owners?
1489
00:58:55,860 –> 00:58:57,660
The answer should be 100%.
1490
00:58:57,660 –> 00:58:59,860
Not 95%, not most of them.
1491
00:58:59,860 –> 00:59:00,860
All of them.
1492
00:59:00,860 –> 00:59:03,060
If you have teams without clear ownership,
1493
00:59:03,060 –> 00:59:04,460
you have often spaces.
1494
00:59:04,460 –> 00:59:07,260
Do you have life cycle policies for inactive teams?
1495
00:59:07,260 –> 00:59:07,860
You should.
1496
00:59:07,860 –> 00:59:09,460
Teams that haven’t had activity in 90 days
1497
00:59:09,460 –> 00:59:10,660
should trigger a review.
1498
00:59:10,660 –> 00:59:12,660
They should either be renewed or archived.
1499
00:59:12,660 –> 00:59:15,060
What percentage of your sharepoint sites are often?
1500
00:59:15,060 –> 00:59:16,060
The answer should be zero.
1501
00:59:16,060 –> 00:59:18,460
If you have often sites, you’re carrying dead weight.
1502
00:59:18,460 –> 00:59:19,460
Your storing data,
1503
00:59:19,460 –> 00:59:20,660
you’re not actively managing.
1504
00:59:20,660 –> 00:59:23,460
Your potentially exposing information you’ve forgotten about.
1505
00:59:23,460 –> 00:59:24,460
Look at automation.
1506
00:59:24,460 –> 00:59:27,660
Does every power automate flow have documented ownership?
1507
00:59:27,660 –> 00:59:29,260
Again, the answer should be 100%.
1508
00:59:29,260 –> 00:59:31,860
If you have flows floating around with no clear owner,
1509
00:59:31,860 –> 00:59:33,060
you have automation debt.
1510
00:59:33,060 –> 00:59:35,260
Do you monitor flow failures and performance?
1511
00:59:35,260 –> 00:59:36,860
You should know when a flow fails.
1512
00:59:36,860 –> 00:59:38,860
You should know if performance is degrading.
1513
00:59:38,860 –> 00:59:41,860
If you’re running hundreds of flows and you have no visibility
1514
00:59:41,860 –> 00:59:43,260
into whether they’re actually working,
1515
00:59:43,260 –> 00:59:45,460
you’ve lost control of your automation platform.
1516
00:59:45,460 –> 00:59:46,860
Assess your data.
1517
00:59:46,860 –> 00:59:49,260
What percentage of files have sensitivity labels?
1518
00:59:49,260 –> 00:59:50,860
The number should be increasing over time.
1519
00:59:50,860 –> 00:59:53,860
If it’s declining or if it’s stuck at a low percentage,
1520
00:59:53,860 –> 00:59:55,860
you haven’t built a data governance practice.
1521
00:59:55,860 –> 00:59:57,460
Do you have external sharing policies?
1522
00:59:57,460 –> 00:59:59,260
Not do you allow external sharing?
1523
00:59:59,260 –> 01:00:01,260
Do you have clear documented policies
1524
01:00:01,260 –> 01:00:03,060
about how external sharing works?
1525
01:00:03,060 –> 01:00:04,060
When is it allowed?
1526
01:00:04,060 –> 01:00:05,660
What can be shared with whom?
1527
01:00:05,660 –> 01:00:08,460
If you can’t articulate your external sharing policy clearly,
1528
01:00:08,460 –> 01:00:10,260
your external sharing is out of control.
1529
01:00:10,260 –> 01:00:11,260
Look at AI readiness.
1530
01:00:11,260 –> 01:00:13,460
Have you assessed permission sprawl in your environment?
1531
01:00:13,460 –> 01:00:14,660
You don’t need to have fixed it.
1532
01:00:14,660 –> 01:00:16,660
But you should at least know what you’re dealing with.
1533
01:00:16,660 –> 01:00:18,460
Do you have a data classification strategy?
1534
01:00:18,460 –> 01:00:20,060
Before you deploy AI at scale,
1535
01:00:20,060 –> 01:00:23,260
you need to know what data is sensitive and what data is not.
1536
01:00:23,260 –> 01:00:25,060
If you don’t have a classification strategy,
1537
01:00:25,060 –> 01:00:26,460
you’re not ready for co-pilot.
1538
01:00:26,460 –> 01:00:27,460
You’re not ready for agents.
1539
01:00:27,460 –> 01:00:29,460
You’re not ready for AI-driven analytics.
1540
01:00:29,460 –> 01:00:30,860
You need that foundation first.
1541
01:00:30,860 –> 01:00:32,460
This checklist isn’t about compliance
1542
01:00:32,460 –> 01:00:34,460
that you’re not doing this to satisfy an auditor
1543
01:00:34,460 –> 01:00:36,260
or pass a security assessment.
1544
01:00:36,260 –> 01:00:38,660
You’re doing this because every question on this list
1545
01:00:38,660 –> 01:00:41,060
determines whether your organization can sustain
1546
01:00:41,060 –> 01:00:43,060
its Microsoft 365 environment.
1547
01:00:43,060 –> 01:00:46,060
If you can answer every question clearly with the should be answer,
1548
01:00:46,060 –> 01:00:47,860
your governance architecture is solid.
1549
01:00:47,860 –> 01:00:48,860
You have durability.
1550
01:00:48,860 –> 01:00:50,260
You have clarity about ownership.
1551
01:00:50,260 –> 01:00:51,660
You have lifecycle management.
1552
01:00:51,660 –> 01:00:52,460
You have monitoring.
1553
01:00:52,460 –> 01:00:54,460
You have policies that are actually being followed.
1554
01:00:54,460 –> 01:00:57,260
You have a foundation that can sustain the platform as it evolves.
1555
01:00:57,260 –> 01:00:59,860
If you can’t answer most of these questions clearly
1556
01:00:59,860 –> 01:01:02,460
or if your answers don’t match the should be standard,
1557
01:01:02,460 –> 01:01:04,260
then your governance architecture is weak.
1558
01:01:04,260 –> 01:01:06,260
That doesn’t mean your technical setup is broken.
1559
01:01:06,260 –> 01:01:07,860
It means you’re carrying governance debt.
1560
01:01:07,860 –> 01:01:10,060
You’re operating in a system where clarity is missing.
1561
01:01:10,060 –> 01:01:11,660
Where ownership is ambiguous.
1562
01:01:11,660 –> 01:01:14,460
Where monitoring is happening by accident instead of by design.
1563
01:01:14,460 –> 01:01:16,460
Where policies are drifting from reality.
1564
01:01:16,460 –> 01:01:19,460
That’s the difference between a managed tenant and an unmanaged one.
1565
01:01:19,460 –> 01:01:20,860
Not whether the technology works,
1566
01:01:20,860 –> 01:01:23,060
whether the organization can actually operate it.
1567
01:01:23,060 –> 01:01:25,460
Moving from configuration to intent.
1568
01:01:25,460 –> 01:01:27,460
Let me walk you through how to make the shift
1569
01:01:27,460 –> 01:01:30,260
from configuration thinking to intent-based governance.
1570
01:01:30,260 –> 01:01:32,260
This is where the abstraction becomes practical.
1571
01:01:32,260 –> 01:01:34,060
Most organizations never do this shift.
1572
01:01:34,060 –> 01:01:36,460
They follow their current approach and call it governance.
1573
01:01:36,460 –> 01:01:38,460
But there’s a five-step framework
1574
01:01:38,460 –> 01:01:40,460
that changes everything about how you design
1575
01:01:40,460 –> 01:01:41,860
sustainable architecture.
1576
01:01:41,860 –> 01:01:43,860
Step one is deceptively simple.
1577
01:01:43,860 –> 01:01:46,860
Identify the intent behind each major governance area.
1578
01:01:46,860 –> 01:01:48,660
Not the configuration, the intent.
1579
01:01:48,660 –> 01:01:50,060
What are we actually trying to achieve?
1580
01:01:50,060 –> 01:01:52,260
Instead of starting with reinforce MFA,
1581
01:01:52,260 –> 01:01:55,260
ask what behavior do we want to enforce around authentication?
1582
01:01:55,260 –> 01:01:57,660
That’s different. MFA is an implementation detail.
1583
01:01:57,660 –> 01:01:58,660
It’s a control.
1584
01:01:58,660 –> 01:02:01,060
But the behavior you’re trying to enforce might be
1585
01:02:01,060 –> 01:02:04,260
users are authenticated based on risk, not just identity.
1586
01:02:04,260 –> 01:02:07,660
Or critical accounts require stronger authentication
1587
01:02:07,660 –> 01:02:08,860
than standard accounts.
1588
01:02:08,860 –> 01:02:11,260
Or systems should adapt authentication requirements
1589
01:02:11,260 –> 01:02:12,260
based on context.
1590
01:02:12,260 –> 01:02:14,660
Those are intents. MFA supports those intents.
1591
01:02:14,660 –> 01:02:16,060
But MFA isn’t the intent itself.
1592
01:02:16,060 –> 01:02:18,660
This distinction matters because intents are durable.
1593
01:02:18,660 –> 01:02:20,060
Controls are temporary.
1594
01:02:20,060 –> 01:02:22,460
Step two is designing principles that express intent
1595
01:02:22,460 –> 01:02:24,460
without prescribing implementation.
1596
01:02:24,460 –> 01:02:26,660
A principle is a statement that guides decisions
1597
01:02:26,660 –> 01:02:29,660
without dictating exactly how you implement it.
1598
01:02:29,660 –> 01:02:32,260
For authentication, a principle might be
1599
01:02:32,260 –> 01:02:34,460
we authenticate users based on risk,
1600
01:02:34,460 –> 01:02:35,860
not just identity.
1601
01:02:35,860 –> 01:02:38,260
That’s a principle. It’s not a specific configuration.
1602
01:02:38,260 –> 01:02:39,860
It acknowledges that we’re not treating
1603
01:02:39,860 –> 01:02:42,060
all authentication requests the same.
1604
01:02:42,060 –> 01:02:43,860
A user logging in from their home computer
1605
01:02:43,860 –> 01:02:47,260
on the corporate network at 9 a.m. gets one level of scrutiny.
1606
01:02:47,260 –> 01:02:50,260
A user logging in from a VPN from a new device at 3 a.m. gets
1607
01:02:50,260 –> 01:02:52,660
different scrutiny, same principle.
1608
01:02:52,660 –> 01:02:54,460
Different implementation.
1609
01:02:54,460 –> 01:02:55,660
Another principle.
1610
01:02:55,660 –> 01:02:58,860
We balance security friction with operational usability.
1611
01:02:58,860 –> 01:03:00,260
That one acknowledges the tension.
1612
01:03:00,260 –> 01:03:02,860
You’re not maximizing security at the expense of work.
1613
01:03:02,860 –> 01:03:03,860
You’re finding the balance.
1614
01:03:03,860 –> 01:03:06,860
What that balance is depends on the user, the application,
1615
01:03:06,860 –> 01:03:09,060
the risk, the principle guides the decision.
1616
01:03:09,060 –> 01:03:10,260
It doesn’t prescribe it.
1617
01:03:10,260 –> 01:03:12,260
Step three is defining configurations
1618
01:03:12,260 –> 01:03:13,460
that support the principle.
1619
01:03:13,460 –> 01:03:16,060
This is where you move from principle to implementation.
1620
01:03:16,060 –> 01:03:18,260
What specific controls policies, settings
1621
01:03:18,260 –> 01:03:20,260
will help you achieve this principle.
1622
01:03:20,260 –> 01:03:22,460
For we authenticate users based on risk,
1623
01:03:22,460 –> 01:03:25,460
your configurations might include conditional access policies
1624
01:03:25,460 –> 01:03:27,460
that increase authentication requirements
1625
01:03:27,460 –> 01:03:29,260
for high-risk scenarios.
1626
01:03:29,260 –> 01:03:32,460
MFA requirements for users accessing sensitive data,
1627
01:03:32,460 –> 01:03:34,260
device compliance checks that verify the device
1628
01:03:34,260 –> 01:03:35,860
meet security baselines.
1629
01:03:35,860 –> 01:03:38,260
Location-based access rules that adjust requirements
1630
01:03:38,260 –> 01:03:39,860
for unfamiliar locations.
1631
01:03:39,860 –> 01:03:42,660
Usage analytics that identify anomalous behavior
1632
01:03:42,660 –> 01:03:44,460
and trigger additional authentication.
1633
01:03:44,460 –> 01:03:47,860
You’re not saying we require MFA for everyone always.
1634
01:03:47,860 –> 01:03:51,660
You’re saying we require MFA contextually based on risk.
1635
01:03:51,660 –> 01:03:53,060
The configuration is flexible.
1636
01:03:53,060 –> 01:03:54,260
It adapts.
1637
01:03:54,260 –> 01:03:56,460
Step four is building feedback loops that measure
1638
01:03:56,460 –> 01:03:58,260
whether the principle is being achieved.
1639
01:03:58,260 –> 01:04:01,260
You’re not measuring whether the configuration is in place.
1640
01:04:01,260 –> 01:04:04,060
You’re measuring whether the actual behavior is what you intended.
1641
01:04:04,060 –> 01:04:06,260
Are users authenticated appropriately?
1642
01:04:06,260 –> 01:04:09,060
Are legitimate users able to work without excessive friction?
1643
01:04:09,060 –> 01:04:10,060
Are attacks being blocked?
1644
01:04:10,060 –> 01:04:12,660
Is the system still usable or have you overengineered it?
1645
01:04:12,660 –> 01:04:14,060
Those are the questions you’re answering.
1646
01:04:14,060 –> 01:04:17,660
The answers tell you whether your principle is being achieved in practice.
1647
01:04:17,660 –> 01:04:20,460
Step five is evolving the configuration based on feedback
1648
01:04:20,460 –> 01:04:21,860
without changing the principle.
1649
01:04:21,860 –> 01:04:23,260
This is where durability lives.
1650
01:04:23,260 –> 01:04:24,460
A year into deployment,
1651
01:04:24,460 –> 01:04:26,660
you discover that your conditional access policies
1652
01:04:26,660 –> 01:04:28,460
are blocking legitimate business travel.
1653
01:04:28,460 –> 01:04:30,860
Remote workers signing in from hotel networks
1654
01:04:30,860 –> 01:04:32,260
are getting too much scrutiny.
1655
01:04:32,260 –> 01:04:33,860
They’re having trouble accessing files
1656
01:04:33,860 –> 01:04:35,060
that the configuration isn’t working,
1657
01:04:35,060 –> 01:04:38,460
but the principle authenticate based on risk is still valid.
1658
01:04:38,460 –> 01:04:40,260
You don’t abandon the principle.
1659
01:04:40,260 –> 01:04:41,460
You adjust the configuration.
1660
01:04:41,460 –> 01:04:43,060
You refine the risk calculations.
1661
01:04:43,060 –> 01:04:46,060
You add exceptions for legitimate remote work scenarios.
1662
01:04:46,060 –> 01:04:49,260
You evolve the implementation while keeping the principle intact.
1663
01:04:49,260 –> 01:04:51,660
Technical people often skip steps one and two.
1664
01:04:51,660 –> 01:04:53,060
They jump straight to step three.
1665
01:04:53,060 –> 01:04:55,260
They ask what configurations should we deploy?
1666
01:04:55,260 –> 01:04:56,660
Without understanding intent,
1667
01:04:56,660 –> 01:04:57,860
without designing principles,
1668
01:04:57,860 –> 01:05:00,460
and that’s why they create technically perfect configurations
1669
01:05:00,460 –> 01:05:03,260
that don’t align with what the organization actually needs.
1670
01:05:03,260 –> 01:05:06,660
Intent-based governance is harder to design initially.
1671
01:05:06,660 –> 01:05:09,260
It requires thinking about principles before controls,
1672
01:05:09,260 –> 01:05:10,660
but it’s easier to maintain
1673
01:05:10,660 –> 01:05:12,460
because when you know the intent,
1674
01:05:12,460 –> 01:05:15,660
you can adapt the implementation as reality changes.
1675
01:05:15,660 –> 01:05:16,460
That’s the shift.
1676
01:05:16,460 –> 01:05:19,460
That’s how you move from configuration thinking to governance thinking.
1677
01:05:19,460 –> 01:05:21,460
The role of continuous governance.
1678
01:05:21,460 –> 01:05:23,860
This is perhaps the most important point I’m going to make
1679
01:05:23,860 –> 01:05:25,460
in this entire conversation.
1680
01:05:25,460 –> 01:05:27,060
Governance is not a project.
1681
01:05:27,060 –> 01:05:28,260
It’s a continuous practice.
1682
01:05:28,260 –> 01:05:29,860
Most organizations approach governance
1683
01:05:29,860 –> 01:05:31,660
like their approach in office renovation.
1684
01:05:31,660 –> 01:05:34,260
They hire consultants, the consultants interview people.
1685
01:05:34,260 –> 01:05:35,260
They design a system.
1686
01:05:35,260 –> 01:05:36,860
They document it meticulously.
1687
01:05:36,860 –> 01:05:37,860
They create policies.
1688
01:05:37,860 –> 01:05:38,860
They create workflows.
1689
01:05:38,860 –> 01:05:40,260
They create role definitions.
1690
01:05:40,260 –> 01:05:41,060
They hand it off.
1691
01:05:41,060 –> 01:05:43,060
And then leadership declares governance complete.
1692
01:05:43,060 –> 01:05:44,060
We have policies.
1693
01:05:44,060 –> 01:05:45,260
We have documentation.
1694
01:05:45,260 –> 01:05:46,660
Governance is solved.
1695
01:05:46,660 –> 01:05:48,660
Now we can move on to the next initiative.
1696
01:05:48,660 –> 01:05:50,260
But that’s not how governance works.
1697
01:05:50,260 –> 01:05:51,660
Governance is never solved.
1698
01:05:51,660 –> 01:05:53,060
It’s continuously maintained.
1699
01:05:53,060 –> 01:05:55,260
You don’t build a governance model and declare victory.
1700
01:05:55,260 –> 01:05:56,660
You build a governance model
1701
01:05:56,660 –> 01:05:58,460
and then you spend the next five years
1702
01:05:58,460 –> 01:06:00,460
adapting it as the organization evolves
1703
01:06:00,460 –> 01:06:02,260
and as circumstances change.
1704
01:06:02,260 –> 01:06:03,660
Here’s what the data shows.
1705
01:06:03,660 –> 01:06:06,460
Most co-pilot rollout stall between week six and 12.
1706
01:06:06,460 –> 01:06:07,060
Why?
1707
01:06:07,060 –> 01:06:09,060
Because governance is treated as an event
1708
01:06:09,060 –> 01:06:10,060
rather than a process.
1709
01:06:10,060 –> 01:06:12,860
Organizations go through their governance checklist.
1710
01:06:12,860 –> 01:06:13,860
They create policies.
1711
01:06:13,860 –> 01:06:15,060
They configure DLP.
1712
01:06:15,060 –> 01:06:16,860
They set up sensitivity labels.
1713
01:06:16,860 –> 01:06:18,060
They declare governance ready.
1714
01:06:18,060 –> 01:06:19,060
Then they roll out co-pilot.
1715
01:06:19,060 –> 01:06:20,060
Week one is exciting.
1716
01:06:20,060 –> 01:06:21,460
Week two people are using it.
1717
01:06:21,460 –> 01:06:22,660
Week six something breaks.
1718
01:06:22,660 –> 01:06:24,060
Maybe it’s a compliance issue.
1719
01:06:24,060 –> 01:06:25,460
Maybe it’s an oversharing problem.
1720
01:06:25,460 –> 01:06:27,060
Maybe it’s a performance issue.
1721
01:06:27,060 –> 01:06:28,860
By week 12, the rollout has stalled
1722
01:06:28,860 –> 01:06:31,660
while the organization tries to fix the underlying problem.
1723
01:06:31,660 –> 01:06:34,460
That stall happens because governance was treated as a gate.
1724
01:06:34,460 –> 01:06:36,660
Something you pass through before deployment.
1725
01:06:36,660 –> 01:06:38,660
Not as something you maintain continuously
1726
01:06:38,660 –> 01:06:39,660
throughout the deployment.
1727
01:06:39,660 –> 01:06:42,060
Continuous governance is fundamentally different
1728
01:06:42,060 –> 01:06:43,660
from configuration management.
1729
01:06:43,660 –> 01:06:46,060
Configuration management asks the technical question.
1730
01:06:46,060 –> 01:06:47,460
Are the settings correct?
1731
01:06:47,460 –> 01:06:49,860
Is the DLP policy configured correctly?
1732
01:06:49,860 –> 01:06:52,660
Is the conditional access policy configured correctly?
1733
01:06:52,660 –> 01:06:54,460
Is the sensitivity label applied correctly?
1734
01:06:54,460 –> 01:06:55,860
Those are yes or no questions.
1735
01:06:55,860 –> 01:06:58,660
The settings either match the desired state or they don’t.
1736
01:06:58,660 –> 01:07:00,460
Continuous governance asks a different question.
1737
01:07:00,460 –> 01:07:01,460
It’s not about settings.
1738
01:07:01,460 –> 01:07:02,460
It’s about outcomes.
1739
01:07:02,460 –> 01:07:04,860
Is the system still achieving its intent?
1740
01:07:04,860 –> 01:07:06,260
Not is the policy configured?
1741
01:07:06,260 –> 01:07:07,660
Is the policy actually working?
1742
01:07:07,660 –> 01:07:10,460
Are users able to work while still being protected?
1743
01:07:10,460 –> 01:07:13,260
Are we catching oversharing before it becomes a problem?
1744
01:07:13,260 –> 01:07:15,660
Are we identifying risks before they materialize?
1745
01:07:15,660 –> 01:07:19,060
Is the organization adapting faster than the configuration is drifting?
1746
01:07:19,060 –> 01:07:19,660
That’s the difference.
1747
01:07:19,660 –> 01:07:21,460
Configuration management is reactive.
1748
01:07:21,460 –> 01:07:22,460
You deploy a policy.
1749
01:07:22,460 –> 01:07:24,260
You monitor whether the configuration drifts.
1750
01:07:24,260 –> 01:07:25,260
You fix it if it does.
1751
01:07:25,260 –> 01:07:27,060
Continuous governance is proactive.
1752
01:07:27,060 –> 01:07:30,460
You monitor whether the system is still achieving its intent.
1753
01:07:30,460 –> 01:07:32,860
You adapt the configuration before it becomes a problem.
1754
01:07:32,860 –> 01:07:36,260
You evolve the governance model as the organization evolves.
1755
01:07:36,260 –> 01:07:40,260
Organizations that treat governance as continuous seedrometically better outcomes.
1756
01:07:40,260 –> 01:07:41,460
They catch drift earlier.
1757
01:07:41,460 –> 01:07:42,660
They adapt faster.
1758
01:07:42,660 –> 01:07:44,260
They maintain durability longer.
1759
01:07:44,260 –> 01:07:44,860
Why?
1760
01:07:44,860 –> 01:07:46,060
Because they have feedback loops.
1761
01:07:46,060 –> 01:07:47,660
Someone is continuously asking,
1762
01:07:47,660 –> 01:07:48,660
is this still working?
1763
01:07:48,660 –> 01:07:50,660
Is this still aligned with our intent?
1764
01:07:50,660 –> 01:07:51,660
Do we need to adapt?
1765
01:07:51,660 –> 01:07:53,460
And they’re equipped to answer those questions
1766
01:07:53,460 –> 01:07:55,660
because governance isn’t something that happened once.
1767
01:07:55,660 –> 01:07:57,460
It’s something that’s actively maintained.
1768
01:07:57,460 –> 01:07:59,460
The technical people who understand this shift
1769
01:07:59,460 –> 01:08:02,060
are the ones who move from being engineers to being architects.
1770
01:08:02,060 –> 01:08:03,460
They still have deep technical expertise.
1771
01:08:03,460 –> 01:08:05,660
But they’ve added a layer of systems thinking.
1772
01:08:05,660 –> 01:08:08,460
They’re thinking about not just whether something works technically
1773
01:08:08,460 –> 01:08:11,260
but whether an organization can sustain it operationally.
1774
01:08:11,260 –> 01:08:12,860
They’re thinking about feedback loops.
1775
01:08:12,860 –> 01:08:15,460
They’re thinking about how to detect when something is drifting.
1776
01:08:15,460 –> 01:08:18,860
They’re thinking about how to adapt without abandoning the underlying principles.
1777
01:08:18,860 –> 01:08:21,260
Here’s what continuous governance looks like in practice.
1778
01:08:21,260 –> 01:08:23,060
You deploy a governance policy.
1779
01:08:23,060 –> 01:08:24,660
Three months later, you review it.
1780
01:08:24,660 –> 01:08:26,860
Did it work? Are there unintended consequences?
1781
01:08:26,860 –> 01:08:29,860
Is it creating friction that’s driving users toward workarounds?
1782
01:08:29,860 –> 01:08:30,860
You make adjustments.
1783
01:08:30,860 –> 01:08:32,260
Three months later, you review again.
1784
01:08:32,260 –> 01:08:33,660
The organization has changed.
1785
01:08:33,660 –> 01:08:35,260
You’ve added new applications.
1786
01:08:35,260 –> 01:08:36,660
You’ve added new user roles.
1787
01:08:36,660 –> 01:08:38,060
You’ve added new data categories.
1788
01:08:38,060 –> 01:08:39,860
Does the governance model still fit?
1789
01:08:39,860 –> 01:08:41,460
Do the policy still make sense?
1790
01:08:41,460 –> 01:08:42,260
You adapt them.
1791
01:08:42,260 –> 01:08:44,460
A year in, you conduct a comprehensive review.
1792
01:08:44,460 –> 01:08:46,060
Is the principle still valid?
1793
01:08:46,060 –> 01:08:48,260
Is the configuration still achieving the intent?
1794
01:08:48,260 –> 01:08:50,460
Or have circumstances changed so much
1795
01:08:50,460 –> 01:08:52,660
that you need to rethink the entire framework?
1796
01:08:52,660 –> 01:08:54,260
That’s continuous governance.
1797
01:08:54,260 –> 01:08:56,060
It’s not a project with a completion date.
1798
01:08:56,060 –> 01:08:58,060
It’s an ongoing architectural practice.
1799
01:08:58,060 –> 01:09:00,460
And it’s the only practice that produces durable systems.
1800
01:09:00,460 –> 01:09:02,260
The organizations that understand this,
1801
01:09:02,260 –> 01:09:04,660
that governance is continuous, not a project.
1802
01:09:04,660 –> 01:09:08,460
Other ones that build Microsoft 365 tenants that actually survive.
1803
01:09:08,460 –> 01:09:10,060
Not because the technology is better,
1804
01:09:10,060 –> 01:09:12,460
not because they’re more technically sophisticated,
1805
01:09:12,460 –> 01:09:15,860
but because they understand that architecture is a living discipline
1806
01:09:15,860 –> 01:09:18,260
that requires constant attention and adaptation.
1807
01:09:18,260 –> 01:09:20,260
Building a governance first culture.
1808
01:09:20,260 –> 01:09:22,860
Technical excellence alone will not solve these problems.
1809
01:09:22,860 –> 01:09:24,660
You can have the smartest architects.
1810
01:09:24,660 –> 01:09:26,660
You can have the most sophisticated policies.
1811
01:09:26,660 –> 01:09:28,060
You can have perfect documentation.
1812
01:09:28,060 –> 01:09:30,260
But if your organization doesn’t value governance,
1813
01:09:30,260 –> 01:09:32,260
none of it will survive contact with real work.
1814
01:09:32,260 –> 01:09:35,260
Building a governance first culture is the hardest part.
1815
01:09:35,260 –> 01:09:37,460
It’s harder than designing the architecture.
1816
01:09:37,460 –> 01:09:39,260
It’s harder than implementing the controls
1817
01:09:39,260 –> 01:09:41,660
because it requires changing how your organization thinks
1818
01:09:41,660 –> 01:09:42,660
about technical work.
1819
01:09:42,660 –> 01:09:44,460
It requires changing what you reward.
1820
01:09:44,460 –> 01:09:47,260
It requires changing what leadership cares about.
1821
01:09:47,260 –> 01:09:51,060
A governance first culture means governance is a leadership priority.
1822
01:09:51,060 –> 01:09:52,660
Not an IT checkbox.
1823
01:09:52,660 –> 01:09:54,860
It means that when your CIO talks about strategy,
1824
01:09:54,860 –> 01:09:56,660
governance is part of that conversation.
1825
01:09:56,660 –> 01:09:58,060
Not something to bolt on later.
1826
01:09:58,060 –> 01:09:59,660
Not something to handle in governance.
1827
01:09:59,660 –> 01:10:01,060
A part of the core strategy.
1828
01:10:01,060 –> 01:10:03,860
It means architects are valued for designing durable systems,
1829
01:10:03,860 –> 01:10:05,260
not just capable ones.
1830
01:10:05,260 –> 01:10:07,860
Right now, the technical culture rewards capability.
1831
01:10:07,860 –> 01:10:08,860
How much can we automate?
1832
01:10:08,860 –> 01:10:10,460
How many applications can we integrate?
1833
01:10:10,460 –> 01:10:12,460
How sophisticated can we make the system?
1834
01:10:12,460 –> 01:10:13,460
That’s where the respect goes.
1835
01:10:13,460 –> 01:10:16,460
A governance first culture values durability equally.
1836
01:10:16,460 –> 01:10:18,260
How will someone maintain this in three years?
1837
01:10:18,260 –> 01:10:19,860
What happens when the architect leaves?
1838
01:10:19,860 –> 01:10:21,460
Can the organization still operate this?
1839
01:10:21,460 –> 01:10:22,860
Those questions get respect.
1840
01:10:22,860 –> 01:10:24,060
Those answers get rewarded.
1841
01:10:24,060 –> 01:10:25,860
It means technical people are rewarded
1842
01:10:25,860 –> 01:10:27,460
for thinking about sustainability,
1843
01:10:27,460 –> 01:10:28,460
not just innovation.
1844
01:10:28,460 –> 01:10:29,460
Innovation is flashy.
1845
01:10:29,460 –> 01:10:30,660
You deploy a new feature.
1846
01:10:30,660 –> 01:10:31,860
You automate a process.
1847
01:10:31,860 –> 01:10:33,460
You integrate a new application.
1848
01:10:33,460 –> 01:10:34,260
That’s visible.
1849
01:10:34,260 –> 01:10:35,060
That’s impressive.
1850
01:10:35,060 –> 01:10:36,460
Sustainability is invisible.
1851
01:10:36,460 –> 01:10:38,260
You design a system that’s maintainable.
1852
01:10:38,260 –> 01:10:40,060
You create governance that scales.
1853
01:10:40,060 –> 01:10:42,260
You build processes that don’t degrade over time.
1854
01:10:42,260 –> 01:10:43,860
Nobody sees it. Nobody uploads it.
1855
01:10:43,860 –> 01:10:46,060
But a governance first culture recognizes it.
1856
01:10:46,060 –> 01:10:47,060
Values it.
1857
01:10:47,060 –> 01:10:47,860
Rewards it.
1858
01:10:47,860 –> 01:10:50,460
It means organizations measure governance health
1859
01:10:50,460 –> 01:10:52,060
alongside technical health.
1860
01:10:52,060 –> 01:10:55,060
Right now most organizations measure technical metrics.
1861
01:10:55,060 –> 01:10:56,860
Uptime, performance, feature adoption,
1862
01:10:56,860 –> 01:10:58,060
those are valuable metrics.
1863
01:10:58,060 –> 01:10:59,660
But governance health is unmeasured.
1864
01:10:59,660 –> 01:11:01,060
How many often teams exist?
1865
01:11:01,060 –> 01:11:03,060
How many flows don’t have documented owners?
1866
01:11:03,060 –> 01:11:04,460
How many global admins do you have?
1867
01:11:04,460 –> 01:11:06,260
How much governance debt are you accumulating?
1868
01:11:06,260 –> 01:11:09,660
Those metrics should be measured, reported, tracked over time.
1869
01:11:09,660 –> 01:11:12,060
If you’re not measuring it, you’re not managing it.
1870
01:11:12,060 –> 01:11:13,460
Here’s what the research tells us.
1871
01:11:13,460 –> 01:11:15,660
Organizations with mature governance frameworks
1872
01:11:15,660 –> 01:11:17,860
experience 23% fewer incidents.
1873
01:11:17,860 –> 01:11:18,860
That’s not coincidental.
1874
01:11:18,860 –> 01:11:21,660
That’s the outcome of building a culture where governance matters.
1875
01:11:21,660 –> 01:11:23,260
Where durability is valued,
1876
01:11:23,260 –> 01:11:26,060
where architects are empowered to slow down capability deployment
1877
01:11:26,060 –> 01:11:27,860
when governance readiness is lacking.
1878
01:11:27,860 –> 01:11:30,860
Building that culture requires specific things from leadership.
1879
01:11:30,860 –> 01:11:33,860
The CIO needs to communicate that governance is strategic,
1880
01:11:33,860 –> 01:11:34,860
not tactical.
1881
01:11:34,860 –> 01:11:37,060
Not we need to comply with this regulation.
1882
01:11:37,060 –> 01:11:38,060
Strategic.
1883
01:11:38,060 –> 01:11:39,260
Governance is how we scale.
1884
01:11:39,260 –> 01:11:40,460
It’s how we reduce risk.
1885
01:11:40,460 –> 01:11:42,860
It’s how we maintain control as the organization grows.
1886
01:11:42,860 –> 01:11:44,260
It’s core to our strategy.
1887
01:11:44,260 –> 01:11:48,060
Technical teams need to understand that durability is as important as capability.
1888
01:11:48,060 –> 01:11:49,060
Not more important.
1889
01:11:49,060 –> 01:11:52,260
As important, you’re not sacrificing innovation for governance.
1890
01:11:52,260 –> 01:11:53,860
You’re making innovation sustainable.
1891
01:11:53,860 –> 01:11:55,860
You’re asking, what’s the capability we need?
1892
01:11:55,860 –> 01:11:58,860
And how do we build it so the organization can actually maintain it?
1893
01:11:58,860 –> 01:12:02,060
Architects need to be empowered to slow down capability deployment
1894
01:12:02,060 –> 01:12:03,860
when governance readiness is lacking.
1895
01:12:03,860 –> 01:12:05,860
Right now, the pressure flows one direction.
1896
01:12:05,860 –> 01:12:08,460
Deploy faster, get to market faster, innovate faster.
1897
01:12:08,460 –> 01:12:11,860
But a governance first culture empowers architects to say, not yet.
1898
01:12:11,860 –> 01:12:13,260
The organization isn’t ready.
1899
01:12:13,260 –> 01:12:15,260
We need to build the governance foundation first.
1900
01:12:15,260 –> 01:12:17,060
And that should be respected, not overruled.
1901
01:12:17,060 –> 01:12:18,860
This requires changing incentive structures.
1902
01:12:18,860 –> 01:12:22,260
If architects are measured on speed of deployment, they’ll optimize for speed.
1903
01:12:22,260 –> 01:12:25,860
If they’re measured on durability of deployment, they’ll optimize for durability.
1904
01:12:25,860 –> 01:12:29,660
If technical excellence is rewarded and governance durability is ignored,
1905
01:12:29,660 –> 01:12:31,060
technical excellence will win.
1906
01:12:31,060 –> 01:12:33,660
If both are valued equally, both will happen.
1907
01:12:33,660 –> 01:12:35,660
It requires changing conversations.
1908
01:12:35,660 –> 01:12:39,460
When someone proposes a new capability, the conversation can’t just be,
1909
01:12:39,460 –> 01:12:40,860
is it technically possible?
1910
01:12:40,860 –> 01:12:43,660
It has to include, is the organization ready to operate it?
1911
01:12:43,660 –> 01:12:45,260
Do we have governance readiness?
1912
01:12:45,260 –> 01:12:46,460
Do we have clear ownership?
1913
01:12:46,460 –> 01:12:47,860
Do we have monitoring in place?
1914
01:12:47,860 –> 01:12:49,860
If not, what do we need to do first?
1915
01:12:49,860 –> 01:12:51,660
That conversation is uncomfortable.
1916
01:12:51,660 –> 01:12:52,860
It slows things down.
1917
01:12:52,860 –> 01:12:54,460
It requires saying no sometimes.
1918
01:12:54,460 –> 01:12:56,660
But it’s the conversation that builds sustainable systems.
1919
01:12:56,660 –> 01:12:59,260
This is the hardest part because it requires changing culture.
1920
01:12:59,260 –> 01:13:00,460
And culture changes slowly.
1921
01:13:00,460 –> 01:13:02,060
It requires leadership commitment.
1922
01:13:02,060 –> 01:13:03,860
It requires consistent messaging.
1923
01:13:03,860 –> 01:13:07,660
It requires new people to see the pattern and understand that durability matters.
1924
01:13:07,660 –> 01:13:09,860
It requires architects to feel safe,
1925
01:13:09,860 –> 01:13:13,060
prioritizing governance even when other pressures push towards speed.
1926
01:13:13,060 –> 01:13:16,460
But organizations that make that shift, that build a governance first culture
1927
01:13:16,460 –> 01:13:19,460
are the ones that actually scale Microsoft 365 sustainably.
1928
01:13:19,460 –> 01:13:20,460
They’re not the fastest,
1929
01:13:20,460 –> 01:13:23,660
but they’re the ones still operating successfully five years later.
1930
01:13:23,660 –> 01:13:25,260
The architects’ responsibility,
1931
01:13:25,260 –> 01:13:28,860
as architects, we have a responsibility that goes beyond technical excellence.
1932
01:13:28,860 –> 01:13:31,260
And this is the part that doesn’t get talked about enough.
1933
01:13:31,260 –> 01:13:33,860
When you design a Microsoft 365 architecture,
1934
01:13:33,860 –> 01:13:35,860
you’re not designing an abstract system.
1935
01:13:35,860 –> 01:13:39,660
You’re designing something that thousands of people will live inside for years.
1936
01:13:39,660 –> 01:13:42,460
You’re making decisions that will be felt by them every day.
1937
01:13:42,460 –> 01:13:44,260
Whether they can find what they need,
1938
01:13:44,260 –> 01:13:46,260
whether they can collaborate effectively,
1939
01:13:46,260 –> 01:13:47,460
whether they can work safely,
1940
01:13:47,460 –> 01:13:48,660
whether they can move fast,
1941
01:13:48,660 –> 01:13:50,460
or whether they’re constantly hitting friction,
1942
01:13:50,460 –> 01:13:54,460
you’re creating the conditions for either sustainable collaboration or operational chaos.
1943
01:13:54,460 –> 01:13:56,260
Most technical people don’t think about it that way.
1944
01:13:56,260 –> 01:13:57,660
They think about the system,
1945
01:13:57,660 –> 01:14:00,060
the configuration, the elegance of the design,
1946
01:14:00,060 –> 01:14:02,060
the optimization, those are important,
1947
01:14:02,060 –> 01:14:03,860
but they’re not the most important thing.
1948
01:14:03,860 –> 01:14:08,060
The most important thing is whether actual human beings can actually operate the system.
1949
01:14:08,060 –> 01:14:11,660
This responsibility requires thinking beyond technical capability.
1950
01:14:11,660 –> 01:14:13,860
It requires understanding organizational behavior.
1951
01:14:13,860 –> 01:14:16,060
It requires understanding human psychology.
1952
01:14:16,060 –> 01:14:20,660
It requires understanding what happens when a policy conflicts with how people actually work.
1953
01:14:20,660 –> 01:14:23,260
It requires understanding that people will find workarounds,
1954
01:14:23,260 –> 01:14:24,460
that they’ll bend rules,
1955
01:14:24,460 –> 01:14:28,260
that they’ll circumvent controls if those controls make it impossible to do their job.
1956
01:14:28,260 –> 01:14:31,660
You can’t design sustainable systems without understanding those realities.
1957
01:14:31,660 –> 01:14:35,060
The best architects I’ve worked with are not the most technical people I’ve known.
1958
01:14:35,060 –> 01:14:40,260
They’re not the ones who can write the most sophisticated code or design the most elegant infrastructure.
1959
01:14:40,260 –> 01:14:41,860
They’re the most thoughtful people.
1960
01:14:41,860 –> 01:14:44,260
They ask questions that technical people often skip.
1961
01:14:44,260 –> 01:14:47,060
They ask, “Who will operate this? Can they actually do it?
1962
01:14:47,060 –> 01:14:49,860
Will they be able to maintain it when circumstances change?”
1963
01:14:49,860 –> 01:14:52,060
What happens when this assumption turns out to be wrong?
1964
01:14:52,060 –> 01:14:53,460
Those are uncomfortable questions.
1965
01:14:53,460 –> 01:14:54,460
They slow things down.
1966
01:14:54,460 –> 01:14:58,660
They require admitting that your elegant technical solution might not be operationally viable.
1967
01:14:58,660 –> 01:15:03,860
But those are the questions that separate systems that survive from systems that silently collapse.
1968
01:15:03,860 –> 01:15:06,060
They design for the organization that exists,
1969
01:15:06,060 –> 01:15:08,060
not the organization they wish existed.
1970
01:15:08,060 –> 01:15:09,460
This is the critical distinction.
1971
01:15:09,460 –> 01:15:12,660
A lot of architects design for a fictional version of the organization.
1972
01:15:12,660 –> 01:15:14,660
They assume perfect execution.
1973
01:15:14,660 –> 01:15:16,060
They assume clear processes.
1974
01:15:16,060 –> 01:15:19,060
They assume that everyone will follow the policies exactly as documented.
1975
01:15:19,060 –> 01:15:22,260
They assume that change will be managed carefully and thoughtfully.
1976
01:15:22,260 –> 01:15:24,460
But that’s not the organization you’re designing for.
1977
01:15:24,460 –> 01:15:27,060
You’re designing for an organization with budget constraints,
1978
01:15:27,060 –> 01:15:28,660
with competing priorities,
1979
01:15:28,660 –> 01:15:30,860
with people who are overworked and overwhelmed,
1980
01:15:30,860 –> 01:15:33,860
with processes that are more bureaucratic than strategic,
1981
01:15:33,860 –> 01:15:36,860
with change that happens by accident as much as by plan.
1982
01:15:36,860 –> 01:15:41,260
An architect who designs for that reality builds systems that actually work.
1983
01:15:41,260 –> 01:15:46,060
An architect who designs for the fictional organization builds systems that immediately start to fail.
1984
01:15:46,060 –> 01:15:48,460
They build governance into architecture from the beginning,
1985
01:15:48,460 –> 01:15:49,460
not as an afterthought.
1986
01:15:49,460 –> 01:15:50,660
This is where the shift happens.
1987
01:15:50,660 –> 01:15:54,060
Most technical architects think about technical architecture first.
1988
01:15:54,060 –> 01:15:55,260
How do I design the system?
1989
01:15:55,260 –> 01:15:56,460
How do I make it scalable?
1990
01:15:56,460 –> 01:15:57,460
How do I make it performant?
1991
01:15:57,460 –> 01:15:58,860
How do I make it reliable?
1992
01:15:58,860 –> 01:16:00,460
Then at the end, they think about governance.
1993
01:16:00,460 –> 01:16:01,860
Okay, now how do we manage this?
1994
01:16:01,860 –> 01:16:02,860
How do we control it?
1995
01:16:02,860 –> 01:16:04,460
Governance becomes a layer on top.
1996
01:16:04,460 –> 01:16:05,860
Separate from the technical design.
1997
01:16:05,860 –> 01:16:10,060
But governance first architects think about it together from the beginning.
1998
01:16:10,060 –> 01:16:13,860
How do I design the system so that the organization can actually govern it?
1999
01:16:13,860 –> 01:16:15,260
What does governance look like?
2000
01:16:15,260 –> 01:16:15,860
Who owns it?
2001
01:16:15,860 –> 01:16:16,860
How do we prevent drift?
2002
01:16:16,860 –> 01:16:19,460
Those questions shape the architecture, not the other way around.
2003
01:16:19,460 –> 01:16:22,660
They measure success by durability, not just capability.
2004
01:16:22,660 –> 01:16:25,660
A capability focused architect measures success by features.
2005
01:16:25,660 –> 01:16:27,460
How many processes did we automate?
2006
01:16:27,460 –> 01:16:29,460
How many applications did we integrate?
2007
01:16:29,460 –> 01:16:31,060
How sophisticated did we make the system?
2008
01:16:31,060 –> 01:16:34,260
A durability focused architect measures success differently?
2009
01:16:34,260 –> 01:16:36,660
Can the organization still operate this in three years?
2010
01:16:36,660 –> 01:16:39,060
Can someone who didn’t build it understand how it works?
2011
01:16:39,060 –> 01:16:41,060
Can it adapt when circumstances change?
2012
01:16:41,060 –> 01:16:43,060
Can it survive without the original architect?
2013
01:16:43,060 –> 01:16:44,660
Those are the measures that matter.
2014
01:16:44,660 –> 01:16:47,660
This is the shift from technical leadership to architectural leadership.
2015
01:16:47,660 –> 01:16:51,460
Technical leadership is about mastering the platform, learning all the features.
2016
01:16:51,460 –> 01:16:53,860
Understanding how to configure everything optimally.
2017
01:16:53,860 –> 01:16:56,660
Architectural leadership is about understanding systems.
2018
01:16:56,660 –> 01:17:01,860
Understanding organizations, understanding the tension between technical purity and operational reality.
2019
01:17:01,860 –> 01:17:05,260
Understanding that the goal isn’t to build the most sophisticated system.
2020
01:17:05,260 –> 01:17:08,660
The goal is to build a system that the organization can actually sustain.
2021
01:17:08,660 –> 01:17:09,860
That’s the responsibility.
2022
01:17:09,860 –> 01:17:11,460
That’s what we are accountable for.
2023
01:17:11,460 –> 01:17:13,460
Not just whether the system works technically,
2024
01:17:13,460 –> 01:17:15,460
whether the organization can operate it,
2025
01:17:15,460 –> 01:17:17,860
whether it survives, whether it creates value,
2026
01:17:17,860 –> 01:17:20,260
that’s the architect’s responsibility.
2027
01:17:20,260 –> 01:17:22,860
Practical steps to implement governance architecture.
2028
01:17:22,860 –> 01:17:26,260
If you want to start implementing governance architecture immediately,
2029
01:17:26,260 –> 01:17:27,860
here are the practical steps.
2030
01:17:27,860 –> 01:17:29,860
Not theoretical, not aspirational.
2031
01:17:29,860 –> 01:17:33,460
Concrete actions you can take this week that will begin shifting your organization
2032
01:17:33,460 –> 01:17:35,060
toward durable governance.
2033
01:17:35,060 –> 01:17:36,660
Step one is audit your current state.
2034
01:17:36,660 –> 01:17:39,660
Use the tenant durability checklist we discussed earlier.
2035
01:17:39,660 –> 01:17:42,260
Walk through every category, be honest about what you find.
2036
01:17:42,260 –> 01:17:43,460
This isn’t for an auditor.
2037
01:17:43,460 –> 01:17:44,460
This is for you.
2038
01:17:44,460 –> 01:17:45,460
You’re establishing a baseline,
2039
01:17:45,460 –> 01:17:48,260
so you know where you actually are before you start moving.
2040
01:17:48,260 –> 01:17:51,460
Most organizations skip this step because it’s uncomfortable.
2041
01:17:51,460 –> 01:17:54,060
You don’t want to admit that you have global admins’ role.
2042
01:17:54,060 –> 01:17:57,660
You don’t want to acknowledge that you have hundreds of flows with no documented owners.
2043
01:17:57,660 –> 01:17:59,260
You don’t want to measure the governance dead.
2044
01:17:59,260 –> 01:18:00,260
But you have to.
2045
01:18:00,260 –> 01:18:03,060
You can’t move from where you’re not toward where you want to be.
2046
01:18:03,060 –> 01:18:05,660
You have to start from the truth about where you are.
2047
01:18:05,660 –> 01:18:08,060
Step two is define intent for each governance area.
2048
01:18:08,060 –> 01:18:09,460
Don’t start with implementation.
2049
01:18:09,460 –> 01:18:10,460
Start with intent.
2050
01:18:10,460 –> 01:18:12,460
What are you actually trying to achieve?
2051
01:18:12,460 –> 01:18:15,460
For identity ask, how do we balance access and security?
2052
01:18:15,460 –> 01:18:18,060
That’s different from how do we enforce MFA?
2053
01:18:18,060 –> 01:18:20,460
That’s asking what behavior you’re trying to enable.
2054
01:18:20,460 –> 01:18:24,460
For collaboration ask, how do we enable teamwork while protecting data?
2055
01:18:24,460 –> 01:18:26,660
Not how do we restrict external sharing?
2056
01:18:26,660 –> 01:18:28,660
What’s the balance you’re trying to achieve?
2057
01:18:28,660 –> 01:18:32,460
For automation ask, how do we empower innovation while maintaining control?
2058
01:18:32,460 –> 01:18:34,460
Not how do we lock down power automate?
2059
01:18:34,460 –> 01:18:36,060
What’s the outcome you’re trying to create?
2060
01:18:36,060 –> 01:18:38,660
These three questions reshape your entire governance conversation.
2061
01:18:38,660 –> 01:18:40,660
Step three is design governance zones.
2062
01:18:40,660 –> 01:18:42,660
This is the framework that simplifies everything.
2063
01:18:42,660 –> 01:18:43,660
You have three zones.
2064
01:18:43,660 –> 01:18:45,060
Zone one is personal work.
2065
01:18:45,060 –> 01:18:48,260
One drive, personal teams chats, stuff that belongs to individuals,
2066
01:18:48,260 –> 01:18:49,060
minimal governance.
2067
01:18:49,060 –> 01:18:50,860
You don’t need to control this aggressively.
2068
01:18:50,860 –> 01:18:52,260
Zone two is collaborative work.
2069
01:18:52,260 –> 01:18:56,060
Teams channels, project sharepoint sites, places where teams work together.
2070
01:18:56,060 –> 01:18:59,860
Moderate governance, clear ownership, life cycle policies, guest management.
2071
01:18:59,860 –> 01:19:04,660
Zone three is enterprise records, HR systems, financial data, regulated content,
2072
01:19:04,660 –> 01:19:08,660
strict governance, retention policies, sensitivity labels, access reviews.
2073
01:19:08,660 –> 01:19:11,660
This three zone model instantly makes governance decisions clearer.
2074
01:19:11,660 –> 01:19:15,260
You’re not asking, how do we apply governance to all Microsoft 365?
2075
01:19:15,260 –> 01:19:16,460
That’s unanswerable.
2076
01:19:16,460 –> 01:19:18,860
You’re asking, how do we govern this specific zone?
2077
01:19:18,860 –> 01:19:20,060
That’s unanswerable.
2078
01:19:20,060 –> 01:19:22,460
Apply different governance models to each zone.
2079
01:19:22,460 –> 01:19:24,660
You don’t need the same level of control everywhere.
2080
01:19:24,660 –> 01:19:26,460
Step four is identify quick wins.
2081
01:19:26,460 –> 01:19:29,460
Where can you improve governance with minimal disruption?
2082
01:19:29,460 –> 01:19:30,660
Start with identity.
2083
01:19:30,660 –> 01:19:32,060
Reduce your global admin count.
2084
01:19:32,060 –> 01:19:35,660
If you have 20 global admins and the recommendation is fewer than five,
2085
01:19:35,660 –> 01:19:37,260
start working toward that number.
2086
01:19:37,260 –> 01:19:39,060
Not by removing people’s access suddenly,
2087
01:19:39,060 –> 01:19:42,460
by implementing privileged access management, by delegating specific roles,
2088
01:19:42,460 –> 01:19:45,060
by creating a plan to get to a reasonable number.
2089
01:19:45,060 –> 01:19:48,460
This is a quick win because it’s high impact and relatively straightforward.
2090
01:19:48,460 –> 01:19:49,660
Other quick wins.
2091
01:19:49,660 –> 01:19:52,660
Implement teams, life cycle policies for inactive teams.
2092
01:19:52,660 –> 01:19:55,860
Clean up guest accounts from partnerships that ended years ago.
2093
01:19:55,860 –> 01:19:59,660
These are wins you can achieve without restructuring your entire governance model.
2094
01:19:59,660 –> 01:20:01,860
Step five is build continuous monitoring.
2095
01:20:01,860 –> 01:20:03,660
This is where most organizations fail.
2096
01:20:03,660 –> 01:20:05,260
They implement governance and then stop.
2097
01:20:05,260 –> 01:20:06,260
Nothing changes.
2098
01:20:06,260 –> 01:20:07,260
Policies drift.
2099
01:20:07,260 –> 01:20:09,060
Ownership becomes unclear again.
2100
01:20:09,060 –> 01:20:10,060
Don’t let that happen.
2101
01:20:10,060 –> 01:20:12,260
Establish regular reviews of governance health.
2102
01:20:12,260 –> 01:20:14,660
Quarterly reviews of major governance areas.
2103
01:20:14,660 –> 01:20:16,260
Are our policies still working?
2104
01:20:16,260 –> 01:20:17,060
Is drift happening?
2105
01:20:17,060 –> 01:20:18,260
Do we need to adapt?
2106
01:20:18,260 –> 01:20:21,260
Create feedback loops that inform policy evolution.
2107
01:20:21,260 –> 01:20:25,860
Automation debt discovered in month one should inform your automation governance by month three.
2108
01:20:25,860 –> 01:20:27,860
Permissions sprawl identified in a review
2109
01:20:27,860 –> 01:20:30,060
should trigger updates to your sharing policy.
2110
01:20:30,060 –> 01:20:31,860
Step six is communicate the shift.
2111
01:20:31,860 –> 01:20:35,460
This is the most important step because culture change is the hardest part.
2112
01:20:35,460 –> 01:20:38,460
Help your organization understand that governance enables innovation,
2113
01:20:38,460 –> 01:20:39,860
not just restricts it.
2114
01:20:39,860 –> 01:20:41,860
Right now people think governance is limiting.
2115
01:20:41,860 –> 01:20:42,860
It’s bureaucracy.
2116
01:20:42,860 –> 01:20:43,860
It’s saying no.
2117
01:20:43,860 –> 01:20:44,860
Shift that conversation.
2118
01:20:44,860 –> 01:20:47,860
Governance is the foundation that lets you move fast safely.
2119
01:20:47,860 –> 01:20:50,860
Governance is what allows you to scale without losing control.
2120
01:20:50,860 –> 01:20:52,260
That’s a different conversation.
2121
01:20:52,260 –> 01:20:53,460
That’s what gets adoption.
2122
01:20:53,460 –> 01:20:54,660
Communicate what you’re doing.
2123
01:20:54,660 –> 01:20:55,460
Why you’re doing it?
2124
01:20:55,460 –> 01:20:56,660
What the outcome will be?
2125
01:20:56,660 –> 01:20:57,860
Do that continuously.
2126
01:20:57,860 –> 01:20:59,660
Culture change doesn’t happen from a memo.
2127
01:20:59,660 –> 01:21:01,460
It happens from consistent messaging.
2128
01:21:01,460 –> 01:21:04,860
From showing results, from demonstrating that governance makes work better,
2129
01:21:04,860 –> 01:21:06,060
not just safer.
2130
01:21:06,060 –> 01:21:07,260
That’s the implementation path.
2131
01:21:07,260 –> 01:21:08,660
Start small, start honest.
2132
01:21:08,660 –> 01:21:10,460
Move incrementally, build momentum.
2133
01:21:10,460 –> 01:21:12,860
Create the conditions for sustainable architecture.
2134
01:21:12,860 –> 01:21:15,860
That’s how you go from governance debt to governance durability.
2135
01:21:15,860 –> 01:21:17,660
The long view.
2136
01:21:17,660 –> 01:21:19,060
Why this matters now?
2137
01:21:19,060 –> 01:21:22,660
Let me finish with the strategic context for why this matters right now.
2138
01:21:22,660 –> 01:21:24,460
Not in five years, right now.
2139
01:21:24,460 –> 01:21:25,660
In 2026.
2140
01:21:25,660 –> 01:21:28,660
Microsoft 365 is becoming more complex, not less.
2141
01:21:28,660 –> 01:21:30,860
Every quarter new capabilities are added.
2142
01:21:30,860 –> 01:21:33,060
AI is being integrated into every application.
2143
01:21:33,060 –> 01:21:35,860
Copilot is becoming the default way people work.
2144
01:21:35,860 –> 01:21:36,860
Not an add-on.
2145
01:21:36,860 –> 01:21:37,860
The platform is expanding.
2146
01:21:37,860 –> 01:21:39,260
The surface area is growing.
2147
01:21:39,260 –> 01:21:41,660
The number of decision points is multiplying.
2148
01:21:41,660 –> 01:21:45,260
If governance is difficult now, it’s about to become exponentially more difficult.
2149
01:21:45,260 –> 01:21:48,460
The organizations that haven’t built governance architecture are running out of time.
2150
01:21:48,460 –> 01:21:52,060
At the same time, AI capabilities are surfacing governance debt instantly.
2151
01:21:52,060 –> 01:21:57,460
Copilot can access any data available to users across SharePoint, Teams, OneDrive and Exchange.
2152
01:21:57,460 –> 01:21:59,860
That means Copilot can surface overshared data.
2153
01:21:59,860 –> 01:22:01,460
It can expose broken permissions.
2154
01:22:01,460 –> 01:22:04,460
It can make visible what was previously hidden by obscurity.
2155
01:22:04,460 –> 01:22:09,060
73% of organizations in regulated industries have paused Copilot rollouts
2156
01:22:09,060 –> 01:22:10,460
due to data exposure concerns.
2157
01:22:10,460 –> 01:22:14,060
Not because Copilot is unsafe, because their own data governance is unsafe.
2158
01:22:14,060 –> 01:22:17,060
Because they have years of permissions sprawled that they’ve never fixed.
2159
01:22:17,060 –> 01:22:18,660
Copilot didn’t create that problem.
2160
01:22:18,660 –> 01:22:19,660
It revealed it.
2161
01:22:19,660 –> 01:22:22,260
The regulatory environment is tightening simultaneously.
2162
01:22:22,260 –> 01:22:24,060
The EU AI Act is now in effect.
2163
01:22:24,060 –> 01:22:29,060
Organizations operating in Europe face legally enforceable obligations around AI governance.
2164
01:22:29,060 –> 01:22:30,260
Not best practices.
2165
01:22:30,260 –> 01:22:31,260
Legal requirements.
2166
01:22:31,260 –> 01:22:33,660
They must demonstrate control over AI systems.
2167
01:22:33,660 –> 01:22:35,060
They must maintain audit trails.
2168
01:22:35,060 –> 01:22:36,860
They must ensure fairness and transparency.
2169
01:22:36,860 –> 01:22:38,460
Those are not optional suggestions.
2170
01:22:38,460 –> 01:22:39,860
Those are compliance requirements.
2171
01:22:39,860 –> 01:22:43,660
Organizations that deploy Copilot without governance are deploying a regulated system
2172
01:22:43,660 –> 01:22:44,860
without compliance controls.
2173
01:22:44,860 –> 01:22:46,060
That’s not a technical problem.
2174
01:22:46,060 –> 01:22:47,060
That’s a legal problem.
2175
01:22:47,060 –> 01:22:48,660
Licensing costs are increasing.
2176
01:22:48,660 –> 01:22:52,860
Microsoft has announced significant pricing increases effective July 2026.
2177
01:22:52,860 –> 01:22:58,060
Organizations are facing double digit percentage increases on their Microsoft 365 licenses.
2178
01:22:58,060 –> 01:22:59,860
That budget pressure forces a conversation.
2179
01:22:59,860 –> 01:23:01,460
What are we actually getting value from?
2180
01:23:01,460 –> 01:23:02,660
Where is licensing waste?
2181
01:23:02,660 –> 01:23:05,260
Where is governance debt creating unnecessary cost?
2182
01:23:05,260 –> 01:23:08,860
Organizations that haven’t measured governance debt suddenly need to justify
2183
01:23:08,860 –> 01:23:10,660
continued investment in capabilities.
2184
01:23:10,660 –> 01:23:12,660
They’re not actually operating effectively.
2185
01:23:12,660 –> 01:23:14,060
Here’s the inflection point.
2186
01:23:14,060 –> 01:23:17,860
Organizations with strong governance architecture are moving forward confidently.
2187
01:23:17,860 –> 01:23:19,060
They are deploying Copilot.
2188
01:23:19,060 –> 01:23:20,460
They’re implementing agents.
2189
01:23:20,460 –> 01:23:22,060
They’re scaling AI capabilities.
2190
01:23:22,060 –> 01:23:23,860
They understand their data landscape.
2191
01:23:23,860 –> 01:23:25,460
They have clarity about permissions.
2192
01:23:25,460 –> 01:23:27,060
They have life cycle management.
2193
01:23:27,060 –> 01:23:28,060
They can deploy safely.
2194
01:23:28,060 –> 01:23:29,260
They can scale sustainably.
2195
01:23:29,260 –> 01:23:32,860
They can take advantage of new capabilities without creating new risk.
2196
01:23:32,860 –> 01:23:35,060
Organizations without governance are stalling.
2197
01:23:35,060 –> 01:23:37,060
Pilots are pausing, rollouts are halting.
2198
01:23:37,060 –> 01:23:40,260
Why? Because when you try to deploy Copilot at scale and you discover
2199
01:23:40,260 –> 01:23:42,860
you don’t have governance readiness, you have to choose.
2200
01:23:42,860 –> 01:23:46,660
Slow down the deployment and fix governance or deploy anyway and accept the risk.
2201
01:23:46,660 –> 01:23:50,060
Most organizations are choosing to slow down and that slow down is expensive.
2202
01:23:50,060 –> 01:23:51,660
The license costs are accumulating.
2203
01:23:51,660 –> 01:23:53,660
The capability isn’t delivering value.
2204
01:23:53,660 –> 01:23:57,060
The organization is standing still while competitors move forward.
2205
01:23:57,060 –> 01:23:59,460
The technical people who understand governance architecture
2206
01:23:59,460 –> 01:24:02,660
are about to become the most valuable leaders in enterprise technology.
2207
01:24:02,660 –> 01:24:05,460
They’re the ones who can deploy AI safely and sustainably.
2208
01:24:05,460 –> 01:24:07,860
They’re the ones who can navigate the regulatory landscape.
2209
01:24:07,860 –> 01:24:11,260
They’re the ones who can extract value from the platform without creating chaos.
2210
01:24:11,260 –> 01:24:14,060
They’re the ones who understand that technical excellence is not enough.
2211
01:24:14,060 –> 01:24:15,060
That durability matters.
2212
01:24:15,060 –> 01:24:17,060
That governance is architecture, not compliance.
2213
01:24:17,060 –> 01:24:21,060
Organizations are going to be scrambling to find architects who understand this.
2214
01:24:21,060 –> 01:24:24,060
Architects who can balance innovation with sustainability.
2215
01:24:24,060 –> 01:24:26,460
Architects who can build systems that actually survive.
2216
01:24:26,460 –> 01:24:31,060
The technical people who don’t understand governance are about to become increasingly frustrated.
2217
01:24:31,060 –> 01:24:35,260
They’ll build brilliant systems, elegant configurations, sophisticated automation
2218
01:24:35,260 –> 01:24:38,060
and then they’ll watch those systems become unmentable.
2219
01:24:38,060 –> 01:24:41,060
They’ll watch organizations struggle to operate what they design.
2220
01:24:41,060 –> 01:24:43,860
They’ll watch co-pilot deployment store because governance wasn’t ready.
2221
01:24:43,860 –> 01:24:46,860
They’ll watch automation platforms collapse under complexity.
2222
01:24:46,860 –> 01:24:50,060
They’ll be frustrated because they did their job, they built great systems.
2223
01:24:50,060 –> 01:24:52,060
But the organization couldn’t sustain them.
2224
01:24:52,060 –> 01:24:52,860
This is the moment.
2225
01:24:52,860 –> 01:24:56,860
The next 18 months are going to determine which organizations scale AI sustainably
2226
01:24:56,860 –> 01:24:57,860
and which ones get stuck.
2227
01:24:57,860 –> 01:25:01,460
Which organizations deploy co-pilot confidently and which ones pause in panic?
2228
01:25:01,460 –> 01:25:04,860
Which organizations extract value from their Microsoft investment
2229
01:25:04,860 –> 01:25:06,860
and which ones accumulate licensing debt?
2230
01:25:06,860 –> 01:25:08,860
The difference won’t be technical capability.
2231
01:25:08,860 –> 01:25:10,060
Microsoft will handle that.
2232
01:25:10,060 –> 01:25:12,060
The difference will be governance maturity.
2233
01:25:12,060 –> 01:25:15,260
Organizations that build governance architecture now will have the foundation.
2234
01:25:15,260 –> 01:25:18,460
Organizations that wait will be playing catch-up and catch-up is expensive.
2235
01:25:18,460 –> 01:25:22,060
It’s disruptive, it’s painful, you’re better off doing the work now.
2236
01:25:22,060 –> 01:25:23,260
The confession completes.
2237
01:25:23,260 –> 01:25:25,860
I’m still not the most technical person in the room.
2238
01:25:25,860 –> 01:25:27,260
I don’t write production code.
2239
01:25:27,260 –> 01:25:28,660
I don’t tune infrastructure.
2240
01:25:28,660 –> 01:25:31,660
But I’ve learned something that the brilliant technical people in the room
2241
01:25:31,660 –> 01:25:33,260
don’t always understand.
2242
01:25:33,260 –> 01:25:37,260
Technical excellence without governance creates the worst Microsoft 365 tenants.
2243
01:25:37,260 –> 01:25:41,060
The engineers in the failures we discussed were talented, really talented.
2244
01:25:41,060 –> 01:25:42,660
The problem wasn’t their expertise.
2245
01:25:42,660 –> 01:25:45,260
The problem was that brilliance applied to the wrong problem
2246
01:25:45,260 –> 01:25:48,660
create systems that are technically perfect and operationally impossible.
2247
01:25:48,660 –> 01:25:52,060
The goal of architecture is not to build systems that work today.
2248
01:25:52,060 –> 01:25:55,860
It’s to design systems that organizations can still operate five years from now
2249
01:25:55,860 –> 01:25:58,860
that requires thinking beyond technical capability.
2250
01:25:58,860 –> 01:26:02,460
That requires understanding governance, understanding organizational behavior,
2251
01:26:02,460 –> 01:26:04,860
understanding that people will find workarounds
2252
01:26:04,860 –> 01:26:07,260
if your architecture makes their job impossible.
2253
01:26:07,260 –> 01:26:10,260
Understanding that durability matters more than perfection.
2254
01:26:10,260 –> 01:26:14,860
If you’re building Microsoft 365 architecture, start with governance intent,
2255
01:26:14,860 –> 01:26:16,060
not configuration.
2256
01:26:16,060 –> 01:26:19,660
Design for the organization that exists, not the one you wish existed.
2257
01:26:19,660 –> 01:26:22,260
Measure success by durability, not just capability.
2258
01:26:22,260 –> 01:26:25,260
And remember, the most dangerous architecture is the one that works perfectly
2259
01:26:25,260 –> 01:26:27,660
on day one and collapses silently in year three.
2260
01:26:27,660 –> 01:26:32,060
Subscribe to the M365FM podcast for more insights on Microsoft 365,
2261
01:26:32,060 –> 01:26:35,860
governance, architecture and the human systems that make technology sustainable.
2262
01:26:35,860 –> 01:26:37,060
Connect with me on LinkedIn.
2263
01:26:37,060 –> 01:26:40,860
I’m always looking for the next story of technical excellence that created governance failure
2264
01:26:40,860 –> 01:26:43,860
because those stories are how we learn to build better systems.
