1
00:00:00,110 --> 00:00:01,640
Welcome to the Architecture 
Corner. 

2
00:00:01,650 --> 00:00:04,840
Today we're tackling something I
think a lot of you listening 

3
00:00:04,850 --> 00:00:07,460
probably deal with. 
It's this constant pressure, you

4
00:00:07,470 --> 00:00:13,040
know, the need to move fast, but
crucially without losing your 

5
00:00:13,050 --> 00:00:15,610
direction, your strategy. 
We've got some really 

6
00:00:15,620 --> 00:00:17,280
interesting sources to unpack on
this. 

7
00:00:17,350 --> 00:00:19,220
Yeah, it's that classic dilemma,
isn't it? 

8
00:00:19,410 --> 00:00:21,220
Sometimes called the Red Queens 
race. 

9
00:00:21,630 --> 00:00:24,460
You feel like you're running as 
fast as you can, adopting new 

10
00:00:24,470 --> 00:00:27,260
tech, migrating platforms. 
Just to keep up. 

11
00:00:27,330 --> 00:00:29,580
Exactly, just to stay in the 
same place. 

12
00:00:29,670 --> 00:00:33,340
And well, with the whole AI 
revolution happening, that 

13
00:00:33,350 --> 00:00:35,600
pressure to deliver faster is 
only ramping. 

14
00:00:35,610 --> 00:00:37,560
Up right. 
So the big question is, how do 

15
00:00:37,570 --> 00:00:40,020
you actually guarantee you're 
heading in the right direction, 

16
00:00:40,070 --> 00:00:43,050
not just running faster off a? 
Cliff, precisely how do you make

17
00:00:43,060 --> 00:00:45,060
sure speed doesn't just mean? 
Chaos. 

18
00:00:45,070 --> 00:00:47,180
OK, let's dig into that. 
Yeah, moving fast. 

19
00:00:47,190 --> 00:00:49,110
It sounds great. 
Obviously, everyone wants that. 

20
00:00:49,230 --> 00:00:53,140
But the sources we looked at 
highlight this sort of unspoken 

21
00:00:53,150 --> 00:00:54,420
problem. 
It's not just about speed 

22
00:00:54,430 --> 00:00:56,320
itself, is it? 
No, not at all. 

23
00:00:56,390 --> 00:00:58,730
It's often about the sprawl that
comes with it. 

24
00:00:58,790 --> 00:01:00,600
Unchecked sprawl. 
Sprawl. 

25
00:01:00,690 --> 00:01:02,610
Tell me more about that. 
Well, think about it. 

26
00:01:02,660 --> 00:01:05,190
Development teams grow, new 
people join. 

27
00:01:05,820 --> 00:01:09,850
Everyone wants to use the quote 
UN quote best tool for the job, 

28
00:01:09,860 --> 00:01:11,590
right? 
Which sounds reasonable on the 

29
00:01:11,600 --> 00:01:14,430
surface. 
It does, but suddenly maybe a 

30
00:01:14,440 --> 00:01:18,250
new developer introduces, say, 
MongoDB, because it's great for 

31
00:01:18,260 --> 00:01:21,610
their specific task, but you 
already use Postgres 

32
00:01:21,620 --> 00:01:24,230
extensively. 
OK, so now you've got. 

33
00:01:24,240 --> 00:01:26,290
Both exactly. 
Now you're supporting both 

34
00:01:26,300 --> 00:01:30,620
Postgres and Mongo DB, and while
being polyglot using different 

35
00:01:30,630 --> 00:01:32,930
tools, be powerful for most 
companies. 

36
00:01:32,940 --> 00:01:35,290
You know, companies not at 
Google or Facebook scale. 

37
00:01:35,300 --> 00:01:39,370
Yeah, it usually means a smaller
team is suddenly stretched thin,

38
00:01:39,500 --> 00:01:43,030
supporting way more technologies
than they may be planned for or 

39
00:01:43,040 --> 00:01:45,110
even realized. 
Without the resources or the 

40
00:01:45,120 --> 00:01:46,380
preparation it just kind. 
Of happened. 

41
00:01:46,390 --> 00:01:48,830
It just happened and you're left
asking, OK, how do we get a 

42
00:01:48,840 --> 00:01:52,270
handle on this, this tech jungle
before it gets totally out of 

43
00:01:52,280 --> 00:01:53,950
control? 
That really paints a picture. 

44
00:01:54,020 --> 00:01:56,340
A tech jungle, right? 
So here's where the sources get 

45
00:01:56,350 --> 00:01:59,170
really interesting. 
Suggesting a specific solution. 

46
00:01:59,520 --> 00:02:02,960
They point towards something 
called the technology radar as a

47
00:02:02,970 --> 00:02:04,860
way to guide things. 
Yes. 

48
00:02:05,170 --> 00:02:07,560
And what's really neat about it 
is it's, well, it's simplicity 

49
00:02:08,300 --> 00:02:11,570
fundamentally, but the impact 
can be huge. 

50
00:02:11,640 --> 00:02:14,280
It's basically a way to 
visualize and document the 

51
00:02:14,290 --> 00:02:17,150
technologies your company 
actually cares about, or maybe 

52
00:02:17,160 --> 00:02:18,210
doesn't care about it. 
Anymore. 

53
00:02:18,280 --> 00:02:21,450
OK, so it's like a map of your 
approved tech landscape? 

54
00:02:21,500 --> 00:02:23,840
Sort of, yeah. 
It helps teams make informed 

55
00:02:23,850 --> 00:02:26,470
choices because they know, OK, 
this tool has buy in. 

56
00:02:26,480 --> 00:02:29,510
It's supported here. 
And crucially, it's not just a 

57
00:02:29,520 --> 00:02:32,760
list of approved tech. 
It's also about what to avoid, 

58
00:02:33,450 --> 00:02:35,500
maybe consolidating languages 
for example. 

59
00:02:35,550 --> 00:02:39,520
Like saying we're focusing on Go
for new microservices, maybe not

60
00:02:39,530 --> 00:02:42,800
Python unless it's for say. 
Data science exactly like that, 

61
00:02:42,810 --> 00:02:46,200
and the radar should explain why
it provides that rationale, that

62
00:02:46,210 --> 00:02:47,900
shared understanding behind the 
choices. 

63
00:02:47,910 --> 00:02:50,440
So it's more than just rules, 
it's captured wisdom. 

64
00:02:50,490 --> 00:02:52,940
Even a new person could look at 
it and understand the thinking. 

65
00:02:53,010 --> 00:02:56,540
OK I'm sold on the idea, but how
do you actually build 1? 

66
00:02:56,590 --> 00:02:58,500
Sounds like it could be a big 
undertaking. 

67
00:02:58,510 --> 00:03:00,860
Do you start from scratch? 
Good question. 

68
00:03:01,130 --> 00:03:04,660
The source is actually recommend
not starting from a blank page. 

69
00:03:04,850 --> 00:03:07,840
Get inspired. 
They point specifically to the 

70
00:03:07,850 --> 00:03:10,900
technology radar that 
ThoughtWorks shares publicly. 

71
00:03:10,970 --> 00:03:13,080
It's a great starting point. 
Thought works OK. 

72
00:03:13,470 --> 00:03:15,560
What's their approach? 
It's pretty straightforward. 

73
00:03:15,610 --> 00:03:17,560
They acknowledge tech evolves, 
right? 

74
00:03:17,630 --> 00:03:20,200
So they group things into 
categories like techniques, 

75
00:03:20,210 --> 00:03:22,340
tools, platforms, languages and 
frameworks. 

76
00:03:22,510 --> 00:03:25,490
And within those they use four 
key classifications which are 

77
00:03:25,500 --> 00:03:27,820
really useful. 
Adopt stuff that's proven. 

78
00:03:27,870 --> 00:03:30,560
Definitely use it. 
Trial looks promising, ready for

79
00:03:30,570 --> 00:03:31,880
real projects, but keep an eye 
on it. 

80
00:03:32,470 --> 00:03:37,090
Then assess things to look into,
maybe for proof of concept, and 

81
00:03:37,420 --> 00:03:40,090
hold. 
Proceed with caution, maybe 

82
00:03:40,100 --> 00:03:42,270
stuff you're phasing out or 
decided against. 

83
00:03:42,320 --> 00:03:44,790
Adopt trial, assess, hold. 
Got it? 

84
00:03:44,840 --> 00:03:47,120
Simple but clear. 
Very clear and you don't have to

85
00:03:47,130 --> 00:03:50,210
copy their structure exactly, 
but those classifications highly

86
00:03:50,220 --> 00:03:52,030
recommended. 
You can start small, just 

87
00:03:52,040 --> 00:03:55,050
classify your main existing tech
and maybe update it quarterly or

88
00:03:55,060 --> 00:03:57,610
so. 
Right, Start small, iterate 

89
00:03:57,720 --> 00:04:01,460
makes sense. 
Now I can almost hear some 

90
00:04:01,470 --> 00:04:03,920
listeners thinking, hang on, 
doesn't this sound a bit 

91
00:04:04,290 --> 00:04:07,050
bureaucratic? 
Doesn't it stifle innovation if 

92
00:04:07,060 --> 00:04:09,940
we tell people what tools they 
can or can't assess? 

93
00:04:10,370 --> 00:04:13,360
That's a really common pushback 
and a fair question to ask. 

94
00:04:13,750 --> 00:04:15,370
The sources address this head 
on. 

95
00:04:16,180 --> 00:04:19,010
They argue it's not meant to be 
some top down mandate from an 

96
00:04:19,019 --> 00:04:20,430
ivory tower. 
It shouldn't be. 

97
00:04:20,440 --> 00:04:22,670
Anyway, no, it should involve 
developers. 

98
00:04:22,740 --> 00:04:25,550
Like do an audit of what you're 
actually using first, make it 

99
00:04:25,560 --> 00:04:28,270
collaborative. 
And it's definitely not static. 

100
00:04:28,280 --> 00:04:31,810
It has to be revisited, updated 
with feedback, new ideas 

101
00:04:31,820 --> 00:04:35,760
considered for assess or trial. 
So it's a living document shaped

102
00:04:35,770 --> 00:04:38,570
by the teams using. 
It exactly, and while the value 

103
00:04:38,580 --> 00:04:41,490
might not seem obvious every 
single day, think of it as a 

104
00:04:41,500 --> 00:04:42,810
first filter. 
If someone wants to use 

105
00:04:42,820 --> 00:04:46,380
something in the adopt ring. 
Great green light go build, less

106
00:04:46,390 --> 00:04:49,090
time having, more time doing. 
Ah, so it can actually 

107
00:04:49,100 --> 00:04:52,120
accelerate things by removing 
some friction. 

108
00:04:52,190 --> 00:04:54,370
That's the argument. 
It accelerates informed 

109
00:04:54,380 --> 00:04:57,110
innovation and thinking bigger 
picture, especially for 

110
00:04:57,120 --> 00:04:58,420
companies that are growing or 
scaling. 

111
00:04:58,430 --> 00:05:01,090
Yeah, it's crucial for 
preventing that divergent 

112
00:05:01,440 --> 00:05:05,290
avoiding what one source called 
a technology Tower of Babel, 

113
00:05:05,560 --> 00:05:07,910
where different teams are 
speaking different languages, 

114
00:05:07,920 --> 00:05:10,530
can't share work easily. 
It leads to massive 

115
00:05:10,540 --> 00:05:12,490
inefficiency. 
A tower of Babel? 

116
00:05:12,540 --> 00:05:15,110
I like that analogy. 
OK, so wrapping this up then. 

117
00:05:15,120 --> 00:05:16,940
What's the key take away for our
listeners? 

118
00:05:17,010 --> 00:05:20,250
What does building a tech radar 
actually mean for you day-to-day

119
00:05:20,260 --> 00:05:23,050
or strategically? 
I think it means gaining really 

120
00:05:23,060 --> 00:05:26,070
valuable insights into your own 
tech ecosystem. 

121
00:05:26,220 --> 00:05:28,750
Just the process of building it 
can be revealing. 

122
00:05:28,800 --> 00:05:31,990
It helps democratize that 
knowledge we talked about guides

123
00:05:32,000 --> 00:05:34,910
future choices, and ultimately 
Foster is a more unified, 

124
00:05:34,920 --> 00:05:37,910
efficient way to innovate. 
So it's about being proactive 

125
00:05:37,960 --> 00:05:40,310
with direction, not just 
reactive with speed. 

126
00:05:40,360 --> 00:05:43,670
Couldn't said it better myself. 
It's about proactive direction. 

127
00:05:43,720 --> 00:05:46,590
Give it a try. 
Honestly, even just sketching 

128
00:05:46,600 --> 00:05:48,940
one out using the thought radar 
is a template. 

129
00:05:49,010 --> 00:05:52,210
You benefit from their thinking 
and you start getting clarity on

130
00:05:52,220 --> 00:05:56,460
your specific tech landscape. 
What to adopt, trial, assess, or

131
00:05:56,470 --> 00:05:59,440
hold? 
It's a powerful concept, and 

132
00:05:59,450 --> 00:06:01,820
Mario Bittencourt articulated 
the need for this kind of 

133
00:06:01,830 --> 00:06:03,680
thinking really well in the 
source material. 

134
00:06:03,810 --> 00:06:06,720
It's fundamentally about 
enabling smart, sustainable 

135
00:06:06,730 --> 00:06:09,280
growth. 
Smart, sustainable growth. 

136
00:06:09,290 --> 00:06:11,940
Love it. 
Absolutely fantastic insights. 

137
00:06:12,150 --> 00:06:14,480
For more details on everything 
we've discussed in this deep 

138
00:06:14,490 --> 00:06:16,520
dive, definitely check out the 
description. 

139
00:06:16,620 --> 00:06:19,660
And remember, you can subscribe 
for free to the Architecture 

140
00:06:19,670 --> 00:06:22,580
Corner newsletter over at 
architecturecorner.substack.com 

141
00:06:22,690 --> 00:06:25,420
to get more essential insights 
like these sent straight to your

142
00:06:25,430 --> 00:06:27,790
inbox. 
Until next time, keep building 

143
00:06:27,870 --> 00:06:28,310
smartly.