1
00:00:00,040 --> 00:00:05,160
Now more than ever, engineering 
leaders are being asked to be 

2
00:00:05,160 --> 00:00:08,680
more transparent with how work 
is getting done. 

3
00:00:09,080 --> 00:00:12,040
Every single thing that an 
engineering team works on needs 

4
00:00:12,040 --> 00:00:15,120
to benefit the business. 
And your job as an engineering 

5
00:00:15,120 --> 00:00:18,160
leader is not to say, well, just
trust us, we're in the code all 

6
00:00:18,160 --> 00:00:20,640
day. 
Developer experience and 

7
00:00:20,640 --> 00:00:25,080
developer productivity exists in
this very strange area where 

8
00:00:25,080 --> 00:00:27,920
what is good for your engineers 
and what is good for your 

9
00:00:27,920 --> 00:00:31,440
business are the same thing. 
Because the bottom line is that 

10
00:00:31,480 --> 00:00:34,720
poor developer experience just 
cripples innovation. 

11
00:00:35,040 --> 00:00:38,200
We've really nailed it down to 
speed, effectiveness, quality, 

12
00:00:38,200 --> 00:00:41,640
and business impact as the four 
pillars to kind of put a story 

13
00:00:41,640 --> 00:00:44,360
together about developer 
productivity and developer 

14
00:00:44,360 --> 00:00:46,560
effectiveness. 
So there's not going to be a 

15
00:00:46,560 --> 00:00:50,000
single metric. 
So for speed, that is diffs per 

16
00:00:50,000 --> 00:00:52,440
engineer. 
These are like PRS or merge 

17
00:00:52,440 --> 00:00:53,880
requests or whatever it's 
called. 

18
00:00:54,280 --> 00:00:56,960
That's the first one I always 
talk about because it is the 

19
00:00:56,960 --> 00:00:59,520
most controversial. 
I think even a few years ago I 

20
00:00:59,520 --> 00:01:01,800
would have said like, that's a 
bad idea, don't do it. 

21
00:01:01,920 --> 00:01:04,959
It's not about ping pong and 
beer, which is often. 

22
00:01:04,959 --> 00:01:08,440
I think developer experience has
a like quite a marketing 

23
00:01:08,440 --> 00:01:11,080
problem. 
Abby has this thing that just 

24
00:01:11,080 --> 00:01:13,160
like makes me laugh every time. 
He's like, Can you imagine if a 

25
00:01:13,160 --> 00:01:15,960
new sales leader, like a new CRO
comes in and says, well, we're 

26
00:01:15,960 --> 00:01:19,280
going to measure the impact of 
our sales organization based on 

27
00:01:19,720 --> 00:01:23,520
sales Rep experience? 
Like, there's just no way that 

28
00:01:23,520 --> 00:01:39,040
that would ever go over. 
Hello, welcome back to another 

29
00:01:39,040 --> 00:01:41,200
new episode of the Technical 
Journal podcast today. 

30
00:01:41,200 --> 00:01:44,320
I'm very happy to have another 
DX person in my show. 

31
00:01:44,560 --> 00:01:46,360
Laura Taco is here with me 
today. 

32
00:01:46,560 --> 00:01:50,520
So she's the CTO of Get the X or
the x.com, right? 

33
00:01:50,520 --> 00:01:54,440
So if people who are following 
into these developer experience,

34
00:01:54,440 --> 00:01:57,960
developer productivity, you 
might have heard of or seen the 

35
00:01:57,960 --> 00:02:01,080
X materials out there be 
research paper or their own 

36
00:02:01,080 --> 00:02:03,840
products, right? 
So happy to have you again in 

37
00:02:03,840 --> 00:02:07,120
the show to talk about developer
experience and all the stuff 

38
00:02:07,160 --> 00:02:10,280
that you published recently. 
So welcome to the show, Laura. 

39
00:02:11,080 --> 00:02:12,000
Yeah. 
Thanks so much. 

40
00:02:12,000 --> 00:02:14,640
Nice to be here. 
Right, Laura, I always love to 

41
00:02:14,640 --> 00:02:17,920
invite my guest first to maybe 
share anything from your career,

42
00:02:18,040 --> 00:02:20,520
any turning points that you 
think we all can learn from 

43
00:02:20,520 --> 00:02:23,640
that? 
Yeah, what a big question to 

44
00:02:23,640 --> 00:02:24,760
start with. 
A good one. 

45
00:02:25,280 --> 00:02:28,320
I think there's really 2. 
I mean, there's lots of points 

46
00:02:28,320 --> 00:02:31,040
that have defined my career, but
the two that stick out may be 

47
00:02:31,040 --> 00:02:36,760
interesting to your audience. 1 
was Docker and getting in 

48
00:02:38,080 --> 00:02:43,480
extremely early on a new thing. 
I think as technologists, it's 

49
00:02:43,520 --> 00:02:46,320
really hard to know like what's 
just a new shiny thing that 

50
00:02:46,320 --> 00:02:48,320
might be a little bit of a 
distraction and like what's a 

51
00:02:48,320 --> 00:02:50,880
new thing that's like 
fundamentally going to change 

52
00:02:50,880 --> 00:02:53,560
the way that we build, ship and 
run software. 

53
00:02:53,840 --> 00:02:57,240
Even thinking back to like back 
in 2013, I'm not sure that I 

54
00:02:57,240 --> 00:03:00,680
fully understood just how big of
a difference Docker would make. 

55
00:03:00,680 --> 00:03:04,840
But to me, it just felt 
different than like a new 

56
00:03:04,840 --> 00:03:06,360
JavaScript framework, for 
example. 

57
00:03:06,360 --> 00:03:08,920
Not to put down new JavaScript 
frameworks, but you know, it. 

58
00:03:08,920 --> 00:03:12,840
Just like my intuition, which I 
think a lot of leaders, we are 

59
00:03:12,840 --> 00:03:15,160
taught not to follow our 
intuition because we shouldn't 

60
00:03:15,160 --> 00:03:17,760
act on emotion, we should act on
logic. 

61
00:03:17,760 --> 00:03:21,360
But truly what your intuition 
is, is just hundreds of 

62
00:03:21,360 --> 00:03:24,280
thousands of data points that 
you've accumulated over your 

63
00:03:24,280 --> 00:03:27,960
career that allow you to make a 
judgement about something. 

64
00:03:27,960 --> 00:03:31,240
So it is, it's not just fully 
emotion, but working on 

65
00:03:31,240 --> 00:03:35,240
developer tools for Docker from 
very, very early on, getting 

66
00:03:35,240 --> 00:03:39,120
started with it before it was 
really heard of anywhere was 

67
00:03:39,280 --> 00:03:41,000
hugely transformative to my 
career. 

68
00:03:41,000 --> 00:03:45,720
So I guess one lesson, intuition
isn't just emotion, it is data 

69
00:03:45,720 --> 00:03:47,640
points. 
So sometimes you have an 

70
00:03:47,680 --> 00:03:49,600
intuitive feeling about 
something and you should follow 

71
00:03:49,600 --> 00:03:51,080
it. 
It might pay off in a big way. 

72
00:03:51,640 --> 00:03:54,440
The second big turning point was
like I left my corporate job, 

73
00:03:54,440 --> 00:03:58,040
AVP job that was like had a lot 
of responsibility to start my 

74
00:03:58,040 --> 00:04:00,880
own business and go into 
coaching and consulting full 

75
00:04:00,880 --> 00:04:05,480
time during the pandemic. 
Like on paper didn't look great.

76
00:04:05,600 --> 00:04:08,480
At the time, I was working with 
my own executive coach and I 

77
00:04:08,480 --> 00:04:12,840
really realized how much of my 
career I had let someone else's 

78
00:04:12,840 --> 00:04:15,000
career framework decide. 
And that was really the first 

79
00:04:15,000 --> 00:04:17,959
time that I said no, if I want 
something different, you know, I

80
00:04:17,959 --> 00:04:20,279
want more flexibility. 
I want to be able to go climbing

81
00:04:20,440 --> 00:04:23,640
at 11:00 AM or whatever it is. 
I need to fundamentally do 

82
00:04:23,640 --> 00:04:27,160
something different with my job.
And so I took a very big leap to

83
00:04:27,160 --> 00:04:32,760
do that and it paid off with a 
ton of hard work, a lot of 

84
00:04:32,760 --> 00:04:35,800
opportunity and hard work went 
into creating my own luck to 

85
00:04:35,800 --> 00:04:38,880
make that successful. 
I still do coaching on kind of 

86
00:04:38,880 --> 00:04:41,160
on the side. 
Now I'm back sort of in full, 

87
00:04:41,240 --> 00:04:46,200
you know, full product building 
mode with DX. 

88
00:04:46,520 --> 00:04:50,160
But I think the short lesson 
there is like, don't let someone

89
00:04:50,160 --> 00:04:53,800
else's career ladder define how 
you're gonna, you know, your 

90
00:04:53,800 --> 00:04:55,560
trajectory and your own career 
growth. 

91
00:04:55,560 --> 00:04:58,720
You need to at some point take 
responsibility for it and be in 

92
00:04:58,720 --> 00:05:01,440
the driver's seat. 
And it's surprising how long we 

93
00:05:01,440 --> 00:05:03,800
all go in our careers without 
actually being in the driver's 

94
00:05:03,800 --> 00:05:05,800
seat. 
Well, thank you so much for 

95
00:05:05,800 --> 00:05:07,960
sharing the story. 
I think those are really great 

96
00:05:08,160 --> 00:05:10,200
insights, right? 
So the first thing is about the 

97
00:05:10,240 --> 00:05:12,880
Docker containerization 
technology, right? 

98
00:05:13,120 --> 00:05:16,160
So I think these days almost 
everything is run based on 

99
00:05:16,160 --> 00:05:17,240
container. 
All right? 

100
00:05:17,480 --> 00:05:19,480
So be it, you know, the CICD and
all that. 

101
00:05:19,480 --> 00:05:22,520
So I think that kind of like 
revolutionize the whole thing, 

102
00:05:22,560 --> 00:05:25,000
how we get things done. 
And the second thing about, you 

103
00:05:25,000 --> 00:05:27,000
know, defining your own career 
path, I guess. 

104
00:05:27,240 --> 00:05:28,720
So thanks for sharing that as 
well. 

105
00:05:28,720 --> 00:05:31,840
So maybe some people also are 
looking into, you know, more 

106
00:05:31,840 --> 00:05:34,440
meaningful career, right? 
So don't follow other people's 

107
00:05:34,440 --> 00:05:36,280
paths or maybe define on your 
own. 

108
00:05:36,800 --> 00:05:39,760
So maybe you mentioned something
about intuition, right? 

109
00:05:39,760 --> 00:05:42,800
So the engineering leaders have 
to kind of like listen to your 

110
00:05:42,800 --> 00:05:46,160
intuition, you know, gather from
past data points probably that 

111
00:05:46,160 --> 00:05:48,400
you have gathered in your 
experience or maybe whatever 

112
00:05:48,760 --> 00:05:50,120
learning things that you have 
done. 

113
00:05:50,480 --> 00:05:54,960
So what can you advise us to 
actually do more in terms of, 

114
00:05:54,960 --> 00:05:56,960
you know, following our 
intuitions? 

115
00:05:56,960 --> 00:05:59,640
Because sometimes, you know, 
technology change so fast, there

116
00:05:59,640 --> 00:06:02,440
are so many things out there, 
but your intuition is not 

117
00:06:02,440 --> 00:06:05,360
something that we always, you 
know, try to sharpen, right? 

118
00:06:05,360 --> 00:06:08,080
So maybe anything any tips from 
you about this? 

119
00:06:09,120 --> 00:06:11,480
Yeah. 
You know, this is an exercise 

120
00:06:11,480 --> 00:06:15,280
and two things can be true 
because on one hand I say, you 

121
00:06:15,280 --> 00:06:16,560
know, you should trust your 
intuition. 

122
00:06:16,560 --> 00:06:19,640
Your intuition is data that 
you've accumulated throughout 

123
00:06:19,640 --> 00:06:21,640
the course of your career that 
allow you to make a snap 

124
00:06:21,640 --> 00:06:23,920
judgement about something or 
have, you know, a gut feel. 

125
00:06:23,920 --> 00:06:27,640
It's not just purely emotional. 
On the other side, I'm like a 

126
00:06:28,120 --> 00:06:32,560
extremely data informed decision
maker, but I think you know, if 

127
00:06:32,560 --> 00:06:35,320
you get your intuition and 
actually I think practicing 

128
00:06:35,320 --> 00:06:38,640
making data informed decisions 
helps you refine your intuition 

129
00:06:38,640 --> 00:06:41,640
skills. 
So changing your mind when new 

130
00:06:41,640 --> 00:06:45,440
data is available to you, being 
able to broadly look at lots of 

131
00:06:45,440 --> 00:06:48,880
data sets and draw a conclusion 
from them, but not just draw the

132
00:06:48,880 --> 00:06:51,640
conclusion, but then know what 
data you're going to look for to

133
00:06:51,640 --> 00:06:54,000
know that you're wrong or what 
data you're going to look for to

134
00:06:54,000 --> 00:06:56,160
know that you're right. 
I think those are all skills to 

135
00:06:56,160 --> 00:06:58,960
kind of practice that will help 
you feel more comfortable about 

136
00:06:58,960 --> 00:07:01,320
intuition. 
I think the other part of it is 

137
00:07:01,320 --> 00:07:04,880
like, just like in a recipe, 
time is important. 

138
00:07:05,200 --> 00:07:08,360
Like you can't just throw the 
ingredients in a pan and like, 

139
00:07:08,760 --> 00:07:12,480
wait a minute. 
And they're like, there's a time

140
00:07:12,480 --> 00:07:14,320
element of that. 
And I think careers are the same

141
00:07:14,320 --> 00:07:16,440
thing. 
You have to just get the cycles 

142
00:07:16,440 --> 00:07:20,480
and get the reps in and let you 
know experience will teach you a

143
00:07:20,480 --> 00:07:23,760
lot. 
So time is a factor in career 

144
00:07:23,760 --> 00:07:25,800
growth. 
And I think, you know, over 

145
00:07:25,960 --> 00:07:29,920
time, your intuition gets more 
honed and more honed. 

146
00:07:29,920 --> 00:07:34,160
So look out for opportunities 
where your intuition might be 

147
00:07:34,160 --> 00:07:36,120
telling you something to figure 
out. 

148
00:07:36,120 --> 00:07:39,160
Is there a way that I can use 
data to see if I'm right or 

149
00:07:39,160 --> 00:07:40,960
wrong? 
What data would I look for to do

150
00:07:40,960 --> 00:07:42,440
that? 
And then when you can get some 

151
00:07:42,440 --> 00:07:45,440
more practice in that, it will 
just become more natural to you.

152
00:07:46,400 --> 00:07:47,960
Yeah, I like that. 
You mentioned time, right? 

153
00:07:47,960 --> 00:07:50,200
So I think one thing that I 
would add also like your past 

154
00:07:50,200 --> 00:07:52,240
mistakes, right? 
Sometimes in our career cannot 

155
00:07:52,320 --> 00:07:54,520
always go up, right? 
So there'll be ups and downs, 

156
00:07:54,520 --> 00:07:57,680
maybe situational, you know, 
change of culture, leadership in

157
00:07:57,680 --> 00:08:00,400
the company, or maybe you made 
the wrong decision to take some 

158
00:08:00,680 --> 00:08:02,720
career path. 
But nevertheless, those things 

159
00:08:02,720 --> 00:08:05,880
are like data points that you 
can use to, you know, hone your 

160
00:08:05,880 --> 00:08:09,040
intuition. 
So maybe let's go into our main 

161
00:08:09,040 --> 00:08:11,880
topics of discussion today. 
So the first thing that I'd like

162
00:08:11,880 --> 00:08:15,080
to discuss is something that you
actually highlighted before we 

163
00:08:15,280 --> 00:08:17,760
had this conversation, right? 
You mentioned one thing that 

164
00:08:17,760 --> 00:08:20,680
piqued your interest lately. 
It's about engineering leaders 

165
00:08:21,000 --> 00:08:24,560
not necessarily being able to 
become part of the so-called 

166
00:08:24,560 --> 00:08:27,320
business leaders, right? 
So almost in any company, 

167
00:08:27,320 --> 00:08:29,440
technology is kind of like 
enablers, right? 

168
00:08:30,120 --> 00:08:32,799
Even though if if it's like 
technology companies, right, 

169
00:08:32,799 --> 00:08:35,159
it's like one of the key pillars
of the business. 

170
00:08:35,480 --> 00:08:37,760
But many engineering leaders 
after you mentioned that, yeah, 

171
00:08:37,760 --> 00:08:40,480
I kind of like make some kind of
like reflection. 

172
00:08:40,480 --> 00:08:43,360
I think many engineering leaders
are not able to kind of like 

173
00:08:43,360 --> 00:08:47,200
switch their technology mindset 
into more business oriented. 

174
00:08:47,360 --> 00:08:50,920
So maybe tell us a little bit 
more like what made you come up 

175
00:08:50,920 --> 00:08:54,280
with this kind of, you know, 
thoughts and what do you see 

176
00:08:54,280 --> 00:08:59,000
from your side there? 
Yeah, I think right now we're 

177
00:08:59,000 --> 00:09:01,120
in, I mean, there's lots of 
things going on 

178
00:09:01,120 --> 00:09:04,280
macroeconomically, right? 
We've got like the end of the 

179
00:09:04,280 --> 00:09:07,760
zero interest rate period. 
We had this like big hiring boom

180
00:09:07,760 --> 00:09:10,640
and then a bust and like maybe 
hiring starting to come back. 

181
00:09:11,000 --> 00:09:14,680
I think now more than ever, 
engineering leaders are being 

182
00:09:14,680 --> 00:09:20,240
asked to be more transparent 
with how work is getting done, 

183
00:09:20,760 --> 00:09:24,160
how much it's costing. 
There's just like lots of things

184
00:09:24,160 --> 00:09:28,760
that before engineering was 
really kind of a black box. 

185
00:09:28,760 --> 00:09:30,240
Like we got away with a lot of 
stuff. 

186
00:09:30,240 --> 00:09:34,120
Let's be honest, you know, I 
think back to the, you know, 

187
00:09:34,120 --> 00:09:35,840
like, let's bring this back to 
Docker. 

188
00:09:35,840 --> 00:09:38,800
But you know, I remember the, I 
mean, the heyday, like the 

189
00:09:38,800 --> 00:09:42,520
height of the Docker craze, when
it was just like you, if you 

190
00:09:42,520 --> 00:09:45,960
knew Docker or knew Kubernetes, 
like you could just hear pretty 

191
00:09:45,960 --> 00:09:49,360
much, you know, no one got fired
for learning Kubernetes, right? 

192
00:09:49,400 --> 00:09:52,080
You know, that's the saying you 
could demand a higher salary, 

193
00:09:52,080 --> 00:09:55,800
you could do a lot because 
companies were afraid of losing 

194
00:09:55,800 --> 00:09:58,440
your talent and having that 
business knowledge walk out the 

195
00:09:58,440 --> 00:10:01,040
door. 
And because of that, it, there 

196
00:10:01,040 --> 00:10:03,680
was just, I think a lot of, I 
don't want to say that, you 

197
00:10:03,680 --> 00:10:06,680
know, there was dancing around 
engineering, but maybe it, you 

198
00:10:06,680 --> 00:10:11,280
know, we just weren't expected 
to show the bottom line for 

199
00:10:11,280 --> 00:10:13,520
stuff that's happening in 
engineering org the same way 

200
00:10:13,520 --> 00:10:16,800
that marketing, sales, other 
functions would be expected to. 

201
00:10:16,800 --> 00:10:19,880
I think that's really changed. 
You know, I spent all my time in

202
00:10:19,880 --> 00:10:22,800
developer productivity and 
engineering metrics. 

203
00:10:22,800 --> 00:10:24,240
And so I know that that's the 
case. 

204
00:10:24,240 --> 00:10:26,800
I know that engineers are being 
asked for metrics in a way that 

205
00:10:26,800 --> 00:10:29,640
they just have not been asked to
before and they're not prepared 

206
00:10:30,040 --> 00:10:34,400
to be able to tell that story 
with numbers because now we have

207
00:10:34,400 --> 00:10:35,960
to answer those questions. 
I think there's just a 

208
00:10:35,960 --> 00:10:38,040
heightened sense of 
accountability from engineering.

209
00:10:38,040 --> 00:10:41,680
We're no longer the as charity 
Majors puts at the artists and 

210
00:10:41,680 --> 00:10:45,840
the organization that we can 
kind of not work without 

211
00:10:45,840 --> 00:10:47,760
accountability. 
But there's just there's more 

212
00:10:47,760 --> 00:10:49,320
questions that need to be 
answered now. 

213
00:10:49,800 --> 00:10:52,880
And I think because it hasn't 
been expected of us, a lot of 

214
00:10:52,880 --> 00:10:56,000
engineering leaders just haven't
had to develop that skill even 

215
00:10:56,000 --> 00:10:58,280
on the broad level. 
But just think about an 

216
00:10:58,280 --> 00:11:01,720
interaction of engineering wants
to do this tech tech project 

217
00:11:01,960 --> 00:11:04,280
product manager says we need to 
build this new feature. 

218
00:11:04,640 --> 00:11:07,480
And the conversation in a lot of
companies is like, well, 

219
00:11:07,480 --> 00:11:10,240
engineering says that we need to
do tech, that we're going to do 

220
00:11:10,240 --> 00:11:12,760
that before we do the feature. 
I mean, a lot of companies it's 

221
00:11:12,760 --> 00:11:15,280
the other way around. 
But there was never this like, 

222
00:11:15,760 --> 00:11:18,320
let's actually build out a 
business case and see what 

223
00:11:18,320 --> 00:11:21,160
customer impact this tech tech 
project is going to have. 

224
00:11:21,880 --> 00:11:24,520
That is something that 
engineering leaders need to do 

225
00:11:24,520 --> 00:11:27,240
now in a lot of companies in a 
lot of circumstances that we 

226
00:11:27,240 --> 00:11:30,560
just haven't had to do before. 
And it's a really missing skill 

227
00:11:30,560 --> 00:11:32,840
set. 
Yeah, you mentioned something 

228
00:11:32,840 --> 00:11:35,320
about, you know, the situation 
about the economic, right. 

229
00:11:35,320 --> 00:11:38,320
So the end of 0 interest rates, 
I think in the past, I don't 

230
00:11:38,320 --> 00:11:40,560
know how many years. 
You know, they are a lot of tech

231
00:11:40,560 --> 00:11:42,960
startup booms, right? 
So many engineers being hired 

232
00:11:43,240 --> 00:11:46,040
and you know, the engineering 
teams are keep growing, growing 

233
00:11:46,040 --> 00:11:48,120
and growing. 
Right now, I think it's like a 

234
00:11:48,920 --> 00:11:50,880
questionable kind of a decision,
right? 

235
00:11:50,880 --> 00:11:52,880
If you still want to hire more 
engineers, right? 

236
00:11:52,880 --> 00:11:54,840
And that's why engineering 
leaders are being asked to 

237
00:11:54,840 --> 00:11:56,360
actually kind of like be 
accountable. 

238
00:11:56,360 --> 00:11:59,200
You mentioned, right? 
So how you optimize your kind of

239
00:11:59,200 --> 00:12:01,720
like resource versus the impact 
that you bring. 

240
00:12:02,040 --> 00:12:03,960
So you mentioned about tech 
debt, right? 

241
00:12:03,960 --> 00:12:07,600
So it's always very interesting,
right, whenever engineers talk 

242
00:12:07,600 --> 00:12:09,600
about tech debt, right? 
Because obviously the first 

243
00:12:09,600 --> 00:12:11,600
question is like how to quantify
that. 

244
00:12:11,960 --> 00:12:14,360
And I think you also mentioned 
things like, for example, 

245
00:12:14,440 --> 00:12:16,840
engineering leaders are not able
to explain things in the 

246
00:12:16,840 --> 00:12:19,840
business sense of business 
metrics, be it, you know, for 

247
00:12:19,840 --> 00:12:23,040
example, number of users, number
of growth, right, number of 

248
00:12:23,240 --> 00:12:26,040
revenue, dollar that is being 
brought into the company. 

249
00:12:26,320 --> 00:12:30,000
So how do you actually will 
advise leaders to actually think

250
00:12:30,000 --> 00:12:34,360
about, you know, switching their
mindset, but you know, from tech

251
00:12:34,360 --> 00:12:36,680
debt, which is probably more 
like, I don't know, like 

252
00:12:36,680 --> 00:12:40,160
complexity or, you know, 
maintainability and all that 

253
00:12:40,160 --> 00:12:41,960
into something that is more 
quantifiable. 

254
00:12:43,320 --> 00:12:46,440
Yeah, I think there's kind of 
two, maybe there's like two ways

255
00:12:46,440 --> 00:12:49,120
to answer that. 
I think for the broadly, I want 

256
00:12:49,120 --> 00:12:52,880
to say just as a a general 
statement that I'm not saying 

257
00:12:52,880 --> 00:12:56,120
that individual engineers should
be thinking about how much 

258
00:12:56,120 --> 00:12:58,520
revenue that their features are 
going to bring in, right. 

259
00:12:58,520 --> 00:13:00,920
That's not appropriate. 
What I am talking about though, 

260
00:13:00,920 --> 00:13:04,840
is engineering leaders who have 
a product manager counterpart or

261
00:13:04,840 --> 00:13:08,240
like a business stakeholder 
being able to come with the same

262
00:13:08,240 --> 00:13:10,680
information that you would 
expect that business stakeholder

263
00:13:10,680 --> 00:13:13,680
to bring about a new feature, 
come to that conversation with 

264
00:13:13,680 --> 00:13:16,320
that same information about a 
tech debt project. 

265
00:13:16,760 --> 00:13:20,240
So I think a, a way to get 
practice here is like, let's 

266
00:13:20,240 --> 00:13:23,960
just take tech debt for example,
which is a term that I actually 

267
00:13:23,960 --> 00:13:26,160
really don't like because I 
think it's too broad. 

268
00:13:26,160 --> 00:13:29,840
It's not very descriptive but if
we could pick AI, don't know. 

269
00:13:29,840 --> 00:13:32,760
Why don't you pick a 
hypothetical tech debt project? 

270
00:13:32,760 --> 00:13:35,640
Can you think of 1? 
The typical one these days, 

271
00:13:35,640 --> 00:13:38,000
especially if you're in the big 
setup monolith versus 

272
00:13:38,000 --> 00:13:39,640
microservice kind of thing, you 
know? 

273
00:13:40,040 --> 00:13:41,840
OK, great. 
One monolith versus 

274
00:13:41,840 --> 00:13:43,320
microservice. 
Like let's break up this 

275
00:13:43,320 --> 00:13:46,680
monolith into microservices. 
Or sometimes what I'm saying now

276
00:13:46,680 --> 00:13:49,160
is like let's combine these 
microservices into a monolith 

277
00:13:49,160 --> 00:13:51,960
again, because it's just, it's 
just too complex. 

278
00:13:53,320 --> 00:13:56,920
But let's think about that like 
what's the actual benefit of 

279
00:13:56,920 --> 00:13:59,800
doing that? 
So let's just say it's lower 

280
00:13:59,800 --> 00:14:01,960
complexity. 
Whichever way you're going, if 

281
00:14:01,960 --> 00:14:04,400
you're breaking up the monolith 
or putting things back into a 

282
00:14:04,400 --> 00:14:08,840
monolith, it's lower complexity.
So what would we expect from an 

283
00:14:08,840 --> 00:14:11,280
environment where developers 
have lower complexity code? 

284
00:14:11,280 --> 00:14:15,440
We would expect that features 
can be delivered faster and so 

285
00:14:15,440 --> 00:14:17,880
we can pick some measurements to
measure that. 

286
00:14:17,880 --> 00:14:22,800
We we might expect fewer bugs 
and higher stability because 

287
00:14:22,800 --> 00:14:26,120
it's less complex. 
We might expect build times to 

288
00:14:26,120 --> 00:14:27,880
go down because it's less 
complex. 

289
00:14:28,040 --> 00:14:30,760
We could probably find four or 
five more examples. 

290
00:14:30,760 --> 00:14:33,200
I think for each of those 
examples then we can actually 

291
00:14:33,200 --> 00:14:37,520
tie that to customer impact. 
So how much does it cost to have

292
00:14:37,520 --> 00:14:39,880
an outage? 
We can look at contracts. 

293
00:14:39,880 --> 00:14:43,760
If you have an SLA of whatever, 
however many nines you need, 

294
00:14:44,080 --> 00:14:48,080
usually if your service goes 
below that, you need to pay back

295
00:14:48,080 --> 00:14:51,160
some of your subscription fee. 
Or maybe there's customer churn.

296
00:14:51,160 --> 00:14:53,320
You know, there's lots of 
different places that you could 

297
00:14:53,320 --> 00:14:55,200
look for. 
What's the actual impact of 

298
00:14:55,680 --> 00:14:57,480
incidents and stability 
problems? 

299
00:14:57,960 --> 00:15:00,440
I think the other thing here is 
opportunity cost. 

300
00:15:00,920 --> 00:15:05,360
It's a little bit more difficult
to calculate, but let's say, OK,

301
00:15:05,360 --> 00:15:11,240
so every project that used to 
take two weeks now takes only 1 

302
00:15:11,240 --> 00:15:13,800
1/2 weeks. 
So we're able to accelerate our 

303
00:15:13,800 --> 00:15:17,600
delivery by half a week for 
every project. 

304
00:15:17,920 --> 00:15:20,800
Like over time, that's a lot of 
time saved. 

305
00:15:20,800 --> 00:15:23,200
And of course, we can do the 
back of the napkin calculation 

306
00:15:23,200 --> 00:15:27,120
on like salary, you know, just 
like pure monetary, like how 

307
00:15:27,120 --> 00:15:30,640
much salary money did we save? 
But let's actually talk about 

308
00:15:30,640 --> 00:15:34,440
what you could have built 
instead in that time and what's 

309
00:15:34,440 --> 00:15:38,840
the potential economic impact of
the stuff that you would build 

310
00:15:38,840 --> 00:15:41,680
instead. 
And so now it becomes a question

311
00:15:41,680 --> 00:15:44,560
of like, well, if we wait, we 
could do this now. 

312
00:15:44,840 --> 00:15:48,680
And that means that features AB 
and C will be delivered more 

313
00:15:48,680 --> 00:15:52,240
quickly, but minus the cost of 
being able to or the, the 

314
00:15:52,240 --> 00:15:55,320
technical debt project, actually
the monolith micro service 

315
00:15:55,320 --> 00:15:59,320
project, or we could delay it 
and do it in 1/4 from now, which

316
00:15:59,320 --> 00:16:03,160
means we know we're OK with 
paying that tax basically. 

317
00:16:03,160 --> 00:16:04,640
I mean, we're talking about debt
here. 

318
00:16:05,200 --> 00:16:09,440
We know we're OK with things 
moving slower, but the upside of

319
00:16:09,440 --> 00:16:11,880
those features going to market 
first before we do this tech 

320
00:16:11,880 --> 00:16:16,120
tech project outweigh the 
negative parts of waiting for it

321
00:16:16,120 --> 00:16:18,600
or whatever. 
So you know, that's just a kind 

322
00:16:18,600 --> 00:16:23,560
of simplified example of how we 
want to start thinking about the

323
00:16:23,560 --> 00:16:27,080
business impact, the customer 
impact, the user impact of 

324
00:16:27,080 --> 00:16:30,520
something that traditionally has
been seen as engineering's 

325
00:16:30,520 --> 00:16:33,840
problem and engineering's kind 
of self-directed project. 

326
00:16:33,840 --> 00:16:37,640
It's not every single thing that
an engineering team works on 

327
00:16:37,640 --> 00:16:41,120
needs to benefit the business. 
And your job as an engineering 

328
00:16:41,120 --> 00:16:44,160
leader is not to say, well, just
trust us, we're in the code all 

329
00:16:44,160 --> 00:16:46,480
day. 
It is to figure out what is the 

330
00:16:46,480 --> 00:16:48,400
way that this actually benefits 
the business. 

331
00:16:48,760 --> 00:16:50,920
And it's just something that we 
haven't had to do a lot in the 

332
00:16:50,920 --> 00:16:52,480
past. 
So it's a new skill for a lot of

333
00:16:52,480 --> 00:16:53,960
leaders. 
Yeah. 

334
00:16:53,960 --> 00:16:56,320
So you mentioned that I'm also 
guilty in the past, right. 

335
00:16:56,320 --> 00:16:58,800
So whenever we talk about 
engineering challenges, 

336
00:16:58,800 --> 00:17:01,800
engineering project, I think we 
always kind of like explain it 

337
00:17:01,960 --> 00:17:05,920
in the engineering complexity 
manner and then it stops there, 

338
00:17:06,240 --> 00:17:07,520
right? 
We don't actually translate 

339
00:17:07,520 --> 00:17:10,640
further into how it actually 
impacts the business or how can 

340
00:17:10,640 --> 00:17:13,040
it actually bring more 
capability into the business, 

341
00:17:13,040 --> 00:17:16,040
right. 
So I think culturally in the 

342
00:17:16,079 --> 00:17:19,680
industry, I think it's really 
rare to have an organization 

343
00:17:19,680 --> 00:17:22,440
that kind of like be able to 
balance between these two. 

344
00:17:22,480 --> 00:17:25,480
And even you mentioned in the in
our pre composition as well that

345
00:17:25,480 --> 00:17:28,840
you have seen two different 
extremes, one maybe organization

346
00:17:28,840 --> 00:17:32,200
that focus a lot more on just 
business impact, you know, being

347
00:17:32,200 --> 00:17:35,160
able to churn new features fast,
as many features as possible. 

348
00:17:35,160 --> 00:17:37,120
And the other one is actually 
focusing a lot more on 

349
00:17:37,120 --> 00:17:39,800
engineering and maybe doing a 
lot more this, you know, 

350
00:17:40,320 --> 00:17:42,120
rewriting micro service and all 
that. 

351
00:17:42,120 --> 00:17:45,120
So maybe tell us about the 
danger of these two extremes and

352
00:17:45,120 --> 00:17:47,080
how can we actually balance 
between these two? 

353
00:17:48,720 --> 00:17:51,680
Yeah. 
You know, and I think the career

354
00:17:51,680 --> 00:17:55,000
change that I went through in 
going to be a coach versus, so 

355
00:17:55,000 --> 00:17:58,920
now I get to go extremely broad,
not necessarily as deep, but 

356
00:17:58,920 --> 00:18:02,320
like very, very broad across a 
lot of companies, which is a 

357
00:18:02,320 --> 00:18:04,480
huge benefit to do like pattern 
matching. 

358
00:18:04,480 --> 00:18:06,640
You know, sometimes I think 
about myself as like a human 

359
00:18:06,640 --> 00:18:08,840
regular expression for 
engineering problems. 

360
00:18:08,840 --> 00:18:11,960
Like I just, I'm just like 
figuring out which things belong

361
00:18:11,960 --> 00:18:14,800
and which things don't. 
I've worked with companies who 

362
00:18:14,800 --> 00:18:18,800
really have extremely hands off 
approach to say like, OK, say 

363
00:18:18,800 --> 00:18:21,760
every engineer, you just like 
you're hired to do this job. 

364
00:18:21,760 --> 00:18:24,640
Here's the product you work on, 
do the thing. 

365
00:18:25,120 --> 00:18:28,280
And I think what we get in that 
situation is like a bunch of 

366
00:18:28,280 --> 00:18:30,120
people moving in different 
directions. 

367
00:18:30,120 --> 00:18:32,960
I mean, this is an extreme 
example, but you know, people 

368
00:18:32,960 --> 00:18:36,600
are vectors. 
We have like a speed, but also a

369
00:18:36,600 --> 00:18:38,960
direction. 
And so people can be moving 

370
00:18:38,960 --> 00:18:41,520
really fast, but if they're not 
aligned and going in the same 

371
00:18:41,520 --> 00:18:44,560
place, the benefit just isn't 
going to be as great as it could

372
00:18:44,560 --> 00:18:46,680
be. 
So that's on one end of the 

373
00:18:47,240 --> 00:18:49,520
extreme. 
I think the other end is I've 

374
00:18:49,520 --> 00:18:52,800
worked with some clients where I
mean their engineers need to 

375
00:18:52,800 --> 00:18:58,200
know not down to the cent, but 
like how much impact did that 

376
00:18:58,800 --> 00:19:01,600
bring to the the company? 
You know, I've worked with 

377
00:19:01,600 --> 00:19:05,120
engineers who really like that's
their gratification centers 

378
00:19:05,120 --> 00:19:09,120
light up when they know like, oh
great, you know my whatever 

379
00:19:09,120 --> 00:19:12,360
optimization I did in, you know,
usually it's more like 

380
00:19:12,360 --> 00:19:16,040
e-commerce type situations. 
But like, oh, I optimized this 

381
00:19:16,280 --> 00:19:20,520
page load and like now our 
shopping cart drop off went 

382
00:19:20,520 --> 00:19:23,440
from, you know, X percent down 
to X percent and that accounts 

383
00:19:23,440 --> 00:19:27,440
for 1.3 million in revenue and 
whatever. 

384
00:19:27,480 --> 00:19:30,280
And I'm like, it's great that 
you know that, Like, I love that

385
00:19:30,320 --> 00:19:33,920
you have access to that. 
But I have also some clients 

386
00:19:33,920 --> 00:19:36,560
that take that to the farthest 
extreme and say if we can't 

387
00:19:36,560 --> 00:19:38,840
quantify it and if the number 
isn't high enough, then we're 

388
00:19:38,840 --> 00:19:41,400
not gonna do it. 
And what that leads to is just 

389
00:19:41,400 --> 00:19:46,480
like a slow degradation of their
systems over time 'cause you 

390
00:19:46,480 --> 00:19:50,280
know, if you cook all day and 
never do it, a single load of 

391
00:19:50,280 --> 00:19:52,800
dishes, it's not going to take 
long until it's just very 

392
00:19:52,800 --> 00:19:54,360
difficult to operate in the 
kitchen. 

393
00:19:54,360 --> 00:19:55,560
And that's sort of what's 
happened. 

394
00:19:55,560 --> 00:19:59,160
So, you know, where in the 
middle is right for your company

395
00:19:59,160 --> 00:20:01,800
is really an exercise I will 
leave to the listener. 

396
00:20:02,080 --> 00:20:04,640
It's got to be somewhere in 
between the two of those. 

397
00:20:04,640 --> 00:20:10,160
Like how can you save space for 
self-directed engineering 

398
00:20:10,360 --> 00:20:15,440
projects with also, you know, 
alignment and working toward 

399
00:20:15,440 --> 00:20:17,920
common goals for the business? 
How can you have both? 

400
00:20:18,320 --> 00:20:20,000
Because you definitely can have 
both. 

401
00:20:20,360 --> 00:20:22,920
It's just hard to know. 
Every business context is a 

402
00:20:22,920 --> 00:20:25,360
little bit different, but you 
need to find the place in the 

403
00:20:25,360 --> 00:20:27,640
middle that's right for your 
team and your company. 

404
00:20:28,600 --> 00:20:30,600
Yeah, definitely. 
I think every company has a 

405
00:20:30,600 --> 00:20:33,200
different situation or context. 
So maybe time as well, right? 

406
00:20:33,200 --> 00:20:36,160
There's a pressure to increase 
the business impact and there's 

407
00:20:36,200 --> 00:20:39,320
a time probably that is more 
relaxed so you can do more 

408
00:20:39,320 --> 00:20:41,840
self-directed engineering 
projects or maybe equally 

409
00:20:41,840 --> 00:20:43,360
balanced in any product road 
map. 

410
00:20:43,360 --> 00:20:45,800
Typically it's like, I don't 
know, yearly, quarterly, right? 

411
00:20:45,800 --> 00:20:48,760
You kind of like allocate what 
kind of percentage to work on 

412
00:20:48,760 --> 00:20:51,880
business related stuff and also 
the engineering related stuff. 

413
00:20:52,240 --> 00:20:54,040
I think those are definitely 
good tips, right? 

414
00:20:54,040 --> 00:20:56,400
So for people don't go to the 
extreme, right, I think it's 

415
00:20:56,680 --> 00:20:59,640
always challenging if you just 
follow one approach versus the 

416
00:20:59,640 --> 00:21:01,440
others. 
And I think the other thing that

417
00:21:01,440 --> 00:21:05,200
is quite typical these days is 
about developer productivity and

418
00:21:05,200 --> 00:21:08,120
developer experience, right? 
So I remember in the past when I

419
00:21:08,120 --> 00:21:10,080
work in a bigger scale up, 
right? 

420
00:21:10,240 --> 00:21:13,240
So this is always the bigger 
question to the engineering 

421
00:21:13,240 --> 00:21:17,240
leaders, Like tell us about, you
know, what kind of metrics do 

422
00:21:17,240 --> 00:21:20,400
you want to use for engineering?
And I think this is always 

423
00:21:20,400 --> 00:21:22,960
difficult, especially if we want
to bring up the topic. 

424
00:21:23,080 --> 00:21:26,000
We want to improve our developer
experience, but building a 

425
00:21:26,000 --> 00:21:27,800
business case is always 
difficult. 

426
00:21:27,880 --> 00:21:31,080
So tell us, how can we actually 
build a business case for 

427
00:21:31,080 --> 00:21:34,080
improving developer experience 
or developer productivity? 

428
00:21:35,280 --> 00:21:38,480
Yeah, this is one of my favorite
questions to answer because I 

429
00:21:38,480 --> 00:21:42,080
think that developer experience 
and developer productivity 

430
00:21:42,080 --> 00:21:46,440
exists in this very strange area
where what is good for your 

431
00:21:46,440 --> 00:21:49,400
engineers and what is good for 
your business are the same 

432
00:21:49,400 --> 00:21:53,840
thing. 
And they're so few opportunities

433
00:21:53,840 --> 00:21:58,480
as leaders that we get to like, 
do the right thing That's, you 

434
00:21:58,480 --> 00:22:01,560
know, the right thing that like 
we as engineers also want to do.

435
00:22:01,560 --> 00:22:03,520
But like, that's also the right 
thing for the business. 

436
00:22:03,760 --> 00:22:06,920
Because the bottom line is that 
poor developer experience just 

437
00:22:06,920 --> 00:22:12,440
cripples innovation. 
It makes work and value flow 

438
00:22:12,480 --> 00:22:16,880
through your company to your 
users at very slow speed and 

439
00:22:16,880 --> 00:22:20,000
reducing friction, not just 
makes engineers more like 

440
00:22:20,000 --> 00:22:22,320
fulfilled and happy and 
satisfied with their working 

441
00:22:22,320 --> 00:22:24,560
environment. 
It is really good for your 

442
00:22:24,560 --> 00:22:26,400
customers and for your business 
as well. 

443
00:22:26,920 --> 00:22:30,200
And so it makes sense to invest 
in it because if you don't and 

444
00:22:30,200 --> 00:22:33,280
your competitors do, there's 
only one outcome of that 

445
00:22:33,280 --> 00:22:35,120
situation, which is that you 
fall behind. 

446
00:22:35,840 --> 00:22:39,120
And so developer experience is 
this interesting thing that is 

447
00:22:39,120 --> 00:22:42,400
sort of like the overlap of the 
Venn diagram right there. 

448
00:22:42,560 --> 00:22:45,600
And I think it's such an 
enjoyable problem space to work 

449
00:22:45,600 --> 00:22:47,840
in. 
Very interesting that you 

450
00:22:47,840 --> 00:22:51,440
mentioned developer experience 
is something that both business 

451
00:22:51,440 --> 00:22:54,720
and engineers, you know, 
incentivize to make it better, 

452
00:22:54,720 --> 00:22:56,320
right? 
I think this term is kind of 

453
00:22:56,320 --> 00:22:58,920
like new in the industry, maybe,
I don't know, in the past three,

454
00:22:58,920 --> 00:23:02,360
2-3 years, probably it's getting
hotter and hotter, right, in 

455
00:23:02,360 --> 00:23:05,120
terms of discussions and 
research papers and all that. 

456
00:23:05,480 --> 00:23:09,080
And more companies are getting 
into this space as well trying 

457
00:23:09,080 --> 00:23:11,000
to understand what is developer 
experience, right? 

458
00:23:11,000 --> 00:23:14,200
Because in so many different 
culture, different types of 

459
00:23:14,200 --> 00:23:17,600
companies, experience and 
productivity can be quantified 

460
00:23:17,600 --> 00:23:19,400
differently. 
And I know that you have dealt 

461
00:23:19,400 --> 00:23:22,320
with this engineering metrics 
for quite a number of years. 

462
00:23:22,760 --> 00:23:24,360
So maybe in your point of view, 
right. 

463
00:23:24,360 --> 00:23:27,800
So what are the good engineering
metrics to use these days? 

464
00:23:29,320 --> 00:23:33,320
Yeah, well, I can answer that 
question simply with a new 

465
00:23:33,320 --> 00:23:34,080
framework. 
Actually. 

466
00:23:34,080 --> 00:23:37,880
Then Abhinoda and I published 
along with a collaboration from 

467
00:23:38,040 --> 00:23:42,040
quite a few other people. 
So to give a kind of a richer 

468
00:23:42,040 --> 00:23:44,680
answer, I think I would have 
said it depends. 

469
00:23:44,880 --> 00:23:47,680
And my answer would have been it
depends for a long time. 

470
00:23:47,680 --> 00:23:51,800
I've been working in developer 
tooling for over a decade, you 

471
00:23:51,800 --> 00:23:54,400
know, always trying to like make
things more efficient, make them

472
00:23:54,400 --> 00:23:56,600
better, make them faster, make 
them more stable or whatever. 

473
00:23:56,600 --> 00:23:59,360
And like how to quantify this 
and how to bring that to the 

474
00:23:59,360 --> 00:24:02,320
business has always been kind of
an open question. 

475
00:24:02,320 --> 00:24:05,440
And because every business is so
unique, usually the story that 

476
00:24:05,440 --> 00:24:08,760
we've needed to tell with 
metrics to make them matter to 

477
00:24:08,760 --> 00:24:11,840
the business has also been 
slightly different depending on 

478
00:24:11,840 --> 00:24:13,800
it. 
As you said, the last couple 

479
00:24:13,800 --> 00:24:16,680
years, like developer 
productivity and developer 

480
00:24:16,680 --> 00:24:19,040
experience are really like 
having their moment in the 

481
00:24:19,040 --> 00:24:21,200
spotlight. 
There's so many companies that 

482
00:24:21,200 --> 00:24:26,000
are practicing improving 
developer experience, like 

483
00:24:26,000 --> 00:24:28,960
really investing in developer 
efficiency and effectiveness. 

484
00:24:28,960 --> 00:24:33,040
So we have just more data to 
look at more examples. 

485
00:24:33,080 --> 00:24:36,480
And from all of those examples, 
we've really nailed it down to 

486
00:24:36,480 --> 00:24:39,840
speed, effectiveness, quality 
and business impact as the four 

487
00:24:39,840 --> 00:24:43,480
pillars to kind of put a story 
together about developer 

488
00:24:43,480 --> 00:24:45,200
productivity and developer 
effectiveness. 

489
00:24:45,200 --> 00:24:47,680
So there's not going to be a 
single metric. 

490
00:24:47,760 --> 00:24:49,840
I think that's an important 
thing also to call out here. 

491
00:24:50,400 --> 00:24:54,160
We've been looking for a single 
metric for decades now. 

492
00:24:54,920 --> 00:24:58,120
Maybe we thought it was lines of
code before and now we, I don't 

493
00:24:58,120 --> 00:25:00,480
know, maybe we thought it was 
number of commits or number of 

494
00:25:00,480 --> 00:25:02,520
PRS. 
We're just not going to get to a

495
00:25:02,520 --> 00:25:05,800
single metric because software 
development is just inherently 

496
00:25:05,800 --> 00:25:07,920
very complex. 
There's a lot of knowledge work,

497
00:25:07,920 --> 00:25:10,800
there's a lot of different 
processes and social systems 

498
00:25:10,800 --> 00:25:14,960
that also feed into it. 
But I think those four really 

499
00:25:14,960 --> 00:25:18,360
cover comprehensively the most 
important bits. 

500
00:25:19,520 --> 00:25:22,680
Yeah, the new framework that you
mentioned is called DX Core 4, 

501
00:25:22,680 --> 00:25:25,840
right? 
So it's speed, effectiveness, 

502
00:25:25,840 --> 00:25:30,440
yeah, quality and impact. 
So it's very exciting to always 

503
00:25:30,520 --> 00:25:33,320
hear new research, you know, new
kind of metrics, you know, 

504
00:25:33,320 --> 00:25:35,800
especially, right. 
So how do you compare this with,

505
00:25:36,120 --> 00:25:38,120
you know, the other metrics that
were available before? 

506
00:25:38,120 --> 00:25:40,760
So I think many people would 
have heard about Dora metrics, 

507
00:25:40,760 --> 00:25:44,000
right, the four P metrics and 
also space framework. 

508
00:25:44,080 --> 00:25:48,520
And I know DX also published a 
paper called DFX, you know, a 

509
00:25:48,560 --> 00:25:53,000
few years ago. 
So how would you differ between 

510
00:25:53,000 --> 00:25:55,680
this DX Core 4 and the other 
metrics? 

511
00:25:55,680 --> 00:25:58,680
And is it just another metrics 
that we have to study and 

512
00:25:59,200 --> 00:26:02,960
implement our company? 
Yeah. 

513
00:26:02,960 --> 00:26:06,880
So the aim with DX Core 4 is 
that these, the metrics that we 

514
00:26:06,880 --> 00:26:12,800
have in the DX Core 4 framework 
are like they unify the other 

515
00:26:12,840 --> 00:26:15,920
frameworks that come before it. 
And also the research that went 

516
00:26:15,920 --> 00:26:19,960
into DX Core 4, it's all 
building on top of the research 

517
00:26:19,960 --> 00:26:22,440
from Dora, from space, from the 
Dev X framework, etcetera. 

518
00:26:22,440 --> 00:26:24,920
So this is not meant to 
necessarily. 

519
00:26:25,400 --> 00:26:27,720
I think there's all often it's 
like, which one are you going to

520
00:26:27,720 --> 00:26:30,080
choose one or the other? 
When in fact, they sort of all 

521
00:26:30,080 --> 00:26:32,720
kind of coexist in the same 
universe and have different 

522
00:26:32,720 --> 00:26:35,840
purposes. 
The DX Core 4 has all of the 

523
00:26:35,840 --> 00:26:37,920
four key Dora metrics integrated
in it. 

524
00:26:38,320 --> 00:26:41,600
It is an implementation of the 
space framework and it uses the 

525
00:26:41,600 --> 00:26:44,760
concepts from Dev X. 
So the Core 4 is sort of 

526
00:26:45,320 --> 00:26:47,960
everything altogether, but 
simplified enough that it's easy

527
00:26:47,960 --> 00:26:50,200
to get started with. 
Yeah. 

528
00:26:50,200 --> 00:26:52,760
So I think that's a very good 
thing, right? 

529
00:26:52,760 --> 00:26:56,400
So now we can consolidate our 
effort into this just the X Core

530
00:26:56,400 --> 00:26:58,400
4, right? 
So maybe if you can explain a 

531
00:26:58,400 --> 00:27:01,440
little bit about those 4 
dimensions, how did you come up 

532
00:27:01,440 --> 00:27:04,040
with just these four? 
Are there any kind of research 

533
00:27:04,040 --> 00:27:07,440
or you know, something that kind
of like brought you into this 

534
00:27:07,440 --> 00:27:09,600
conclusion? 
Yeah. 

535
00:27:09,960 --> 00:27:13,520
I think fundamentally the 
backbone of the DX Core 4 is a 

536
00:27:13,520 --> 00:27:15,520
concept called oppositional 
metrics. 

537
00:27:15,520 --> 00:27:19,920
And, and you'll see this also in
Dora and in space and and you 

538
00:27:19,920 --> 00:27:23,440
know, many metrics frameworks. 
But the idea is that when we 

539
00:27:23,440 --> 00:27:26,200
look at many metrics next to 
each other, we want to have 

540
00:27:26,200 --> 00:27:30,480
metrics that are sending signal 
and work in in conjunction with 

541
00:27:30,480 --> 00:27:33,080
each other, that if one goes up,
we want to see the other one 

542
00:27:33,480 --> 00:27:35,240
like also go up. 
And if the other one goes down, 

543
00:27:35,240 --> 00:27:37,880
we know it's a, a signal that 
something is wrong. 

544
00:27:38,160 --> 00:27:41,480
And so, for example, we could 
take speed and quality because 

545
00:27:41,480 --> 00:27:44,440
that's an often the classic 
trade off is like, are we going 

546
00:27:44,440 --> 00:27:47,640
to go faster or do we want to 
make it good and, and quality. 

547
00:27:47,680 --> 00:27:49,640
And usually it's seen as a trade
off. 

548
00:27:49,680 --> 00:27:53,040
And what core 4 and a lot of 
these others metrics frameworks 

549
00:27:53,200 --> 00:27:55,440
suggest is like, it should not 
be a trade off. 

550
00:27:55,760 --> 00:27:58,480
You should be able to move 
faster while increasing quality,

551
00:27:59,000 --> 00:28:01,080
and so we want to see those 
things move together. 

552
00:28:01,440 --> 00:28:04,520
The same for effectiveness, 
which is like the the measure of

553
00:28:04,520 --> 00:28:07,520
developer experience. 
How effective can developers be 

554
00:28:07,520 --> 00:28:10,560
in the system in which they 
develop software? 

555
00:28:11,280 --> 00:28:15,400
If we see speed go up but the 
developer experience degrade, we

556
00:28:15,400 --> 00:28:18,560
know something is wrong. 
Or if we see a really great 

557
00:28:18,560 --> 00:28:21,480
developer experience, but 
quality goes down, also not 

558
00:28:21,480 --> 00:28:23,920
good. 
So we want to have these sort of

559
00:28:23,920 --> 00:28:26,880
levers and checks and balances 
built into the framework. 

560
00:28:27,120 --> 00:28:29,920
And so speed, effectiveness, 
quality and business impact 

561
00:28:29,920 --> 00:28:34,960
really cover the biggest corners
of software development and keep

562
00:28:34,960 --> 00:28:38,040
those things in check. 
For the individual metrics, what

563
00:28:38,040 --> 00:28:41,280
we're doing is suggesting a key 
metric and then several 

564
00:28:41,280 --> 00:28:44,000
secondary metrics if you want to
go a bit further into your 

565
00:28:44,000 --> 00:28:47,240
measurement. 
So for speed, that is diffs per 

566
00:28:47,240 --> 00:28:50,640
engineer, these are like PRS or 
merge requests or whatever it's 

567
00:28:50,640 --> 00:28:53,360
called. 
This is a metric and it's, you 

568
00:28:53,360 --> 00:28:55,840
know, it's the first one, it's 
the first one at the table. 

569
00:28:55,840 --> 00:28:58,720
It's the first one I always talk
about because it is the most 

570
00:28:58,720 --> 00:29:00,440
controversial. 
Definitely. 

571
00:29:00,920 --> 00:29:03,520
I think even a few years ago I 
would have said like, that's a 

572
00:29:03,520 --> 00:29:06,920
bad idea, don't do it. 
But we have seen lots of 

573
00:29:06,920 --> 00:29:11,400
companies use this metric to 
provide helpful but limited 

574
00:29:11,400 --> 00:29:16,600
insight into the health of their
software development cycle. 

575
00:29:17,560 --> 00:29:20,120
One really important thing about
this metric of diffs per 

576
00:29:20,120 --> 00:29:24,720
engineer is that we're not 
trying to see, oh, how many PRS 

577
00:29:24,720 --> 00:29:27,320
did Henry close and then how 
many did Laura close? 

578
00:29:27,320 --> 00:29:29,960
We're not looking at that. 
We just want to look at a 

579
00:29:30,000 --> 00:29:33,360
developer in your organization, 
you know, are they closing on 

580
00:29:33,360 --> 00:29:36,880
average 3 PRS a week or 10? 
You know, what is that? 

581
00:29:36,880 --> 00:29:38,960
What does that look like? 
Because that can provide us 

582
00:29:39,160 --> 00:29:44,320
information about how easy it is
for developers to develop code 

583
00:29:44,440 --> 00:29:46,560
just like fundamentally what 
we're doing here, right? 

584
00:29:46,560 --> 00:29:49,680
So we wanna keep track. 
Like are developers able to 

585
00:29:49,920 --> 00:29:53,120
actually produce code that has a
lot to do with effectiveness, 

586
00:29:53,120 --> 00:29:55,040
which is the measure of 
developer experience in the 

587
00:29:55,040 --> 00:29:58,000
system. 
So companies that have a great 

588
00:29:58,000 --> 00:30:00,440
developer experience have 
developers that you know, just 

589
00:30:00,440 --> 00:30:04,840
don't lose time to things that 
are wasteful, are friction, you 

590
00:30:04,840 --> 00:30:08,160
know, a lot of drag. 
They are satisfied with their 

591
00:30:08,160 --> 00:30:10,200
tools, their processes, 
etcetera. 

592
00:30:10,200 --> 00:30:12,560
They, you know, they can make 
room for innovation, those 

593
00:30:12,560 --> 00:30:14,000
things. 
So we want to measure that and 

594
00:30:14,000 --> 00:30:17,400
make sure that that's again one 
of the four pillars and that 

595
00:30:17,400 --> 00:30:19,040
it's keeping balance with the 
rest. 

596
00:30:19,400 --> 00:30:22,560
Quality is change failure rate. 
That's a classic good old Dora 

597
00:30:22,560 --> 00:30:24,160
metric. 
If you recognize that change 

598
00:30:24,160 --> 00:30:27,080
failure rate. 
And then impact is the kind of 

599
00:30:27,080 --> 00:30:30,520
the business number here, which 
is percentage of time spent on 

600
00:30:30,520 --> 00:30:34,000
new capabilities. 
Thanks for sharing this overview

601
00:30:34,000 --> 00:30:36,960
about those 4 dimensions, right?
I think definitely the first 

602
00:30:36,960 --> 00:30:40,840
thing that always kind of like 
controversial is counting the 

603
00:30:40,840 --> 00:30:44,640
number of something, right? 
So this time in the DX Core 4, 

604
00:30:44,960 --> 00:30:48,320
it suggested that we should 
count the number of diffs per 

605
00:30:48,320 --> 00:30:51,400
engineer, although in the 
aggregate not like individuals, 

606
00:30:51,400 --> 00:30:53,840
right? 
So this this diff could be the 

607
00:30:53,840 --> 00:30:57,200
PR or merge request that we are 
accustomed to these days. 

608
00:30:57,640 --> 00:31:01,120
So tell us why this is something
that is more prominent versus 

609
00:31:01,120 --> 00:31:03,720
the Dora metrics which 
previously advocated something 

610
00:31:03,720 --> 00:31:07,520
like number of deployments or 
maybe the lead time, right time 

611
00:31:07,520 --> 00:31:11,480
to bring value to production. 
So why diffs become more 

612
00:31:11,480 --> 00:31:14,920
prominent rather than those? 
Yeah. 

613
00:31:14,920 --> 00:31:18,440
So Dora metrics are designed to 
measure software delivery 

614
00:31:18,440 --> 00:31:20,720
capabilities. 
It's really focusing on like 

615
00:31:20,720 --> 00:31:24,160
once the code is written, how 
can we get that code out to our 

616
00:31:24,160 --> 00:31:26,760
customers? 
So you'll see things like lead 

617
00:31:26,760 --> 00:31:30,840
time, deployment frequency 
change, failure rate, time to 

618
00:31:30,840 --> 00:31:32,640
recover from a failed 
deployment, which used to be 

619
00:31:32,640 --> 00:31:34,960
called MTTR. 
These are really focusing on 

620
00:31:34,960 --> 00:31:39,040
that delivery side of things. 
The diffs per engineer focuses a

621
00:31:39,040 --> 00:31:41,880
little bit more on the code 
authoring side of things like 

622
00:31:41,880 --> 00:31:45,040
the, you know, everything that 
happens before the Dora metrics 

623
00:31:45,040 --> 00:31:50,200
kick in more or less. 
So the activity measurements. 

624
00:31:50,200 --> 00:31:52,520
So you mentioned the space 
framework before. 

625
00:31:52,880 --> 00:31:56,200
For those listeners who haven't 
had a chance to work with the 

626
00:31:56,200 --> 00:31:59,520
space framework or read about 
it, the space framework suggests

627
00:31:59,520 --> 00:32:02,680
that there's five main 
dimensions to developer 

628
00:32:02,680 --> 00:32:04,760
productivity. 
We've got satisfaction and 

629
00:32:04,760 --> 00:32:07,520
well-being, performance, 
activity, communication and 

630
00:32:07,520 --> 00:32:09,280
collaboration, and efficiency 
and flow. 

631
00:32:10,040 --> 00:32:13,120
Those activity metrics are 
usually what we think about when

632
00:32:13,120 --> 00:32:16,280
we think of developer 
productivity, like commits, 

633
00:32:16,960 --> 00:32:18,800
lines of code. 
It's not a great metric. 

634
00:32:19,160 --> 00:32:21,880
Other things like that number of
PRS, for example, those all fit 

635
00:32:21,880 --> 00:32:24,000
into the activity side of 
things. 

636
00:32:24,520 --> 00:32:27,360
We're not saying like we should 
ignore those activity metrics. 

637
00:32:27,360 --> 00:32:29,640
That's not what space came out 
to say. 

638
00:32:29,720 --> 00:32:32,200
They're saying activity metrics 
exist. 

639
00:32:32,200 --> 00:32:35,720
They provide limited insight 
into how well the system is 

640
00:32:35,720 --> 00:32:37,840
performing. 
Also, you need to make sure that

641
00:32:37,840 --> 00:32:40,080
there's all these other things 
accounted for as well. 

642
00:32:40,320 --> 00:32:44,320
And so that's what we've tried 
to do with the core 4 is to not 

643
00:32:44,320 --> 00:32:48,200
ignore the activity metrics. 
It's still an important part of 

644
00:32:48,200 --> 00:32:50,920
system performance, but give it 
more context so that it's 

645
00:32:50,920 --> 00:32:55,520
actually meaningful and gives us
information, which is why Disper

646
00:32:55,520 --> 00:32:58,760
Engineer not in an individual 
level, but not as the only 

647
00:32:58,760 --> 00:33:00,280
number. 
We never want to look at that 

648
00:33:00,280 --> 00:33:02,120
number on its own. 
We always want to have it 

649
00:33:02,600 --> 00:33:04,840
accompanied by effectiveness, 
quality and impact. 

650
00:33:05,600 --> 00:33:07,600
Yeah. 
Also not to mention that you not

651
00:33:07,600 --> 00:33:10,200
just have the key metrics, 
right, the one metric for each 

652
00:33:10,200 --> 00:33:12,600
dimension, right? 
You actually also have secondary

653
00:33:12,600 --> 00:33:16,080
metrics, which I think in this 
speed dimension, right, you also

654
00:33:16,080 --> 00:33:19,200
have likely time and also a 
number of deployments as well. 

655
00:33:19,600 --> 00:33:22,160
So I think again, like coming 
back to what you said, there's 

656
00:33:22,160 --> 00:33:24,560
no one single metric. 
So it's always kind of like 

657
00:33:24,840 --> 00:33:28,520
combination of a couple of them.
And the other thing that I find 

658
00:33:28,520 --> 00:33:30,240
also interesting is about 
impact, right? 

659
00:33:30,680 --> 00:33:33,800
You're not actually measuring in
terms of dollar revenue or 

660
00:33:33,800 --> 00:33:36,080
number of user or number of 
whatever, right? 

661
00:33:36,080 --> 00:33:39,280
But actually it's kind of like 
the number of new capabilities 

662
00:33:39,280 --> 00:33:41,280
and kind of like new innovations
probably. 

663
00:33:41,560 --> 00:33:45,000
So why is that more important 
rather than, you know, the BAU 

664
00:33:45,280 --> 00:33:47,800
stuff, right, bringing more 
revenue and profit to the 

665
00:33:47,800 --> 00:33:52,320
company? 
Yeah, part of this is like every

666
00:33:52,320 --> 00:33:54,880
business is different and I 
guess like when we get into it 

667
00:33:54,880 --> 00:33:59,320
depends territory like we are 
not able to provide outstanding 

668
00:33:59,320 --> 00:34:02,560
benchmarks about like what is a 
great business performance for 

669
00:34:02,560 --> 00:34:05,800
your particular company in terms
of like monthly active users or 

670
00:34:05,800 --> 00:34:07,680
daily active users. 
That's not really something. 

671
00:34:07,840 --> 00:34:13,440
But what we can do is look at in
general how, what's the ratio of

672
00:34:14,000 --> 00:34:17,520
like what's revenue per 
engineer, for example, for every

673
00:34:17,719 --> 00:34:20,440
dollar of revenue that we get in
how much are we spending on 

674
00:34:20,440 --> 00:34:22,280
developer salaries. 
That's something that we can 

675
00:34:22,280 --> 00:34:26,400
kind of look at standardized and
see and compare, you know, 

676
00:34:26,400 --> 00:34:29,080
companies or like R&D as 
percentage of revenue. 

677
00:34:29,400 --> 00:34:33,320
We can look at different ratios 
and see, OK, how do we like how 

678
00:34:33,320 --> 00:34:35,360
does this look across the 
industry, but then more 

679
00:34:35,360 --> 00:34:38,920
importantly is like, how do we 
look compared to ourselves and 

680
00:34:39,199 --> 00:34:40,880
is this number going higher or 
lower? 

681
00:34:40,880 --> 00:34:43,239
We're not suggesting that you 
shouldn't measure daily active 

682
00:34:43,239 --> 00:34:46,239
users or monthly active users, 
like please do that if that's 

683
00:34:46,239 --> 00:34:48,199
the if that's the metric that 
you're looking for. 

684
00:34:48,440 --> 00:34:51,600
But when it comes to kind of 
broadly speaking about business 

685
00:34:51,600 --> 00:34:55,000
impact and how organizations are
approaching this across the 

686
00:34:55,000 --> 00:34:57,880
industry, these are a bit more 
easy, like they're a bit easier 

687
00:34:57,960 --> 00:34:59,680
and more straightforward to 
standardize on. 

688
00:34:59,840 --> 00:35:02,000
You mentioned about the IT 
depends answer, right? 

689
00:35:02,000 --> 00:35:05,080
I think this is quite typical in
any kind of discussions about 

690
00:35:05,080 --> 00:35:07,960
developer experience. 
I even have a friend telling me 

691
00:35:07,960 --> 00:35:10,440
that, hey, in your past 
episodes, why is it always kind 

692
00:35:10,440 --> 00:35:12,920
of like it depends, right? 
So I think it's a more 

693
00:35:12,920 --> 00:35:17,560
opinionated answer is something 
that many of us would kind of 

694
00:35:17,560 --> 00:35:19,840
like appreciate or kind of like 
want to follow, right? 

695
00:35:20,120 --> 00:35:23,240
But in this case, the X Core 4, 
I think it's kind of like a new 

696
00:35:23,320 --> 00:35:24,880
new, kind of like a new 
paradigms. 

697
00:35:25,000 --> 00:35:28,160
How can we actually start 
measuring this, maybe in our 

698
00:35:28,160 --> 00:35:30,560
engineering team or engineering 
organization? 

699
00:35:31,080 --> 00:35:33,840
Is there some kind of different 
mechanism that you would 

700
00:35:33,840 --> 00:35:36,240
suggest? 
Yeah. 

701
00:35:36,240 --> 00:35:39,920
So in the DX Core 4, we'll go 
over the key metrics and 

702
00:35:39,920 --> 00:35:44,080
secondary metrics, but we also 
have a third row, I guess or 

703
00:35:44,280 --> 00:35:47,000
column depending on how you're 
looking at in that table, which 

704
00:35:47,000 --> 00:35:49,920
is about data collection. 
So I'll just like I'll get right

705
00:35:49,920 --> 00:35:51,760
to my sort of opinionated 
answer. 

706
00:35:52,280 --> 00:35:55,080
Everything in here can be 
collected via a survey. 

707
00:35:55,400 --> 00:35:58,680
So surveys are super powerful. 
They're not just about gathering

708
00:35:58,680 --> 00:36:01,800
people's opinions. 
You can gather quantitative data

709
00:36:01,800 --> 00:36:03,960
via a survey. 
It's self reported data, which 

710
00:36:03,960 --> 00:36:08,400
quite honestly is high enough 
fidelity to make the decisions 

711
00:36:08,400 --> 00:36:09,760
that you need to make with the 
data. 

712
00:36:10,000 --> 00:36:14,560
So whether your lead time is 46 
minutes or if it's between 30 

713
00:36:14,560 --> 00:36:17,760
minutes and an hour usually 
doesn't matter when it comes to 

714
00:36:17,760 --> 00:36:20,000
what do we need to focus on and 
what do we want to improve. 

715
00:36:20,200 --> 00:36:24,000
So you can gather all of these 
metrics with a survey and self 

716
00:36:24,000 --> 00:36:26,000
reported data. 
You might have to ask some 

717
00:36:26,000 --> 00:36:28,360
different people for different 
surveys, especially for 

718
00:36:28,360 --> 00:36:30,480
different survey answers, 
especially when you get into the

719
00:36:30,480 --> 00:36:33,800
business impact stuff because 
individual engineers probably 

720
00:36:33,800 --> 00:36:37,000
don't have information about R&D
as percentage of revenue, but 

721
00:36:37,000 --> 00:36:39,440
they can tell you how much time 
they spent on maintenance work 

722
00:36:39,440 --> 00:36:43,280
versus new features last week, 
you know, So my opinion, the 

723
00:36:43,280 --> 00:36:45,840
answer is start with a survey. 
You can get all of this via a 

724
00:36:45,840 --> 00:36:49,760
survey and then figure out what 
would be useful if the 

725
00:36:49,760 --> 00:36:53,080
collection was automated via, 
you know, scraping data from an 

726
00:36:53,080 --> 00:36:56,440
API or integrating with some 
tool and then go build that. 

727
00:36:56,440 --> 00:37:00,400
But don't delay getting a 
baseline because a baseline is 

728
00:37:00,400 --> 00:37:03,240
going to give you direction into
what you should start improving 

729
00:37:03,320 --> 00:37:05,240
and then help you measure your 
progress. 

730
00:37:05,520 --> 00:37:08,840
And so delaying a baseline to 
build something that you're not 

731
00:37:08,840 --> 00:37:11,160
even, you don't even know if 
it's going to be useful because 

732
00:37:11,160 --> 00:37:13,120
you haven't gone through the 
process of getting the 

733
00:37:13,120 --> 00:37:16,400
information, making a decision, 
changing something, measuring 

734
00:37:16,400 --> 00:37:18,840
again to me is a a bit of a 
waste of time. 

735
00:37:18,840 --> 00:37:22,800
So I would start first with the 
baseline, make your changes, 

736
00:37:23,000 --> 00:37:25,400
measure them, and then figure 
out what you want to invest in 

737
00:37:25,400 --> 00:37:27,080
when it comes to automated 
collection. 

738
00:37:28,400 --> 00:37:29,800
Yeah, getting the baseline, I 
agree. 

739
00:37:29,800 --> 00:37:32,520
It's I think it's very important
as well because in the past I've

740
00:37:32,520 --> 00:37:37,240
used the X as well, right. 
So we were actually like having 

741
00:37:37,240 --> 00:37:39,520
a lot of challenges, right. 
We know we have problems like 

742
00:37:39,560 --> 00:37:42,320
anecdotally, we can hear from 
engineers, OK, we had built 

743
00:37:42,320 --> 00:37:45,880
issue, built time issue, you 
know, quality issue, but it's 

744
00:37:45,880 --> 00:37:49,480
all about opinions, right? 
Rather than kind of like, you 

745
00:37:49,480 --> 00:37:51,480
know, quantifiable, right? 
So I think get getting the 

746
00:37:51,480 --> 00:37:54,080
baseline across different teams,
across the whole engineering. 

747
00:37:54,080 --> 00:37:56,400
In fact, I think it's something 
that is super critical, 

748
00:37:56,400 --> 00:37:57,680
especially if you're a leader, 
right? 

749
00:37:57,680 --> 00:38:00,840
Because without that baseline, I
don't think you would know what 

750
00:38:00,840 --> 00:38:02,360
kind of things you should 
improve. 

751
00:38:02,720 --> 00:38:05,120
And plus there are so many 
different dimensions and 

752
00:38:05,120 --> 00:38:07,760
problems, right? 
I think it's also difficult to 

753
00:38:08,160 --> 00:38:09,520
kind of like improve everything,
right? 

754
00:38:09,520 --> 00:38:12,560
You're gonna, you know, put 
focus on some certain areas 

755
00:38:12,560 --> 00:38:15,200
rather than, you know, throwing 
all your effort into all 

756
00:38:15,200 --> 00:38:17,560
different dimensions, right? 
I think, I think the baseline is

757
00:38:17,560 --> 00:38:20,560
definitely super critical. 
And I think another thing that 

758
00:38:21,080 --> 00:38:23,440
is one of the dimension that I 
would like to ask you is about 

759
00:38:23,440 --> 00:38:26,800
effectiveness, right? 
So I think in your DX Core 4, 

760
00:38:26,800 --> 00:38:29,480
right, you mentioned about 
Developer Experience Index or 

761
00:38:29,480 --> 00:38:33,600
DXI. 
Maybe this is something new for 

762
00:38:33,640 --> 00:38:35,560
some of us who haven't heard 
about it before. 

763
00:38:35,760 --> 00:38:39,320
Tell us what is this DXI? 
Yeah. 

764
00:38:39,320 --> 00:38:42,880
So Dxi is a developer experience
index. 

765
00:38:42,880 --> 00:38:47,800
It is a predictive benchmark of 
developer experience and all 

766
00:38:47,800 --> 00:38:51,640
that it is, is just a mean 
average of 25 developer 

767
00:38:51,640 --> 00:38:54,160
experienced drivers that you can
find online. 

768
00:38:54,160 --> 00:38:57,000
It's like the DX 25, we can find
it on DXS site. 

769
00:38:57,280 --> 00:39:00,760
What we found over time, now 
that we have a lot of companies 

770
00:39:00,760 --> 00:39:05,960
using DXA, lot more data is that
companies that score higher in 

771
00:39:05,960 --> 00:39:10,160
these Dev X drivers have less 
time wasted. 

772
00:39:10,800 --> 00:39:14,200
And so that again, that time 
waste is not just in terms of 

773
00:39:14,200 --> 00:39:18,280
like salary and, you know, 
frustration, but really the main

774
00:39:18,280 --> 00:39:20,440
benefit there is like, what 
would you have built instead? 

775
00:39:20,600 --> 00:39:22,120
What could you have built 
instead? 

776
00:39:22,440 --> 00:39:26,280
Because even if like so for 
example, the average developer 

777
00:39:26,280 --> 00:39:32,440
wastes 20% of their time each 
week on inefficient processes, 

778
00:39:33,040 --> 00:39:35,920
meetings that are not useful to 
them, waiting around, waiting 

779
00:39:35,920 --> 00:39:38,000
for a feedback, you, you name 
it. 

780
00:39:38,000 --> 00:39:40,920
I mean, if you've worked as a 
developer, it probably probably 

781
00:39:40,920 --> 00:39:43,840
doesn't take you long to list 
out all the ways that your time 

782
00:39:43,840 --> 00:39:45,760
gets wasted in a week. 
Or when you're just kind of 

783
00:39:45,760 --> 00:39:47,760
spent, you're, you're just 
waiting for stuff. 

784
00:39:48,320 --> 00:39:53,120
Even taking that down to 19%, I 
mean, this is like a minuscule, 

785
00:39:53,160 --> 00:39:55,760
but like, let's give developers 
back just like a little bit of 

786
00:39:55,760 --> 00:39:58,240
time every day or like don't 
take them out of their flow a 

787
00:39:58,240 --> 00:40:00,840
little bit more. 
It does not take long for that 

788
00:40:00,840 --> 00:40:06,280
to add up to some. 
A huge amount of time of money, 

789
00:40:06,280 --> 00:40:09,000
but also opportunity like what 
else could you build instead? 

790
00:40:09,440 --> 00:40:11,480
And so that's really what the 
idea of this developer 

791
00:40:11,480 --> 00:40:15,000
experience index like it's not 
about ping pong and beer, which 

792
00:40:15,000 --> 00:40:18,360
is often I think developer 
experience has a like quite a 

793
00:40:18,360 --> 00:40:20,400
marketing problem. 
I don't know if there's a, we 

794
00:40:20,400 --> 00:40:24,880
should name it something better,
but you know, when Abby has this

795
00:40:24,880 --> 00:40:26,840
thing that just like makes me 
laugh every time he's like, Can 

796
00:40:26,840 --> 00:40:30,120
you imagine if a new salesperson
or a new sales leader, like a 

797
00:40:30,120 --> 00:40:32,960
new CRO comes in and says, well,
we're going to measure the 

798
00:40:32,960 --> 00:40:37,880
impact of our sales organization
based on sales Rep experience. 

799
00:40:37,880 --> 00:40:41,120
Like no way. 
Like you would not like there's 

800
00:40:41,120 --> 00:40:42,840
just no way that that would ever
go over. 

801
00:40:43,120 --> 00:40:45,840
And so I sometimes I feel like, 
you know, when developer 

802
00:40:45,840 --> 00:40:48,920
leaders, CTOSVPS directors and 
we talk about developer 

803
00:40:48,920 --> 00:40:52,240
experience, the perception is a 
little bit like, oh, these whiny

804
00:40:52,240 --> 00:40:56,000
engineers want to play ping pong
and drink beer after 3:30 PM 

805
00:40:56,000 --> 00:40:58,000
every day. 
And like, that's not what this 

806
00:40:58,000 --> 00:41:00,560
is. 
This is not a ping pong and beer

807
00:41:00,560 --> 00:41:03,640
problem. 
This is like a crippling, you 

808
00:41:03,640 --> 00:41:06,240
know, this, this stops 
innovation and it's going to 

809
00:41:06,560 --> 00:41:10,040
cripple your company's ability 
to innovate if you don't fix it.

810
00:41:10,320 --> 00:41:13,320
And so putting it front and 
center in the Core 4 along with 

811
00:41:13,320 --> 00:41:15,680
the other things sort of 
emphasizes like this isn't just 

812
00:41:15,680 --> 00:41:19,080
a ping pong and beer, it's truly
like a fundamental business 

813
00:41:19,080 --> 00:41:22,600
problem that needs to be solved.
But the DX I I guess to go back 

814
00:41:22,600 --> 00:41:25,280
to your original question is 
just a mean average of these 

815
00:41:25,280 --> 00:41:28,480
developer experienced drivers 
that are correlated with lower 

816
00:41:28,480 --> 00:41:31,200
time loss, better performance 
and engineering generally. 

817
00:41:31,920 --> 00:41:33,800
I think it's very funny when you
mentioned that, right? 

818
00:41:33,800 --> 00:41:37,040
Yeah, I think it speaks true to 
the situation, right. 

819
00:41:37,040 --> 00:41:39,680
So why there is a developer 
experience but not, you know 

820
00:41:39,680 --> 00:41:41,760
other departments experience, I 
don't know like sales 

821
00:41:41,760 --> 00:41:44,400
experience, operation experience
and things like that. 

822
00:41:44,720 --> 00:41:48,360
So I think it's very important 
that we kind of, I've put 

823
00:41:48,480 --> 00:41:50,960
perspective on this, right? 
I think productivity is kind of 

824
00:41:50,960 --> 00:41:53,720
like general term, right? 
To kind of like measure or 

825
00:41:53,720 --> 00:41:56,320
improve. 
So another thing that I would 

826
00:41:56,320 --> 00:41:58,640
like to ask you, since you have 
published this paper, right? 

827
00:41:58,880 --> 00:42:02,040
Has it been implemented in maybe
some of your customers or maybe 

828
00:42:02,120 --> 00:42:04,440
other organizations be big or 
small? 

829
00:42:04,960 --> 00:42:09,160
Is there any kind of impact? 
So once somebody has, you know, 

830
00:42:09,200 --> 00:42:11,000
used this framework, new 
framework, right? 

831
00:42:11,720 --> 00:42:14,840
Is there any impact into how 
they improve their developer 

832
00:42:14,840 --> 00:42:17,720
experience? 
Yeah, there's quite like 

833
00:42:17,720 --> 00:42:20,680
hundreds of companies using the 
DX Core 4 right now. 

834
00:42:21,280 --> 00:42:24,280
And I think like when you start 
using it, you shouldn't expect 

835
00:42:24,280 --> 00:42:27,560
that, OK, now all of a sudden 
developer experience is going to

836
00:42:27,560 --> 00:42:30,240
improve. 
What it does is it shows you or 

837
00:42:30,480 --> 00:42:35,640
or gives you some models to 
figure out where do I want to 

838
00:42:35,640 --> 00:42:38,880
focus my efforts and where 
should I prioritize our 

839
00:42:38,880 --> 00:42:42,160
resources in order to fix 
problems, to see the impact that

840
00:42:42,160 --> 00:42:44,920
we want to see. 
The other thing that DX Core 4 

841
00:42:44,920 --> 00:42:47,680
really does for an individual 
engineering leader is it just 

842
00:42:47,680 --> 00:42:52,520
gives you better set of 
vocabulary words, common 

843
00:42:52,520 --> 00:42:56,480
language to take the problem of 
developer experience and the 

844
00:42:56,480 --> 00:42:59,480
problem of developer 
productivity, quantify it, but 

845
00:42:59,480 --> 00:43:03,680
also tell a better story so that
you can walk into your exec team

846
00:43:03,680 --> 00:43:06,520
meeting or whatever. 
Meaning that you have to go to 

847
00:43:06,800 --> 00:43:10,680
and draw a line in between 
developer experience and 

848
00:43:11,080 --> 00:43:13,360
innovation capability, for 
example, in that impact 

849
00:43:13,360 --> 00:43:15,600
category. 
I think before with other 

850
00:43:15,600 --> 00:43:18,440
metrics like Dora. 
Dora is really great, but it 

851
00:43:18,440 --> 00:43:20,840
only measures software delivery 
capabilities. 

852
00:43:21,160 --> 00:43:24,320
It's not tying it all together 
and really bringing it back to 

853
00:43:24,320 --> 00:43:27,120
the business, which is what 
we've designed Core 4 to do so 

854
00:43:27,120 --> 00:43:30,880
that an individual engineering 
leader, whether you're a manager

855
00:43:30,880 --> 00:43:35,400
or AVP or CTO, you can have 
better conversations about why 

856
00:43:36,040 --> 00:43:40,320
productivity problems or, you 
know, lack of investment in 

857
00:43:40,480 --> 00:43:43,040
things like tech debt or 
whatever it might be, why it's 

858
00:43:43,040 --> 00:43:45,760
bad for the business. 
And then specifically, when you 

859
00:43:46,040 --> 00:43:48,520
change something, what are the 
results that you should expect 

860
00:43:48,520 --> 00:43:51,040
to see and then hold yourself 
accountable to that prediction? 

861
00:43:51,880 --> 00:43:53,280
Yeah. 
So when you mention about, you 

862
00:43:53,280 --> 00:43:56,000
know, not expecting sudden, you 
know, improvement, right. 

863
00:43:56,000 --> 00:43:59,040
So I remember in the past when 
I, you know, used to do this as 

864
00:43:59,040 --> 00:44:01,360
well, right? 
So after, I don't know, like two

865
00:44:01,360 --> 00:44:06,120
quarters, we only saw like a 
mini improvements in some of the

866
00:44:06,120 --> 00:44:08,080
numbers, right? 
So I think some of these 

867
00:44:08,320 --> 00:44:11,120
problems are very complex, 
especially the social dynamic 

868
00:44:11,120 --> 00:44:12,960
aspect. 
And plus, you know, people 

869
00:44:12,960 --> 00:44:16,080
change, you know, direction or 
maybe the mission of the 

870
00:44:16,080 --> 00:44:17,560
organizations also change, 
right? 

871
00:44:17,920 --> 00:44:19,960
And I think don't forget about 
that aspect as well. 

872
00:44:19,960 --> 00:44:22,680
It's not like something you just
quantify and you know, you put a

873
00:44:22,680 --> 00:44:26,000
lot more effort and it will be 
improved after a while. 

874
00:44:26,320 --> 00:44:29,760
So I think the other aspect is 
how do you actually motivate 

875
00:44:29,760 --> 00:44:33,760
engineering leaders to actually 
try bringing business case for 

876
00:44:33,760 --> 00:44:37,120
improving developer experience? 
And do you suggest also doing it

877
00:44:37,120 --> 00:44:40,080
quarterly or is it something 
like a yearly thing or is there 

878
00:44:40,080 --> 00:44:43,440
any kind of a, a best practice 
that you would suggest us to do?

879
00:44:44,760 --> 00:44:50,160
Yeah, I think always all the 
time, I think, you know, I don't

880
00:44:50,160 --> 00:44:52,920
have a great answer to the 
cadence part of it, but let's 

881
00:44:52,920 --> 00:44:56,800
take a maybe a, a bigger picture
answer, which is like, who are 

882
00:44:56,800 --> 00:44:58,720
your enemies and who are your 
allies? 

883
00:44:59,000 --> 00:45:03,040
So I know we're going to talk 
about like my tech leadership 

884
00:45:03,040 --> 00:45:04,920
wisdom at the end of this 
episode. 

885
00:45:04,920 --> 00:45:08,200
But like, you know, adjacent to 
that answer is like there's 

886
00:45:08,440 --> 00:45:11,200
always going to be someone who 
benefits from an inefficient 

887
00:45:11,200 --> 00:45:13,280
system. 
Doesn't matter how bad something

888
00:45:13,280 --> 00:45:15,880
is, there's always going to be a
group or an individual that's 

889
00:45:15,880 --> 00:45:19,080
going to benefit from it. 
And so you really need to figure

890
00:45:19,080 --> 00:45:22,680
out like, why is the systems 
like, why do we tolerate 

891
00:45:23,160 --> 00:45:26,480
developer experience as it is? 
Or like, why do we tolerate poor

892
00:45:26,480 --> 00:45:28,560
productivity or like bad 
tooling? 

893
00:45:28,560 --> 00:45:31,800
Like who is it benefiting? 
Is it benefiting us because we 

894
00:45:31,800 --> 00:45:34,960
don't like change and it's just 
easier to not change than to go 

895
00:45:34,960 --> 00:45:38,880
through the discomfort of having
to change, You know, why is 

896
00:45:38,880 --> 00:45:40,880
that? 
But try to figure out like, what

897
00:45:40,880 --> 00:45:43,680
are the, the organizational 
factors that are keeping the 

898
00:45:43,680 --> 00:45:47,320
status quo in place? 
So that's like your enemies kind

899
00:45:47,320 --> 00:45:50,280
of category. 
There's also your allies and 

900
00:45:50,280 --> 00:45:52,560
those are like your Co 
conspirators, people who are 

901
00:45:52,560 --> 00:45:55,200
going to, you know, just as 
fired up about developer 

902
00:45:55,200 --> 00:45:57,280
productivity and about developer
experiences. 

903
00:45:57,280 --> 00:46:00,240
You are that might be another 
engineering manager or leader. 

904
00:46:00,560 --> 00:46:03,640
It's really great if it can be 
like a product manager or 

905
00:46:03,640 --> 00:46:07,200
someone from a cross functional 
function or a senior individual 

906
00:46:07,200 --> 00:46:10,520
contributor, like staff level, 
principal level, like those are 

907
00:46:10,520 --> 00:46:13,760
really great allies to have. 
Because then instead of it being

908
00:46:13,760 --> 00:46:19,040
you going to your VP or your CTO
and saying, hey, we want to do 

909
00:46:19,040 --> 00:46:22,160
X, it's like a bunch of you. 
And there is strength in 

910
00:46:22,160 --> 00:46:23,840
numbers. 
There is strength in numbers. 

911
00:46:24,400 --> 00:46:28,000
I would also look for the person
at your organization who's going

912
00:46:28,000 --> 00:46:33,360
to sponsor this. 
So like an exec who is going to 

913
00:46:33,920 --> 00:46:37,000
pave a path for you. 
You know, you might need more 

914
00:46:37,000 --> 00:46:39,640
budget, you might need resources
or headcount. 

915
00:46:39,640 --> 00:46:42,480
You're also going to need sort 
of like a mandate to be able to 

916
00:46:42,480 --> 00:46:45,960
get everyone on board with these
types of projects being on the 

917
00:46:45,960 --> 00:46:48,880
road map, so to speak. 
And so who's gonna sponsor you? 

918
00:46:49,320 --> 00:46:51,760
And then concretely, what are, 
you know, if you do establish 

919
00:46:51,800 --> 00:46:53,720
this sort of like working group,
like what are you really 

920
00:46:53,720 --> 00:46:56,720
responsible for? 
What are your KPIs, so to speak?

921
00:46:56,720 --> 00:46:58,840
And that's really where the core
4 comes in, which is like, how 

922
00:46:58,840 --> 00:47:00,720
do you measure the impact of 
what you're gonna do? 

923
00:47:01,240 --> 00:47:03,600
So that's where I would 
encourage if, if an engineering 

924
00:47:03,600 --> 00:47:06,640
leader is like interested in 
pursuing this is like first 

925
00:47:06,640 --> 00:47:09,520
figure out like your, you know, 
like your tactics on the ground,

926
00:47:09,520 --> 00:47:11,880
like who are you working with? 
What are the factors working 

927
00:47:11,880 --> 00:47:13,600
against you? 
What are those objections? 

928
00:47:13,800 --> 00:47:17,120
Who is an executive sponsor that
you can, you know, bring this up

929
00:47:17,120 --> 00:47:20,760
to and try to kind of make a 
plan and then pitch it that way 

930
00:47:21,160 --> 00:47:25,320
and then take it from there? 
Very interesting advice you have

931
00:47:25,320 --> 00:47:27,720
there, you know, figure out your
allies and kind of like your 

932
00:47:28,000 --> 00:47:30,760
detractors, right? 
So the one who benefited from 

933
00:47:30,760 --> 00:47:33,000
the inefficiencies or maybe 
status quo, right? 

934
00:47:33,000 --> 00:47:36,040
Sometimes we don't like changes,
especially if it's too drastic, 

935
00:47:36,160 --> 00:47:38,600
you know, coming back to the 
example of monoliths micro 

936
00:47:38,600 --> 00:47:39,800
service or the other way around,
right? 

937
00:47:39,800 --> 00:47:41,280
It's kind of like a big change, 
right? 

938
00:47:41,280 --> 00:47:44,680
It's something that not everyone
is incentivized to make it 

939
00:47:44,680 --> 00:47:46,080
successful or make it happen, 
right? 

940
00:47:46,080 --> 00:47:49,600
So I think figuring out allies 
and work together in order to 

941
00:47:49,600 --> 00:47:51,800
come up with business case 
definitely is a very, very 

942
00:47:51,800 --> 00:47:53,880
crucial. 
Another important thing that 

943
00:47:53,920 --> 00:47:56,880
typically is always discussed 
when we talk about developer 

944
00:47:56,880 --> 00:47:59,520
experience. 
Lately, it's about introduction 

945
00:47:59,520 --> 00:48:02,760
of internal developer platform 
or even AI these days. 

946
00:48:03,120 --> 00:48:06,320
So maybe in your view, do you 
have any take of these two, 

947
00:48:06,320 --> 00:48:09,640
right, IDP and AI? 
How do you see them as a core 

948
00:48:09,640 --> 00:48:11,920
components these days to improve
developer experience? 

949
00:48:11,920 --> 00:48:15,240
Or is it something just nice to 
have for some organizations? 

950
00:48:16,840 --> 00:48:18,880
Yeah, I think developers see it 
as a core component. 

951
00:48:19,120 --> 00:48:22,360
And So what I'm interestingly 
seeing, I've had quite a few 

952
00:48:22,360 --> 00:48:25,840
conversations about this in the 
last few months, is like, how do

953
00:48:25,840 --> 00:48:29,360
I as an engineering leader, make
a business case for investing in

954
00:48:29,680 --> 00:48:33,080
an IDP or investing in Copilot, 
for example? 

955
00:48:33,320 --> 00:48:37,920
Especially with AI, some of the 
promises are very lofty. 

956
00:48:37,920 --> 00:48:39,880
Let's just keep it that. 
Like, let's just say that 

957
00:48:39,880 --> 00:48:41,960
diplomatically. 
I mean, you know, I don't know 

958
00:48:41,960 --> 00:48:46,000
who really believes that, but 
like, AI in general, you know, 

959
00:48:46,000 --> 00:48:48,600
is just sold as like, oh, it's 
going to make everyone twice as 

960
00:48:48,600 --> 00:48:50,800
productive and you can reduce 
half your staff or, you know, 

961
00:48:50,800 --> 00:48:52,360
whatever, whatever the promise 
is. 

962
00:48:52,640 --> 00:48:54,760
That's just not really what's 
happening. 

963
00:48:55,000 --> 00:49:00,080
It does reduce cognitive load 
and make developers work faster,

964
00:49:00,080 --> 00:49:03,360
help them work faster. 
But you know, it's still, it's a

965
00:49:03,360 --> 00:49:06,840
tool that needs to be operated 
by a skilled individual and 

966
00:49:07,240 --> 00:49:09,920
using an irresponsibly can lead 
to more problems when it comes 

967
00:49:09,920 --> 00:49:12,800
to maintainability and creating 
more problems for yourself. 

968
00:49:12,800 --> 00:49:17,040
So figuring out what purpose 
these tools should serve and 

969
00:49:17,040 --> 00:49:21,080
then figuring out a way to 
measure that impact and tell a 

970
00:49:21,080 --> 00:49:24,600
story with numbers and make a 
business case for it again is a 

971
00:49:24,600 --> 00:49:27,280
very important thing. 
So, you know, one thing we 

972
00:49:27,280 --> 00:49:30,240
haven't really touched on is 
like attrition or being able to 

973
00:49:30,240 --> 00:49:34,520
attract talent. 
A lot of developers, if you ask 

974
00:49:34,520 --> 00:49:36,880
them like if they were 
interviewing for two similar 

975
00:49:36,880 --> 00:49:39,800
companies and one of them had a 
copilot license for them and the

976
00:49:39,800 --> 00:49:42,360
other one didn't, most 
developers are going to go work 

977
00:49:42,360 --> 00:49:44,520
for the company that has a 
copilot license for them. 

978
00:49:45,040 --> 00:49:46,960
And So what does that actually 
cost you? 

979
00:49:47,160 --> 00:49:49,240
And you can figure out the 
numbers like you might have to 

980
00:49:49,240 --> 00:49:52,400
ask some other people, but like 
how long does it take the 

981
00:49:52,400 --> 00:49:56,160
average from job requisition to 
be posted online for that role 

982
00:49:56,160 --> 00:49:58,800
to be filled? 
Then how long does higher like 

983
00:49:58,880 --> 00:50:02,320
training take? 
Like on boarding, you can figure

984
00:50:02,320 --> 00:50:06,200
out how much expensive that is. 
And then how expensive is it 

985
00:50:06,200 --> 00:50:09,000
when someone quits and goes 
works for someone else because 

986
00:50:09,000 --> 00:50:10,720
they're not happy with developer
experience. 

987
00:50:10,720 --> 00:50:13,560
Like we can put a number on 
attrition pretty easily. 

988
00:50:13,800 --> 00:50:18,800
It usually it costs like 75 
thousand U.S. dollars, I would 

989
00:50:18,800 --> 00:50:22,080
say at a minimum to replace an 
engineer like that's mid level 

990
00:50:22,080 --> 00:50:24,240
or above. 
And that's not nothing. 

991
00:50:24,240 --> 00:50:27,080
You know that that's pretty 
significant when it comes to 

992
00:50:27,080 --> 00:50:29,800
like what are you going to pay 
for copilot licenses? 

993
00:50:29,920 --> 00:50:32,520
But these are some of the ways 
that I might put together a, a 

994
00:50:32,560 --> 00:50:36,320
narrative around something like 
Copilot or, or an IDP. 

995
00:50:36,320 --> 00:50:39,120
It's not just about like what's 
the tangible benefit in terms of

996
00:50:39,120 --> 00:50:41,720
productivity gains, but also 
let's look at space. 

997
00:50:41,720 --> 00:50:43,640
What about satisfaction 
well-being? 

998
00:50:43,640 --> 00:50:45,440
What about communication and 
collaboration? 

999
00:50:45,560 --> 00:50:49,640
What are those other things that
are positively impacted by these

1000
00:50:49,640 --> 00:50:52,640
tools being in place? 
Yeah, thanks for highlighting 

1001
00:50:52,640 --> 00:50:53,760
that. 
We have to understand the 

1002
00:50:53,760 --> 00:50:56,520
purpose before we implement 
those kind of thing, right? 

1003
00:50:56,520 --> 00:51:00,520
Because many of us, we read from
the research out there, people 

1004
00:51:00,640 --> 00:51:02,800
raving about, you know, IDP or 
AI, right? 

1005
00:51:02,800 --> 00:51:05,480
And we just follow, right? 
Implement it without actually 

1006
00:51:05,480 --> 00:51:09,240
understanding the the impact or 
the purpose or the even the the 

1007
00:51:09,240 --> 00:51:13,680
things that actually sometimes 
like in the past episode, I have

1008
00:51:13,680 --> 00:51:16,400
this Andrew Boyaji, right? 
So he highlighted the state of 

1009
00:51:16,400 --> 00:51:20,000
developer experience report. 
So he highlighted that leaders 

1010
00:51:20,000 --> 00:51:22,320
are just following, you know, 
maybe the trends, right? 

1011
00:51:22,320 --> 00:51:25,240
Implement AI and thought by 
doing that they actually can 

1012
00:51:25,240 --> 00:51:28,120
improve developers, but 
developers thought differently. 

1013
00:51:28,120 --> 00:51:32,480
They just find like maybe a few 
percentage improvement, but it 

1014
00:51:32,480 --> 00:51:34,800
doesn't really actually 
necessarily improve the whole 

1015
00:51:34,800 --> 00:51:37,040
developer experience. 
So understanding the true 

1016
00:51:37,040 --> 00:51:39,720
purpose behind implementing 
those I think definitely is a 

1017
00:51:39,720 --> 00:51:42,000
key. 
So we discussed a lot of things,

1018
00:51:42,000 --> 00:51:45,480
you know, maybe is there 
anything that unintuitively you 

1019
00:51:45,640 --> 00:51:48,560
figure it out but many people 
are not aware of in terms of 

1020
00:51:48,560 --> 00:51:50,880
developer experience, is there 
something that you want to 

1021
00:51:50,880 --> 00:51:53,120
highlight? 
So for us who may not have heard

1022
00:51:53,120 --> 00:51:56,280
before in the industry or in the
research these days. 

1023
00:51:58,280 --> 00:52:01,800
I think that maybe the most 
surprising thing is that your 

1024
00:52:01,800 --> 00:52:03,880
teams just, they know where the 
problems are. 

1025
00:52:04,000 --> 00:52:06,000
They work in these tools all the
time. 

1026
00:52:06,080 --> 00:52:09,800
And I don't care what metrics 
framework it is like if it's the

1027
00:52:09,800 --> 00:52:14,440
TX Core 4 or Dora or any 
combination of metrics aligned 

1028
00:52:14,440 --> 00:52:18,800
to the space categories. 
Do not expect that capturing 

1029
00:52:18,800 --> 00:52:23,240
workflow data and looking at 
GitHub data, JIRA, GitLab, 

1030
00:52:23,240 --> 00:52:27,040
whatever, is going to point you 
to some like unknown about 

1031
00:52:27,040 --> 00:52:29,680
developer productivity that like
suddenly now that I have all 

1032
00:52:29,680 --> 00:52:34,040
this data about commits and 
story points and number of PRS 

1033
00:52:34,040 --> 00:52:36,400
and how work is flowing through 
the system, I'm going to be able

1034
00:52:36,400 --> 00:52:39,240
to find this magic bottleneck 
that I'll be able to fix and 

1035
00:52:39,240 --> 00:52:41,280
like unlock productivity for my 
team. 

1036
00:52:41,640 --> 00:52:45,520
I have never seen that happen. 
I have worked with literally 

1037
00:52:45,520 --> 00:52:47,560
literally thousands of 
engineering leaders at this 

1038
00:52:47,560 --> 00:52:49,600
point. 
I have never come across a 

1039
00:52:49,600 --> 00:52:54,360
single case where engineering 
team, let's just say, has 

1040
00:52:54,360 --> 00:52:58,640
discovered something new based 
on workflow data or quite 

1041
00:52:58,640 --> 00:53:01,600
honestly even like survey data. 
The thing is like your team is 

1042
00:53:01,600 --> 00:53:03,440
in these, they're in the tools 
all day long. 

1043
00:53:03,440 --> 00:53:04,880
They know where the problems 
are. 

1044
00:53:05,440 --> 00:53:08,880
But surveys can be so helpful to
just tell you how big the 

1045
00:53:08,880 --> 00:53:10,720
problem is. 
Like we know the problem is 

1046
00:53:10,720 --> 00:53:13,600
there and then we can put some 
kind of formality around 

1047
00:53:13,600 --> 00:53:16,200
measuring how big the problem is
and if we're fixing it or not. 

1048
00:53:16,200 --> 00:53:19,840
So I think this myth of like I'm
going to implement, I'm going to

1049
00:53:19,840 --> 00:53:22,200
get some developer productivity 
dashboards and like suddenly I'm

1050
00:53:22,200 --> 00:53:25,560
going to be able to forecast and
see ahead when my team has 

1051
00:53:25,560 --> 00:53:27,600
productivity problems. 
Or I'm going to kind of find 

1052
00:53:27,600 --> 00:53:31,120
this like secret bottleneck, 
like it just doesn't exist, 

1053
00:53:31,320 --> 00:53:32,840
doesn't exist. 
Your team knows where the 

1054
00:53:32,840 --> 00:53:35,440
problems are. 
Just believe them because they 

1055
00:53:35,440 --> 00:53:38,680
are professional adults who do 
not have incentive to lie to you

1056
00:53:38,680 --> 00:53:40,640
unless you give them incentive 
to lie to you. 

1057
00:53:41,080 --> 00:53:45,440
So gaming the system isn't 
actually as as big of a problem 

1058
00:53:45,440 --> 00:53:48,080
as we think it is as well. 
That's another surprising thing.

1059
00:53:49,480 --> 00:53:51,080
Wow, I think thanks for 
highlighting that, right. 

1060
00:53:51,080 --> 00:53:54,080
So I, I, I left when you 
explained all that because, 

1061
00:53:54,080 --> 00:53:56,560
yeah, I think many people try to
automate, you know, you know, 

1062
00:53:56,560 --> 00:53:59,000
getting the workflow data, 
getting metrics out 

1063
00:53:59,120 --> 00:54:01,920
out-of-the-box, right? 
Only to find that if you ask 

1064
00:54:02,280 --> 00:54:04,800
maybe the engineers or the 
teams, right, you could get the 

1065
00:54:04,800 --> 00:54:06,880
signals master. 
Other than spending all the 

1066
00:54:06,880 --> 00:54:09,040
effort to actually come up with 
the dashboard, maybe. 

1067
00:54:09,280 --> 00:54:11,920
And in the end you kind of like,
no, that's the the like the 

1068
00:54:11,920 --> 00:54:15,480
problem exists from some people 
who may have shared it with you.

1069
00:54:15,720 --> 00:54:17,760
So you don't need to actually 
spend a lot of effort. 

1070
00:54:18,440 --> 00:54:20,600
So Laura, it's been a pleasant 
conversation. 

1071
00:54:20,600 --> 00:54:23,520
So I think we all learn a lot 
about improving developer 

1072
00:54:23,520 --> 00:54:25,920
experience. 
So as we reach the end of our 

1073
00:54:25,920 --> 00:54:28,240
conversation, I have one last 
question for you. 

1074
00:54:28,320 --> 00:54:30,480
I call this the three technical 
leadership wisdom. 

1075
00:54:30,760 --> 00:54:33,160
So you can think of it just like
advice that you want to give to 

1076
00:54:33,160 --> 00:54:34,840
us. 
Maybe if there anything that you

1077
00:54:34,840 --> 00:54:39,280
want to share with us today? 
Yeah, I have so many things. 

1078
00:54:39,280 --> 00:54:43,920
I'll try to keep it to three. 
On the topic of metrics, I think

1079
00:54:43,920 --> 00:54:48,360
the saying that like all systems
are wrong and some are useful is

1080
00:54:48,360 --> 00:54:51,360
really important. 
And so I would encourage anyone 

1081
00:54:51,640 --> 00:54:55,480
listening to have a healthy dose
of skepticism for any type of 

1082
00:54:55,480 --> 00:54:59,000
data that you're looking at, 
making sure you understand where

1083
00:54:59,000 --> 00:55:02,600
it's coming from, understand the
purpose of it, all the things 

1084
00:55:02,600 --> 00:55:04,960
around it. 
Because measurements are going 

1085
00:55:04,960 --> 00:55:07,080
to be wrong. 
Even a broken clock is right 

1086
00:55:07,080 --> 00:55:10,480
twice a day. 
So just don't let data push you 

1087
00:55:10,480 --> 00:55:13,440
to incorrect conclusions. 
I think that's a very dangerous 

1088
00:55:13,440 --> 00:55:16,080
area in this developer 
productivity metric space. 

1089
00:55:16,680 --> 00:55:21,200
Yeah, I think, again, as I said 
before, things work poorly 

1090
00:55:21,480 --> 00:55:25,480
because it sometimes benefits us
to have them keeping, like to 

1091
00:55:25,480 --> 00:55:28,240
stay working poorly. 
Maybe that's ourselves and we're

1092
00:55:28,240 --> 00:55:30,840
the enemy there because we are 
resistant to change. 

1093
00:55:31,160 --> 00:55:33,600
And maybe there's another factor
in there. 

1094
00:55:33,600 --> 00:55:35,920
So I would figure out what those
things are. 

1095
00:55:35,920 --> 00:55:39,920
You know, you'd really try to 
debug the system and maybe to 

1096
00:55:39,920 --> 00:55:42,640
follow on this like, you know, 
metrics thing. 

1097
00:55:43,360 --> 00:55:46,480
A lot of us that are, you know, 
were previously individual 

1098
00:55:46,480 --> 00:55:50,480
contributor engineers are going 
to try to pattern match or bring

1099
00:55:50,480 --> 00:55:53,080
a lot of the skills that we had 
as an engineer, for example, 

1100
00:55:53,080 --> 00:55:56,560
debugging skills and try to 
debug our teams and 

1101
00:55:56,560 --> 00:55:58,920
organizations in the same way 
that we debugged like our 

1102
00:55:58,920 --> 00:56:03,440
Kubernetes clusters or whatever.
The thing is like, your nodes 

1103
00:56:03,440 --> 00:56:09,080
can't talk to you and they don't
have feelings, and talking to 

1104
00:56:09,080 --> 00:56:12,720
people because your teams are 
made of people isn't being 

1105
00:56:12,720 --> 00:56:15,520
illogical. 
It's actually the correct way to

1106
00:56:15,520 --> 00:56:18,520
approach measuring a system 
that's made-up of people. 

1107
00:56:19,280 --> 00:56:23,000
If we fail to recognize that 
people make up teams and we try 

1108
00:56:23,000 --> 00:56:26,000
to treat them like a Kubernetes 
cluster, we're actually missing 

1109
00:56:26,000 --> 00:56:28,160
sort of like half of the whole 
system. 

1110
00:56:28,520 --> 00:56:31,160
And I would just say that's sort
of categorically incorrect to 

1111
00:56:31,160 --> 00:56:33,120
approach it that way. 
So make sure that you're not 

1112
00:56:33,120 --> 00:56:36,200
forgetting that software teams 
and software development is a 

1113
00:56:36,200 --> 00:56:39,760
socio technical phenomenon. 
So we need to have the social 

1114
00:56:39,760 --> 00:56:42,120
aspect and the technical aspect 
together. 

1115
00:56:42,360 --> 00:56:43,920
Both of them are equally as 
important. 

1116
00:56:43,920 --> 00:56:49,280
So don't forget that humans 
exist. 

1117
00:56:49,280 --> 00:56:51,760
Developers are adults. 
They're professionals. 

1118
00:56:51,760 --> 00:56:53,080
They don't have reason to lie to
you. 

1119
00:56:53,200 --> 00:56:55,120
Treat them as adults. 
Believe them when they tell you 

1120
00:56:55,120 --> 00:56:57,240
something is causing them 
friction in the deploy or the 

1121
00:56:57,240 --> 00:57:00,440
development process. 
Wow, that's really beautiful. 

1122
00:57:00,520 --> 00:57:02,560
I don't know why when you 
explain that, right, I always 

1123
00:57:02,560 --> 00:57:05,560
come back to this phrase, you 
know, pet versus capital thing, 

1124
00:57:05,600 --> 00:57:07,680
right? 
So I think for engineers, we try

1125
00:57:07,680 --> 00:57:10,360
to make everything kind of like 
uniform with big container 

1126
00:57:10,360 --> 00:57:13,120
Kubernetes cluster, right? 
And we treat everything like 

1127
00:57:13,320 --> 00:57:15,760
capital, right? 
But actually all individuals are

1128
00:57:15,760 --> 00:57:18,560
different, right? 
We have our own needs, our own 

1129
00:57:18,560 --> 00:57:20,480
challenges, right? 
And don't forget about the 

1130
00:57:20,520 --> 00:57:22,280
people aspect. 
So I think that's really 

1131
00:57:22,280 --> 00:57:22,880
beautiful. 
Yeah. 

1132
00:57:23,200 --> 00:57:26,680
So, Laura, if people want to 
follow you or you know, maybe 

1133
00:57:26,680 --> 00:57:29,080
discuss with you further about 
some of these topics, is there a

1134
00:57:29,080 --> 00:57:30,640
place where they can find you 
online? 

1135
00:57:31,640 --> 00:57:35,480
Yeah, go to laurataco.com. 
That is where you'll find more 

1136
00:57:35,480 --> 00:57:36,720
about me. 
My blog. 

1137
00:57:36,720 --> 00:57:39,480
I do have a course on developer 
productivity metrics. 

1138
00:57:39,480 --> 00:57:41,360
I'm going to be running it more 
frequently, so you can check 

1139
00:57:41,360 --> 00:57:43,960
that out as well. 
And you can find me on LinkedIn.

1140
00:57:43,960 --> 00:57:46,080
Just search for Laura Taco. 
I think I'm the only one. 

1141
00:57:47,680 --> 00:57:48,960
Right. 
I'll put that all in the show 

1142
00:57:48,960 --> 00:57:50,200
notes. 
Thank you so much for your time,

1143
00:57:50,200 --> 00:57:51,800
Laura. 
I think we all can learn a lot 

1144
00:57:51,800 --> 00:57:53,440
about developer experience from 
you today. 

1145
00:57:53,440 --> 00:57:54,800
So thank you so much for 
sharing. 

1146
00:57:55,680 --> 00:57:56,800
Wonderful. 
Thanks for the lovely 

1147
00:57:56,800 --> 00:57:57,440
conversation.