The goal of your resume is to get a recruiter called, it's a
binary yes-or-no. That is the goal.
As soon as you have your recruiter, call.
Your resume doesn't really matter that much.
Hey everyone. My name is Henry sura, one.
And you're listening to the tekhelet journal.
The show will be bringing you the greatest technical leaders
practitioners and thought leaders in the industry to
discuss about their Journey ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our Journal. Hello, my friend.
Welcome to the Tecla. Juno show with me.
Oh host, Henry Surya with Robin. It's great to be back here again
with a new episode sharing, my conversation with another great
technical leader. Thank you for tuning in and
spending your time with me today, listening to this
episode. If you haven't joined any of the
technology, you know, social media channels, please spend a
few seconds right now, to click on the links in the show notes
where you can find this show, either on LinkedIn Twitter.
Our Instagram and join a fast growing number of people who
have been following the show so far.
Make sure to also, subscribe and follow the show on your favorite
podcast app. And for those of you longtime
listeners, if you have been enjoying and benefiting from the
show so far. I am looking forward to hearing
from your feedback or comments on the social media channels or
even direct to me. I'm always happy to hear from
any of you and will do my best to keep on improving the show.
Last week, you have listened from my first Patron.
Tony long. Sharing his message about this
show and his favorite episode for today.
I would like to introduce you to my second Patron.
David cattle prod Noto from Indonesia.
He's a good friend of mine, and he has been a great supporter of
this show. Even during the time, when all I
had was just an idea of doing a podcast, his continuous support
and feedback are one of my greatest source of inspiration
so far. And I'd like to thank him for
that. So let's hear from David what he
has to say about tekhelet Journal.
Hello everyone. My name is David from Jakarta,
Indonesia, and I'm currently working as an engineer at
tokopedia. I've known Henry from way back.
Once I heard that he's planning to do a podcast with in the tech
industry. I support him 110% and hopefully
this can be xpeke as Jose and legs podcasts.
Honestly, at first, I was a bit skeptical on how it's going to
be, but as usual, Henry always manage to To exceed my
expectation. I acquired a lot of insights by
listening to all the experts here.
However, if I have to choose the most memorable episode so far, I
have to choose tray and in no particular order.
He has to be the one with Jerome hongyi and Crystal episodes.
As for the, why, besides the top three victims at the end of the
episodes. The Henry always asks, I also
find that their stories challenges and the things they
need to do to overcome them are personally responsible.
At the bill to me, I guess that's it.
Good luck Henry for the future episodes and I will always keep
supporting the podcast. Goodbye.
Thank you. Again.
David was such a great supporter.
I am extremely happy to hear that.
You have also benefited from the show.
For those of you who are liking the show and would also like to
make contribution to the show. You can find more information on
the patreon page at technology, you know dot f / Patron.
I'm currently running a goal on my patreon page and your support
with tremendously. Up me towards achieving it.
I'll guess what today's episode is, girl, gay or Rose GE GE is a
seasoned software engineer and engineering manager.
And was last at Uber before Uber.
He also worked in other hyper growth companies, such as
Skyscanner and Skype. And I recently bumped into his
latest book, the tech resume inside out.
And I find that it is one of the best resources that are found
for coming up with a great tech resume with lots of Balls on how
to improve the resume specifically for technical
roles. And if any of you is currently
impacted by pandemic and is looking for a job, GE, GE
currently offers this book for free, which you can find more
information about on its website, the tech resume.com,
which you can also find in the show notes in this episode gag.
A shared about his interesting career Journey path starting
from being a software engineer at small companies and then
moving to hyper growth startups and becoming engineering
manager. We then moved on to discuss
about tech resume, how important it is to get it right based on
his early hard lessons, and his experience being at the other
side, as the hiring manager, which then led him to writing
the book. Next, we had insightful
discussion about his experience at Uber and how the engineering
team works there, including his first-hand experience seeing
Ubers pace of change GE GE recently, quit boober.
And he shared with me his reasoning and what he currently
has for his future plan. Lastly, we discussed about his
block, the pragmatic engineer, and some of his popular posts on
topics such as what Silicon Valley companies get right, when
dealing with software engineers. Distributed architecture
Concepts and why software architecture is overrated.
While clear and simple design is underrated.
I hope that you will enjoy this great episode.
Please. Consider helping the show in the
smallest possible way by leaving me a rating and review on Apple
podcast and other podcast apps that allow you to do.
So, those ratings and reviews are one of the best ways to get
this podcast to reach more listeners.
And hopefully, the show gets featured on the podcast
platform. Let's get the episode started
right after our sponsor message. Are you start up in software
development Which is less than five years old.
If yes, our sponsor at jetbrains have a 50% startup discount
offer, which allows startups to purchase multiple products and
subscriptions for up to 10 unique licenses over a period of
months to find out more search for jetbrains startup discount
offer, or you can check out the link mention in the show notes.
Welcome gate to technology. You know, show is really a
pleasure to meet you. I saw you on LinkedIn.
Somebody posts. Something about your book
recently, which is called tech resume book.
I found it interesting. I bought it.
I read it and I think we will talk about that as well.
It's really good to have you in the show.
Yeah. Yeah.
Looking forward to learning from you.
Yeah, really good to be on the show.
Thanks for inviting me. So the gay I saw your profile.
You have tremendous career Journey starting from working as
a software engineer and then climb the ladder into different
companies work in Tech you. Cons.
The last one was Uber before you quit.
Just a few weeks ago. I guess I'm so maybe you can
share with us. First of all, what's your career
Journey? Like?
So, you can mention some of your major highlights probably or sub
turning points that change your career.
Yeah. So while looking back, I'm
pretty happy with my career Journey, all the boat looking
forward. It is hard to predict on how
things will end up with. I did a computer science degree
back and I'm originally from Hungary.
So small country in the middle of Europe.
While I was working at University.
It was an interesting degree where I did six years and I only
got a master's degree. So instead of the usual
bachelor's and Master's, this was back in the day before,
there was a split. And in the last two years.
I work full-time at a small local company building content
Management Systems back, then these things were big but as
working on that and right, as I graduated, I decided to move
abroad partially because I had a girlfriend that I'm from the US
who went to study to Edinburgh in the UK, going to straight to
the us as a graduate is difficult, and it didn't really
make sense, but we just moved there.
So I just moved her chattering burrow out of college and I was
lucky enough to join. Company, that was a financial
consultancy. It was really difficult to get
in there. I was a little bit lucky.
This was my first job and I was struggling to get interview.
So I arrived, I had a really good degree in hungary's.
Best university. I was top of the class.
I even was on imagine cup, which is a Microsoft competition back
then. It was the biggest software
engineering competition in the world.
And with our team, we came third worldwide and we got a special
invitation to Silicon Valley as well.
And I was not getting any injuries at all.
I felt really strange. I'm like, I think I'm smart.
Think I know what I'm doing. Anyway, after a few weeks.
I did get a couple of interviews and I got offers wherever
interviewed later. It was interesting because some
of the recruiters told me that they were recruiting for the
company that I eventually got hired for but they thought I
didn't stand a chance. One of the things that helped me
get. My first job actually, is I
over-prepared. So back then.
I didn't know what to expect for interviews.
But when I Googled interview preparation, there was this
course from Stanford saying beating the Google interview,
and this was back in 2009 or so. We knew that Google had
difficulty interviews, but there is no preparation.
So I actually prepare for the Google injury.
I prepare for the coding, the algorithmic will sell
challenges, and this company was asking those challenges.
So, I had to developers asking me to code and white board and
do all these things. And I actually practiced all of
this later. They told me that they hired
about one candidate from about 100 and they were doing this,
Google sounds of your super early on.
But it goes back to the fact that I knew that my background.
It was clear that I didn't have strong credentials in the new
country. So I just overheard Where'd the
nice thing about joining, a company that has a hiring bar?
I work with really smart people, and some of those people are
actually very active still in today's Community.
One of the people is the leading figure in the webassembly
community, and I had really good mentors from there on.
I spent two years there building small products.
I moved up to London, which is a big leap from me from Edinburgh.
All the way to London. I worked at JPMorgan.
Big Investment Bank work with the trading floor.
I was very interesting learning for finance and how Traders work
and how our trading desk move huge amounts of money.
And it was interesting to see how this happening, but it was
not Very interesting software engineering challenge on the
side. I was building apps side
projects and I was a prominent figure in the Windows Phone
ecosystem at built a couple of apps that were very well known
and then Microsoft reach out to me saying, we can tell you what
we're doing, but it's going to be something new, and exciting,
and it turned out to be the sky for Xbox one.
They were building it in London. So I joined Skype or Microsoft
right after they acquire Skype and Microsoft, had this new
policy to leave the company's completely alone for 18 months.
So it didn't feel like Microsoft at all.
And this was the old Microsoft of Steve.
Bombers Microsoft, it just felt exactly like Skype.
So we're a small team, we could do whatever we wanted.
And then in London we built sky for Xbox one.
We shipped it, which was a really fun project on launch
week. We had a million people use the
product that we used on the Skype was a huge feature for
Xbox one. It was the first console that
was just not a games console. And I moved on to different team
to build Skype for web, which was a Google Hangouts.
Competitor. Also of very fun challenges, as
I did. I kept changing Stacks.
So that was also something interesting that I didn't
deliberately Zoo, but when I joined Microsoft, they hired me
as a seizure. Developer C, sharp wpx, a mold
that kind of stuff, cause that's what we're supposed to build
Skype with one month into the project.
We were told the C, sharp compiler will not ship on Xbox.
They don't have time to do. It is going to be HTML and CSS
and Steve lost on the back end. And so we just had to relearn
that stuff. We're looking back.
One of the learnings I had in my career is whenever you have a
challenge, you can just turn that into an opportunity.
Our team was really upset. Some people are like, I don't
know. I might just quit.
This is ridiculous. I'm not going to do its
JavaScript and HTML. This was back in 2013 before.
For es5 was not even a thing. So it was a wild west.
The best book to learn JavaScript was JavaScript the
good parts. And I also joined this crowd for
a few weeks, but then I thought, you know, what?
If you can't beat them, join them, so I figured let me just
learn JavaScript really properly and we have this framework
called when Jays. And in the end, I ended up
recording a course on wind Json. How to use wind.
Yes. We became wind JS experts, which
was actually one of the I think most popular winges courses at
the time taken when Jess is gone, and it's not used but I
just said, look, let me take this opportunity to become an
expert in something new something interesting.
Just to wrap up after Microsoft after things still down.
I jumped ship to start up called Skyscanner.
There are flight booking service.
You can find the cheapest flight tickets worldwide.
We're not flying as much but when we do, they're really good
service. I joined a small team there and
it was a little bit of startup in a start-up and then, finally,
I spend the last four years. I do /.
I joined. When the team was about 25,
engineers in Amsterdam, and then it grew up to, like about 150
Engineers, which was really fun. Girlfriend, and I worked on
different projects. So since sky for the past eight
years. I've been working in what I
would call. Hyper-growth environments, which
is absolutely accidental. I had no idea this would happen,
but I didn't join when the team was size X and I left when the
team was 3x or 4X and I saw that growth and it's always really
fun. There's a lot of challenges
where you have to hire but keep the morale at Skyscanner.
I started to become a manager and repairing a small team and
an Uber, I joined as an engineer, but I very quickly
basically went back or became a manager again.
What I left I was managing a manager as well.
As I was on that managing managers track potentially.
Thanks for sharing your story. It's very very Interesting.
Even starting from the beginning.
You didn't get any interviews at all.
No chance of you getting a good job.
You climb from a small company and up to the latest one, which
is Uber which you categorized as a hyper Growth Company, maybe
the first lessons there. So why do you think it was hard
for you to get interviews? Because obviously, now these
days there are so many tech companies.
Do you actually see similar things?
Like, maybe some people just not visible enough like they
couldn't get interviews because of something.
Maybe you can share from your experience.
Yeah. I think it's Uma nature at the
time. I was super upset at recruiters,
I thought recruiters had it out for me.
I thought they were being nasty or something and a lot of people
are like this with recruiters. You will see people post, people
are upset at recruiters. When they get a template
message, they're upset at recruiters.
When they get messages of, let's say, someone got hired to a good
company and they get a lot of messages.
I would also offset. So, after I got hired, I started
to get message from recruiter saying, hey, are you interested
in other job and I was a bit upset.
What do you mean? You never talk to me?
Why are you talking me now? But especially at ruber I got to
know recruiters really well, and I'm I was very curious.
It is good to understand the recruiters point of view.
If any software and you're listening to this podcast, you
have a great job. We have a great job recruiting.
I'm going to be honest is a pretty terrible job for the most
part. If you ever talk to her cooter
asked and how they got into recruiting and a lot of
recruiters will tell you well and had an Arts major and I want
to do something, but I couldn't get a job.
And then there was recruiting. There are very few recruiters
who will tell you. I graduated out a recruiting
school and I wanted to be a recruiter.
Usually, it's a secondary choice, and on top of that, they
have Really hard expectation, even at the likes of uber,
there's hard expectations. They tell you, you need to
contact this many people per week.
You need to get this many people on site, you need to do this,
you need to do that. It's numbers again, at better
companies. It gets a little bit better but
it is hard to get there. You have to go through
basically, the grind and recruiters will have some mental
models. For example, they will try to
optimize their time. I'll give an example, a lot of
Engineers complain, why they get templated messages and I asked
recruiters the same thing. Turns out that most of them when
they start out, they actually write personalized messages.
They look at A cover for your GitHub, but they quickly realize
that they still don't get an answer from a lot of people
because let's say, if you're really enjoying your job right
now, you're not going to apply. It doesn't matter how nice that
messages. You just don't want to change.
So after a while, they realize that, even if they send the
short message, you get a roughly same response rate because turns
out that, if you are interested in the job, let's say you're
listening and you're not working at Google and someone from
Google messages. You, hey, would you be
interested in working at Google and you're thinking, oh, wow,
this is great. So the end of optimizing for
love and finally, they see some patterns.
So I now see, the reason I wasn't getting any Interviews, I
was coming from a place that was not the UK.
I had zero UK experience and just to generalize people like
this, usually don't do well on job interviews.
My resume was also terrible. I put my photo on there.
I put the first five step Hungarian, which you never put
on there. I put my birthdate, the format
just screamed. This person does not belong
here. There are some one else and
recruiters. They just put it to the bottom
of their list. They saw local applicants who
they thought had a higher chance.
So my resume was also not telling that story, but it's not
just a resume whenever Go somewhere new and you have zero
references. It's hard to break and it is
hard to break into Tech, unless you order additional route of
University, where it is a bit easier.
It is still hard through bootcamps.
Once you land that first job though, it gets a lot easier.
So I can understand when you mention about this recruiter.
I can also empathize with them their job.
How hot it is. They probably need to message.
Hundreds could even be thousands of candidates maybe only 10
percent response rate. I could be even lesser.
So I really can empathize it. Let's switch back to the resume.
You talking about you. Mention about some of the bad
things that you did. Last time, why you put pictures
or maybe mention about nationality?
And I saw that. You also wrote a book called the
tech resume book. I think it's very interesting.
Maybe you can share a bit about that.
Book. What makes you write the book
for a? So, this was very interesting.
The book is called to detect a resume inside out and it refers
to the fact that it's giving a little bit inside or knowledge.
A lot of times books that are written of, let's say how to do
this, how to do that. People doing it, who've done
that. But you rarely see books, where
it's written. From the other side, you will
see a lot of job Seekers or lot of career coaches who say I can
help you write a great resume because I've helped other people
but I always found it interesting to get advice from
people who actually on the other side.
So this book is written by myself as a hiring manager and I
have a lot of insights from recruiters and Tech managers
almost everyone contributing to the book is not people who have
written and submitted. Their resumes is the people who
are sitting on the other side, going through them and deciding.
Yes. No, yes.
Yes.
And the reason I wrote this
book, if covid-19 happened. This book would have definitely
not happened. I was writing a book on growing
as a software engineer and I had a contract with a publisher.
I'm still writing this book by the way.
So this will be my next one. The book was about how to grow
from entry level engineer at a tech company, like the likes of
Google Facebook, Uber Lyft Etc. Going to senior all the way to
staff and principal positions, and I find to have a small short
chapter on, changing jobs, because I think to grow as your
career, it is important to go out on a job market.
Every few years and evaluate yourself.
And then covid, started. I stopped writing the book
because we had a lot of things to take care of that Hooper.
And also they asked him to Burr to my old company Skyscanner.
They were hit quite hard and I was thinking how I can help
people. So I offered to do resume
reviews, both for people who are impacted that I knew personally
and I put it on Twitter as well as saying, if anyone's looking
for a job as a developer and you want some rest of the feedback,
let me know and I got a lot more responses than I expected.
And this made me realize two things first as a hiring
manager. I'm used to just really bad
software developer resumes, and we're okay with that because
usually you don't have that many applicants except for maybe New
grads where there's always a lot.
Applications for senior, my most common software resume as a
LinkedIn screenshot. And we spend the time look
through it because even for likes of Looper, there aren't
usually as many senior applicants before covid, but
now, this has changed drastically.
I talked with a lot of hiring managers at other companies and
the people were hiring, they were seeing surges of 10 or even
sometimes 20x to the usual applications and resumes, some
of these order to matter. The resume feedback that I give
to people, people said that actually help them get that
first recruiter call. And then I decided to kill two
birds with one stone. Stone.
So I started to scale myself. I got so many about application
that I could get high-quality feedback for let's say the first
50 and then I just did what you usually do.
While what I usually do. I put together the most common
advice and ended up putting in a PDF and I sent it to everyone
else. Saying, read all of this stuff,
look at the this and the section and this might apply a bit more
per to and now why did it turn into a book?
I could have just stopped at this PDF or it could have been a
blog post. But as I was writing this other
book, I did want to just experiment with what it is to
write a proper ebook. As I started to write.
I thought this ebook will be very short.
About 80 pages in the end. It turned about into 200 Pages
because I feel this topic of resumes is very fluffy and I
would have felt very bad just to put out something generic.
So I turn into something that I would want to read, which is
very specific advice would example saying, right.
Here's an example of this section here is the original
resume sample, that I got permission to use from people.
And here's the improved one. And here's why it's better.
And I also wanted to have actual resumes that are before and
after resume. So I asked permission from a
bunch of people who end up getting interviews and later
drops. And then finally, I Also, added
some resume template. So it's a bit more than a book.
I personally think it's the best resume resource for good advice,
but you have to spend a lot of time to figure out what is good
advice. Some of the advice out there as
I was writing it. I realized it's really bad
advice. There's a whole industry that is
built on trying to have you part from your money and they're
saying things like robots, can resumes and the 80s system
application trying to sum all of it is false.
There's a hint of Truth in it, but these companies are doing it
because they can charge additional services to this for
job Seekers. And that's also one thing that I
really don't want to. What this book?
I wrote this book and I'm selling it because I believe
that when you pay for something you are more likely to use it.
I think Gage readers, but for the people who need it, most
people who are out of a job is free.
There's no strings attached. They get the whole thing.
The only thing I'm asking from people is if you do get a job,
just help someone it can be anyone.
It doesn't even have to buying the book.
Just Mentor. Someone do public talks if you
want to buy this book for another job Seeker, but I'm
hoping to just give back to the community a bit like this.
And so far. The interesting thing was, I was
expecting that a lot of people would ask for free book.
And it's probably been about four people.
Buy the book and one person asked for a book in the sense
that they're out of a job is unexpected for me.
Again. I don't have any goals here.
So either people are buying it for people who don't have a job
are buying it as well. Or maybe there's not as many
Engineers out of a job as I seen or maybe not as many people know
about it. Because again, I'm fine to keep
it like this, at least until for another year on the covid
subsides. And we're getting a little bit
back to normal. So I bought the book as well.
I saw the contents. I also saw the examples that you
have and especially what I find very useful.
Is that you compare the before and after what was it like
before and how you improve with all the messages that you have
and all the explanations that you gave including some of the
templates that people can use and agree as well.
There are not many resources for developers to write a good
resume. I think this is one good
resource that I found lately about how to write a good tech
resume. But first of all, maybe if you
can highlight a few things, what are some of the common pitfalls
that every tacky rights in terms of their resume, the most common
Pitfall that I was doing for a long?
Time is you just don't really know what you're supposed to do.
You just take a template. You look at someone else's
resume and you're like, okay. I'm just going to write all the
stuff. I did.
You write your life story and you never pause for a second to
think, who am I writing this? And what is my goal?
I never asked this question, but you should ask your question.
What is the goal of your resume? There is only one good answer to
this and most people don't know what the goal of your resume is
to get a recruiter called. It's a binary yes-or-no.
That is the goal. As soon as you have your
recruiter, call. Your resume doesn't really
matter that much. Means you're now, the next stage
of the process. What matters is what you
interact with the recruiter, you can, then give them additional
context and then that recruiter or hiring manager.
So that first call they're going to decide.
Are you going to come on site? Now, typically, after your
resume that are going to confirm some soft skills.
Can you communicate? They might ask for Visa that
kind of stuff, but once you're on side, your resume is
irrelevant. The reason I say that most
people don't know this, because if this is the goal that if you
apply to three different jobs, you should be sending three
different resumes because every one of them you should tweak A
little bit for that job. Now.
Most people don't do this because they're thinking oh, why
should I do that? Well, look, if you're just
shooting with a shotgun and you're hoping things will and
don't do it and you will see a lot slower response.
If your goal is to get that call, you should optimize for
that and you should tweak your resume a little bit for each of
them. You should read the job
description and reflect their and this is why.
But the first third of the book is not about the resume.
It's about telling you how the hiring process works is.
Here's how the hiring process works.
I'm a hiring manager and I have what we call an opening or
acquisition. I want to hire.
And let's see. What happened.
Is someone quit on my team. This person was an engine with
two years of experience and I need to replace that person and
I need to do that now because I have a problem I need to do as
soon as possible. So I read the job description.
I right in there. What matters to me.
I might ride that I need two years of experience because
maybe this person was there. I need to experience with these
on these framework. I need someone with this and
that and it's all in the job description.
And I'm a busy person. We're going to get a bunch of
responses and I'm going to go through it and what I'm scanning
those resumes, I'm gonna ask, can this person do the job?
That's what I've been. Interested, if I see evidence
there that they can do the job, great.
If I don't see evidence, I will assume they cannot do the job.
I just don't have time to dig into it.
You need to sell yourself in a resume.
It's a bit of a sales pitch. I will Echo this because I talk
with a recruiter who works at a recruiting agency.
So what they do is developers apply to them and they send
their resumes on to clients for client jobs, and she told me she
seen about twenty thousand resumes in the past 20 years
easily. She's done six thousand
interviews herself with developers and she told me this
she said she still believe this is a sales.
Writing a resume, she rewrites their resume.
So a lot of times when these recruiting agencies, ask for a
resume and a document format or docx is because they were right.
It later to try to sell you better.
They're not doing it out of that content.
And you told me there is no resume that you cannot work
with, but multiple offers are not good at selling themselves
and for better or worse. I don't like that.
The system works like this, but this is how it works.
It is a bit of a sales pitch and it's for that specific position.
So, that's the key. Takeaway of the book and all the
examples are just showing on how to talk about your impact, how
to reflect on the job description?
If a job is talking, About distributed systems or if
another job is talking about building web products.
You probably mirror a little bit of language to make it clear
that you are capable of doing this job.
So that's the name, take away. So, yeah, for those listeners
out there, who wants to improve your resume, your tech resume,
please go and find the books. I'll put it in the mentions as
well. So moving onto your career, you
last held the position at Uber as an engineering manager.
Maybe he can tell us a little bit about what are the major
challenges that you work on when you were there.
I know. Is a major big company is a tech
unicorn, one of the biggest disruptors during that time.
So what was it like for you in Uber?
I know, when we say the word, boober different people, think
different things. Some people think, oh, what a
terrible company. I remember some really bad news
from 2017 when I joined Ubers pressed was fantastic.
So they just raised 13 or 10 billion or so from the Saudis
and the evaluation went to seventy two billion.
It was I think a new record it was the fastest growing company
in history and everything about. It seemed great.
There were talks about how Ubers do thousands my purse.
Services and everyone's sitting back and off.
It sounded like amazing company. It sounded like the next
Facebook or Google and one of the first challenges I join is
when you go inside a company like this, a lot of things
inside are not as pretty as they seem from the outside.
A lot of things are broken. There's outages happening on
calls that are terrible. We have meetings and Amsterdam
at 11 p.m. Or midnight.
It was a little bit sobering and by the way, this is not just a
case for Uber. I saw this for all the other
companies. So if you think of a company
that seems really good like it might be snowflake or slack or
Zoom. If you join that company you
would see that. Things are not as amazing as you
think because they're young companies and that's normal.
But one of the biggest challenges is what I joined
were, is we have so much stuff to do and we had so few people.
So we had all these projects that were each of them were
estimated to have an impact of, let's say, 10 million, 20
million, 30 million, on my team. For example, we have five
people. We were doing so many things.
At the same time. Everyone was working on a bunch
of stuff. We had this cultural value of
always be hustling and we were, but it was a little bit too
much. So the first challenge was, how
to say no to things because in an environment, in any hyper
growth environment, Everyone will tell you can you do this?
Can you do that? This is huge.
That's even bigger. So I had to say learn to say no
and had to educate people and make sure that we focused on the
right things and we consistently shipped the most important
things and we actually finish the work that just left it
halfway at that time. I think we both like what you
mentioned is growing very fast. I'm not sure what's the latest
system architecture of uber but I certainly will get bigger and
especially they are in multiple different countries.
So, how can you successfully manage?
Engineering team. There is there any Friends, in
terms of compared to other traditional companies, there any
difference in how you manage such a team for such a growing?
Hyperscale company? Well, I was a manager at
Skyscanner, a new burst of both were were sort of so I don't
have as much to compare as a manager.
I can't say what I've seen from the other side.
I personally think it's actually easier to manage teams at a high
growth companies because there's growth people have
opportunities. People are engaged.
You don't need to worry about those things.
What I actually find, personally, a more difficult
environment to work in is companies that are not growing.
So I remember towards the end of my tenure at Skype, it became
more of Microsoft and we stopped growing in London.
In fact, we start to not get back feels, which is a little
bit of a sign that things are not going the right way.
That's when I left and two years later.
They closed down the London office in an environment like
that. It is hard to manage when people
want to grow, they want to get us to the next level.
There might not be an opening in a stagnating environment.
And that's where you do have good people.
Leave if someone wants to move, let's say into senior role,
there might not be budget or scope.
So I find it really easy to manage in this environment.
The challenge. Is providing Focus, helping the
team succeed. Hiring is a big challenge
because you have to hire while keeping the team happy.
When I join some of my mentors have told me that one of the
most important thing is always to be hiring at a hyper growth
organization after a few years. I disagree.
I think the most important thing as a manager is for you to
retain people which means keep them.
Happy, keep them motivated. If my team was not really
healthy. If I could choose between
spending time with them or hiring.
I will choose spending time with them.
It's a lot more valuable to have someone around for two, three,
four, five. Ears it when you hire.
Someone takes about six months for them to get up to speed to
know how they're working on. It's always a bit of a risk.
And we were, I was really lucky as well on my team until the
layoffs in the end. No one left a company.
Some people did move teams, but everyone was there.
Which was incredible for four years.
No one left on my team. Wow, that's pretty good
achievement. I would say, especially in
Silicon Valley, people poaching, each other totally agree.
But this was also a master damn. So it's a little bit different
environment. But still, it was really good.
Because when you spend this much time with people, you get to
really know. Them and in the end, the team
jailed so much better than her Leon.
I do see that around two years. You can have a really well gel
team if you work with the same group of people, especially when
they can grow. So both myself and the team
started with more Junior. I was on an experience that your
manager I had an interest or not experience as well, but we grew
together and we became this really strong team and a lot of
people there, still a trooper. They're very strong Engineers.
They're often Central go to people for a lot of projects and
they have really strong growth ahead of them.
May that be at this company or other companies.
So what are some of your personal?
Tips on how to grow a well, gel team.
It sounds like you have a very good maybe culture process or
boundaries practices. Maybe.
Yeah, the biggest one. I get a lot of inspiration from
this book. That a couple people my manager
recommended to me. It's called turn the ship
around. Apparently, it's based on a true
story about a nuclear submarine and it's Captain.
Apparently, the Navy to run a submarine.
You have to go through this training school, where you learn
everything about that model to summary, and how it works in all
those things. So, this guy learned all of this
and he was supposed to be given the best submarine in the Navy.
The best meaning. There's these drills were,
whoever does this fastest, your best gets points and then you
can basically see was good discipline.
And instead, he's given a different submarine that he
doesn't know, and it's the worst submarine in the fleet.
Meaning, they're always slow, they make mistakes and so on.
So the guy has two problems. First.
He has no idea how the submarine works is very different.
It's like if you're training for one type of plane and you have
to apply a different one and S. It is the worst crew and they
need to improve. So he's forced to give up
control and he changes the culture from the traditional
top-down in the military where you tell people what to do.
Do he asked people to tell them what they will be doing and to
tell them, here's what I intend to do and he changes the culture
to be Bottoms Up. And in the end, what I like
about, this is how he empowers, people who are used to being
told what to do at least in Europe, and this might be true
in Asia as well. There's a culture shock, when
you go to Silicon Valley, tech company, a lot of them.
If you go in Silicon Valley to one of these tech companies as a
software engineer, you're going to be told.
All right. So what are you going to do?
And you're like what? What am I supposed to do know,
you need to figure that out. So it's a very different culture
in a lot of European companies, engineer's are a resource.
And you're told you get the juror ticket and that's it.
I try to instill this culture from day one and my thinking is
to empower people to be leaders. So when we have projects I make
it clear. I usually appoint a leader.
Usually it starts with the most senior person in the scene for
the first project. I said expectations on how I
expect them to run the project from an output point of view.
I tried to not tell them what to do, but I tell them, for
example, I expect regular updates.
I expect you to tell me when things are at risk, so we can
talk about it. I expect you to engage the team.
I expect you to make sure that everyone is happy, those kind of
things. I have a framework that I put
together and then later asked the team to do this in shorter
projects of project. One, two, three maximum of four
months and then I asked someone else to leave the project and
eventually everyone gets to lead a project including the most
Junior person on the team. Now.
A junior person will not be a great leader.
Let's be honest, they've never done this, but what I also do
is, I then asked the senior person to support them.
So, I tell them, your job is to make this person successful,
this work really, well. It works well in the growing
environment where there's a lot of stuff to do it.
Empowers people who are not just going to be leaders on this
project with later. Feel free to speak up saying, I
think this is wrong or we should do something different after a
while. People start to surprise me.
They start to make better decisions and I would have done
and you could scale yourself a lot more.
So this also helped me as a team grew, we had leads, some people
became manager so later and even when they weren't managers teams
could run themselves better. I think it's a fine balance, but
I like to give people trust. I like to give people trust with
additional support. I don't think it works.
If you tell a junior person. Alright, you do whatever you
want. Make it succeed.
That's not great. They're going to fail.
It's also not great when you micromanage every A senior
person. All right.
What did you do this? Why don't you do that?
So despite enough fine line. I feel like the luckiest off to
find it with you breath least and I have a post.
We can link it on the show notes where I describe what work and I
shared this document that I put together of expectations.
I would advise to don't copy anything that you see.
But you can think about in your team.
Can you try to instill something like this.
What I do know for sure. And this is my name.
Philosophy. A motivated engineer who's
engaged and who feel that? They have a real say.
They're going to do twice or three times.
The amount of work. They're going to do better
decisions and they'll do Martyr work.
So that's what you should aim for.
So I want to go back to the point that you make test.
Now, comparing European and Asian companies, versus the
Silicon Valley companies. I saw your blog posts related to
this, what Silicon Valley companies gets right.
When dealing with software Engineers.
Maybe can you share a little bit?
What are those things that Silicon Valley does better?
In terms of treating the software developers?
Some people might disagree. I talk with people who work in
Silicon Valley in there, so that their company doesn't work like
this, but in general, I find a big differentiation.
The biggest one is how companies look at theirs.
Software Engineers are software Engineers, just workers who are
told, are they just resources? Are they resources that we are
using to get a job done? Well, tell them what to do and
they'll do it. And we're going to make the
decisions because we know the business and we do all these
things or are they actually the people who are close to the
problems and we can utilize them to solve problems and we can
Empower them to make better decisions.
And boober has been a fantastic example.
On this, one of the cultural values Uber was be an owner, not
a renter, which meant if you see a problem solve it.
When I joined, Uber about a few months in, We have the session
where one of the teams who was doing cash payments, all the
engineers called up drivers and ask them.
Hey, how are using our product? What do you like about cash?
What you don't like about cash. The engineers were calling them
up and the driver is saying. I hate this about it or I and
the Angela like, whoa, whoa, whoa, so they talk with
customers. So we had Engineers talk with
customers every now and then we went to customer support centers
to see what feedback people were giving for the products.
We were building which in my case was payments.
We did this. And afterward, we had off sites
where engineers and other people we brainstormed about what we
should. Fix my team came up with a fix,
which was a really annoying thing.
We own the payments experience. And when something went wrong,
we just showed a generic message.
Oops, something went wrong because it was easy to do.
We knew this was not for the good and some people from the
business World saying, it could be nice to fix it.
But we never did too much in the end an engineer and someone else
got together and said, let's just fix it and they propose, we
fix it. They did an estimate.
They work for some data science is the injury actually, work
with the data scientist. We shipped it.
We estimated that maybe it'll bring in a million or $2 per
year, it brought in 10 times that much and this was all from
an engineer. Having seen this a ruber
software Engineers, if you're smart, you can expose them to
customers and if you're even smarter, you give them some
autonomy saying, hey, don't come up with the whole business
strategy here. But do you see some improvements
that you could do? That could make things faster.
Maybe development speed will be faster.
Maybe you could fix some bugs and people are a lot more
engaged. The results of this is, by the
way, that these injuries become a lot more valuable.
They're no longer just code monkeys.
They're actually bringing in a lot of business value, which
also makes the case for promotion.
A lot of these Engineers from the likes of uber.
And other companies. They will probably go go on
later in their career and they might co-found companies because
they understand the business. And I had a big renovation.
One engineer came over from a company that was consultancy and
they always gave him Jurassic. It's he was supposed to work on
that. If you ask questions, it wasn't
very welcome because the higher-ups decided what to do.
This person was confused on how this whole system work and he
was really struggling, but I was coaching him and I gave him
examples on how he should figure out what to do, how we should
talk with the product managers, this kind of thing in the end.
After about three months. He told me, you know what, I
really like working like this. I don't want to go back to the
old way. So even when this person left to
birth, a didn't goes back to the old company, the who would have
welcomed them back. You actually want to do
something different smaller companies have more autonomy and
have a say, in how things are being built.
But, yeah, I can totally understand.
I mean, for me as well as a software engineer, we don't like
to be told or here's what you need to do, including even like
some of the lower level details putting like algorithms or what
code to write and things like that.
So obviously we aspire to be more autonomous and more
creative as well. Sometimes.
I do understand as well, like getting exposed to the problem.
Yes, to the customers. Can also intrigued us to find a
better solution, including some of the Minor Details In the
code. Maybe the flow can be better,
the you I can be better as well. So yeah, I think that's a very
good advice from you one. Major question that I have
looking at all, you're growing and challenges and success at
Uber. Why did you quit recently
evolved? Because it's also a good time.
I was a trooper for four years and before that for about eight
years. I was out these high-growth
companies, which were maybe not remember, but there were pretty
similar and it seemed when I joined Uber.
I came here to take a bath as well to see if Thing with grow
bigger and it did. I also set myself a lot after
about four years. I'll take a look at and see
where I am. And what I'd like to do next.
Is I did I realize that angst to having worked in Uber.
I've built up a bigger risk, appetite the nice thing about
working at a company like Uber or any startup, when you join a
start-up when you join, you don't really know what it's like
and if you could ever do it, but by working at Uber I saw that
they're not as mystical. So starting a company.
Yes. It takes a lot of luck to do
something like uber, but starting from something from
scratch, when you've seen it, done a few times, you get a lot
more confidence and I've had other people lived, Uber.
She told me the same thing. They said, you know, I joined
you were really early on. I never thought I would do a
start-up, but I saw how we were worked and I think I can do
this. So, I'm at this stage as well,
where I think I am ready to take a risk in my career to start
something and that's a lot more risky.
There's always a risk reward. So you take high risk, you might
get zero or award, but I'm also missing that experience from my
career of doing something from very small.
I have them the bigger ones and I'd like to do that right now.
That's how I feel. And in the meantime when I quit
I didn't just quit for like, okay.
I'm going to try to figure out exactly what I'm doing.
I was really itching. Also finished my book about
growing as a software engineer, which is a lot of the things
that I've seen them. Maybe it'll be helpful for other
people. I knew that if I would stay with
Weber, it will take a lot longer to finish these two things just
seem to combine pretty well. And the third thing was Corona,
which again, I think whenever there's a challenge, you can
look at it and you can be really scared of it or unhappy with it,
or you can look at the opportunity.
Corona is a big hit for the economy.
Jobs are going to be lost, the economy will suffer.
It's a crisis. It's similar to the 2008
financial crisis. Probably bigger or.com, boom or
We even bigger, but during a crisis, you also have an
opportunity during crisis, is probably the best time to start
something small. Something you and your company.
And in certain cases. It is easier to hire capital is
still very strong everywhere. So, there have been a really
great Returns on when you see the current IPOs and those High
returns will want to go back and they will fund the next wave of
companies. So also see the opportunity and
then finally, honesty is just a change of pace.
I have been doing similar things for a while now that I've
reflected, and I just want to take a risk.
I want to do something different and see how I like it.
I don't know what the future holds.
Actually, there's their scenario lower likelihood, but I might go
back to zoom what I've done before, but there's a higher
scenario that I'll just do something small.
And the last thing is, I was curious.
What happens when I leave you bird without a plan because I
think it opens up a lot of interesting opportunities and
conversations. I've already talked with
founders with other people who are reaching out to me because
they know that I'm here. I might be advising a few
companies here and there. Again, it is very unusual.
Most people go from company to company or they leave a company
immediately to start a new one. So I'm doing something different
and we'll see if it pays off for an option.
Let's move. Move on to the other things that
you do which is writing a Blog. I saw you wrote a lot of blog
posts. I don't know.
When did you start? Maybe you can remember, I've
been blogging for more than 10 years, but for the first many
years it was an interesting blog.
I have to clean it up. It's my first name.
Last name.com, as a WordPress site is full of spam.
I need to clean it up. I just wrote about stuff every
now and then I started the pragmatic engineering blog
though about 3 years ago. And what prompted me is that I
set myself a challenge. I got really inspired by reading
Jeff, Atwoods advice to start a blog just blog.
Later, so I set myself a challenge to blog once a week
for two months and I wrote about six or seven articles that were
about software engineering. And I left it.
I just gave up and I forgot about it for a few months and
then about three or four months later.
One of the Articles was on The Hacker News from page, and I got
a huge amount of traffic. I had a few bunch of readers, a
huge amount of comments. People disagreed with me and
agree with me and I was like, huh?
That's interesting. People find my blog,
interesting. I didn't know that because it
before that I didn't get any sort of traffic and I start to
go back and add to articles every now and then.
On my writing style changed in the time, so it took a while to
figure out what my style is, but I enjoy sharing what I learned.
And it's a catch-22 when you write good stuff after a while
people discovered, but it takes time and then more people
discover it and so on. I just like that people find it.
Interesting. I've had people connect with me
about it. I do find that blogging also
helps me understand things a bit more.
So an example is an Uber. I learned a lot about
distributed systems. I didn't know, too much before I
joined, but my team ended up owning a couple of them and we
ended up building them. And even though I didn't push
code to those systems, but I read a lot of this.
Like I talked with bunch of Staff engineers and I realized,
you know, this distributed systems.
I think it's a bit over high for it talks about, it's not as
complicated. So I just summarize what I think
the basics are this block became really popular as translated
into multiple languages and what it made me realize, I think a
lot of people know this stuff. They just don't write it down or
they don't write it down in a simple form.
So for me, blogging has also helped with my writing, my early
blogs are a lot more verbose. They don't get to the point.
I'm a better writer because I block and because I get feedback
and then I block some more. I do recommend writing as a way
and it doesn't have to be a Blog.
It can be something else but writing as a way to grow as a
professional. In fact, I do burr, not being a
good writer is starting to become a block, or for people to
go beyond the senior level because in a distributor
organization, you need to express your thoughts.
You need to write up your proposals.
You need to write emails saying, hey, here's what I'm thinking of
doing. What do you think you need to
convince people over written forms, and this will be true for
a lot of other companies. I feel one of the big changes in
software engineering in the past decade.
Writing is becoming more important than communication is,
becoming more important for software Engineers is going to
be based on expectation for staff and principal Engineers to
be decent writers. The same way as a manager should
be a good communicator. For example, I was intrigued by
your blog about this distributed system.
Maybe you can share in short. What are some of the things that
you think are over hype about this distributed system.
I was pretty intimidated when I first started to look at
distributed systems because there's a lot of Concepts being
thrown around, like, consistency, strong consistency
eventual, because this It's in C or like durability idempotency
and they sound like Latin words and I didn't know what they
meant. I was in a meeting where we had
a person from San Francisco, come over an engineer on the
team and he was doing an overview of one of the payment
system that they built. And he was saying like, all
right now, because we made it this eventual consistent, we
made a decision because strong consistency was not a
requirement and this works. Well enough, although we have
some trade-offs and I as I called on just pause for a
second. Can anyone put up their hands?
Who knows what? And understands, what strong and
weak consistency is and no one. Their hands.
And I was like, okay. So do you mind explaining to us
what you meant for that? And he explained it.
But the crazy thing was, I think there's a bit of an acronym
overload, sometimes which makes sense, but it blocks people out
of there and it's not that complicated in this block was I
just wrote down what they mean. For example, idempotency is a
very important Concept in any distributed system.
It means that you have an API that behaves the same way
whenever you do it. Let's say in Boca.
So you do a get to an end point and it always returns the same
thing. And this can be important for
let's say payments, an input will be item potent when you try
to Charge a payment and you get a response that they either says
yes, or it says no. And if you charge it the second
time after its successful, it will return, you know, and you
can do it multiple times and you'll still get the same
response. There's only a handful of these
Concepts and once you know these things you can confidently,
speak distributed systems. And again, there's some use
cases where these are importance and the use cases where they're
not same thing with scaling, everyone talks about.
Oh, we need to make a scalable well, but scaling there's
horizontal scaling which is you can just add more boxes,
basically, or vertical scaling where you can have a bigger box.
I try to not use by the way, these things while I talk with
people like consistency or idempotency while you do it,
when you know that it's take those same language, but I think
it's easier to explain and more clear if you can get people
including a conversation. So that's what the blog post is
about. It seems has resonated with
people and I hope some of these special words will be broken
down or it'll be either part of the vocabulary or it's just more
accessible to everyone. So for those of you who are
still having a lot of doubts, about what this should be the
system is do check it out. So I'm just a little bit curious
as well which post that you have on.
On Hacker News, the one that made you popular allows the very
early post. That's one of the first one
that's all listed. It's called a comment is
invitation for a refactor. So I wrote about, I had the
strong conviction which change has sense, but I was pretty
certain that. If you have comments in your
code, your code is doing something wrong.
You should not have comments in your code.
And I wrote a post about this since then.
I've actually I've softened up on that and I'm Hacker News.
This created a really is polarized the bay.
Some people are saying, absolutely not and people were
saying hold on. These got a good point.
You can read that article. If you want to.
It's also good contrast of how my writing actually has changed.
For example, that article is not as well and it again.
I do think it is good to put out, people's opinion out there.
Like, after you do some research.
I really enjoy reading other people's opinion about things
like how they see things and it's an opinion.
So some people will disagree, some people are greedy, and
that's great. So there's one more thing that I
saw from your blog, as well is about software.
Architecture, is overrated while clear and simple design is
underrated. Maybe can you explain a little
bit about that? Yeah, so this was a really
interesting when I was thinking a long time if I should write
about this or not, but in the end I decided and again, it was
a poor. I respond.
A lot of people agree. A lot of people didn't one thing
that struck me as very interesting and good at Hoover
is Uber, doesn't have a concept of software Architects, which is
a pretty classic definition. But we do have staff Engineers,
which you can think that they're similar, but they're not the
same to stop injuries. Were building this payment
system that was processing more than 60 billion dollars a year.
So it's a pretty big system and we have to take two existing
systems and turn them into one. So we had a rider and Driver
sight system that were separate the team that was building.
It wasn't a 7. There was a staff engineer who
was basically leading this effort, but the staff engineer,
they did come up with a bunch of the design ideas, but they work
with the team. And even the design document for
this system. I think it mentions consistency
ones, but it uses very simple language.
It uses boxes and arrows and it was heavily debated and you see,
a lot of Junior Engineers. Also ask questions and also some
of the junior Engineers, real part of that document, this
staff engineer wrote the code. They're also on call.
And actually every staff is your, I've interacted a trooper.
Perimeter. So we don't do it but they write
code their own. The on-call rotation.
They're very approachable. They Mentor.
They do bring a lot of ideas and they will often suggest
something but you feel comfortable challenging that.
Now I compare this with a lot of the things that I'm seeing in
the I'm going to say more traditional South, a YouTuber
will build a system that works really well, we built it very
quickly and I had a bit of an aha moment where I talked with
the architect, at a large financial company who was the
Chief Architect for assist. And he was amazed at how quickly
we built our payment system. This person was working for
three years are The new system for this financial company.
A big financial company. I don't want to say that name of
it last time. So interesting.
So how does this work? Well, I our objective.
I have all these meetings and everyone signs that often.
They're going to build it. Oh, who is day?
Well, you know the developers. I'm like, okay.
So do you write code? I don't know.
I just give it to them like, you know, I have a team.
It's going to 50 people that they just do it.
Okay. So, what if someone disagrees
don't know, it's all falling out.
We've had all this meeting. So it's a good plan.
But if they disagree, they can come to me.
I have an office hour like once a week.
I was thinking to myself in a lot of companies over time.
It is Evolution. But you're in this Castle, the
Arctic is on the top and you don't mingle with the peasants.
I should find a counterproductive for two
reasons. One is as an architect.
You just don't know what's going on.
You've done the planning. You have this perfect plan and
in the reality, and we were building a payment system.
It was easy to build the payment system, pretty easy.
The difficult part was everything that followed
operating, it miring things over realizing.
After we deployed it. We missed a bunch of edge cases
because that's how it is. And that we were the architect
or the staff engineer was on the ground.
They saw this firsthand and team was there.
It wasn't just The staff Engineers effort, it was the
whole team's effort and the whole team salt, and the
progress was a lot faster. The other part that I don't like
about this model is in this model.
Your Junior Engineers are at the bottom of the hire her again,
and they will have a chance of growing.
They need to understand this lingo, they need to spend
exteriors and eventually maybe they'll get a seat at a table at
boober and other places. The junior Engineers are at the
table. They learn from scratch and I
saw some of these Engineers go from what I consider Junior to
senior in a lot shorter time because they were exposed.
So I think I will have a key for this model.
Some Buddy's. It might make sense where you're
very regulated and there's reason to do things and you'll
not have people being there, but I think it's a better model to
keep our texture simple. Instead of aiming to have a
great architecture, invest in your infrastructure, make it
easy to deploy things, quickly, make it easy to migrate.
A lot of people make fun of lubbers, microservices the how
many they have but guess what is super easy for us to iterate and
to learn and to change. I think a lot of the old cell
architecture has been because changing it has been difficult.
But if you can make a change you get easier, you can get a lot
faster Pace than a lot faster iteration.
So, how fast how frequent is it in?
Uber? Is it every month or so you
rewrite? Something?
No rewriters a different one. You don't want to take rewrite
easily. I will say, like, my rule of
thumb is when you have 10x you. So shorter, next users might be
traffic. It might be Revenue.
It might be the number of use cases.
You probably have to rewrite. So we're actually didn't have
that many rights for the payment system.
For example, there was a first version which was when we were
started, and it was just very junkie.
Then there was followed by very quick second version, when it
turned out, this business is working and that system work for
a long time and that system. Was built in mind of riders and
drivers. When it was only that one thing.
We only had one rewrite since which was when we realized it's
not just Riders and drivers. It's eats its Freight.
It's all these things and then we have to write that system.
So there's two or three rights and probably like six or seven
years and I rewrite is always a big thing to do.
That's a weird of the bigger system, but the service is there
because you're so small Services.
They have changed all the time. They have been replaced a bunch
of times. So the smaller parts, always
change over time, of course, the pace of change slows down as a
business matures. So this is also typical of we
were, when you build We don't know how big it's going to be,
and it turned out of this really big.
You'll have to change things more frequently.
So at the last count, homies micro services are then Uber and
don't know the exact number. I think number might have gone
down. I remember someone said, but I
don't know, quote. Exactly.
It is Thousands, but it doesn't seem to grow as crazy as before.
In fact, some of them are starting to consolidate like do
get the point of like again when it comes to architecture when
you have a company that's 30 or 40 or 50 years old and you know,
your business and that's not changing.
It probably makes sense to have schools Architects eventually
and to protect and not make some changes, but when You're growing
fast. You want to make change easier
and eventually you will sold out.
So like we were has written a blog post about this concept of
domain-driven microservices and domain layering.
So there's more structure coming in there.
But yeah early on just move fast.
I also saw the lesson that if you're successful, if your
business is successful, you will have the space and time or at
least the money to hire people and more people and pay off the
tag depth. And don't forget that, a lot of
companies are in the business of making money or having a
business model. If you don't have that, it
doesn't matter if you're a clean architecture, that's a good
point. That So get thanks so much for
sharing as a custom. In this show.
I would ask the last question for all my guests.
Can you share with us? Your three technical leadership.
Wisdom, especially coming from your experience and expertise
having been there. Working in big scale companies.
Yeah. So the first one is just know
what's going on under the hood. I was really lucky at Hooper
that when I joined as an engineer, which I'm really
grateful for, because I spent the first few months, just
writing code, and knowing exactly how things are working.
And later. This helped me a lot.
I saw managers struggle who came in and who have to rely on their
A team from day one and they could never roll out their
Studio. Didn't have the time.
If you go into new position or if your transition, just make
sure to take that time in the first one or two months to
actually write code, understand the architecture talk with the
engineers. So that's the first one.
The second one is give space for people to fail.
If you want to grow people. If you're serious about growing
your team, you can either tell them your stories and lessons or
mistakes, or you can just let them make those mistakes.
People will grow the best way if they make their own mistakes.
And as a manager or as a lead, you Want to provide that safe
setting. I'll give you an example.
This is a small one. But one of the more experienced
Engineers on my team was in charge of building a feature.
There was a deadline and they decided to not write unit tests
for this. I'm very against us it can only
for bad things but all things being equal.
I was like, okay. Well, it's your decision, but
you own the fall off as well. Sure enough in a few weeks or
months, something broke and that unit test would have prevented
and it was an outage and I both held my back to my management.
I was like, well, don't worry too much about this.
We've got it under control. But also this was great lesson
for that person if he came. To the conclusion saying, okay.
Well, it was not smart to skip it.
I learned my lesson, same thing. Although this is a really unique
example, but another one is more common with small projects or
projects. I would often give a smaller
piece of a project to a person and they would give me an
estimate and I know they're wrong.
I know it's going to take longer.
So externally, I'll communicate a lot more and I'll tell them.
Alright, show me, and then they'll be late, and then I tell
them. Okay, let's work together.
Let's reflect on it and then they'll ship on time.
But also the team doesn't get in trouble because I predicted this
would happen, but I didn't step in.
So try to not stick them because they're not gonna learn as much.
The third one, which is maybe a high-growth company or maybe any
company. If you can under-promise and
over-deliver, that is a pretty darn good strategy, especially
early on, it's always tempting. If you have a lot of things to
do to say yes, to a lot of things and then struggle to do
it. If you say yes, to fewer things
and say no to things. But the things that you do say
yes, to you consistently get done and maybe sometimes you're
able to do a bit more, you will build a reputation of being
reliable at most companies. There are very few people who
are consistently can meet their deadlines.
Very difficult. And the key is to say, no to
some other things. If you get a reputation, you'll
be on a fast track, your team will grow better.
You'll get more trust, you'll get more projects.
And, of course, you'll have to say no more.
So any tips, how to say, no better or just outright, you
know, you need to build this up. I think this will be unique to
everything. So my strategy of saying, no, I
don't say no. I say, well, here's a trade-off,
I can say yes, so I can do this, but I need to stop this other
project and wait, how much does that other projects in?
So for her to tips? First of all, for every project
you're doing every activity, have an Act.
What is this? Bring to the table?
And when you say no you don't say no.
You say okay. Well, we could stop project a.
That means we're not going to ship this impact of two million
dollars. Should we do that?
No. Okay.
What about stopping Project? B.
That means that our developers will not be 50% faster and
building stuff. And if you ask what was the
impact of your project? Oh a hundred thousand dollars.
Okay. Well, where do you think that
fist? You think we should stop the two
million dollar project or making our developers more productive
for any new work that comes in ask for the impact 50 or 80
percent of the time people use you don't know the They're like,
we need to do this. Why?
Well, because their customer says cool.
Do you have an impact estimation?
How many customers? How much revenue?
How much turn we don't have that?
Oh, geez. I wish we could do it.
But if you don't have the impact, if it's that important
come back with the impact sometimes said, yes, so for
really important project, we have salt work.
It's a bit of a moral drop, but we've sometimes on the right
thing and you need to have your North Star.
Maybe this is what worked for me, but you need to have a
consistent framework of, how do you say?
Yes, how do you say no? And how you enter up work?
And how do you tell the team impact is Always an easy one
because it's easy to sell the team.
We're going to stop this work because we have a project that's
10x, more important and the company survival depends on its.
Let's do it. We've had that a trooper.
Yeah. I think that's a very good tip.
Impact is the common ground for people to discuss about and if
everyone agrees, that's the kind of impact that is measurable as
well, and people can choose which one is more priority.
So, thank you so much for spending the time, Gail.
It's a pleasure learning from you hearing your stories.
So where can people find you online?
Maybe, if let's say, they want to connect.
So, easiest way it is pragmatic engineered.
Cam. That's my website and it has my
Twitter and Linkedin details. So feel free to connect on
Twitter or LinkedIn. I also have my contact details,
emails, Gehrig a at pragmatic engineer.com, bunch of different
communication channels. And then yeah, anything about
resumes. I have the resume book which is
free for anyone who is out of a job currently or might be out of
a job in the future. I'm writing another book.
So there's more details on that on the blog.
There's a newsletter. If you're interested is to try,
I don't send it to often. So feel free to subscribe.
So, when can we expect the new book?
I'm hoping it's going to be early next.
Here, I'd like to Target February and we'll see how that
goes. Because now, that I've written a
book. I know there's plenty of Hearts.
I'm in the content writing phase and then there's the editing and
there's a production izing. But I'd like to now stretch it
out beyond that. You know, this is the first time
I'm saying, something like this on a podcast.
So we'll see if this will stand the test of time.
Let's hope. So, I'll make sure that I'll
check it out as well when the time comes.
So thanks again. Yeah, it's very nice to speak
with you and good luck with your book and all the things that you
do in the future. Great.
Thanks a lot Henry. Thank you for listening to this
episode and for staying right till the end.
If you highly enjoyed, please share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It really really helps me a lot
in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at technology. No, the death website.
Including the full transcript interesting quotes, and links to
the resources and mentions from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on technology nor the deaf to get notified for any future
episodes. Stay tuned for the next
technique Journal episode. And until then.
Goodbye.