#15 - Tech Resumes & Learnings From Uber Engineering Manager - Gergely Orosz

Episode Introduction [00:00:42]

Henry Suryawirawan: Hello, my friend. Welcome to the Tech Lead Journal show with me your host, Henry Suryawirawan. 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 Tech Lead Journal 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, or 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 long time 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 would do my best to keep on improving the show.

Last week, you have listened from my first patron, Tony Luong, sharing his message about this show and his favorite episode. For today, I would like to introduce you to my second patron, David Kartopranoto 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 Tech Lead Journal.

David Kartopranoto: [00:02:19] 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 within the tech industry, I support him 110%. And hopefully it can be as big as Joe’s and Lex podcasts. Honestly, at first I was a bit skeptical on how it’s going to be, but as usual, Henry always managed 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 three. And in no particular order, it has to be the one with Jerome, Hongyi and Crystal episodes. As for the why, besides the top three wisdoms at the end of the episodes, that Henry always asks, I also find that their stories, challenges, and the things they need to do to overcome them are personally relatable to me. I guess that’s it! Good luck Henry for the future episodes, and our we’ll always keep supporting the podcast! Goodbye.

Henry Suryawirawan: [00:03:23] Thank you again, David, for 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 patron page at techleadjournal.dev/patron. I’m currently running a goal on my patron page, and your support would tremendously help me towards achieving it.

Our guess what today’s episode is Gergely Orosz. Gergely is a seasoned software engineer and engineering manager, and was last at Uber. Before Uber, he also worked in other hypergrowth 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 I’ve found for coming up with a great tech resume, with lots of examples 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, Gergely kindly offers this book for free, which you can find more information about on its website, thetechresume.com, which you can also find in the show notes.

In this episode, Gergely shared about his interesting career journey path, starting from being a software engineer at small companies, and then moving to hypergrowth 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 Uber’s pace of change. Gergely recently quit Uber. And he shared with me his reasoning and what he currently has for his future plan. Lastly, we discussed about his blog, “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 Podcasts 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.

Introduction [00:06:29]

Henry Suryawirawan: Welcome Gergely to Tech Lead Journal show. It’s 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, Gergely. Looking forward to learning from you. Gergely Orosz: [00:06:49] Yeah. I’m really glad to be on the show. Thanks for inviting me.

Career Journey [00:06:51]

Henry Suryawirawan: [00:06:52] So Gergely, I saw your profile. You have tremendous career journey. Starting from working as a software engineer, and then climbed the ladder into different companies, worked in tech unicorns - the last one was Uber before you quit just a few weeks ago, I guess. 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 some turning points that changed your career.

Gergely Orosz: [00:07:15] Yeah, so well, looking back, I’m pretty happy with my career journey. Although 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 a 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 then the last two years, I worked full time at a small local company, building Content Management Systems. But back then, these things were big, but I was working on that. And right as I graduated, I decided to move abroad. Partially because I had a girlfriend at the time 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 straight to Edinburgh out of college. And I was lucky enough to join a small 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 interviews. 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 interviews at all. I felt really strange. I’m like, “I think I’m smart. I think I know what I’m doing.” Anyway, after a few weeks, I did get a couple of interviews. And I got offers wherever I 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, when we knew that Google had difficult interviews, but there was no preparation. So I actually prepared for the Google interview. I prepared for the coding, the algorithmical self-challenges. And this company was asking those challenges. So I had two developers asking me to code and whiteboard and do all this things, and I actually practiced all of this. Later they told me that they hired about one candidate from about a hundred. And they were doing this Google sort of interview 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 over-prepared.

The nice thing about joining a company that has a high hiring bar, I worked 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 Web Assembly community. And I had really good mentors. From there on, I spent two years there building small products. I moved up to London, which was a big leap for me, from Edinburgh all the way to London. I worked at JPMorgan, big investment bank, worked with the trading floor. It was very interesting learning for finance, and how traders work, and how our trading desk moved huge amounts of money, and it was interesting to see how that’s 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. I built a couple of apps that were very well known. And then Microsoft reached out to me saying, “We can’t tell you what we’re doing, but it’s going to be something new and exciting.” And it turned out to be the Skype for X-Box One. They were building it in London. So I joined Skype or Microsoft right after they acquired Skype. And Microsoft had this new policy to leave companies completely alone for 18 months. So it didn’t feel like Microsoft at all. And this was the old Microsoft, Steve Ballmer’s Microsoft. It just felt exactly like Skype. So we were a small team. We could do whatever we wanted. And then in London, we built Skype for X-Box One. We shipped it, which was a really fun project. On launch week, we had a million people use the product that we used them. Skype was a huge feature for X-Box One. It was the first console that was just not a games console.

And then I moved on to different teams to build Skype for Web, which was a Google Hangouts competitor. Also a very fun challenge. As I did it, I kept changing stacks. So that was also something interesting that I didn’t deliberately do. But, when I joined Microsoft, they hired me as a C# developer, C#, WPF, SAML, that kind of stuff, cause that’s what we were supposed to build Skype with. One month into the project, we were told the C# compiler will not ship on Xbox. They don’t have time to do it. It’s going to be HTML and CSS and C+ on the backend. And so we just had to relearn that stuff. Looking back, one of the learnings I had in my career is whenever you have a challenge, you can just turn it 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 it. It’s JavaScript and HTML.” This was back in 2013, before 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 had this framework called WinJS. And in the end, I ended up recording a course on WinJS, on how to use WinJS. We became WinJS experts, which was actually one of the, I think most popular WinJS courses at the time. Again, WinJS 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 slowed down, I jumped ship to a startup called Skyscanner. They’re a 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 startup. And then finally, I spent the last four years at Uber. 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 to grow with them. And I worked on different projects. So since Skype, for the past eight years, I’ve been working in what I would call hyper-growth environments, which was absolutely accidental. I had no idea this would happen. But I basically joined 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, when you have to hire, but keep the morale. At Skyscanner, I started to become a manager. I ended up hiring a small team. And at Uber, I joined as an engineer. But I very quickly basically went back or became a manager again. When I left, I was managing a manager as well. I was on that managing managers track potentially.

Why Getting Interviews Could be Tough [00:13:00]

Henry Suryawirawan: [00:13:00] 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 climbed from a small company. And up to the latest one, which is Uber, which you categorize 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 are just not visible enough? Like they couldn’t get interviews because of something. Maybe you can share from your experience?

Gergely Orosz: [00:13:31] Yeah, I think it’s human 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 posts. 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 was also upset. So after I got hired, I started to get messaged from recruiter saying, “Hey, are you interested in this other job?” And I was a bit upset. “What do you mean? You’ve never talked to me. Why are you talking to me now?” But especially at Uber, I got to know recruiters really well. And I’m someone who’s very curious. It is good to understand the recruiter’s point of view. If any software engineer 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 a recruiter, ask them how they got into recruiting. And a lot of recruiters will tell you, “Well, I’d had an arts major, and I wanted 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 of recruiting school and I wanted to be a recruiter. Usually, it’s a secondary choice. And on top of that, they have really hard expectations. 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 onsite. 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 you an example, a lot of engineers complain, why they get some flooded 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 your Stack Overflow, 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 reply. It doesn’t matter how nice that messages, you just don’t want to change. So after a while, they realized that even if they send a short message, they get roughly same response rate, because it 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 they end up optimising for that. 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-line said “Hungarian”, which you never put on there. I put my birth date. The format just screamed “this person does not belong here, there are someone 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 resume. Whenever you go somewhere new and you have zero references, it’s hard to break in it. It is hard to break into tech, unless you go for a traditional 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.

Henry Suryawirawan: [00:16:14] So I can understand, when you mentioned about this recruiter, I can also empathize with them, their job, how hard it is. They probably need to message hundreds, could even be thousands of candidates. Maybe only 10% response rate. It could be even lesser. So I really can empathize it.

“The Tech Resume Inside Out” Book [00:16:29]

Henry Suryawirawan: Let’s switch back to the resume you’re talking about. You mentioned about some of the bad things that you did last time. Why you put pictures or maybe mentioned 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?

Gergely Orosz: [00:16:47] Yeah. So this was very interesting. The book is called " The Tech Resume Inside Out". And it refers to the fact that it’s giving a little bit insider 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 a 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. It’s 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 would have not 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 a 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 planned 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 have a lot of things to take care of at Uber. And also layoffs came to Uber, to my old company, Skyscanner, they were hit quite hard. And I was thinking of how I can help people. So I offered to do resume reviews, both for people who were impacted that I knew personally. And I put it on Twitter as well saying if anyone is looking for a job as a developer and you want some resume 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 of applications. For senior, my most common software resume is a LinkedIn screenshot. And we spend the time, look through it because even for likes of Uber, 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 who were hiring, they were seeing surges of 10 or even sometimes 20X the usual applications, and resumes suddenly started to matter. The resume feedback that I give to people, people said that it actually helped them get that first recruiter call. And then I decided to kill two birds with one stone. So I started to scale myself. I got so many inbound applications that I could give high quality feedback for, let’s say the first 50, and then I just did what you usually do. Well, what I usually do. I put together the most common advice. I ended up putting it in a PDF. And I sent it to everyone else saying, “Read all of this stuff, look at the, this and this section and this might apply a bit more to you.” And now, why did it turn into a book? It could have just stopped that as PDF, or it could have done 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 turned it into something that I would want to read, which is very specific advice with examples saying, alright, here’s an example of this section. Here’s 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 resumes. So I asked permission from a bunch of people who ended up getting interviews and later jobs. And then finally, I also had some resume templates. 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 scan resumes and the ATS system, Application Tracking System. 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 desperate job seekers. And that’s also one thing that I really don’t want to do with 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’d engage readers, but for the people who need it most, people who are out of a job, it’s free. There’s no strings attached. They get the whole thing. The only thing I’m asking for 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. It’s unexpected for me. Again, I don’t have any goals here. So either people are buying it, people who don’t have a job are buying it as well, or maybe there’s not as many engineers out of the job as I had seen, or maybe not as many people know about it. Cause again, I’m fine to keep it like this, at least until for another year, and that COVID subsides, and we’re getting a little bit back to normal.

Henry Suryawirawan: [00:21:25] 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 I 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.

Tech Resume Pitfalls [00:21:51]

Henry Suryawirawan: But first of all, maybe if you can highlight a few things. What are some of the common pitfalls that every techie writes in terms of their resume?

Gergely Orosz: [00:21:59] 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. The goal of your resume is to get a recruiter call. 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. That means you’re now at the next stage of the process. What matters is what you interact with the recruiter. You can then give them additional context, and then have recruiter or hiring manager, so that first call, they’re going to decide are you going to come onsite. Now, typically after your resume, they’re going to confirm some soft skills. Can you communicate? They might ask for visa. That kind of stuff. But once you’re on site, your resume is irrelevant. The reason I say that most people don’t know this because if this is the goal, then 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 land. Don’t do that. And you will see a lot lower 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 there.

And this is why about the first third of the book is not about the resume. It’s about telling you how the hiring process works. Because here’s how the hiring process works. I’m a hiring manager, and I have what we call an opening or requisition. I want to hire something. And let’s say, what happened is someone quit on my team. This person was an engineer with two years of experience, and I need to replace that person, and I need to do it now, because I have a problem. I need to do as soon as possible. So I write the job description. I write in there what matters to me. I might write that I need two years of experience because, maybe this person was there. I need experience with this and this 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 when I’m scanning those resumes, I’m going to ask, “Can this person do the job?” That’s what I’m interested in. 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 talked 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’s seen about 20,000 resumes in the past 20 years easily. She’s done 6,000 interviews herself with developers. And she told me this, she said she still believes this is a sales pitch, writing a resume. She rewrites their resumes. So a lot of times when these recruiting agencies, they ask for a resume in a document format or docx, is because they rewrite it later to try to sell you better. They’re not doing it out of bad content. And she told me, there is no resume that you can not work with. But most developers are not good at selling themselves. And for better or worse, I don’t like that this 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 a job description. If the job is talking about distributed systems, or if another job is talking about building web products, you probably mirror a little bit of the language to make it clear that you are capable of doing this job. So that’s the main takeaway.

Henry Suryawirawan: [00:25:12] So yeah, for those listeners out there who want to improve your resume, your tech resume, please go and find the book. I’ll put it in the mentions as well.

Working at Uber [00:25:20]

Henry Suryawirawan: So moving on to your career, you last held the position at Uber as an engineering manager. Maybe you can tell us a little bit about what are the major challenges that you worked on when you were there? I know Uber 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?

Gergely Orosz: [00:25:39] I know when we say the word Uber, different people think different things. Some people think, “Oh, what a terrible company.” I remember some really bad news from 2017. When I joined, Uber’s press was fantastic. So they just raised 13 or 10 billion or so from the Saudis, and their valuation went to 72 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 Uber is doing thousands of microservices. And everyone was sitting back in awe. It sounded like amazing company. It sounded like the next Facebook or Google. And one of the first challenges when I joined 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 had meetings in Amsterdam at 11:00 PM or midnight. It was a little bit sobering. And by the way, this is not just the 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 joined that company, you would see that some things are not as amazing as you think. Because they’re young companies, and that’s normal. But one of the biggest challenges when I joined Uber is we had 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 had 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 finished the work, not just left it halfway.

Managing Engineering Team at Hyperscale Company [00:27:16]

Henry Suryawirawan: [00:27:16] At that time, I think Uber, like what you mentioned, is growing very fast. I’m not sure what’s the latest system architecture of Uber, but I assume it will get bigger, and especially they are in multiple different countries. So how can you successfully manage engineering team there? Is there any difference in terms of, compared to other traditional companies, is there any difference in how you manage such a team for such a growing hyperscale company?

Gergely Orosz: [00:27:39] Well, I was a manager at Skyscanner and Uber, also both were startups, so I don’t have as much to compare as a manager. I can say what I’ve seen from the other side. I personally think it’s actually easier to manage teams out of 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 started to not get backfills, 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 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 here is providing focus, helping the team succeed. Hiring is a big challenge, because you have to hire while keeping the team happy. When I joined, some of my mentors have told me that one of the most important things 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, or five years. When you hire someone, it takes about six months for them to get up to speed, to know how they’re working, and it’s always a bit of a risk. At Uber, I was really lucky as well. On my team, until the layoffs, in the end no one left the company. Some people did move teams, but everyone was there, which was incredible. For four years, no one left on my team.

Henry Suryawirawan: [00:29:18] Wow. That’s a pretty good achievement, I would say, especially in Silicon Valley, people poaching each other.

Gergely Orosz: [00:29:23] Totally agree. But this was also Amsterdam. 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 gelled so much better than early on. I do say 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 a non-experienced engineering manager. And I had engineers who were not experienced as well. But we grew together. And we became this really strong team. And now a lot of people there, they’re still at Uber, they are very strong engineers. They’re often central, go-to people for a lot of projects. And they have really strong goal ahead of them, may that be at this company or other companies.

Henry Suryawirawan: [00:30:00] So what are some of your personal tips on how to grow a well-gel team? Sounds like you have a very good maybe, culture, process, or boundaries, practices maybe?

Gergely Orosz: [00:30:10] Yeah, the biggest one. I get a lot of inspiration from this book that a couple of 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 its captain. Apparently the Navy to run a submarine, you have to go through this training school where you learn everything about that model, the submarine, and how it works, and 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 where whoever does this fastest or best, it gets points. And then you can basically see who has 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. It’s very different. It’s like if you’re training for one type of plane and you have to fly a different one. And second, 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. 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 “Alright, so what are you going to do?” And you’re like, “What?! What am I supposed to do? No, no, no, you need to figure that out.” So it’s a very different culture. In a lot of European companies, engineers are resources, and you’re told you get the Jira ticket, and that’s it. I tried to instil 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 this team for the first project. I set 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 kinds of things. I have a framework that I put together, and then later ask the team to do this in shorter projects, of projects, one, two, three, maximum four months. And then I asked someone else to lead 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 ask the senior person to support them. So I tell them your job is to make this person successful. This worked 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 that project, but later they’ll 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 than I would have done. And you could scale yourself a lot more. So this also helped me, as the team grew, we had leads. Some people became managers later. And even when there 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 a really senior person. “Alright. Why don’t you do this? Why don’t you do that?” So just find that fine line. I feel I’ve been lucky enough to find it, with Uber at least. And I have a post. We can link it on the show notes, where I describe what worked and I shared this document that I put together of expectations. I would advise don’t copy anything that you see, but you can think about on your team, can you try to instill something like this? What I do know for sure, and this is my main philosophy, a motivated engineer who is 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 smarter work. So that’s what you should aim for.

What Silicon Valley Gets Right Dealing with Software Engineers [00:33:34]

Henry Suryawirawan: [00:33:34] So I want to go back to the point that you made just 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?

Gergely Orosz: [00:33:52] Some people might disagree. I’ve talked with people who worked in Silicon Valley and they said that their company doesn’t work like this. But in general, I find a big differentiation. The biggest one is how companies look at their 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? We’ll tell them what to do. And they’ll do it. And we’re going to make the decisions, because we know the business, and then we do all of those 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 Uber has been a fantastic example on this. One of the cultural values of 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 had this session where one of the teams who was doing cash payments, all the engineers called up drivers and asked them, “Hey, how are you using our product? What do you like about cash? What do you don’t like about cash?” The engineers were calling them up. And the drivers are saying, “I hate this about it, or I hate…”. And they’re usually like, “Whoa, Whoa, Whoa”. So they talked 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’re building, which in my case was payments. We did this and afterwards, 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 show the generic message, “Oops, something went wrong”, because it was easy to do. We knew this was not really good, and some people from the business were 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 proposed we fix it. They did an estimate. They worked with some data scientist. The engineer actually worked with the data scientist. We shipped it. We estimated that maybe it’ll bring in a $1M or 2M per year. And it brought in 10 times that much. And this was all from an engineer.

Having seen this at Uber, software engineers, if you’re smart and 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 the development speed will be faster. Maybe you could fix some bugs.” And people are a lot more engaged. The result of this is by the way that these engineers 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 on later in their career, and they might co-found companies because they understand the business. And I had a big revelation when an engineer came over from a company that was consultancy, and they always gave him JIRA tickets. He was supposed to work on that. If he asked questions, it wasn’t very welcome, because the higher ups decided what to do. This person was confused on how this whole system worked 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, and I don’t want to go back to the old way.” So even when this person left Uber, they didn’t go back to old company, who would have welcomed them back. He actually wants to do something different. Smaller companies have more autonomy and have a say in how things are being built.

Henry Suryawirawan: [00:36:43] Yeah, I can totally understand. I mean, for me as well as a software engineer, we don’t like to be told, “Oh, 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 problems, to the customers, can also intrigue us to find a better solution, including some of the minor details in the code. Maybe the flow can be better. The UI can be better as well. So, yeah, I think that’s a very good advice from you.

Leaving Uber [00:37:12]

Henry Suryawirawan: One major question that I have, looking at all your growing and challenges and success at Uber, why did you quit recently?

Gergely Orosz: [00:37:19] I left because it felt like a good time. I was at Uber for four years. And before that for about eight years, I was at these high-growth companies, which were maybe not Uber, but they were pretty similar. And it seemed when I joined Uber, I came here to take a bet as well, to see if this thing would grow bigger. And it did. I also set myself… (you know) what, after about four years, I’ll take a look at it, and see where I am, and what I’d like to do next. As I did, I realized that thanks to having worked at 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 startup, 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 who left Uber told me the same thing. They said, “You know, I joined Uber really early on. I never thought I would do a startup. But I saw how Uber works 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 reward. But I’m also missing that experience from my career of doing something from very small. I have done 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 to also finish my book about growing as a software engineer, which is a lot of the things that I’ve seen, and maybe it’ll be helpful for other people. I knew that if I would stay with Uber, it will take a lot longer to finish. These two things just seemed 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 dot-com boom, or maybe even bigger. But during a crisis, you also have an opportunity. During crisis is probably the best time to start something small, something new in your company. And in certain cases, it is easier to hire. Capital is still very strong everywhere. So there have been 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 I also see the opportunity.

And then finally honestly, it’s 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 exactly. There’s the scenario, lower likelihood, but I might go back to doing 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 Uber 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 just to start a new one. So I’m doing something different. And we’ll see if it pays off or not.

Writing Blogs [00:40:01]

Henry Suryawirawan: [00:40:01] Let’s 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?

Gergely Orosz: [00:40:09] I’ve been blogging for more than 10 years. But for the first many years, it wasn’t that interesting blog. I have to clean it up. It’s my first name, last name.com. It’s a WordPress site. It’s 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 three years ago. And what prompted me is that I set myself a challenge. I got really inspired by reading Jeff Atwood’s advice, to start a blog, just blog regularly. 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 then 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 front 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 agreed with me. And I was like, “Huh, that’s interesting! People find my blog interesting.” I didn’t know that, because before that, I didn’t get any sort of traffic. And then I started to go back and add articles every now and then. 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 discover it, 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, at 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 the spec. I talked with a bunch of the staff engineers. And I realized, you know this distributed systems, I think it’s a bit over-hyped. Everyone talks about it, but it’s not as complicated. So I just summarize what I think the basics are. This blog became really popular. It’s 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 am a better writer because I blog, and because I get feedback, and then I blog 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 at Uber, not being a good writer is starting to become a blocker for people to go beyond the senior level. Because in a distributed 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 is writing is becoming more important, and communication is becoming more important for software engineers. It’s 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.

Distributed System [00:42:44]

Henry Suryawirawan: [00:42:44] 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-hyped about this distributed system?

Gergely Orosz: [00:42:52] 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 consistency, 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 came over, an engineer on the team, and he was doing an overview of one of the payment systems that they built. And he was saying like, “Oh yeah, because we made it this eventual consistent, we made this decision because strong consistency was not a requirement. And this works well enough, although we have some trade-offs.” And I was like, “Hold 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 put up their hands. And I was like, “Okay. So do you mind explain to us what you meant by 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 locks people out of there. And it’s not that complicated. In this blog post, 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 invoke it. So you do a GET to an endpoint, and always returns the same thing. And this can be important for, let’s say payments. An endpoint will be idempotent when you try to charge a payment, and you get a response that either says “yes”, or it says “no”. And if you charge it the second time after it’s successful, it’ll return you “no”. And you can do it multiple times and you’ll still get the same response. There’s only a handful of this concept. And once you know these things, you can confidently speak distributed systems. And again, there’s some use cases where these are important. Some use cases where they’re not. Same thing with scaling. Everyone talks about “Oh, we need to make it scalable.” Well, with 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, when I talk with people like consistency or idempotency. Well, you do it when you know that they speak the same language. But, I think it’s easier to explain, and more clear, if you can get people included in a conversation. So that’s what the blog post is about. It seemed it’s resonated with people. And I hope some of these special words will be broken down, or it will be either part of the vocabulary, or it’s just more accessible to everyone.

Other Popular Blog Posts [00:44:53]

Henry Suryawirawan: [00:44:53] So for those of you who are still having a lot of doubts about what distributed system is, do check it out. So I’m just a little bit curious as well, which posts that you have on Hacker News? The one that made you popular.

Gergely Orosz: [00:45:04] That was a very early post, that’s one of the first ones. It’s all listed. It’s called “A Comment is an Invitation for Refactoring”. So I wrote about… I had the strong conviction which changed has since, 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 end. On Hacker News, this created a really polarized the base. Some people were saying “Absolutely not”. And some people were saying, “Hold on, this got a good point.” So 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 edited. But 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 will agree. And that’s great.

Henry Suryawirawan: [00:45:52] So there’s one more thing that I saw from your blog as well. It’s about “Software architecture is overrated, while clear and simple design is underrated.” Maybe can you explain a little bit about that?

Gergely Orosz: [00:46:01] Yeah. So this was a really interesting one. 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 polarized response. A lot of people agreed. A lot of people didn’t. One thing that struck me as very interesting and good at Uber 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. The staff engineers were building this payment system that was processing more than $60 billion 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 a driver side system that were separate. The team that was building it wasn’t a staff. And 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 a 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 wrote part of that document. This staff engineer wrote the code. They’re also on call. And actually, every staff engineer I’ve interacted at Uber, maybe there’re some who don’t do it, but they write code. They’re on 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 style. And at Uber we built 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 a chief architect for a system, and he was amazed at how quickly we built our payment system. This person was working for three years, architecting the new system for this financial company, a big financial company. I don’t want to say the name of it. But I asked him, “Oh, interesting. So how does this work?” “Well, I architect it. I have all these meetings and everyone signs it off. Then they’re going to build it.” “Oh, who is they?” “Well, you know, the developers.” I’m like, “Okay, so do you write code?” “Oh no. I just give it to them. Like, you know, I have a team. It’s got 50 people. That they just do it.” “Okay. So what if someone disagrees?” “Oh no, it’s all thought out. We’ve had all those meetings, 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’s an evolution, but you’re in this castle. The architect is on the top. And you don’t mingle with the peasants. I just find it 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, at Uber, building the payment system, it was easy to build the payment system. Pretty easy. The difficult part was everything that followed. Operating it. Migrating things over. Realizing that after we deployed it, we missed a bunch of edge cases, because that’s how it is. And at Uber, the architect or the staff engineer was on the ground. They saw this firsthand. And the team was there. It wasn’t just the staff engineer’s effort. It was the whole team’s effort. And the whole team solved it. 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 hierarchy. And they don’t have a chance of growing. They need to understand this lingo. They need to spend X years. And eventually maybe they’ll get a seat at the table. At Uber and other places, the junior engineers are at the table. They learned from scratch. And I saw some of these engineers go from, what I considered junior to senior, in a lot shorter time because they were exposed.

So I think I will advocate for this model. Some companies, it might make sense where you’re very regulated, and there’s reasons to do things, and you do not have people being there. But I think it’s a better model to keep architecture simple. Instead of aiming to have a great architecture, invest in your infrastructure. Make it easy to deploy things quick. Make it easy to migrate. A lot of people make fun of Uber’s microservices, of the how many they have. But guess what? It’s super easy for us to iterate and to learn and to change. I think a lot of the old style architecture has been because changing it has been difficult. But if you can make a change, it gets easier. You can get a lot faster pace and a lot faster iteration.

Uber Pace of Change and Microservices [00:49:31]

Henry Suryawirawan: [00:49:31] So how fast? How frequent is it in Uber? Is it every month or so you rewrite something?

Gergely Orosz: [00:49:36] No. Rewrites, there’s a different one. You don’t want to take rewrites easily. I will say like, my rule of thumb is: when you have 10X usage or 10X users, might be traffic, it might be revenue, it might be the number of use cases, you probably have to rewrite. So we actually didn’t have that many rewrites for the payment system. For example, there was a first version, which was when Uber started, and it was just very junky. Then there was… followed by very quick second version, when it turned out this business is working. And that system worked 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. It’s freight. It’s all these things. And then we have to write that system. So there’s two or three rewrites in probably six or seven years. And a rewrite is always a big thing to do. That’s the rewrite of the bigger system. But the services there, because they’re so small services, they have changed all the time. They have been replaced a bunch of times. So, the smaller parts always changed. Over time, of course, the pace of change slows down as the business matures. So this is also typical of Uber, when you build something where you don’t know how big it’s going to be, and it turns out it’s really big, you’ll have to change things more frequently.

Henry Suryawirawan: [00:50:36] So at the last count, how many microservices are there in Uber?

Gergely Orosz: [00:50:39] I don’t know the exact number. I think the number might’ve gone down. I remember someone said, but I don’t know (the) 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. I 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 it’s not changing, it probably makes sense to have the smallest architecture 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 slow down. So like Uber 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 that tech debt. 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 have a clean architecture.

3 Tech Lead Wisdom [00:51:30]

Henry Suryawirawan: [00:51:30] That’s a good point there. So Gergely, 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 3 technical leadership wisdom, especially coming from your experience and expertise, having been there working in big scale companies?

Gergely Orosz: [00:51:44] Yeah. So the first one is, just know what’s going on under the hood. I was really lucky at Uber that when I joined as an engineer, which I’m really grateful for. Because I spend the first few months just writing code and knowing exactly how things are working. And later this helped me a lot. I saw managers struggled, who came in, and who had to rely on their team from day one, and they could never roll up their sleeves, or they didn’t have the time. If you go into a new position, or if you’re transitioning, 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 should 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 this. It can only lead 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 a month, something broke. And that unit test would’ve prevented it. And then, 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. 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 step in because they’re not going to learn as much.

The third one, which is maybe at a high growth company, or maybe any company, if you can underpromise and overdeliver, 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 consistently can meet their deadlines. It’s very difficult. And the key is to say “no” to some other things. If you get that reputation, you’ll be on a fast track. Your team will grow better. You’ll get more trust. You’ll get more projects. And then of course, you’ll have to say “no” more.

Henry Suryawirawan: [00:54:12] So any tips, how to say “no” better? Or just outright “no”?

Gergely Orosz: [00:54:16] 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 the trade-off. I can say “yes”. So I can do this. But I need to solve this other project. And wait, how much does that other project seem? So, okay, two tips. First of all, for every project you’re doing, every activity, have an impact. What is this bringing to the table? And when you say “no”, you don’t say “no”. You say, “Okay, well, we can stop project A. That means we’re not going to ship this impact of $2 million. Should we do that? No, okay. What about stopping project B? That means that our developers will not be 50% faster in 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 fits? Do you think we should stop the $2 million project? Or making our developers more productive?” For any new work that comes in, ask for the impact. 50 or 80% of the time, people usually don’t know the impact. They’re like, “We need to do this.” Why? “Well, because our customer says.” “Cool, do you have an impact estimation? How many customers? How much revenue? How much churn?” “We don’t have that.” “Oh, geez. I wish we could do it. But if you don’t have the impact, if it is that important, come back with the impact.” I sometimes said “yes”. So for really important projects, we have stopped work. It’s a bit of a morale drop. But we’re 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 interrupt work, and how do you tell the team. Impact is always an easy one. Because it’s easy to tell the team, “We’re going to stop this work, because we have a project that’s 10X more important, and the company’s survival depends on it. Let’s do it.” We’ve had that at Uber.

Henry Suryawirawan: [00:55:40] 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, Gergely. 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.

Gergely Orosz: [00:55:59] So, easiest way is pragmaticengineer.com. 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. Email is gergely@pragmaticengineer.com . A 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 to subscribe. I don’t send this too often. So feel free to subscribe.

Henry Suryawirawan: [00:56:28] So, when can we expect the new book?

Gergely Orosz: [00:56:30] I’m hoping it’s going to be early next year. 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 only a parts… I’m in the content writing phase. And then, there’s the editing. And there’s a productionizing. But I’d like to not 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.

Henry Suryawirawan: [00:56:47] I’ll make sure that I’ll check it out as well, when the time comes. So thanks again, Gergely. It’s very nice to speak with you. And good luck with your book and all the things that you do in the future.

Gergely Orosz: [00:56:56] Great. Thanks a lot, Henry.

– End –