1
00:00:00,000 --> 00:00:02,600
High performing team is one the 
kids to spend almost all of 

2
00:00:02,600 --> 00:00:06,200
their time solving interesting 
problems that move the business 

3
00:00:06,200 --> 00:00:10,500
forward, not doing a lot of toil
not like working on things that 

4
00:00:10,500 --> 00:00:12,500
they have to do in order to get 
to the things that they want to 

5
00:00:12,500 --> 00:00:15,000
do. 
Not slogging through fixing the 

6
00:00:15,000 --> 00:00:16,800
bill. 
Begin not slogging through 

7
00:00:16,800 --> 00:00:20,900
outages, not waiting for test to
pass, not waiting for our 

8
00:00:20,900 --> 00:00:23,100
deploys to finish fixing 
something and then realizing it 

9
00:00:23,100 --> 00:00:26,000
was a different problem. 
I think we tend to take for 

10
00:00:26,000 --> 00:00:27,900
granted that it just it has to 
be that way. 

11
00:00:28,300 --> 00:00:30,900
If you get your shit in order 
you you can have a job where you

12
00:00:30,900 --> 00:00:33,900
spend most of your time solving 
new and interesting problems. 

13
00:00:38,400 --> 00:00:41,700
Hey everyone. 
My name is Henry Surya be Robin.

14
00:00:43,300 --> 00:00:47,100
And you're listening to the 
tekhelet Juno, the show will be 

15
00:00:47,100 --> 00:00:50,400
bringing you the greatest 
technical leaders practitioners 

16
00:00:50,700 --> 00:00:54,000
and thought leaders in the 
industry to discuss about their 

17
00:00:54,000 --> 00:00:58,800
Journey ideas and practices that
we all can learn and apply to 

18
00:00:58,800 --> 00:01:01,800
build a highly performing 
technical team and to make an 

19
00:01:01,800 --> 00:01:06,500
impact in your personal work. 
So let's dive into our Journal. 

20
00:01:11,500 --> 00:01:14,100
Hello everyone. 
I'm back here again with another

21
00:01:14,100 --> 00:01:16,600
new episode of the technology, 
you know podcast. 

22
00:01:16,900 --> 00:01:19,800
Thank you so much for tuning in 
and spending your time with me 

23
00:01:19,800 --> 00:01:23,700
today listening to this episode.
If you're new to the podcast 

24
00:01:23,900 --> 00:01:27,100
know that package, you know, is 
available for you to subscribe 

25
00:01:27,100 --> 00:01:31,200
on major podcast apps such as 
Spotify and apple podcast Google

26
00:01:31,200 --> 00:01:34,900
podcast, YouTube, and many 
others also, check out and 

27
00:01:34,900 --> 00:01:37,500
follow technology. 
No social media channels on 

28
00:01:37,500 --> 00:01:42,300
LinkedIn, Twitter and Instagram.
Everyday, I post quotes and 

29
00:01:42,300 --> 00:01:45,700
words of wisdom from the recent 
podcast episode, and I share 

30
00:01:45,700 --> 00:01:48,600
them on those channels to give 
us some inspiration and 

31
00:01:48,600 --> 00:01:51,300
motivation for us to get better 
each day. 

32
00:01:52,000 --> 00:01:54,300
And if you are thinking about 
making some contribution to the 

33
00:01:54,300 --> 00:01:58,300
show and support the creation of
this podcast, please consider 

34
00:01:58,300 --> 00:02:01,100
joining as a patron by visiting 
technology. 

35
00:02:01,100 --> 00:02:05,000
No dot f /, Patron. 
I highly appreciate any kind of 

36
00:02:05,008 --> 00:02:08,000
support and your contribution 
would help me towards 

37
00:02:08,000 --> 00:02:12,100
sustainably producing this show.
Every week for today's episode. 

38
00:02:12,100 --> 00:02:16,700
I am extremely excited to share 
my conversation with Charity 

39
00:02:16,700 --> 00:02:20,900
Majors charity. 
Is the co-founder and CTO of 

40
00:02:20,900 --> 00:02:25,100
honeycomb, the observability 
tools for engineering teams to 

41
00:02:25,100 --> 00:02:29,300
debug production systems faster.
And smarter charity is a 

42
00:02:29,308 --> 00:02:32,200
frequent speaker. 
And is someone that I admire a 

43
00:02:32,200 --> 00:02:35,400
lot, not just for her thought 
leadership on devops 

44
00:02:35,400 --> 00:02:39,800
observability, distributed 
systems, Etc, but also for her, 

45
00:02:40,200 --> 00:02:43,700
Opinions on multiple other 
topics, such as management, 

46
00:02:43,700 --> 00:02:48,700
engineering startup culture, 
diversity, and many more which 

47
00:02:48,700 --> 00:02:52,800
you can also find and follow on 
her Twitter and personal blog in

48
00:02:52,800 --> 00:02:56,800
this episode charity. 
And I discussed in depth about 

49
00:02:56,800 --> 00:02:59,200
building. 
High performing teams by having 

50
00:02:59,200 --> 00:03:03,000
observability and CI CD. 
As the critical pillars to 

51
00:03:03,000 --> 00:03:05,700
support it. 
We open up our discussion 

52
00:03:05,800 --> 00:03:09,600
discussing about what 
observability is how it diverse 

53
00:03:09,600 --> 00:03:11,500
from me. 
Monitoring and why the 

54
00:03:11,500 --> 00:03:14,700
traditional monitoring tools and
pre Aggregates are not 

55
00:03:14,700 --> 00:03:18,300
sufficient to help us understand
our systems better and to 

56
00:03:18,300 --> 00:03:22,200
uncover the unknown unknowns 
charity shares. 

57
00:03:22,200 --> 00:03:25,400
How honeycomb provides unique 
capabilities that can help 

58
00:03:25,400 --> 00:03:28,900
provide observability for 
distributed systems and how it 

59
00:03:28,900 --> 00:03:32,300
works, including an interesting 
use case that can provide 

60
00:03:32,400 --> 00:03:35,000
observability for CI CD 
pipelines. 

61
00:03:35,800 --> 00:03:39,100
Then we moved on to discuss 
about building, high-performing 

62
00:03:39,100 --> 00:03:42,400
engineering teams. 
Charity, share, it has strong 

63
00:03:42,400 --> 00:03:46,300
views on how to build such teams
by focusing on continuous 

64
00:03:46,300 --> 00:03:50,400
delivery, carrying a lot about 
the socio technical aspects of a

65
00:03:50,408 --> 00:03:54,400
team and the fifth key metric. 
As her addition to the widely 

66
00:03:54,400 --> 00:03:57,400
known Dora metrics towards the 
end. 

67
00:03:57,600 --> 00:04:01,500
We discuss the engineer manager,
pendulum based on her popular 

68
00:04:01,500 --> 00:04:03,900
blog post some time back and 
charity. 

69
00:04:03,900 --> 00:04:07,700
Shared what she means by the 
pendulum and how one should be 

70
00:04:07,700 --> 00:04:10,000
conscious about it. 
She gave her word. 

71
00:04:10,100 --> 00:04:14,100
Of advice and explain that going
into management, is not a one 

72
00:04:14,100 --> 00:04:17,399
way street and that we should 
also not treat it as a 

73
00:04:17,399 --> 00:04:20,200
promotion. 
This is such an amazing episode 

74
00:04:20,200 --> 00:04:23,500
that you don't want to miss and 
I'm certain that you will also 

75
00:04:23,500 --> 00:04:25,900
enjoy this episode if you like 
it. 

76
00:04:25,900 --> 00:04:29,700
Considered helping the show by 
living it a rating review or 

77
00:04:29,700 --> 00:04:33,700
comment on your podcast app or 
social media channels, those 

78
00:04:33,700 --> 00:04:36,900
reviews and comments are one of 
the best ways to help me get 

79
00:04:36,900 --> 00:04:41,000
this podcast to reach more 
listeners and hopefully they can

80
00:04:41,000 --> 00:04:43,900
also benefit from the contents. 
In this podcast. 

81
00:04:44,300 --> 00:04:47,700
Let's get this episode started 
right after our short sponsor 

82
00:04:47,700 --> 00:04:50,000
message. 
Are you looking for a new cool 

83
00:04:50,000 --> 00:04:53,500
swag tekhelet Journal. 
Now offers you some swags that 

84
00:04:53,500 --> 00:04:57,300
you can purchase online. 
These wax are printed on demand 

85
00:04:57,300 --> 00:05:00,700
based on your preference and 
will be delivered safely to you 

86
00:05:00,700 --> 00:05:03,200
all over the world where 
shipping is available. 

87
00:05:03,700 --> 00:05:06,300
Check out all the cool strikes 
available by visiting 

88
00:05:06,300 --> 00:05:09,600
technology, you know dot, f / 
shop and don't forget to break 

89
00:05:09,600 --> 00:05:11,900
yourself. 
Once you receive any of those 

90
00:05:11,900 --> 00:05:18,000
wrecks. 
Hey everyone, welcome to another

91
00:05:18,000 --> 00:05:19,900
new episode of the technology. 
You know today. 

92
00:05:19,900 --> 00:05:23,100
I'm very excited to have someone
that I really admire from the 

93
00:05:23,100 --> 00:05:26,900
devops technology side. 
Her name is Charity Majors. 

94
00:05:27,200 --> 00:05:30,400
I'm sure many of you would have 
recognized her name today. 

95
00:05:30,400 --> 00:05:34,300
We'll be talking a lot about 
observability, monitoring CI CD 

96
00:05:34,300 --> 00:05:37,600
and a few other topics that she 
is famous for in terms of blog 

97
00:05:37,600 --> 00:05:40,300
posts. 
Charity is a CTO and co-founder 

98
00:05:40,300 --> 00:05:43,000
of honeycomb developer tools, 
that helps to improve the 

99
00:05:43,000 --> 00:05:44,800
observability of your 
application. 

100
00:05:45,100 --> 00:05:50,900
She also writes a great Posts at
charity WTF and co-host, a 

101
00:05:50,900 --> 00:05:54,100
popular podcast, called only 
cats, which I think is one of 

102
00:05:54,100 --> 00:05:57,100
the best observability of 
monitoring podcast available out

103
00:05:57,100 --> 00:05:59,400
there for charity. 
Thanks for your time today. 

104
00:05:59,400 --> 00:06:01,100
Hope to have a good conversation
with you. 

105
00:06:01,200 --> 00:06:02,900
Yeah. 
Thanks so much for having me. 

106
00:06:02,900 --> 00:06:05,600
I'm really excited. 
So charity and maybe in the 

107
00:06:05,600 --> 00:06:07,900
first place. 
Let us hear more from you about 

108
00:06:07,900 --> 00:06:10,700
your career Journey, about your 
highlights and turning points. 

109
00:06:11,200 --> 00:06:13,800
Yeah. 
Well, I'm kind of an accidental 

110
00:06:13,800 --> 00:06:16,500
technologist. 
I went to college for for 

111
00:06:16,500 --> 00:06:20,800
classical piano performance when
I was 15 and I never had a 

112
00:06:20,800 --> 00:06:23,600
computer when I was growing up. 
I never even had email until I 

113
00:06:23,600 --> 00:06:26,300
went to college, but I didn't 
want to be poor. 

114
00:06:26,500 --> 00:06:29,200
I didn't want to be broke and I 
found myself hanging out in the 

115
00:06:29,200 --> 00:06:32,200
computer lab a lot. 
I never actually had a degree in

116
00:06:32,200 --> 00:06:34,500
computer science. 
I had majored in classical 

117
00:06:34,500 --> 00:06:38,800
studies Latin and Greek and 
creative writing and philosophy,

118
00:06:38,800 --> 00:06:42,200
but I found that I was spending 
more and more time working in 

119
00:06:42,200 --> 00:06:44,400
the lab than I was doing any of 
my schoolwork. 

120
00:06:44,400 --> 00:06:48,100
I dropped out a couple of X came
to San Francisco. 

121
00:06:48,300 --> 00:06:51,400
I've been working at startups 
ever since I've made a niche for

122
00:06:51,400 --> 00:06:54,700
myself, being an early or I like
to be the first infrastructure 

123
00:06:54,700 --> 00:06:57,200
higher that joins a team of 
software Engineers when they 

124
00:06:57,200 --> 00:06:59,400
think that they've got something
that might be real. 

125
00:06:59,400 --> 00:07:01,200
And I like to help them help it 
grow up. 

126
00:07:01,400 --> 00:07:04,000
And then I typically start 
hiring a team, then I manage the

127
00:07:04,000 --> 00:07:05,900
team. 
Then there comes a point where 

128
00:07:05,900 --> 00:07:08,200
I'm like, well, I've got 
everything I do here and I find 

129
00:07:08,200 --> 00:07:09,500
another startup, but I do it 
again. 

130
00:07:09,800 --> 00:07:12,400
So that's what I was doing when 
I joined parse, which is a 

131
00:07:12,400 --> 00:07:15,500
mobile backend for mobile 
developers, and that was about 

132
00:07:15,500 --> 00:07:18,300
six years ago. 
I was there before beta got 

133
00:07:18,300 --> 00:07:20,800
acquired by Facebook. 
I stayed at Facebook for two and

134
00:07:20,800 --> 00:07:23,400
a half years give you a little 
bit of context. 

135
00:07:23,500 --> 00:07:26,400
Parse was we were doing a lot of
like microservices before there 

136
00:07:26,400 --> 00:07:28,700
were microservices. 
We were doing this really hard 

137
00:07:28,700 --> 00:07:31,500
code tenancy problems. 
We had over a million apps 

138
00:07:31,500 --> 00:07:34,800
running on purse with one 
database in one pool of app 

139
00:07:34,800 --> 00:07:36,300
workers. 
And we were going down 

140
00:07:36,300 --> 00:07:38,300
constantly. 
It was really professionally. 

141
00:07:38,300 --> 00:07:40,400
Embarrassing to me because every
day be like, a new app. 

142
00:07:40,400 --> 00:07:43,100
Would hit the iTunes. 
Top ten parts we go down. 

143
00:07:43,400 --> 00:07:46,300
I tried every monitoring tool. 
Every logging tool, every AP. 

144
00:07:46,500 --> 00:07:50,400
Tool tried everything and 
nothing helped because they were

145
00:07:50,400 --> 00:07:53,400
all dealing with metrics and pre
Aggregates pre Aggregates are 

146
00:07:53,400 --> 00:07:54,700
great. 
When you know what questions 

147
00:07:54,700 --> 00:07:56,700
you're going to need to ask. 
Can you capture that data in 

148
00:07:56,700 --> 00:07:59,300
that way, but when you have to 
ask different questions every 

149
00:07:59,300 --> 00:08:01,500
day and you have no idea what 
questions are going to need to 

150
00:08:01,500 --> 00:08:04,200
ask, like, all of the existing 
tools just fell apart. 

151
00:08:04,200 --> 00:08:06,700
So, there was one tool that 
Facebook called scuba that we 

152
00:08:06,700 --> 00:08:08,500
started shipping some data sets 
into. 

153
00:08:08,700 --> 00:08:11,500
And the time it took us to 
figure out which apple is the 

154
00:08:11,500 --> 00:08:13,800
root cause of us going down or 
whatever, just dropped like a 

155
00:08:13,800 --> 00:08:15,800
rock. 
It could be hours or days. 

156
00:08:15,800 --> 00:08:17,900
It was like opening. 
And ended like who knew to like 

157
00:08:17,900 --> 00:08:21,400
predictably it was s not even 
minutes, but every time we would

158
00:08:21,400 --> 00:08:24,000
just like start slicing and 
dicing we could find the answer,

159
00:08:24,200 --> 00:08:25,600
this made a huge impression on 
me. 

160
00:08:25,600 --> 00:08:29,400
And when I was leaving Facebook,
I was like, oh my God, I can't 

161
00:08:29,400 --> 00:08:31,000
go back to being without this 
tooling. 

162
00:08:31,200 --> 00:08:33,299
I was supposed to be going to be
an engineering manager at soccer

163
00:08:33,299 --> 00:08:36,000
stripe or something. 
And I was just like this needs 

164
00:08:36,000 --> 00:08:38,799
to exist because everyone is 
starting to have this problem. 

165
00:08:39,000 --> 00:08:41,400
Everyone is starting to this 
problem of high cardinality and 

166
00:08:41,400 --> 00:08:44,400
high dimensionality, and there's
no tool out there that exists. 

167
00:08:44,800 --> 00:08:47,500
So we started building the 
tools, Would become honeycomb. 

168
00:08:47,800 --> 00:08:50,800
We had to start by writing our 
own database effectively because

169
00:08:50,800 --> 00:08:53,100
there is nothing out there that 
could do this and that was 

170
00:08:53,100 --> 00:08:55,300
difficult, but it wasn't as 
difficult as trying to figure 

171
00:08:55,300 --> 00:08:58,000
out the language because we knew
we weren't building a monitoring

172
00:08:58,000 --> 00:09:00,000
tool. 
We knew that it was something 

173
00:09:00,000 --> 00:09:03,100
very fundamentally different 
that it was, you know, for 

174
00:09:03,100 --> 00:09:05,900
helping you develop your 
application and it was about six

175
00:09:05,900 --> 00:09:07,800
months into having start 
honeycomb. 

176
00:09:07,900 --> 00:09:11,200
When I happened to Google the 
term observability, which no one

177
00:09:11,200 --> 00:09:14,800
was using at the time when I 
read the definition which comes 

178
00:09:14,800 --> 00:09:16,200
from like mechanical engineering
and construction. 

179
00:09:16,300 --> 00:09:18,900
Troll Theory and it has to do 
with how well, can you 

180
00:09:18,900 --> 00:09:22,300
understand any state that your 
system can get into just by 

181
00:09:22,300 --> 00:09:25,600
looking at it for me outside and
I went, oh my God, but light 

182
00:09:25,600 --> 00:09:28,300
bulbs are appeared in my head. 
This is what we're trying to do.

183
00:09:28,400 --> 00:09:29,700
This is what we're trying to 
build. 

184
00:09:29,900 --> 00:09:33,300
We're trying to build a way to 
understand your system just by 

185
00:09:33,300 --> 00:09:35,600
asking questions from the 
outside without having to ship 

186
00:09:35,600 --> 00:09:39,100
any custom code to understand 
the problem, which implies that 

187
00:09:39,100 --> 00:09:41,200
you could have known it was 
going to be in advance. 

188
00:09:41,400 --> 00:09:44,000
So it's all about the unknown 
unknowns and it's all about 

189
00:09:44,000 --> 00:09:46,200
being able to infinitely slice 
and dice the Attila. 

190
00:09:46,400 --> 00:09:48,400
That's coming out. 
We started talking about it a 

191
00:09:48,400 --> 00:09:50,300
lot and for the first two years 
or so. 

192
00:09:50,300 --> 00:09:53,000
It was like, just nothing. 
Everybody was like, we've been 

193
00:09:53,000 --> 00:09:55,500
told this is impossible. 
We believe that you're lying, 

194
00:09:55,500 --> 00:09:58,100
but blah, and about three years 
into doing honeycomb. 

195
00:09:58,300 --> 00:09:59,900
One day. 
It was just like everything 

196
00:09:59,900 --> 00:10:01,600
changed. 
I woke up the next morning and 

197
00:10:01,600 --> 00:10:03,800
the entire world was like, but 
of course, we need 

198
00:10:03,800 --> 00:10:05,300
observability. 
We have always wanted 

199
00:10:05,300 --> 00:10:07,100
observability. 
And by the way, we do 

200
00:10:07,100 --> 00:10:09,700
observability to number was just
like, oh my God. 

201
00:10:09,700 --> 00:10:12,700
No, so there's been a little bit
of a bandwagon effect. 

202
00:10:12,700 --> 00:10:14,600
Now, the frustrating thing is 
everybody's like, yeah, we do 

203
00:10:14,600 --> 00:10:17,400
observe ability to just like, 
well, no, they're supposed to be

204
00:10:17,400 --> 00:10:20,300
very specific technical 
definition because if you say 

205
00:10:20,300 --> 00:10:22,700
you want to be able to ask any 
question of your systems, some 

206
00:10:22,700 --> 00:10:24,900
things proceed from that some 
technical prerequisites 

207
00:10:24,900 --> 00:10:27,800
perceiving that you have to be 
able to handle high, cardinality

208
00:10:27,800 --> 00:10:30,700
and high, dimensionality, and 
you have to gather the Telemetry

209
00:10:30,700 --> 00:10:33,900
in such a way that you have one,
arbitrarily wife tortured event 

210
00:10:33,900 --> 00:10:36,100
per request per service. 
And I've written all these blog 

211
00:10:36,100 --> 00:10:38,300
posts and stuff. 
The people who follow it closely

212
00:10:38,300 --> 00:10:39,900
understand. 
But like the rest of the markers

213
00:10:39,900 --> 00:10:42,500
just like how observability is a
new synonym for Telemetry? 

214
00:10:42,500 --> 00:10:45,700
Got it, and I'm just like, okay.
Well, this is better. 

215
00:10:45,700 --> 00:10:48,900
This is progress. 
You know, yep is coming in 

216
00:10:48,900 --> 00:10:51,800
technology industry, any new. 
Jargon, any new buzzword, 

217
00:10:51,800 --> 00:10:54,600
everyone taste used. 
So if you can help us, like 

218
00:10:54,600 --> 00:10:56,300
maybe share from your point of 
view. 

219
00:10:56,300 --> 00:10:59,200
What is observability? 
And how does it differ from 

220
00:10:59,200 --> 00:11:01,300
monitoring? 
Which, what we are used to? 

221
00:11:01,900 --> 00:11:03,200
Yeah, I think it's really 
important. 

222
00:11:03,200 --> 00:11:05,300
That people like understand the 
way it's different because 

223
00:11:05,300 --> 00:11:09,000
monitoring is a very mature. 
It's an important discipline of 

224
00:11:09,000 --> 00:11:11,600
its own and there's a lot of 
best practices and stuff that go

225
00:11:11,600 --> 00:11:13,800
along with it. 
I think that the metrics tooling

226
00:11:13,800 --> 00:11:17,200
is great, it fulfills a separate
need In the ecosystem from 

227
00:11:17,200 --> 00:11:19,500
observability. 
Monitoring is really about 

228
00:11:19,500 --> 00:11:22,600
taking from the perspective of 
the service and saying is this 

229
00:11:22,600 --> 00:11:25,900
service objectively speaking? 
Healthy is a service healthy. 

230
00:11:26,100 --> 00:11:27,800
Do I need to plan for more 
capacity? 

231
00:11:28,000 --> 00:11:29,700
What's my consumption 
percentage? 

232
00:11:29,700 --> 00:11:32,300
It's usually built on a 
structure of metrics. 

233
00:11:32,500 --> 00:11:34,600
There are the generic term for 
metric, which just Telemetry. 

234
00:11:34,600 --> 00:11:37,300
But the specific technical term 
for metric is just it's a number

235
00:11:37,400 --> 00:11:40,300
you can append tags to. 
So like it's really cheap. 

236
00:11:40,300 --> 00:11:43,300
You can store a lot of metrics 
very efficiently, you can age 

237
00:11:43,300 --> 00:11:46,200
them out, as they get older, you
can drop some detail and you can

238
00:11:46,400 --> 00:11:47,700
Your system for a very long 
time. 

239
00:11:47,900 --> 00:11:50,500
The source of Truth for 
observability is not metrics 

240
00:11:50,500 --> 00:11:52,900
because when you capture that 
one metric that would number. 

241
00:11:53,000 --> 00:11:56,600
You've discarded all of the 
context except for a few tags, 

242
00:11:56,600 --> 00:11:59,100
which you bring back. 
So for example, say you have a 

243
00:11:59,108 --> 00:12:01,700
spike of errors in your graph. 
What's wrong? 

244
00:12:01,900 --> 00:12:04,000
Well, what's up durability, you 
might slice and dice to figure 

245
00:12:04,000 --> 00:12:05,800
out. 
Oh, these errors are for all the

246
00:12:05,800 --> 00:12:08,100
requests are coming from this 
version of iOS. 

247
00:12:08,200 --> 00:12:11,400
From this end point from this 
language pack from this version 

248
00:12:11,400 --> 00:12:14,700
of the firmware from this build 
ID, just like the long string of

249
00:12:14,700 --> 00:12:16,200
things that like this is what's 
different about them. 

250
00:12:16,300 --> 00:12:19,700
The well, you can't do that with
metrics unless you happen to an 

251
00:12:19,700 --> 00:12:24,000
advanced capture a metric for 
this version of iOS this build 

252
00:12:24,000 --> 00:12:26,300
ID and the ability is always 
incrementing and always 

253
00:12:26,300 --> 00:12:28,000
changing. 
So you have to capture those 

254
00:12:28,000 --> 00:12:30,000
specific numbers in advance with
metrics. 

255
00:12:30,100 --> 00:12:32,400
Then with observability. 
You've captured it in this very 

256
00:12:32,400 --> 00:12:35,600
wide event, which captures all 
that context and it says all of 

257
00:12:35,600 --> 00:12:38,300
these things are linked together
by this one request from the 

258
00:12:38,300 --> 00:12:40,900
users perspective. 
So you can then ask any 

259
00:12:40,900 --> 00:12:42,700
combination of question from 
that on it. 

260
00:12:42,700 --> 00:12:45,000
So monitor is about from the 
perspective of the service. 

261
00:12:45,200 --> 00:12:47,500
Observability is Perspective of 
the user. 

262
00:12:47,600 --> 00:12:51,000
What is the users experience? 
Like which I think is super 

263
00:12:51,000 --> 00:12:54,200
important. 
So the user for monitoring and 

264
00:12:54,200 --> 00:12:58,000
metrics is typically Ops. 
The user for observability is 

265
00:12:58,000 --> 00:13:01,000
typically people who are writing
code, people who are shipping 

266
00:13:01,000 --> 00:13:03,400
code every day, who want to 
understand the magical 

267
00:13:03,400 --> 00:13:06,600
conjunction between your code, 
your infrastructure, this point 

268
00:13:06,600 --> 00:13:08,700
in time, and that users 
experience. 

269
00:13:09,200 --> 00:13:11,700
So, I think to me, when I hear 
about it, it seems like it 

270
00:13:11,700 --> 00:13:14,100
requires a lot of mindset 
change. 

271
00:13:14,200 --> 00:13:16,100
First of all, like, capturing. 
All these hide. 

272
00:13:16,300 --> 00:13:19,500
Mentionable High cardinality 
metrics and also like 

273
00:13:19,500 --> 00:13:22,600
implementing that. 
So what do you think someone if 

274
00:13:22,600 --> 00:13:24,900
they want to explore this 
observability further? 

275
00:13:25,100 --> 00:13:26,900
What should they do to change 
their mindset? 

276
00:13:27,300 --> 00:13:29,000
Well, I think the shortcut is 
often. 

277
00:13:29,000 --> 00:13:31,700
Just seeing your own system, 
your own data in and 

278
00:13:31,700 --> 00:13:35,000
observability Tool which is why 
honeycomb has a really generous 

279
00:13:35,000 --> 00:13:37,400
free tier because we want people
to be able to sign up play 

280
00:13:37,400 --> 00:13:39,200
around with it. 
Even if they don't become our 

281
00:13:39,200 --> 00:13:40,700
users. 
I still want them to like 

282
00:13:40,700 --> 00:13:43,600
understand the Mind shift and 
experience the difference. 

283
00:13:43,800 --> 00:13:46,200
So I think that's the shortest 
quickest route to experience. 

284
00:13:46,300 --> 00:13:48,200
It to understanding it. 
There's a lot of things will 

285
00:13:48,200 --> 00:13:50,600
just click if you're used to 
trying to understand your own 

286
00:13:50,600 --> 00:13:52,200
system and you see it in 
different tool. 

287
00:13:52,200 --> 00:13:54,000
You already know the fields your
landscape. 

288
00:13:54,000 --> 00:13:55,800
And so it's a pretty quick and 
easy way. 

289
00:13:56,000 --> 00:13:58,400
Another way of thinking about 
this is that this became 

290
00:13:58,400 --> 00:14:01,800
necessary when the monolith 
began to decompose because if 

291
00:14:01,800 --> 00:14:04,400
follows failed with the model, 
if you could always attach a 

292
00:14:04,408 --> 00:14:06,200
debugger and step through the 
code. 

293
00:14:06,200 --> 00:14:09,000
Well, now you've blown up the 
monolith and God knows how many 

294
00:14:09,000 --> 00:14:11,400
services and every time it pops 
the network. 

295
00:14:11,600 --> 00:14:13,800
Whoops. 
You've lost all the context. 

296
00:14:13,800 --> 00:14:16,500
You can no longer Trace that 
code anymore, which is why When 

297
00:14:16,500 --> 00:14:18,800
you're Gathering the Telemetry 
for observability, the way we do

298
00:14:18,800 --> 00:14:20,500
it. 
Now, you come is we initialize a

299
00:14:20,508 --> 00:14:23,300
honeycomb event as soon as 
request enters the service and 

300
00:14:23,300 --> 00:14:25,300
then we pre populate it with 
everything. 

301
00:14:25,300 --> 00:14:28,400
We know about the environment, 
the language, the internals go 

302
00:14:28,400 --> 00:14:30,900
routines, anything about the 
context that was passed in 

303
00:14:30,900 --> 00:14:33,400
parameters. 
And then, while it's executing 

304
00:14:33,400 --> 00:14:35,500
in that service, you as a 
developer can go. 

305
00:14:35,700 --> 00:14:38,100
Oh this might be useful stuff it
in. 

306
00:14:38,300 --> 00:14:41,000
We also wrap a lot of common 
functions database calls. 

307
00:14:41,200 --> 00:14:43,800
So any time you do a database 
called, we wrap it and we record

308
00:14:43,800 --> 00:14:45,700
the time it took and The Rock 
query. 

309
00:14:45,700 --> 00:14:49,300
And the Nice query and results. 
And every time you do, if you 

310
00:14:49,300 --> 00:14:51,700
request, we wrap it and we give 
you the duration, and the 

311
00:14:51,700 --> 00:14:54,000
result, and all that stuff. 
And then when the request is 

312
00:14:54,000 --> 00:14:56,800
ready to exit or error from that
service, it gets packaged up 

313
00:14:56,800 --> 00:14:59,400
into that one arbitrarily wide 
track your data blob and shipped

314
00:14:59,400 --> 00:15:01,400
off to a honeycomb. 
So you can think of this as 

315
00:15:01,400 --> 00:15:04,500
like, packaging packaging along 
all of that context, that it 

316
00:15:04,500 --> 00:15:06,300
needs every time a pops, the 
wire. 

317
00:15:06,500 --> 00:15:08,700
Well, now you've got that 
context because we're passing it

318
00:15:08,700 --> 00:15:11,200
along with request. 
That's pretty cool. 

319
00:15:11,400 --> 00:15:14,500
So, in the first place who is 
responsible for implementing 

320
00:15:14,500 --> 00:15:16,700
this, because in the beginning, 
you said, Said, it should be 

321
00:15:16,708 --> 00:15:18,800
developers. 
First of all, there will be the 

322
00:15:18,800 --> 00:15:21,300
main users of this. 
But as we all know, 

323
00:15:21,300 --> 00:15:24,600
observability monitoring these 
days are highly associated with 

324
00:15:24,600 --> 00:15:28,000
Ops, or the devops site. 
So, who should implement this 

325
00:15:28,000 --> 00:15:30,700
and how should someone actually 
think about? 

326
00:15:30,700 --> 00:15:32,400
Okay? 
What kind of questions that I 

327
00:15:32,400 --> 00:15:35,200
would ask about my system? 
And where does this? 

328
00:15:35,200 --> 00:15:38,000
Observability might be useful 
for my system down the road. 

329
00:15:38,600 --> 00:15:41,600
Absolutely anyone in the chain 
can take responsibility for 

330
00:15:41,600 --> 00:15:43,900
this. 
I think that most commonly, we 

331
00:15:43,900 --> 00:15:47,000
have Ops teams who get it. 
Set up on behalf of Developers 

332
00:15:47,000 --> 00:15:50,200
and start to teach them which is
I think a really beautiful 

333
00:15:50,200 --> 00:15:51,700
thing. 
I think that Ops teams are not 

334
00:15:51,700 --> 00:15:55,500
becoming any less necessary and 
increasingly their job is not to

335
00:15:55,500 --> 00:15:59,600
make the code run, its to help 
developers understand. 

336
00:15:59,600 --> 00:16:01,300
This is like the second wave of 
devops, right? 

337
00:16:01,400 --> 00:16:04,500
First wave of devops is like AA.
Simple, you must learn to write 

338
00:16:04,500 --> 00:16:07,400
codes like, okay. 
Okay, we get the message and now

339
00:16:07,400 --> 00:16:09,500
it's like, okay, software 
Engineers, it's your turn. 

340
00:16:09,500 --> 00:16:12,100
It's your turn to learn to write
operable Services. 

341
00:16:12,100 --> 00:16:14,900
It's your turn to learn, to 
support the services, and to 

342
00:16:14,900 --> 00:16:18,100
build systems that are Not too 
expensive to maintain but we're 

343
00:16:18,100 --> 00:16:19,900
here for you. 
We will help you. 

344
00:16:20,200 --> 00:16:22,900
So I think that sometimes it's 
the developers who take it upon 

345
00:16:22,900 --> 00:16:25,200
themselves to bring 
observability and often. 

346
00:16:25,200 --> 00:16:27,400
It's the Ops teams who bring it 
in, on behalf of their 

347
00:16:27,400 --> 00:16:30,000
developers often. 
It's execs, who are like they've

348
00:16:30,000 --> 00:16:31,400
been paying attention and 
they've got their ear to the 

349
00:16:31,400 --> 00:16:32,500
ground. 
They know that systems are 

350
00:16:32,500 --> 00:16:36,400
becoming impossible to run and 
scale and maintained without the

351
00:16:36,400 --> 00:16:39,500
sort of tooling because forever 
the way that we've been doing is

352
00:16:39,500 --> 00:16:42,700
has been by guessing what we see
something wrong. 

353
00:16:42,800 --> 00:16:46,700
We guess based on past outages 
and battle scars were like, I 

354
00:16:46,700 --> 00:16:49,000
think it's this, right? 
And then we go and look for 

355
00:16:49,000 --> 00:16:50,900
evidence that were right, that 
works really. 

356
00:16:50,900 --> 00:16:52,200
Well. 
When you have a lot of people 

357
00:16:52,200 --> 00:16:54,300
who've been there for a very 
long time who have a lot of 

358
00:16:54,300 --> 00:16:57,800
context in their heads and the 
systems aren't changing that 

359
00:16:57,800 --> 00:16:59,700
much. 
But when the system starts 

360
00:16:59,700 --> 00:17:03,200
breaking in a novel way every 
single day, it doesn't, do you 

361
00:17:03,200 --> 00:17:05,400
much good? 
So I think that it doesn't 

362
00:17:05,400 --> 00:17:08,200
matter who takes it upon 
themselves to do this as long as

363
00:17:08,200 --> 00:17:12,099
someone does, because it is very
important because people burn 

364
00:17:12,099 --> 00:17:14,500
out teams. 
This is an ethical issue. 

365
00:17:14,500 --> 00:17:17,599
I believe this is a Humane it. 
Issue, we've all grown up 

366
00:17:17,599 --> 00:17:20,599
working in the tech industry 
accepting a certain amount of 

367
00:17:20,599 --> 00:17:24,200
self-abuse just like masochism, 
an Ops is just Infamous for 

368
00:17:24,200 --> 00:17:25,800
this. 
Well, throw ourselves on the 

369
00:17:25,800 --> 00:17:28,099
grenade, drag ourselves into the
meetings. 

370
00:17:28,200 --> 00:17:30,400
Just like in the morning, like, 
I've been up all night. 

371
00:17:30,500 --> 00:17:33,400
It's like a badge of honor for 
us, which it was fun. 

372
00:17:33,500 --> 00:17:36,900
I enjoyed being the wizard who 
points at a graph and goes, so 

373
00:17:37,500 --> 00:17:40,300
that's super fun, but it doesn't
scale very well. 

374
00:17:40,400 --> 00:17:42,000
And our systems increasingly 
don't reward. 

375
00:17:42,000 --> 00:17:44,900
That kind of magical thinking 
especially these days when 

376
00:17:44,900 --> 00:17:48,000
people are using lots and More 
microservices distributed 

377
00:17:48,000 --> 00:17:50,600
systems even platforms like 
Cloud where you have so many 

378
00:17:50,600 --> 00:17:54,200
services first, because whenever
you have a platform, you're 

379
00:17:54,200 --> 00:17:58,000
inviting your users chaos to 
live at your house and you're 

380
00:17:58,000 --> 00:18:00,900
responsible for it. 
So can this observation T 

381
00:18:00,900 --> 00:18:04,100
concept be useful monitoring 
business metrics as well. 

382
00:18:04,100 --> 00:18:07,300
I think that the separation 
between business and Technical 

383
00:18:07,300 --> 00:18:09,700
metrics is pretty arbitrary and 
detrimental. 

384
00:18:09,700 --> 00:18:12,800
In fact, I think that you want 
everyone to be reading off the 

385
00:18:12,800 --> 00:18:15,000
same answer sheet. 
You want everyone in the company

386
00:18:15,000 --> 00:18:16,200
to have you seen view of 
reality. 

387
00:18:16,200 --> 00:18:19,000
Reality and to the extent that 
you can all be looking at the 

388
00:18:19,008 --> 00:18:20,800
same numbers. 
Well, that's just a lot of 

389
00:18:20,800 --> 00:18:22,100
argument. 
You don't have to have. 

390
00:18:22,200 --> 00:18:25,900
I believe that tools can create 
silos because the borders of 

391
00:18:25,900 --> 00:18:27,900
your tool is the borders of your
knowledge. 

392
00:18:28,000 --> 00:18:30,000
I've been in so many meetings, 
where you spend more time. 

393
00:18:30,000 --> 00:18:33,200
Arguing about what was true 
because of what your tool said 

394
00:18:33,300 --> 00:18:35,800
versus the actual problem that 
you're trying to solve together.

395
00:18:36,400 --> 00:18:39,700
So maybe if you can mention few 
attributes, I know you have 

396
00:18:39,700 --> 00:18:43,400
metrics, you have maybe logging 
and you maybe have traces likes 

397
00:18:43,400 --> 00:18:46,000
pens and things like that. 
What are the things that are? 

398
00:18:46,300 --> 00:18:49,200
Crucial in any distributor 
systems these days. 

399
00:18:49,700 --> 00:18:53,600
I mean metrics logs and traces 
are just data formats and you 

400
00:18:53,600 --> 00:18:56,800
can derive all of them from the 
arbitrarily wide structured data

401
00:18:56,800 --> 00:18:59,100
blob that I was just describing.
You can derive your metrics from

402
00:18:59,100 --> 00:19:00,500
it. 
You can drive your log lines 

403
00:19:00,500 --> 00:19:02,000
from it. 
You can direct your spans from 

404
00:19:02,000 --> 00:19:03,200
it. 
You can't go in the other 

405
00:19:03,200 --> 00:19:06,200
direction. 
You can't go from a metric to a 

406
00:19:06,208 --> 00:19:07,100
white truck. 
Sure blood. 

407
00:19:07,200 --> 00:19:09,600
You can't go from a log line, to
a wide structure blog. 

408
00:19:09,800 --> 00:19:12,400
So I really think that we need 
to stop thinking about this in 

409
00:19:12,400 --> 00:19:15,700
terms of the archaic tooling 
that we've inherited and start 

410
00:19:15,700 --> 00:19:18,500
thinking about At it, in terms 
of the use, we get out of the 

411
00:19:18,500 --> 00:19:20,600
system. 
And I feel like the move to 

412
00:19:20,608 --> 00:19:22,800
these arbitrarily white shark 
today to blogs is inevitable, 

413
00:19:22,800 --> 00:19:25,000
but it also shouldn't be a big 
deal for people. 

414
00:19:25,000 --> 00:19:26,500
Right? 
If you squint, they're just 

415
00:19:26,500 --> 00:19:28,200
logs. 
They're just structured that 

416
00:19:28,200 --> 00:19:31,900
race is just a wide log line 
that has a couple of dedicated 

417
00:19:31,900 --> 00:19:34,200
expand ID fields, and Trace ID 
Fields. 

418
00:19:34,400 --> 00:19:35,900
So I think it's kind of a red 
herring. 

419
00:19:36,000 --> 00:19:39,500
It pisses me off that so many 
Legacy tools are just like you 

420
00:19:39,500 --> 00:19:42,900
definitely metrics logs and 
traces, why because they happen 

421
00:19:42,900 --> 00:19:45,600
to have metrics products, 
logging products and tracing 

422
00:19:45,600 --> 00:19:48,200
products that they What to sell 
you and if they're selling you 

423
00:19:48,200 --> 00:19:50,400
those three products and you're 
paying just saved your data, 

424
00:19:50,400 --> 00:19:53,500
three different places three 
different ways and they can't 

425
00:19:53,500 --> 00:19:55,600
talk to each other. 
So I see this as a really 

426
00:19:55,600 --> 00:19:59,100
cynical Ploy on behalf of the 
entrenched Legacy, this Punk's 

427
00:19:59,100 --> 00:20:00,900
in the new relics and that data 
dogs are the world. 

428
00:20:00,900 --> 00:20:02,700
They count up all the products. 
They want to sell you in there. 

429
00:20:02,700 --> 00:20:05,400
Like this is how many you need 
and it's like, no you don't. 

430
00:20:05,500 --> 00:20:06,800
What you need is the 
functionality. 

431
00:20:07,300 --> 00:20:10,300
Maybe you can share a little bit
more about honeycomb for people 

432
00:20:10,300 --> 00:20:13,200
who haven't used it before. 
I must have haven't used it 

433
00:20:13,200 --> 00:20:16,000
personally, but I heard a lot of
rave reviews about it. 

434
00:20:16,200 --> 00:20:19,500
So maybe we can share a little 
bit how honeycomb can help and 

435
00:20:19,500 --> 00:20:21,900
what are some of those tooling? 
Like what you said, they sell 

436
00:20:21,900 --> 00:20:25,600
you as a suite of products could
not achieve compatibility comb. 

437
00:20:26,000 --> 00:20:29,100
Well, so, you know, there's a 
narcissism of small differences.

438
00:20:29,400 --> 00:20:31,800
Of course, we're all trying to 
solve the same problems here. 

439
00:20:31,800 --> 00:20:35,100
So like for example, we usually 
start all of us, universally. 

440
00:20:35,100 --> 00:20:37,800
We usually start our debugging 
experience by looking at metrics

441
00:20:37,800 --> 00:20:39,800
graph. 
We see a spike in errors of my 

442
00:20:39,800 --> 00:20:41,700
God. 
There's a problem then because 

443
00:20:41,700 --> 00:20:45,400
you can't slice and dice metrics
arbitrarily, you typically jump 

444
00:20:45,400 --> 00:20:47,500
over to your lung. 
Tool and you start just trying 

445
00:20:47,500 --> 00:20:49,800
to visually correlate. 
Well, that spiked hair is looks 

446
00:20:49,800 --> 00:20:52,100
like this over here. 
It's not really science. 

447
00:20:52,100 --> 00:20:54,300
But you know, you try and find 
the same thing around the same 

448
00:20:54,300 --> 00:20:56,700
time, then maybe you want to 
trace it or something. 

449
00:20:56,700 --> 00:20:59,600
So you pick out a tray side you 
pick out a request ID and then 

450
00:20:59,600 --> 00:21:01,900
you jump over to your tracing 
tool and you paste it and you 

451
00:21:01,900 --> 00:21:04,000
hope that one got captured. 
And so you're just visually 

452
00:21:04,000 --> 00:21:06,800
jumping around and you the human
or in the middle of the glue. 

453
00:21:07,000 --> 00:21:09,700
Well, you do exactly the same 
thing and how do you home only? 

454
00:21:09,700 --> 00:21:12,600
You don't jump around you just 
you look at the graph. 

455
00:21:12,700 --> 00:21:14,300
You see there's a spike or 
something. 

456
00:21:14,700 --> 00:21:16,900
Well, the way we don't honeycomb
is he Just draw a little box 

457
00:21:16,900 --> 00:21:19,000
around, this is what I'm 
interested in and then we can 

458
00:21:19,000 --> 00:21:21,700
pre-compute for you for all the 
dimensions inside the box. 

459
00:21:21,700 --> 00:21:24,100
He said, you're interested in 
and outside the Baseline, and 

460
00:21:24,100 --> 00:21:25,900
then we dip them and then we 
sort them. 

461
00:21:26,100 --> 00:21:28,000
So, all the ones that are 
different rise up to the top, 

462
00:21:28,000 --> 00:21:30,700
and then you can click on one 
and just say, she'll be this 

463
00:21:30,700 --> 00:21:32,500
traced to me, example, trace for
this. 

464
00:21:32,800 --> 00:21:35,400
So you're doing exactly the same
thing but you know that you're 

465
00:21:35,400 --> 00:21:37,400
dealing with the same data 
because you're not jumping 

466
00:21:37,400 --> 00:21:38,700
around. 
The cool thing. 

467
00:21:38,700 --> 00:21:40,300
Is it? 
Because traces and moments were 

468
00:21:40,300 --> 00:21:41,900
just like two sides of the same 
coin. 

469
00:21:42,000 --> 00:21:45,000
Well, it turns out that Tracy 
was just visualizing by time. 

470
00:21:45,200 --> 00:21:47,600
So you're dealing with it. 
The same events, exactly the 

471
00:21:47,600 --> 00:21:50,600
same data stored, only one time,
but you're able to turn it 

472
00:21:50,600 --> 00:21:53,200
around, inspect it in all the 
different ways to try and find 

473
00:21:53,200 --> 00:21:55,200
the anomalies. 
I think, the Bubble Up thing 

474
00:21:55,200 --> 00:21:58,500
that we've done is like, it's a 
game changer because what it did

475
00:21:58,500 --> 00:22:01,400
was it replaced the manual 
process of what we used to do at

476
00:22:01,400 --> 00:22:03,700
parse was scuba. 
What we used to do is go. 

477
00:22:03,700 --> 00:22:04,900
Okay. 
There's a spike. 

478
00:22:05,000 --> 00:22:07,400
Well, let's see. 
Is it for all and points? 

479
00:22:07,600 --> 00:22:10,200
No, it's just for the endpoints 
that are like in points. 

480
00:22:10,400 --> 00:22:12,200
Well, is it for all the right 
and points? 

481
00:22:12,500 --> 00:22:15,500
No, it's just the ones that are 
writing to say mongodb. 

482
00:22:15,500 --> 00:22:17,800
Well is It to all the mongodb 
and buts. 

483
00:22:17,800 --> 00:22:20,900
Well, no, it's only airing to 
Feast three primaries. 

484
00:22:21,000 --> 00:22:22,300
Weld, what do they have in 
common? 

485
00:22:22,400 --> 00:22:24,800
Or is it to all of them? 
Well, no, it's just this 

486
00:22:24,800 --> 00:22:27,000
application idea. 
You're following the trail of 

487
00:22:27,000 --> 00:22:29,300
breadcrumbs, which is let me 
point out. 

488
00:22:29,300 --> 00:22:32,300
Vastly preferable to guessing 
and looking for evidence of. 

489
00:22:32,308 --> 00:22:33,300
You're right. 
Right here. 

490
00:22:33,300 --> 00:22:35,400
You're actually following the 
trail of bread crumbs to the 

491
00:22:35,400 --> 00:22:38,800
answer every time, but Bubble Up
did is it just replace that 

492
00:22:38,800 --> 00:22:41,600
whole iterative process because 
we pre compute them and we show 

493
00:22:41,600 --> 00:22:43,900
you them all at once yours like 
Dropbox group. 

494
00:22:43,900 --> 00:22:45,700
There's the answer, which is 
pretty cool. 

495
00:22:46,200 --> 00:22:49,300
This is where we hear a lot 
these days about AI Ops and like

496
00:22:49,300 --> 00:22:51,400
machine learning and all this 
bullshit. 

497
00:22:51,500 --> 00:22:54,100
I have lots of strong feelings 
on this topic, but I feel like 

498
00:22:54,200 --> 00:22:56,500
I've never want to take the 
human out of the driver's seat, 

499
00:22:56,500 --> 00:22:58,700
but I do want to look for ways 
for to make machines. 

500
00:22:58,700 --> 00:23:01,000
What machines are good at 
machines are good at crunching, 

501
00:23:01,000 --> 00:23:04,000
lots of numbers to let humans do
what humans are good at which is

502
00:23:04,000 --> 00:23:07,200
attaching meaning to things. 
If you see a spike, you don't 

503
00:23:07,200 --> 00:23:10,100
actually know if that was good 
or bad or something. 

504
00:23:10,100 --> 00:23:13,000
Expected to see something you 
wanted to see, you don't know 

505
00:23:13,000 --> 00:23:15,300
that until the human is attached
me to that. 

506
00:23:15,400 --> 00:23:18,400
And then the Computer can crunch
a bunch of numbers and back up 

507
00:23:18,400 --> 00:23:21,600
the meaning assigned to it. 
So I don't want any developer to

508
00:23:21,600 --> 00:23:24,100
give up that centrality of be in
the driver's seat. 

509
00:23:24,100 --> 00:23:26,900
But I do want to look for ways 
to take out the repetitive. 

510
00:23:26,900 --> 00:23:30,700
The loop just like is it this is
it that we can collapse a lot of

511
00:23:30,700 --> 00:23:33,200
that work so that you just have 
to point and click and 

512
00:23:33,200 --> 00:23:37,400
understand the way you described
it actually sounds to me as if 

513
00:23:37,400 --> 00:23:39,400
like, I'm Googling something 
right? 

514
00:23:39,600 --> 00:23:42,600
No problem. 
I start from google.com such one

515
00:23:42,600 --> 00:23:46,300
thing and it brings me to more 
and more links until I get Yeah,

516
00:23:46,300 --> 00:23:50,500
so it's about starting up high 
and methodically working your 

517
00:23:50,500 --> 00:23:53,800
way to the answer is a process 
that we're all familiar with and

518
00:23:53,800 --> 00:23:55,600
our tools just haven't supported
it. 

519
00:23:55,600 --> 00:23:57,300
We've just had to make these 
wildly too fancy. 

520
00:23:57,500 --> 00:23:58,000
One. 
Other thing. 

521
00:23:58,000 --> 00:24:00,400
I will point out is that 
something philosophically a 

522
00:24:00,400 --> 00:24:03,400
honeycomb that we really believe
it is the power of the team 

523
00:24:03,600 --> 00:24:05,600
because whenever we're working 
on these complex security 

524
00:24:05,600 --> 00:24:07,800
systems. 
I'm an expert in my corner of 

525
00:24:07,800 --> 00:24:09,600
it, that service that I'm 
writing right now. 

526
00:24:09,600 --> 00:24:10,700
Like the thing that I'm 
building. 

527
00:24:10,700 --> 00:24:12,700
I know everything about it. 
I know the variable names. 

528
00:24:12,700 --> 00:24:16,800
I know rather Gremlins live, but
I don't know your Art nearly as 

529
00:24:16,800 --> 00:24:18,800
well yet. 
When I'm debugging, I have to 

530
00:24:18,800 --> 00:24:20,500
take the whole system into 
account. 

531
00:24:20,600 --> 00:24:22,900
So we talked a lot about how can
we bring everyone up to the 

532
00:24:22,900 --> 00:24:25,600
level of the best debugger and 
every single corner of the 

533
00:24:25,600 --> 00:24:27,500
system? 
Well, we can do that by 

534
00:24:27,500 --> 00:24:30,600
piggybacking on the way that I 
interact with my system as an 

535
00:24:30,600 --> 00:24:33,100
expert and way you interact with
your system is an expert. 

536
00:24:33,100 --> 00:24:35,500
So if I get paged about 
something, maybe it's looks like

537
00:24:35,508 --> 00:24:37,400
a, my SQL problem. 
And I don't know anything about 

538
00:24:37,400 --> 00:24:40,300
my sequel, but I know that the 
experts on the team are like, 

539
00:24:40,300 --> 00:24:42,700
Ben and Emily. 
And I feel like we had an outage

540
00:24:42,700 --> 00:24:44,500
like this like last 
Thanksgiving. 

541
00:24:44,500 --> 00:24:47,200
So I just want to go look at 
like Any of them on colic? 

542
00:24:47,200 --> 00:24:49,400
What did they do? 
What was meaningful enough to 

543
00:24:49,400 --> 00:24:50,400
them? 
That they would run it a bunch 

544
00:24:50,400 --> 00:24:51,400
of times. 
Right? 

545
00:24:51,400 --> 00:24:53,700
What did they tag and put into a
post-mortem? 

546
00:24:53,800 --> 00:24:56,800
What did they add a comment to, 
or name and like putting their 

547
00:24:56,800 --> 00:24:58,700
personal arsenal of useful 
links? 

548
00:24:58,900 --> 00:25:01,400
You should wear grooves in the 
system as you use it and you 

549
00:25:01,400 --> 00:25:04,200
should be able to draw on the 
collective wisdom of your team 

550
00:25:04,300 --> 00:25:07,300
as experts in the system. 
I trust that so much more than I

551
00:25:07,308 --> 00:25:10,600
would ever trust any a. 
I so if I understand correctly, 

552
00:25:10,600 --> 00:25:13,400
the way it works, is you 
instrument your coat, your 

553
00:25:13,400 --> 00:25:15,900
services to give you this blob 
of data. 

554
00:25:16,200 --> 00:25:18,200
Is there any other mechanism 
that you use? 

555
00:25:18,400 --> 00:25:20,400
And how about the platforms that
you mentioned? 

556
00:25:20,500 --> 00:25:22,500
So how do you instrument the 
platforms? 

557
00:25:22,500 --> 00:25:25,400
Like the database is the cloud 
platform that you use? 

558
00:25:25,900 --> 00:25:28,300
Well, observability is 
fundamentally about the first 

559
00:25:28,300 --> 00:25:31,000
person perspective. 
It's about writing a library for

560
00:25:31,000 --> 00:25:34,000
your code. 
Being the first person actor. 

561
00:25:34,000 --> 00:25:37,000
Who's this is what I am doing. 
This is what I am seeing, but 

562
00:25:37,000 --> 00:25:40,400
data is data and it's better to 
have second best data that no 

563
00:25:40,400 --> 00:25:42,600
data at all. 
When you've got say a database 

564
00:25:42,600 --> 00:25:45,300
where you're my instrumenting it
and it's not your code. 

565
00:25:45,400 --> 00:25:47,500
You do want Some ways to get 
Telemetry out of it. 

566
00:25:47,500 --> 00:25:50,000
The easy answer is, will accept 
any structured data. 

567
00:25:50,000 --> 00:25:52,700
You can throw at us. 
It's most useful to you as a 

568
00:25:52,708 --> 00:25:54,800
debugger. 
If you've gathered into one or 

569
00:25:54,800 --> 00:25:56,600
trailer wide structure. 
Data Bob per request for 

570
00:25:56,600 --> 00:25:58,500
service. 
But, you know, if you have an 

571
00:25:58,500 --> 00:26:01,000
elk stack, you can just put a 
little stanza in your log. 

572
00:26:01,000 --> 00:26:03,500
Stash thing that will just 
duplicate the output streams and

573
00:26:03,500 --> 00:26:05,200
send us everything. 
You're sending to elq. 

574
00:26:05,300 --> 00:26:07,900
That can be a really nice little
bridge for people as they're 

575
00:26:07,900 --> 00:26:09,800
getting started because they 
already knows this data. 

576
00:26:09,800 --> 00:26:12,000
They know how to navigate it. 
You don't have to do anything 

577
00:26:12,000 --> 00:26:14,700
change any code that way for 
things like MySQL. 

578
00:26:14,800 --> 00:26:16,400
I'm a databases. 
Right. 

579
00:26:16,400 --> 00:26:19,700
So this is an old school shit. 
But what we do is we get three 

580
00:26:19,700 --> 00:26:22,300
sources of data for my SQL or 
mongodb or whatever. 

581
00:26:22,500 --> 00:26:24,500
We get the slow query log 
because there's some information

582
00:26:24,500 --> 00:26:26,000
that is only sent to the slow 
query log. 

583
00:26:26,200 --> 00:26:30,200
We also stream over the wire, we
do a tcpdump extreme over the 

584
00:26:30,200 --> 00:26:33,400
wire and we reconstruct all the 
transactions and then we ship 

585
00:26:33,400 --> 00:26:36,200
each transaction in to Honeycomb
as an event. 

586
00:26:36,200 --> 00:26:37,800
Because there's some 
information, you can only get 

587
00:26:37,800 --> 00:26:40,600
that way. 
And thirdly, we also run a Cron 

588
00:26:40,600 --> 00:26:43,600
job that connects every couple 
seconds to the command line 

589
00:26:43,600 --> 00:26:45,900
interface and just dumps out all
the internal stats. 

590
00:26:46,100 --> 00:26:49,300
Ship those in as a beds to those
three sources of data. 

591
00:26:49,500 --> 00:26:51,100
That's basically the sum total 
of everything. 

592
00:26:51,100 --> 00:26:53,600
You can get out of these 
databases and it's frustrating 

593
00:26:53,600 --> 00:26:56,200
because they clearly weren't 
designed, in a way to just, like

594
00:26:56,200 --> 00:26:58,700
output all the information that 
we would like them to have and 

595
00:26:58,700 --> 00:27:01,800
welcome place, but you can get a
pretty good approximation with 

596
00:27:01,800 --> 00:27:04,500
those three sources. 
So I'm sure you have plenty of 

597
00:27:04,500 --> 00:27:07,500
these, right? 
But any kind of cool use cases 

598
00:27:07,500 --> 00:27:09,500
that maybe your customers have 
shared. 

599
00:27:09,800 --> 00:27:12,500
The coolest thing. 
That was a big surprise to me 

600
00:27:12,500 --> 00:27:15,900
was when one of our customers, 
your to ago made it. 

601
00:27:16,000 --> 00:27:19,200
Library called build events for 
build pipelines and what they 

602
00:27:19,200 --> 00:27:22,400
did was basically, they made it 
so that you can instrument, your

603
00:27:22,400 --> 00:27:26,700
CI, CD pipeline as a trace. 
Just like your Trace. 

604
00:27:26,900 --> 00:27:29,900
So they like overloaded that a 
little bit if you put the build 

605
00:27:29,900 --> 00:27:33,500
of its library in your circle or
Travis or Jenkins or whatever, 

606
00:27:33,500 --> 00:27:36,100
then it will wrap. 
So it shows each test when it 

607
00:27:36,100 --> 00:27:38,700
fires off and when it finishes 
you can see how well the 

608
00:27:38,700 --> 00:27:42,000
paralyzation is doing, or if 
it's all sequential or where the

609
00:27:42,000 --> 00:27:44,700
time is going. 
That's so amazing because 

610
00:27:44,700 --> 00:27:45,900
Bringing Down the amount of 
time. 

611
00:27:46,100 --> 00:27:48,900
Takes to build and ship. 
Your code is so Central to I 

612
00:27:48,900 --> 00:27:51,400
think every team really should 
be paying attention to this but 

613
00:27:51,400 --> 00:27:53,500
there's it hasn't been a good 
way to visualize it and I 

614
00:27:53,500 --> 00:27:55,000
thought that was just fucking 
brilliant. 

615
00:27:55,300 --> 00:27:58,300
It's such a good use of 
visualization by time and that 

616
00:27:58,300 --> 00:28:00,900
had never occurred to me. 
So now we try and get people to 

617
00:28:00,900 --> 00:28:03,400
do it all the time because it's 
such a great gateway, drug to 

618
00:28:03,400 --> 00:28:05,200
observability because we're 
Engineers. 

619
00:28:05,200 --> 00:28:07,700
We love to figure things out. 
We love spotting and 

620
00:28:07,700 --> 00:28:10,300
efficiencies and some things 
seemed really hard and tough, 

621
00:28:10,300 --> 00:28:12,300
but that you just see them in 
the right tools. 

622
00:28:12,300 --> 00:28:15,500
Like, oh, duh. 
I can fix this, but I think 

623
00:28:15,500 --> 00:28:17,600
almost no one has this 
experience with the build events

624
00:28:17,600 --> 00:28:20,100
are like, oh my God, that's 
where all my time is going and 

625
00:28:20,108 --> 00:28:22,200
they go and fix it and it's just
you get such a dope, what you 

626
00:28:22,200 --> 00:28:24,900
did, such a high off of, it's 
just, it's so fun. 

627
00:28:25,400 --> 00:28:28,200
I never imagined it that way. 
But yeah, now that you mention 

628
00:28:28,200 --> 00:28:30,600
it, I think it's pretty cool. 
If we can have that data, 

629
00:28:30,600 --> 00:28:33,000
especially if you can correlate 
with the real production system,

630
00:28:33,000 --> 00:28:35,100
but what happened? 
During build time what happened 

631
00:28:35,100 --> 00:28:37,600
during development? 
Maybe can't ask mrs. 

632
00:28:37,600 --> 00:28:39,300
Behave differently during that 
time. 

633
00:28:39,300 --> 00:28:41,400
Yeah, so that's pretty cool. 
So you mentioned in the 

634
00:28:41,408 --> 00:28:45,100
beginning as well that you have 
to write your own database and 

635
00:28:45,100 --> 00:28:47,100
we can share a little bit. 
Because since you are database 

636
00:28:47,100 --> 00:28:50,800
person, why the current database
tuning is not good enough for 

637
00:28:50,800 --> 00:28:53,100
you. 
It comes down to the fact that 

638
00:28:53,100 --> 00:28:55,600
the trade-offs that we wanted to
make our not trade-offs that 

639
00:28:55,600 --> 00:28:59,400
anyone else would make for our 
purposes fast and mostly, right 

640
00:28:59,400 --> 00:29:03,000
is better than accurate. 
So, uh, we're fine with just 

641
00:29:03,000 --> 00:29:06,400
throwing away, some very small 
tail of data in order to get 

642
00:29:06,400 --> 00:29:08,700
like sub. 
S query Layton sees, this is the

643
00:29:08,700 --> 00:29:10,600
other theme of honeycomb. 
It's fuckin fast. 

644
00:29:10,800 --> 00:29:14,300
The 95th percentile for queries 
is like under a second and this 

645
00:29:14,300 --> 00:29:16,600
is really important because when
you're debugging, You want to be

646
00:29:16,600 --> 00:29:19,800
in a state of flow, wouldn't be 
asking this this this this can 

647
00:29:19,800 --> 00:29:22,500
imagine with Google took five 
minutes to return to search. 

648
00:29:22,600 --> 00:29:24,700
You be planning in advance. 
You be like, oh God. 

649
00:29:24,700 --> 00:29:26,000
Okay. 
I'm going to run this query and 

650
00:29:26,000 --> 00:29:27,200
then I'm going to go to the 
bathroom. 

651
00:29:27,500 --> 00:29:30,300
That's not good. 
So we need to really fast. 

652
00:29:30,300 --> 00:29:31,800
You're okay. 
With discarding some data. 

653
00:29:31,900 --> 00:29:35,200
We also knew that it was very 
core that we didn't want there 

654
00:29:35,200 --> 00:29:37,500
to be any schemas. 
We wanted people to be able to 

655
00:29:37,500 --> 00:29:40,600
throw in more Dimensions. 
Any point in time, a maturely 

656
00:29:40,600 --> 00:29:43,800
instrumented Services. 
Honeycomb will have 300 400 500 

657
00:29:43,800 --> 00:29:45,800
Dimensions. 
So the events are that wide. 

658
00:29:46,000 --> 00:29:47,800
We don't want the friction of, 
okay. 

659
00:29:47,800 --> 00:29:49,300
Now I'm going to add another 
one. 

660
00:29:49,600 --> 00:29:51,900
We want people to just be able 
to throw it in, forget about it.

661
00:29:51,900 --> 00:29:53,400
Stop sending it, forget about 
it. 

662
00:29:53,500 --> 00:29:56,700
So no scheming changes. 
No indexes, because indexes 

663
00:29:56,700 --> 00:29:59,400
again, they violate the theory 
of durability, which is that, 

664
00:29:59,400 --> 00:30:01,200
you shouldn't have to predict 
what's going to be fast. 

665
00:30:01,200 --> 00:30:03,600
What you're going to need to ask
if you'd all be equally fast to 

666
00:30:03,600 --> 00:30:05,800
query it on. 
So that meant that we needed to 

667
00:30:05,800 --> 00:30:09,000
build a columnist or they're not
a lot of Open Source freely 

668
00:30:09,000 --> 00:30:11,600
available columnar scores. 
We also knew that we needed the 

669
00:30:11,600 --> 00:30:14,300
data to be very distributed. 
We didn't want to spend all of 

670
00:30:14,300 --> 00:30:17,500
our time managing the database. 
A store like adding databases 

671
00:30:17,500 --> 00:30:20,600
for each user, the way it stored
is actually it's cool. 

672
00:30:20,700 --> 00:30:23,400
So when data comes in through 
the API, the events get dropped 

673
00:30:23,400 --> 00:30:26,200
into Kafka into a topic just for
you, your account. 

674
00:30:26,300 --> 00:30:30,000
And then the topic is consumed 
by n numbers of retrievers. 

675
00:30:30,300 --> 00:30:32,800
All of our sources are named 
after dogs, because we're a dog 

676
00:30:32,800 --> 00:30:34,500
company. 
So the retriever is just a pair 

677
00:30:34,500 --> 00:30:38,700
of them for each for, each will 
consume off the queue and then a

678
00:30:38,700 --> 00:30:41,000
thing that we did just unless 
you're too, we actually made our

679
00:30:41,000 --> 00:30:44,500
database, go serverless. 
So like At first we were storing

680
00:30:44,500 --> 00:30:47,500
them all on ssds and am. 
And then we were like would it 

681
00:30:47,500 --> 00:30:50,600
be cool if it was just an S3? 
We thought that the performance 

682
00:30:50,600 --> 00:30:54,800
hit would be huge but it wasn't 
so now like the queries actually

683
00:30:54,800 --> 00:30:59,100
they run as Lambda jobs and the 
data gets aged out to S3 after a

684
00:30:59,100 --> 00:31:02,400
few hours on disk and eventually
I think we'd like to make it so 

685
00:31:02,400 --> 00:31:05,300
that you can choose to age it 
out to your S3, buckets. 

686
00:31:05,500 --> 00:31:08,000
So that they're really just 
hosted on, you know, you can 

687
00:31:08,000 --> 00:31:11,200
post it forever for free. 
We have 60 days of storage for 

688
00:31:11,200 --> 00:31:13,600
free, which I think is the best 
in the industry and if we're 

689
00:31:13,600 --> 00:31:15,800
able to do that because we were 
able to just Outsource a desk. 

690
00:31:15,900 --> 00:31:17,100
3r. 
It's really cheap. 

691
00:31:17,300 --> 00:31:18,800
Wow. 
Sounds really cool. 

692
00:31:19,000 --> 00:31:20,300
Thanks for sharing that, of 
course. 

693
00:31:20,600 --> 00:31:23,300
So charity, you mentioned. 
Also, you're passionate about 

694
00:31:23,300 --> 00:31:25,500
building High performing team 
lately. 

695
00:31:25,500 --> 00:31:28,700
I've seen one of your talk about
CI CD and also the blog post. 

696
00:31:28,900 --> 00:31:30,800
So can you tell us a little bit 
more about? 

697
00:31:30,800 --> 00:31:32,700
What do you think about 
high-performing team? 

698
00:31:32,800 --> 00:31:35,100
What is actually a high 
performing team versus the low 

699
00:31:35,100 --> 00:31:38,300
performing on a high performing?
Team is one the kids to spend 

700
00:31:38,300 --> 00:31:42,100
almost all of their time solving
interesting problems that move 

701
00:31:42,100 --> 00:31:46,500
the business forward, not doing 
a lot of toil not Working on 

702
00:31:46,500 --> 00:31:48,400
things that they have to do in 
order to get to the things that 

703
00:31:48,400 --> 00:31:51,300
they want to do. 
Not slogging through fixing the 

704
00:31:51,300 --> 00:31:53,100
bill. 
Begin, not slogging through 

705
00:31:53,100 --> 00:31:57,200
outages, not waiting for test to
pass, not waiting for our 

706
00:31:57,200 --> 00:31:59,400
deploys to finish fixing 
something and then realizing it 

707
00:31:59,400 --> 00:32:02,200
was a different problem. 
Just like all of the stuff that 

708
00:32:02,200 --> 00:32:05,200
makes this job frustrating 
sometimes I think we tend to 

709
00:32:05,200 --> 00:32:07,500
take for granted that it just it
has to be that way. 

710
00:32:07,800 --> 00:32:10,300
I've now worked on a few High 
performing team for it. 

711
00:32:10,300 --> 00:32:13,400
Just it doesn't if you get your 
shit in order, you can have a 

712
00:32:13,408 --> 00:32:16,300
job where you spend most of your
time solving new and Interesting

713
00:32:16,300 --> 00:32:18,600
problems. 
And that is just it's a joy, 

714
00:32:18,600 --> 00:32:20,500
right? 
It brings a joy to your work 

715
00:32:20,500 --> 00:32:23,700
that is just it's Indescribable.
And in order to get there. 

716
00:32:23,700 --> 00:32:25,900
I think that focusing on the 
door metrics is a really good 

717
00:32:25,900 --> 00:32:28,000
place to start. 
How often you deploy. 

718
00:32:28,000 --> 00:32:29,700
How long does it take? 
How often is it fail? 

719
00:32:29,700 --> 00:32:32,700
How is it take to restore? 
Time to recovery and a lot of 

720
00:32:32,700 --> 00:32:34,800
improving. 
Those metrics, involves leveling

721
00:32:34,800 --> 00:32:37,400
up and observability seeing what
you're doing, like, putting in 

722
00:32:37,400 --> 00:32:40,200
your glasses before you go and 
you drive down the freeway and a

723
00:32:40,200 --> 00:32:42,400
lot of teams. 
They're really Flying Blind. 

724
00:32:42,600 --> 00:32:45,100
That means that a lot of their 
work is wasted. 

725
00:32:45,200 --> 00:32:47,700
I also feel like It's important 
to note that high performing 

726
00:32:47,700 --> 00:32:49,500
teams. 
They need to feel emotional 

727
00:32:49,500 --> 00:32:52,000
safety. 
They need to support each other.

728
00:32:52,000 --> 00:32:54,400
They need to be kind and the 
high performing teams. 

729
00:32:54,400 --> 00:32:57,700
You don't get them by just 
hiring the best people or hiring

730
00:32:57,700 --> 00:32:59,500
the best Engineers. 
You don't. 

731
00:32:59,500 --> 00:33:01,800
In fact, some of the people, 
I've known, who are the best 

732
00:33:01,800 --> 00:33:05,700
individual Engineers are pretty 
toxic to team's overall you, as 

733
00:33:05,700 --> 00:33:07,700
a leader. 
It's your responsibility not to 

734
00:33:07,700 --> 00:33:10,500
coddle the best Engineers. 
It's a responsibility to build 

735
00:33:10,500 --> 00:33:14,700
teams that have a very steady 
strong level of combined output 

736
00:33:14,700 --> 00:33:15,800
because that's what wins the 
race. 

737
00:33:15,900 --> 00:33:18,400
Race, it's not individuals. 
It's setting your team's up for 

738
00:33:18,400 --> 00:33:20,600
success. 
I just published a slide Deck 

739
00:33:20,600 --> 00:33:22,500
with the bunch of steps. 
The other day. 

740
00:33:22,700 --> 00:33:25,200
I do think that the number one, 
technical point that people 

741
00:33:25,200 --> 00:33:27,600
should focus on which, I know 
that this is something that 

742
00:33:27,600 --> 00:33:29,200
nobody would disagree with. 
Right? 

743
00:33:29,300 --> 00:33:30,900
We should have high performing 
teams. 

744
00:33:30,900 --> 00:33:32,500
But another time on moving the 
business forward. 

745
00:33:32,800 --> 00:33:35,000
No fuckers gonna disagree with 
that sentence. 

746
00:33:35,200 --> 00:33:39,100
The hard part is how how, and 
the place to start for almost 

747
00:33:39,100 --> 00:33:42,400
everybody I've ever talked to 
is, you need to shrink the 

748
00:33:42,400 --> 00:33:45,200
amount of time between when 
someone is written the code. 

749
00:33:45,300 --> 00:33:47,800
And when the His life. 
You should get that interval 

750
00:33:47,800 --> 00:33:51,300
down to 15 minutes or less. 
And if you get that, you get to 

751
00:33:51,300 --> 00:33:54,100
spend your time on a lot of 
problems that are much, much 

752
00:33:54,100 --> 00:33:56,500
higher up the value chain, but 
if you get that wrong, you're 

753
00:33:56,500 --> 00:33:57,800
just going to waste all your 
time. 

754
00:33:57,800 --> 00:34:01,300
Tending, to pathologies. 
It is really an efficient and 

755
00:34:01,300 --> 00:34:04,200
effective in my experience. 
If the number of people it takes

756
00:34:04,200 --> 00:34:07,400
to write and build. 
The system is say x number with 

757
00:34:07,400 --> 00:34:10,100
a 15 minute or less interval. 
Well, if that interval stretches

758
00:34:10,100 --> 00:34:12,000
two hours, you need twice as 
many people. 

759
00:34:12,300 --> 00:34:14,900
If that interval stretches two 
days, you need twice as many 

760
00:34:14,900 --> 00:34:16,800
people again. 
And if it's weeks, you'll need 

761
00:34:16,800 --> 00:34:20,199
twice as many again, because the
cost of context switching and 

762
00:34:20,199 --> 00:34:22,500
waiting on each other at the 
diff, get bigger. 

763
00:34:22,500 --> 00:34:26,600
And the reviews take longer and 
now you need a dedicated SRE 

764
00:34:26,600 --> 00:34:29,500
team to like manage all of the 
deploys in the failures in the 

765
00:34:29,500 --> 00:34:32,100
Cheetahs, get patched up. 
It's just as desk by rho. 

766
00:34:32,300 --> 00:34:34,400
So that's the place that I think
everyone needs to start is 

767
00:34:34,400 --> 00:34:37,300
getting that fully automated and
15 minutes or less and then 

768
00:34:37,300 --> 00:34:40,500
everything is going to get so 
much easier for you or in short.

769
00:34:40,500 --> 00:34:43,400
It's continuous delivery, right?
So that's what the team should 

770
00:34:43,400 --> 00:34:45,500
Aspire for continuous discrete 
for real. 

771
00:34:46,300 --> 00:34:50,000
So 15 minutes to me, that sounds
really short amount of time. 

772
00:34:50,000 --> 00:34:52,800
And there's so many things that 
people wants to do in the 

773
00:34:52,800 --> 00:34:54,699
pipeline. 
Like, for example, automated 

774
00:34:54,699 --> 00:34:57,100
test performance test, security 
test, whatever test. 

775
00:34:57,200 --> 00:35:01,700
So is that really important to 
have 15 minutes as Max limit? 

776
00:35:01,700 --> 00:35:03,200
Yes. 
I feel like I'm being generous 

777
00:35:03,200 --> 00:35:05,300
with that. 
It is important because you 

778
00:35:05,300 --> 00:35:07,800
don't want people to have enough
time in there to be able to 

779
00:35:07,800 --> 00:35:10,700
shift context that moment. 
When you've written the code, 

780
00:35:10,700 --> 00:35:12,400
you want this to be a small dip,
right? 

781
00:35:12,400 --> 00:35:14,300
You want this to be like a few 
lines. 

782
00:35:14,400 --> 00:35:17,500
How quickly can you deploy? 
One line of code should be your 

783
00:35:17,500 --> 00:35:19,700
goal here, right? 
You want to be short enough that

784
00:35:19,700 --> 00:35:22,000
you hook it into people's 
physiological systems, their 

785
00:35:22,000 --> 00:35:24,600
muscle memory, you want all of 
your developers to go and look 

786
00:35:24,600 --> 00:35:26,200
at their code after they shipped
it. 

787
00:35:26,200 --> 00:35:28,200
So, it needs to be short enough 
that it hooks into your 

788
00:35:28,200 --> 00:35:30,700
physical, like expectation. 
Just like, you don't feel done, 

789
00:35:30,700 --> 00:35:32,100
until you've got a new looked at
it. 

790
00:35:32,200 --> 00:35:34,300
And so, that's an hour or more. 
I'm sorry. 

791
00:35:34,300 --> 00:35:36,800
That's too much time. 
Someone's gotten switched over 

792
00:35:36,800 --> 00:35:38,500
to something else, and that 
means that they flushed all of 

793
00:35:38,508 --> 00:35:41,300
this context of their head and 
they've gotten distracted and 

794
00:35:41,300 --> 00:35:42,600
they're not going to do it 
regularly. 

795
00:35:42,700 --> 00:35:44,500
And if it's an hour or more that
I guarantee, you're going to 

796
00:35:44,500 --> 00:35:46,900
start batching multiple. 
Changes up together. 

797
00:35:47,100 --> 00:35:49,500
When it's really important that 
you be shipping, one person's 

798
00:35:49,500 --> 00:35:52,900
change, set at a time because 
that creates ownership. 

799
00:35:53,000 --> 00:35:55,800
If you're change going up, 
you're going to go look at it. 

800
00:35:55,800 --> 00:35:59,700
If you know, it's your change 
and 1 to 20 of your co-workers 

801
00:35:59,700 --> 00:36:01,500
going out at some point in the 
next day. 

802
00:36:01,700 --> 00:36:03,200
You're not going to go look at 
it. 

803
00:36:03,200 --> 00:36:06,000
You need to construct that 
feedback loop and keep it crisp.

804
00:36:06,400 --> 00:36:10,000
And also notice that you are one
of the strongest proponent for 

805
00:36:10,000 --> 00:36:12,800
testing and production, right? 
Is that also one of the reason 

806
00:36:12,800 --> 00:36:14,700
why? 
Because you want to achieve this

807
00:36:14,700 --> 00:36:17,000
15 minutes, right? 
You Don't do a lot of testing 

808
00:36:17,000 --> 00:36:20,400
and there it all goes together. 
I think there's been a major sea

809
00:36:20,400 --> 00:36:23,500
change over the past five years.
In terms of startups that have 

810
00:36:23,500 --> 00:36:25,600
started, the way people are 
talking about this stuff. 

811
00:36:25,700 --> 00:36:28,600
But used to be that we put all 
this focus on pre-production 

812
00:36:28,600 --> 00:36:30,400
stuff. 
All of our energy went to like 

813
00:36:30,400 --> 00:36:33,100
every developer gets their own 
staging environment and oh, this

814
00:36:33,100 --> 00:36:35,300
pre-production stuff and 
everything but we've hit 

815
00:36:35,300 --> 00:36:37,900
diminishing returns a long time 
ago there. 

816
00:36:38,200 --> 00:36:40,000
And I feel like over the last 
five years. 

817
00:36:40,000 --> 00:36:42,700
We've started to focus correctly
much more on. 

818
00:36:42,900 --> 00:36:46,400
Okay, but now, what about 
production, we Tools for 

819
00:36:46,400 --> 00:36:48,400
production. 
They're like scalpels that are 

820
00:36:48,400 --> 00:36:50,200
very sensitive. 
Very precise. 

821
00:36:50,500 --> 00:36:52,500
Developer Cycles are the 
scarcest resource in our 

822
00:36:52,500 --> 00:36:54,500
universe. 
They're not infinite if we're 

823
00:36:54,500 --> 00:36:56,200
wasting them all in 
pre-production stuff. 

824
00:36:56,300 --> 00:36:58,400
Then we're left with nothing for
production. 

825
00:36:58,600 --> 00:37:00,800
I just think that the importance
needs to be inverted there. 

826
00:37:01,000 --> 00:37:03,000
We need to be thinking. 
First about production. 

827
00:37:03,100 --> 00:37:05,900
Do we have the tools that we 
need to ship safely and swiftly 

828
00:37:05,900 --> 00:37:09,200
and understand what's going on? 
And then give 80% to production,

829
00:37:09,200 --> 00:37:12,500
20% to pre-production set of 80%
of pre-production, and 20% of 

830
00:37:12,508 --> 00:37:14,500
production. 
But the point is not that 

831
00:37:14,500 --> 00:37:15,700
everyone should be testing 
production. 

832
00:37:15,800 --> 00:37:18,600
In the point is that everyone is
testing and production whether 

833
00:37:18,600 --> 00:37:22,400
you admit it or not and you're 
better off if you just admit it 

834
00:37:22,500 --> 00:37:25,900
and try to do it. 
Well don't deny deny deny and 

835
00:37:25,900 --> 00:37:28,300
then sneakily like SSH into see 
what's going on. 

836
00:37:28,500 --> 00:37:30,000
Now. 
Everybody has to test the 

837
00:37:30,008 --> 00:37:31,800
production you do. 
I do? 

838
00:37:31,900 --> 00:37:34,200
It's not embarrassing. 
It's a fact of life. 

839
00:37:34,400 --> 00:37:36,400
Now, how can we do it better? 
Yeah. 

840
00:37:36,400 --> 00:37:38,900
I mean I must admit. 
I also testing Productions most 

841
00:37:38,900 --> 00:37:41,700
of the times because you can't 
really predict what actually 

842
00:37:41,700 --> 00:37:43,400
happened. 
Yeah. 

843
00:37:43,400 --> 00:37:45,500
You have know what the gold 
standard is to capture. 

844
00:37:45,500 --> 00:37:47,700
And Play like 24 hours worth of 
traffic. 

845
00:37:47,900 --> 00:37:50,300
And I will say the closer you 
get to laying B on disk the book

846
00:37:50,300 --> 00:37:51,300
paranoid. 
You should be. 

847
00:37:51,500 --> 00:37:53,700
I have written this Suite of 
software three times for three, 

848
00:37:53,700 --> 00:37:56,300
different databases that 
captures 24 hours of traffic and

849
00:37:56,300 --> 00:37:58,100
replays it. 
Again and again under different 

850
00:37:58,100 --> 00:38:00,600
conditions and stuff. 
You should know when to do that.

851
00:38:00,600 --> 00:38:02,800
Major database upgrade. 
You should absolutely fucking do

852
00:38:02,800 --> 00:38:04,900
that. 
But every day when you're 

853
00:38:04,900 --> 00:38:08,400
shipping a few lines at a time, 
no, of course not. 

854
00:38:08,400 --> 00:38:12,000
But you should invest that 
energy into observability and if

855
00:38:12,000 --> 00:38:14,600
you want to get really precise 
and really you should be using 

856
00:38:14,600 --> 00:38:17,500
feature Flags, so, You can flip 
that on and off so that you can 

857
00:38:17,500 --> 00:38:19,400
decouple your releases from your
deploys. 

858
00:38:19,500 --> 00:38:21,300
You should invest in 
observability so that you can 

859
00:38:21,300 --> 00:38:23,800
see and canaries. 
So, if you're really scared 

860
00:38:23,800 --> 00:38:26,800
about a change, ship it to one 
percent of the traffic or ship 

861
00:38:26,800 --> 00:38:30,400
it, to one percent of the users 
or ship it to one node, build 

862
00:38:30,400 --> 00:38:33,100
the tools that let you have this
very high level of precision 

863
00:38:33,100 --> 00:38:36,100
around, who you're shipping it 
to and then the ability to 

864
00:38:36,100 --> 00:38:38,400
compare the traffic stream so 
that you can see what the 

865
00:38:38,400 --> 00:38:41,100
difference is error rates is or 
what the difference in latency 

866
00:38:41,100 --> 00:38:44,700
is or anything like that, build 
those tools to address your 

867
00:38:44,700 --> 00:38:46,800
paranoia. 
Don't say that you're not 

868
00:38:46,800 --> 00:38:49,900
testing and production. 
So I'm interested to dig deeper 

869
00:38:49,900 --> 00:38:53,400
about this 15 minutes. 
So what actually has to be done 

870
00:38:53,400 --> 00:38:56,300
in this 15 minutes apart from 
building software and also 

871
00:38:56,300 --> 00:38:58,300
packaging it and deploy it run 
tests. 

872
00:38:58,500 --> 00:39:01,300
Absolutely run tests. 
I know that some languages like 

873
00:39:01,300 --> 00:39:03,000
was girl. 
I hardly takes any time at all. 

874
00:39:03,000 --> 00:39:06,500
We can rush it to test but this 
is achievable even for things 

875
00:39:06,500 --> 00:39:09,700
like Ruby which is notoriously 
huge to package, you know, slow 

876
00:39:09,700 --> 00:39:10,600
to run. 
All this stuff. 

877
00:39:10,900 --> 00:39:13,100
Our friends at intercom who are 
the ones who came up with a 

878
00:39:13,107 --> 00:39:15,800
slogan that shipping is your 
company's heartbeat, which I I 

879
00:39:15,808 --> 00:39:19,200
really value and respect. 
They run a ruby monolith and 

880
00:39:19,200 --> 00:39:22,400
their entire build and test 
pipeline runs, and deploys, and 

881
00:39:22,400 --> 00:39:24,400
under 10 minutes. 
It can be done. 

882
00:39:24,400 --> 00:39:26,100
Well, this can absolutely be 
done. 

883
00:39:26,300 --> 00:39:29,000
It's not hard. 
It's just engineering work. 

884
00:39:29,200 --> 00:39:31,500
You just need to commit to doing
the ongoing work. 

885
00:39:31,600 --> 00:39:34,200
Setting yourself a limit set 
yourself a limit alert. 

886
00:39:34,200 --> 00:39:36,600
Would it goes off. 
Take it, seriously, invest in it

887
00:39:36,600 --> 00:39:39,000
over time and you can hold 
yourself to a higher standard. 

888
00:39:39,400 --> 00:39:41,200
So I'm mostly interested with 
this phrase. 

889
00:39:41,200 --> 00:39:43,000
Shipping is the heartbeat of 
your company. 

890
00:39:43,000 --> 00:39:45,200
Maybe you can tell us a little 
bit more about that. 

891
00:39:45,800 --> 00:39:48,100
This came from intercom and I 
adopted it cuz I love it so 

892
00:39:48,100 --> 00:39:50,500
much. 
Shipping for any tech company. 

893
00:39:50,500 --> 00:39:54,200
Giving value to our users is why
we exist shipping. 

894
00:39:54,200 --> 00:39:56,900
New changes should be new code 
where users should be absolutely

895
00:39:56,900 --> 00:40:02,600
as common as ordinary as 
uneventful, and is regular, it 

896
00:40:02,600 --> 00:40:05,400
should be a nothing. 
Nothing Burger, ask me how many 

897
00:40:05,400 --> 00:40:07,500
times a day we ship? 
I don't fucking know the trip 

898
00:40:07,500 --> 00:40:09,300
all the time like a couple times
an hour. 

899
00:40:09,300 --> 00:40:12,100
I don't know because we're 
making changes constantly and it

900
00:40:12,100 --> 00:40:15,100
is because those changes are 
small and uneventful that it's 

901
00:40:15,100 --> 00:40:17,300
not a big. 
Deal, I feel like we need to 

902
00:40:17,300 --> 00:40:20,300
invert the way that we think 
about this is this social change

903
00:40:20,300 --> 00:40:23,200
is a mindset change, but it's 
not a new thing. 

904
00:40:23,300 --> 00:40:26,000
The principles of cic have been 
around for what 15 years 

905
00:40:26,200 --> 00:40:28,900
accelerate was written with all 
that data years ago. 

906
00:40:28,900 --> 00:40:31,700
Like we've known this for a very
long time. 

907
00:40:31,900 --> 00:40:33,200
We just need to look at it into 
action. 

908
00:40:33,400 --> 00:40:36,100
And the thing is, this is so 
good for engineers Engineers, 

909
00:40:36,100 --> 00:40:38,600
who have worked with true. 
See, ICD are unwilling to ever 

910
00:40:38,600 --> 00:40:41,100
go back because it is like 
different profession. 

911
00:40:41,300 --> 00:40:44,900
It is so much more interesting 
and exciting and up to the 

912
00:40:44,900 --> 00:40:47,700
moment. 
See your real impact on users 

913
00:40:47,700 --> 00:40:50,800
lies like many times a day and 
that's fundamentally motivating 

914
00:40:50,800 --> 00:40:53,300
and inspiring. 
It's real hard to ever. 

915
00:40:53,300 --> 00:40:57,200
Be willing to go back to a 
situation where releases are so 

916
00:40:57,200 --> 00:41:00,200
far away from your lived 
experience or someone else's 

917
00:41:00,200 --> 00:41:02,700
problem. 
We don't want that and I think 

918
00:41:02,700 --> 00:41:05,100
this is related to the 
socio-technical. 

919
00:41:05,200 --> 00:41:07,000
Mm aspect that you mentioned, 
right? 

920
00:41:07,100 --> 00:41:09,300
Like in the first place. 
You mentioned, you don't need 

921
00:41:09,300 --> 00:41:11,400
all the high performer people in
your team. 

922
00:41:11,400 --> 00:41:13,500
You just need a team that works 
well together. 

923
00:41:13,600 --> 00:41:15,000
Maybe you can also share a 
little bit. 

924
00:41:15,000 --> 00:41:17,800
What we mean by By social 
technical aspect of a team. 

925
00:41:18,200 --> 00:41:20,500
Yeah. 
So for example, think of it this

926
00:41:20,500 --> 00:41:23,200
way. 
Imagine if New York Times is a 

927
00:41:23,300 --> 00:41:26,100
technical and social 
organization, imagine that all 

928
00:41:26,100 --> 00:41:28,600
of the people in the tech side, 
got flown to the Bahamas for a 

929
00:41:28,607 --> 00:41:31,100
month and they brought in a new 
set of people who are 

930
00:41:31,200 --> 00:41:34,300
everybody's experience talented,
good Engineers, Etc. 

931
00:41:34,500 --> 00:41:36,500
He was brought instead of 
Replacements to keep everything 

932
00:41:36,500 --> 00:41:38,000
running and then something 
breaks. 

933
00:41:38,300 --> 00:41:41,400
How long do you think it would 
take them to figure out and fix 

934
00:41:41,400 --> 00:41:43,500
even a very small problem? 
First of all, how do they get 

935
00:41:43,500 --> 00:41:45,900
into the system? 
It's a mind experiment to You 

936
00:41:45,900 --> 00:41:48,700
just how much of the system 
lives in our heads. 

937
00:41:49,000 --> 00:41:50,800
These people are not fungible. 
Right? 

938
00:41:50,800 --> 00:41:54,600
Engineers are not fungible. 
People are very important part 

939
00:41:54,600 --> 00:41:58,700
of the technical system and you 
can't just separate them. 

940
00:41:58,900 --> 00:42:01,000
I think it's really important. 
Especially as we're entering 

941
00:42:01,000 --> 00:42:03,000
this age with machine learning 
and AI. 

942
00:42:03,000 --> 00:42:06,100
This AI that just remind 
ourselves that no people are 

943
00:42:06,100 --> 00:42:08,700
really fucking important here. 
The part of the system that 

944
00:42:08,700 --> 00:42:12,100
lives in your head is a part of 
the system honeycomb. 

945
00:42:12,100 --> 00:42:14,900
We interview lots of Engineers 
and what's really important to 

946
00:42:14,900 --> 00:42:16,300
us as their communication. 
Ation skill. 

947
00:42:16,500 --> 00:42:19,300
Now, they need to be able to 
write code obviously, but the 

948
00:42:19,300 --> 00:42:21,800
real interview is not us. 
Looking at their code. 

949
00:42:21,800 --> 00:42:23,700
It says, talking to them about 
their code. 

950
00:42:23,800 --> 00:42:25,900
Just having a conversation 
about, well, talk to you about 

951
00:42:25,900 --> 00:42:27,800
your choices here. 
Why did you choose this? 

952
00:42:28,000 --> 00:42:31,000
What else might you have done or
like what trade-offs we did you 

953
00:42:31,000 --> 00:42:33,400
have in mind when you are doing 
this because there are so many 

954
00:42:33,400 --> 00:42:35,900
people who are capable of 
writing the great code but can't

955
00:42:35,900 --> 00:42:38,000
communicate about it. 
And those aren't the people that

956
00:42:38,000 --> 00:42:40,600
we want for our team because we 
believe that high performing 

957
00:42:40,600 --> 00:42:44,300
teams come from people who are 
ready willing and able to talk 

958
00:42:44,300 --> 00:42:46,500
about what they do. 
And They've done what they've 

959
00:42:46,500 --> 00:42:48,900
done without getting their ego, 
too wrapped up in it, but just 

960
00:42:48,900 --> 00:42:51,400
being like able to have a 
conversation about it. 

961
00:42:51,400 --> 00:42:53,800
Christina and I could have just 
hired all of our X Google X 

962
00:42:53,800 --> 00:42:55,900
Facebook, friends. 
We knew that we didn't want to 

963
00:42:55,900 --> 00:42:59,300
create a cultural bubble. 
So we made sure to go outside of

964
00:42:59,300 --> 00:43:01,500
our networks, but we were never 
looking for the best 

965
00:43:01,500 --> 00:43:02,900
programmers. 
We were looking for the best 

966
00:43:02,900 --> 00:43:05,800
communicators, the level at 
which this team performs. 

967
00:43:05,800 --> 00:43:07,900
It just, it blows me away. 
Every single day. 

968
00:43:08,000 --> 00:43:10,600
There are order of magnitude 
better than the elite category 

969
00:43:10,600 --> 00:43:12,700
and the door of metrics. 
And it's not because they're the

970
00:43:12,707 --> 00:43:14,800
flashiest. 
Coders is because they're dogged

971
00:43:14,800 --> 00:43:16,900
about improving. 
In their craft at this really 

972
00:43:16,900 --> 00:43:19,500
inspiring. 
So what else do you see from a 

973
00:43:19,500 --> 00:43:21,700
candidate? 
If you interview them apart from

974
00:43:21,700 --> 00:43:24,000
communication skills and some 
basic programming skills. 

975
00:43:24,000 --> 00:43:26,500
Of course, they need to have 
what other things that you look 

976
00:43:26,500 --> 00:43:29,600
for in an engineer. 
We look for humility. 

977
00:43:29,600 --> 00:43:33,200
We look for people who can be 
gently challenged and don't fall

978
00:43:33,200 --> 00:43:35,500
apart. 
We look for people who are 

979
00:43:35,500 --> 00:43:37,800
constantly, I guess growth 
mindset. 

980
00:43:37,800 --> 00:43:40,400
Is the term of art for it, which
feels a little corporate e to 

981
00:43:40,400 --> 00:43:43,200
me, but we want people to be 
able to come curious to a 

982
00:43:43,200 --> 00:43:45,300
problem. 
Not to come feel like they're 

983
00:43:45,300 --> 00:43:46,900
going to be. 
If I'd if it turns out that they

984
00:43:46,900 --> 00:43:48,600
don't know what they're doing. 
Because it turns out, we don't 

985
00:43:48,600 --> 00:43:50,400
know what we're doing, either 
all day long. 

986
00:43:50,400 --> 00:43:51,400
None of us know what we're 
doing. 

987
00:43:51,600 --> 00:43:54,300
Our company values. 
Are we have values that are like

988
00:43:54,300 --> 00:43:56,400
we hire adults. 
We don't have your family or 

989
00:43:56,400 --> 00:43:59,600
your whole life. 
But we also do, hire people who 

990
00:43:59,600 --> 00:44:01,400
take a lot of pride in their 
craft. 

991
00:44:01,400 --> 00:44:02,700
We don't want to hire people who
just want to work. 

992
00:44:02,700 --> 00:44:05,400
You just do it to pay the bills 
either because we take a lot of 

993
00:44:05,400 --> 00:44:07,600
pleasure. 
And what we do, nobody honestly 

994
00:44:07,600 --> 00:44:10,500
has more than four hours a day 
in them of hard, focused, 

995
00:44:10,500 --> 00:44:13,100
engineering labor and it's so 
much more important to me, that 

996
00:44:13,100 --> 00:44:15,500
people know how to manage their 
time to get them. 

997
00:44:15,700 --> 00:44:18,600
Themselves those four hours then
for them to like sit at their 

998
00:44:18,600 --> 00:44:21,400
desk 24 hours a day. 
We hire adults. 

999
00:44:21,500 --> 00:44:24,800
Their values are, everything is 
an experiment and fast and close

1000
00:44:24,800 --> 00:44:27,800
to ride is better than done and 
perfect, which trees is all the 

1001
00:44:27,808 --> 00:44:29,700
way back to manifesting in our 
storage and right? 

1002
00:44:29,700 --> 00:44:32,200
Like that's our philosophy for 
storing data, turns out. 

1003
00:44:32,200 --> 00:44:34,000
It's our philosophy for people 
as well. 

1004
00:44:34,300 --> 00:44:37,300
Feedback is a gift. 
Is another one because I think 

1005
00:44:37,300 --> 00:44:40,000
that so many pathologies in the 
modern workplace can be traced 

1006
00:44:40,000 --> 00:44:42,400
back to the fact that people are
scared to give each other 

1007
00:44:42,400 --> 00:44:45,500
feedback and so it builds up and
it becomes a big thing. 

1008
00:44:46,000 --> 00:44:48,900
And if we can just like 
deescalate that make it, not a 

1009
00:44:48,900 --> 00:44:52,100
big thing to be constantly 
giving and receiving feedback 

1010
00:44:52,100 --> 00:44:54,400
and to be able to give feedback,
knowing that we might be wrong 

1011
00:44:54,400 --> 00:44:56,100
about it. 
Just like your something that 

1012
00:44:56,100 --> 00:44:58,500
I've noticed I thought might 
help you because we're all on 

1013
00:44:58,500 --> 00:45:00,800
the same team, right? 
Like we should be able to help 

1014
00:45:00,800 --> 00:45:04,400
each other improve which is so 
easy to say and so hard to do 

1015
00:45:04,400 --> 00:45:06,400
because we all have our own 
personal damage. 

1016
00:45:06,500 --> 00:45:09,400
We all have our own prom has and
stuff around the stuff. 

1017
00:45:09,500 --> 00:45:12,000
So we're all constantly having 
to learn and unlearn bad 

1018
00:45:12,000 --> 00:45:15,200
behavioral patterns, but there 
was a couple of people have said

1019
00:45:15,200 --> 00:45:16,500
to me. 
They started working at 

1020
00:45:16,508 --> 00:45:19,000
honeycomb to like how you guys 
talk about your feelings and 

1021
00:45:19,000 --> 00:45:21,100
awful lot, and I'm just like 
embarrassed. 

1022
00:45:21,100 --> 00:45:22,100
It's okay. 
Yes. 

1023
00:45:22,300 --> 00:45:24,500
Female founded company. 
Yes, I guess we do talk about 

1024
00:45:24,500 --> 00:45:26,900
our feelings about, but you know
what, it's better than the 

1025
00:45:26,900 --> 00:45:30,000
alternative. 
Thanks for sharing all that. 

1026
00:45:30,000 --> 00:45:32,500
I think it's a really good 
Lessons Learned as well for 

1027
00:45:32,500 --> 00:45:35,400
other teams who would like to 
build High performing team, you 

1028
00:45:35,400 --> 00:45:38,100
know, we spend more time at work
with each other than we do at 

1029
00:45:38,100 --> 00:45:40,000
home with our partners and our 
families. 

1030
00:45:40,200 --> 00:45:42,500
I think that we shouldn't be 
embarrassed about talking about 

1031
00:45:42,500 --> 00:45:45,500
our feelings and being emotional
human beings at work. 

1032
00:45:45,700 --> 00:45:48,600
Because if you're not well, 
you're just faking it and I 

1033
00:45:48,600 --> 00:45:51,400
don't believe that lets you 
perform at a high level over the

1034
00:45:51,400 --> 00:45:53,800
long term. 
I agree with you on that. 

1035
00:45:54,000 --> 00:45:57,000
So one thing that you mentioned 
about Dora metrics, I think in 

1036
00:45:57,000 --> 00:46:00,300
some of the presentations I saw 
that you actually insert one 

1037
00:46:00,300 --> 00:46:02,500
moment trick not just a yes, you
metrics. 

1038
00:46:02,500 --> 00:46:05,000
So what is the fifth? 
Maybe if we can share I think 

1039
00:46:05,000 --> 00:46:08,400
that every team should be 
tracking how often someone gets 

1040
00:46:08,400 --> 00:46:11,100
paged out of hours. 
I strongly believe it's software

1041
00:46:11,100 --> 00:46:13,700
Engineers need to be on call for
their own code, but this comes 

1042
00:46:13,700 --> 00:46:15,700
hand in hand with commitment 
from management to make Make 

1043
00:46:15,700 --> 00:46:18,600
sure that does not suck. 
I'm not just saying software 

1044
00:46:18,600 --> 00:46:20,500
Engineers. 
You need to go be masochists to 

1045
00:46:20,500 --> 00:46:21,900
just like cops have been all 
this year. 

1046
00:46:22,100 --> 00:46:25,100
No, the reason to put software 
Engineers on calls because this 

1047
00:46:25,100 --> 00:46:27,900
is how we make it better. 
This is how we close that 

1048
00:46:27,900 --> 00:46:30,500
feedback loop, how we make it 
short, how we get things fixed 

1049
00:46:30,500 --> 00:46:33,100
quickly, so they don't get to 
infest and like become all 

1050
00:46:33,100 --> 00:46:36,000
infected and gross and big 
problems be fixing their small. 

1051
00:46:36,100 --> 00:46:38,200
So I think that these two have 
to go hand in hand. 

1052
00:46:38,400 --> 00:46:39,600
Yes. 
Developers need to be on call 

1053
00:46:39,600 --> 00:46:41,900
for their code. 
And yes manage music. 

1054
00:46:41,900 --> 00:46:44,300
Make sure it doesn't suck and 
probably compensate them for 

1055
00:46:44,300 --> 00:46:48,100
their time to I It's reasonable 
to expect any engineer who works

1056
00:46:48,100 --> 00:46:51,300
on a 24/7 highly available 
system should expect to get 

1057
00:46:51,300 --> 00:46:53,800
woken up twice a year or so, 
once or twice a year for their 

1058
00:46:53,800 --> 00:46:55,400
work. 
I think that's reasonable. 

1059
00:46:55,500 --> 00:46:58,200
I do that's compatible with an 
adult life. 

1060
00:46:58,300 --> 00:47:01,400
The exception being, if you have
a child that is waking up in the

1061
00:47:01,408 --> 00:47:03,300
middle of the night. 
I would never put one of those 

1062
00:47:03,300 --> 00:47:05,700
people on call. 
If you have a baby, you are out 

1063
00:47:05,700 --> 00:47:08,000
of the uncover rotation until 
your kid is regularly sleeping 

1064
00:47:08,000 --> 00:47:10,000
through the night. 
It's not fair to ask anyone to 

1065
00:47:10,000 --> 00:47:11,600
wake up for two things. 
Right? 

1066
00:47:11,800 --> 00:47:14,700
So with that caveat, these are 
human systems, right? 

1067
00:47:14,700 --> 00:47:16,400
So there are exceptions. 
To everything. 

1068
00:47:16,500 --> 00:47:19,800
I'm not actually saying every 
person must be on call at 

1069
00:47:19,800 --> 00:47:21,900
Facebook. 
I had a guy on my team who was 

1070
00:47:21,900 --> 00:47:23,700
totally willing. 
He wanted to share his part of 

1071
00:47:23,700 --> 00:47:27,400
the burden, but when he took the
pager, he got such anxiety and 

1072
00:47:27,400 --> 00:47:29,500
it wasn't because he was getting
called or page all the time. 

1073
00:47:29,700 --> 00:47:32,100
He was so afraid. 
He just had a personality that 

1074
00:47:32,100 --> 00:47:35,700
was just not compatible with it.
We tried for a couple months and

1075
00:47:35,700 --> 00:47:38,500
he gave it a good shot. 
But I was just like I just felt 

1076
00:47:38,500 --> 00:47:41,100
so bad for him and the whole 
team did right there just like, 

1077
00:47:41,100 --> 00:47:42,900
okay. 
No, Alan doesn't have to be in 

1078
00:47:42,900 --> 00:47:45,500
called what can Alan do instead 
and so Alan took over. 

1079
00:47:45,800 --> 00:47:48,600
Ownership of the build Pipeline 
and just like with build cop. 

1080
00:47:48,600 --> 00:47:51,100
So that was like technically 
more work but it was during 

1081
00:47:51,100 --> 00:47:53,500
business hours and the rest of 
us were totally fine to get the 

1082
00:47:53,508 --> 00:47:55,300
slack. 
So it's about pulling your own 

1083
00:47:55,300 --> 00:47:56,800
weight. 
It's about being willing to 

1084
00:47:56,800 --> 00:47:59,400
support your own code. 
It's about management. 

1085
00:47:59,500 --> 00:48:02,800
Making sure you have the time to
fix the things that need to be 

1086
00:48:02,800 --> 00:48:05,600
fixed because you can't just put
a long call and then tell them 

1087
00:48:05,600 --> 00:48:08,100
to build features all the time. 
If you're putting them on call 

1088
00:48:08,100 --> 00:48:09,900
it, you have to give them the 
time to fix the shit. 

1089
00:48:09,900 --> 00:48:12,100
So they're not getting woken up 
all the time and I just feel 

1090
00:48:12,100 --> 00:48:14,900
like having that metric and 
holding managers accountable for

1091
00:48:14,900 --> 00:48:17,000
that metric. 
You never promote a manager 

1092
00:48:17,000 --> 00:48:18,800
who's paging. 
Alerts are going off at all 

1093
00:48:18,800 --> 00:48:20,700
hours. 
That is just a sign of terrible 

1094
00:48:20,700 --> 00:48:22,600
management. 
Their team is going to burn out.

1095
00:48:22,700 --> 00:48:24,500
It should come down on them. 
The hardest. 

1096
00:48:25,000 --> 00:48:27,700
Wow, thanks for sharing that. 
I think it's really good key 

1097
00:48:27,700 --> 00:48:30,800
metrics, especially when you 
have so many distributed systems

1098
00:48:30,800 --> 00:48:33,100
in production with problems 
could happen at any point in 

1099
00:48:33,100 --> 00:48:34,800
time. 
And was, if you have a global 

1100
00:48:34,800 --> 00:48:37,300
system with your users come from
anywhere in the world. 

1101
00:48:37,400 --> 00:48:40,200
I think it's also critical to 
monitor this like how much you 

1102
00:48:40,200 --> 00:48:43,000
get paid tonight, right? 
Because that's what burns your 

1103
00:48:43,000 --> 00:48:47,400
team's up faster than anything. 
So one of your most popular blog

1104
00:48:47,400 --> 00:48:50,200
post is about engineer and 
manager pendulum. 

1105
00:48:50,400 --> 00:48:53,800
So because this podcast is also 
about technical leadership and 

1106
00:48:53,800 --> 00:48:56,200
also Engineering Management. 
Maybe you can share a little 

1107
00:48:56,200 --> 00:48:57,400
bit. 
What do you mean by this 

1108
00:48:57,400 --> 00:48:59,400
pendulum between engineering 
manager? 

1109
00:48:59,500 --> 00:49:01,900
Yeah. 
Well, when I became a manager I 

1110
00:49:01,900 --> 00:49:04,700
was told it was a one-way trip 
and I've heard this repeatedly. 

1111
00:49:04,800 --> 00:49:07,200
People are just like agonizing 
over whether to become managers 

1112
00:49:07,200 --> 00:49:09,100
because they see it as a one-way
trip. 

1113
00:49:09,100 --> 00:49:11,500
They're not sure if they can get
hired as an engineer afterwards.

1114
00:49:11,500 --> 00:49:13,600
They're not sure if they should.
You're often told that they 

1115
00:49:13,600 --> 00:49:16,800
shouldn't and I feel like this 
has said, the best technical 

1116
00:49:16,800 --> 00:49:19,700
leaders that I've ever worked 
with have been people who have 

1117
00:49:19,700 --> 00:49:22,500
spent time as managers because 
you learn things about how to 

1118
00:49:22,500 --> 00:49:25,400
help a team overcome obstacles 
and work as a unit, that you 

1119
00:49:25,400 --> 00:49:27,800
can't learn any other way. 
You learn things about how the 

1120
00:49:27,800 --> 00:49:29,200
business works. 
If you can't learn any other 

1121
00:49:29,200 --> 00:49:32,600
way, but has also, like has been
hands on within the past five 

1122
00:49:32,600 --> 00:49:35,600
years because when you take a 
step away from the day-to-day of

1123
00:49:35,600 --> 00:49:39,200
building shipping code, like 
you're on a path that diverges, 

1124
00:49:39,200 --> 00:49:40,800
right? 
And there comes a point where 

1125
00:49:40,800 --> 00:49:43,400
you are not an effective leader 
of people who are writing 

1126
00:49:43,400 --> 00:49:45,400
shipping code for the sake of 
your own career. 

1127
00:49:45,600 --> 00:49:48,600
You need to be cognizant of that
and are two different paths. 

1128
00:49:48,600 --> 00:49:50,600
You can take. 
If you want to continue managing

1129
00:49:50,600 --> 00:49:52,500
people. 
You can make it, your goal to 

1130
00:49:52,500 --> 00:49:53,800
work your way up. 
The ladder. 

1131
00:49:54,100 --> 00:49:56,800
Now, there are an order of 
magnitude fewer jobs at each 

1132
00:49:56,800 --> 00:49:59,200
level, as you go up from 
manager, to senior manager, to 

1133
00:49:59,200 --> 00:50:01,500
director or to, you know, see 
your director at VP or whatever.

1134
00:50:01,700 --> 00:50:04,700
There are fewer and fewer jobs. 
It is more and more competitive.

1135
00:50:04,800 --> 00:50:07,000
There's more and more bias 
involved, I think. 

1136
00:50:07,300 --> 00:50:09,800
But for people who love it, it 
could be very rewarding. 

1137
00:50:10,000 --> 00:50:12,800
But if you want to stay in a 
line manager, who manages 

1138
00:50:12,800 --> 00:50:15,400
Engineers who manages the people
who are writing shipping code, 

1139
00:50:15,700 --> 00:50:18,200
You're going to need to make 
your way back to the Well, from 

1140
00:50:18,200 --> 00:50:20,400
time to time. 
You can't go more than five 

1141
00:50:20,400 --> 00:50:23,000
years without building and 
shipping code regularly yourself

1142
00:50:23,000 --> 00:50:25,600
and maintain that level of 
tension and empathy, and 

1143
00:50:25,600 --> 00:50:28,300
immersion in the problem, set. 
Your engineers won't respect you

1144
00:50:28,300 --> 00:50:30,700
as much. 
You won't be able to mentor and 

1145
00:50:30,700 --> 00:50:34,300
develop Engineers as well. 
You won't have opinions that you

1146
00:50:34,300 --> 00:50:37,600
can trust about the technology. 
And there are lots of places out

1147
00:50:37,600 --> 00:50:39,600
there who just take this for 
granted. 

1148
00:50:39,800 --> 00:50:42,500
They're like manager, shouldn't 
know anything about technology. 

1149
00:50:42,600 --> 00:50:43,900
They shouldn't have the 
opinions. 

1150
00:50:44,100 --> 00:50:45,400
We rely on our tech leads for 
that. 

1151
00:50:45,800 --> 00:50:48,900
And that is a choice. 
I think it is a choice that is 

1152
00:50:48,900 --> 00:50:51,700
becoming less and less popular 
or prevalent because I think the

1153
00:50:51,700 --> 00:50:55,000
outcomes are materially worse. 
I think that it serves everyone.

1154
00:50:55,000 --> 00:50:58,100
When manager has opinions of 
their own that they can trust 

1155
00:50:58,100 --> 00:51:01,300
about what's going on. 
Now that said, you do have to 

1156
00:51:01,300 --> 00:51:03,400
train yourself, not just, you 
speak up all the time as a 

1157
00:51:03,408 --> 00:51:05,300
manager. 
This can be very humbling thing.

1158
00:51:05,300 --> 00:51:07,100
Right? 
Like many of us became managers 

1159
00:51:07,100 --> 00:51:09,900
because we were Top Dog, right? 
Like we were the most technical 

1160
00:51:09,900 --> 00:51:12,400
of the most senior whatever. 
But once you step out of that 

1161
00:51:12,400 --> 00:51:15,400
position and you're the manager,
it's your job to guide. 

1162
00:51:15,500 --> 00:51:18,700
People up to reclaim the oxygen 
that you once, breathe. 

1163
00:51:18,800 --> 00:51:20,900
It's your job to grow people 
into that space. 

1164
00:51:21,100 --> 00:51:24,300
And this can require giving up a
lot of ego on our parts, but its

1165
00:51:24,300 --> 00:51:26,800
necessary. 
It's the best way to grow people

1166
00:51:26,800 --> 00:51:28,700
up is to have a manager who 
actually understands what 

1167
00:51:28,700 --> 00:51:31,600
they're going through and can 
help guide and nudge and suggest

1168
00:51:31,600 --> 00:51:34,800
opportunities for them. 
So, I feel like this is a change

1169
00:51:34,800 --> 00:51:36,700
that needs to be fought on the 
ground Company. 

1170
00:51:36,700 --> 00:51:38,700
By company. 
We need to explain to our 

1171
00:51:38,707 --> 00:51:40,600
Executives, why it's better for 
everyone. 

1172
00:51:40,800 --> 00:51:42,800
We need to build this into our 
org charts. 

1173
00:51:43,000 --> 00:51:45,200
We need to stop talking about 
management as a promotion. 

1174
00:51:45,600 --> 00:51:47,500
A promotion is just a change of 
career. 

1175
00:51:47,700 --> 00:51:50,500
It's a lateral step. 
What that means is that it's not

1176
00:51:50,500 --> 00:51:52,300
a demotion. 
If it manager wants to go back 

1177
00:51:52,300 --> 00:51:54,600
to engineering. 
You don't want to have managers 

1178
00:51:54,600 --> 00:51:59,000
who are resentful or who miss 
being engineers and who like try

1179
00:51:59,000 --> 00:52:01,800
to reclaim that glory and try to
either one, who's always talking

1180
00:52:01,900 --> 00:52:05,000
who has all the best dancers, 
you want your managers to went 

1181
00:52:05,000 --> 00:52:07,900
to be managing people? 
You want the people who were 

1182
00:52:07,900 --> 00:52:10,800
better as Engineers to try it 
for a while maybe and then be 

1183
00:52:10,800 --> 00:52:12,800
able to switch back to 
engineering without any loss of 

1184
00:52:12,800 --> 00:52:16,100
status without any loss of ego. 
So it's really We important that

1185
00:52:16,100 --> 00:52:18,400
management is not a promotion to
change a career. 

1186
00:52:18,600 --> 00:52:20,800
I think anyone who's trying 
management out. 

1187
00:52:20,900 --> 00:52:22,500
You should ask for a two-year 
commitment. 

1188
00:52:22,600 --> 00:52:24,400
Otherwise, it's too rough on the
team's. 

1189
00:52:24,400 --> 00:52:26,800
If you're like, shuffling 
manager around constantly. 

1190
00:52:26,900 --> 00:52:29,300
You literally have to become a 
different person to Be an 

1191
00:52:29,300 --> 00:52:31,800
Effective manager. 
You have to retrain your own 

1192
00:52:31,800 --> 00:52:35,800
instincts, your own reactions of
the way that you think you're 

1193
00:52:35,800 --> 00:52:38,300
pacing. 
You're pacing on it on a daily. 

1194
00:52:38,300 --> 00:52:40,500
Weekly basis is so much 
different as a manager. 

1195
00:52:40,700 --> 00:52:43,400
You have to gain the Instinct 
and intuition know when you're 

1196
00:52:43,400 --> 00:52:45,300
doing a good job when you're 
doing a bad job. 

1197
00:52:45,600 --> 00:52:47,300
Takes at least two years to 
build. 

1198
00:52:47,300 --> 00:52:49,300
And so in the early days as a 
new manager. 

1199
00:52:49,500 --> 00:52:52,100
Everybody is all my doing a good
job or not. 

1200
00:52:52,200 --> 00:52:54,600
I do I like this or not. 
It's like chill out. 

1201
00:52:54,700 --> 00:52:58,400
You don't know, you have no way 
of knowing just turn the voices 

1202
00:52:58,400 --> 00:53:00,800
off. 
Learn everything you can and get

1203
00:53:00,800 --> 00:53:03,300
back to me in two years and then
we'll have a conversation about 

1204
00:53:03,300 --> 00:53:05,100
it. 
But I feel like the industry 

1205
00:53:05,100 --> 00:53:08,700
would be so much better as a 
whole if we demythologize 

1206
00:53:08,700 --> 00:53:10,900
management. 
If pretty much anyone who is 

1207
00:53:10,900 --> 00:53:13,200
interested in trying management,
gotta shake at it. 

1208
00:53:13,400 --> 00:53:16,500
And then if we ask ourselves, 
honestly, is this good for me? 

1209
00:53:16,700 --> 00:53:19,600
Do I like it or not? 
And there should be a path back 

1210
00:53:19,600 --> 00:53:21,200
and forth. 
That is well-trodden. 

1211
00:53:21,400 --> 00:53:24,700
I feel like so much of the 
pathologies that I see on teams 

1212
00:53:24,700 --> 00:53:26,900
come from the relationship 
between management and 

1213
00:53:26,900 --> 00:53:29,100
Engineers. 
If we could just make it less of

1214
00:53:29,100 --> 00:53:32,000
a thing, this make it. 
Another thing that you can try 

1215
00:53:32,000 --> 00:53:33,900
and it's not a big deal. 
It's not a promotion. 

1216
00:53:33,900 --> 00:53:36,900
It's not a big ego thing because
you're not in charge of people. 

1217
00:53:37,100 --> 00:53:39,300
It's not like that. 
It's a support role. 

1218
00:53:39,500 --> 00:53:41,500
I hadn't really thought of this 
until now, but I think in the 

1219
00:53:41,500 --> 00:53:44,200
way that the interval between, 
when you write the code when you

1220
00:53:44,207 --> 00:53:48,000
ship the code is a Building 
block of a healthy software 

1221
00:53:48,000 --> 00:53:51,000
digestive cycle. 
I think that pathway between 

1222
00:53:51,000 --> 00:53:54,100
senior engineer and manager, 
being an equal one. 

1223
00:53:54,200 --> 00:53:56,700
And a well-trodden, one is a 
fundamental building block of a 

1224
00:53:56,700 --> 00:53:59,300
really good social side of the 
socio-technical organization. 

1225
00:53:59,700 --> 00:54:02,600
I also think like many 
Engineers, of course, aspire to 

1226
00:54:02,600 --> 00:54:05,400
try out management. 
So the swing from the engineer 

1227
00:54:05,400 --> 00:54:07,800
to manage arrived, and they 
should because even if 

1228
00:54:07,800 --> 00:54:10,100
long-term, they want to be a 
senior technical leader. 

1229
00:54:10,300 --> 00:54:12,500
There are things that you will 
learn as manager, that will give

1230
00:54:12,500 --> 00:54:15,300
you so, much more empathy will 
be Q so much more effective. 

1231
00:54:15,500 --> 00:54:19,100
As a technical leader from doing
a two-year stint as a manager, I

1232
00:54:19,100 --> 00:54:22,400
think it's a good thing for 
engineer to try management and 

1233
00:54:22,400 --> 00:54:26,200
maybe what are some of the tips 
for like, first, new manager out

1234
00:54:26,200 --> 00:54:28,800
there from engineer. 
They want to try manager, how to

1235
00:54:28,800 --> 00:54:30,700
become effective in that new 
rule. 

1236
00:54:31,200 --> 00:54:33,100
Yeah. 
I think that a lot of it comes 

1237
00:54:33,100 --> 00:54:35,700
down to self-awareness. 
So number one, I'd say, go to 

1238
00:54:35,700 --> 00:54:38,800
therapy. 
This is get a therapist and go 

1239
00:54:38,800 --> 00:54:41,900
to therapy every week. 
Learn stuff about power 

1240
00:54:41,900 --> 00:54:45,900
dynamics, especially if you're a
white or Asian, dude, Tech. 

1241
00:54:46,000 --> 00:54:48,400
I think that there's a lot of 
stuff that you need to learn to 

1242
00:54:48,400 --> 00:54:50,300
be sensitive to that. 
You've perhaps never been 

1243
00:54:50,300 --> 00:54:53,500
sensitive to before you owe it 
to your reports to learn about 

1244
00:54:53,500 --> 00:54:56,000
those things. 
So, start following feminists 

1245
00:54:56,000 --> 00:54:59,400
and some people of color and 
learn about power dynamics learn

1246
00:54:59,400 --> 00:55:01,800
how to listen, all of the advice
that I would give for new 

1247
00:55:01,800 --> 00:55:05,900
managers is really about 
self-awareness and humility and 

1248
00:55:05,900 --> 00:55:08,600
communication skills, which is 
another reason that I think it's

1249
00:55:08,600 --> 00:55:11,900
a really interesting two or 
three year journey to go on as 

1250
00:55:11,900 --> 00:55:13,400
an engineer who's now in your 
30s. 

1251
00:55:13,400 --> 00:55:15,300
Maybe has a family now. 
I think it's a nice. 

1252
00:55:15,500 --> 00:55:17,800
Change of pace. 
I think that it dovetails really

1253
00:55:17,800 --> 00:55:19,500
well with just kind of growing 
up. 

1254
00:55:19,900 --> 00:55:22,700
And I think one of the reason 
the pendulum back from manager 

1255
00:55:22,700 --> 00:55:26,400
to engineer, I think it's about 
the concern that once they go 

1256
00:55:26,400 --> 00:55:29,300
back to individual contributor. 
For example, it's probably 

1257
00:55:29,400 --> 00:55:31,300
difficult, especially in this 
region. 

1258
00:55:31,300 --> 00:55:34,200
At least the way I see it is 
that you might not be able to 

1259
00:55:34,200 --> 00:55:37,400
get back that management role, 
especially when people see the 

1260
00:55:37,400 --> 00:55:40,600
numbers of experience the bigger
team that they managed before. 

1261
00:55:40,800 --> 00:55:43,200
So, what do you see in terms of 
this pendulum back? 

1262
00:55:43,300 --> 00:55:46,700
How could someone assure 
themselves that Create safe. 

1263
00:55:46,700 --> 00:55:50,000
I can go back to I see and I can
always go back as being manager.

1264
00:55:50,500 --> 00:55:53,500
Choose your company's carefully,
especially if you'd be worth in 

1265
00:55:53,500 --> 00:55:55,600
your in your career. 
You should be interviewing them 

1266
00:55:55,600 --> 00:55:58,000
just as much as they're 
interviewing you ask them about 

1267
00:55:58,000 --> 00:56:00,300
their philosophy of management. 
Is it a promotion? 

1268
00:56:00,400 --> 00:56:02,900
How do they think about it as 
anyone ever gotten back from 

1269
00:56:02,900 --> 00:56:05,400
being a manager to, I see, would
you discourage them? 

1270
00:56:05,500 --> 00:56:08,100
Talk to them about it. 
You really want to find a place 

1271
00:56:08,100 --> 00:56:10,500
that has a culture that matches 
your own aspirations. 

1272
00:56:10,700 --> 00:56:13,700
Also, like just Comfort yourself
that if it's been two or three 

1273
00:56:13,700 --> 00:56:16,100
years, you can go back. 
It's fine. 

1274
00:56:16,200 --> 00:56:17,800
Especially if you're a dude, 
right? 

1275
00:56:17,800 --> 00:56:19,900
Nobody's going to even question 
you if it's been two or three 

1276
00:56:19,900 --> 00:56:21,500
years. 
Yeah, it'll take you a month or 

1277
00:56:21,500 --> 00:56:23,200
two. 
You might have to study a little

1278
00:56:23,200 --> 00:56:26,200
bit for the coding interview. 
But, you know, you'll be fine. 

1279
00:56:26,300 --> 00:56:29,100
You might have to change jobs, 
if you aren't a company that 

1280
00:56:29,100 --> 00:56:32,100
values, this, but it is honestly
much easier to go back from 

1281
00:56:32,100 --> 00:56:34,400
being a manager, to be an 
engineer because this is a 

1282
00:56:34,400 --> 00:56:36,500
superpower, everyone wants 
Engineers. 

1283
00:56:36,700 --> 00:56:39,200
There is so much more demand for
engineers and there is 

1284
00:56:39,200 --> 00:56:41,400
availability. 
So, if it's only been two or 

1285
00:56:41,400 --> 00:56:44,100
three years, you're going to be 
fine, but if you're concerned 

1286
00:56:44,100 --> 00:56:46,800
about that, then make sure it's 
all For three years, don't go to

1287
00:56:46,800 --> 00:56:48,900
five years or Beyond, or it 
could actually be very 

1288
00:56:48,900 --> 00:56:51,300
difficult. 
So it's been a pleasant 

1289
00:56:51,300 --> 00:56:54,000
conversation. 
But before we end our chat here,

1290
00:56:54,000 --> 00:56:56,300
normally I would ask all my 
guests to share their three 

1291
00:56:56,300 --> 00:56:57,600
technical leadership. 
Wisdom. 

1292
00:56:57,800 --> 00:56:59,700
So charity. 
Do you have some wisdom that you

1293
00:56:59,700 --> 00:57:01,400
want to share with all my 
listeners here? 

1294
00:57:01,800 --> 00:57:04,000
Yeah. 
I think number one is your 

1295
00:57:04,000 --> 00:57:07,500
career is an enormous asset. 
It is the most valuable thing. 

1296
00:57:07,500 --> 00:57:10,200
You possess. 
It is a multimillion-dollar 

1297
00:57:10,200 --> 00:57:14,900
appreciating asset and you 
should treat it that way in my 

1298
00:57:14,900 --> 00:57:16,400
twenties. 
He's I didn't think of my career

1299
00:57:16,400 --> 00:57:18,700
that way I just lurched from one
thing to the next, you know seat

1300
00:57:18,700 --> 00:57:20,400
of my pants and it turned out 
okay for me. 

1301
00:57:20,400 --> 00:57:23,000
I was pretty lucky but I think 
that a little bit of 

1302
00:57:23,000 --> 00:57:26,200
introspection a little bit of 
where do I want to be and 

1303
00:57:26,200 --> 00:57:28,000
pointing your nose in that 
direction. 

1304
00:57:28,200 --> 00:57:31,300
It has a way of making you a 
tune to opportunities that open 

1305
00:57:31,300 --> 00:57:32,600
up. 
If you're like someday, I might 

1306
00:57:32,600 --> 00:57:35,100
want to be a manager, then you 
might be more likely to take a 

1307
00:57:35,100 --> 00:57:38,200
role at a company that has some 
obvious management roles opening

1308
00:57:38,200 --> 00:57:40,200
up. 
So I just feel like treat your 

1309
00:57:40,200 --> 00:57:42,600
career, the way that you would 
want a friend of yours with a 

1310
00:57:42,607 --> 00:57:45,300
multimillion-dollar appreciating
asset to treat their assets. 

1311
00:57:45,500 --> 00:57:46,800
Think about it for the long 
term. 

1312
00:57:46,800 --> 00:57:49,400
Sometimes this means taking a 
job with a little bit less pay 

1313
00:57:49,400 --> 00:57:52,400
because you think it makes the 
story of your career look much 

1314
00:57:52,400 --> 00:57:54,700
better. 
I think that being in a position

1315
00:57:54,700 --> 00:57:57,200
where you are not spending all 
of your money. 

1316
00:57:57,200 --> 00:57:59,800
Every month is a very good tip 
for everyone. 

1317
00:58:00,100 --> 00:58:02,700
Have some fuck you money in the 
bank, don't live paycheck to 

1318
00:58:02,700 --> 00:58:05,300
paycheck because then your trap,
you can't take any jobs that pay

1319
00:58:05,300 --> 00:58:06,800
any less than that. 
And sometimes you're going to 

1320
00:58:06,808 --> 00:58:10,200
want to look at your career as a
long term asset and think about 

1321
00:58:10,200 --> 00:58:11,800
the story that you wanted to 
tell. 

1322
00:58:12,000 --> 00:58:13,700
And it's not something you have 
to take up a lot of time and 

1323
00:58:13,700 --> 00:58:15,300
energy, right? 
Just like a couple hours. 

1324
00:58:15,400 --> 00:58:18,000
Year, I think will really help. 
It's really valuable though. 

1325
00:58:18,000 --> 00:58:21,000
Like, we are so fortunate to 
live in this time and be doing 

1326
00:58:21,000 --> 00:58:23,700
this thing because this is the 
only growth industry of my 

1327
00:58:23,700 --> 00:58:26,300
lifetime. 
We live in a different economic 

1328
00:58:26,300 --> 00:58:28,400
reality than most of the world 
does. 

1329
00:58:28,500 --> 00:58:31,200
Most of the United States has 
been in a depression for 15 

1330
00:58:31,200 --> 00:58:33,600
years. 
Not in Tech opportunities, 

1331
00:58:33,600 --> 00:58:36,000
abound. 
Yes, Tech has problems with 

1332
00:58:36,000 --> 00:58:39,800
sexism and racism and yet I 
often feel like I want to just 

1333
00:58:39,800 --> 00:58:42,700
like tone down, so the shit that
we tell the kids about because 

1334
00:58:42,700 --> 00:58:44,700
I'm like, if you're telling 
them, not to come to Tech 

1335
00:58:44,700 --> 00:58:47,500
because we're two, Here, where 
do you want them to go? 

1336
00:58:47,600 --> 00:58:49,600
What is this? 
Magical mythical industry where 

1337
00:58:49,600 --> 00:58:51,400
they will be highly paid in 
valued? 

1338
00:58:51,400 --> 00:58:52,700
Where they've not going to have 
to deal with you? 

1339
00:58:52,700 --> 00:58:54,700
This bullshit. 
This is called living in the 

1340
00:58:54,700 --> 00:58:58,200
world, guys. 
Like it just is this way and so 

1341
00:58:58,200 --> 00:59:00,800
I think that we owe it to 
ourselves to get as many women 

1342
00:59:00,800 --> 00:59:03,100
and underrepresented minorities 
in detect, it helped them 

1343
00:59:03,100 --> 00:59:07,400
survive and tough it out because
we're so fucking fortunate and 

1344
00:59:07,400 --> 00:59:09,800
blessed. 
So that was two or three things.

1345
00:59:10,500 --> 00:59:12,900
All in one. 
I guess try to be financially 

1346
00:59:12,900 --> 00:59:16,200
constrained. 
Try to be an ally to In general 

1347
00:59:16,200 --> 00:59:19,100
other genders and races. 
The advice that I always give to

1348
00:59:19,100 --> 00:59:21,200
young women who ask me for 
advice is like when you're a 

1349
00:59:21,207 --> 00:59:22,700
junior engineer, just toughen 
up. 

1350
00:59:22,800 --> 00:59:25,000
This is problematic. 
I absolutely agree. 

1351
00:59:25,100 --> 00:59:26,400
Tough it up. 
Try not to take it too. 

1352
00:59:26,400 --> 00:59:29,900
Personally, put your head down, 
learn as much as you can just 

1353
00:59:29,900 --> 00:59:33,700
survive, become a senior 
engineer and then get sensitive 

1354
00:59:33,700 --> 00:59:36,700
and then learn to be sensitive 
on behalf of other people, use 

1355
00:59:36,700 --> 00:59:38,900
your power for good. 
Anyone who's a senior 

1356
00:59:38,900 --> 00:59:41,800
engineering Tech has an absolute
responsibility to learn to be 

1357
00:59:41,808 --> 00:59:45,000
sensitive and to use our power 
for good on behalf of those who 

1358
00:59:45,000 --> 00:59:47,400
can't, Wow, thanks for sharing 
all this. 

1359
00:59:47,400 --> 00:59:50,300
I think it's a message that we 
all need to learn especially in 

1360
00:59:50,300 --> 00:59:53,200
these days where so many things 
happening, especially in Tech 

1361
00:59:53,200 --> 00:59:55,400
and around the world. 
So, thanks for sharing that. 

1362
00:59:55,600 --> 00:59:58,500
So charity, if people want to 
connect with you or find you 

1363
00:59:58,500 --> 01:00:00,200
more, where can they find you 
online? 

1364
01:00:00,700 --> 01:00:06,700
I am on Twitter as Nifty Tipsy. 
I EverQuest enchanters name and 

1365
01:00:06,700 --> 01:00:09,400
Trudy. 
WTF is my blog and honeycomb. 

1366
01:00:09,400 --> 01:00:13,600
Dot IO is where you can sign up 
for a free honeycomb account and

1367
01:00:13,700 --> 01:00:15,500
use the build event stuff to 
visualize. 

1368
01:00:15,700 --> 01:00:17,500
Cic pipeline. 
The way I was talking about. 

1369
01:00:17,500 --> 01:00:20,300
It's super fun. 
So one day, I'll make sure that 

1370
01:00:20,300 --> 01:00:22,300
I'll try that. 
You expect less than an hour. 

1371
01:00:22,300 --> 01:00:24,000
It's super fun. 
You could see all your time is 

1372
01:00:24,000 --> 01:00:24,900
going. 
It's great. 

1373
01:00:25,100 --> 01:00:29,000
Although thanks again for your 
time, charity, honeycomb, and 

1374
01:00:29,000 --> 01:00:33,100
everything that you do. 
Thank you for listening to this 

1375
01:00:33,100 --> 01:00:35,700
episode and for staying right 
till the end. 

1376
01:00:36,000 --> 01:00:38,900
If you highly enjoyed, please 
share it with your friends and 

1377
01:00:38,900 --> 01:00:42,200
colleagues who you think would 
also benefit from listening to 

1378
01:00:42,200 --> 01:00:44,500
this episode. 
And if you're new to the 

1379
01:00:44,500 --> 01:00:47,900
podcast, make sure to subscribe 
and leave me your valuable 

1380
01:00:47,900 --> 01:00:51,200
review and feedback. 
It really, really helps me a lot

1381
01:00:51,200 --> 01:00:53,700
in order to grow these podcasts 
better. 

1382
01:00:54,200 --> 01:00:57,600
You can also find the full show 
notes of this conversation on 

1383
01:00:57,600 --> 01:01:00,800
the episode page at technology. 
Know the death website, 

1384
01:01:00,800 --> 01:01:04,300
including the full transcript 
interesting quotes and links to 

1385
01:01:04,300 --> 01:01:07,200
the resources and mentions from 
the conversation. 

1386
01:01:07,700 --> 01:01:10,600
And lastly, make sure to 
subscribe to the shows mailing 

1387
01:01:10,600 --> 01:01:14,000
list on technology on of the 
deaf to get notified for any 

1388
01:01:14,000 --> 01:01:16,700
future episodes. 
Stay tuned for the next 

1389
01:01:16,700 --> 01:01:19,100
technique Journal episode. 
And until then. 

1390
01:01:19,200 --> 01:01:19,800
Goodbye.