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. No, yes. 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.