The Monorepo Myth: Why Your Architecture Is Fragmented

1
00:00:00,000 --> 00:00:02,040
You chose a repository strategy years ago.

2
00:00:02,040 --> 00:00:04,620
It felt technical at the time, a decision about Git,

3
00:00:04,620 --> 00:00:06,680
whether to use one repository or many,

4
00:00:06,680 --> 00:00:08,240
whether you needed Sparse checkout,

5
00:00:08,240 --> 00:00:09,720
how many branches you could manage,

6
00:00:09,720 --> 00:00:11,120
how fast you needed to clone,

7
00:00:11,120 --> 00:00:13,560
it felt like an engineering problem, in reality.

8
00:00:13,560 --> 00:00:14,880
It wasn't a Git decision at all,

9
00:00:14,880 --> 00:00:16,540
it was an organizational decision,

10
00:00:16,540 --> 00:00:18,120
and you probably didn't know you were making it

11
00:00:18,120 --> 00:00:19,680
because that choice didn't just affect

12
00:00:19,680 --> 00:00:21,080
how your code was stored.

13
00:00:21,080 --> 00:00:23,680
It started shaping how your teams worked together,

14
00:00:23,680 --> 00:00:26,080
how they communicate, whether they can move fast,

15
00:00:26,080 --> 00:00:28,200
or whether they grind, whether they build products,

16
00:00:28,200 --> 00:00:29,200
or manage structure.

17
00:00:29,200 --> 00:00:30,520
And it's been doing that ever since,

18
00:00:30,520 --> 00:00:31,920
whether you've noticed it or not,

19
00:00:31,920 --> 00:00:33,480
most organizations don't realize this,

20
00:00:33,480 --> 00:00:35,080
they don't realize that their fragmentation

21
00:00:35,080 --> 00:00:37,720
isn't a code problem, it's a structure problem.

22
00:00:37,720 --> 00:00:39,440
Today we're diagnosing why,

23
00:00:39,440 --> 00:00:40,920
the assumption everyone makes.

24
00:00:40,920 --> 00:00:43,960
Most teams think repository strategy is about one thing,

25
00:00:43,960 --> 00:00:46,120
Git performance, scalability, how fast can you clone,

26
00:00:46,120 --> 00:00:48,920
how fast can you push, can the system handle a million files,

27
00:00:48,920 --> 00:00:50,520
can it handle thousands of developers?

28
00:00:50,520 --> 00:00:53,200
These are real questions, they're just not the right questions.

29
00:00:53,200 --> 00:00:55,240
When you talk to technical leaders in organizations

30
00:00:55,240 --> 00:00:57,840
that actually move fast, they don't talk about Git speed,

31
00:00:57,840 --> 00:01:00,800
they talk about coordination, where do we pay our coordination tax,

32
00:01:00,800 --> 00:01:04,000
that's the real question hiding inside the repository choice.

33
00:01:04,000 --> 00:01:06,280
Most technical leaders are solving for the wrong problem

34
00:01:06,280 --> 00:01:08,640
because they are looking at a tool instead of a system.

35
00:01:08,640 --> 00:01:09,880
But here's what's actually happening

36
00:01:09,880 --> 00:01:11,800
when you choose between Monorepo and Multi-Repo,

37
00:01:11,800 --> 00:01:13,560
you're not choosing a repository structure,

38
00:01:13,560 --> 00:01:15,320
you're choosing where coordination happens,

39
00:01:15,320 --> 00:01:16,760
you're choosing how information moves,

40
00:01:16,760 --> 00:01:18,800
you're choosing how decisions get made,

41
00:01:18,800 --> 00:01:20,800
and you're choosing whether that process is visible

42
00:01:20,800 --> 00:01:24,600
or invisible, Monorepo, one repository, everything in one place.

43
00:01:24,600 --> 00:01:26,400
The promise is clean, shared tooling,

44
00:01:26,400 --> 00:01:29,640
easier refactoring, consistent standards, high visibility,

45
00:01:29,640 --> 00:01:32,960
a single source of truth, one build system, one set of rules,

46
00:01:32,960 --> 00:01:36,080
what you're actually doing is centralizing the coordination problem.

47
00:01:36,080 --> 00:01:38,560
Every change that affects multiple parts of the system

48
00:01:38,560 --> 00:01:40,760
has to be reviewed by everyone who cares.

49
00:01:40,760 --> 00:01:42,960
Every dependency bump touches every team,

50
00:01:42,960 --> 00:01:45,560
every breaking change gets negotiated in one place,

51
00:01:45,560 --> 00:01:48,760
the coordination becomes visible, it becomes concrete,

52
00:01:48,760 --> 00:01:52,200
it happens in code reviews and CIP lines, Multi-Repo,

53
00:01:52,200 --> 00:01:54,240
many repositories, clear boundaries.

54
00:01:54,240 --> 00:01:58,200
The promise here is different, team autonomy, independent release cycles,

55
00:01:58,200 --> 00:02:00,480
clear ownership, the ability to move fast

56
00:02:00,480 --> 00:02:02,240
without waiting for other teams,

57
00:02:02,240 --> 00:02:04,720
what you're actually doing is pushing the coordination problem

58
00:02:04,720 --> 00:02:06,080
into a different place.

59
00:02:06,080 --> 00:02:07,840
Instead of managing it in code review,

60
00:02:07,840 --> 00:02:09,840
you manage it through APIs and contracts.

61
00:02:09,840 --> 00:02:11,680
Instead of one commit touching everything,

62
00:02:11,680 --> 00:02:13,320
you have coordinated releases.

63
00:02:13,320 --> 00:02:16,600
Instead of shared governance, you have explicit versioning,

64
00:02:16,600 --> 00:02:18,240
the coordination becomes invisible,

65
00:02:18,240 --> 00:02:21,560
it happens in meetings, it happens in release notes and migration guides,

66
00:02:21,560 --> 00:02:23,640
neither choice makes coordination disappear.

67
00:02:23,640 --> 00:02:25,320
You just choose which text to pay.

68
00:02:25,320 --> 00:02:28,040
And most technical leaders don't realize they're making that choice,

69
00:02:28,040 --> 00:02:30,600
they think they're solving for performance or scalability,

70
00:02:30,600 --> 00:02:33,800
they're actually encoding their organizational structure into the code base,

71
00:02:33,800 --> 00:02:37,440
they're making structural assumptions about how teams should work together.

72
00:02:37,440 --> 00:02:41,000
This choice reflects how your organization actually communicates,

73
00:02:41,000 --> 00:02:42,400
and it reinforces that pattern.

74
00:02:42,400 --> 00:02:45,880
Once you choose Monorepo, you've made it harder to work independently,

75
00:02:45,880 --> 00:02:47,440
which forces teams toward alignment.

76
00:02:47,440 --> 00:02:51,120
Once you choose Multi-Repo, you've made it easier for teams to move alone,

77
00:02:51,120 --> 00:02:53,440
which requires much more formal communication.

78
00:02:53,440 --> 00:02:56,600
Technical leaders often miss this because they're solving for the wrong problem,

79
00:02:56,600 --> 00:02:58,920
they're asking which Git strategy scales.

80
00:02:58,920 --> 00:03:02,240
When they should be asking, how do my teams actually work together?

81
00:03:02,240 --> 00:03:05,440
The answer to the first question is, all of them scale.

82
00:03:05,440 --> 00:03:07,680
Google has Monorepo's with millions of files,

83
00:03:07,680 --> 00:03:10,080
Spotify has hundreds of independent repositories,

84
00:03:10,080 --> 00:03:12,080
both work, neither is objectively better,

85
00:03:12,080 --> 00:03:14,640
but here's what actually happens when you make that choice.

86
00:03:14,640 --> 00:03:16,880
How Monorepo's work and what they cost?

87
00:03:16,880 --> 00:03:19,080
A Monorepo puts all your code in one place,

88
00:03:19,080 --> 00:03:23,120
not just the main product, not just the core services, everything.

89
00:03:23,120 --> 00:03:26,240
Your libraries, your build tools, your infrastructure code,

90
00:03:26,240 --> 00:03:28,920
your internal frameworks, your shared components,

91
00:03:28,920 --> 00:03:32,800
all of it versioned together, building together and deploying together.

92
00:03:32,800 --> 00:03:34,080
The infrastructure is unified.

93
00:03:34,080 --> 00:03:38,040
You have one build system, one CI pipeline, and one set of dependencies.

94
00:03:38,040 --> 00:03:41,760
You use one version of the compiler, the testing framework, and the linting rules.

95
00:03:41,760 --> 00:03:44,080
When you upgrade a library, you upgrade it everywhere at once,

96
00:03:44,080 --> 00:03:47,240
and when you change a standard, it applies to every single line of code.

97
00:03:47,240 --> 00:03:48,600
The visibility is total.

98
00:03:48,600 --> 00:03:50,240
Any developer can see any code.

99
00:03:50,240 --> 00:03:51,640
There are no permissions boundaries,

100
00:03:51,640 --> 00:03:54,400
and no, you don't have access to that repository errors.

101
00:03:54,400 --> 00:03:56,840
The entire system is right there for you to reason about.

102
00:03:56,840 --> 00:04:01,440
Dependencies are explicit because every service that relies on a shared library is visible,

103
00:04:01,440 --> 00:04:04,400
and every place a change will ripple through shows up immediately.

104
00:04:04,400 --> 00:04:06,040
The promise is powerful.

105
00:04:06,040 --> 00:04:08,400
Refactoring is easier because you see all the callers.

106
00:04:08,400 --> 00:04:11,960
Dependency management is simpler because there is only one version of everything.

107
00:04:11,960 --> 00:04:16,040
Standards stay consistent, because there is nowhere to hide from the rules.

108
00:04:16,040 --> 00:04:19,080
Changes are atomic because one commit can update a library

109
00:04:19,080 --> 00:04:20,960
and all its consumers at the same time.

110
00:04:20,960 --> 00:04:22,960
This works beautifully when teams are aligned.

111
00:04:22,960 --> 00:04:26,160
It works when the teams using a library agree on what the API should be.

112
00:04:26,160 --> 00:04:28,280
It works when they coordinate on changes,

113
00:04:28,280 --> 00:04:30,760
and are willing to adapt their code when a library moves forward.

114
00:04:30,760 --> 00:04:34,160
It works when they communicate about breaking changes before they happen,

115
00:04:34,160 --> 00:04:36,720
and accept that they are part of a larger system.

116
00:04:36,720 --> 00:04:39,000
But here's what actually happens as the monorepo grows.

117
00:04:39,000 --> 00:04:40,560
More teams start touching it.

118
00:04:40,560 --> 00:04:44,160
Not just your core platform team, but feature teams, infrastructure teams,

119
00:04:44,160 --> 00:04:46,320
and teams in different parts of the organization.

120
00:04:46,320 --> 00:04:48,680
You have teams that don't talk to each other very much,

121
00:04:48,680 --> 00:04:50,800
and teams with completely different priorities.

122
00:04:50,800 --> 00:04:53,240
Now that unified build system isn't so unified anymore,

123
00:04:53,240 --> 00:04:56,520
you can't upgrade the compiler without checking if every team is ready.

124
00:04:56,520 --> 00:04:58,400
You can't change the build configuration

125
00:04:58,400 --> 00:05:01,160
without understanding how 50 different teams rely on it.

126
00:05:01,160 --> 00:05:04,960
You can't deprecate an API without waiting months for every consumer to migrate.

127
00:05:04,960 --> 00:05:07,360
The visibility becomes a burden, everyone can see the code,

128
00:05:07,360 --> 00:05:08,400
but nobody owns it.

129
00:05:08,400 --> 00:05:11,800
A change to a shared library requires review from whoever cares about it.

130
00:05:11,800 --> 00:05:15,120
And as the monorepo grows, more people care about more things.

131
00:05:15,120 --> 00:05:18,960
Dependencies become a political negotiation instead of a technical decision.

132
00:05:18,960 --> 00:05:20,560
Code review becomes the bottleneck.

133
00:05:20,560 --> 00:05:24,040
If a change touches multiple services, it needs sign-off from each team.

134
00:05:24,040 --> 00:05:25,960
If a library change affects the whole system,

135
00:05:25,960 --> 00:05:28,280
everyone needs to verify it doesn't break their code.

136
00:05:28,280 --> 00:05:31,320
As the monorepo grows, code review doesn't speed up.

137
00:05:31,320 --> 00:05:34,800
It slows down because more stakeholders are involved in every decision.

138
00:05:34,800 --> 00:05:36,320
The branching model breaks.

139
00:05:36,320 --> 00:05:39,080
In a small monorepo, everyone commits to main.

140
00:05:39,080 --> 00:05:41,880
But as teams multiply, long-lived branches multiply too.

141
00:05:41,880 --> 00:05:43,640
You get feature branches that live for weeks

142
00:05:43,640 --> 00:05:46,880
because they're too risky to merge without every stakeholder checking them.

143
00:05:46,880 --> 00:05:49,320
You get release branches because you can't coordinate

144
00:05:49,320 --> 00:05:51,560
a synchronized release across 30 teams.

145
00:05:51,560 --> 00:05:54,400
And you get hot-fixed branches because production broke

146
00:05:54,400 --> 00:05:57,280
and nobody wants to wait for a massive code review.

147
00:05:57,280 --> 00:05:58,680
Build time explodes.

148
00:05:58,680 --> 00:06:00,240
The monorepo is massive.

149
00:06:00,240 --> 00:06:02,600
And because all the code for all the teams is there,

150
00:06:02,600 --> 00:06:04,880
the build system has to understand all of it.

151
00:06:04,880 --> 00:06:08,160
Builds get slower, C.I. becomes a bottleneck and tests take longer.

152
00:06:08,160 --> 00:06:11,920
Developers spend their day waiting for builds instead of doing actual work.

153
00:06:11,920 --> 00:06:14,600
The solution is usually to add more infrastructure.

154
00:06:14,600 --> 00:06:17,240
You set up Spass checkout, so you don't have to download everything.

155
00:06:17,240 --> 00:06:20,320
You use partial clones, so you aren't cloning the entire history.

156
00:06:20,320 --> 00:06:23,200
You implement selective builds, so only changed parts, rebuilt,

157
00:06:23,200 --> 00:06:25,680
and you add caching, so you aren't recompiling everything.

158
00:06:25,680 --> 00:06:28,960
You create different test groups, so you aren't running every test for every change.

159
00:06:28,960 --> 00:06:31,800
But here's the thing, all of that infrastructure exists.

160
00:06:31,800 --> 00:06:34,360
To work around the fact that the monorepo is too big,

161
00:06:34,360 --> 00:06:37,160
the coordination is too complex and the teams aren't aligned.

162
00:06:37,160 --> 00:06:39,400
You're treating the symptom, not the disease.

163
00:06:39,400 --> 00:06:41,520
The disease isn't that Git can't handle the scale

164
00:06:41,520 --> 00:06:45,320
because Git handles monorepo with millions of files every day.

165
00:06:45,320 --> 00:06:46,800
The disease is organizational debt.

166
00:06:46,800 --> 00:06:49,000
It's the accumulation of teams that need to coordinate

167
00:06:49,000 --> 00:06:51,600
but don't have the trust or alignment to do it smoothly.

168
00:06:51,600 --> 00:06:54,080
It's unresolved decisions about who owns what

169
00:06:54,080 --> 00:06:56,640
and processes that haven't kept up with the scale.

170
00:06:56,640 --> 00:06:58,960
The monorepo doesn't fail because of technical reasons.

171
00:06:58,960 --> 00:07:01,000
It fails because you've made coordination visible

172
00:07:01,000 --> 00:07:03,520
and then you pretended you could manage it with infrastructure

173
00:07:03,520 --> 00:07:06,240
instead of actually fixing the underlying organizational problem.

174
00:07:06,240 --> 00:07:08,840
And that's where most organizations hit the wall.

175
00:07:08,840 --> 00:07:11,360
The monorepo scaling problem, no one talks about.

176
00:07:11,360 --> 00:07:13,600
Now let's be clear about what's actually breaking.

177
00:07:13,600 --> 00:07:15,440
It's not Git, it's not the technology.

178
00:07:15,440 --> 00:07:17,240
It's not that your version control system

179
00:07:17,240 --> 00:07:19,280
hits some hard limit and stops working.

180
00:07:19,280 --> 00:07:22,040
GitHub manages monorepo with millions of files

181
00:07:22,040 --> 00:07:24,480
and Google's monorepo is larger than anything

182
00:07:24,480 --> 00:07:27,600
you will ever build the technology scales.

183
00:07:27,600 --> 00:07:30,400
What breaks is the organizational model.

184
00:07:30,400 --> 00:07:32,040
And here's the thing, nobody talks about.

185
00:07:32,040 --> 00:07:34,560
The monorepo doesn't fail because you ran out of infrastructure.

186
00:07:34,560 --> 00:07:36,680
It fails because you ran out of alignment.

187
00:07:36,680 --> 00:07:38,480
You have people making decisions in parallel

188
00:07:38,480 --> 00:07:40,200
who should be making decisions together.

189
00:07:40,200 --> 00:07:41,840
You have teams touching the same code

190
00:07:41,840 --> 00:07:43,960
who haven't agreed on what safe means.

191
00:07:43,960 --> 00:07:46,520
You have dependencies that are implicit instead of explicit.

192
00:07:46,520 --> 00:07:49,440
As the monorepo grows, these unresolved decisions

193
00:07:49,440 --> 00:07:51,400
accumulate faster than you can manage them.

194
00:07:51,400 --> 00:07:53,040
This is organizational debt.

195
00:07:53,040 --> 00:07:55,520
It isn't technical debt because the code might be fine.

196
00:07:55,520 --> 00:07:57,240
It isn't infrastructure debt because you might

197
00:07:57,240 --> 00:07:58,520
have plenty of resources.

198
00:07:58,520 --> 00:08:00,800
It is the cost of decisions you haven't made yet

199
00:08:00,800 --> 00:08:02,520
and the burden of coordination problems

200
00:08:02,520 --> 00:08:03,760
you're pretending don't exist.

201
00:08:03,760 --> 00:08:06,960
In a growing monorepo, decision debt shows up in concrete ways

202
00:08:06,960 --> 00:08:10,040
who decides when it's safe to break an API.

203
00:08:10,040 --> 00:08:12,320
In a small monorepo, the team that owns the API

204
00:08:12,320 --> 00:08:14,600
decides checks with the three other teams that use it

205
00:08:14,600 --> 00:08:15,640
and then breaks it.

206
00:08:15,640 --> 00:08:19,040
In a large monorepo, you have 40 teams using that API

207
00:08:19,040 --> 00:08:21,400
and you can't break it without breaking something important.

208
00:08:21,400 --> 00:08:22,480
So the API gets frozen.

209
00:08:22,480 --> 00:08:24,160
You add a new version, then a third version,

210
00:08:24,160 --> 00:08:26,160
and suddenly you have three versions of the same API

211
00:08:26,160 --> 00:08:28,600
in the code base and nobody knows which one to use.

212
00:08:28,600 --> 00:08:30,720
Who decides when to upgrade a dependency?

213
00:08:30,720 --> 00:08:32,720
In a small monorepo, you upgrade when it's safe

214
00:08:32,720 --> 00:08:34,240
and push the change to everyone.

215
00:08:34,240 --> 00:08:38,000
In a large monorepo, upgrading a compiler or a core library

216
00:08:38,000 --> 00:08:39,320
affects every single team.

217
00:08:39,320 --> 00:08:41,200
Some teams are ready, but some teams are blocked

218
00:08:41,200 --> 00:08:42,840
and some teams haven't even checked their code

219
00:08:42,840 --> 00:08:44,120
against the new version.

220
00:08:44,120 --> 00:08:45,480
So you don't upgrade.

221
00:08:45,480 --> 00:08:48,560
You freeze the version, you create a compatibility layer

222
00:08:48,560 --> 00:08:49,880
and you build workarounds.

223
00:08:49,880 --> 00:08:52,320
The dependency becomes stale and security patches don't get

224
00:08:52,320 --> 00:08:55,200
applied because applying them breaks something somewhere else.

225
00:08:55,200 --> 00:08:57,760
Who decides what coordinated release means?

226
00:08:57,760 --> 00:08:59,960
Does the monorepo release once a day or once a week?

227
00:08:59,960 --> 00:09:02,080
Does it release only when all the tests pass?

228
00:09:02,080 --> 00:09:04,560
Even if that means a critical fix for team A

229
00:09:04,560 --> 00:09:06,760
waits behind a failing test from team C,

230
00:09:06,760 --> 00:09:08,320
these are not technical questions.

231
00:09:08,320 --> 00:09:09,920
They are organizational questions.

232
00:09:09,920 --> 00:09:11,360
But if you haven't answered them explicitly,

233
00:09:11,360 --> 00:09:13,760
the system will answer them for you by blocking releases

234
00:09:13,760 --> 00:09:16,400
and creating the perception that the monorepo is slow.

235
00:09:16,400 --> 00:09:18,440
These decisions don't get made because making them

236
00:09:18,440 --> 00:09:19,760
requires authority.

237
00:09:19,760 --> 00:09:21,680
It requires someone saying, here's the policy.

238
00:09:21,680 --> 00:09:22,760
Everyone follows it.

239
00:09:22,760 --> 00:09:24,840
That person has to have the organizational credibility

240
00:09:24,840 --> 00:09:26,400
to enforce it across all the teams.

241
00:09:26,400 --> 00:09:28,200
Most organizations don't have that person.

242
00:09:28,200 --> 00:09:30,360
Most organizations have distributed authority

243
00:09:30,360 --> 00:09:33,280
where each team has autonomy, but nobody has the final say.

244
00:09:33,280 --> 00:09:34,640
So the decisions don't happen.

245
00:09:34,640 --> 00:09:35,400
They accumulate.

246
00:09:35,400 --> 00:09:36,800
They become organizational debt.

247
00:09:36,800 --> 00:09:38,560
And then you try to fix it with infrastructure.

248
00:09:38,560 --> 00:09:40,680
You add spars checkout so teams don't have to download

249
00:09:40,680 --> 00:09:43,400
the whole monorepo, but that doesn't fix the decision debt.

250
00:09:43,400 --> 00:09:45,760
It just hides the fact that the monorepo is too big.

251
00:09:45,760 --> 00:09:48,680
You add selective builds, so only relevant code rebuilds.

252
00:09:48,680 --> 00:09:50,880
But that doesn't fix the decision debt.

253
00:09:50,880 --> 00:09:53,200
It just hides the fact that you have too many teams

254
00:09:53,200 --> 00:09:55,160
with too many interdependencies.

255
00:09:55,160 --> 00:09:56,920
You add caching and distributed builds

256
00:09:56,920 --> 00:09:58,600
and parallel test execution.

257
00:09:58,600 --> 00:10:01,440
You're adding complexity to work around the fundamental problem,

258
00:10:01,440 --> 00:10:04,040
which is that your organization hasn't decided how to coordinate.

259
00:10:04,040 --> 00:10:05,840
The infrastructure doesn't fix anything.

260
00:10:05,840 --> 00:10:07,000
It just delays the reckoning.

261
00:10:07,000 --> 00:10:09,880
Eventually, you hit the wall where no amount of infrastructure

262
00:10:09,880 --> 00:10:12,400
engineering solves the organizational problem.

263
00:10:12,400 --> 00:10:13,880
Your CI becomes a nightmare because you're

264
00:10:13,880 --> 00:10:15,400
building everything for everyone.

265
00:10:15,400 --> 00:10:17,200
Your review process becomes glacial

266
00:10:17,200 --> 00:10:19,040
because you have too many stakeholders.

267
00:10:19,040 --> 00:10:21,320
Your releases become risky because you're coordinating

268
00:10:21,320 --> 00:10:22,800
too many changes at once.

269
00:10:22,800 --> 00:10:25,520
And at that point, the monorepo isn't the solution anymore.

270
00:10:25,520 --> 00:10:26,800
It's the problem.

271
00:10:26,800 --> 00:10:29,080
Now let's look at the other side of this choice.

272
00:10:29,080 --> 00:10:31,680
How multi-repo's work and their hidden tax.

273
00:10:31,680 --> 00:10:34,440
A multi-repo keeps your services, libraries, or products

274
00:10:34,440 --> 00:10:35,760
in separate repositories.

275
00:10:35,760 --> 00:10:37,240
It is not one massive repository.

276
00:10:37,240 --> 00:10:38,520
It is multiple repositories.

277
00:10:38,520 --> 00:10:40,560
You have one for your API service and another

278
00:10:40,560 --> 00:10:42,280
for your front-end application.

279
00:10:42,280 --> 00:10:44,920
You keep separate repositories for payment processing,

280
00:10:44,920 --> 00:10:47,720
notifications, and user management.

281
00:10:47,720 --> 00:10:51,240
Every single repository has its own code, its own build system,

282
00:10:51,240 --> 00:10:54,160
its own tests, and its own deployment pipeline.

283
00:10:54,160 --> 00:10:55,200
The boundaries are clear.

284
00:10:55,200 --> 00:10:58,280
Team A owns this repository while Team B owns that one.

285
00:10:58,280 --> 00:11:00,760
The code is separated, the deployments are separate,

286
00:11:00,760 --> 00:11:02,320
and the versions are separate.

287
00:11:02,320 --> 00:11:04,280
When Team A wants to deploy, they do not

288
00:11:04,280 --> 00:11:06,640
have to wait for Team B to finish their work.

289
00:11:06,640 --> 00:11:08,280
When Team B updates their service,

290
00:11:08,280 --> 00:11:10,960
Team A does not automatically pull in that change.

291
00:11:10,960 --> 00:11:12,160
The promise is explicit.

292
00:11:12,160 --> 00:11:13,200
Team autonomy.

293
00:11:13,200 --> 00:11:14,840
Each team controls their own repository

294
00:11:14,840 --> 00:11:16,680
and decides exactly when to deploy.

295
00:11:16,680 --> 00:11:18,200
You can iterate at your own pace

296
00:11:18,200 --> 00:11:20,720
without coordinating with anyone to push a change.

297
00:11:20,720 --> 00:11:23,520
You do not have to wait for code reviews from distant teams,

298
00:11:23,520 --> 00:11:25,120
and you do not even have to understand

299
00:11:25,120 --> 00:11:26,760
how anyone else's system works.

300
00:11:26,760 --> 00:11:29,600
You just control your own corner of the world.

301
00:11:29,600 --> 00:11:33,080
The architecture is built on contracts instead of shared code.

302
00:11:33,080 --> 00:11:35,720
If Team A needs to call a service owned by Team B,

303
00:11:35,720 --> 00:11:37,360
they use an API contract.

304
00:11:37,360 --> 00:11:40,240
Team B publishes the API and Team A consumes it.

305
00:11:40,240 --> 00:11:41,800
Team B can change their implementation

306
00:11:41,800 --> 00:11:43,640
as long as the API stays the same,

307
00:11:43,640 --> 00:11:46,560
and Team A can upgrade to a new version on their own schedule.

308
00:11:46,560 --> 00:11:48,040
They test it against their own code

309
00:11:48,040 --> 00:11:49,800
and deploy whenever they feel ready.

310
00:11:49,800 --> 00:11:51,000
This is elegant in theory.

311
00:11:51,000 --> 00:11:53,080
You have independent teams, clear interfaces,

312
00:11:53,080 --> 00:11:54,440
and minimal coordination.

313
00:11:54,440 --> 00:11:55,960
But here is what actually happens.

314
00:11:55,960 --> 00:11:58,040
The coordination problem does not disappear.

315
00:11:58,040 --> 00:11:59,080
It moves.

316
00:11:59,080 --> 00:12:01,520
In a monorippo, you see the problem during code review.

317
00:12:01,520 --> 00:12:03,200
A change ripples through the system,

318
00:12:03,200 --> 00:12:05,320
and you see every single place where it breaks.

319
00:12:05,320 --> 00:12:07,680
You fix all of those issues in one commit.

320
00:12:07,680 --> 00:12:09,120
The coordination is visible,

321
00:12:09,120 --> 00:12:11,160
and while it feels painful, it is concrete.

322
00:12:11,160 --> 00:12:14,000
In a multi-repo, the coordination problem becomes invisible.

323
00:12:14,000 --> 00:12:16,960
It hides an API design, version compatibility,

324
00:12:16,960 --> 00:12:19,600
release timing, and dependency management.

325
00:12:19,600 --> 00:12:21,520
When Team A needs a new feature from Team B,

326
00:12:21,520 --> 00:12:23,000
they cannot just modify the code

327
00:12:23,000 --> 00:12:25,560
because that code lives in a different repository.

328
00:12:25,560 --> 00:12:28,120
They have to ask Team B for help and explain the use case.

329
00:12:28,120 --> 00:12:30,320
Then they have to wait for Team B to prioritize

330
00:12:30,320 --> 00:12:33,000
the request, implement it, test it, and finally release it.

331
00:12:33,000 --> 00:12:35,160
What would have been a single commit in a monorippo

332
00:12:35,160 --> 00:12:38,320
becomes a month-long negotiation in a multi-repo.

333
00:12:38,320 --> 00:12:40,040
When Team B updates their API,

334
00:12:40,040 --> 00:12:42,440
they have to worry about backwards compatibility.

335
00:12:42,440 --> 00:12:45,000
They have to decide how long to support the old version,

336
00:12:45,000 --> 00:12:47,120
or if they should create a V2 API.

337
00:12:47,120 --> 00:12:48,960
Every consumer from Team A to Team D

338
00:12:48,960 --> 00:12:50,520
has to decide when to migrate.

339
00:12:50,520 --> 00:12:52,480
They probably will not all migrate at once,

340
00:12:52,480 --> 00:12:55,480
so you end up supporting multiple versions simultaneously.

341
00:12:55,480 --> 00:12:57,240
This makes your service more complex

342
00:12:57,240 --> 00:12:59,320
and forces your team to maintain code paths

343
00:12:59,320 --> 00:13:00,960
that only a few people use.

344
00:13:00,960 --> 00:13:02,720
When a critical bug is found in a shared library,

345
00:13:02,720 --> 00:13:03,960
it cannot be fixed in one place

346
00:13:03,960 --> 00:13:05,600
and consumed everywhere immediately.

347
00:13:05,600 --> 00:13:08,160
The library owner fixes the bug and releases a new version,

348
00:13:08,160 --> 00:13:10,000
but then every team, depending on that library,

349
00:13:10,000 --> 00:13:12,200
has to update their dependency declaration.

350
00:13:12,200 --> 00:13:14,400
They have to rerun their tests and deploy,

351
00:13:14,400 --> 00:13:15,760
which might conflict with other work

352
00:13:15,760 --> 00:13:17,600
or block their current release cycle.

353
00:13:17,600 --> 00:13:19,520
The coordination tax does not disappear.

354
00:13:19,520 --> 00:13:21,800
It moves from code review to dependency management.

355
00:13:21,800 --> 00:13:23,400
It moves from one integrated system

356
00:13:23,400 --> 00:13:25,160
to a bunch of loosely coupled services

357
00:13:25,160 --> 00:13:26,840
that have to negotiate with each other.

358
00:13:26,840 --> 00:13:28,320
And this tax is invisible.

359
00:13:28,320 --> 00:13:31,000
In a monorepo, when you make a breaking change to an API,

360
00:13:31,000 --> 00:13:32,240
you see the error immediately

361
00:13:32,240 --> 00:13:33,880
because the code will not compile.

362
00:13:33,880 --> 00:13:36,040
The tests fail and you have to fix it right there.

363
00:13:36,040 --> 00:13:37,840
The problem is concrete.

364
00:13:37,840 --> 00:13:39,800
In a multi-repo, when you release a new version

365
00:13:39,800 --> 00:13:42,240
of your service, you do not see who breaks.

366
00:13:42,240 --> 00:13:44,440
You release it to production, and three weeks later,

367
00:13:44,440 --> 00:13:46,040
somebody's integration fails.

368
00:13:46,040 --> 00:13:47,600
By then your change is months old

369
00:13:47,600 --> 00:13:49,360
and you have moved on to something else.

370
00:13:49,360 --> 00:13:50,840
The problem is abstract, hiding away

371
00:13:50,840 --> 00:13:52,800
and release notes and migration guides.

372
00:13:52,800 --> 00:13:54,960
The coordination also becomes more social.

373
00:13:54,960 --> 00:13:56,640
It is less about automated systems

374
00:13:56,640 --> 00:13:58,240
and more about meetings and process.

375
00:13:58,240 --> 00:14:00,320
You need API reviews, versioning discipline

376
00:14:00,320 --> 00:14:01,720
and release coordination.

377
00:14:01,720 --> 00:14:04,120
You need explicit communication about breaking changes

378
00:14:04,120 --> 00:14:06,160
and governance forums where teams negotiate

379
00:14:06,160 --> 00:14:07,240
over shared concerns.

380
00:14:07,240 --> 00:14:10,160
All of that requires organizational capability and discipline.

381
00:14:10,160 --> 00:14:12,560
It requires people to actually read the documentation

382
00:14:12,560 --> 00:14:14,840
and follow the processes you put in place.

383
00:14:14,840 --> 00:14:15,760
But here's the thing.

384
00:14:15,760 --> 00:14:16,760
It does not always work.

385
00:14:16,760 --> 00:14:19,800
Teams skip the API review, push breaking changes

386
00:14:19,800 --> 00:14:22,120
without coordination and fail to maintain

387
00:14:22,120 --> 00:14:23,280
backward compatibility.

388
00:14:23,280 --> 00:14:26,280
They update dependencies without understanding the impact.

389
00:14:26,280 --> 00:14:28,040
The informal coordination falls apart

390
00:14:28,040 --> 00:14:30,040
because there is no system to enforce it.

391
00:14:30,040 --> 00:14:31,120
Both choices have a text.

392
00:14:31,120 --> 00:14:33,960
The real question is which text you are actually paying.

393
00:14:33,960 --> 00:14:35,840
The real cost coordination overhead,

394
00:14:35,840 --> 00:14:37,880
here is what neither choice teaches you.

395
00:14:37,880 --> 00:14:40,600
Whether you choose a monorapal or a multi-rapo,

396
00:14:40,600 --> 00:14:42,360
you are going to have coordination overhead.

397
00:14:42,360 --> 00:14:44,280
You will have meetings, you will have waiting

398
00:14:44,280 --> 00:14:45,600
and you will have people blocked

399
00:14:45,600 --> 00:14:47,680
because they need input from someone else.

400
00:14:47,680 --> 00:14:48,960
You will deal with dependencies

401
00:14:48,960 --> 00:14:51,040
that do not move at the speed they should.

402
00:14:51,040 --> 00:14:52,480
That is not a technical problem,

403
00:14:52,480 --> 00:14:54,440
but a structural reality of building software

404
00:14:54,440 --> 00:14:55,640
with multiple teams.

405
00:14:55,640 --> 00:14:58,000
The question is not whether you have coordination overhead

406
00:14:58,000 --> 00:15:00,000
but the question is what form it takes.

407
00:15:00,000 --> 00:15:02,160
And that form is called organizational debt.

408
00:15:02,160 --> 00:15:04,720
Organizational debt is different from technical debt.

409
00:15:04,720 --> 00:15:05,960
Technical debt lives in the code,

410
00:15:05,960 --> 00:15:08,320
like the shortcut you took or the test you did not write.

411
00:15:08,320 --> 00:15:11,280
You can see it, quantify it and decide to pay it down.

412
00:15:11,280 --> 00:15:13,000
Organizational debt lives in the structure.

413
00:15:13,000 --> 00:15:14,720
It is the unresolved decisions,

414
00:15:14,720 --> 00:15:16,360
the ambiguity about ownership

415
00:15:16,360 --> 00:15:18,240
and the processes that nobody follows

416
00:15:18,240 --> 00:15:19,520
because nobody agreed on them.

417
00:15:19,520 --> 00:15:21,440
It is the complexity that accumulated

418
00:15:21,440 --> 00:15:22,880
because you never simplified it

419
00:15:22,880 --> 00:15:25,000
and the meetings that exist only because

420
00:15:25,000 --> 00:15:27,360
communication broke down in the system.

421
00:15:27,360 --> 00:15:29,840
Complex branching models are organizational debt.

422
00:15:29,840 --> 00:15:31,720
When you have five long-lived branches

423
00:15:31,720 --> 00:15:34,400
because you cannot figure out how to release from main,

424
00:15:34,400 --> 00:15:36,240
you are carrying organizational debt.

425
00:15:36,240 --> 00:15:37,440
When you have released branches

426
00:15:37,440 --> 00:15:39,680
because teams cannot coordinate their deployments,

427
00:15:39,680 --> 00:15:41,480
you are carrying organizational debt.

428
00:15:41,480 --> 00:15:43,080
When feature branches live for weeks

429
00:15:43,080 --> 00:15:45,240
because the change is too risky to merge,

430
00:15:45,240 --> 00:15:46,880
you are carrying organizational debt.

431
00:15:46,880 --> 00:15:49,080
Fragmented repositories are also organizational debt.

432
00:15:49,080 --> 00:15:50,480
When you have dozens of repositories

433
00:15:50,480 --> 00:15:52,960
because teams cannot agree on shared standards,

434
00:15:52,960 --> 00:15:54,760
you are carrying organizational debt.

435
00:15:54,760 --> 00:15:56,520
When you have API versioning nightmares

436
00:15:56,520 --> 00:15:58,560
because you never established a policy,

437
00:15:58,560 --> 00:16:00,440
you are carrying organizational debt.

438
00:16:00,440 --> 00:16:02,800
When you have to maintain multiple versions of a library

439
00:16:02,800 --> 00:16:04,720
because nobody will coordinate a migration,

440
00:16:04,720 --> 00:16:06,520
you are carrying organizational debt.

441
00:16:06,520 --> 00:16:08,160
The cost of that debt is invisible.

442
00:16:08,160 --> 00:16:10,400
It does not show up as a line item in your budget

443
00:16:10,400 --> 00:16:12,720
and it does not slow down your build or make your tests fail,

444
00:16:12,720 --> 00:16:14,120
but it is there every single day

445
00:16:14,120 --> 00:16:16,360
in the form of coordination overhead.

446
00:16:16,360 --> 00:16:18,640
Here is what the research actually says about this.

447
00:16:18,640 --> 00:16:21,040
High performing teams keep their collaborative overhead

448
00:16:21,040 --> 00:16:23,200
below 35% of their total time.

449
00:16:23,200 --> 00:16:25,360
That means 35% of their day is spent in meetings,

450
00:16:25,360 --> 00:16:28,040
waiting for input and unblocking dependencies.

451
00:16:28,040 --> 00:16:30,760
The other 65% is spent actually building.

452
00:16:30,760 --> 00:16:32,320
That threshold matters

453
00:16:32,320 --> 00:16:34,280
because it is the boundary between being productive

454
00:16:34,280 --> 00:16:35,280
and being stuck.

455
00:16:35,280 --> 00:16:38,400
Below 35% you are still a team that builds things.

456
00:16:38,400 --> 00:16:40,080
You have meetings and a coordination tax

457
00:16:40,080 --> 00:16:42,800
but it is manageable, it is just the cost of working together.

458
00:16:42,800 --> 00:16:45,200
Once you cross that line, you are in a different mode.

459
00:16:45,200 --> 00:16:47,280
You are no longer primarily building

460
00:16:47,280 --> 00:16:48,560
but primarily managing.

461
00:16:48,560 --> 00:16:50,200
You spend your time in meetings deciding

462
00:16:50,200 --> 00:16:52,240
how to coordinate, waiting for sign-offs

463
00:16:52,240 --> 00:16:54,760
and managing structure instead of building features.

464
00:16:54,760 --> 00:16:57,920
Most large organizations exceed that threshold easily.

465
00:16:57,920 --> 00:16:59,960
I have seen organizations where collaborative overhead

466
00:16:59,960 --> 00:17:02,560
is above 50%, meaning half the day is just coordination.

467
00:17:02,560 --> 00:17:04,760
That is not an outlier, that is normal.

468
00:17:04,760 --> 00:17:07,800
Your monorepal choice determines whether you see that overhead or not.

469
00:17:07,800 --> 00:17:10,200
In a monorepo, the coordination overhead is visible.

470
00:17:10,200 --> 00:17:13,920
It shows up in code reviews, build times and test failures.

471
00:17:13,920 --> 00:17:15,720
It shows up when you cannot merge

472
00:17:15,720 --> 00:17:18,240
because team C has not approved your change.

473
00:17:18,240 --> 00:17:20,000
The overhead is concrete, so you can see it,

474
00:17:20,000 --> 00:17:22,120
measure it and point to the exact cost.

475
00:17:22,120 --> 00:17:24,440
In a multi-repo, the coordination overhead hides.

476
00:17:24,440 --> 00:17:27,080
It hides in API design meetings, release planning

477
00:17:27,080 --> 00:17:28,560
and dependency management.

478
00:17:28,560 --> 00:17:31,320
It hides in the fact that you cannot deploy on your own schedule

479
00:17:31,320 --> 00:17:33,520
because you are waiting for another team to release.

480
00:17:33,520 --> 00:17:35,680
The overhead is there and you are definitely paying it,

481
00:17:35,680 --> 00:17:36,640
but it is invisible.

482
00:17:36,640 --> 00:17:39,320
You just feel slower than you should be without understanding why.

483
00:17:39,320 --> 00:17:43,000
This is where the architecture question becomes a business question.

484
00:17:43,000 --> 00:17:45,080
Once you see the coordination overhead,

485
00:17:45,080 --> 00:17:46,800
you have to decide what to do about it.

486
00:17:46,800 --> 00:17:49,520
You cannot just let it sit there and pretend it does not exist.

487
00:17:49,520 --> 00:17:51,480
You have to either pay down the organizational debt

488
00:17:51,480 --> 00:17:54,000
or accept that your organization will never move faster

489
00:17:54,000 --> 00:17:55,480
than that threshold allows.

490
00:17:55,480 --> 00:17:57,480
Most organizations make the wrong choice.

491
00:17:57,480 --> 00:17:59,640
They accept the overhead and the slow coordination.

492
00:17:59,640 --> 00:18:03,360
They accept the 35% benchmark as just how big organizations work

493
00:18:03,360 --> 00:18:05,800
and then they wonder why their competitors move faster.

494
00:18:05,800 --> 00:18:06,920
But there is another option.

495
00:18:06,920 --> 00:18:08,720
Why teams choose mono-repos?

496
00:18:08,720 --> 00:18:09,880
The real reasons.

497
00:18:09,880 --> 00:18:12,640
Teams don't adopt mono-repos because GitScale is better.

498
00:18:12,640 --> 00:18:13,720
Let's be honest about that.

499
00:18:13,720 --> 00:18:15,480
If scalability was the only issue,

500
00:18:15,480 --> 00:18:17,600
most organizations would just use a multi-repo.

501
00:18:17,600 --> 00:18:19,560
Separate repositories work fine at scale.

502
00:18:19,560 --> 00:18:21,440
You don't hit some magical technical ceiling

503
00:18:21,440 --> 00:18:22,800
where the system just snaps.

504
00:18:22,800 --> 00:18:24,600
The real reason teams choose mono-repos

505
00:18:24,600 --> 00:18:27,640
is because coordination in a multi-repo is painful.

506
00:18:27,640 --> 00:18:29,720
And they're willing to accept a different kind of pain

507
00:18:29,720 --> 00:18:32,320
to make the workflow, but here's the problem.

508
00:18:32,320 --> 00:18:34,760
A mono-repo makes cross-cutting changes atomic.

509
00:18:34,760 --> 00:18:37,120
When you're moving fast, when you're iterating,

510
00:18:37,120 --> 00:18:39,160
when you're responding to market feedback,

511
00:18:39,160 --> 00:18:41,680
you need to make changes that span multiple systems.

512
00:18:41,680 --> 00:18:43,120
Your API layer needs to change.

513
00:18:43,120 --> 00:18:44,960
Your authentication model needs to change.

514
00:18:44,960 --> 00:18:46,440
Your data contract needs to change.

515
00:18:46,440 --> 00:18:48,480
In a mono-repo, you make that change once,

516
00:18:48,480 --> 00:18:51,360
one commit, one code review, one deployment,

517
00:18:51,360 --> 00:18:52,800
everything moves together.

518
00:18:52,800 --> 00:18:54,480
Everything is validated together.

519
00:18:54,480 --> 00:18:56,480
Everything breaks together if it's going to break.

520
00:18:56,480 --> 00:18:57,400
And that's the point.

521
00:18:57,400 --> 00:18:59,240
You catch the problem immediately

522
00:18:59,240 --> 00:19:00,640
instead of discovering it in production

523
00:19:00,640 --> 00:19:02,520
when you try to integrate three different services.

524
00:19:02,520 --> 00:19:04,000
It's fast, it's coordinated.

525
00:19:04,000 --> 00:19:06,120
It doesn't require negotiation with other teams

526
00:19:06,120 --> 00:19:08,240
about when they're going to update their dependencies.

527
00:19:08,240 --> 00:19:10,840
It doesn't require waiting for multiple deployments to align.

528
00:19:10,840 --> 00:19:13,160
It doesn't require release notes and migration guides.

529
00:19:13,160 --> 00:19:14,880
You change the thing, you test the thing,

530
00:19:14,880 --> 00:19:17,360
you deploy the thing, done.

531
00:19:17,360 --> 00:19:19,000
This is powerful when your teams are actually

532
00:19:19,000 --> 00:19:21,560
co-located or well aligned, when team A and team B

533
00:19:21,560 --> 00:19:22,760
are in the same organization.

534
00:19:22,760 --> 00:19:23,840
They talk every day.

535
00:19:23,840 --> 00:19:25,400
They understand each other's constraints.

536
00:19:25,400 --> 00:19:26,960
They can coordinate quickly.

537
00:19:26,960 --> 00:19:29,880
A mono-repo lets them move at the speed of conversation.

538
00:19:29,880 --> 00:19:32,000
Instead of the speed of formal process,

539
00:19:32,000 --> 00:19:34,200
but there's another reason teams choose mono-repos.

540
00:19:34,200 --> 00:19:35,040
And it's more subtle.

541
00:19:35,040 --> 00:19:36,920
It's because they want to enforce standards

542
00:19:36,920 --> 00:19:38,320
when you have a strong platform team,

543
00:19:38,320 --> 00:19:40,680
a group of engineers who own the shared infrastructure.

544
00:19:40,680 --> 00:19:41,760
Who set the standards?

545
00:19:41,760 --> 00:19:43,800
Who decide how things should work?

546
00:19:43,800 --> 00:19:45,400
A mono-repo is a tool for enforcement.

547
00:19:45,400 --> 00:19:46,760
The platform team can enforce

548
00:19:46,760 --> 00:19:48,440
the limiting rules on every project.

549
00:19:48,440 --> 00:19:50,120
They can enforce testing standards.

550
00:19:50,120 --> 00:19:51,960
They can enforce naming conventions.

551
00:19:51,960 --> 00:19:54,520
They can decide what version of the compiler everyone uses.

552
00:19:54,520 --> 00:19:56,920
They can ensure everyone uses their shared authentication

553
00:19:56,920 --> 00:19:59,080
library instead of rolling their own.

554
00:19:59,080 --> 00:20:01,720
In a multi-repo, enforcing standards is soft.

555
00:20:01,720 --> 00:20:03,040
You can publish guidelines.

556
00:20:03,040 --> 00:20:04,320
You can create templates.

557
00:20:04,320 --> 00:20:06,520
You can ask teams to follow the policy.

558
00:20:06,520 --> 00:20:07,640
But you can't force it.

559
00:20:07,640 --> 00:20:09,720
Teams that own their own repositories

560
00:20:09,720 --> 00:20:11,400
can always decide to diverge.

561
00:20:11,400 --> 00:20:12,920
They can use their own build system.

562
00:20:12,920 --> 00:20:14,840
They can use their own authentication model.

563
00:20:14,840 --> 00:20:16,720
They can refuse to upgrade a shared library

564
00:20:16,720 --> 00:20:18,840
because they don't want to deal with the migration.

565
00:20:18,840 --> 00:20:20,760
In a mono-repo, enforcement is hard.

566
00:20:20,760 --> 00:20:22,040
There's only one build system.

567
00:20:22,040 --> 00:20:24,280
So you use the one the platform team chose.

568
00:20:24,280 --> 00:20:26,920
There's only one version of the authentication library.

569
00:20:26,920 --> 00:20:28,880
So you upgrade when the platform team upgrades.

570
00:20:28,880 --> 00:20:31,480
There's one-linting configuration, one testing framework,

571
00:20:31,480 --> 00:20:32,520
one deployment pipeline.

572
00:20:32,520 --> 00:20:34,720
You can't opt out because the code you're working on

573
00:20:34,720 --> 00:20:36,880
lives in the same system as everything else.

574
00:20:36,880 --> 00:20:38,840
For organizations that value consistency

575
00:20:38,840 --> 00:20:41,440
and coherence, that matters a lot.

576
00:20:41,440 --> 00:20:43,280
But here's the critical thing that decides

577
00:20:43,280 --> 00:20:45,320
whether a mono-repo actually succeeds.

578
00:20:45,320 --> 00:20:47,680
You have to invest in the infrastructure to make it work.

579
00:20:47,680 --> 00:20:50,360
Not just the git infrastructure, though that matters.

580
00:20:50,360 --> 00:20:51,720
You need the Spass checkout tool.

581
00:20:51,720 --> 00:20:53,160
So teams aren't downloading code.

582
00:20:53,160 --> 00:20:54,000
They don't need.

583
00:20:54,000 --> 00:20:55,280
You need the partial clone.

584
00:20:55,280 --> 00:20:56,880
So history doesn't become a bottleneck.

585
00:20:56,880 --> 00:20:59,680
You need the selective build so you're not recombiling everything.

586
00:20:59,680 --> 00:21:00,520
You need the caching.

587
00:21:00,520 --> 00:21:02,080
So repeated builds are fast.

588
00:21:02,080 --> 00:21:03,920
But also the organizational infrastructure.

589
00:21:03,920 --> 00:21:05,360
You need a clear governance model.

590
00:21:05,360 --> 00:21:06,680
You need documented standards.

591
00:21:06,680 --> 00:21:08,120
You need a platform team that's actually

592
00:21:08,120 --> 00:21:10,080
resourced to maintain and enforce them.

593
00:21:10,080 --> 00:21:12,160
You need onboarding their teachers' teams.

594
00:21:12,160 --> 00:21:14,640
How to work in the mono-repo without breaking things.

595
00:21:14,640 --> 00:21:17,480
You need clear ownership of different parts of the system.

596
00:21:17,480 --> 00:21:19,440
Most organizations don't have that capacity.

597
00:21:19,440 --> 00:21:21,480
Most organizations choose a mono-repo.

598
00:21:21,480 --> 00:21:24,080
Expect it to solve their coordination problems.

599
00:21:24,080 --> 00:21:25,880
And then discover that it just concentrates

600
00:21:25,880 --> 00:21:27,960
the coordination problem into one system

601
00:21:27,960 --> 00:21:30,720
without providing the infrastructure to manage it at scale.

602
00:21:30,720 --> 00:21:33,040
And that's where most organizations fail.

603
00:21:33,040 --> 00:21:34,280
The infrastructure trap.

604
00:21:34,280 --> 00:21:35,600
And this is where most organizations

605
00:21:35,600 --> 00:21:37,080
hit the infrastructure wall.

606
00:21:37,080 --> 00:21:38,920
A large mono-repo isn't just git.

607
00:21:38,920 --> 00:21:41,040
It's not just throw everything in one repository

608
00:21:41,040 --> 00:21:42,320
and let git handle it.

609
00:21:42,320 --> 00:21:44,160
That's a catastrophic misunderstanding.

610
00:21:44,160 --> 00:21:46,800
Git handles it fine from a version control perspective.

611
00:21:46,800 --> 00:21:48,600
The problem is everything else.

612
00:21:48,600 --> 00:21:50,200
Large mono-repos require tooling

613
00:21:50,200 --> 00:21:52,040
that doesn't come with git by default.

614
00:21:52,040 --> 00:21:53,760
Spass checkout is the first piece.

615
00:21:53,760 --> 00:21:55,840
This lets developers clone the repository,

616
00:21:55,840 --> 00:21:58,280
but only check out the directories they actually work on.

617
00:21:58,280 --> 00:22:01,000
You're pulling down the metadata for the entire mono-repo.

618
00:22:01,000 --> 00:22:03,800
You need to know about all the dependencies, all the structure,

619
00:22:03,800 --> 00:22:05,680
but you're not materializing the files

620
00:22:05,680 --> 00:22:07,680
you don't need on your local disk.

621
00:22:07,680 --> 00:22:09,800
Without this, a developer working on one service

622
00:22:09,800 --> 00:22:12,640
is downloading gigabytes of code for services they'll never touch.

623
00:22:12,640 --> 00:22:13,880
Partial clone is different.

624
00:22:13,880 --> 00:22:17,080
Partial clone lets you defer downloading file contents

625
00:22:17,080 --> 00:22:18,440
until you actually need them.

626
00:22:18,440 --> 00:22:20,320
You clone the repository, you get the history,

627
00:22:20,320 --> 00:22:24,520
you get the file names, but the actual file contents are lazy loaded.

628
00:22:24,520 --> 00:22:27,400
When you try to read a file, it downloads on demand.

629
00:22:27,400 --> 00:22:29,640
This cuts initial clone time from hours to minutes

630
00:22:29,640 --> 00:22:31,080
for massive repositories.

631
00:22:31,080 --> 00:22:33,120
Selective builds are where the real work happens.

632
00:22:33,120 --> 00:22:36,400
When a developer pushes code, you don't rebuild the entire mono-repo.

633
00:22:36,400 --> 00:22:38,120
You only rebuild the parts that changed.

634
00:22:38,120 --> 00:22:41,520
The services that depend on the changed code, the tests that are affected,

635
00:22:41,520 --> 00:22:44,120
you need a build system that understands the dependency graph

636
00:22:44,120 --> 00:22:47,440
deeply enough to know what changed and what it impacts.

637
00:22:47,440 --> 00:22:49,160
Most build systems don't have this.

638
00:22:49,160 --> 00:22:51,880
You need something sophisticated, something that knows which tests

639
00:22:51,880 --> 00:22:54,000
actually exercise which code paths.

640
00:22:54,000 --> 00:22:55,360
Caching is the final pillar.

641
00:22:55,360 --> 00:22:59,280
Build outputs need to be cached and reused across developers and CI runs.

642
00:22:59,280 --> 00:23:02,800
If one developer built a particular component and it hasn't changed,

643
00:23:02,800 --> 00:23:06,360
the next developer should use the cached result instead of rebuilding.

644
00:23:06,360 --> 00:23:10,040
This requires infrastructure to store and distribute those caches reliably.

645
00:23:10,040 --> 00:23:13,360
It requires coordination so that cache invalidation works correctly.

646
00:23:13,360 --> 00:23:15,320
This isn't optional infrastructure.

647
00:23:15,320 --> 00:23:17,040
This is essential.

648
00:23:17,040 --> 00:23:20,480
Without sparse checkout, your developers wait forever to clone.

649
00:23:20,480 --> 00:23:23,280
Without partial clone, your history becomes a bottleneck.

650
00:23:23,280 --> 00:23:25,800
Without selective builds, your CI takes hours.

651
00:23:25,800 --> 00:23:27,720
Because you're rebuilding things that haven't changed.

652
00:23:27,720 --> 00:23:30,440
Without caching, your builds are slow and resource-intensive.

653
00:23:30,440 --> 00:23:32,680
But here's the thing most organizations don't understand.

654
00:23:32,680 --> 00:23:34,720
Building this infrastructure is expensive.

655
00:23:34,720 --> 00:23:35,600
It takes years.

656
00:23:35,600 --> 00:23:39,800
It requires specialized engineers who understand both the domain and the problem deeply.

657
00:23:39,800 --> 00:23:42,960
Google built their monorepo infrastructure over decades.

658
00:23:42,960 --> 00:23:46,480
They have engineers whose entire job is making the monorepo work at scale.

659
00:23:46,480 --> 00:23:48,920
They built a custom build system called Basel,

660
00:23:48,920 --> 00:23:52,040
specifically to handle the dependency graph complexity.

661
00:23:52,040 --> 00:23:54,000
They built distributed caching infrastructure.

662
00:23:54,000 --> 00:23:56,280
They built distributed testing orchestration.

663
00:23:56,280 --> 00:23:57,560
Meta did the same thing.

664
00:23:57,560 --> 00:23:59,160
They built their own build system.

665
00:23:59,160 --> 00:24:01,040
They built sapling their own version control system,

666
00:24:01,040 --> 00:24:04,280
specifically because Git didn't do everything they needed for their monorepo.

667
00:24:04,280 --> 00:24:05,880
They invested substantially.

668
00:24:05,880 --> 00:24:07,400
Microsoft invested substantially.

669
00:24:07,400 --> 00:24:09,720
They built infrastructure for their monorepo.

670
00:24:09,720 --> 00:24:12,800
They built systems to handle the scale of their cloud services.

671
00:24:12,800 --> 00:24:14,760
Your organization probably doesn't have that capacity.

672
00:24:14,760 --> 00:24:19,400
Most organizations don't have a team of engineers dedicated to build system infrastructure.

673
00:24:19,400 --> 00:24:22,240
Most organizations don't have the budget to build custom tooling.

674
00:24:22,240 --> 00:24:26,960
Most organizations are running on whatever Git and whatever standard build system they happen to have

675
00:24:26,960 --> 00:24:31,840
without the specialized infrastructure that makes a large monorepo actually work.

676
00:24:31,840 --> 00:24:32,800
So what happens?

677
00:24:32,800 --> 00:24:33,800
You choose a monorepo.

678
00:24:33,800 --> 00:24:35,960
You expect it to solve your coordination problems.

679
00:24:35,960 --> 00:24:37,960
You expect developers to work efficiently.

680
00:24:37,960 --> 00:24:39,000
But then you hit the wall.

681
00:24:39,000 --> 00:24:40,880
Clones take too long, builds take too long.

682
00:24:40,880 --> 00:24:43,480
Spars checkout doesn't work right because nobody's maintained it.

683
00:24:43,480 --> 00:24:47,360
CI becomes glacial because you're trying to build and test the entire system on every change.

684
00:24:47,360 --> 00:24:50,080
Developers get frustrated because they're waiting all the time.

685
00:24:50,080 --> 00:24:52,960
The monorepo doesn't become a source of speed and coordination.

686
00:24:52,960 --> 00:24:54,080
It becomes a bottleneck.

687
00:24:54,080 --> 00:24:55,760
It becomes the thing slowing everyone down.

688
00:24:55,760 --> 00:24:58,600
It becomes the thing people complain about constantly.

689
00:24:58,600 --> 00:25:00,800
And at that point you've made the problem worse.

690
00:25:00,800 --> 00:25:05,120
Not better, you've taken the coordination problem that was invisible in a multi-repo or manageable

691
00:25:05,120 --> 00:25:06,640
in a smaller monorepo.

692
00:25:06,640 --> 00:25:10,160
And you've made it into an infrastructure problem that impacts every single developer every

693
00:25:10,160 --> 00:25:11,160
single day.

694
00:25:11,160 --> 00:25:12,440
That's the infrastructure trap.

695
00:25:12,440 --> 00:25:15,640
You choose the right structure but without the infrastructure to support it, the structure

696
00:25:15,640 --> 00:25:17,840
becomes a liability instead of an asset.

697
00:25:17,840 --> 00:25:21,280
Now let's talk about what actually happens when the monorepo breaks.

698
00:25:21,280 --> 00:25:23,320
The fragmentation problem.

699
00:25:23,320 --> 00:25:24,320
Repository level.

700
00:25:24,320 --> 00:25:27,640
Here's the thing about fragmentation that most organizations don't see coming.

701
00:25:27,640 --> 00:25:29,200
It's not about having too many repositories.

702
00:25:29,200 --> 00:25:31,000
It's not about Git repository count.

703
00:25:31,000 --> 00:25:34,120
The problem isn't, we have 40 repos instead of one.

704
00:25:34,120 --> 00:25:36,400
The problem is having the wrong repositories.

705
00:25:36,400 --> 00:25:39,400
Having repositories that don't match how your teams actually work.

706
00:25:39,400 --> 00:25:41,200
Having boundaries in the wrong places.

707
00:25:41,200 --> 00:25:44,840
Having a structure that forces you to work around the system instead of with it.

708
00:25:44,840 --> 00:25:47,760
When you have a monorepo that's too large, when you've hit the infrastructure wall and

709
00:25:47,760 --> 00:25:50,240
builds, our slow and coordination is painful.

710
00:25:50,240 --> 00:25:51,880
Something interesting starts to happen.

711
00:25:51,880 --> 00:25:53,400
Teams don't abandon the monorepo.

712
00:25:53,400 --> 00:25:56,320
They stay committed to it for the reasons they chose it in the first place.

713
00:25:56,320 --> 00:26:00,480
The shared standards, the ease of cross-cutting refactors, the unified visibility.

714
00:26:00,480 --> 00:26:02,360
But they stop using it the way it was designed.

715
00:26:02,360 --> 00:26:04,200
Instead they start creating workarounds.

716
00:26:04,200 --> 00:26:06,960
They carve out informal boundaries within the monorepo.

717
00:26:06,960 --> 00:26:10,280
Team A decides they're only going to touch their service and the shared libraries it directly

718
00:26:10,280 --> 00:26:11,280
depends on.

719
00:26:11,280 --> 00:26:14,040
They set up sparse checkout to only pull down those directories.

720
00:26:14,040 --> 00:26:17,240
They configure their local build to only rebuild what they need.

721
00:26:17,240 --> 00:26:21,200
They create local branch workflows that diverge from how everyone else is supposed to work.

722
00:26:21,200 --> 00:26:22,360
Team B does the same thing.

723
00:26:22,360 --> 00:26:24,280
They create their own checkout pattern.

724
00:26:24,280 --> 00:26:25,840
Their own build configuration.

725
00:26:25,840 --> 00:26:27,200
Their own branching convention.

726
00:26:27,200 --> 00:26:32,080
What was supposed to be one unified monorepo becomes a collection of de facto separate repositories

727
00:26:32,080 --> 00:26:34,320
all living within the same git instance.

728
00:26:34,320 --> 00:26:36,600
Parallel development tracks emerge.

729
00:26:36,600 --> 00:26:39,800
Team A is working on version 3.2 of a shared library.

730
00:26:39,800 --> 00:26:41,360
Team B hasn't upgraded yet.

731
00:26:41,360 --> 00:26:45,480
Team C skipped version 3.1 because of breaking changes they didn't want to deal with.

732
00:26:45,480 --> 00:26:49,080
So now you have different versions of the same library in flight in different parts of

733
00:26:49,080 --> 00:26:50,080
the monorepo.

734
00:26:50,080 --> 00:26:51,080
That shouldn't be possible.

735
00:26:51,080 --> 00:26:54,600
The whole point of a monorepo is one version of everything, but it is.

736
00:26:54,600 --> 00:26:58,600
Teams are managing their own checkouts, creating workarounds to avoid the coordination

737
00:26:58,600 --> 00:26:59,600
tax.

738
00:26:59,600 --> 00:27:02,360
The selective builds become selective in ways they weren't designed to be.

739
00:27:02,360 --> 00:27:05,760
A team configures their CI to only run tests for their service.

740
00:27:05,760 --> 00:27:09,600
They skip the cross cutting tests that would tell them if their change breaks anything

741
00:27:09,600 --> 00:27:10,600
else.

742
00:27:10,600 --> 00:27:13,000
They do this not out of malice but out of necessity.

743
00:27:13,000 --> 00:27:15,360
The full test suite takes too long.

744
00:27:15,360 --> 00:27:16,360
They can't wait for it.

745
00:27:16,360 --> 00:27:20,360
So they create a parallel testing world where they test only their part.

746
00:27:20,360 --> 00:27:22,080
Selective builds become invisible silos.

747
00:27:22,080 --> 00:27:25,200
You end up with local knowledge about which builds matter and which don't.

748
00:27:25,200 --> 00:27:28,640
You end up with developers who know they need to manually run a broader test if they're

749
00:27:28,640 --> 00:27:31,800
touching a shared library, but newer team members don't know that.

750
00:27:31,800 --> 00:27:35,440
You end up with breakage that should have been caught by automated tests but wasn't because

751
00:27:35,440 --> 00:27:38,800
the automated tests were configured to skip the affected areas.

752
00:27:38,800 --> 00:27:40,360
And here's what emerges from all of this.

753
00:27:40,360 --> 00:27:42,080
You end up with the worst of both worlds.

754
00:27:42,080 --> 00:27:46,600
You have a monorepo, so you have the centralized coordination problem, the unified build system,

755
00:27:46,600 --> 00:27:49,640
the everything is in one place infrastructure overhead.

756
00:27:49,640 --> 00:27:51,480
But you also have informal fragmentation.

757
00:27:51,480 --> 00:27:54,680
You have workarounds that make the system harder to understand.

758
00:27:54,680 --> 00:27:57,520
You have local conventions that contradict the global ones.

759
00:27:57,520 --> 00:28:00,640
You have implicit boundaries that contradict the explicit structure.

760
00:28:00,640 --> 00:28:02,200
The result is invisible coupling.

761
00:28:02,200 --> 00:28:03,800
Team A thinks they're isolated.

762
00:28:03,800 --> 00:28:05,800
They're only working on their service.

763
00:28:05,800 --> 00:28:09,400
But their service depends on a shared library that team B is changing.

764
00:28:09,400 --> 00:28:12,960
They don't see the dependency because it's hidden in the sparse checkout configuration.

765
00:28:12,960 --> 00:28:16,440
They don't know they need to coordinate because the system doesn't make it explicit.

766
00:28:16,440 --> 00:28:18,480
The deployment happens and something breaks.

767
00:28:18,480 --> 00:28:20,760
Unclear ownership becomes the default state.

768
00:28:20,760 --> 00:28:22,400
Nominally ownership is clear.

769
00:28:22,400 --> 00:28:23,400
There's a code owner's file.

770
00:28:23,400 --> 00:28:24,400
There's documentation.

771
00:28:24,400 --> 00:28:26,400
There's a team responsible for each service.

772
00:28:26,400 --> 00:28:30,120
But because teams are working around the system, the actual ownership becomes fuzzy when

773
00:28:30,120 --> 00:28:31,680
something breaks in the shared library.

774
00:28:31,680 --> 00:28:32,680
Who do you call?

775
00:28:32,680 --> 00:28:33,680
The official owners?

776
00:28:33,680 --> 00:28:34,680
But they didn't change it directly.

777
00:28:34,680 --> 00:28:36,960
They changed something else that broke it indirectly.

778
00:28:36,960 --> 00:28:39,360
Do you call the person who works on that part most frequently?

779
00:28:39,360 --> 00:28:41,920
Do you call the team who's changed calls the cascade?

780
00:28:41,920 --> 00:28:43,720
Slow integration becomes endemic.

781
00:28:43,720 --> 00:28:46,000
You're not getting the benefits of a monorepo.

782
00:28:46,000 --> 00:28:50,520
Atomic changes, unified testing, comprehensive validation because the workarounds have created

783
00:28:50,520 --> 00:28:56,560
implicit fragmentation, but you're also not getting the benefits of a multi-repo, clear contracts,

784
00:28:56,560 --> 00:28:58,640
explicit versioning autonomous teams.

785
00:28:58,640 --> 00:29:01,640
You're stuck in a hybrid state that has the downsides of both.

786
00:29:01,640 --> 00:29:04,080
This is fragmentation at the repository level.

787
00:29:04,080 --> 00:29:08,160
Not we have too many repositories per year, but we have a repository structure that doesn't

788
00:29:08,160 --> 00:29:10,040
match our actual work patterns.

789
00:29:10,040 --> 00:29:14,080
So we've layered workarounds on top of it that make the system harder to understand

790
00:29:14,080 --> 00:29:16,400
and harder to reason about.

791
00:29:16,400 --> 00:29:20,320
And this fragmentation at the repository level is a symptom of something deeper.

792
00:29:20,320 --> 00:29:23,000
It's a real fragmentation, organizational level.

793
00:29:23,000 --> 00:29:25,480
The mess in your repositories is just a symptom.

794
00:29:25,480 --> 00:29:28,280
It's a sign of something deeper happening inside your company.

795
00:29:28,280 --> 00:29:30,840
There's a rule in systems thinking called Conway's Law.

796
00:29:30,840 --> 00:29:35,120
It says that the structure of your software will always mirror the structure of your organization.

797
00:29:35,120 --> 00:29:39,040
If you have separate teams for backend, frontend, and operations, your code will have

798
00:29:39,040 --> 00:29:40,040
those same walls.

799
00:29:40,040 --> 00:29:43,640
If you organize around products where one team owns everything from the database to the

800
00:29:43,640 --> 00:29:45,440
UI, your code will follow that path.

801
00:29:45,440 --> 00:29:47,080
You can't separate the two.

802
00:29:47,080 --> 00:29:50,360
The boundaries in your code are just a map of the boundaries in your office.

803
00:29:50,360 --> 00:29:51,680
This works both ways.

804
00:29:51,680 --> 00:29:53,840
Your repository setup didn't just appear out of nowhere.

805
00:29:53,840 --> 00:29:56,640
It grew out of how you decided to structure your teams.

806
00:29:56,640 --> 00:30:01,080
And once that code structure exists, it locks those organizational silos in place.

807
00:30:01,080 --> 00:30:04,240
The moment you create separate repositories for backend and frontend, you've made it a

808
00:30:04,240 --> 00:30:07,000
physical reality that those are separate teams.

809
00:30:07,000 --> 00:30:10,520
You've drawn a line in the code that makes it much harder to redraw the lines in your

810
00:30:10,520 --> 00:30:11,840
organization later on.

811
00:30:11,840 --> 00:30:12,960
But here's the problem.

812
00:30:12,960 --> 00:30:15,520
If your teams are siloed, your repositories will be siloed.

813
00:30:15,520 --> 00:30:18,200
It doesn't matter if you pick a monorepo or a multi-repo.

814
00:30:18,200 --> 00:30:22,000
If your teams don't talk, if they have different goals, if they report to different bosses and

815
00:30:22,000 --> 00:30:24,480
follow different road maps, your code base will show it.

816
00:30:24,480 --> 00:30:27,960
In a monorepo, you'll see parts of the code that never actually touch.

817
00:30:27,960 --> 00:30:31,760
In a multi-repo, you'll see services with messy contracts and zero coordination.

818
00:30:31,760 --> 00:30:33,680
The fragmentation is there either way.

819
00:30:33,680 --> 00:30:37,080
And if your teams aren't aligned on standards, your code will be a mess.

820
00:30:37,080 --> 00:30:40,800
You can try to force standards in a monorepo because everyone uses the same build system,

821
00:30:40,800 --> 00:30:43,880
but if those rules don't make sense for how the teams actually work, they will find

822
00:30:43,880 --> 00:30:45,040
a way around them.

823
00:30:45,040 --> 00:30:48,560
They'll just end up with inconsistency hiding under a thin layer of uniformity.

824
00:30:48,560 --> 00:30:51,240
Because in reality, the repository doesn't fix the people.

825
00:30:51,240 --> 00:30:56,120
On the other hand, if your teams are coordinated and talk every day, a multi-repo can work perfectly.

826
00:30:56,120 --> 00:30:59,600
You get clear contracts between services and independent deployments that don't break

827
00:30:59,600 --> 00:31:00,600
things.

828
00:31:00,600 --> 00:31:03,840
And there is some extra work to keep things in sync, but it's manageable because the teams

829
00:31:03,840 --> 00:31:05,240
are moving in the same direction.

830
00:31:05,240 --> 00:31:06,680
They aren't fighting the system.

831
00:31:06,680 --> 00:31:07,680
They're using it.

832
00:31:07,680 --> 00:31:08,680
That's the critical insight.

833
00:31:08,680 --> 00:31:11,720
The repository choice doesn't fix organizational fragmentation.

834
00:31:11,720 --> 00:31:13,240
It just changes how you see it.

835
00:31:13,240 --> 00:31:16,720
A fragmented organization will eventually break a monorepo.

836
00:31:16,720 --> 00:31:19,840
You'll end up with informal boundaries and hidden dependencies that make the system

837
00:31:19,840 --> 00:31:21,400
impossible to understand.

838
00:31:21,400 --> 00:31:24,640
People will start complaining that the monorepo is slower on wieldy and they'll blame the

839
00:31:24,640 --> 00:31:25,640
tool.

840
00:31:25,640 --> 00:31:26,840
But the tool isn't the problem.

841
00:31:26,840 --> 00:31:30,880
The problem is that the organization isn't aligned enough to use a unified system.

842
00:31:30,880 --> 00:31:35,400
If you take that same fragmented organization and give them a multi-repo, the problems become

843
00:31:35,400 --> 00:31:36,400
explicit.

844
00:31:36,400 --> 00:31:39,600
You'll run into API versioning nightmares and release delays because nobody knows who

845
00:31:39,600 --> 00:31:40,600
owns what.

846
00:31:40,600 --> 00:31:44,400
People will say the multi-repo is inefficient, but that inefficiency is just an honest look

847
00:31:44,400 --> 00:31:46,440
at the fragmentation that was already there.

848
00:31:46,440 --> 00:31:49,160
So what's actually happening when your architecture feels broken?

849
00:31:49,160 --> 00:31:51,200
It's not that your repository strategy is wrong.

850
00:31:51,200 --> 00:31:53,480
It's that your organization is fragmented.

851
00:31:53,480 --> 00:31:57,760
And the repository you chose is just the container where that fragmentation lives.

852
00:31:57,760 --> 00:32:00,520
You can't fix a communication problem with a folder structure.

853
00:32:00,520 --> 00:32:03,200
You can only choose which version of the problem you want to deal with it.

854
00:32:03,200 --> 00:32:07,240
If this changed how you think about your architecture, follow me, Mercopeders, Unlinked

855
00:32:07,240 --> 00:32:08,240
in.

856
00:32:08,240 --> 00:32:10,440
The real fragmentation, organizational level.

857
00:32:10,440 --> 00:32:14,560
But the repository level fragmentation is just a surface symptom of something much deeper

858
00:32:14,560 --> 00:32:16,440
happening in your organization.

859
00:32:16,440 --> 00:32:19,000
There's a principle in systems thinking called Conway's Law.

860
00:32:19,000 --> 00:32:22,360
It says the structure of a system reflects the structure of the organization that built

861
00:32:22,360 --> 00:32:23,360
it.

862
00:32:23,360 --> 00:32:27,320
If your organization is built around functions, separate backend teams, separate front end

863
00:32:27,320 --> 00:32:31,880
teams, separate ops teams, your architecture will look exactly the same way.

864
00:32:31,880 --> 00:32:36,000
If your organization is built around products, teams that own an entire feature from the database

865
00:32:36,000 --> 00:32:39,240
to the UI, your architecture will be organized around products.

866
00:32:39,240 --> 00:32:40,560
You can't separate the two.

867
00:32:40,560 --> 00:32:43,200
The boundaries in your code mirror the boundaries in your organization.

868
00:32:43,200 --> 00:32:44,800
This works in both directions.

869
00:32:44,800 --> 00:32:48,000
Your repository structure didn't randomly emerge from nowhere.

870
00:32:48,000 --> 00:32:51,280
It came from decisions about how your organization is structured.

871
00:32:51,280 --> 00:32:54,640
And once it exists, it reinforces those organizational boundaries.

872
00:32:54,640 --> 00:32:57,880
Once you have separate repositories for backend and front end, you've made it concrete that

873
00:32:57,880 --> 00:32:59,360
those are separate teams.

874
00:32:59,360 --> 00:33:03,360
Once you've drawn the line there in code, it becomes much harder to redraw it in the organization.

875
00:33:03,360 --> 00:33:04,360
But here's the problem.

876
00:33:04,360 --> 00:33:07,320
If your teams are siloed, your repositories will be siloed.

877
00:33:07,320 --> 00:33:10,000
It doesn't matter if you choose Monorepo or Multi-Repo.

878
00:33:10,000 --> 00:33:14,000
If your teams don't talk to each other, if they have different priorities, if they report

879
00:33:14,000 --> 00:33:18,080
to different leaders, but if they have different budgets and different roadmaps, then your codebase

880
00:33:18,080 --> 00:33:19,080
will reflect that.

881
00:33:19,080 --> 00:33:22,200
In a Monorepo, you'll see it as separate parts that don't really integrate.

882
00:33:22,200 --> 00:33:27,400
In a multi-repo, you'll see it as repositories with unclear contracts and minimal coordination.

883
00:33:27,400 --> 00:33:29,400
But the fragmentation will be there either way.

884
00:33:29,400 --> 00:33:33,480
And if your teams are misaligned on standards, your code will be inconsistent, regardless

885
00:33:33,480 --> 00:33:35,080
of repository strategy.

886
00:33:35,080 --> 00:33:38,400
You can enforce standards in a Monorepo because there's only one build system for everyone

887
00:33:38,400 --> 00:33:39,400
to use.

888
00:33:39,400 --> 00:33:42,800
But if the standards don't make sense to the teams, if they conflict with how those teams

889
00:33:42,800 --> 00:33:44,840
work, then teams will find workarounds.

890
00:33:44,840 --> 00:33:48,000
You'll get inconsistency hidden beneath the surface of uniformity.

891
00:33:48,000 --> 00:33:51,840
Conversely, if your teams are well coordinated, if they talk frequently, if they understand

892
00:33:51,840 --> 00:33:56,160
each other's constraints and priorities, then a multi-repo can work beautifully.

893
00:33:56,160 --> 00:34:00,400
Clear contracts between services, explicit versioning independent deployments, yes, there's

894
00:34:00,400 --> 00:34:03,040
overhead, but it's manageable because the teams are aligned.

895
00:34:03,040 --> 00:34:04,520
They're not fighting the system.

896
00:34:04,520 --> 00:34:05,520
They're working with it.

897
00:34:05,520 --> 00:34:08,600
The repository choice doesn't fix organizational fragmentation.

898
00:34:08,600 --> 00:34:09,600
That's the critical insight.

899
00:34:09,600 --> 00:34:10,600
It doesn't fix it.

900
00:34:10,600 --> 00:34:12,480
It just exposes it in different ways.

901
00:34:12,480 --> 00:34:15,240
The fragmented organization will fragmented a Monorepo.

902
00:34:15,240 --> 00:34:18,880
You'll end up with workarounds and informal boundaries and implicit coupling.

903
00:34:18,880 --> 00:34:22,440
The system becomes hard to understand because the structure doesn't match how the teams

904
00:34:22,440 --> 00:34:23,440
actually work.

905
00:34:23,440 --> 00:34:26,160
A coordinated organization can make a multi-repo succeed.

906
00:34:26,160 --> 00:34:27,400
The teams communicate.

907
00:34:27,400 --> 00:34:29,120
The contracts are clear.

908
00:34:29,120 --> 00:34:30,360
Integration points are explicit.

909
00:34:30,360 --> 00:34:35,400
The coordination burden exists, but teams shoulder it together because they're aligned on the mission.

910
00:34:35,400 --> 00:34:39,640
This means choosing a Monorepo thinking it will solve coordination problems is a strategic

911
00:34:39,640 --> 00:34:40,640
mistake.

912
00:34:40,640 --> 00:34:43,680
You can't fix organizational fragmentation with a repository decision.

913
00:34:43,680 --> 00:34:45,840
You can only choose which form the fragmentation takes.

914
00:34:45,840 --> 00:34:50,360
If you choose Monorepo in a fragmented organization, you're making the fragmentation invisible.

915
00:34:50,360 --> 00:34:54,200
It hides in sparse checkouts and selective builds and informal boundaries.

916
00:34:54,200 --> 00:34:56,480
People think the Monorepo is slower and wieldy.

917
00:34:56,480 --> 00:34:57,600
They blame the tool.

918
00:34:57,600 --> 00:34:58,680
But the tool isn't the problem.

919
00:34:58,680 --> 00:35:02,960
The problem is that your organization isn't aligned enough to use a unified system effectively.

920
00:35:02,960 --> 00:35:07,600
If you choose multi-repo in a fragmented organization, you're making the fragmentation explicit.

921
00:35:07,600 --> 00:35:11,160
It shows up as API versioning challenges and release coordination problems and unclear

922
00:35:11,160 --> 00:35:12,240
contracts.

923
00:35:12,240 --> 00:35:14,320
People think the multi-repo is inefficient.

924
00:35:14,320 --> 00:35:18,720
But the inefficiency is just an honest representation of the organizational fragmentation that already

925
00:35:18,720 --> 00:35:19,720
existed.

926
00:35:19,720 --> 00:35:23,560
So what's actually happening when you experience fragmentation in your architecture is this.

927
00:35:23,560 --> 00:35:25,680
It's not that your repository strategy is wrong.

928
00:35:25,680 --> 00:35:27,640
It's that your organization is fragmented.

929
00:35:27,640 --> 00:35:32,520
The repository strategy you chose is just the container where that fragmentation manifests.

930
00:35:32,520 --> 00:35:34,600
The communication architecture model.

931
00:35:34,600 --> 00:35:37,120
Here is the frame shift that changes everything.

932
00:35:37,120 --> 00:35:39,440
Repository strategy isn't about how you store code.

933
00:35:39,440 --> 00:35:42,960
It isn't about git performance, scalability, or build times.

934
00:35:42,960 --> 00:35:45,040
Those are just downstream consequences.

935
00:35:45,040 --> 00:35:49,040
The real choice you are making when you pick a Monorepo or a multi-repo is a choice about

936
00:35:49,040 --> 00:35:51,200
how your organization will communicate.

937
00:35:51,200 --> 00:35:52,440
Think about it this way.

938
00:35:52,440 --> 00:35:56,720
When you put all your code in a Monorepo, you are making a statement about communication.

939
00:35:56,720 --> 00:35:58,760
You are saying that you are one system.

940
00:35:58,760 --> 00:36:01,960
All changes that affect the system must be visible to every part of that system at the

941
00:36:01,960 --> 00:36:02,960
same time.

942
00:36:02,960 --> 00:36:06,960
If your backend changes in API, the front end sees that change immediately.

943
00:36:06,960 --> 00:36:10,920
If you add a new field to a shared data model, every service using that model sees it.

944
00:36:10,920 --> 00:36:12,520
The communication happens through code.

945
00:36:12,520 --> 00:36:14,160
It happens through shared visibility.

946
00:36:14,160 --> 00:36:19,560
It happens because when you change something in the center, the impact ripples everywhere.

947
00:36:19,560 --> 00:36:21,240
Communication in a Monorepo is synchronous.

948
00:36:21,240 --> 00:36:22,320
It is visible.

949
00:36:22,320 --> 00:36:24,840
It happens through code review and failing tests.

950
00:36:24,840 --> 00:36:28,480
It happens through CI systems that validate that everything still works together.

951
00:36:28,480 --> 00:36:30,400
The coordination problem is front and center.

952
00:36:30,400 --> 00:36:31,520
You cannot hide from it.

953
00:36:31,520 --> 00:36:35,040
You have to address it the moment you make the change instead of waiting until you try

954
00:36:35,040 --> 00:36:36,320
to integrate later.

955
00:36:36,320 --> 00:36:40,160
A Monorepo centralizes communication into code, CI, and shared processes.

956
00:36:40,160 --> 00:36:44,160
The message your structure sends is that you coordinate tightly, you move together, and

957
00:36:44,160 --> 00:36:45,160
you validate together.

958
00:36:45,160 --> 00:36:46,360
Now take the opposite choice.

959
00:36:46,360 --> 00:36:48,640
You put each service in its own repository.

960
00:36:48,640 --> 00:36:50,800
You are making a different statement about communication.

961
00:36:50,800 --> 00:36:52,640
You are saying that you are many systems.

962
00:36:52,640 --> 00:36:54,520
Each system can evolve on its own.

963
00:36:54,520 --> 00:36:56,600
Communication between these systems happens at the boundary.

964
00:36:56,600 --> 00:37:00,560
It happens through contracts, APIs, and explicit versioning.

965
00:37:00,560 --> 00:37:02,440
Communication in a Monorepo is asynchronous.

966
00:37:02,440 --> 00:37:03,440
It is formal.

967
00:37:03,440 --> 00:37:07,640
It happens through published APIs, release notes, and versioning contracts.

968
00:37:07,640 --> 00:37:10,880
It happens through migration guides that explain how to upgrade to a new version.

969
00:37:10,880 --> 00:37:14,880
It happens through meetings where teams negotiate what the API should be before anyone even

970
00:37:14,880 --> 00:37:16,040
writes the code.

971
00:37:16,040 --> 00:37:20,520
The coordination problem is invisible in daily work, but it emerges at integration points.

972
00:37:20,520 --> 00:37:22,640
You do not see it until you try to deploy.

973
00:37:22,640 --> 00:37:25,880
You do not see it until you upgrade a dependency and something breaks.

974
00:37:25,880 --> 00:37:29,840
You do not see it until you realize that two teams built incompatible versions of the

975
00:37:29,840 --> 00:37:32,720
same thing because they were not looking at each other's code.

976
00:37:32,720 --> 00:37:38,240
A Monorepo decentralizes communication into APIs, contracts, and governance forums.

977
00:37:38,240 --> 00:37:41,920
The message your structure sends is that you move independently, you coordinate at boundaries

978
00:37:41,920 --> 00:37:43,840
and you respect each team's autonomy.

979
00:37:43,840 --> 00:37:45,720
Neither model is better.

980
00:37:45,720 --> 00:37:46,720
That is the thing.

981
00:37:46,720 --> 00:37:47,920
They are not better or worse.

982
00:37:47,920 --> 00:37:49,720
They are different communication architectures.

983
00:37:49,720 --> 00:37:52,680
They encode different assumptions about how your organization works.

984
00:37:52,680 --> 00:37:54,200
They create different friction points.

985
00:37:54,200 --> 00:37:55,680
They are quite different kinds of discipline.

986
00:37:55,680 --> 00:38:00,040
If you have a communication style that works by sitting together and talking frequently,

987
00:38:00,040 --> 00:38:02,440
then the Monorepo synchronous model fits.

988
00:38:02,440 --> 00:38:04,160
You can move at the speed of conversation.

989
00:38:04,160 --> 00:38:06,040
You can see ripple effects immediately.

990
00:38:06,040 --> 00:38:08,720
You can coordinate through shared code and shared process.

991
00:38:08,720 --> 00:38:12,440
If you have a communication style that works by publishing clear contracts and respecting

992
00:38:12,440 --> 00:38:15,400
boundaries, then the multi-repo asynchronous model fits.

993
00:38:15,400 --> 00:38:17,120
You can move independently.

994
00:38:17,120 --> 00:38:18,680
You can deploy on your own schedule.

995
00:38:18,680 --> 00:38:21,120
You can own your own destiny within your domain.

996
00:38:21,120 --> 00:38:22,400
But here is the critical insight.

997
00:38:22,400 --> 00:38:26,120
The fragmentation happens when your communication model does not match your actual communication

998
00:38:26,120 --> 00:38:27,120
patterns.

999
00:38:27,120 --> 00:38:31,600
If you adopt a Monorepo, but your teams actually communicate asynchronously, you have created

1000
00:38:31,600 --> 00:38:32,600
a mismatch.

1001
00:38:32,600 --> 00:38:36,360
If they are distributed across time zones and do not talk to each other, they have to coordinate

1002
00:38:36,360 --> 00:38:39,120
through formal processes instead of sitting together.

1003
00:38:39,120 --> 00:38:43,560
The Monorepo assumes synchronous communication, but you are operating asynchronously.

1004
00:38:43,560 --> 00:38:44,960
That mismatch creates friction.

1005
00:38:44,960 --> 00:38:45,960
It creates workarounds.

1006
00:38:45,960 --> 00:38:47,560
It creates fragmentation.

1007
00:38:47,560 --> 00:38:52,280
Conversely, if you adopt a multi-repo, but your teams actually need to communicate synchronously,

1008
00:38:52,280 --> 00:38:53,600
you have a different problem.

1009
00:38:53,600 --> 00:38:57,200
If you are moving fast and need cross-cutting changes to happen all at once, the formal

1010
00:38:57,200 --> 00:38:59,000
contract model creates bottlenecks.

1011
00:38:59,000 --> 00:39:01,600
You end up constantly negotiating about APIs.

1012
00:39:01,600 --> 00:39:07,040
The multi-repo assumes asynchronous boundary-based communication, but you need synchronous coordination.

1013
00:39:07,040 --> 00:39:10,320
The real fragmentation isn't about how many repositories you have.

1014
00:39:10,320 --> 00:39:14,920
It is about the gap between the communication model your structure assumes, and the communication

1015
00:39:14,920 --> 00:39:18,160
model your organization actually uses.

1016
00:39:18,160 --> 00:39:20,480
Diagnosing your actual communication pattern.

1017
00:39:20,480 --> 00:39:23,760
So now the practical question is, how you know if you have that mismatch?

1018
00:39:23,760 --> 00:39:27,520
How do you figure out what your organization actually needs versus what your repository structure

1019
00:39:27,520 --> 00:39:28,520
assumes?

1020
00:39:28,520 --> 00:39:30,120
The answer is simpler than you might think.

1021
00:39:30,120 --> 00:39:31,840
Stop looking at your documentation.

1022
00:39:31,840 --> 00:39:33,280
Stop looking at your org chart.

1023
00:39:33,280 --> 00:39:34,920
Stop looking at how you are supposed to work.

1024
00:39:34,920 --> 00:39:36,280
Look at how you actually work.

1025
00:39:36,280 --> 00:39:38,480
Watch what happens when a change needs to be made.

1026
00:39:38,480 --> 00:39:42,960
Let's say your product team decides you need to add a new field to a core data model.

1027
00:39:42,960 --> 00:39:47,040
This field needs to be added to the API, consumed by three different services, stored in the

1028
00:39:47,040 --> 00:39:49,280
database, and surfaced in the UI.

1029
00:39:49,280 --> 00:39:50,920
Now watch what happens next.

1030
00:39:50,920 --> 00:39:55,120
If most of the work happens in one repository with one code review and one deployment, you

1031
00:39:55,120 --> 00:39:56,480
have high coupling.

1032
00:39:56,480 --> 00:39:59,560
The field gets added to the data model and the API gets updated.

1033
00:39:59,560 --> 00:40:03,840
The three services in the UI get updated, one pull request, one review, and one deployment

1034
00:40:03,840 --> 00:40:05,760
means everything moves together.

1035
00:40:05,760 --> 00:40:07,840
That is the signal.

1036
00:40:07,840 --> 00:40:11,720
When changes like this are atomic and move together, your teams have high coupling.

1037
00:40:11,720 --> 00:40:13,200
They need to coordinate frequently.

1038
00:40:13,200 --> 00:40:15,360
They need to see each other's changes immediately.

1039
00:40:15,360 --> 00:40:16,640
They need unified visibility.

1040
00:40:16,640 --> 00:40:17,840
A monorepo makes that work.

1041
00:40:17,840 --> 00:40:19,920
A monorepo says that this is how you operate.

1042
00:40:19,920 --> 00:40:23,200
But imagine the same change requires coordinating across repositories.

1043
00:40:23,200 --> 00:40:27,120
If the data model lives in one repo and the API in another, while each service and the UI

1044
00:40:27,120 --> 00:40:29,760
have their own repositories, the process changes completely.

1045
00:40:29,760 --> 00:40:34,120
You have to make the change in the data model repo first and wait for that to be released.

1046
00:40:34,120 --> 00:40:38,000
Then you update the API repo to depend on the new version, then you update each service,

1047
00:40:38,000 --> 00:40:39,520
and finally you update the UI.

1048
00:40:39,520 --> 00:40:44,200
If it takes days or weeks to complete because each repository has its own release cycle, then

1049
00:40:44,200 --> 00:40:45,720
you have low coupling.

1050
00:40:45,720 --> 00:40:47,040
Your teams move independently.

1051
00:40:47,040 --> 00:40:48,960
They do not need to coordinate frequently.

1052
00:40:48,960 --> 00:40:50,200
They need explicit contracts.

1053
00:40:50,200 --> 00:40:51,400
A multi-repo works for this.

1054
00:40:51,400 --> 00:40:54,480
A multi-repo says that you move independently and talk at the boundary.

1055
00:40:54,480 --> 00:40:56,480
But here is where most organizations are actually living.

1056
00:40:56,480 --> 00:40:59,040
They are in between.

1057
00:40:59,040 --> 00:41:00,560
Some changes are independent.

1058
00:41:00,560 --> 00:41:03,720
Team A can add a feature to their service without touching anything else.

1059
00:41:03,720 --> 00:41:06,200
They deploy on their schedule and they own their domain.

1060
00:41:06,200 --> 00:41:07,200
That is low coupling.

1061
00:41:07,200 --> 00:41:08,920
But other changes require coordination.

1062
00:41:08,920 --> 00:41:11,360
The API team needs to work with the backend team.

1063
00:41:11,360 --> 00:41:13,920
The front end team needs to work with the data team.

1064
00:41:13,920 --> 00:41:17,680
Some changes are atomic while others are distributed across time and space.

1065
00:41:17,680 --> 00:41:19,680
That is when you know you have a structural mismatch.

1066
00:41:19,680 --> 00:41:24,120
If you have chosen a multi-repo for this scenario, the independent changes work great.

1067
00:41:24,120 --> 00:41:25,120
Team A ships fast.

1068
00:41:25,120 --> 00:41:26,800
But the coupled changes are painful.

1069
00:41:26,800 --> 00:41:30,480
You are stuck coordinating across repositories, managing, versioning and negotiating about

1070
00:41:30,480 --> 00:41:31,760
API contracts.

1071
00:41:31,760 --> 00:41:34,880
The multi-repo structure assumes low coupling, but you have a mix.

1072
00:41:34,880 --> 00:41:38,320
If you have chosen a monorepo for this scenario, the coupled changes work great.

1073
00:41:38,320 --> 00:41:39,800
They make the change automatically.

1074
00:41:39,800 --> 00:41:41,800
But the independent changes feel heavy.

1075
00:41:41,800 --> 00:41:43,400
Team A has to wait for the full build.

1076
00:41:43,400 --> 00:41:46,040
They have to go through the unified review process.

1077
00:41:46,040 --> 00:41:49,080
They have to work within the constraints of the monorepo's infrastructure.

1078
00:41:49,080 --> 00:41:51,880
The monorepo structure assumes high coupling, but you have a mix.

1079
00:41:51,880 --> 00:41:54,840
The mismatch creates friction.

1080
00:41:54,840 --> 00:41:56,320
Here is the diagnostic.

1081
00:41:56,320 --> 00:41:58,320
Look at where your friction is concentrated.

1082
00:41:58,320 --> 00:42:02,160
If you are experiencing long review cycles and slow builds while developers complain that

1083
00:42:02,160 --> 00:42:06,160
the system is heavy, but your teams actually work independently, then you probably have a

1084
00:42:06,160 --> 00:42:09,160
monorepo that assumes more coupling than you actually have.

1085
00:42:09,160 --> 00:42:11,880
You have built a heavyweight system for a lightweight problem.

1086
00:42:11,880 --> 00:42:15,840
If you are experiencing coordination nightmares and release scheduling problems while your teams

1087
00:42:15,840 --> 00:42:20,000
actually have high coupling, then you probably have a multi-repo that assumes more autonomy

1088
00:42:20,000 --> 00:42:21,160
than you actually have.

1089
00:42:21,160 --> 00:42:23,520
You have built a lightweight system for a heavyweight problem.

1090
00:42:23,520 --> 00:42:26,080
The fragmentation you are experiencing isn't random.

1091
00:42:26,080 --> 00:42:27,080
It is structural.

1092
00:42:27,080 --> 00:42:31,520
It is the system telling you that the communication model, your repository choice assumes, does

1093
00:42:31,520 --> 00:42:35,280
not match the communication model your organization actually uses.

1094
00:42:35,280 --> 00:42:36,560
That is the diagnosis.

1095
00:42:36,560 --> 00:42:38,400
The next question is what you do about it.

1096
00:42:38,400 --> 00:42:41,040
AI code generation and the verification tags.

1097
00:42:41,040 --> 00:42:42,880
The monorepo myth is becoming dangerous.

1098
00:42:42,880 --> 00:42:47,320
In 2024 and 2025, your organization is changing because AI code generation is now the

1099
00:42:47,320 --> 00:42:48,320
standard.

1100
00:42:48,320 --> 00:42:53,200
Developers are using GitHub, Co-Pilot, Claude and Curse to write code faster than ever before.

1101
00:42:53,200 --> 00:42:54,720
The data on this shift is clear.

1102
00:42:54,720 --> 00:42:58,160
AI generates code about 50% faster than a human can type.

1103
00:42:58,160 --> 00:43:00,440
This isn't just a small productivity boost.

1104
00:43:00,440 --> 00:43:03,160
It is a structural shift in how fast we produce software.

1105
00:43:03,160 --> 00:43:07,000
A developer with an AI agent can implement a feature or write boilerplate in half the

1106
00:43:07,000 --> 00:43:08,000
time.

1107
00:43:08,000 --> 00:43:09,000
They prototype faster.

1108
00:43:09,000 --> 00:43:10,080
They iterate faster.

1109
00:43:10,080 --> 00:43:11,760
But here is where the model breaks.

1110
00:43:11,760 --> 00:43:16,400
That AI generated code is sitting in code review 4.6 times longer than human written code.

1111
00:43:16,400 --> 00:43:20,480
We have a strange dynamic where code is produced at double the speed but reviewed at half the

1112
00:43:20,480 --> 00:43:21,480
speed.

1113
00:43:21,480 --> 00:43:25,320
The acceleration on the generation side is being completely canceled out by the deceleration

1114
00:43:25,320 --> 00:43:26,320
on the review side.

1115
00:43:26,320 --> 00:43:27,320
So why is this happening?

1116
00:43:27,320 --> 00:43:30,920
It isn't because your reviewers are lazy or your processes are broken.

1117
00:43:30,920 --> 00:43:32,520
It's because of fragmentation.

1118
00:43:32,520 --> 00:43:35,760
Your coordination system wasn't designed to handle this volume of change.

1119
00:43:35,760 --> 00:43:38,960
Think about what happens when an AI generates a new API endpoint.

1120
00:43:38,960 --> 00:43:42,720
In a fragmented architecture that change doesn't exist in a vacuum, the endpoint depends

1121
00:43:42,720 --> 00:43:45,800
on authentication, database updates and security validation.

1122
00:43:45,800 --> 00:43:48,920
It has to stay consistent with how every other endpoint works.

1123
00:43:48,920 --> 00:43:53,480
In a monorepo with tight coupling, these dependencies are visible immediately.

1124
00:43:53,480 --> 00:43:57,480
The AI's change triggers tests that fail because the database hasn't been updated yet.

1125
00:43:57,480 --> 00:44:00,920
It triggers linting failures because the code doesn't match your standards.

1126
00:44:00,920 --> 00:44:02,960
All these issues surface during the review.

1127
00:44:02,960 --> 00:44:07,120
The reviewer has to read the AI code, figure out what it's trying to do and validate every

1128
00:44:07,120 --> 00:44:08,320
place it touches.

1129
00:44:08,320 --> 00:44:09,320
That takes time.

1130
00:44:09,320 --> 00:44:13,920
And it takes more time than reviewing human code because AI is often less coherent.

1131
00:44:13,920 --> 00:44:17,120
It solves the immediate problem but lacks the context a human brings.

1132
00:44:17,120 --> 00:44:20,440
A human developer asks where a change fits in the broader architecture.

1133
00:44:20,440 --> 00:44:24,280
An AI just looks at the spec and generates something that technically works but might not

1134
00:44:24,280 --> 00:44:25,280
fit the big picture.

1135
00:44:25,280 --> 00:44:26,920
The reviewer has to fill in those gaps.

1136
00:44:26,920 --> 00:44:30,280
They have to validate the architectural fit, not just the code.

1137
00:44:30,280 --> 00:44:33,280
In a multi-repo setup, a different problem emerges.

1138
00:44:33,280 --> 00:44:37,480
The AI might change a services internal API but that change has to be backward compatible.

1139
00:44:37,480 --> 00:44:40,200
Now, the review has to validate the contract with other teams.

1140
00:44:40,200 --> 00:44:41,760
Does this break something downstream?

1141
00:44:41,760 --> 00:44:44,000
Does someone need to update the documentation?

1142
00:44:44,000 --> 00:44:46,240
The verification burden explodes.

1143
00:44:46,240 --> 00:44:47,760
But here is the critical insight.

1144
00:44:47,760 --> 00:44:53,000
AI generated code is produced at such a high volume that it simply overwhelms your coordination

1145
00:44:53,000 --> 00:44:54,000
system.

1146
00:44:54,000 --> 00:44:58,080
One developer using an AI tool can generate as much code in a day as they used to generate

1147
00:44:58,080 --> 00:44:58,920
in a week.

1148
00:44:58,920 --> 00:45:02,640
When you multiply that across a whole team, the volume of code hitting your bottlenecks

1149
00:45:02,640 --> 00:45:04,120
increases dramatically.

1150
00:45:04,120 --> 00:45:08,640
Your organization was not built to handle that much code while maintaining quality.

1151
00:45:08,640 --> 00:45:12,680
You end up in a state where AI accelerates production but slows down integration.

1152
00:45:12,680 --> 00:45:16,160
You are paying a verification tax at the point of maximum fragmentation.

1153
00:45:16,160 --> 00:45:19,680
If your organization is already struggling to coordinate, AI won't solve that.

1154
00:45:19,680 --> 00:45:20,680
It amplifies it.

1155
00:45:20,680 --> 00:45:23,600
It makes the bottleneck visible because that's where all the work is piling up.

1156
00:45:23,600 --> 00:45:27,240
The fragmentation you used to hide is now impossible to ignore.

1157
00:45:27,240 --> 00:45:28,680
The monorepo myth.

1158
00:45:28,680 --> 00:45:30,040
But everyone gets wrong.

1159
00:45:30,040 --> 00:45:33,200
We need to talk about what you've been told a monorepo will do for you.

1160
00:45:33,200 --> 00:45:37,320
There is a myth at the center of this decision that leads most organizations astray.

1161
00:45:37,320 --> 00:45:41,160
The myth is that a monorepo will reduce your coordination overhead and make you move faster.

1162
00:45:41,160 --> 00:45:42,160
That's the pitch.

1163
00:45:42,160 --> 00:45:44,440
You put all the code in one place and unify the build system.

1164
00:45:44,440 --> 00:45:46,200
You enforce one set of standards.

1165
00:45:46,200 --> 00:45:49,400
No more versioning nightmares or release conflicts.

1166
00:45:49,400 --> 00:45:51,480
Everything moves together and gets tested together.

1167
00:45:51,480 --> 00:45:55,160
It's a seductive idea because it sounds like it fixes the coordination problem directly,

1168
00:45:55,160 --> 00:45:56,440
but the reality is different.

1169
00:45:56,440 --> 00:45:58,800
A monorepo does not reduce coordination overhead.

1170
00:45:58,800 --> 00:46:00,880
It makes that overhead visible and concentrated.

1171
00:46:00,880 --> 00:46:02,200
The problem doesn't go away.

1172
00:46:02,200 --> 00:46:03,560
It just stops being invisible.

1173
00:46:03,560 --> 00:46:06,360
In a multi-repo world, coordination overhead is distributed.

1174
00:46:06,360 --> 00:46:09,800
It hides in meetings and API contracts that take weeks to negotiate.

1175
00:46:09,800 --> 00:46:12,160
It hides in version management and release schedules.

1176
00:46:12,160 --> 00:46:16,320
It's there, but it's spread out across the system so you can pretend it isn't happening.

1177
00:46:16,320 --> 00:46:18,640
In a monorepo, that overhead is concentrated.

1178
00:46:18,640 --> 00:46:20,800
You see it in code reviews and long build times.

1179
00:46:20,800 --> 00:46:24,160
You see it in merge conflicts because everyone is touching the same shared code.

1180
00:46:24,160 --> 00:46:28,080
You see it in CIFalias because when one service breaks, the impact on everything else is immediate.

1181
00:46:28,080 --> 00:46:29,760
The problem becomes undeniable.

1182
00:46:29,760 --> 00:46:31,600
This is where most organizations hit a wall.

1183
00:46:31,600 --> 00:46:34,440
They adopt a monorepo thinking it will reduce friction.

1184
00:46:34,440 --> 00:46:36,960
For about six months, it feels like it's working.

1185
00:46:36,960 --> 00:46:39,800
Cross-cutting changes are easier and the tooling feels clean.

1186
00:46:39,800 --> 00:46:41,560
But then the monorepo hits an inflection point.

1187
00:46:41,560 --> 00:46:44,120
The number of teams grows and the dependencies multiply.

1188
00:46:44,120 --> 00:46:47,400
Suddenly you are dealing with the same coordination problems you had before, but now they are all

1189
00:46:47,400 --> 00:46:48,880
in one system.

1190
00:46:48,880 --> 00:46:50,920
Because they are concentrated, they are uncomfortable.

1191
00:46:50,920 --> 00:46:53,680
You have slow builds because you're building more code.

1192
00:46:53,680 --> 00:46:56,920
You have merge conflicts because multiple teams are hitting the same files.

1193
00:46:56,920 --> 00:47:00,280
You have CIFalias that ripple across the entire organization.

1194
00:47:00,280 --> 00:47:03,040
The overhead that used to be hidden is now impossible to ignore.

1195
00:47:03,040 --> 00:47:05,680
At this point, many organizations make the wrong move.

1196
00:47:05,680 --> 00:47:09,040
They think the monorepo was a mistake and they try to split it apart again.

1197
00:47:09,040 --> 00:47:10,120
But they are missing the point.

1198
00:47:10,120 --> 00:47:11,960
The coordination problem was always there.

1199
00:47:11,960 --> 00:47:13,680
The monorepo just exposed it.

1200
00:47:13,680 --> 00:47:16,080
And that visibility is valuable if you actually use it.

1201
00:47:16,080 --> 00:47:18,800
A monorepo doesn't fix organizational fragmentation.

1202
00:47:18,800 --> 00:47:19,800
It exposes it.

1203
00:47:19,800 --> 00:47:24,640
If your teams aren't aligned or they aren't communicating, a monorepo forces you to deal with that right now.

1204
00:47:24,640 --> 00:47:25,840
You can't hide from it.

1205
00:47:25,840 --> 00:47:27,800
It's right there in your builds and your reviews.

1206
00:47:27,800 --> 00:47:30,600
A fragmented organization will blame the monorepo.

1207
00:47:30,600 --> 00:47:32,240
They'll say it's slow or hard to work with.

1208
00:47:32,240 --> 00:47:35,400
They'll split it up so the coordination problem becomes invisible again.

1209
00:47:35,400 --> 00:47:37,320
Then they can go back to thinking it's manageable.

1210
00:47:37,320 --> 00:47:39,840
But a coordinated organization sees something else.

1211
00:47:39,840 --> 00:47:41,400
They see exactly where the friction is.

1212
00:47:41,400 --> 00:47:44,880
They see which teams depend on each other and where decisions need to be made.

1213
00:47:44,880 --> 00:47:46,720
They invest in the infrastructure to make it work.

1214
00:47:46,720 --> 00:47:50,080
They clarify ownership and align teams around shared standards.

1215
00:47:50,080 --> 00:47:53,200
They build a CI system that can handle the complexity.

1216
00:47:53,200 --> 00:47:55,000
They do the actual organizational work.

1217
00:47:55,000 --> 00:47:57,320
The monorepo becomes a tool for moving fast.

1218
00:47:57,320 --> 00:48:01,040
Not because the problem went away, but because the problem is being actively managed.

1219
00:48:01,040 --> 00:48:02,440
That is the myth we need to break.

1220
00:48:02,440 --> 00:48:05,680
The choice of repository won't solve your coordination problems for you.

1221
00:48:05,680 --> 00:48:06,680
It won't.

1222
00:48:06,680 --> 00:48:07,920
But it will show you where they are.

1223
00:48:07,920 --> 00:48:12,200
And that is only valuable if you're willing to face what it's showing you.

1224
00:48:12,200 --> 00:48:13,720
The real work.

1225
00:48:13,720 --> 00:48:14,920
Organizational debt repayment.

1226
00:48:14,920 --> 00:48:16,600
Now you know what the actual problem is.

1227
00:48:16,600 --> 00:48:18,480
It's not the repository strategy.

1228
00:48:18,480 --> 00:48:19,480
It's not Git.

1229
00:48:19,480 --> 00:48:20,480
It's not the build system.

1230
00:48:20,480 --> 00:48:22,720
The actual problem is organizational debt.

1231
00:48:22,720 --> 00:48:25,720
Organizational debt is what happens when you accumulate unresolved decisions.

1232
00:48:25,720 --> 00:48:28,360
It's the result of compromises that feel necessary in the moment.

1233
00:48:28,360 --> 00:48:30,080
You say, "We'll deal with this later.

1234
00:48:30,080 --> 00:48:31,760
We'll clarify ownership next quarter.

1235
00:48:31,760 --> 00:48:34,200
We'll standardize the process once we have more capacity."

1236
00:48:34,200 --> 00:48:35,480
And then next quarter comes.

1237
00:48:35,480 --> 00:48:36,720
And you still haven't dealt with it.

1238
00:48:36,720 --> 00:48:37,720
Now there's a new problem.

1239
00:48:37,720 --> 00:48:39,400
The old one gets pushed down the list again.

1240
00:48:39,400 --> 00:48:40,840
That's organizational debt.

1241
00:48:40,840 --> 00:48:44,280
It's the accumulation of things you decided to live with instead of fix.

1242
00:48:44,280 --> 00:48:46,320
And like financial debt, it costs you interest.

1243
00:48:46,320 --> 00:48:48,600
Every day you live with an unresolved decision.

1244
00:48:48,600 --> 00:48:50,520
Every day you operate with unclear ownership.

1245
00:48:50,520 --> 00:48:53,560
Every day you have a duplicated process instead of a unified one.

1246
00:48:53,560 --> 00:48:54,560
That's costing you.

1247
00:48:54,560 --> 00:48:55,960
It costs you in slow decisions.

1248
00:48:55,960 --> 00:48:57,800
It costs you in wasted coordination effort.

1249
00:48:57,800 --> 00:49:01,520
It costs you in mistakes that happen because ownership is ambiguous.

1250
00:49:01,520 --> 00:49:03,920
Complex branching models are organizational debt.

1251
00:49:03,920 --> 00:49:08,560
You have a strategy that made sense at some point or at least felt safer than the alternative.

1252
00:49:08,560 --> 00:49:11,120
But now you're maintaining it even though it's slowing you down.

1253
00:49:11,120 --> 00:49:12,600
That's debt.

1254
00:49:12,600 --> 00:49:14,720
The ownership is organizational debt.

1255
00:49:14,720 --> 00:49:17,480
When someone changes code and nobody knows who to talk to.

1256
00:49:17,480 --> 00:49:20,080
When a service breaks and three different teams could be responsible.

1257
00:49:20,080 --> 00:49:23,120
When there's a code owner's file but nobody actually knows who owns it.

1258
00:49:23,120 --> 00:49:24,120
That's debt.

1259
00:49:24,120 --> 00:49:26,160
Duplicated processes are organizational debt.

1260
00:49:26,160 --> 00:49:30,120
Team A has a different build process than Team B because they evolved separately.

1261
00:49:30,120 --> 00:49:31,760
Nobody took the time to unify them.

1262
00:49:31,760 --> 00:49:35,480
One team uses one branching convention and another team uses a different one.

1263
00:49:35,480 --> 00:49:38,200
Approval process is vary by team or by service.

1264
00:49:38,200 --> 00:49:39,200
That's all debt.

1265
00:49:39,200 --> 00:49:43,160
All accumulating costs that you're paying invisibly through coordination overhead.

1266
00:49:43,160 --> 00:49:46,440
Fixing fragmentation isn't about choosing a better repository strategy.

1267
00:49:46,440 --> 00:49:48,600
You can't choose your way out of organizational debt.

1268
00:49:48,600 --> 00:49:50,160
You can't buy a tool that solves it.

1269
00:49:50,160 --> 00:49:52,880
It's not a technical problem that has a technical solution.

1270
00:49:52,880 --> 00:49:57,280
Fixing fragmentation requires doing the actual work of organizational debt repayment.

1271
00:49:57,280 --> 00:50:01,800
It requires clarifying ownership, sitting down and deciding who owns this service, who owns

1272
00:50:01,800 --> 00:50:05,600
the shared library, who decides when we make breaking changes, who gets paged at three

1273
00:50:05,600 --> 00:50:07,160
in the morning when it breaks.

1274
00:50:07,160 --> 00:50:08,680
And then documenting that.

1275
00:50:08,680 --> 00:50:11,200
Making it real, making it the truth, not a best guess.

1276
00:50:11,200 --> 00:50:13,000
It requires simplifying decision parts.

1277
00:50:13,000 --> 00:50:16,360
If a decision takes three layers of approval, you have organizational debt.

1278
00:50:16,360 --> 00:50:20,560
If a change requires consensus from six different teams, you have organizational debt.

1279
00:50:20,560 --> 00:50:23,000
Repaying that debt means pushing decisions down.

1280
00:50:23,000 --> 00:50:27,400
It means asking what's the minimum approval required to make this decision safely.

1281
00:50:27,400 --> 00:50:30,040
And then building a system that enforces that.

1282
00:50:30,040 --> 00:50:31,040
Nothing more.

1283
00:50:31,040 --> 00:50:33,640
It requires standardizing processes, not for standardization sake.

1284
00:50:33,640 --> 00:50:36,320
But because every variation in process is cognitive load.

1285
00:50:36,320 --> 00:50:40,400
We do it this way in this team, but that way in that team is a small tax.

1286
00:50:40,400 --> 00:50:43,160
It's a tax on every person trying to work across boundaries.

1287
00:50:43,160 --> 00:50:45,760
Standardizing means picking one way and committing to it.

1288
00:50:45,760 --> 00:50:47,000
Not always the best way.

1289
00:50:47,000 --> 00:50:48,680
Just one way and everyone using it.

1290
00:50:48,680 --> 00:50:50,600
Most organizations don't do this work.

1291
00:50:50,600 --> 00:50:53,480
Because it's hard because it's not visible in the sprint backlog.

1292
00:50:53,480 --> 00:50:55,280
Because it doesn't feel like shipping features.

1293
00:50:55,280 --> 00:50:58,600
The debt is being paid invisibly as coordination overhead.

1294
00:50:58,600 --> 00:51:02,080
And when you're paying invisibly, you can kind of pretend it's not there.

1295
00:51:02,080 --> 00:51:03,600
But here's the problem.

1296
00:51:03,600 --> 00:51:04,960
Organizations that don't do this work.

1297
00:51:04,960 --> 00:51:05,960
They stay fragmented.

1298
00:51:05,960 --> 00:51:08,600
They swap repository strategies and think that will help.

1299
00:51:08,600 --> 00:51:10,280
They buy new tools and think that will help.

1300
00:51:10,280 --> 00:51:12,760
They implement new branching models and think that will help.

1301
00:51:12,760 --> 00:51:13,800
And nothing changes.

1302
00:51:13,800 --> 00:51:17,040
Because the actual problem, the organizational debt, the unresolved decisions,

1303
00:51:17,040 --> 00:51:18,840
the unclear ownership is still there.

1304
00:51:18,840 --> 00:51:20,640
Organizations that do do this work.

1305
00:51:20,640 --> 00:51:21,760
They look completely different.

1306
00:51:21,760 --> 00:51:22,720
They move faster.

1307
00:51:22,720 --> 00:51:24,640
Not because of their repository strategy.

1308
00:51:24,640 --> 00:51:27,120
But because there's less coordination overhead to wade through,

1309
00:51:27,120 --> 00:51:28,440
they make better decisions.

1310
00:51:28,440 --> 00:51:29,680
Not because they're smarter.

1311
00:51:29,680 --> 00:51:33,200
But because decision paths are clear and responsibility is explicit,

1312
00:51:33,200 --> 00:51:34,680
they onboard people faster.

1313
00:51:34,680 --> 00:51:36,280
Not because of their tools.

1314
00:51:36,280 --> 00:51:39,800
But because the standards are consistent and the ownership is unambiguous.

1315
00:51:39,800 --> 00:51:41,720
The question isn't whether you'll do this work.

1316
00:51:41,720 --> 00:51:44,120
The question is whether you'll do it intentionally.

1317
00:51:44,120 --> 00:51:46,640
Or whether you'll keep paying the debt invisibly.

1318
00:51:46,640 --> 00:51:48,720
Wondering why your organization feels slow.

1319
00:51:48,720 --> 00:51:51,520
There's a pattern in organizations that actually solve this problem.

1320
00:51:51,520 --> 00:51:53,080
And it's worth understanding.

1321
00:51:53,080 --> 00:51:54,880
The trunk-based development pattern.

1322
00:51:54,880 --> 00:51:56,360
The pattern looks like this.

1323
00:51:56,360 --> 00:51:59,600
High performing organizations don't use complex branching strategies.

1324
00:51:59,600 --> 00:52:01,560
They don't maintain long-lived release branches.

1325
00:52:01,560 --> 00:52:04,960
They don't use separate development branches or intricate promotion paths.

1326
00:52:04,960 --> 00:52:07,520
They use something called trunk-based development.

1327
00:52:07,520 --> 00:52:10,200
In trunk-based development, there's one primary branch.

1328
00:52:10,200 --> 00:52:12,160
It's usually called main or master.

1329
00:52:12,160 --> 00:52:13,560
And the way it works is simple.

1330
00:52:13,560 --> 00:52:16,240
Developers work on features in short-lived branches.

1331
00:52:16,240 --> 00:52:18,640
When a feature is ready, they merge it back to main.

1332
00:52:18,640 --> 00:52:20,040
The whole cycle happens fast.

1333
00:52:20,040 --> 00:52:24,680
A branch might exist for a few hours or a few days, not weeks, not months, but days at most.

1334
00:52:24,680 --> 00:52:29,520
The key is that main is always in a deployable state, always.

1335
00:52:29,520 --> 00:52:30,120
Not.

1336
00:52:30,120 --> 00:52:31,360
We hope it's deployable.

1337
00:52:31,360 --> 00:52:34,600
Not, it should be deployable once we run the full test suite.

1338
00:52:34,600 --> 00:52:38,600
But actually, provably, measurably in a state where you could deploy it to production right

1339
00:52:38,600 --> 00:52:39,920
now if you needed to.

1340
00:52:39,920 --> 00:52:43,600
And because main is always deployable, because changes are moving to main frequently.

1341
00:52:43,600 --> 00:52:45,400
The coordination problem doesn't pile up.

1342
00:52:45,400 --> 00:52:47,160
Think about the alternative for a second.

1343
00:52:47,160 --> 00:52:50,760
In a complex branching model, you have a feature branch that lives for weeks.

1344
00:52:50,760 --> 00:52:53,080
During those weeks, other changes are going to main.

1345
00:52:53,080 --> 00:52:54,240
Other branches are being worked on.

1346
00:52:54,240 --> 00:52:57,840
The longer the feature branch lives, the more it diverges from main.

1347
00:52:57,840 --> 00:53:00,600
When you finally try to merge it back, you have massive conflicts.

1348
00:53:00,600 --> 00:53:03,120
You have to resolve weeks of other people's changes.

1349
00:53:03,120 --> 00:53:06,240
You have to retest everything because the codebase has moved so far.

1350
00:53:06,240 --> 00:53:08,000
The coordination problem compounds.

1351
00:53:08,000 --> 00:53:11,640
It accumulates by the time you merge, you're dealing with a huge coordination burden.

1352
00:53:11,640 --> 00:53:14,080
In trunk-based development, you don't let that accumulate.

1353
00:53:14,080 --> 00:53:15,280
You merge frequently.

1354
00:53:15,280 --> 00:53:19,320
You deal with conflicts as they happen, not later when they're exponentially worse.

1355
00:53:19,320 --> 00:53:22,360
You see the impact of your change on other work immediately.

1356
00:53:22,360 --> 00:53:25,080
Not weeks later when it's intertwined with a dozen other changes.

1357
00:53:25,080 --> 00:53:28,960
The coordination still happens, but it happens continuously in small increments rather than

1358
00:53:28,960 --> 00:53:30,480
in batches at the end.

1359
00:53:30,480 --> 00:53:33,560
And this is why it works for organizations that are trying to solve their fragmentation

1360
00:53:33,560 --> 00:53:38,920
problem because fragmentation gets solved by making coordination a continuous, visible process.

1361
00:53:38,920 --> 00:53:43,200
Not by trying to eliminate it, not by trying to hide it, but by making it the default state.

1362
00:53:43,200 --> 00:53:46,160
Now, does trunk-based development require infrastructure?

1363
00:53:46,160 --> 00:53:47,160
Yes.

1364
00:53:47,160 --> 00:53:48,840
You need strong CI/CD.

1365
00:53:48,840 --> 00:53:52,960
You need automated testing that runs quickly and validates that main is actually deployable.

1366
00:53:52,960 --> 00:53:56,960
You need feature flags so that you can merge incomplete work without exposing it to users.

1367
00:53:56,960 --> 00:54:00,120
You need monitoring and observability so you can catch problems quickly when they do

1368
00:54:00,120 --> 00:54:01,120
happen.

1369
00:54:01,120 --> 00:54:02,120
But here's the critical thing.

1370
00:54:02,120 --> 00:54:03,120
Those are tools.

1371
00:54:03,120 --> 00:54:04,360
They're important tools.

1372
00:54:04,360 --> 00:54:06,080
But they're not the core requirement.

1373
00:54:06,080 --> 00:54:09,560
The core requirement is that your teams are aligned on what "done" means.

1374
00:54:09,560 --> 00:54:12,360
If you have two teams with different definitions of "done".

1375
00:54:12,360 --> 00:54:14,800
trunk-based development will expose that immediately.

1376
00:54:14,800 --> 00:54:17,440
Team A thinks "done" means my feature works locally.

1377
00:54:17,440 --> 00:54:21,440
Team B thinks "done" means my feature has been tested in production for a week.

1378
00:54:21,440 --> 00:54:25,720
If those definitions are different, trunk-based development breaks because you're merging constantly

1379
00:54:25,720 --> 00:54:26,720
to main.

1380
00:54:26,720 --> 00:54:30,800
If main is always supposed to be deployable, but half your team thinks deployable is flexible

1381
00:54:30,800 --> 00:54:33,440
and the other half thinks it's rigid, you're going to have problems.

1382
00:54:33,440 --> 00:54:35,560
But that's not a problem with trunk-based development.

1383
00:54:35,560 --> 00:54:37,360
That's a problem with organizational misalignment.

1384
00:54:37,360 --> 00:54:39,560
And trunk-based development forces you to deal with it.

1385
00:54:39,560 --> 00:54:41,400
It won't let you pretend it's not there.

1386
00:54:41,400 --> 00:54:44,960
A coordinated organization can use trunk-based development beautifully.

1387
00:54:44,960 --> 00:54:46,440
The teams agree on what "done" means.

1388
00:54:46,440 --> 00:54:48,480
They enforce it through automated testing.

1389
00:54:48,480 --> 00:54:49,480
They merge constantly.

1390
00:54:49,480 --> 00:54:50,680
They move fast.

1391
00:54:50,680 --> 00:54:53,760
The coordination is continuous but manageable because everyone's pulling in the same

1392
00:54:53,760 --> 00:54:54,760
direction.

1393
00:54:54,760 --> 00:54:57,960
A fragmented organization will try trunk-based development and fail.

1394
00:54:57,960 --> 00:54:58,960
They'll blame it.

1395
00:54:58,960 --> 00:55:01,320
They'll say trunk-based development doesn't work at scale.

1396
00:55:01,320 --> 00:55:03,080
It requires too much infrastructure.

1397
00:55:03,080 --> 00:55:04,080
It's too risky.

1398
00:55:04,080 --> 00:55:06,520
But what they're actually discovering is their fragmentation.

1399
00:55:06,520 --> 00:55:07,920
The tool is just making it visible.

1400
00:55:07,920 --> 00:55:10,880
The pattern isn't that trunk-based development solves everything.

1401
00:55:10,880 --> 00:55:14,480
The pattern is that successful organizations use trunk-based development because they've

1402
00:55:14,480 --> 00:55:17,320
already done the work of alignment that makes it viable.

1403
00:55:17,320 --> 00:55:21,040
And the continuous coordination that trunk-based development requires keeps them aligned.

1404
00:55:21,040 --> 00:55:23,400
It prevents fragmentation from creeping back in.

1405
00:55:23,400 --> 00:55:26,120
Microsoft's release flow model, the blueprint.

1406
00:55:26,120 --> 00:55:30,280
Now let's look at what happens when an organization actually implements this at scale.

1407
00:55:30,280 --> 00:55:34,080
When they take trunk-based development and they do it right.

1408
00:55:34,080 --> 00:55:35,320
Microsoft is the perfect example here.

1409
00:55:35,320 --> 00:55:39,200
They build a model that is incredibly instructive because of the sheer scale they deal with

1410
00:55:39,200 --> 00:55:40,880
every single day.

1411
00:55:40,880 --> 00:55:42,880
Microsoft operates M365.

1412
00:55:42,880 --> 00:55:47,160
That's Outlook, Teams, SharePoint, OneDrive, Exchange Online.

1413
00:55:47,160 --> 00:55:48,160
These services are massive.

1414
00:55:48,160 --> 00:55:50,600
They have millions of people using them at the same time.

1415
00:55:50,600 --> 00:55:52,760
They process billions of operations every day.

1416
00:55:52,760 --> 00:55:54,440
The complexity is staggering.

1417
00:55:54,440 --> 00:55:58,800
And yet, Microsoft deploys changes to production multiple times per day, not once a week,

1418
00:55:58,800 --> 00:56:01,880
not once a day, multiple times across all of those interconnected services.

1419
00:56:01,880 --> 00:56:02,880
How do they do that?

1420
00:56:02,880 --> 00:56:04,880
They use something called release flow.

1421
00:56:04,880 --> 00:56:08,360
Release flow is the blueprint for making trunk-based development work when you have thousands

1422
00:56:08,360 --> 00:56:09,520
of developers.

1423
00:56:09,520 --> 00:56:10,520
Here is the model.

1424
00:56:10,520 --> 00:56:12,120
The team develops on a single trunk.

1425
00:56:12,120 --> 00:56:13,280
That is the main branch.

1426
00:56:13,280 --> 00:56:14,280
Changes are small.

1427
00:56:14,280 --> 00:56:15,280
They merge frequently.

1428
00:56:15,280 --> 00:56:17,680
The main branch is always in a state where it could be deployed.

1429
00:56:17,680 --> 00:56:20,440
All of this is standard trunk-based development.

1430
00:56:20,440 --> 00:56:22,920
And here is where release flow adds the critical layer.

1431
00:56:22,920 --> 00:56:26,320
Instead of deploying directly to everyone, instead of saying we merged it so everyone gets

1432
00:56:26,320 --> 00:56:28,080
it, they deploy in rings.

1433
00:56:28,080 --> 00:56:29,760
The first ring is the canary.

1434
00:56:29,760 --> 00:56:32,360
It is a tiny percentage of users, maybe 1%.

1435
00:56:32,360 --> 00:56:36,360
The code goes to production, and it starts processing real traffic for a very small group.

1436
00:56:36,360 --> 00:56:38,080
The monitoring is watching.

1437
00:56:38,080 --> 00:56:40,560
If something breaks, you see it immediately.

1438
00:56:40,560 --> 00:56:43,840
You can roll back, you can fix it, you can redeploy.

1439
00:56:43,840 --> 00:56:48,080
But the blast radius is tiny because you only affected 1% of your users.

1440
00:56:48,080 --> 00:56:51,560
If the canary is stable and the monitoring looks clean, you move to the next ring.

1441
00:56:51,560 --> 00:56:55,760
Maybe 5% of users, then 20%, then 50, then everyone.

1442
00:56:55,760 --> 00:56:57,080
Each ring takes time.

1443
00:56:57,080 --> 00:56:58,720
Each ring gathers more data.

1444
00:56:58,720 --> 00:57:01,160
Each ring proves that the change is safe.

1445
00:57:01,160 --> 00:57:04,120
And you only move forward if the previous ring succeeded.

1446
00:57:04,120 --> 00:57:08,440
This model separates two things that most organizations confuse, deployment and release.

1447
00:57:08,440 --> 00:57:12,040
Deployment is putting the code on servers, making it live, making it handle traffic, release

1448
00:57:12,040 --> 00:57:15,120
is letting users see it, making it available to customers.

1449
00:57:15,120 --> 00:57:17,280
Most organizations treat these as the same thing.

1450
00:57:17,280 --> 00:57:19,640
You deploy and you release at the same time.

1451
00:57:19,640 --> 00:57:21,880
The code goes live and the users see it.

1452
00:57:21,880 --> 00:57:24,080
Microsoft separates them.

1453
00:57:24,080 --> 00:57:27,680
Code gets deployed in the canary ring, and it is live.

1454
00:57:27,680 --> 00:57:29,280
But it is not released to users.

1455
00:57:29,280 --> 00:57:30,360
The code is running.

1456
00:57:30,360 --> 00:57:31,760
But users do not see it.

1457
00:57:31,760 --> 00:57:33,480
Feature flags control the experience.

1458
00:57:33,480 --> 00:57:38,520
So the canary ring is running the new code, but users still see the old behavior because

1459
00:57:38,520 --> 00:57:39,760
the flag is off.

1460
00:57:39,760 --> 00:57:41,640
Once you are confident the code is safe.

1461
00:57:41,640 --> 00:57:44,080
Once you have moved through the rings and proven it works.

1462
00:57:44,080 --> 00:57:45,160
Then you flip the flag.

1463
00:57:45,160 --> 00:57:46,160
That is the release.

1464
00:57:46,160 --> 00:57:47,280
It can happen instantly.

1465
00:57:47,280 --> 00:57:48,480
It can happen gradually.

1466
00:57:48,480 --> 00:57:50,560
It is completely decoupled from the deployment.

1467
00:57:50,560 --> 00:57:53,200
This matters because it changes the risk profile.

1468
00:57:53,200 --> 00:57:56,280
In traditional models, the risk of shipping bad code is acute.

1469
00:57:56,280 --> 00:57:58,640
You deploy and everyone sees it immediately.

1470
00:57:58,640 --> 00:58:00,680
If something goes wrong, it goes wrong for everyone.

1471
00:58:00,680 --> 00:58:02,480
The pressure to be perfect is enormous.

1472
00:58:02,480 --> 00:58:03,480
The testing is slow.

1473
00:58:03,480 --> 00:58:04,640
The review is heavy.

1474
00:58:04,640 --> 00:58:07,360
And you still deploy in frequently because the stakes are too high.

1475
00:58:07,360 --> 00:58:09,240
With release flow, the risk is distributed.

1476
00:58:09,240 --> 00:58:10,600
You deploy to 1%.

1477
00:58:10,600 --> 00:58:11,720
If it breaks, you catch it.

1478
00:58:11,720 --> 00:58:12,720
You roll back.

1479
00:58:12,720 --> 00:58:14,360
Only 1% of users had a problem.

1480
00:58:14,360 --> 00:58:15,360
The stakes are lower.

1481
00:58:15,360 --> 00:58:16,360
The blast radius is controlled.

1482
00:58:16,360 --> 00:58:18,240
And that means you can deploy more frequently.

1483
00:58:18,240 --> 00:58:19,560
Each deployment is lower risk.

1484
00:58:19,560 --> 00:58:23,200
You can deploy throughout the day because you aren't coordinating a massive event.

1485
00:58:23,200 --> 00:58:26,760
You are just moving code through a canary and waiting for it to prove itself.

1486
00:58:26,760 --> 00:58:29,280
Trunk-based development provides the coordination.

1487
00:58:29,280 --> 00:58:31,880
Release flow through rings provides the risk management.

1488
00:58:31,880 --> 00:58:33,440
Feature flags provide the decoupling.

1489
00:58:33,440 --> 00:58:35,920
Together they form a model that works at scale.

1490
00:58:35,920 --> 00:58:38,120
Not because the coordination problem went away.

1491
00:58:38,120 --> 00:58:41,240
But because the coordination is continuous and the risk is managed.

1492
00:58:41,240 --> 00:58:43,480
This is what fixing fragmentation actually looks like.

1493
00:58:43,480 --> 00:58:46,720
How to measure fragmentation, the real metrics.

1494
00:58:46,720 --> 00:58:48,560
So now you understand the actual problem.

1495
00:58:48,560 --> 00:58:50,160
It is organizational debt.

1496
00:58:50,160 --> 00:58:52,600
It is about alignment and coordination patterns.

1497
00:58:52,600 --> 00:58:55,400
You know that your repository strategy is just a symptom.

1498
00:58:55,400 --> 00:58:57,080
But how do you know if you are fragmented?

1499
00:58:57,080 --> 00:58:58,480
How do you actually measure it?

1500
00:58:58,480 --> 00:59:00,720
This is where most organizations get it completely wrong.

1501
00:59:00,720 --> 00:59:02,000
They count repositories.

1502
00:59:02,000 --> 00:59:03,000
They count branches.

1503
00:59:03,000 --> 00:59:05,000
They measure build times and code review latency.

1504
00:59:05,000 --> 00:59:08,480
They look at door or metrics and cycle time in all the technical signals that feel like

1505
00:59:08,480 --> 00:59:09,480
they should matter.

1506
00:59:09,480 --> 00:59:12,160
And none of that actually tells you if you are fragmented.

1507
00:59:12,160 --> 00:59:14,760
You can have three repositories and be completely fragmented.

1508
00:59:14,760 --> 00:59:17,280
You can have 50 repositories and be completely aligned.

1509
00:59:17,280 --> 00:59:21,080
You can have trunk-based development and still have massive coordination overhead.

1510
00:59:21,080 --> 00:59:22,920
The technical metrics are activity metrics.

1511
00:59:22,920 --> 00:59:24,200
They measure what is happening.

1512
00:59:24,200 --> 00:59:26,120
But they do not measure the outcome.

1513
00:59:26,120 --> 00:59:27,440
Fragmentation is not a technical problem.

1514
00:59:27,440 --> 00:59:29,240
It is an organizational outcome.

1515
00:59:29,240 --> 00:59:31,000
So what should you actually measure?

1516
00:59:31,000 --> 00:59:32,920
Measure coordination overhead.

1517
00:59:32,920 --> 00:59:34,560
That is the real metric.

1518
00:59:34,560 --> 00:59:38,440
Coordination overhead is the time your organization spends talking about work instead of building

1519
00:59:38,440 --> 00:59:39,440
it.

1520
00:59:39,440 --> 00:59:40,560
It is the hour spent in meetings.

1521
00:59:40,560 --> 00:59:42,520
It is the time waiting for approvals.

1522
00:59:42,520 --> 00:59:44,600
It is the time managing dependencies.

1523
00:59:44,600 --> 00:59:49,040
It is the rework that happens because one team didn't know what another team was doing.

1524
00:59:49,040 --> 00:59:52,440
Ask your team how much of your week is spent actively building and how much time is spent

1525
00:59:52,440 --> 00:59:56,240
waiting waiting for a review, waiting for an approval, waiting for another team to finish

1526
00:59:56,240 --> 00:59:57,240
their piece.

1527
00:59:57,240 --> 01:00:00,080
Most organizations have flow efficiency below 20%.

1528
01:00:00,080 --> 01:00:02,720
That means 80% of your lead time is just wait time.

1529
01:00:02,720 --> 01:00:06,000
You are spending 80% of your calendar on coordination overhead.

1530
01:00:06,000 --> 01:00:10,080
That is fragmentation, not the number of repositories, not the branching strategy.

1531
01:00:10,080 --> 01:00:13,520
At the amount of time your organization spends on coordination instead of value.

1532
01:00:13,520 --> 01:00:18,200
The research shows that high performing teams keep collaborative overhead below 35%.

1533
01:00:18,200 --> 01:00:19,200
That is the boundary.

1534
01:00:19,200 --> 01:00:21,880
Below 35% you are coordinating efficiently.

1535
01:00:21,880 --> 01:00:24,720
Above 35% you have crossed into fragmentation.

1536
01:00:24,720 --> 01:00:25,720
So start tracking it.

1537
01:00:25,720 --> 01:00:30,040
Of every hour a developer spends working, how much is active progress and how much is waiting.

1538
01:00:30,040 --> 01:00:31,040
Break it down.

1539
01:00:31,040 --> 01:00:32,400
When they are waiting, what are they waiting for?

1540
01:00:32,400 --> 01:00:35,520
If they are waiting for code reviews, your process is a bottleneck.

1541
01:00:35,520 --> 01:00:38,400
If they are waiting for approvals, your process has too many gates.

1542
01:00:38,400 --> 01:00:42,560
If they are waiting for another team, your dependencies are creating serialization points.

1543
01:00:42,560 --> 01:00:45,840
Each category of waiting points to a different fragmentation problem.

1544
01:00:45,840 --> 01:00:49,080
The beauty of measuring it this way is that it doesn't care about your tools.

1545
01:00:49,080 --> 01:00:52,520
You can measure this whether you use a monorepo or a thousand small ones.

1546
01:00:52,520 --> 01:00:56,240
The metric tells you the truth about your organization, not your repository.

1547
01:00:56,240 --> 01:00:57,440
And here is what matters.

1548
01:00:57,440 --> 01:01:01,840
Once you know your baseline, once you know you are at 17% flow efficiency.

1549
01:01:01,840 --> 01:01:05,280
Then you can start improving, but you cannot improve what you do not measure.

1550
01:01:05,280 --> 01:01:06,840
Most organizations never look at this.

1551
01:01:06,840 --> 01:01:08,000
They look at build times.

1552
01:01:08,000 --> 01:01:09,320
They optimize the build system.

1553
01:01:09,320 --> 01:01:10,720
They buy a faster CI tool.

1554
01:01:10,720 --> 01:01:15,520
They get the build time down by 30% and their developers still feel slow because the build

1555
01:01:15,520 --> 01:01:16,920
time was never the bottleneck.

1556
01:01:16,920 --> 01:01:17,920
It was the meetings.

1557
01:01:17,920 --> 01:01:18,920
It was the approvals.

1558
01:01:18,920 --> 01:01:20,360
It was the dependency coordination.

1559
01:01:20,360 --> 01:01:21,760
The metric keeps you honest.

1560
01:01:21,760 --> 01:01:24,160
It stops you from optimizing the wrong thing.

1561
01:01:24,160 --> 01:01:27,120
If your flow efficiency is low, your fragmentation is real.

1562
01:01:27,120 --> 01:01:29,000
It doesn't matter what your org chart says.

1563
01:01:29,000 --> 01:01:31,400
It doesn't matter what your repository strategy is.

1564
01:01:31,400 --> 01:01:32,760
The metric is telling you the truth.

1565
01:01:32,760 --> 01:01:36,520
And if your flow efficiency is low, you need to do the organizational work.

1566
01:01:36,520 --> 01:01:38,000
You need to clarify ownership.

1567
01:01:38,000 --> 01:01:39,720
You need to simplify decision paths.

1568
01:01:39,720 --> 01:01:43,240
You need to minimize the number of teams that have to coordinate on a single change.

1569
01:01:43,240 --> 01:01:45,200
No repository strategy will fix that.

1570
01:01:45,200 --> 01:01:47,000
No branching model will fix that.

1571
01:01:47,000 --> 01:01:49,200
Only organizational alignment will fix that.

1572
01:01:49,200 --> 01:01:51,720
Only reducing the actual coordination overhead will fix it.

1573
01:01:51,720 --> 01:01:52,720
So start measuring.

1574
01:01:52,720 --> 01:01:54,040
Track your flow efficiency.

1575
01:01:54,040 --> 01:01:55,720
Break down where the waiting happens.

1576
01:01:55,720 --> 01:01:58,480
And let the metric guide you toward the actual problem.

1577
01:01:58,480 --> 01:02:00,400
That is how you diagnose fragmentation.

1578
01:02:00,400 --> 01:02:04,000
Not by looking at your tools, but by looking at how your organization actually spends its

1579
01:02:04,000 --> 01:02:04,800
time.

1580
01:02:04,800 --> 01:02:07,080
It's the path forward reducing fragmentation.

1581
01:02:07,080 --> 01:02:10,200
Now that you know what to measure and what you're actually looking at, the question becomes

1582
01:02:10,200 --> 01:02:11,200
practical.

1583
01:02:11,200 --> 01:02:12,480
What do you actually do?

1584
01:02:12,480 --> 01:02:14,360
This is where most organizations get stuck.

1585
01:02:14,360 --> 01:02:15,560
They understand the diagnosis.

1586
01:02:15,560 --> 01:02:17,400
They know they have fragmentation.

1587
01:02:17,400 --> 01:02:19,160
They know it's an organizational problem.

1588
01:02:19,160 --> 01:02:22,960
And then they don't know how to move forward because the solution isn't a tool purchase.

1589
01:02:22,960 --> 01:02:24,200
It's not a software decision.

1590
01:02:24,200 --> 01:02:25,520
It's structural change.

1591
01:02:25,520 --> 01:02:26,520
But here's the problem.

1592
01:02:26,520 --> 01:02:28,080
You can't fix what you can't see.

1593
01:02:28,080 --> 01:02:31,640
First, you need to measure your actual communication patterns and coordination overhead.

1594
01:02:31,640 --> 01:02:32,840
You already know this.

1595
01:02:32,840 --> 01:02:34,760
Intellectually, but you need to make it quantitative.

1596
01:02:34,760 --> 01:02:38,840
You need to track for a representative two week period where your organization's time actually

1597
01:02:38,840 --> 01:02:41,720
goes, not where it's supposed to go, where it actually goes.

1598
01:02:41,720 --> 01:02:46,520
You'll discover that some teams have flow efficiency above 40% while others sit below

1599
01:02:46,520 --> 01:02:47,520
10.

1600
01:02:47,520 --> 01:02:48,520
That variation is a signal.

1601
01:02:48,520 --> 01:02:51,760
It tells you that some parts of your organization have solved the fragmentation problem

1602
01:02:51,760 --> 01:02:53,000
and other parts haven't.

1603
01:02:53,000 --> 01:02:56,840
That baseline measurement is everything until you have a number, until you know that you're

1604
01:02:56,840 --> 01:03:01,960
at 17% or 31% or 52% you're operating on assumption.

1605
01:03:01,960 --> 01:03:05,680
Second, map your organizational structure to your repository structure.

1606
01:03:05,680 --> 01:03:07,360
Draw out where your code actually lives.

1607
01:03:07,360 --> 01:03:09,120
Draw out where your teams actually sit.

1608
01:03:09,120 --> 01:03:11,320
And look for alignment or misalignment.

1609
01:03:11,320 --> 01:03:15,080
If you have a team that owns a microservice, is that service in its own repository?

1610
01:03:15,080 --> 01:03:17,600
Or is it embedded in a shared monorepo with eight other services?

1611
01:03:17,600 --> 01:03:20,360
If it's in a shared monorepo, is that by design or by accident?

1612
01:03:20,360 --> 01:03:24,320
If you have two teams that need to coordinate frequently, are they in separate repositories

1613
01:03:24,320 --> 01:03:27,040
forcing them to manage, versioning and contracts?

1614
01:03:27,040 --> 01:03:30,400
Or are they in the same repository where they can coordinate through shared code and share

1615
01:03:30,400 --> 01:03:31,400
testing?

1616
01:03:31,400 --> 01:03:35,080
And for a perfect answer, you're looking for intentionality and you're looking for cases

1617
01:03:35,080 --> 01:03:38,880
where the repository structure doesn't match how the teams actually work.

1618
01:03:38,880 --> 01:03:40,360
Those misalignments are costing you.

1619
01:03:40,360 --> 01:03:43,880
They're not obvious in the sprint backlog, but they're showing up in your flow efficiency

1620
01:03:43,880 --> 01:03:44,880
metric.

1621
01:03:44,880 --> 01:03:48,000
Third, identify where decision making is slow or unclear.

1622
01:03:48,000 --> 01:03:50,960
Walk through a representative change that required coordination.

1623
01:03:50,960 --> 01:03:51,960
Track it.

1624
01:03:51,960 --> 01:03:52,960
Where did it get stuck?

1625
01:03:52,960 --> 01:03:53,960
Where did it wait the longest?

1626
01:03:53,960 --> 01:03:54,960
Was it in code review?

1627
01:03:54,960 --> 01:03:56,680
Was it waiting for approval from another team?

1628
01:03:56,680 --> 01:04:00,160
Was it waiting for another service to be released before you could deploy your change?

1629
01:04:00,160 --> 01:04:01,160
Wherever it got stuck.

1630
01:04:01,160 --> 01:04:03,160
That's where organizational debt is concentrated.

1631
01:04:03,160 --> 01:04:05,920
That's where unresolved decisions are creating bottlenecks.

1632
01:04:05,920 --> 01:04:10,560
The most common stuck points are unclear ownership, too many approval gates and synchronized

1633
01:04:10,560 --> 01:04:11,800
dependencies.

1634
01:04:11,800 --> 01:04:16,560
Teams don't know who decides, so changes wait for a consensus that never forms, or changes

1635
01:04:16,560 --> 01:04:20,320
need approval from three different stakeholders and coordinating those three approvals takes

1636
01:04:20,320 --> 01:04:21,320
weeks.

1637
01:04:21,320 --> 01:04:24,160
Or your change can't deploy until another team's change is released, so you're blocked

1638
01:04:24,160 --> 01:04:25,160
on their schedule.

1639
01:04:25,160 --> 01:04:28,360
Those aren't technical problems, but they show up as technical friction.

1640
01:04:28,360 --> 01:04:32,840
Fourth, choose a repository strategy that matches your actual coupling, not your desired coupling.

1641
01:04:32,840 --> 01:04:34,760
This is where the rubber meets the road.

1642
01:04:34,760 --> 01:04:37,720
Look at the changes that create the most coordination overhead.

1643
01:04:37,720 --> 01:04:39,520
Look at what actually has to move together.

1644
01:04:39,520 --> 01:04:41,200
Is it your entire organization?

1645
01:04:41,200 --> 01:04:43,760
Then a monorapal with strong infrastructure might be right.

1646
01:04:43,760 --> 01:04:47,240
You're acknowledging that your teams are tightly coupled, and you're building a system

1647
01:04:47,240 --> 01:04:50,000
that makes that coupling explicit and manageable.

1648
01:04:50,000 --> 01:04:51,000
Are your teams independent?

1649
01:04:51,000 --> 01:04:52,760
Do they move on different schedules?

1650
01:04:52,760 --> 01:04:54,760
Do they have different definitions of done?

1651
01:04:54,760 --> 01:04:57,120
Then a multi-repa with clear contracts might be right.

1652
01:04:57,120 --> 01:05:00,240
You're acknowledging that your teams don't coordinate frequently, and you're building

1653
01:05:00,240 --> 01:05:02,080
a system that respects their autonomy.

1654
01:05:02,080 --> 01:05:03,080
Are you in between?

1655
01:05:03,080 --> 01:05:07,120
Then you need a hybrid model, some core services in a shared monorapal, product services

1656
01:05:07,120 --> 01:05:09,040
in separate repositories.

1657
01:05:09,040 --> 01:05:11,680
Explicit seems between the coupled and independent parts.

1658
01:05:11,680 --> 01:05:14,440
The worst choice is the choice that doesn't match reality.

1659
01:05:14,440 --> 01:05:18,280
A monorapal imposed on independent teams creates resentment and workarounds.

1660
01:05:18,280 --> 01:05:22,760
A multi-repa imposed on tightly coupled teams creates coordination nightmares.

1661
01:05:22,760 --> 01:05:24,600
Choose what fits how you actually work.

1662
01:05:24,600 --> 01:05:28,400
If, invest in the infrastructure that makes your choice viable at scale.

1663
01:05:28,400 --> 01:05:32,040
This is where commitment shows if you choose monorepo you need sparse checkout, partial

1664
01:05:32,040 --> 01:05:33,800
clone, selective builds and caching.

1665
01:05:33,800 --> 01:05:34,920
You need strong CI/CD.

1666
01:05:34,920 --> 01:05:35,920
You need feature flags.

1667
01:05:35,920 --> 01:05:39,360
You need the infrastructure that lets teams work in parts of the system without building

1668
01:05:39,360 --> 01:05:40,360
the whole thing.

1669
01:05:40,360 --> 01:05:43,160
Google and Meta and Microsoft have this infrastructure.

1670
01:05:43,160 --> 01:05:44,400
Most organizations don't.

1671
01:05:44,400 --> 01:05:46,160
Building it costs time and money.

1672
01:05:46,160 --> 01:05:48,400
But without it, the monorepo becomes a bottleneck.

1673
01:05:48,400 --> 01:05:50,800
If you choose multi-repo you need versioning discipline.

1674
01:05:50,800 --> 01:05:52,600
You need API governance.

1675
01:05:52,600 --> 01:05:54,560
You need clear contracts between services.

1676
01:05:54,560 --> 01:05:57,840
You need the discipline that keeps teams aligned even though they're working separately.

1677
01:05:57,840 --> 01:06:00,000
You need mechanisms to prevent API drift.

1678
01:06:00,000 --> 01:06:01,880
The infrastructure investment is non-negotiable.

1679
01:06:01,880 --> 01:06:03,040
It's not optional.

1680
01:06:03,040 --> 01:06:05,560
It's the cost of paying down your organizational debt.

1681
01:06:05,560 --> 01:06:06,680
Do these five things.

1682
01:06:06,680 --> 01:06:07,680
Not perfectly.

1683
01:06:07,680 --> 01:06:08,680
Not all at once.

1684
01:06:08,680 --> 01:06:09,680
But do them intentionally.

1685
01:06:09,680 --> 01:06:13,000
That's how you move from fragmentation to coherence.

1686
01:06:13,000 --> 01:06:14,760
The infrastructure investment mistake.

1687
01:06:14,760 --> 01:06:16,520
But here's where most organizations fail.

1688
01:06:16,520 --> 01:06:17,520
They make the choice.

1689
01:06:17,520 --> 01:06:19,200
They commit to a repository strategy.

1690
01:06:19,200 --> 01:06:22,480
And then they don't actually commit the resources required to make that choice work.

1691
01:06:22,480 --> 01:06:23,760
You see this pattern constantly.

1692
01:06:23,760 --> 01:06:26,600
A leadership team decides we're going monorepo.

1693
01:06:26,600 --> 01:06:27,600
That's the call.

1694
01:06:27,600 --> 01:06:29,520
We're consolidating our scattered repositories.

1695
01:06:29,520 --> 01:06:31,040
We're unifying our code base.

1696
01:06:31,040 --> 01:06:34,520
We're going to reap the benefits of shared visibility and atomic changes.

1697
01:06:34,520 --> 01:06:36,160
So they merge the repositories.

1698
01:06:36,160 --> 01:06:37,560
They unify the build system.

1699
01:06:37,560 --> 01:06:38,720
They celebrate the decision.

1700
01:06:38,720 --> 01:06:41,400
And then they expect Git to scale on its own.

1701
01:06:41,400 --> 01:06:42,400
It doesn't.

1702
01:06:42,400 --> 01:06:43,400
Git doesn't scale on its own.

1703
01:06:43,400 --> 01:06:45,600
Not at the size most large organizations operate.

1704
01:06:45,600 --> 01:06:47,360
Not with hundreds of developers.

1705
01:06:47,360 --> 01:06:48,760
Not with millions of lines of code.

1706
01:06:48,760 --> 01:06:51,400
Not with complex dependencies and interconnected services.

1707
01:06:51,400 --> 01:06:53,640
A monorepo at that scale needs infrastructure.

1708
01:06:53,640 --> 01:06:57,080
You need sparse checkouts so developers can work on their part of the system

1709
01:06:57,080 --> 01:07:00,320
without checking out the whole 500 gigabyte repository.

1710
01:07:00,320 --> 01:07:03,400
You need partial clone so the initial setup doesn't take hours.

1711
01:07:03,400 --> 01:07:07,160
You need selective builds so a change to one service doesn't trigger a rebuild of the entire

1712
01:07:07,160 --> 01:07:08,160
monolith.

1713
01:07:08,160 --> 01:07:12,200
You need aggressive caching so you're not re-computing the same builds over and over.

1714
01:07:12,200 --> 01:07:17,000
You need a build system that understands dependencies and can orchestrate work intelligently.

1715
01:07:17,000 --> 01:07:19,040
Most organizations don't have that infrastructure.

1716
01:07:19,040 --> 01:07:21,600
Because it takes work to build, it takes engineering capacity.

1717
01:07:21,600 --> 01:07:24,120
It takes decisions about how the system should work.

1718
01:07:24,120 --> 01:07:25,480
So what happens instead?

1719
01:07:25,480 --> 01:07:28,360
Teams start working around the limitations of the monorepo.

1720
01:07:28,360 --> 01:07:31,040
One team enables sparse checkout on their own.

1721
01:07:31,040 --> 01:07:34,280
Another team starts using a different build tool to work around the slowness.

1722
01:07:34,280 --> 01:07:38,080
A third team creates an unofficial sub-repost structure with their own branching patterns

1723
01:07:38,080 --> 01:07:39,080
and build process.

1724
01:07:39,080 --> 01:07:43,560
The monorepo that was supposed to unify the organization becomes a bottleneck instead.

1725
01:07:43,560 --> 01:07:45,920
And teams respond by fragmenting it informally.

1726
01:07:45,920 --> 01:07:49,280
They create boundaries within the monorepo that were never intended.

1727
01:07:49,280 --> 01:07:51,200
They work around the system instead of with it.

1728
01:07:51,200 --> 01:07:54,840
The irony is that you end up with the worst of both worlds.

1729
01:07:54,840 --> 01:07:59,680
You have a monorepo which assumes tight coupling and requires unified infrastructure.

1730
01:07:59,680 --> 01:08:03,560
But you have the workarounds and informal boundaries of a multi-repo, except without

1731
01:08:03,560 --> 01:08:06,000
the explicit contracts, without the clear expectations.

1732
01:08:06,000 --> 01:08:09,120
So you get both the coupling problems and the coordination problems.

1733
01:08:09,120 --> 01:08:10,800
That's what happens when you don't invest.

1734
01:08:10,800 --> 01:08:12,360
The opposite is equally common.

1735
01:08:12,360 --> 01:08:15,840
A different leadership team decides, we're going multi-repo.

1736
01:08:15,840 --> 01:08:17,160
We're respecting team autonomy.

1737
01:08:17,160 --> 01:08:21,160
We're letting each service be independently deployable and independently versioned.

1738
01:08:21,160 --> 01:08:24,400
We're reducing the coordination burden by giving teams clear boundaries.

1739
01:08:24,400 --> 01:08:25,600
Again, a good decision.

1740
01:08:25,600 --> 01:08:27,640
But then they don't invest in what makes it work.

1741
01:08:27,640 --> 01:08:29,560
A multi-repo requires discipline.

1742
01:08:29,560 --> 01:08:32,200
It requires teams to agree on versioning conventions.

1743
01:08:32,200 --> 01:08:33,960
It requires clear API contracts.

1744
01:08:33,960 --> 01:08:36,960
It requires governance about when you can make breaking changes.

1745
01:08:36,960 --> 01:08:41,560
It requires mechanisms to prevent version skew, where one service depends on version 2.0

1746
01:08:41,560 --> 01:08:45,760
of a library, but another service depends on version 1.5.

1747
01:08:45,760 --> 01:08:48,560
Most organizations expect teams to figure this out on their own.

1748
01:08:48,560 --> 01:08:50,560
They expect natural emergence of discipline.

1749
01:08:50,560 --> 01:08:54,680
They expect that once the repositories are separated, teams will automatically communicate

1750
01:08:54,680 --> 01:08:56,920
about their APIs and coordinate their releases.

1751
01:08:56,920 --> 01:08:58,080
They don't.

1752
01:08:58,080 --> 01:09:00,120
What happens instead is that teams drift.

1753
01:09:00,120 --> 01:09:04,480
One team's API changes in ways that break downstream consumers, but nobody is looking for

1754
01:09:04,480 --> 01:09:05,480
that.

1755
01:09:05,480 --> 01:09:08,480
One service upgrades to a new version of a shared library and another service doesn't.

1756
01:09:08,480 --> 01:09:10,760
And now you have incompatible versions running.

1757
01:09:10,760 --> 01:09:14,200
Teams decide on different standards for logging or error handling or configuration because

1758
01:09:14,200 --> 01:09:16,040
nobody enforced unified standards.

1759
01:09:16,040 --> 01:09:18,760
The multi-repo was supposed to reduce coordination.

1760
01:09:18,760 --> 01:09:21,720
But it trades visible coordination problems for invisible ones.

1761
01:09:21,720 --> 01:09:23,080
The problems don't go away.

1762
01:09:23,080 --> 01:09:26,480
They just hide until they surface as a production incident again.

1763
01:09:26,480 --> 01:09:30,640
The worst of both worlds, you have separate repositories, which assumes low coupling and

1764
01:09:30,640 --> 01:09:31,760
clear boundaries.

1765
01:09:31,760 --> 01:09:35,160
But you don't have the explicit contracts and governance that make it work.

1766
01:09:35,160 --> 01:09:37,960
So you get the autonomy problems and the coordination problems.

1767
01:09:37,960 --> 01:09:41,000
The infrastructure investment isn't about having the fanciest tools.

1768
01:09:41,000 --> 01:09:43,600
It's about committing to the operating model that your choice requires.

1769
01:09:43,600 --> 01:09:47,840
If you choose monorippo, you're committing to investing in selective builds and caching

1770
01:09:47,840 --> 01:09:51,200
and the infrastructure that lets teams work efficiently at that scale.

1771
01:09:51,200 --> 01:09:54,720
If you choose multi-repo, you're committing to investing in versioning governance and

1772
01:09:54,720 --> 01:09:59,960
API contracts and the discipline that keeps teams aligned even though they're working independently.

1773
01:09:59,960 --> 01:10:01,360
That investment isn't optional.

1774
01:10:01,360 --> 01:10:02,520
It's not nice to have.

1775
01:10:02,520 --> 01:10:04,280
It's the price of making your choice work.

1776
01:10:04,280 --> 01:10:05,680
Most organizations skip it.

1777
01:10:05,680 --> 01:10:08,720
They choose the repository strategy, but not the infrastructure.

1778
01:10:08,720 --> 01:10:12,520
And then they wonder why the strategy isn't delivering the promised benefits of it.

1779
01:10:12,520 --> 01:10:15,520
AI, fragmentation and the verification crisis.

1780
01:10:15,520 --> 01:10:18,920
Now let's talk about what happens when you add AI to this picture.

1781
01:10:18,920 --> 01:10:22,240
Because everything we've been discussing about fragmentation and coordination overhead,

1782
01:10:22,240 --> 01:10:23,240
AI doesn't solve it.

1783
01:10:23,240 --> 01:10:24,960
AI amplifies it.

1784
01:10:24,960 --> 01:10:26,760
And the amplification is happening right now.

1785
01:10:26,760 --> 01:10:28,560
The scale of code generation is accelerating.

1786
01:10:28,560 --> 01:10:32,240
A developer using modern AI tools isn't producing incremental improvements.

1787
01:10:32,240 --> 01:10:34,200
They're producing exponentially more code.

1788
01:10:34,200 --> 01:10:38,480
An individual can generate in a single day what would have taken a week without AI.

1789
01:10:38,480 --> 01:10:42,800
And when you multiply that across a team and an entire organization, the volume becomes

1790
01:10:42,800 --> 01:10:43,800
staggering.

1791
01:10:43,800 --> 01:10:47,080
The verification infrastructure was built for a different world.

1792
01:10:47,080 --> 01:10:50,160
It was built for a time when code generation was human-paced.

1793
01:10:50,160 --> 01:10:54,240
Back then, a team produced a predictable amount of code per sprint.

1794
01:10:54,240 --> 01:10:58,760
And that code moved through review and testing in a cadence that everyone could handle that

1795
01:10:58,760 --> 01:11:00,400
cadence is gone.

1796
01:11:00,400 --> 01:11:04,760
Now code is arriving at the verification system faster than the system can process it.

1797
01:11:04,760 --> 01:11:07,280
In a fragmented architecture, this creates a crisis.

1798
01:11:07,280 --> 01:11:11,440
Every change generated by AI still has to navigate your fragmentation.

1799
01:11:11,440 --> 01:11:13,560
It still has to pass through your review gates.

1800
01:11:13,560 --> 01:11:15,320
It's just for your approval processes.

1801
01:11:15,320 --> 01:11:19,240
And be checked against dependencies in a multi-repo or integrated into shared code in a

1802
01:11:19,240 --> 01:11:20,400
monorepo.

1803
01:11:20,400 --> 01:11:22,760
But now it's arriving 10 times faster.

1804
01:11:22,760 --> 01:11:25,320
In a monorepo environment, this creates an immediate bottleneck.

1805
01:11:25,320 --> 01:11:29,680
The CICD system gets overwhelmed, the build queue backs up, and developers end up sitting

1806
01:11:29,680 --> 01:11:31,640
around waiting for builds to complete.

1807
01:11:31,640 --> 01:11:35,240
The infrastructure that was supposed to be unified and fast becomes a choke point because

1808
01:11:35,240 --> 01:11:37,000
it was designed for a certain load.

1809
01:11:37,000 --> 01:11:39,320
And you've suddenly tripled that load overnight.

1810
01:11:39,320 --> 01:11:41,240
More than that, the review process breaks.

1811
01:11:41,240 --> 01:11:44,320
AI generated code requires more scrutiny, not less.

1812
01:11:44,320 --> 01:11:48,480
It's not that the AI is bad at writing code, but it lacks the contextual reasoning that

1813
01:11:48,480 --> 01:11:50,520
a human developer brings to the table.

1814
01:11:50,520 --> 01:11:53,480
It solves the immediate problem, but lacks architectural awareness.

1815
01:11:53,480 --> 01:11:57,800
So reviewers have to work harder to validate that the code actually fits into the bigger picture.

1816
01:11:57,800 --> 01:12:01,200
And now they're doing that deep review work on 10 times the volume.

1817
01:12:01,200 --> 01:12:04,560
In a multi-repo environment, a different kind of crisis emerges.

1818
01:12:04,560 --> 01:12:08,120
Every AI generated change that touches a service boundary has to be checked against

1819
01:12:08,120 --> 01:12:12,480
contracts with other services. It has to be validated for backward compatibility and reasoned

1820
01:12:12,480 --> 01:12:15,400
about in terms of how it affects every downstream consumer.

1821
01:12:15,400 --> 01:12:17,960
That's already a heavy overhead in a multi-repo.

1822
01:12:17,960 --> 01:12:19,640
At human speeds, it's manageable.

1823
01:12:19,640 --> 01:12:24,120
Teams coordinate on API contracts, discuss breaking changes, and plan migrations together.

1824
01:12:24,120 --> 01:12:25,640
It's formal, but it works.

1825
01:12:25,640 --> 01:12:27,360
At AI speeds, it becomes impossible.

1826
01:12:27,360 --> 01:12:30,120
You can't coordinate about every API change as it happens.

1827
01:12:30,120 --> 01:12:33,000
You can't negotiate every contract change in real time.

1828
01:12:33,000 --> 01:12:36,440
And you certainly can't plan migrations for code that was generated five minutes ago.

1829
01:12:36,440 --> 01:12:40,440
So the changes pile up. They're waiting for coordination, waiting for approval, waiting

1830
01:12:40,440 --> 01:12:41,880
for other teams to adapt.

1831
01:12:41,880 --> 01:12:46,880
The verification crisis is what happens when you apply AI scale generation to a fragmented

1832
01:12:46,880 --> 01:12:47,960
architecture.

1833
01:12:47,960 --> 01:12:49,320
And here's the critical thing.

1834
01:12:49,320 --> 01:12:52,720
This isn't a review capacity problem that you can solve by hiring more people or buying

1835
01:12:52,720 --> 01:12:53,720
better tools.

1836
01:12:53,720 --> 01:12:55,040
It's a coordination problem.

1837
01:12:55,040 --> 01:12:58,320
It's the fragmentation of your organization becoming visible in the form of backed up

1838
01:12:58,320 --> 01:13:01,240
cues and stagnant code.

1839
01:13:01,240 --> 01:13:03,360
Organizations without fragmentation handle this differently.

1840
01:13:03,360 --> 01:13:07,160
They see the volume of code arriving. They know it's AI generated and they have clear

1841
01:13:07,160 --> 01:13:08,880
mechanisms to validate it quickly.

1842
01:13:08,880 --> 01:13:12,360
They have clear ownership, clear standards, and clear contracts.

1843
01:13:12,360 --> 01:13:15,920
The verification still happens, but it's not delayed because there's no confusion about

1844
01:13:15,920 --> 01:13:18,440
who's responsible or which rules apply.

1845
01:13:18,440 --> 01:13:21,680
Organizations that are fragmented, they see the volume and they panic.

1846
01:13:21,680 --> 01:13:24,920
The fragmentation that was already slowing them down is now the limiting factor.

1847
01:13:24,920 --> 01:13:29,040
The coordination overhead that used to eat 30% of their time is now eating 60%.

1848
01:13:29,040 --> 01:13:32,800
The irony is that AI is the perfect exposure for fragmentation.

1849
01:13:32,800 --> 01:13:34,720
It's invisible when code moves slowly.

1850
01:13:34,720 --> 01:13:38,760
When things move at human speed, the coordination text feels manageable and you get used to

1851
01:13:38,760 --> 01:13:41,560
it without realizing how much time you're actually wasting.

1852
01:13:41,560 --> 01:13:45,320
But when AI generates code at 10 times the speed and your coordination system can't keep

1853
01:13:45,320 --> 01:13:48,080
up, the fragmentation becomes impossible to ignore.

1854
01:13:48,080 --> 01:13:51,560
The organizations that will win with AI aren't the ones that bought the best tools.

1855
01:13:51,560 --> 01:13:54,400
They're the ones that already solved their fragmentation problem.

1856
01:13:54,400 --> 01:13:58,840
They already have clear ownership, explicit contracts, and streamlined decision paths.

1857
01:13:58,840 --> 01:14:02,760
Because those organizations can take AI generated code and move it through their system at high

1858
01:14:02,760 --> 01:14:03,760
velocity.

1859
01:14:03,760 --> 01:14:06,920
The verification happens and the coordination happens, but it's not a bottleneck because

1860
01:14:06,920 --> 01:14:09,120
the organization is already optimized for it.

1861
01:14:09,120 --> 01:14:11,880
The fragmented organizations, they're about to hit a wall.

1862
01:14:11,880 --> 01:14:14,120
The future state unified architecture.

1863
01:14:14,120 --> 01:14:15,720
So what does winning actually look like?

1864
01:14:15,720 --> 01:14:17,200
What's the state you're trying to get to?

1865
01:14:17,200 --> 01:14:21,000
It's not about monorippo or multi-repo, it's not a specific repository strategy.

1866
01:14:21,000 --> 01:14:22,720
It's unified architecture.

1867
01:14:22,720 --> 01:14:25,800
And unified architecture is something different altogether.

1868
01:14:25,800 --> 01:14:29,280
Unified architecture means your organization has made intentional choices about how teams

1869
01:14:29,280 --> 01:14:32,000
communicate and how code moves through the system.

1870
01:14:32,000 --> 01:14:33,240
Those choices are consistent.

1871
01:14:33,240 --> 01:14:38,160
They're reinforced by your tooling, your governance, and your infrastructure.

1872
01:14:38,160 --> 01:14:40,800
In a unified architecture you have clear ownership.

1873
01:14:40,800 --> 01:14:44,320
Every service and every library has an owner, not in theory, but in reality.

1874
01:14:44,320 --> 01:14:47,600
There is a specific person or team you can go to with a question.

1875
01:14:47,600 --> 01:14:51,560
When something breaks, you know who's responsible and when you need to change someone else's

1876
01:14:51,560 --> 01:14:53,640
code, you know exactly who to talk to.

1877
01:14:53,640 --> 01:14:57,200
There's no ambiguity and no one ever says we're not sure who owns that.

1878
01:14:57,200 --> 01:14:59,080
You have explicit contracts.

1879
01:14:59,080 --> 01:15:02,120
Services have versioning policies and APIs are fully documented.

1880
01:15:02,120 --> 01:15:05,280
Teams agree on which breaking changes are allowed and how they're communicated to everyone

1881
01:15:05,280 --> 01:15:06,280
else.

1882
01:15:06,280 --> 01:15:08,720
If you change an API, you don't just hope people figure it out.

1883
01:15:08,720 --> 01:15:12,240
You follow a process, you announce it, and you provide migration paths.

1884
01:15:12,240 --> 01:15:13,680
The contract is explicit.

1885
01:15:13,680 --> 01:15:15,400
You have automated coordination.

1886
01:15:15,400 --> 01:15:17,440
The build system understands dependencies.

1887
01:15:17,440 --> 01:15:20,800
If service A depends on library B and someone changes that library, the system automatically

1888
01:15:20,800 --> 01:15:22,880
runs A's test to validate the change.

1889
01:15:22,880 --> 01:15:26,360
You don't have to manually coordinate or check because the system does it for you.

1890
01:15:26,360 --> 01:15:28,440
The coordination is automated and it's immediate.

1891
01:15:28,440 --> 01:15:30,440
You have continuous integration.

1892
01:15:30,440 --> 01:15:32,840
Code moves through the system constantly, not in batches.

1893
01:15:32,840 --> 01:15:37,200
It moves to the main branch frequently, gets validated immediately, and deploys quickly.

1894
01:15:37,200 --> 01:15:40,080
There's no integration event scheduled for three months from now.

1895
01:15:40,080 --> 01:15:43,280
There is continuous incremental integration happening every single hour.

1896
01:15:43,280 --> 01:15:47,400
The beautiful thing about unified architecture is that coordination is built into the system.

1897
01:15:47,400 --> 01:15:48,840
It's not something you add on top.

1898
01:15:48,840 --> 01:15:51,480
It's not something you do in meetings or over long email threads.

1899
01:15:51,480 --> 01:15:55,000
It's something your infrastructure enforces and your tools make happen.

1900
01:15:55,000 --> 01:15:56,960
This is where AI actually becomes powerful.

1901
01:15:56,960 --> 01:16:00,880
In a fragmented architecture, AI is a problem because the fragmentation is the bottleneck.

1902
01:16:00,880 --> 01:16:04,400
You generate code fast, but you can't integrate it because your coordination system can't

1903
01:16:04,400 --> 01:16:05,680
keep up.

1904
01:16:05,680 --> 01:16:08,480
In a unified architecture, AI is a force multiplier.

1905
01:16:08,480 --> 01:16:11,800
You generate code fast and the system validates it automatically.

1906
01:16:11,800 --> 01:16:14,840
The dependencies are clear, so the system catches problems immediately.

1907
01:16:14,840 --> 01:16:18,880
The ownership is clear, so the code goes to the right reviewers, and the contracts are

1908
01:16:18,880 --> 01:16:19,880
explicit.

1909
01:16:19,880 --> 01:16:22,440
The system verifies that the AI didn't break anything.

1910
01:16:22,440 --> 01:16:27,360
An AI tool generating code in a unified architecture isn't struggling through coordination overhead.

1911
01:16:27,360 --> 01:16:29,600
It's moving through a system designed to handle it.

1912
01:16:29,600 --> 01:16:34,560
The code gets generated, hits the CI system, and the system runs tests, validates dependencies

1913
01:16:34,560 --> 01:16:37,240
and checks contracts against unified standards.

1914
01:16:37,240 --> 01:16:39,320
All of that happens automatically and quickly.

1915
01:16:39,320 --> 01:16:42,880
If something looks suspicious, or if the AI tool generates something that doesn't fit

1916
01:16:42,880 --> 01:16:46,880
the pattern, the system flags it immediately, not days later when someone finally gets

1917
01:16:46,880 --> 01:16:48,040
around to reviewing it.

1918
01:16:48,040 --> 01:16:49,840
But right away, the feedback loop is tied.

1919
01:16:49,840 --> 01:16:52,760
Right, the AI can be corrected, and the code moves through.

1920
01:16:52,760 --> 01:16:57,400
That's the environment where AI stops being a crisis and starts being a productivity multiplier.

1921
01:16:57,400 --> 01:17:01,800
Organizations that achieve unified architecture move differently than fragmented ones.

1922
01:17:01,800 --> 01:17:03,200
They move faster.

1923
01:17:03,200 --> 01:17:06,040
Not just a little bit faster, exponentially faster.

1924
01:17:06,040 --> 01:17:10,440
The research suggests 10 times faster on delivery metrics, 10 times faster on lead time, and 10

1925
01:17:10,440 --> 01:17:14,400
times faster on how quickly you can respond to what your customers actually need.

1926
01:17:14,400 --> 01:17:15,800
That's not because the people are smarter.

1927
01:17:15,800 --> 01:17:18,320
It's because they've eliminated the coordination tax.

1928
01:17:18,320 --> 01:17:22,280
The system moves through without friction, the infrastructure handles the verification,

1929
01:17:22,280 --> 01:17:24,040
and the tooling handles the coordination.

1930
01:17:24,040 --> 01:17:26,680
The people just focus on building, and that's what you're building toward.

1931
01:17:26,680 --> 01:17:30,960
Not a specific repository strategy or a branching model, but a unified system where coordination

1932
01:17:30,960 --> 01:17:33,400
is automatic and code moves fast.

1933
01:17:33,400 --> 01:17:35,560
This is the future state, and it's achievable.

1934
01:17:35,560 --> 01:17:39,760
It's not easy, and it requires real work, but organizations are doing it right now.

1935
01:17:39,760 --> 01:17:43,600
The question is whether your organization will be one of them.

1936
01:17:43,600 --> 01:17:44,800
The decision framework.

1937
01:17:44,800 --> 01:17:45,800
What to do Monday?

1938
01:17:45,800 --> 01:17:47,360
You understand the diagnosis now?

1939
01:17:47,360 --> 01:17:48,760
You know where fragmentation comes from?

1940
01:17:48,760 --> 01:17:50,840
It is organizational, not technical.

1941
01:17:50,840 --> 01:17:53,240
You know what to measure, but the question is practical.

1942
01:17:53,240 --> 01:17:55,000
What decision do you actually make on Monday?

1943
01:17:55,000 --> 01:17:56,000
Here is a framework.

1944
01:17:56,000 --> 01:17:59,160
It is not the only way to think about this, but it is a way that works.

1945
01:17:59,160 --> 01:18:00,320
Start with one question.

1946
01:18:00,320 --> 01:18:02,080
How are your teams actually coupled?

1947
01:18:02,080 --> 01:18:05,320
This is the foundational insight, not how you wish they were coupled, not how your

1948
01:18:05,320 --> 01:18:08,480
org chart says they should be coupled, but how they actually work.

1949
01:18:08,480 --> 01:18:11,840
If you trace the changes that require the most coordination, where does that coupling

1950
01:18:11,840 --> 01:18:12,840
live?

1951
01:18:12,840 --> 01:18:15,680
Look for the changes that involve the most teams.

1952
01:18:15,680 --> 01:18:17,800
Look for the work that forces people into meetings.

1953
01:18:17,800 --> 01:18:20,480
If your teams are tightly coupled, a monorepo makes sense.

1954
01:18:20,480 --> 01:18:24,040
This is for the groups where most changes involve multiple teams.

1955
01:18:24,040 --> 01:18:27,400
It is for the people frequently refactoring across service boundaries.

1956
01:18:27,400 --> 01:18:30,640
It is for the systems with shared dependencies that must move together.

1957
01:18:30,640 --> 01:18:34,160
By choosing a monorepo, you are acknowledging the reality of that coupling.

1958
01:18:34,160 --> 01:18:35,800
You are building a system designed for it.

1959
01:18:35,800 --> 01:18:39,000
You are moving coordination into your tooling, so it doesn't get lost in a calendar full

1960
01:18:39,000 --> 01:18:40,000
of meetings.

1961
01:18:40,000 --> 01:18:41,640
But the investment is substantial.

1962
01:18:41,640 --> 01:18:42,720
You need sparse checkout.

1963
01:18:42,720 --> 01:18:44,280
You need selective builds.

1964
01:18:44,280 --> 01:18:46,440
You need feature flags and canary deployments.

1965
01:18:46,440 --> 01:18:49,560
You need monitoring that catches problems before they ever reach a user.

1966
01:18:49,560 --> 01:18:52,680
If your teams are tightly coupled, you are already paying for it.

1967
01:18:52,680 --> 01:18:56,680
You're just paying invisibly through waiting and rework and endless sinks.

1968
01:18:56,680 --> 01:18:59,760
Making it visible and investing in infrastructure is the honest choice.

1969
01:18:59,760 --> 01:19:01,160
Now look at the other side.

1970
01:19:01,160 --> 01:19:05,480
If your teams are independent, a multi-repo with explicit contracts makes sense.

1971
01:19:05,480 --> 01:19:07,920
This is for the teams where changes rarely cross boundaries.

1972
01:19:07,920 --> 01:19:12,000
It is for the services with clear ownership that move on different schedules.

1973
01:19:12,000 --> 01:19:14,160
In this model, you are respecting autonomy.

1974
01:19:14,160 --> 01:19:16,040
You are building clear themes between systems.

1975
01:19:16,040 --> 01:19:18,040
You are letting teams own their own destiny.

1976
01:19:18,040 --> 01:19:19,600
The investment here is different.

1977
01:19:19,600 --> 01:19:21,320
You need discipline around versioning.

1978
01:19:21,320 --> 01:19:24,360
You need API contracts that teams actually respect.

1979
01:19:24,360 --> 01:19:27,240
You need governance that prevents your systems from drifting apart.

1980
01:19:27,240 --> 01:19:31,240
You need mechanisms to keep teams aware of breaking changes and migration parts.

1981
01:19:31,240 --> 01:19:34,680
If your teams are truly independent, you are already paying for that independence.

1982
01:19:34,680 --> 01:19:37,960
Making it explicit and investing in governance is the honest choice.

1983
01:19:37,960 --> 01:19:40,080
But most organizations are in between.

1984
01:19:40,080 --> 01:19:41,960
If that is you, you need a hybrid.

1985
01:19:41,960 --> 01:19:44,240
Keep your core coupled services in a monorepo.

1986
01:19:44,240 --> 01:19:47,160
Keep your truly independent services in separate repositories.

1987
01:19:47,160 --> 01:19:50,560
Draw an explicit boundary to find which side of that boundary owns what.

1988
01:19:50,560 --> 01:19:54,040
Make it clear which model applies to which part of your system.

1989
01:19:54,040 --> 01:19:55,960
This isn't about splitting the difference.

1990
01:19:55,960 --> 01:19:59,080
It is about being honest about where coupling actually exists.

1991
01:19:59,080 --> 01:20:02,680
And choosing a model that fits the architecture once you have made that choice.

1992
01:20:02,680 --> 01:20:03,680
There is a second decision.

1993
01:20:03,680 --> 01:20:05,320
What are you willing to invest?

1994
01:20:05,320 --> 01:20:07,840
Because whatever you choose, it requires infrastructure.

1995
01:20:07,840 --> 01:20:09,040
It requires governance.

1996
01:20:09,040 --> 01:20:10,360
It requires discipline.

1997
01:20:10,360 --> 01:20:13,600
If you are not willing to pay that price, your choice does not matter.

1998
01:20:13,600 --> 01:20:16,360
You will end up with a monorepo that acts like a multi-repo.

1999
01:20:16,360 --> 01:20:19,000
You will end up with a multi-repo that lacks contracts.

2000
01:20:19,000 --> 01:20:21,480
You will end up with a hybrid that has ambiguous seams.

2001
01:20:21,480 --> 01:20:23,320
You will end up fragmented either way.

2002
01:20:23,320 --> 01:20:26,240
The organizations that succeed understand this trade off upfront.

2003
01:20:26,240 --> 01:20:27,240
They choose a model.

2004
01:20:27,240 --> 01:20:29,520
They commit to the investment and they follow through.

2005
01:20:29,520 --> 01:20:32,560
That investment might be built optimization and partial clones.

2006
01:20:32,560 --> 01:20:34,840
It might be versioning discipline and API contracts.

2007
01:20:34,840 --> 01:20:36,400
It might be hybrid governance.

2008
01:20:36,400 --> 01:20:37,720
But it is not optional.

2009
01:20:37,720 --> 01:20:40,320
The worst choice is the one that doesn't match your coupling.

2010
01:20:40,320 --> 01:20:42,320
Combined with the choice not to invest.

2011
01:20:42,320 --> 01:20:44,120
That is how you end up fragmented.

2012
01:20:44,120 --> 01:20:48,240
So here is what you do Monday, not Tuesday, not next quarter, Monday.

2013
01:20:48,240 --> 01:20:49,240
Map your coupling.

2014
01:20:49,240 --> 01:20:50,960
Be honest about how your teams actually work.

2015
01:20:50,960 --> 01:20:54,400
Do not try to engineer your way to independence if you are tightly coupled.

2016
01:20:54,400 --> 01:20:56,080
Do not expect natural alignment.

2017
01:20:56,080 --> 01:20:59,280
If you are operating as independent services, make a choice.

2018
01:20:59,280 --> 01:21:00,240
Monorepo.

2019
01:21:00,240 --> 01:21:01,080
Multi-repo.

2020
01:21:01,080 --> 01:21:01,920
Hybrid.

2021
01:21:01,920 --> 01:21:03,200
Choose the one that fits.

2022
01:21:03,200 --> 01:21:04,600
Document why you are choosing it.

2023
01:21:04,600 --> 01:21:06,960
Commit the resources if it is a monorepo.

2024
01:21:06,960 --> 01:21:08,280
Budget for the infrastructure.

2025
01:21:08,280 --> 01:21:09,520
If it is a multi-repo.

2026
01:21:09,520 --> 01:21:10,520
Budget for the governance.

2027
01:21:10,520 --> 01:21:11,520
If it is a hybrid.

2028
01:21:11,520 --> 01:21:12,920
Budget for both.

2029
01:21:12,920 --> 01:21:13,920
Make it visible.

2030
01:21:13,920 --> 01:21:16,200
Make it a line item in your engineering budget.

2031
01:21:16,200 --> 01:21:18,200
And then follow through.

2032
01:21:18,200 --> 01:21:19,760
Consistency matters more than perfection.

2033
01:21:19,760 --> 01:21:24,160
A suboptimal choice executed consistently beats a perfect choice executed halfway.

2034
01:21:24,160 --> 01:21:25,440
That is the decision framework.

2035
01:21:25,440 --> 01:21:26,680
It is simple on the surface.

2036
01:21:26,680 --> 01:21:30,720
It is difficult in practice because it requires honesty about where you are.

2037
01:21:30,720 --> 01:21:33,280
And it requires a commitment to the path forward.

2038
01:21:33,280 --> 01:21:34,280
But it works.

2039
01:21:34,280 --> 01:21:37,400
Your architecture isn't fragmented because of your repository strategy.

2040
01:21:37,400 --> 01:21:40,240
It is fragmented because of unresolved decisions.

2041
01:21:40,240 --> 01:21:43,480
Somewhere along the way, your organization accumulated debt.

2042
01:21:43,480 --> 01:21:46,480
Decisions about how teams should work together were never finished.

2043
01:21:46,480 --> 01:21:51,440
And those unresolved decisions are costing you every single day.

2044
01:21:51,440 --> 01:21:55,520
The monorepo myth is that the right repository structure will solve that problem for you.

2045
01:21:55,520 --> 01:21:56,520
It won't.

2046
01:21:56,520 --> 01:21:57,680
A monorepo won't fix fragmentation.

2047
01:21:57,680 --> 01:21:59,520
A multi-repo won't fix fragmentation.

2048
01:21:59,520 --> 01:22:01,040
No tool will fix fragmentation.

2049
01:22:01,040 --> 01:22:04,000
What a repository choice will do is make your fragmentation visible.

2050
01:22:04,000 --> 01:22:05,000
Or invisible.

2051
01:22:05,000 --> 01:22:06,000
Make it visible.

2052
01:22:06,000 --> 01:22:07,360
And you are forced to deal with it.

2053
01:22:07,360 --> 01:22:08,600
Make it invisible.

2054
01:22:08,600 --> 01:22:10,360
And you can pretend it is not there.

2055
01:22:10,360 --> 01:22:13,440
While you pretend, it slowly erodes your ability to move fast.

2056
01:22:13,440 --> 01:22:16,680
The organization's moving fastest are not the ones with monorepo's.

2057
01:22:16,680 --> 01:22:19,360
They are the ones that paid down their organizational debt.

2058
01:22:19,360 --> 01:22:21,280
They align their teams around clear patterns.

2059
01:22:21,280 --> 01:22:23,080
They chose a communication model.

2060
01:22:23,080 --> 01:22:24,560
And they invested in making it work.

2061
01:22:24,560 --> 01:22:26,520
Your choice isn't monorepo or multi-repo.

2062
01:22:26,520 --> 01:22:29,920
Your choice is whether you are going to face your fragmentation problem.

2063
01:22:29,920 --> 01:22:31,120
Or keep pretending it doesn't exist.