1
00:00:00,100 --> 00:00:02,600
Definitely is the top 
International software 

2
00:00:02,600 --> 00:00:06,600
development conference with an 
emphasis on coding architecture 

3
00:00:06,600 --> 00:00:09,900
and Tech leadership skills. 
The lineup for this year is 

4
00:00:09,900 --> 00:00:13,600
truly stellar and features many 
Legends in software development 

5
00:00:13,900 --> 00:00:18,300
names, such as Robert Uncle Bob.
Martin can back Scott Hanselman 

6
00:00:18,600 --> 00:00:21,500
Franca subramanium, Carolyn 
honey, Alan. 

7
00:00:21,500 --> 00:00:23,900
Hello. 
Mary poppendieck and many other 

8
00:00:23,900 --> 00:00:27,200
prominent names including some 
of those who have also appeared 

9
00:00:27,200 --> 00:00:29,800
in this podcast before the 
conference. 

10
00:00:30,000 --> 00:00:33,200
Takes place online so you can 
enjoy it from the comfort of 

11
00:00:33,200 --> 00:00:35,700
your couch. 
We spoke to the definitey 

12
00:00:35,700 --> 00:00:38,300
organizers, and I'm happy to 
share that technology. 

13
00:00:38,300 --> 00:00:42,200
You know, has got the 10% 
discount code for you, enter the

14
00:00:42,200 --> 00:00:47,800
promo code, awsm underscore tlg.
When you purchase the ticket on 

15
00:00:47,800 --> 00:00:50,700
definite e.com, here's the promo
code. 

16
00:00:50,700 --> 00:00:54,800
One more time awsm underscore, 
tlj. 

17
00:00:55,500 --> 00:00:58,700
Depending on the time when you 
purchase a ticket, early price 

18
00:00:58,700 --> 00:01:02,000
is still available. 
See you there developer 

19
00:01:02,000 --> 00:01:06,400
experience is one approach to 
thinking about engineering 

20
00:01:06,400 --> 00:01:09,900
excellence and maximizing 
engineering performance. 

21
00:01:09,900 --> 00:01:13,400
And developer experience is 
really about focusing on the 

22
00:01:13,400 --> 00:01:16,200
day-to-day experience of 
delivering software and a team 

23
00:01:16,600 --> 00:01:19,500
understanding. 
What is getting in the way one 

24
00:01:19,500 --> 00:01:22,600
of the biggest constraints and 
bottlenecks and frustrations in 

25
00:01:22,600 --> 00:01:26,600
that process and improving those
to increase. 

26
00:01:26,600 --> 00:01:29,500
The capacity and performance of 
individuals, and the team as a 

27
00:01:29,500 --> 00:01:37,500
whole Hey everyone. 
My name is Henry Surya with 

28
00:01:37,500 --> 00:01:40,800
Robin. 
And you're listening to the 

29
00:01:40,800 --> 00:01:44,000
technology, you know, podcast 
the show where I'll be bringing 

30
00:01:44,000 --> 00:01:47,200
you the greatest technical 
leaders practitioners and 

31
00:01:47,200 --> 00:01:50,900
thought leaders in the industry 
to discuss about their Journey 

32
00:01:51,200 --> 00:01:55,600
ideas and practices that we all 
can learn and apply to build a 

33
00:01:55,607 --> 00:01:59,200
highly performing technical team
and to make an impact in your 

34
00:01:59,200 --> 00:02:02,400
personal work. 
So let's dive into our Journal. 

35
00:02:07,600 --> 00:02:09,600
Hey everyone, welcome to the 
technology. 

36
00:02:09,600 --> 00:02:12,300
Now, podcast the show where you 
can learn about technical 

37
00:02:12,300 --> 00:02:15,400
leadership and Excellence from 
my conversations with great 

38
00:02:15,400 --> 00:02:17,200
thought, leaders in the tech 
industry. 

39
00:02:17,600 --> 00:02:20,000
If this is your first time 
listening to tackle, it Journal,

40
00:02:20,300 --> 00:02:23,400
subscribe and follow the show on
your podcast app and on 

41
00:02:23,400 --> 00:02:27,000
LinkedIn, Twitter and Instagram.
And if you'd like to support my 

42
00:02:27,000 --> 00:02:30,700
journey, creating this podcast, 
Please Subscribe, as a patron at

43
00:02:30,700 --> 00:02:34,200
package. 
Another death / Patron, Be my 

44
00:02:34,200 --> 00:02:36,400
guest for today's episode is a 
be no de. 

45
00:02:36,400 --> 00:02:41,300
RB is the CEO and co-founder of 
DX a platform that helps 

46
00:02:41,300 --> 00:02:44,700
engineering, leaders, measure, 
and improve developer experience

47
00:02:44,700 --> 00:02:48,700
in this episode, I'll be open or
discussion by sharing. 

48
00:02:48,700 --> 00:02:52,400
What developer experiences, why 
it is becoming such an industry 

49
00:02:52,400 --> 00:02:55,200
Trend, nowadays, and the 
different ways of how it is 

50
00:02:55,200 --> 00:02:58,400
being implemented. 
In the industry are be explained

51
00:02:58,400 --> 00:03:01,300
why the traditional metrics 
normally used to measure 

52
00:03:01,300 --> 00:03:04,500
developer productivity? 
Do Really work and can even 

53
00:03:04,500 --> 00:03:07,200
provide perverse incentives are 
be then. 

54
00:03:07,200 --> 00:03:09,400
Touch on the two. 
Popular research has widely 

55
00:03:09,400 --> 00:03:12,600
known in the industry. 
IE the Dora report and space 

56
00:03:12,600 --> 00:03:16,600
framework before then explained 
how the x is building on top of 

57
00:03:16,600 --> 00:03:20,200
both researchers to provide the 
measurements and kpis to measure

58
00:03:20,200 --> 00:03:24,300
developer experience and 
productivity towards the N are 

59
00:03:24,300 --> 00:03:27,700
be shared his advice on how we 
can start investing in improving

60
00:03:27,700 --> 00:03:31,000
developer experience, including 
when to form a dedicated 

61
00:03:31,000 --> 00:03:34,400
developer experience team. 
Getting the buy-in from company 

62
00:03:34,400 --> 00:03:37,800
Executives. 
I really enjoyed my conversation

63
00:03:37,800 --> 00:03:41,300
with Abby and developer 
experience is also an area that 

64
00:03:41,300 --> 00:03:45,200
I have much interest in lately, 
which I believe can be a great 

65
00:03:45,200 --> 00:03:47,400
area. 
Any engineering team can invest 

66
00:03:47,400 --> 00:03:51,200
in, to improve the overall 
productivity and engagement. 

67
00:03:51,300 --> 00:03:54,600
If you find this episode useful,
please help, share it with your 

68
00:03:54,600 --> 00:03:57,600
friends and colleagues who can 
also benefit from listening to 

69
00:03:57,600 --> 00:04:00,500
this episode. 
I really appreciate your support

70
00:04:00,500 --> 00:04:02,800
in sharing and spreading this 
podcast. 

71
00:04:03,000 --> 00:04:06,600
The knowledge to more people. 
Let's dive into a conversation 

72
00:04:06,600 --> 00:04:09,000
after hearing some words from 
our sponsors. 

73
00:04:09,500 --> 00:04:11,800
Mental will be is a silent 
pandemic. 

74
00:04:12,200 --> 00:04:16,100
According to the who depression 
and anxiety caused the global 

75
00:04:16,100 --> 00:04:19,899
economy over one trillion US 
dollars every year, it's time to

76
00:04:19,899 --> 00:04:23,200
make a difference, learn how to 
enhance your life through a 

77
00:04:23,200 --> 00:04:25,100
master class from Founders 
well-being. 

78
00:04:25,100 --> 00:04:29,000
And my good friend Sandy brow on
mental Wellness, visit Founders 

79
00:04:29,000 --> 00:04:32,800
well-being.com / masterclass to 
enroll and enter TL. 

80
00:04:32,900 --> 00:04:38,200
AJ 24, a 20% discount be a 
better version of yourself and 

81
00:04:38,200 --> 00:04:40,800
make an impact. 
Today's episode is proudly 

82
00:04:40,800 --> 00:04:44,400
sponsored by skills matter. 
The global community and events 

83
00:04:44,400 --> 00:04:47,100
platform. 
With more than 100,000 software 

84
00:04:47,100 --> 00:04:50,800
professionals here members. 
Can organize their learning 

85
00:04:50,800 --> 00:04:53,200
experiences around the 
technology topics. 

86
00:04:53,200 --> 00:04:57,000
They care about most you get 
on-demand access to their latest

87
00:04:57,000 --> 00:05:00,200
content thought, leadership 
insights, as well, as the 

88
00:05:00,200 --> 00:05:04,500
exciting schedule of tech events
running a Cross all time zones. 

89
00:05:04,800 --> 00:05:08,400
So whether devops our data 
science is your bus or you're a 

90
00:05:08,400 --> 00:05:12,300
fan of functional programming or
all things Cloud, you can make 

91
00:05:12,300 --> 00:05:16,100
real connections with people who
share your interests head on 

92
00:05:16,100 --> 00:05:19,100
over to skills, method.com to 
become part of the tech 

93
00:05:19,100 --> 00:05:21,200
community that matters most to 
you. 

94
00:05:21,500 --> 00:05:24,700
It's free to join and you will 
find it easy to keep up with the

95
00:05:24,700 --> 00:05:29,300
latest tech Trends. 
Hello everyone. 

96
00:05:29,400 --> 00:05:31,300
Welcome back to another new 
episode of the Attack. 

97
00:05:31,300 --> 00:05:34,500
Original podcast today. 
I have with me a guest named 

98
00:05:34,500 --> 00:05:39,800
Albie NoDa, so I'll be is the 
co-founder and CEO of the x or 

99
00:05:39,800 --> 00:05:42,900
some people also refers to it as
get dx.com. 

100
00:05:43,300 --> 00:05:47,100
So DX is a company that helps 
software organizations to 

101
00:05:47,100 --> 00:05:50,700
measure and improve developer 
productivity and experienced. 

102
00:05:51,000 --> 00:05:54,500
Previously, our be also was the 
founder of pole Panda which got 

103
00:05:54,500 --> 00:05:58,300
acquired by GitHub and thus he 
spent maybe about one and a half

104
00:05:58,300 --> 00:06:01,800
years in GitHub to become like, 
the product manager are looking 

105
00:06:01,800 --> 00:06:06,100
at developing inside, So as you 
can tell Abby's background is 

106
00:06:06,100 --> 00:06:08,600
all about developer experience, 
developing sites and 

107
00:06:08,600 --> 00:06:11,200
productivity. 
So I'm really looking forward to

108
00:06:11,200 --> 00:06:14,000
discuss with you today about 
this topic because it seems to 

109
00:06:14,000 --> 00:06:16,700
be a pretty trendy these days. 
Talking about developer 

110
00:06:16,700 --> 00:06:19,200
productivity, and developer 
experience. 

111
00:06:19,200 --> 00:06:22,300
So welcome to the show, I'll be 
thanks so much for having me. 

112
00:06:22,800 --> 00:06:26,200
So I'll be I always like to 
start my conversation by asking 

113
00:06:26,200 --> 00:06:28,200
the guests to share more about 
yourself. 

114
00:06:28,400 --> 00:06:31,300
So maybe if you can share any 
highlights or turning points in 

115
00:06:31,300 --> 00:06:35,900
your career, Yeah, first of all,
so excited to be here, I'm 

116
00:06:35,900 --> 00:06:38,700
programmer. 
That's what I do by trade and 

117
00:06:38,700 --> 00:06:41,700
that's what I've always done 
since high school, in terms of 

118
00:06:41,700 --> 00:06:45,700
my career, about seven years 
ago, I transition from just 

119
00:06:45,700 --> 00:06:49,100
being an individual contributor 
to being an engineering manager.

120
00:06:49,400 --> 00:06:51,400
And I still remember that shift 
I made. 

121
00:06:51,400 --> 00:06:54,600
It was so exciting at the time 
because you go from being so 

122
00:06:54,600 --> 00:06:57,700
focused on shipping tasks and 
programming features and 

123
00:06:57,700 --> 00:07:01,800
suddenly you're now responsible 
for people and the Dynamics of a

124
00:07:01,800 --> 00:07:03,800
team. 
And so, a big fan of your 

125
00:07:03,800 --> 00:07:07,300
podcast, and big fan of sort of 
the science and art of software 

126
00:07:07,300 --> 00:07:09,700
leadership. 
When I became a software 

127
00:07:09,700 --> 00:07:13,000
engineering manager, one of the 
problems I kind of became 

128
00:07:13,000 --> 00:07:17,400
fascinated by was the problem of
how do you measure software 

129
00:07:17,400 --> 00:07:19,100
development? 
How do you measure software 

130
00:07:19,100 --> 00:07:22,700
development teams, the event 
that sort of prompted, that was,

131
00:07:22,700 --> 00:07:27,000
I was the CTO of a start out in 
California and the CEO came to 

132
00:07:27,000 --> 00:07:30,000
me one day and said, hey, I'll 
be our leadership. 

133
00:07:30,000 --> 00:07:32,200
Team is going to start having 
metrics that. 

134
00:07:32,300 --> 00:07:36,100
We review together each month. 
Can you bring some metrics for 

135
00:07:36,100 --> 00:07:39,000
engineering to understand the 
productivity of your team? 

136
00:07:39,300 --> 00:07:43,700
I remember my initial reaction 
was, I don't know if there is 

137
00:07:43,700 --> 00:07:47,600
anything but really is an 
accurate, depiction of what 

138
00:07:47,600 --> 00:07:50,300
we're producing. 
And certainly there was nothing 

139
00:07:50,300 --> 00:07:53,700
that I felt would be reasonable 
to also use with my team. 

140
00:07:53,900 --> 00:07:57,300
I could report something like 
velocity points or number of 

141
00:07:57,300 --> 00:08:00,400
pull requests or number of 
features to the rest of the 

142
00:08:00,400 --> 00:08:03,100
executives. 
But I knew that number, Nothing.

143
00:08:03,100 --> 00:08:06,500
So, the actual developers on my 
team and so, that moment has 

144
00:08:06,500 --> 00:08:11,600
sparked a now, nearly 70 or 
journey to try and figure out 

145
00:08:11,600 --> 00:08:14,500
this problem. 
And along the way, I first 

146
00:08:14,500 --> 00:08:17,800
started a company called pull 
Panda, which had a few different

147
00:08:17,800 --> 00:08:20,100
products. 
But primarily was still focused 

148
00:08:20,100 --> 00:08:23,600
around this problem of 
measurement with pull Panda. 

149
00:08:23,800 --> 00:08:29,000
The approach we attempted was to
use development sort of exhaust 

150
00:08:29,000 --> 00:08:32,200
that I write so data from GitHub
and jira tools. 

151
00:08:32,299 --> 00:08:36,500
Like that and compile those into
metrics for managers and teams 

152
00:08:36,500 --> 00:08:38,400
and leaders to measure how 
they're doing. 

153
00:08:39,000 --> 00:08:40,600
That company was acquired by 
GitHub. 

154
00:08:40,600 --> 00:08:43,900
Where, as you mentioned in the 
intro, I led a similar product 

155
00:08:43,900 --> 00:08:47,800
with in GitHub GitHub. 
Also wanted to bring a product 

156
00:08:47,800 --> 00:08:49,500
to Market that tried to solve 
this problem. 

157
00:08:49,800 --> 00:08:53,300
Then along the way, I kind of 
came to the realization that 

158
00:08:53,400 --> 00:08:56,400
there was maybe a different way 
to approach this problem, 

159
00:08:56,700 --> 00:08:59,900
perhaps a better way. 
And that's really the Genesis of

160
00:08:59,900 --> 00:09:01,600
DX. 
The company that I've been 

161
00:09:01,600 --> 00:09:03,600
working on for the last Two 
years and running today. 

162
00:09:04,400 --> 00:09:06,800
Thanks for sharing your story. 
I think is really fascinating. 

163
00:09:06,800 --> 00:09:09,800
You have been dwelling with this
problem for 7 years. 

164
00:09:09,800 --> 00:09:13,100
So now that you get a chance to 
found a company working on that,

165
00:09:13,100 --> 00:09:16,300
I think it's really exciting. 
You mentioned that you are kind 

166
00:09:16,300 --> 00:09:19,900
of intrigued by this problem 
these days, actually, it is 

167
00:09:19,900 --> 00:09:22,500
becoming like a trend, like 
everyone's problem. 

168
00:09:22,500 --> 00:09:25,600
Everyone is thinking about it, 
especially so many startups, 

169
00:09:25,600 --> 00:09:28,600
software company these days and 
they want to measure this kind 

170
00:09:28,600 --> 00:09:30,700
of a developer experience and 
productivity. 

171
00:09:31,100 --> 00:09:33,000
So why do you think only Only 
these days. 

172
00:09:33,000 --> 00:09:35,100
It becomes like really hot and 
trendy. 

173
00:09:35,800 --> 00:09:38,500
I actually don't think it's that
new. 

174
00:09:38,500 --> 00:09:41,700
I mean, I think people in 
business of, always tried, to 

175
00:09:41,700 --> 00:09:45,700
measure performance, businesses 
and public companies, have their

176
00:09:45,700 --> 00:09:48,700
stock price public to the whole 
world that everyone can see how 

177
00:09:48,700 --> 00:09:50,300
well your quote-unquote 
performing. 

178
00:09:50,300 --> 00:09:53,600
And of course, if you're ever 
inside of a sales organization 

179
00:09:53,600 --> 00:09:56,900
or a marketing organization, 
it's very much driven by targets

180
00:09:56,900 --> 00:10:00,700
and numbers and performance. 
I think Business Leaders have 

181
00:10:00,700 --> 00:10:02,200
been trying to do the same 
thing. 

182
00:10:02,700 --> 00:10:05,000
For engineer organizations for a
long time. 

183
00:10:05,200 --> 00:10:07,900
Of course, I think at some point
in their careers anyone who's 

184
00:10:07,900 --> 00:10:10,000
worked in Tak has kind of bumped
into this. 

185
00:10:10,000 --> 00:10:15,000
But the most primitive approach 
to trying to measure was through

186
00:10:15,000 --> 00:10:17,200
metrics like lines of code or 
velocity points. 

187
00:10:17,200 --> 00:10:19,900
Just people looked at 
programmers acedo, they produce 

188
00:10:19,900 --> 00:10:21,900
code. 
Let's count how much code they 

189
00:10:21,900 --> 00:10:23,500
produce. 
And of course, everyone who's 

190
00:10:23,500 --> 00:10:26,200
ever written a line of code 
understands why that doesn't 

191
00:10:26,200 --> 00:10:28,500
work. 
But that approach is still 

192
00:10:28,500 --> 00:10:31,700
pretty common today, actually, 
surprisingly, even at really big

193
00:10:31,700 --> 00:10:34,200
reputable Companies. 
But I'm sure we'll get back to 

194
00:10:34,200 --> 00:10:37,300
kind of more like the 
progression of how this happens 

195
00:10:37,300 --> 00:10:41,900
later in terms of, I think why 
it's been a Hot Topic. 

196
00:10:41,900 --> 00:10:45,800
As of late is partly the shift 
to remote and hybrid working 

197
00:10:45,800 --> 00:10:48,200
models. 
So the whole world changed and 

198
00:10:48,200 --> 00:10:51,200
Business Leaders naturally. 
Wanted to understand how has 

199
00:10:51,200 --> 00:10:54,500
this changed our capacity as an 
engineering organization. 

200
00:10:55,000 --> 00:10:58,600
I think it's also that software 
is just becoming such a more and

201
00:10:58,600 --> 00:11:00,800
more important part of every 
business. 

202
00:11:01,200 --> 00:11:04,100
It's not see. 
As a cost center as much as a 

203
00:11:04,100 --> 00:11:07,300
really, the lifeblood of every 
organization is the key to 

204
00:11:07,300 --> 00:11:09,700
success is innovation and 
technology. 

205
00:11:09,700 --> 00:11:13,100
And so, I think as more 
companies realize that and the 

206
00:11:13,100 --> 00:11:16,000
job market, the market for 
talent has become more and more 

207
00:11:16,000 --> 00:11:19,400
competitive, it's just created 
more pressure overall in the 

208
00:11:19,400 --> 00:11:24,200
whole system to understand how 
well you're doing as an 

209
00:11:24,200 --> 00:11:26,000
organization or even as an 
individual. 

210
00:11:26,000 --> 00:11:29,400
So that's my perspective. 
I mean, we have been talking 

211
00:11:29,400 --> 00:11:32,400
from the engineering leaders 
point of view we want to have X,

212
00:11:32,400 --> 00:11:35,700
we want to have measurement. 
We want to know how features get

213
00:11:35,700 --> 00:11:38,500
delivered and that's impact the 
business performance so to 

214
00:11:38,500 --> 00:11:40,700
speak. 
But what will be some of the 

215
00:11:40,700 --> 00:11:44,400
impacts may be for developers 
Engineers or the software teams 

216
00:11:44,400 --> 00:11:48,400
themselves if they actually put 
more, focus on, improving their 

217
00:11:48,400 --> 00:11:51,000
developer experience? 
So maybe you can share a little 

218
00:11:51,000 --> 00:11:53,700
bit on this. 
I think everyone in any 

219
00:11:53,700 --> 00:11:57,300
profession and any trade you 
want to feel like you're good at

220
00:11:57,300 --> 00:12:00,900
what you do, you want to feel 
Mastery over your craft and I 

221
00:12:00,908 --> 00:12:03,700
think that's true. 
Much trip software developers. 

222
00:12:03,700 --> 00:12:07,000
It's very much a craft there's 
very much a lifelong pursuit of 

223
00:12:07,000 --> 00:12:10,900
Mastery in it that almost every 
professional developer sort of 

224
00:12:10,900 --> 00:12:14,600
embodies in terms of developer 
experience developer 

225
00:12:14,600 --> 00:12:17,300
productivity and measurement 
today. 

226
00:12:17,300 --> 00:12:19,600
It's not so much about 
measurement. 

227
00:12:19,600 --> 00:12:23,400
I think for a team as just about
working in more effective ways, 

228
00:12:23,800 --> 00:12:26,500
I think just as much as 
measurement has been kind of a 

229
00:12:26,500 --> 00:12:30,600
mystery and Elusive problem for 
software organizations, how to 

230
00:12:30,600 --> 00:12:33,900
actually be good has also Then 
sort of elusive, right? 

231
00:12:34,000 --> 00:12:36,300
Software organizations are 
constantly trying to figure out 

232
00:12:36,300 --> 00:12:39,500
what technology should we use? 
How should we organize our 

233
00:12:39,500 --> 00:12:42,000
team's? 
What kind of processes should we

234
00:12:42,000 --> 00:12:45,000
use to deliver software? 
Should we do scrum? 

235
00:12:45,000 --> 00:12:48,300
Should we do save, should we not
do any of those things teams? 

236
00:12:48,300 --> 00:12:52,200
Apologies microservices, it's 
just always changing. 

237
00:12:52,500 --> 00:12:57,800
And so, to boil this down for a 
team developer experience is one

238
00:12:57,800 --> 00:13:02,100
approach to thinking about 
engineering excellence and Max 

239
00:13:02,300 --> 00:13:05,400
Rising and cheering performance.
And developer experience is 

240
00:13:05,400 --> 00:13:08,900
really about focusing on the 
day-to-day experience of 

241
00:13:08,900 --> 00:13:11,800
delivering software on a team. 
Understanding. 

242
00:13:11,900 --> 00:13:15,300
What is getting in the way one 
of the biggest constraints and 

243
00:13:15,300 --> 00:13:19,200
bottlenecks and frustrations in 
that process and improving those

244
00:13:19,300 --> 00:13:23,100
to increase the capacity and 
performance of individuals, and 

245
00:13:23,100 --> 00:13:26,400
the team as a whole. 
So that is really what developer

246
00:13:26,400 --> 00:13:29,300
experiences about from the 
standpoint of an individual 

247
00:13:29,300 --> 00:13:32,100
team. 
And if I'm not mistaken there, 

248
00:13:32,100 --> 00:13:35,200
so many terms in the industry, 
referring to the same, almost 

249
00:13:35,200 --> 00:13:37,400
the same thing, I guess, but not
really the same. 

250
00:13:37,400 --> 00:13:40,300
So develop experienced 
developer, productivity team, 

251
00:13:40,600 --> 00:13:41,900
maybe you can share a little bit
more. 

252
00:13:41,900 --> 00:13:45,000
What summer for the companies do
to solve this problem. 

253
00:13:45,800 --> 00:13:47,800
That's really interesting. 
This is something. 

254
00:13:47,800 --> 00:13:51,300
I've been focusing a lot on 
through my own podcast and 

255
00:13:51,300 --> 00:13:56,000
research and talking to leaders 
across the industry for many 

256
00:13:56,000 --> 00:13:59,100
years. 
Organizations have stood up 

257
00:13:59,100 --> 00:14:02,500
special teams or Herbs with then
the organization that are 

258
00:14:02,500 --> 00:14:05,300
devoted to making the rest of 
the organization? 

259
00:14:05,300 --> 00:14:09,000
More excellent. 
And in fact, one of the, I think

260
00:14:09,300 --> 00:14:11,600
slightly did it. 
I should say names for these 

261
00:14:11,600 --> 00:14:14,400
teams are engineering, 
Excellence groups, engineering 

262
00:14:14,400 --> 00:14:17,200
Excellence teams. 
But when you look, broadly 

263
00:14:17,200 --> 00:14:21,000
across the industry, you see, a 
lot of different flavors of this

264
00:14:21,000 --> 00:14:23,900
type of work happening. 
I think, if you had to give it 

265
00:14:23,900 --> 00:14:27,900
one label across the industry, I
would call it enablement. 

266
00:14:28,200 --> 00:14:32,000
These are teams. 
Cartman's whose responsibility 

267
00:14:32,000 --> 00:14:34,800
is to enable teams and 
developers across the rest of 

268
00:14:34,808 --> 00:14:38,000
the organization to be more 
effective and more successful. 

269
00:14:38,300 --> 00:14:41,100
So when you look at the industry
today, I'll just list them off. 

270
00:14:41,100 --> 00:14:45,500
You'll see platform teams 
infrastructure, teams developer 

271
00:14:45,500 --> 00:14:49,100
productivity, teams developer 
experience, teams, engineering 

272
00:14:49,100 --> 00:14:52,800
Excellence, teams software, 
delivery life, cycle teams, 

273
00:14:53,000 --> 00:14:56,000
engineering, enablement teams. 
Forgot that one the list kind of

274
00:14:56,000 --> 00:14:59,100
goes on. 
And what they, all share is 

275
00:14:59,100 --> 00:15:03,700
roughly the same Charter. 
They all exist to help. 

276
00:15:03,700 --> 00:15:06,800
They all Focus inward. 
They're not external customer 

277
00:15:06,800 --> 00:15:11,100
facing their inward facing and 
they focus on helping 

278
00:15:11,100 --> 00:15:13,500
development teams. 
Be more effective. 

279
00:15:13,500 --> 00:15:16,800
Saving them time, helping them 
adopt better practices 

280
00:15:17,100 --> 00:15:20,600
supporting them in specific 
areas of their features or 

281
00:15:20,600 --> 00:15:25,500
products that they need support 
in the ways in which these 

282
00:15:25,500 --> 00:15:28,200
different types of teams. 
I described accomplish, that 

283
00:15:28,200 --> 00:15:30,500
goal are a little bit different.
Here and there. 

284
00:15:30,500 --> 00:15:34,200
But if you had to kind of take a
10,000-foot view on it, I would 

285
00:15:34,200 --> 00:15:38,200
say some of the teams tend to be
more process and culture 

286
00:15:38,200 --> 00:15:40,800
focused. 
Whereas some teams are more 

287
00:15:40,800 --> 00:15:45,200
tools and Tech focused and then 
others are sort of just a blend 

288
00:15:45,200 --> 00:15:47,200
of both to bring this full 
circle. 

289
00:15:47,200 --> 00:15:52,300
Developer experience, teams are,
I think the newest kind of 

290
00:15:52,300 --> 00:15:56,500
evolution of these enablement 
teams developer experience teams

291
00:15:56,500 --> 00:16:00,700
have really been born out of 
platform and developer. 30 teams

292
00:16:00,700 --> 00:16:04,500
that were traditionally very 
focused on internal, tooling 

293
00:16:04,500 --> 00:16:08,300
particularly around builds and 
tests the way in which developer

294
00:16:08,300 --> 00:16:11,300
experience teams are different 
or that instead of just being 

295
00:16:11,300 --> 00:16:14,800
responsible for a few tools that
developer use, they're 

296
00:16:14,800 --> 00:16:17,100
responsible for looking at the 
developer experience 

297
00:16:17,100 --> 00:16:20,500
holistically across all the 
different tools they use. 

298
00:16:20,500 --> 00:16:23,100
Because in fact, that's where a 
lot of the friction is between 

299
00:16:23,100 --> 00:16:25,500
the different tools, not within 
each of the individual tools. 

300
00:16:25,500 --> 00:16:29,000
So looking at the developer 
experience holistically and 

301
00:16:29,000 --> 00:16:33,000
finding ways to improve, Prove 
that not only through technology

302
00:16:33,000 --> 00:16:37,800
and tools, but also through Best
Practices, cultural changes even

303
00:16:37,800 --> 00:16:42,100
organizational changes. 
So if I also can share, when I 

304
00:16:42,100 --> 00:16:45,500
read your, get the ex white 
paper, there are certain impacts

305
00:16:45,500 --> 00:16:49,500
that organizations can get when 
they invest a lot more in this 

306
00:16:49,500 --> 00:16:51,300
developer experience. 
So things like of course 

307
00:16:51,300 --> 00:16:55,300
efficiency developer gets more 
productive and more velocity, so

308
00:16:55,300 --> 00:16:57,700
to speak. 
And then also Engineers 

309
00:16:57,700 --> 00:17:01,600
attrition thing if you probably 
work, Company that has so bad. 

310
00:17:01,600 --> 00:17:04,099
Developed Express. 
I guess Engineers would probably

311
00:17:04,099 --> 00:17:07,200
find another place to work at 
and of course, the satisfaction 

312
00:17:07,200 --> 00:17:09,900
working there at the end of the 
day is always about business 

313
00:17:09,900 --> 00:17:12,500
performance, right? 
If the engineers are productive,

314
00:17:12,500 --> 00:17:15,099
of course, you will drive 
business performance as well. 

315
00:17:15,099 --> 00:17:17,900
So you mentioned in the 
beginning about different ways, 

316
00:17:17,900 --> 00:17:21,400
traditional companies, use to 
measure their productivity lines

317
00:17:21,400 --> 00:17:26,300
of code number PR, maybe prh 
number of box number of 

318
00:17:26,300 --> 00:17:30,000
features, ship software, 
velocity, so maybe tell us more 

319
00:17:30,200 --> 00:17:34,000
What are some of the problems if
we try to measure productivity 

320
00:17:34,000 --> 00:17:36,600
by using this traditional 
metrics and maybe they are other

321
00:17:36,600 --> 00:17:38,700
more traditional metrics that 
you can share as well. 

322
00:17:39,600 --> 00:17:42,000
Yeah. 
So for quote unquote traditional

323
00:17:42,000 --> 00:17:46,400
Matrix or metrics that are I 
think most commonly misused 

324
00:17:46,400 --> 00:17:49,800
would be really anything that 
revolves around like counting 

325
00:17:49,800 --> 00:17:52,500
widgets of what programmers 
produce. 

326
00:17:52,800 --> 00:17:57,500
I use the term widgets because 
the flaw is in the way leaders 

327
00:17:57,500 --> 00:18:00,900
view software development as 
something that produces Widgets 

328
00:18:01,200 --> 00:18:05,000
in other words, they do it as a 
sort of factory assembly line. 

329
00:18:05,300 --> 00:18:07,600
And as a side note, what's 
really interesting is a lot of 

330
00:18:07,600 --> 00:18:10,700
the most popular software 
engineering metrics like cycle 

331
00:18:10,700 --> 00:18:14,600
time, for example or lead time. 
Actually those have been used in

332
00:18:14,600 --> 00:18:18,000
manufacturing for many more 
decades and they've been used in

333
00:18:18,000 --> 00:18:20,400
software development. 
So it's interesting that our 

334
00:18:20,400 --> 00:18:24,200
discipline has adopted these 
manufacturing metrics when 

335
00:18:24,200 --> 00:18:26,800
anyone who's built sulfur 
understands that it's not a 

336
00:18:26,808 --> 00:18:29,000
repetitive assembly line sort of
process, right? 

337
00:18:29,000 --> 00:18:32,700
It's a creative process. 
Is so going back to kind of what

338
00:18:32,700 --> 00:18:35,700
the problematic metrics are. 
So things like lines of code. 

339
00:18:35,800 --> 00:18:38,300
Number of pull requests velocity
points. 

340
00:18:38,300 --> 00:18:42,300
Those are probably the most 
notorious metrics velocity 

341
00:18:42,300 --> 00:18:45,900
points, which really is about 
counting the number of agile 

342
00:18:45,900 --> 00:18:49,100
points that come from sort of 
agile, ceremony of assigning 

343
00:18:49,100 --> 00:18:51,000
points in the estimation 
process. 

344
00:18:51,400 --> 00:18:56,300
Suffers a really, really harmful
problem in that agile estimation

345
00:18:56,300 --> 00:18:59,700
points are tool for estimation, 
and therefore, you're measuring 

346
00:18:59,700 --> 00:19:03,300
your Asian based on how much 
work they completed based off of

347
00:19:03,300 --> 00:19:07,100
the estimates, which may or may 
not be what actually occurred in

348
00:19:07,100 --> 00:19:09,200
actuality. 
That's not even the worst part. 

349
00:19:09,200 --> 00:19:14,000
The worst part is that by 
incentivizing teams to be sort 

350
00:19:14,000 --> 00:19:17,500
of graded, based on their 
velocity points, you're actually

351
00:19:17,500 --> 00:19:20,700
incentivizing them to inflate 
their estimates. 

352
00:19:20,700 --> 00:19:24,700
And so you actually in this 
process, completely ruin the 

353
00:19:24,700 --> 00:19:28,000
actual purpose of velocity 
points in the first place, which

354
00:19:28,000 --> 00:19:34,000
is to provide a And useful way 
to gauge the capacity and 

355
00:19:34,000 --> 00:19:37,800
forecasts of delivery for an 
organization lines of code. 

356
00:19:37,800 --> 00:19:41,000
I mean we joked about it earlier
but again anyone who's written 

357
00:19:41,000 --> 00:19:43,700
software understands that 
writing more code, is that 

358
00:19:43,700 --> 00:19:45,800
better? 
So therein lies. 

359
00:19:45,800 --> 00:19:48,400
The critical flaw with using 
lines of code. 

360
00:19:48,600 --> 00:19:52,100
But in a more nuanced way, it 
just doesn't really make sense 

361
00:19:52,100 --> 00:19:54,900
because as any software 
developer knows depending on the

362
00:19:54,900 --> 00:19:58,200
programming language, you might 
write more or less lines of code

363
00:19:58,200 --> 00:20:01,600
just based on the syntax. 
It's funny, I've actually talked

364
00:20:01,600 --> 00:20:04,800
to organizations recently who 
joke and say they're actually 

365
00:20:04,800 --> 00:20:08,300
incentivizing people to delete 
code that add code. 

366
00:20:08,400 --> 00:20:11,200
We want less code AS software 
developers and organizations, 

367
00:20:11,200 --> 00:20:13,900
like all code is just tapped at 
waiting a happen. 

368
00:20:14,100 --> 00:20:17,800
We want lesko not more. 
So, incentivizing lines of code 

369
00:20:17,800 --> 00:20:21,500
just creates a completely 
perverse incentive to actually 

370
00:20:21,500 --> 00:20:25,100
write poor quality software and 
on maintainable code. 

371
00:20:25,400 --> 00:20:28,500
So, those are some examples of 
problems with what I would call 

372
00:20:28,500 --> 00:20:31,400
the traditional. 
Estate developer productivity 

373
00:20:31,400 --> 00:20:32,700
metrics. 
And this has been talked about 

374
00:20:32,700 --> 00:20:34,700
for decades. 
I mean, there's a Martin Fowler 

375
00:20:34,700 --> 00:20:37,400
article called cannot measure 
productivity. 

376
00:20:37,500 --> 00:20:41,800
I think it's from my 2002 where 
he talks about wine zip code and

377
00:20:41,900 --> 00:20:44,700
how leaders just keep using it 
even though it doesn't work. 

378
00:20:44,700 --> 00:20:48,000
So developers have been telling 
leaders that these metrics don't

379
00:20:48,000 --> 00:20:51,000
work for a long time. 
Unfortunately that still hasn't 

380
00:20:51,000 --> 00:20:53,600
stopped a lot of companies and 
businesses from at least 

381
00:20:53,600 --> 00:20:57,200
attempting to use them. 
So, I guess, one of the common 

382
00:20:57,200 --> 00:21:00,600
challenges, why companies still 
using those numbers is because 

383
00:21:00,600 --> 00:21:04,200
probably is hard to get the 
quantifiable measurement, right?

384
00:21:04,400 --> 00:21:08,000
So mostly at maybe anecdotal or 
perception within the company, 

385
00:21:08,200 --> 00:21:11,400
I'll build a slow, I'll build 
socks, or our environment is 

386
00:21:11,400 --> 00:21:13,800
bad, but nobody really 
quantifies that. 

387
00:21:13,800 --> 00:21:15,300
So I guess it's really hard for 
me. 

388
00:21:15,300 --> 00:21:18,700
That's probably to choose those 
numbers, but I guess lately 

389
00:21:18,700 --> 00:21:22,200
there are so many research done 
around these topics, or maybe 

390
00:21:22,200 --> 00:21:25,100
previously was there as well, 
but it was just not popular. 

391
00:21:25,700 --> 00:21:28,800
So there are few things that I 
can picked up from the industry 

392
00:21:28,800 --> 00:21:32,300
versus about Dora state of 
devops report or Dora reports. 

393
00:21:32,300 --> 00:21:35,300
Some people call it and also 
space from Microsoft. 

394
00:21:35,700 --> 00:21:38,800
So tell us more about these two 
popular research. 

395
00:21:38,900 --> 00:21:42,500
And what is your thoughts about 
using some kind of research 

396
00:21:42,500 --> 00:21:44,600
based approach to measure 
productivity? 

397
00:21:45,400 --> 00:21:48,600
Well, first of all, I think we 
all need to be looking more to 

398
00:21:48,600 --> 00:21:51,400
research for answers to this 
problem because it's so 

399
00:21:51,400 --> 00:21:53,700
difficult. 
Not only is it so difficult. 

400
00:21:53,700 --> 00:21:55,100
There's a lot of non-research 
out. 

401
00:21:55,800 --> 00:21:59,200
So many vendors selling their 
magic metric for developer 

402
00:21:59,200 --> 00:22:02,900
productivity, so many leaders 
choosing and adopting 

403
00:22:02,900 --> 00:22:05,300
ill-advised metrics with 
organizations that harm their 

404
00:22:05,300 --> 00:22:08,800
organization. 
So we all really need to be more

405
00:22:08,900 --> 00:22:13,800
prudent and how we think about 
this problem and Leverage The 

406
00:22:13,800 --> 00:22:16,100
Wonderful research that's come 
on in the last few years. 

407
00:22:16,600 --> 00:22:20,900
I'm a huge fan of both Dora, the
book accelerate and the space 

408
00:22:20,900 --> 00:22:24,000
framework I work with Margaret 
and story who is one of the 

409
00:22:24,000 --> 00:22:27,000
authors of space and the Cole, 
Force, grin, another author of 

410
00:22:27,000 --> 00:22:29,400
space, and of course, the she 
was the chief scientist and 

411
00:22:29,400 --> 00:22:31,700
researcher and author of 
accelerate. 

412
00:22:31,800 --> 00:22:36,600
And the founder of Dora, Dora 
was a Monumental step forward 

413
00:22:36,600 --> 00:22:40,900
for the industry. 
Because what dora proves was 

414
00:22:40,900 --> 00:22:44,300
that engineering performance 
software delivery performance 

415
00:22:44,700 --> 00:22:47,600
actually helps business. 
And this goes back to the 

416
00:22:47,608 --> 00:22:51,000
earlier point I made about how 
in the past software development

417
00:22:51,000 --> 00:22:54,100
was seen as a cost center, how 
much are we spending on I.T? 

418
00:22:54,400 --> 00:22:56,700
Whereas today, we I know that 
all the biggest and most 

419
00:22:56,700 --> 00:22:59,000
successful companies in the 
world are really technology 

420
00:22:59,000 --> 00:23:02,600
companies. 
And so accelerate above all 

421
00:23:02,600 --> 00:23:08,000
Wiles prove that using real 
rigorous statistical research 

422
00:23:08,400 --> 00:23:12,000
one of their findings was also 
that there were these four key 

423
00:23:12,000 --> 00:23:15,700
metrics which made up the 
construct, which they called 

424
00:23:15,700 --> 00:23:19,400
software delivery performance 
which correlated highly or 

425
00:23:19,400 --> 00:23:23,300
predicted business performance, 
those four metrics of course 

426
00:23:23,300 --> 00:23:26,900
have sort of taken a life of 
Their Own That Nicole and other 

427
00:23:26,900 --> 00:23:30,000
authors of the book, never 
anticipated or intended, we can 

428
00:23:30,000 --> 00:23:33,000
maybe come back to the Merit of 
those four metrics. 

429
00:23:33,000 --> 00:23:37,700
But in terms of using them in an
organization, the science behind

430
00:23:37,800 --> 00:23:42,300
what those metrics correlate to 
Across the industry is real and 

431
00:23:42,500 --> 00:23:46,400
Google continues to produce the 
annual report examining those 

432
00:23:46,400 --> 00:23:48,600
four metrics and stats across 
the industry. 

433
00:23:48,600 --> 00:23:54,400
To this day space, which is much
more recent was about developer 

434
00:23:54,400 --> 00:23:56,700
productivity. 
Which is very different 

435
00:23:56,700 --> 00:23:59,900
accelerate was around software 
delivery performance, which is 

436
00:23:59,900 --> 00:24:03,100
not developer productivity. 
That's why Nicole wrote space 

437
00:24:03,100 --> 00:24:05,400
because it was a different 
problem to be solved. 

438
00:24:05,600 --> 00:24:10,800
I love space, I love the premise
and the findings and advice to 

439
00:24:10,800 --> 00:24:14,100
practitioners and leaders that 
are embodied in space. 

440
00:24:14,500 --> 00:24:19,000
And I think the biggest shift 
that space has made in the 

441
00:24:19,000 --> 00:24:23,700
industry as that leaders are 
finally, realizing that 

442
00:24:23,800 --> 00:24:27,200
developer productivity. 
Is more than just counting, 

443
00:24:27,200 --> 00:24:30,600
widgets space talks about how 
there's five different 

444
00:24:30,600 --> 00:24:32,700
dimensions of developer 
productivity and that a 

445
00:24:32,700 --> 00:24:36,700
developers day is complex and 
multifaceted and it's not just 

446
00:24:36,700 --> 00:24:39,700
about cranking out code, it's 
about collaborating with peers 

447
00:24:39,700 --> 00:24:44,200
and reviewing code and planning 
designing features and even 

448
00:24:44,200 --> 00:24:48,200
talking to customers. 
And so space really put forth 

449
00:24:48,200 --> 00:24:51,600
the idea that developer 
productivity is complex and to 

450
00:24:51,600 --> 00:24:55,100
understand measure or improve 
developer productivity. 

451
00:24:55,300 --> 00:24:57,900
Need to be looking at it from 
different angles. 

452
00:24:58,500 --> 00:25:01,900
And so, you've seen 
organizations try to implement 

453
00:25:01,900 --> 00:25:06,400
these things, both Dora and 
space and I think that kind of 

454
00:25:06,400 --> 00:25:11,900
brings us along to my work today
which is space and door really 

455
00:25:12,100 --> 00:25:16,700
help the industry think about 
software rendering performance 

456
00:25:16,700 --> 00:25:18,700
and developer productivity in 
the right ways. 

457
00:25:18,700 --> 00:25:21,700
But I think there's still been a
real challenge with. 

458
00:25:21,800 --> 00:25:23,200
Okay what do we actually 
measure? 

459
00:25:23,700 --> 00:25:25,500
How do we measure doormats? 
Works. 

460
00:25:25,700 --> 00:25:27,900
Now that we have the door 
metrics, what do we do with 

461
00:25:27,900 --> 00:25:30,800
them? 
How do we measure space metrics?

462
00:25:30,800 --> 00:25:34,200
What does that mean? 
That's really the work that me 

463
00:25:34,200 --> 00:25:38,200
as well as Nicole and Margaret 
and story are doing today, is it

464
00:25:38,200 --> 00:25:40,300
really Builds on the work that 
they've done. 

465
00:25:40,300 --> 00:25:44,000
It builds under a Builds on 
space but what we're trying to 

466
00:25:44,000 --> 00:25:49,000
do is kind of bring that into a 
more applicable set of 

467
00:25:49,000 --> 00:25:51,800
Frameworks and tools and 
Concepts to really help 

468
00:25:51,800 --> 00:25:55,000
organizations, actually, apply 
this both measure. 

469
00:25:55,200 --> 00:25:59,300
Improve developer productivity, 
using a set of practices and 

470
00:25:59,300 --> 00:26:02,500
measures that work. 
Thanks for sharing this in 

471
00:26:02,500 --> 00:26:05,700
details because yeah, Dora took 
the industry by storm. 

472
00:26:05,700 --> 00:26:08,700
I read the accelerate book as 
well as really good for those 

473
00:26:08,700 --> 00:26:12,100
who haven't read it, please go 
and check it out and space which

474
00:26:12,100 --> 00:26:14,500
came in the last, maybe, three 
years or four years. 

475
00:26:14,500 --> 00:26:17,000
He was also quite revolutionary 
before. 

476
00:26:17,000 --> 00:26:20,400
People were talking about the 
four key metrics from Dora but 

477
00:26:20,400 --> 00:26:23,600
hey yeah that's another angle of
developer productivity 

478
00:26:23,600 --> 00:26:26,100
satisfaction and things like 
that that maybe we should not 

479
00:26:26,100 --> 00:26:29,100
neglect as well because that 
also improves the software 

480
00:26:29,100 --> 00:26:32,300
development performance at the 
end of the day, I was so excited

481
00:26:32,300 --> 00:26:34,200
when I saw that dr. 
Nicole and dr. 

482
00:26:34,200 --> 00:26:37,300
Margaret and was also part of 
your company, they are probably 

483
00:26:37,300 --> 00:26:41,600
the researchers in your company 
and hence comes with the DX 

484
00:26:41,700 --> 00:26:44,900
unique way of measuring this 
developer performance and 

485
00:26:44,900 --> 00:26:47,700
develop experience. 
So maybe now it's time to tell 

486
00:26:47,700 --> 00:26:51,300
us more how exactly the X 
actually do the measurement. 

487
00:26:51,300 --> 00:26:54,000
I know that you have the x k pi 
numbers, right? 

488
00:26:54,000 --> 00:26:56,400
And also top drivers that you 
measure. 

489
00:26:56,700 --> 00:26:59,400
So tell us more about all these 
kind of measurement that the 

490
00:26:59,400 --> 00:27:02,700
acts differently I think 
important to start with the 

491
00:27:02,700 --> 00:27:05,900
philosophy of what we're doing 
because one of the things that's

492
00:27:05,900 --> 00:27:09,100
been a little lost and all the 
conversation around metrics all 

493
00:27:09,100 --> 00:27:11,000
the time is what are we trying 
to measure? 

494
00:27:11,000 --> 00:27:13,200
What are we trying to improve 
again? 

495
00:27:13,200 --> 00:27:17,200
When you look at some of those 
old notorious metrics like lines

496
00:27:17,200 --> 00:27:20,000
of code or even things like 
cycle time, it's all about 

497
00:27:20,008 --> 00:27:24,000
looking at your software 
developers from the top down and

498
00:27:24,000 --> 00:27:27,700
observing what they're doing and
then making an assessment of 

499
00:27:27,700 --> 00:27:32,200
whether that is good or bad that
doesn't actually Improve things.

500
00:27:32,400 --> 00:27:35,400
And it actually doesn't even 
tell you if anything's wrong, or

501
00:27:35,400 --> 00:27:37,100
if something is wrong, what it 
is. 

502
00:27:37,600 --> 00:27:41,600
And so, the philosophy behind 
developer experience is that, we

503
00:27:41,600 --> 00:27:45,400
believe that the developer 
experience which we talked about

504
00:27:45,400 --> 00:27:47,600
earlier. 
Meaning, the day-to-day friction

505
00:27:47,600 --> 00:27:51,200
that developers encounter the 
things that make them stuck, the

506
00:27:51,200 --> 00:27:53,900
things that make them 
frustrated, the obstacles that 

507
00:27:53,900 --> 00:27:56,600
get in the way, from them 
shipping and being able to 

508
00:27:56,600 --> 00:27:59,100
deliver things that customers as
quickly as possible 

509
00:27:59,400 --> 00:28:03,000
understanding. 
Identifying and improving those 

510
00:28:03,000 --> 00:28:05,300
things is the key to 
productivity. 

511
00:28:05,400 --> 00:28:08,100
So that's the philosophy of what
we're doing and so when we talk 

512
00:28:08,100 --> 00:28:11,400
about what do we measure? 
It's all around. 

513
00:28:11,400 --> 00:28:14,300
How do we identify? 
How do we measure that friction?

514
00:28:14,300 --> 00:28:17,300
How do we understand where the 
friction in the organization 

515
00:28:17,300 --> 00:28:20,200
exists? 
How do we know if that friction 

516
00:28:20,200 --> 00:28:23,200
is good or bad? 
Meaning compare it against 

517
00:28:23,200 --> 00:28:26,900
industry benchmarks understand? 
Is this process slower or faster

518
00:28:26,900 --> 00:28:30,500
than other organizations are 
high performing organizations is

519
00:28:30,500 --> 00:28:34,900
this A typical or is it a sign 
of a bottleneck in our process 

520
00:28:35,400 --> 00:28:37,500
with DX? 
It's a little bit of a 

521
00:28:37,508 --> 00:28:40,300
long-winded response to get into
kind of what we measure. 

522
00:28:40,700 --> 00:28:44,100
But in principle what we do is 
we look at the developer 

523
00:28:44,100 --> 00:28:46,700
experience as a whole and we 
publish the paper that's on our 

524
00:28:46,700 --> 00:28:48,600
website. 
That was our first peer-reviewed

525
00:28:48,600 --> 00:28:51,400
paper on what actually is 
developer experience and what is

526
00:28:51,400 --> 00:28:53,800
it made up of. 
So what we do at DX is we 

527
00:28:53,800 --> 00:28:58,200
identify what are the top 
drivers of developer experience.

528
00:28:58,400 --> 00:29:00,900
What are the things in the 
day-to-day experience? 

529
00:29:01,000 --> 00:29:04,200
It's that most affect 
developers, things like slow, 

530
00:29:04,200 --> 00:29:09,200
tests, or nasty code or poor 
requirements on the task. 

531
00:29:09,200 --> 00:29:13,600
They're working on or delays in 
handoffs between developers or 

532
00:29:13,700 --> 00:29:17,300
difficulty building their code, 
deploying their code, releasing 

533
00:29:17,300 --> 00:29:20,300
their code or just slow feedback
loops in terms of getting peer 

534
00:29:20,300 --> 00:29:23,100
review or getting feedback, even
from customers. 

535
00:29:23,500 --> 00:29:26,600
So we constantly are looking at.
Okay, what are the top things 

536
00:29:26,700 --> 00:29:28,900
crossing the street that affect 
organizations? 

537
00:29:28,900 --> 00:29:30,900
The most, I don't, we measure 
them. 

538
00:29:31,200 --> 00:29:34,300
With a multi-faceted approach. 
So we look at really three 

539
00:29:34,300 --> 00:29:38,600
dimensions, we look at first of 
all, the subjective experience. 

540
00:29:38,600 --> 00:29:41,400
Meaning, what's developers 
attitudes towards these things? 

541
00:29:41,600 --> 00:29:43,900
Are they satisfied with their 
tools? 

542
00:29:44,200 --> 00:29:47,300
Are they happy with the code 
review experience? 

543
00:29:47,600 --> 00:29:50,300
Do they have an easy time 
deploying code? 

544
00:29:50,300 --> 00:29:53,200
Or is it really difficult in 
addition to those subjective 

545
00:29:53,200 --> 00:29:56,100
measures? 
We also look at objective 

546
00:29:56,100 --> 00:29:59,600
measure, so we look at OK 
developers, feel like it's 

547
00:29:59,600 --> 00:30:01,500
difficult to release. 
Things. 

548
00:30:02,000 --> 00:30:04,700
How many steps does it take? 
How long does it take them to 

549
00:30:04,700 --> 00:30:08,900
deploy or developers are 
unsatisfied with the card review

550
00:30:08,900 --> 00:30:11,100
process? 
How long do they typically wait 

551
00:30:11,100 --> 00:30:13,700
to get a code review? 
How difficult is it to review 

552
00:30:13,700 --> 00:30:17,100
other people's work? 
So we combine subjective and 

553
00:30:17,100 --> 00:30:18,800
objective. 
In the last Dimension, we 

554
00:30:18,800 --> 00:30:22,400
measure is around importance 
because something can be really 

555
00:30:22,400 --> 00:30:26,100
bad, but unimportant because you
don't experience it frequently, 

556
00:30:26,400 --> 00:30:29,500
vice versa a really small. 
I like the analogy like Pebble 

557
00:30:29,500 --> 00:30:33,000
in your shoe, something really. 
All that's really, not that bad.

558
00:30:33,000 --> 00:30:35,500
But you experience at every 
single day, could be really 

559
00:30:35,500 --> 00:30:38,700
important. 
So we really look at those three

560
00:30:38,700 --> 00:30:40,800
dimensions. 
I like to call it a Triad of 

561
00:30:40,800 --> 00:30:43,300
developer experience. 
Well really, you can measure 

562
00:30:43,300 --> 00:30:46,900
those things in a number of 
ways, a combination of surveys 

563
00:30:46,900 --> 00:30:50,600
as well as helping customers 
instrument their systems to get 

564
00:30:50,600 --> 00:30:53,500
some of that data. 
In real time, we bring that all 

565
00:30:53,500 --> 00:30:57,600
together to customers and help 
them make decisions on where to 

566
00:30:57,600 --> 00:31:00,200
actually invest to improve their
organizations. 

567
00:31:00,600 --> 00:31:04,600
Those Ittle bit long-winded, but
in the gist, that is how we 

568
00:31:04,700 --> 00:31:08,100
think about improving developer 
productivity and how we approach

569
00:31:08,100 --> 00:31:10,500
measurement around developer 
experience. 

570
00:31:11,300 --> 00:31:13,800
Thanks for sharing and details, 
actually, it really gives the 

571
00:31:13,800 --> 00:31:17,100
listeners more concrete ideas of
how the ex works. 

572
00:31:17,500 --> 00:31:19,700
And apparently I also have given
it a try. 

573
00:31:20,100 --> 00:31:23,600
So the way it works like you 
asked developers through surveys

574
00:31:23,700 --> 00:31:27,000
and then they will provide 
answers these three dimensions, 

575
00:31:27,000 --> 00:31:29,700
like the subjective experience 
the perception. 

576
00:31:29,900 --> 00:31:33,200
And then the objective for How 
many probably days, it takes you

577
00:31:33,200 --> 00:31:36,200
to finish a task, for example, 
and you have both subjective and

578
00:31:36,200 --> 00:31:39,800
objective measurement and the 
other part the dimension of 

579
00:31:39,800 --> 00:31:43,400
importance is for you to choose 
after you get all these results.

580
00:31:43,700 --> 00:31:47,100
What will be your focus area? 
So the team themselves can 

581
00:31:47,100 --> 00:31:50,600
choose each team's can have 
different Focus area so to speak

582
00:31:50,800 --> 00:31:54,500
from there you will then do it 
again over the time and hence 

583
00:31:54,500 --> 00:31:57,200
creating this maybe flywheel 
effect that you keep on 

584
00:31:57,200 --> 00:32:00,000
continuing to improve the 
developer experience in 

585
00:32:00,000 --> 00:32:03,000
different parts of the 
Organizations and I just want to

586
00:32:03,000 --> 00:32:07,500
highlight also this DX kpi's. 
So all these top drivers and all

587
00:32:07,500 --> 00:32:11,100
these results, actually, the ex 
tries to come up with much more 

588
00:32:11,100 --> 00:32:13,000
like four key metrics Endora, 
right? 

589
00:32:13,000 --> 00:32:16,800
Like for KBS from the X which 
are engagement, productivity, 

590
00:32:17,000 --> 00:32:20,900
effort to deliver and time loss,
it seems like different from 

591
00:32:20,900 --> 00:32:23,500
Dora or space. 
So tell us more about these 

592
00:32:23,500 --> 00:32:27,000
kpis. 
Yeah, great question with 

593
00:32:27,000 --> 00:32:30,800
developer experience, it's about
what a kpi is like Nordstrom at 

594
00:32:31,300 --> 00:32:34,000
It's about what is the goal of 
all this. 

595
00:32:34,300 --> 00:32:36,100
So, when you take a step back 
and look at an engineering 

596
00:32:36,100 --> 00:32:38,500
organization, and you're talking
about productivity, you're 

597
00:32:38,500 --> 00:32:40,100
talking about developer 
experience. 

598
00:32:40,600 --> 00:32:44,600
What's the goal of all of that? 
And that's what the dxk apis 

599
00:32:44,600 --> 00:32:46,500
are. 
So, as you mentioned, if your 

600
00:32:46,500 --> 00:32:50,400
developers are really productive
and your processes are really 

601
00:32:50,400 --> 00:32:54,700
efficient those map, those 
dried, those predict or 

602
00:32:54,700 --> 00:32:58,300
correlate to better performance 
across the kpis. 

603
00:32:58,300 --> 00:33:02,500
So developer engagement is a 
measure Oh, Employee Engagement 

604
00:33:02,500 --> 00:33:06,200
of how energized and excited 
developers are in their work. 

605
00:33:06,400 --> 00:33:09,000
And that's such an important kpi
for businesses. 

606
00:33:09,000 --> 00:33:11,700
Because if, you know, 
developers, their actual 

607
00:33:11,700 --> 00:33:15,300
day-to-day productivity is very 
much driven by the level of 

608
00:33:15,300 --> 00:33:18,000
passion and excitement. 
They have towards what they're 

609
00:33:18,000 --> 00:33:21,600
working on receive productivity.
Looks at a slightly different 

610
00:33:21,600 --> 00:33:26,000
dimension of more cognitive and 
rational one of how productive 

611
00:33:26,000 --> 00:33:28,900
do developers self report 
themselves to be. 

612
00:33:29,300 --> 00:33:33,000
I mean, every manager will 
Developer, how productive did 

613
00:33:33,000 --> 00:33:35,700
you feel this past week? 
And that tells you a lot. 

614
00:33:35,800 --> 00:33:38,600
That's essentially what we 
surface at the organizational 

615
00:33:38,600 --> 00:33:42,500
level with that kpi effort to 
deliver really centers more 

616
00:33:42,500 --> 00:33:44,800
around tools. 
Although, it does touch on 

617
00:33:44,800 --> 00:33:47,800
practices. 
If you think about the ideal 

618
00:33:47,800 --> 00:33:50,600
software, delivery lifecycle 
from the standpoint of an 

619
00:33:50,600 --> 00:33:53,300
individual developer, you want 
it to be easy. 

620
00:33:53,500 --> 00:33:55,700
You want it to be really easy to
start. 

621
00:33:55,700 --> 00:33:58,100
On a new feature, make changes 
test. 

622
00:33:58,100 --> 00:34:00,800
Those changes may be deploy, 
those changes. 

623
00:34:00,900 --> 00:34:04,300
To another environment staging 
environment manually test them, 

624
00:34:04,400 --> 00:34:07,000
send them to your CI CD 
Pipeline, and ship it to 

625
00:34:07,008 --> 00:34:09,699
customers. 
You want that to be really easy.

626
00:34:09,699 --> 00:34:14,000
And so effort to deliver is 
around understanding the overall

627
00:34:14,000 --> 00:34:15,800
ease or difficulty of that 
process. 

628
00:34:16,400 --> 00:34:21,300
And then, lastly time loss is 
about, literally, how much time 

629
00:34:21,699 --> 00:34:25,600
is being reported to be lost due
to waste and inefficiency in the

630
00:34:25,600 --> 00:34:27,900
process. 
So it provides a way to 

631
00:34:27,900 --> 00:34:31,500
understand those bottlenecks, 
the things Going to way of 

632
00:34:31,500 --> 00:34:35,000
developers in a way that can 
actually be translated to 

633
00:34:35,199 --> 00:34:36,900
Dollars. 
And that's what's so important 

634
00:34:36,900 --> 00:34:40,800
about that last kpi whereas the 
first three are similar to 

635
00:34:40,800 --> 00:34:45,300
employee engagement and that 
their sentiment scores time loss

636
00:34:45,300 --> 00:34:50,800
is still a perceptual measure. 
However, it can be conveyed and 

637
00:34:50,800 --> 00:34:52,900
dollars that matter of the 
business. 

638
00:34:53,300 --> 00:34:57,800
And so with these pork apis, 
it's really about aligning 

639
00:34:57,800 --> 00:34:59,300
around. 
What is a good software 

640
00:34:59,300 --> 00:35:02,800
engineering organization look 
Like that's what the kpis really

641
00:35:02,800 --> 00:35:06,600
provide to businesses in terms 
of how we came up with the kpi 

642
00:35:06,600 --> 00:35:10,600
sir, actually rooted in our 
research paper, I won't go into 

643
00:35:10,600 --> 00:35:14,500
full length out how that works. 
But really one of the things we 

644
00:35:14,500 --> 00:35:17,900
know about developer experience 
or experience in general, is 

645
00:35:17,900 --> 00:35:21,000
that it's based on this concept 
in Psychology called the trilogy

646
00:35:21,000 --> 00:35:23,900
of the mind. 
And so there's really three 

647
00:35:23,900 --> 00:35:28,000
dimensions of experience, and 
three of the four kpi's. 

648
00:35:28,200 --> 00:35:30,800
So, all the kpi is except time 
loss actually map. 

649
00:35:31,000 --> 00:35:35,300
To those different dimensions of
experience in Psychology and 

650
00:35:35,300 --> 00:35:38,700
they're also useful to 
businesses with our kpis. 

651
00:35:38,800 --> 00:35:42,000
One of the things that were 
working on is understanding 

652
00:35:42,000 --> 00:35:44,700
their predictive power similar 
to what dora did. 

653
00:35:44,900 --> 00:35:48,600
So we not only believe that 
these are from a research 

654
00:35:48,600 --> 00:35:52,200
standpoint, the right, North 
Stars for organizations. 

655
00:35:52,500 --> 00:35:56,000
We also believe that these 
Northstar metrics will predict 

656
00:35:56,000 --> 00:35:58,200
and correlate With Better 
Business performance and 

657
00:35:58,200 --> 00:36:01,900
outcomes things like attrition 
Things like financial 

658
00:36:01,900 --> 00:36:05,100
performance or non commercial 
performance, and that's 

659
00:36:05,100 --> 00:36:06,800
research. 
We're still working on and hope 

660
00:36:06,800 --> 00:36:09,600
to be able to share with the 
world early next year. 

661
00:36:10,400 --> 00:36:12,400
Wow! 
Sounds really exciting. 

662
00:36:12,600 --> 00:36:16,300
I'm looking forward to another 
research to complement Dora and 

663
00:36:16,300 --> 00:36:18,300
space. 
I'm sure looking at dr. 

664
00:36:18,300 --> 00:36:21,200
Niccole's and Margaret. 
And as part of the research 

665
00:36:21,200 --> 00:36:23,600
team, I'm sure it's going to be 
revolutionary as well. 

666
00:36:23,900 --> 00:36:26,900
But for all the X users, maybe 
you get a glimpse of it since 

667
00:36:26,900 --> 00:36:29,200
you've been using it as part of 
the software itself. 

668
00:36:29,400 --> 00:36:30,800
And I think this kpi is the most
important. 

669
00:36:31,000 --> 00:36:33,200
Then for leaders, right? 
Because previously, they want to

670
00:36:33,200 --> 00:36:37,300
get numbers the targets. 
So these kpis sort of give them 

671
00:36:37,300 --> 00:36:40,700
a numbers that they can aspire 
to improve and they're just for 

672
00:36:40,900 --> 00:36:43,500
not many. 
So you can actually look at the 

673
00:36:43,500 --> 00:36:46,300
apis for leaders. 
And then for engineers, the top 

674
00:36:46,300 --> 00:36:49,300
drivers, probably the focus area
that you will improve. 

675
00:36:49,700 --> 00:36:52,700
So I'm sure all the listeners 
here who are Engineers or maybe 

676
00:36:52,700 --> 00:36:54,300
leaders. 
They are excited, they want to 

677
00:36:54,308 --> 00:36:57,200
improve developer experience but
maybe they don't know how to 

678
00:36:57,200 --> 00:37:01,400
start or maybe getting into get 
the axes one but How should 

679
00:37:01,400 --> 00:37:03,500
people build a case in a 
company? 

680
00:37:03,500 --> 00:37:07,000
Which probably haven't invested 
a lot on developer experience. 

681
00:37:07,700 --> 00:37:11,500
Yeah, so I talked to a lot of 
companies about their Journeys 

682
00:37:11,600 --> 00:37:14,500
and investing into developer 
experience. 

683
00:37:14,500 --> 00:37:16,600
In fact I talked to a lot of 
companies that are really early 

684
00:37:16,600 --> 00:37:19,700
on that Journey so companies 
were it's just a couple of 

685
00:37:19,700 --> 00:37:23,200
developers kind of Grassroots 
trying to tackle developer 

686
00:37:23,200 --> 00:37:26,000
experience all the way to large 
corporations where c-level 

687
00:37:26,000 --> 00:37:29,400
executives are excited about 
developer experience but don't 

688
00:37:29,400 --> 00:37:32,300
know how to actually He began 
working on it. 

689
00:37:32,700 --> 00:37:35,200
I think from everything I've 
learned with developer 

690
00:37:35,200 --> 00:37:39,000
experience I probably wouldn't 
recommend just one day waking up

691
00:37:39,000 --> 00:37:41,500
and saying we need to do 
developer experience because 

692
00:37:41,500 --> 00:37:43,700
that's not really what developer
experience is about. 

693
00:37:43,700 --> 00:37:46,700
Although it is now a buzzword I 
think it's just dangerous to 

694
00:37:46,700 --> 00:37:49,500
kind of Chase Trends and fads 
and buzzwords in the tech 

695
00:37:49,500 --> 00:37:52,400
industry because that's how we 
ended up with like 1000 

696
00:37:52,400 --> 00:37:55,300
JavaScript Frameworks with 
developer experience. 

697
00:37:55,300 --> 00:37:59,700
I think the success stories I 
hear often all revolve around 

698
00:37:59,700 --> 00:38:03,300
there being an Viable pain in 
the organization that can take 

699
00:38:03,300 --> 00:38:05,700
many forms. 
Sometimes it's that people are 

700
00:38:05,700 --> 00:38:08,000
leaving. 
There's a tradition, in fact, 

701
00:38:08,000 --> 00:38:11,100
that app in the Airbnb, 
sometimes, it's that things are 

702
00:38:11,100 --> 00:38:14,700
just low hiring more and more 
developers, but you can tell, 

703
00:38:14,700 --> 00:38:17,700
it's just becoming harder and 
harder to actually deliver 

704
00:38:17,700 --> 00:38:19,400
things. 
And you're not really seeing 

705
00:38:19,400 --> 00:38:21,800
things accelerate as much as 
they should, as you hire more 

706
00:38:21,800 --> 00:38:24,800
people, other times you're, 
well, aware of developers 

707
00:38:24,800 --> 00:38:29,100
complaining about the problems 
and challenges they're having in

708
00:38:29,100 --> 00:38:32,100
their day-to-day work. 
Whether it's the Old Times going

709
00:38:32,100 --> 00:38:36,500
into the hours or even days or 
multi step process to test work 

710
00:38:36,500 --> 00:38:38,000
before they can deploy it to 
customers. 

711
00:38:38,000 --> 00:38:41,200
And so, I think beginning The 
Tackle developer experience, 

712
00:38:41,200 --> 00:38:44,300
should really just begin with 
picking one concrete thing 

713
00:38:44,300 --> 00:38:47,700
within the organization. 
Something that has leveraged you

714
00:38:47,700 --> 00:38:50,700
want something that's going to 
provide a return for the 

715
00:38:50,700 --> 00:38:53,200
business. 
Simple way to illustrate, this 

716
00:38:53,200 --> 00:38:58,500
would be if builds take let's 
say 45 minutes to pass and 

717
00:38:58,500 --> 00:39:00,700
developer needs to run 10 builds
a day. 

718
00:39:00,800 --> 00:39:03,100
On average. 
Just as part of their work, if 

719
00:39:03,100 --> 00:39:07,600
you can cut that time in half, 
you could be almost doubling the

720
00:39:07,600 --> 00:39:10,600
capacity of your organization in
terms of the productivity of the

721
00:39:10,600 --> 00:39:12,500
developers and what they're able
to Output. 

722
00:39:12,800 --> 00:39:16,300
So that's a simplified example. 
But there's many opportunities 

723
00:39:16,300 --> 00:39:18,600
like this for. 
I think most companies. 

724
00:39:18,600 --> 00:39:22,400
If you go looking, I think 
that's where you should begin as

725
00:39:22,700 --> 00:39:27,700
identify as a single project and
picture that to leadership 

726
00:39:27,900 --> 00:39:30,500
picture that to business 
stakeholders. 

727
00:39:30,900 --> 00:39:33,900
Use that. 
When to then start building that

728
00:39:33,900 --> 00:39:37,200
muscle, start building that 
awareness and start building 

729
00:39:37,200 --> 00:39:42,300
that credibility and buy-in for 
the power and impact that can be

730
00:39:42,300 --> 00:39:44,400
achieved when you invest in 
developer experience. 

731
00:39:44,400 --> 00:39:47,100
I think that's where I would 
sort of begin in terms of baby 

732
00:39:47,100 --> 00:39:50,300
steps. 
So I think that speaks to a lot 

733
00:39:50,300 --> 00:39:53,300
of leaders out there, right? 
So don't chase the buzzwords. 

734
00:39:53,400 --> 00:39:56,900
Start from the real problems 
that you see in your engineering

735
00:39:56,900 --> 00:39:59,500
teams, you mentioned things like
people leaving. 

736
00:39:59,500 --> 00:40:02,300
So that's probably a Earning 
sign already, although it's 

737
00:40:02,300 --> 00:40:04,500
like, probably too late by that 
or slow. 

738
00:40:04,500 --> 00:40:08,500
Build tests are flaky. 
Those kind of things focus on 

739
00:40:08,500 --> 00:40:11,900
solving that because that will 
definitely give a lot of impact.

740
00:40:12,000 --> 00:40:14,800
If people are complaining a lot 
when it gets resolved, I'm sure 

741
00:40:14,800 --> 00:40:16,900
it will give a lot of impact and
satisfaction. 

742
00:40:17,300 --> 00:40:19,500
But the other thing that I 
learned from my journey as well,

743
00:40:19,600 --> 00:40:21,600
these things tend to change over
the time. 

744
00:40:21,600 --> 00:40:24,400
So maybe these day. 
It's about built tomorrow. 

745
00:40:24,400 --> 00:40:28,500
It's documentation. 
The next could be test when you 

746
00:40:28,500 --> 00:40:30,700
write a lot of tests, maybe they
are flaky or take. 

747
00:40:30,900 --> 00:40:33,300
Long to pass. 
I guess all these things like 

748
00:40:33,300 --> 00:40:36,200
Evolution, right? 
You probably never get a perfect

749
00:40:36,200 --> 00:40:37,400
state. 
I'm sure. 

750
00:40:37,400 --> 00:40:40,500
Maybe some organizations think, 
oh, they want to have a perfect 

751
00:40:40,500 --> 00:40:42,100
developer experience. 
I think it's kind of like 

752
00:40:42,100 --> 00:40:46,200
difficult especially these are 
people problem as well, social 

753
00:40:46,200 --> 00:40:48,800
technical problem. 
So I guess these things them to 

754
00:40:48,800 --> 00:40:51,800
change and you mentioned in the 
beginning, some companies 

755
00:40:51,800 --> 00:40:55,100
actually invest in building 
dedicated team, maybe they are 

756
00:40:55,100 --> 00:40:58,000
called like enablement team 
developer experience team. 

757
00:40:58,200 --> 00:41:00,700
So for companies who are at that
stage, maybe they are big. 

758
00:41:00,800 --> 00:41:03,100
Enough or they have hundreds of 
Engineers. 

759
00:41:03,200 --> 00:41:06,800
When do they need to start 
investing building such team and

760
00:41:06,800 --> 00:41:10,300
how should they go about it for 
most readers who have developer 

761
00:41:10,300 --> 00:41:13,800
experience team? 
So typically talk about how they

762
00:41:13,800 --> 00:41:17,400
should have done it sooner. 
So I think there's no sort of 

763
00:41:17,400 --> 00:41:19,300
singletrack answer to that 
question. 

764
00:41:19,300 --> 00:41:23,700
But I think, as soon as you're 
probably hitting around 50 to 80

765
00:41:23,700 --> 00:41:27,700
engineers and growing and also 
probably hit a point of like 

766
00:41:27,700 --> 00:41:30,400
product Market fit in your 
business where you're not just 

767
00:41:30,400 --> 00:41:33,900
wild, Scrambling to ship things.
You might throw away as soon as 

768
00:41:33,900 --> 00:41:38,100
you sort of have a longer-term 
view on the business and plan 

769
00:41:38,100 --> 00:41:40,600
for growth. 
I think that's the right time to

770
00:41:40,600 --> 00:41:43,600
take a good hard. 
Look at how can we get double 

771
00:41:43,600 --> 00:41:45,500
the output out of our 
organization? 

772
00:41:46,000 --> 00:41:47,500
That's what developer experience
is about. 

773
00:41:47,500 --> 00:41:50,700
It's about taking the people, 
you have and empowering them to 

774
00:41:50,700 --> 00:41:53,500
be able to do so much more. 
It's about getting the most out 

775
00:41:53,500 --> 00:41:55,200
of your investment. 
If you want to think, I have 

776
00:41:55,200 --> 00:41:58,900
business terms. 
And so I think the right time as

777
00:41:58,900 --> 00:42:01,100
I said, if I sort of take the 
average of all All the different

778
00:42:01,100 --> 00:42:04,600
companies I've spoken to, I 
think around 50 to 70 Engineers,

779
00:42:04,600 --> 00:42:09,700
post product-market fit is a 
good time to start establishing 

780
00:42:09,700 --> 00:42:11,500
a muscle around developer 
experience. 

781
00:42:11,500 --> 00:42:13,800
I wouldn't necessarily say, you 
have to form a team because 

782
00:42:13,800 --> 00:42:16,300
there's many different ways to 
tackle developer experience. 

783
00:42:16,300 --> 00:42:20,300
It doesn't have to be a 
dedicated team necessarily, but 

784
00:42:20,300 --> 00:42:23,800
I think at that point, you would
definitely want a senior leader,

785
00:42:23,800 --> 00:42:27,300
really taking a good hard. 
Look at the developer experience

786
00:42:27,300 --> 00:42:29,800
and looking for opportunities, 
starting to build a roadmap 

787
00:42:29,800 --> 00:42:33,300
starting to think about I2g and 
considering forming a team 

788
00:42:33,300 --> 00:42:36,400
around that if that's the right 
way to tackle the problem. 

789
00:42:37,200 --> 00:42:40,000
So yeah, I think I also myself 
faced this challenge with my 

790
00:42:40,000 --> 00:42:43,600
engineering team sometimes. 
Yeah, they are just anecdotal 

791
00:42:43,600 --> 00:42:46,100
complains. 
Okay, we had bad process here 

792
00:42:46,100 --> 00:42:49,700
but process there, but we're to 
tackle, sometimes is hard and 

793
00:42:49,700 --> 00:42:51,400
there's no dedicated team as 
well. 

794
00:42:51,600 --> 00:42:54,400
Every Engineers are just tuning 
out features over features of 

795
00:42:54,400 --> 00:42:57,300
visitors who will build the 
enablement team. 

796
00:42:57,500 --> 00:43:00,100
So I guess this is something to 
think about for those leaders, 

797
00:43:00,100 --> 00:43:01,600
right? 
When Is the right time for you 

798
00:43:01,600 --> 00:43:03,400
to start. 
Really investing maybe create a 

799
00:43:03,400 --> 00:43:06,800
more dedicated team build more 
purposeful tools so that 

800
00:43:06,800 --> 00:43:10,000
Engineers are more productive. 
Maybe this is a little bit more 

801
00:43:10,300 --> 00:43:13,500
of a challenging question for 
you to answer but what if a 

802
00:43:13,500 --> 00:43:17,000
company doesn't want to invest 
in develop experience? 

803
00:43:17,000 --> 00:43:18,800
They think. 
Oh, they're just Engineers. 

804
00:43:19,100 --> 00:43:20,700
They're just here to produce 
code. 

805
00:43:20,700 --> 00:43:23,600
So what would be your advice or 
maybe tips here? 

806
00:43:24,600 --> 00:43:26,900
That's such a good question. 
I mean, I think of this one 

807
00:43:26,900 --> 00:43:29,000
company that I know. 
I think they're around 300 

808
00:43:29,000 --> 00:43:31,200
Engineers. 
There's a couple A, they're 

809
00:43:31,200 --> 00:43:35,500
trying to get a Dub Fx function 
off the ground and doesn't sound

810
00:43:35,500 --> 00:43:38,800
like leadership super bought in 
and I really feel for those 

811
00:43:38,800 --> 00:43:42,500
developers clearly, there's huge
opportunities to improve the 

812
00:43:42,500 --> 00:43:46,300
productivity of the organization
but executives are skeptical, to

813
00:43:46,300 --> 00:43:48,100
be honest. 
I don't know if that's always a 

814
00:43:48,100 --> 00:43:51,700
problem, you can solve from the 
inside, you think back 10 years 

815
00:43:51,700 --> 00:43:53,900
ago even devops was hardly a 
term. 

816
00:43:54,200 --> 00:43:57,800
So I think in a sense the 
shamelessly, I would say calling

817
00:43:57,800 --> 00:44:00,500
up a company like us to come in 
and talk to your Executives and 

818
00:44:00,700 --> 00:44:02,900
Tim bought in to the idea of 
developer experience. 

819
00:44:02,900 --> 00:44:06,700
That's part of what we do really
is help developer experience 

820
00:44:06,700 --> 00:44:09,400
teams. 
Get buy-in from Executives by 

821
00:44:09,400 --> 00:44:14,300
taking a very sort of precise 
and methodical approach to 

822
00:44:14,300 --> 00:44:16,200
developer experience. 
It's really aligned with the 

823
00:44:16,200 --> 00:44:18,200
business. 
I think it's just hard. 

824
00:44:18,200 --> 00:44:21,200
Sometimes as developers were not
used to some of the corporate 

825
00:44:21,200 --> 00:44:24,600
politics and the ways of the 
businesses kind of need to 

826
00:44:24,600 --> 00:44:27,000
operate and determine where to 
make investments. 

827
00:44:27,400 --> 00:44:30,400
So that's where I think 
developer experience has trouble

828
00:44:30,400 --> 00:44:33,800
getting The ground sometimes is 
really speaking in terms of the 

829
00:44:33,800 --> 00:44:37,000
business can understand. 
Because I think if you use the 

830
00:44:37,000 --> 00:44:39,600
right language and present 
developer experience in the 

831
00:44:39,600 --> 00:44:44,100
right way, the ROI is very 
obvious and the organizations 

832
00:44:44,100 --> 00:44:46,300
that do invest in developer 
experience know that. 

833
00:44:46,600 --> 00:44:49,600
So I think it'll take a little 
bit of time before developer 

834
00:44:49,600 --> 00:44:52,500
experience. 
Sort of goes fully mainstream if

835
00:44:52,500 --> 00:44:54,400
you will. 
Yeah, I talk to people all the 

836
00:44:54,400 --> 00:44:57,300
time about this and I think most
in the industry would agree like

837
00:44:57,400 --> 00:45:00,600
developer experience is still 
kind of early on that adoption. 

838
00:45:00,700 --> 00:45:03,400
Curve. 
And so if you're out there 

839
00:45:03,500 --> 00:45:06,200
listening to this and you're 
having trouble getting buy-in 

840
00:45:06,200 --> 00:45:08,800
from your Executives, that's to 
be expected. 

841
00:45:08,900 --> 00:45:11,300
Not every company that every 
leader is going to get it, but 

842
00:45:11,300 --> 00:45:16,100
try to make the case and terms 
that the business can understand

843
00:45:16,300 --> 00:45:20,000
not using buzzwords, not 
pointing to Trends or fads in 

844
00:45:20,000 --> 00:45:22,400
the industry. 
But just point out the dollars 

845
00:45:22,400 --> 00:45:24,600
that are being lost or the 
dollars that could be gained 

846
00:45:24,600 --> 00:45:28,900
back, if that latent sort of 
potential could be unlocked 

847
00:45:28,900 --> 00:45:32,200
within the organization through 
And so developer experience, 

848
00:45:32,500 --> 00:45:35,200
that would be my advice so I 
know it's a hard problem, thanks

849
00:45:35,200 --> 00:45:38,100
for trying to answer that. 
So I think any kind of 

850
00:45:38,100 --> 00:45:40,800
organizations, when they build 
Tech teams, they always think 

851
00:45:40,800 --> 00:45:43,700
about feature teams, right? 
We want to feature teams product

852
00:45:43,700 --> 00:45:46,500
teams, whatever that is. 
I'm sure one day, you will reach

853
00:45:46,500 --> 00:45:49,200
a point where but just feature 
team that they will build, they 

854
00:45:49,200 --> 00:45:52,000
will also build this developer 
experience team or engineering 

855
00:45:52,000 --> 00:45:55,200
enablement team straight away 
from the get-go and I guess I 

856
00:45:55,200 --> 00:45:58,800
would also rely on researchers 
your company and some of the 

857
00:45:58,800 --> 00:46:01,900
researchers behind the company. 
To actually publish this kind of

858
00:46:01,900 --> 00:46:03,900
paper so that it becomes 
revolutionary. 

859
00:46:03,900 --> 00:46:06,400
So people take it, just like 
there are metrics right. 

860
00:46:06,400 --> 00:46:08,600
Oh, we have these four key 
metrics that we also should 

861
00:46:08,600 --> 00:46:10,800
think about when we talk about 
developer experience. 

862
00:46:11,200 --> 00:46:14,700
So I think the work that you do 
with your team is exciting, I 

863
00:46:14,700 --> 00:46:18,000
hope that something good covered
in the industry to improve on 

864
00:46:18,000 --> 00:46:20,300
this. 
So I'll be, it's been a pleasure

865
00:46:20,300 --> 00:46:22,400
talking to you. 
I learned a lot about improving 

866
00:46:22,400 --> 00:46:25,200
developer experience. 
So as we going to wrap up this 

867
00:46:25,200 --> 00:46:28,400
conversation, I have one last 
question, which I always ask for

868
00:46:28,400 --> 00:46:31,100
my guests, which is to share 
this thing called Three 

869
00:46:31,100 --> 00:46:34,000
technical leadership wisdom. 
We can think of it just like 

870
00:46:34,000 --> 00:46:36,800
advice for listeners here to 
learn from your journey, your 

871
00:46:36,800 --> 00:46:39,400
experience, or your expertise. 
So what will be your three? 

872
00:46:39,400 --> 00:46:42,500
Technical leadership is the 
great question. 

873
00:46:42,900 --> 00:46:45,000
I think. 
Now the topic we've been sort of

874
00:46:45,000 --> 00:46:49,700
discussing today, I would say be
very discriminant about how you 

875
00:46:49,700 --> 00:46:51,900
choose metrics. 
There's a lot of stuff out 

876
00:46:51,900 --> 00:46:53,300
there. 
There's a lot of vendors out 

877
00:46:53,300 --> 00:46:57,600
there including us. 
I'll admit there's a lot of faux

878
00:46:57,600 --> 00:46:59,800
research up. 
There's a lot of good research 

879
00:46:59,800 --> 00:47:03,000
up there. 
Know exactly what it is. 

880
00:47:03,000 --> 00:47:06,900
You're trying to drive in your 
organization before you start 

881
00:47:06,900 --> 00:47:09,800
picking up metrics. 
I see so many leaders shop for 

882
00:47:09,800 --> 00:47:13,100
metrics instead of really think 
critically about the types of 

883
00:47:13,100 --> 00:47:15,800
outcomes or hoping they achieve 
in their organization. 

884
00:47:16,000 --> 00:47:18,600
And then ask, if there are 
measurements that could help 

885
00:47:18,600 --> 00:47:21,700
them achieve that. 
So that would be the first. 

886
00:47:22,200 --> 00:47:26,400
The second would be surveys are 
very underestimated in our 

887
00:47:26,400 --> 00:47:27,600
industry. 
I think it's because we're 

888
00:47:27,600 --> 00:47:30,500
programmers and we love 
streaming real-time data. 

889
00:47:30,800 --> 00:47:35,700
Coming out of systems into 
pipelines and D3 charts, but one

890
00:47:35,700 --> 00:47:39,100
of the biggest mistakes I've 
seen and Nicole for Scranton 

891
00:47:39,300 --> 00:47:42,300
would agree with this. 
We've talked about this is we've

892
00:47:42,300 --> 00:47:45,700
seen Corporation spending tens 
of millions of dollars during 

893
00:47:45,700 --> 00:47:48,800
the instrument their systems to 
measure the door and metrics 

894
00:47:49,200 --> 00:47:52,400
when in fact what they don't 
realize is that even in her 

895
00:47:52,400 --> 00:47:56,600
research Nicole use surveys to 
measure the door metrics. 

896
00:47:56,600 --> 00:47:59,600
And in fact, the whole last 
third of half of the book goes 

897
00:47:59,600 --> 00:48:03,900
into y and And how she did that.
And so surveys are way to 

898
00:48:03,900 --> 00:48:08,300
measure, both subjective and 
objective metrics. 

899
00:48:08,600 --> 00:48:11,400
There are limitations to using 
surveys. 

900
00:48:11,500 --> 00:48:15,800
For example, you can't measure 
things on a real-time basis. 

901
00:48:15,800 --> 00:48:17,500
You can't run surveys every 
hour. 

902
00:48:17,800 --> 00:48:20,400
You also can't measure things 
down to the millisecond with 

903
00:48:20,400 --> 00:48:24,500
surveys but there's a lot you 
can measure and I think a lot of

904
00:48:24,500 --> 00:48:29,000
leaders are spending too much 
money too much hassle trying to 

905
00:48:29,000 --> 00:48:31,400
get poor metrics that won't even
Help them. 

906
00:48:31,700 --> 00:48:35,800
When a more obvious starting 
path, if you think about it, is 

907
00:48:35,800 --> 00:48:38,700
to just start asking your 
developers questions about 

908
00:48:38,700 --> 00:48:42,200
what's getting in their way, how
their processes are other tools 

909
00:48:42,200 --> 00:48:45,700
are working for them. 
The last sort of word was, I 

910
00:48:45,700 --> 00:48:50,000
would share here would be 
definitely to just follow the 

911
00:48:50,000 --> 00:48:52,300
research that's coming out in 
the industry. 

912
00:48:52,800 --> 00:48:57,000
Whether it's research on the 
different types of agile scrum, 

913
00:48:57,000 --> 00:49:01,900
kanban practices, or whether 
it's research, On algorithms 

914
00:49:02,000 --> 00:49:06,000
hardware systems. 
There's so much amazing research

915
00:49:06,000 --> 00:49:09,100
coming out of academic 
institutions, as well as 

916
00:49:09,100 --> 00:49:11,100
companies like Microsoft and 
Google. 

917
00:49:11,600 --> 00:49:13,400
That's one of the things I've 
been working on. 

918
00:49:13,500 --> 00:49:17,400
Is I have a newsletter where we 
write summaries of research, 

919
00:49:17,500 --> 00:49:19,700
these research papers are pretty
dense to read. 

920
00:49:19,700 --> 00:49:22,500
It's not really casual reading. 
And so, we're trying to make it 

921
00:49:22,508 --> 00:49:24,500
a little more accessible for 
practitioners. 

922
00:49:24,700 --> 00:49:28,400
And we have a multi-year, long, 
backlog of papers, we're looking

923
00:49:28,400 --> 00:49:30,600
forward to sharing, but there's 
really amazing stuff. 

924
00:49:31,300 --> 00:49:33,700
As we talked about earlier, it's
so important because the 

925
00:49:33,700 --> 00:49:38,500
research often debunk, some of 
the sort of trendy opinions of 

926
00:49:38,500 --> 00:49:41,400
the year as far as Fair, what 
you're hearing on blogs that 

927
00:49:41,400 --> 00:49:45,000
you're reading on Twitter. 
So I think more leaders more 

928
00:49:45,000 --> 00:49:48,200
practitioners even developers 
should be following the research

929
00:49:48,200 --> 00:49:50,700
that's happening and I think 
would be able to use that within

930
00:49:50,700 --> 00:49:53,200
their organizations to make the 
case for things like developer 

931
00:49:53,200 --> 00:49:57,400
experience, much easier if they 
were leading on Research rather 

932
00:49:57,400 --> 00:50:01,800
than for example tweets. 
I mean, they love all your 

933
00:50:01,800 --> 00:50:05,000
wisdom is really unique. 
So some of the key takeaways for

934
00:50:05,000 --> 00:50:06,700
me is like Wes don't shop 
metrics. 

935
00:50:07,000 --> 00:50:09,100
Think of what actually the 
underlying problems you're 

936
00:50:09,100 --> 00:50:12,400
trying to solve and try to find 
measurement out of that then 

937
00:50:12,400 --> 00:50:14,500
surveys underestimated. 
The I agree with you. 

938
00:50:14,500 --> 00:50:17,200
Sometimes we engineer's, 
especially if you have a 

939
00:50:17,300 --> 00:50:19,500
dedicated team. 
They will tend to build 

940
00:50:19,500 --> 00:50:22,800
Technologies to solve a problem,
and they will take a lot of 

941
00:50:22,800 --> 00:50:24,600
effort and time to actually 
build it. 

942
00:50:24,600 --> 00:50:27,200
But, at the end of the day, 
maybe survey itself suffices, 

943
00:50:27,200 --> 00:50:28,900
right? 
So, the ratio of input and 

944
00:50:28,900 --> 00:50:31,500
output properties with its 02 
Let's do 70. 

945
00:50:31,900 --> 00:50:35,500
Lastly, I'm a subscriber to your
sub stack newsletter, I find it 

946
00:50:35,500 --> 00:50:37,800
really interesting. 
You cover a lot of software, 

947
00:50:37,800 --> 00:50:39,900
engineering kind of a related 
research. 

948
00:50:40,200 --> 00:50:43,500
I was unaware of those kind of 
research people and luckily you 

949
00:50:43,500 --> 00:50:47,000
do all this so that I can read 
it in an easier way but like in 

950
00:50:47,000 --> 00:50:49,400
a dance complicated way of 
explaining things. 

951
00:50:49,500 --> 00:50:51,900
So thanks for sharing that and 
I'll put a plug for the 

952
00:50:51,900 --> 00:50:54,400
newsletter. 
So people can also subscribe and

953
00:50:54,400 --> 00:50:56,700
read from there. 
I think it's really useful for 

954
00:50:56,700 --> 00:50:59,500
engineering leaders. 
So if people want to connect 

955
00:50:59,500 --> 00:51:02,400
with you or talk, Talk more 
about developer experience 

956
00:51:02,400 --> 00:51:04,200
online. 
Is there a place where they can 

957
00:51:04,200 --> 00:51:06,700
reach up? 
Yeah, always love connecting 

958
00:51:06,700 --> 00:51:09,400
with people. 
So I'm on Twitter, I'll be no. 

959
00:51:09,400 --> 00:51:13,700
Te you can email me, I'll be no 
DirectX a come or on LinkedIn. 

960
00:51:13,800 --> 00:51:15,400
Yeah, always happy to connect 
with people. 

961
00:51:15,500 --> 00:51:18,400
Sure advice by can help and hear
what people are up to in the 

962
00:51:18,400 --> 00:51:21,100
space. 
Then a b also has a podcast, so 

963
00:51:21,100 --> 00:51:24,400
if you are into developer 
experience, do check out Abby's 

964
00:51:24,400 --> 00:51:26,800
podcast as well. 
So thanks again for your time. 

965
00:51:26,800 --> 00:51:30,000
I'll be really excited about all
the research that your team is 

966
00:51:30,000 --> 00:51:31,900
doing. 
So, Good luck with all that and 

967
00:51:31,900 --> 00:51:34,800
looking forward to the paper 
being published next year. 

968
00:51:35,400 --> 00:51:36,700
Thanks so much. 
Thanks for having me. 

969
00:51:36,700 --> 00:51:41,700
This is fun. 
Thank you for listening to this 

970
00:51:41,700 --> 00:51:45,100
episode and for staying, right 
until the end, if you're highly 

971
00:51:45,100 --> 00:51:47,900
enjoyed it, I would appreciate 
if you share it with your 

972
00:51:47,900 --> 00:51:50,900
friends and colleagues who you 
think would also benefit from 

973
00:51:50,900 --> 00:51:53,400
listening to this episode. 
And if you are new to the 

974
00:51:53,400 --> 00:51:56,400
podcast, make sure to subscribe 
and leave me your valuable 

975
00:51:56,400 --> 00:51:59,400
review and feedback. 
It helps me a lot in order to 

976
00:51:59,400 --> 00:52:02,700
grow this podcast better. 
You can also find the full show 

977
00:52:02,700 --> 00:52:06,000
notes of this conversation on 
the episode page at tackling 

978
00:52:06,000 --> 00:52:09,200
Journal, dot death website, 
including the full transcript 

979
00:52:09,300 --> 00:52:11,300
interesting. 
Quartz and links to the 

980
00:52:11,300 --> 00:52:13,600
resources mention from the 
conversation. 

981
00:52:14,000 --> 00:52:17,100
And lastly make sure to 
subscribe to the shows mailing 

982
00:52:17,100 --> 00:52:20,500
list on technology. 
No dot f to get notified for any

983
00:52:20,500 --> 00:52:23,100
future episodes. 
Stay tuned for the next 

984
00:52:23,100 --> 00:52:26,400
technology, you know, episode. 
And until then goodbye.