The Pragmatic Engineer - Promotions and tooling at Google (with Irina Stanescu, Ex-Google)

Episode Date: November 6, 2024

Brought to you by:• WorkOS — The modern identity platform for B2B SaaS.• Sonar —  Trust your developers – verify your AI-generated code.—In today’s episode of The Pragmatic Engineer, I���m joined by Irina Stanescu, a seasoned engineer with over 14 years in software engineering and engineering leadership roles at tech companies like Google and Uber. Now an engineering leadership coach, Irina helps tech professionals build impactful careers, teaches a course on influence, and shares insights through her newsletter, The Caring Techie. In our conversation today, Irina shares her journey of rising through the ranks at Google and Uber. We dive into the following topics: • An inside look at Google’s unique working processes• How to build credibility as a new engineer• Tactical tips for getting promoted • The importance of having a career plan and guidance in designing one• Having influence vs. influencing—and how to become more influential • Essential leadership skills to develop• And so much more—In this episode, we cover:(01:34) Irina’s time at Google(03:10) An overview of ‘design docs’ at Google(08:27) The readiness review at Google(10:40) Why Irina uses spreadsheets(11:44) Irina’s favorite tools and how she uses them(13:46) How Google certifies readability(15:40) Google’s meme generator (17:36) Advice for engineers thinking about working for an organization like Google(20:14) How promotions work at Google(23:15) How Irina worked towards getting promoted (27:50) How Irina got her first mentor (30:44) Organizational shifts at Uber while Irina and Gergely were there(35:50) Why you should prioritize growth over promotion(36:50) What a career plan is and how to build one(40:40) Irina’s current role coaching engineers (42:23) A simple explanation of influence and influencing (51:54) Why saying no is necessary at times(54:30) The importance of building leadership skills—The Pragmatic Engineer deepdives relevant for this episode:• Preparing for promotions ahead of time: https://newsletter.pragmaticengineer.com/p/preparing-for-promotions • Engineering career paths at Big Tech and scaleups: https://newsletter.pragmaticengineer.com/p/engineering-career-paths • Getting an Engineering Executive Job: https://newsletter.pragmaticengineer.com/p/getting-an-engineering-executive • The Seniority Rollercoaster: https://newsletter.pragmaticengineer.com/p/the-seniority-rollercoaster—Where to find Irina Stanescu:• X: https://x.com/thecaringtechie• LinkedIn: https://www.linkedin.com/in/irinastanescu/• Website: https://www.thecaringtechie.com/• Maven course: Impact through Influence in Engineering Teams: https://maven.com/irina-stanescu/influence-sweWhere to find Gergely:• Newsletter: https://www.pragmaticengineer.com/• YouTube: https://www.youtube.com/c/mrgergelyorosz• LinkedIn: https://www.linkedin.com/in/gergelyorosz/• X: https://x.com/GergelyOrosz—References and Transcripts:See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

When you arrived at Uber, how did you feel internal tool in compared to Google? Definitely not at the same level. Google had everything internal. So I had to learn the equivalent of whatever Google had. And I remember my ex-Gougler co-workers literally made a document translating the various tools like code search, Fabricator, Grafana. Like, I didn't know any of these things. Google had a great culture of design docs. It was unheard of to not have a design doc for something.

They wouldn't talk to you if you didn't have the design dog. He couldn't just go and say, hey, I have this idea. Let's do this. They're like, where's the design dog? And that was shocking to me to come to Uber, where I was given a project and I started writing the design doc and started, you know, sharing it with people. And they're like, wow, this is cool.

Irina Stanescu has been a software engineer for more than a decade and a tech lead for seven years, working at Google, Uber, and then an AI startup called Nemonic. In this conversation, we covered with Google's life from the inside from a software engineer's point of view. We touch on internal tools at Google, like critique and Borg and unique engineering processes like the concept of readability review. Arena shares practical advice on how to think about promotions at these large companies

and will close with tactical pointers on how to become more influential as a software engineer within your team and organization. If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube. One thing that I really appreciate about this episode is just how candid arena is about how things worked at Google and Uber. She can do so because she's currently taking a break from corporate life and she's doing plenty of reflections as she coaches tech professionals and writes to her news that are called the caring techie. So with this, let's jump in.

Irina, welcome to the podcast. Hi, thanks for having me. Can we talk about on Google Fiber when you worked there and you moved over to Google's tech stack? How was a project like done in terms of this, this might have been a product development or building a feature? Like how did you all do, you know, planning, coding, tracking progress, code reviews, those kind of things. And what kind of tools did you use? I was as a tech lead sort of given a big problem.

TV ads on live streams, for example. I would then start the design process, talk to product managers, figure out if we had what is like the set of requirements, do the design dog, get the design up. I was given the problem with the requirements, including and was asked to design the solution not to figure out what, you know, the product. We did have a product manager, which was actually very helpful, and we had a great relationship. And one of the things I really appreciated at Google is I had a good relationship with product in the

sense that I was involved in the product definition. So I could say this is not really feasible. This is feasible. And I feel like in other companies, engineering is involved a little later than ideal. And that was that. And then design docs. We had a good process of design docs. We use Google Docs for that, not a lot of like internal tooling for that.

Manual approvals, I think. But by the way, this was a time where design docs were not really common, right? Like this was, I think now it's pretty common. or people know about it. But back then, this was... Culture of design docs, even before my time, I would say. And this is like 2012, 2013. It was unheard of to not have a design doc for something.

For the projects that I led, it was a lot of cross-organizational coordination with double-click, for example. They wouldn't even talk to you if you didn't have the design doc. Like, where's the design doc? And they're great people, by the way. I collaborated very well, but, like, you couldn't just go and say, hey, I have this idea. Let's do this. They're like, where's the design doc?

I want to read. Like, no, seriously. And that was shocking to me to come to Uber, where I was given a project and I started writing the design doc and started, you know, sharing it with people. And they're like, wow, this is cool. Yeah. Well, it later changed, right? Like years later, as you said, it did change.

but early on, no, it was more of a nice to have. It was more like, oh, you had the problem. Okay, let me go code. This episode was brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like Sammel authentication, skin provisioning, and fine-grade authorization.

That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand, and you can ship quickly and get back to building other features. WorkOS also provides a free user management solution called AuthKit for up to 1 million monthly active users. It's a drop in a replacement for Alt Zero and comes standard with useful features like domain verification, rule-based access control, bot protection, and MFA.

It's powered by Radix components, which means zero compromises in design. You get limited as customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Versal, and Perplexity. Check it out at Worko-Oads.com to learn more. That is workOS.com. This episode was brought to you by Sonar, the creators of Sonar Cube Server, Cloud, ID, and Community Build.

Sonar helps prevent bugs, code quality, and security issues from reaching production, amplifies developers' productivity in concert with AI assistance, and improves the developer experience with streamlined workflows. Sonar analyzes all code regardless of who writes it, your internal team or gen AI, resulting in more secure, reliable, and maintainable software. Combining Sonar's AI code assurance capability and Sonar Cube with the power of AI coding assistance like GitHub Copilot, Amazon Q developer, and Google Gemini Code Assist, boosts

developer productivity, and ensures that code means regular as quality and security standards. Join over 7 million developers from organizations like IBM, NASA, Barclays, and Microsoft who use Sonar. Trust your developers, verify your AI generated code. Visit Sonarsource.com slash pragmatic to try SonarCube for free today. That is sonar source.com slash pragmatic. So the design docs, they were engineering design docs, right? So this is like a summary of what did a typical design doc look like in this project, for example? What would it contain?

Yeah. So a brief description of what the problem was and exactly what the goals were. Maybe a link to the PRD. The product requirements? Yeah, product requirements, docs. And then kind of like a high-level architecture proposal, then more in-depth details of proposed interfaces, but not everything very fine-grained, does the thing.

There are components or little things that could be, as a tech lead, I wouldn't design the whole thing because I also wanted to delegate some bits and pieces of the design to my team because I had senior engineers on my team, right? I didn't want to be the tech lead that just does everything and everybody just has to execute, right? Especially when I was a tech lead manager, like I wanted those people to grow in their career, to have what to say in their promo packets and everything. So I couldn't, I didn't want to do everything.

So that was that. And then very important to have risks, like timelines, risks, and then also, a launch plan. I think that was because at Google, everything that went out had to be approved by SREs and production readiness, it was called. Oh, so SITR lobby engineers look through the things and they're like, okay, we think this is good or this needs some work? It's, I don't remember exactly who was on the product readiness teams because they were other teams. But they were looking at these things because I remember that part of the checklist was SRE readiness. And they wanted us to rename all our services.

And then we said, you know what? We can postpone this for some later time. We'll be on call for now. And it's fine. But yeah, they didn't like our acronyms. They're like, this is that intuitive. And we're like, sorry. I guess the downside of a large company.

every team has different goals or focuses. But what I did appreciate was a part of the readiness review, you had security audits, you had, you know, making sure everything is done properly, which, you know, at Uber, you can launch, you can do something and launch it tomorrow, put it in production. Like, it was a very different world. That's kind of how it work, right? Like, every team spun up like multiple microservices. I mean, over time it changed, but early on, yeah, that's.

And I'm not saying either one is good or bad. It's just a contrast. And obviously, product readiness takes time. But it's important. What I do think the takeaway was it's important to think about those things early on. And that's why even though maybe it wasn't ready for launch, there was a plan for it. Someone thought about, hey, let's make sure we don't have. During the design docs, right?

So like even before you would get really into coding, you already thought about like how we're going to launch this. Yeah. And I'm assuming experimentation was always an option, right? You must have had internal systems. Actually, for fiber, we did definitely, Google definitely had experimentation platforms and the systems. But I didn't use it. We didn't use it as much at fiber, like AB testing types. We did gradual rollouts or monitoring, and that was separate.

But yeah. So continuing from planning. Now, interestingly, because you mentioned, you asked me about like planning and task tracking and all that. I actually used a spreadsheet. I was the spreadsheet fan of... Really? Google Sheets? Yeah. Like, I would just cop out the work in Google Sheets.

And I actually took that with me at Uber because I didn't quite like planning and fabricator. And so once I had everything in a nice pretty spreadsheet, I would assign owners and just would file bugs and track that. The reason why I use spreadsheets is to make sure everything gets done, right? Other people want to have access to all this planning, like for example, product managers, because they want to see when is it going to be done. Spreadsheets is hard to track progress other than done not done, and it's hard to see a projection of are we on track or not. So it depends on what you use the spreadsheet for. Does it help answer your question as a product manager? I don't know. But does it help me as a tech lead to be on top of everything that's happening?

Yes. It's like Google. Google is famous for having pretty much a custom everything of anything you can think of from like, you know, whatever we call GitHub. They'll call it something else. And they have an internal tool for that. And so and for everything from tracking, bugs, monitoring, learning, et cetera. What are some interesting tools that you worked with at the time? I used code search a lot because it's like a repository of how to do anything. If you wanted to learn how to use RPC or certain libraries or whatever you want, you can probably find an example. It was just CFLashed and then you just search. It was so fast for me. when, even as a tech lead, if there were debate sometimes, I'm like, let's just look at the code.

Let's just look how this works. Like, let's just settle this with real information. So that's why accessing the code was so important. And also, you forget how things work. So it's nice to just get refreshers whenever you want, like, to just double-check things, make sure, you know, things work the way you remember them. critique was our sort of code review. And it's fun because when you get a code review, a diff approved.

So a diff approved is a CL LGTM. And LGTM stands for it. Looks good to me. So, and CL is a change log. LGTM means you essentially get a stamp of approval. So you can submit your code. And interestingly, what I keep telling people is when with code reviews, We had two reviews. One was a readability reviewer.

So Google prioritized readability. You had to get either readability certified or have people who had readability certifications in that specific language to approve your changes. And this is part of the culture, right? Google really cared about readability. Why? Because Google realized that when the code is not written very clearly, it takes time that is precious for everyone else to read and maintain that code. Wow.

And what did it mean to get certified for readability? Like, I'm assuming it means that, you know, you're an out expert and you can do the things, but what was it? Like, how did it go? So readability, each programming language had a big readability sort of guideline document. To get certified, you had to submit enough code changes that follow the guideline. on your own, essentially. You can get feedback here and there,

but if you keep making the same mistake, then the person who gives your readability won't give you a readability. Would say you're not ready. Keep working on your readability. I like it. It seems like it's not something you can kind of game. I mean, you can game it by giving good feedback, writing good code.

Yeah. But you need to demonstrate you. actually know. Yeah. I really appreciated readability. It just, it, it was such an essential part of the culture because things, they, they prioritize making things intuitive for everyone. I felt like it was a way of caring for everybody, you know.

Um, it was Googly. Yeah, it's, it's rare to hear. But I guess I'm not too surprised to hear from Google. It's pretty awesome. Because it's part of the culture, you don't, like, you only have to invest it. at the beginning and making sure everybody sort of writes code the same way, similar style, and it's not like all over the place. And it just becomes a habit.

People don't even think about it. That was one of the things that was lacking at Uber, and I felt it. Because sometimes I would be at Uber trying to read someone's code, and I had to take notes. And I was like, this at Google would be, if I had, like, if I have to take notes for something, it's not clear enough. And what are other tools that were kind of memorable or like, on your? unusual? Well, meme gen is one of them. I think memes are an essential part of the Google culture to this day. And I think it's, it was interesting sometimes to find out newslike stuff from meme gen. And then is a GIF generator or what is mean jane? Yeah. Yeah. So a meme generator, essentially. So you can pick the template and write whatever you want. And then you would see the latest memes that was. were created and you can upvote them.

So the ones that were really good would become the internal version of viral. Nice. So, and it's always good to have this sort of tool to go to, even in hard times, right? You would make fun of the situation and use humor to overcome both good and bad things. One system that I think if you research Google a little bit comes up as Borg. Did you use Borg? And what was it for? Yes.

So essentially we were tracking the jobs that were deployed and the resources we had. And I think now in if you use, like if people use Google Cloud, it's, you know, kind of given to see your Kubernetes clusters and resources. But at the time, it wasn't like there was no. I had not seen that anywhere else, like dynamically allocating jobs and resources and clusters and all that. And being able, me as an engineer, to actually go and fine-tune some of these things or customize, it felt like a lot of power. So as an engineer who might be joining Google or a similar size company or similar

stage that you were there. What advice would you give them to get up to speed quickly? Basically, advice you wish you would have gotten when you join Google. Yeah. So I would say number one is build relationships early. I think it's easy for people who are new to play the I'm new card. And it's easier to schedule one-on-ones with people. And that would help you understand your org and figure out who's who in the sense that who's the tech lead, who's the manager, who's the the decision maker, who's the owner of various things. Who do I go to and ask questions? And this is the second point is not be afraid to ask questions. But one thing, and this is kind of a generic advice, but one thing I want to mention here is to distribute your questions. I think

people tend to go ask questions to one person, which is the tech lead, which can be, who can be overwhelmed a little bit. But actually, if you go ask questions to go ask your questions to multiple people, it actually helps you connect with them even more. Because people want to help. That's the other thing. It makes people feel good to help you. And then what else? Credibility. I didn't realize, but credibility takes time to build and you do need a track record of results. And you can wait to get work, to get things done. But I think with credibility and visibility, the combo, it needs to be done as soon as you, it needs to be kickstarted, let's say, as soon as you join the company. So getting hands on as soon as possible and creating that track record and intentionally

building this credibility and this pool of knowledge. I think so any, any new engineer should start right away. And these are not things that I knew actually when I joined so. What are good ways that you would see a new engineer built credibility? I really appreciated when people are able to show that they can be good listeners, first and foremost, show understanding rather than just jumping in and throwing opinions. And so that combination of asking the great questions first, and then executing, being reliable with execution, that combination of two is what actually makes me trust people more, trust my reports more, and so on. And that comes hand in hand with

credibility. Because if I trust them, then I find whatever they have to say is believable, right? That's what credibility means. So talking about promotions, your first promotion was, unfortunately, rejected at Google. Can you tell me how promotions work at Google and why this rejection came and what did you do about it? Yeah. So, I call it my blessing in disguise because it taught me a lot. So what ended up happening is when I joined Google, I was on serving ads. And I didn't love it there because there was some organizational changes and wasn't quite finding my place. So after nine months, I transferred to Google Fiber.

At Google Fiber, because I worked on the embedded side of things and I wasn't exposed to the Google 3 Mono Repo and the Google world. My work was kind of niche. Because it was embedded, I actually worked on the kernel at some point. I did very low-level things directly on the Google Fiverr devices. And now where the promotion at Google and my rejection came in, so the way promotions were done then, and I know this changed a little bit, all levels, new grad, all of them, for promotions, they would go to promo committees.

These promo committees were committees of people from all around Google that were presented with your promo packet. That was your self-assessment, your manager assessment, your peer assessment. and they would look at all these documents and then meet up and decide whether the person gets promoted or not. So what ended up happening with my promotion is because it was sort of decoupled and kind of hard to understand. And like it wasn't, the feedback that I got back was that I did everything that was asked of me and executed and finished, but it wasn't.

showing enough impact. That word impact. Yes. And the problem is when you have really small startup like with hundreds of users in your own world working on niche things and you're evaluated against people who have millions of requests handling and it's a very different world. So impact didn't get translated accordingly. So they're like, try in six more months or come back.

You're doing great. Keep going, but not promoted. It was kind of shocking, to be honest, at first. And it went back to my initial insecurities about Google of like, am I really supposed to be here? Like, am I good enough? I don't know. But also, then I thought, but I did everything that I was asked to do. Right?

So it was kind of an unfortunate rejection, but what I, my takeaway here was like, okay, clearly if my manager tells me what to do and I do it is not enough. I need to sort of figure it out on my own and understand the promotion process better, understand what the promo committee is looking for, understand what does it really mean to get promoted? And what it actually meant is to show you're operating at the next level. So then I looked and I said, okay, what is the next level? What do I need to do?

Right? And just start to do those things. And ever since it actually became something that I drove. And in working with my manager to say, I think these are the things I'm supposed to work on. I think this is how I see showing these competencies or building these skills. At Google, promotions ran, run every six, was it every six months or every year? And then you, you were rejected at this point. And then how did you approach it?

So you said, you decided like, all right, I'm going to go for promotion again. And you turn things around and talk to with your manager saying, hey, you know, here's what I'm planning to do. Here's my approach. Here's my interpretation of the next level. Because Google had pretty detailed competencies, right? Like it was pretty clear, like what's expected at the L4 level, which was the next one for you. Yeah. So what ended up happening is I had a conversation with my manager and we thought that by doing a specific project, I will be able to show the impact. So I worked on that project,

but what ended up happening is, again, being a very niche thing that we were trying to see if we should integrate a driver in a thing. So the integration of that driver would have been my promotion package. After my evaluations, I didn't think adding that driver would actually help us. And like driver, you mean like a low-level driver? Yes. Colonel driver. What program language was this? C. C? Wow. You're coding away in C. Awesome. Well, so in college, my specialty was operating systems and compilers.

And I actually was a teaching assistant for operating systems. And my first job was actually networking like doing low-level networking protocols. So that's my background. And that's why I chose fiber because I thought it would be closer to my background. And so my move to distributed systems happened more towards when I started doing TV ads. So I stayed with the team, try to show the impact.

Sadly, I realized it's still not showing the impact that Google committee wanted. So I didn't try again after six months. But what I did instead is I changed teams. which seems like a risky decision in hindsight. Like I wouldn't recommend people just change teams whenever. Sometimes it's better to actually wait and stay on the same team and get that promotion and only after change. But for me, I, you know, this opportunity with TV ads came.

It was a new team. So I thought, perfect. I just need a lot of work. So a new team seems like a lot of work. Can you help explain like how that happened? Like, you know, like some companies are it's easy to change teams. sounds like Google is one of them some are harder like a new team was formed and like a manager was telling people hey if you're interested or how how did this this happen because it doesn't

sound that simple at most places yeah i think um context here definitely helped and also keep in mind google fiber was small so we kind of knew the director knew like i could ask what other opportunities out there i could i met with my skip level actually Nice. Yeah. And that's how I found out about this team that was actually in the same cubicle I was, was getting just getting started. So I didn't even change my desk. Interestingly, that's also how I found my first mentor, because my first mentor ended up being my tech lead from the embedded team. He ended up being my mentor for the TV ads team. And the way I started that mentorship relationship, which I didn't think, again, I didn't think I was in hindsight now, I was. would advise people to approach it like this. But I met with him and I said, hey, you know, you've worked with me for the last year and a half almost. What do you think I should do between these two teams? Like, how do you think about this? And just genuinely ask for his advice.

And then afterwards, he sort of offered and said, hey, you know, we can do this at a cadence if you want. And then he became my mentor and he was amazing. And in fact, it's because of him, I got promoted to senior after one year. So you had a bit of a disappointment for the first promotion to NG2 and then a lot faster promotion to senior. What happened there? Yeah. So it took me two and a half years to get to NG2 and it took me a year to get to senior.

I think it showed why the first promotion was rejected. It wasn't because I wasn't growing and or because I wasn't good enough or because I wasn't learning things. It was the context. But also my understanding of how to write the promo package, how to work on things that the committee cares about and things like that. When I switched teams to this new team, I was hungry. I was, I told myself, I don't, I don't like this feeling of hitting my head against the

wall all the time. I'm ready. I know what to do. I want to show me. Let me show you what I can do. It was kind of my spiel to my manager. And then he just did. And that's when I told him I want to be a tech lead.

I was an inch two. What did I know, right? I said, I told him I want to help you build this team. And just give me work. I was like, give me all the work. I'll do whatever it takes. And so it kind of sounded like a bit of a small startup because you said you were the second engineer on this team. And you became the tech lead.

And to me, it kind of. validates a little bit that being early on a team, may that be a startup or even a team inside a massive company, right? We're talking to a huge company and a very small team here. Sounds like that's kind of a pretty good advantage, especially if you have that, you know, relationship with your manager. You tell them like, I want to be your right hand. I want to help you. I'm going to put in the work. Sounds like that's what you did. Yeah. I think that's what ended up working for me. Well, I think it's pretty like nice to remember that just because it's a big company doesn't mean that, you know, working like like it was a startup.

It sounds like it kind of worked for you. Yeah. Yeah. And then and then so you got to like, it sounds like, you know, you got the work and you got promoted to senior. Later when you joined Uber, I mean, you observe promotions there. How similar or different were promotions at Uber than Google? Again, earlier stage company, but also a very large. company already. Yeah. So when I do an Uber promotions were done by managers. Then in

2018 with Uber 2.0 and I think what ended up happening. So I'm curious to hear your thoughts on this about how you would describe the Uber culture. But to me, it felt like it was very sort of Amazon influenced and very move fast. as maybe a little bit of Facebook, move fast, promotions were decided by managers. And then because of 2017 and what ended up happening then, there were leaders coming in from Google who then, then they brought a little bit of the Google culture in. So in 2018, we had the self-assessment literally exactly the same process as, um, as Google, right? But then people were like, we can't spend months writing these, doing this promo package. Like, it would take so long to write a promo,

Packet Plus, it didn't quite work the same because there's a big difference between Google and Uber, which is at Google. People stick around longer than they do at Uber. So with long peer assessments, you lose these people. You sometimes don't have the people to add and you lose the context. So it didn't quite work. And then in 2019, later on, they changed it again to more of a, you had like an internal resume and it was still now it was decided by people within your org but you had to participate in an interview so I've seen all these yeah yeah I was actually manager at adriber when these changes happened so for the first promotion in 20 we will join in 2016 and then we still had that was as you said it was managers I wasn't involved there but I was

actually involved the first time after in 2017 we had the Holden report which one of the recommendations was to have an unbiased promotion process and as you said it felt like it was an exact copy from someone at google or multiple people at google and it was a very heavyweight process i was a manager there was managers and also engineers in a room reviewing uh it was a committee reviewing and we you had to encourage yourself if you knew the person it was just very long and very exhausting and And every six months, we were just quite iterated on it. So they took the feedback and they made it more lightweight. And towards the end, they also changed it so that, like, initially a committee would

look at all the promotions, including like from Eng 1 to Eng 2, then Ench 2 to Senior. And later they changed that to so that managers could actually, the organization could decide on the up to senior promotions, which were arguably not as, I guess, challenging ones to decide and were like context of the math. manager was very helpful. Yeah. And yeah, also as you said with the with the peer reviews, interesting because I did see as a manager, it was a big problem that people left. Yeah. Someone like, let's say a very experienced engineer, like let's see a staff engineer who the senior engineer was working with. They're going for staff promotion. And they,

they were counting on getting that recommendation from the staff engineer. And the staff engineer was that I'm going to give it to you, but then they left. Yeah. And suddenly on the committee, you didn't have a peer review anymore because even if you could have reached out, it didn't really matter. So, yeah, that was, I guess it's a good observation. You know, it did change. I ended up having to, when one of the staff engineers on my, on Edith's left, I asked him before he left, hey, write me a peer review. I don't know when I'm applying for promotion, but I need your review.

Like, you have to come up with all these defensive mechanisms for the future, all these workarounds. But Google also changed, by the way, they don't do promo committee promotions either for, I think, L3 and L4. Sounds like they ended up where Uber ended up after a while. Yeah. But just to clarify for everyone, the reason why Google designed promotions like this initially was because they wanted an unbiased process. Because they already knew how important it is to have a, like, your relationship to your manager, how much of a determining. factor it is to your career growth. They wanted to decouple the, um, that from the process. Because, and there would be cases where your promoter, your manager maybe wouldn't support

your promotion, but the promo committee decides you do deserve the promotion. Yeah. So it's all to be, to be fair, as a manager, like what I've seen is when the manager didn't support, it was really hard to, to get it. I mean, theoretically, yes, the promo could could smell out some, you know, if there's biases or some of these things. But but also one thing that made it difficult is the committee didn't have context. Anyone who, at least initially, anyone who knew this engineer had to recourse themselves. So there were some awkward situations as well of, you know, like a mobile engineer being decided by non-deasry mobile engineer.

It was interesting challenges. But knowing what you know and you went through multiple promotions at Google, you observe them at Uber. How would you recommend the software engineers at larger companies or mid-sized companies think about promotions? Be intentional about it and have a goal in mind. You driving the process is very important. Now, I don't want people to only focus on promotions. If I focused on promotions, I would be so upset with myself and feel so bad about not getting promoted for my first promotion. Like, who knows if I would even end up to the level that I am today. I just focused on that failure. I think it's important to focus on growth. And no matter where you are,

whatever team you're on, be excited about what you work on. And if you're not excited, and I think excitement and growth will translate in a promotion later on if you have, and you can add the promotion conversations to your excitement and growth. So I think those things are very, very important. And surely, when you drive the process, you can then have the conversations with your manager. You can have your own career plan. I think that's one thing the managers don't really do that I did as a manager, which is career plans for my reports.

Not a lot of managers do this. Very few that I know actually do. career plans, but that doesn't stop individuals, software, engineers, ICs, to do that and run it by their manager. And what is it, what does career plan in your mind or a good career plan look for you? Yeah. So something like, if we based a career plan on a promotion strategy, we would look at, okay, I need to develop these competencies or these skills or these shows.

or these show this type of impact and sort of list or brainstorm, okay, maybe work on this type of project or maybe find more opportunities from, you know, these other activities. So, for example, Google had a citizenship criteria for promotion, right? So for citizenship, maybe in a plan could say, oh, run more interviews or participate at Grace Hoffer or some citizenship showing. So it's a way to sort of strategize what your options are to demonstrate the impact or to build those skills. Just currently looking at the industry, there doesn't seem to be as many promotions just because a lot of companies are not growing as fast.

AI companies are exceptions to this. But what would your recommendation be to figure out, you know, like how much promotions have slowed down at my company? also just how to potentially reevaluate promotions given that it's not going to be as a given as it might have been a few years ago. Yeah. So I think this is where managers are key in communicating and setting the right expectations, even with a career plan. That's why I call it a career plan, not a promotion plan necessarily. Right. I think in a way there's been an unreasonable expectation to get promoted every so often. But as a manager,

You can give your reports more perspective about the deciding factors in promotions, but also the fact that people's careers are long and there aren't enough levels to get promoted every year and a half. And so whether there are times where economy slows down and then there's times, inevitably, it never stays like that. So things catch up, things adjust and balance out over time. what people should focus on, I think, is growth. And by growth, I don't mean career growth.

I mean developing skills, competencies. And there's always something to work on. Or working on interesting things. You can always increase your knowledge, working on new things. There are ways to explore, to keep things interesting. And I do think in this day and age, people also don't, are less, inclined to say if I don't get promoted I'll just leave

because also moving to different companies is not as easy as it used to be because there's not as many openings so I think to let's help each other here between the manager and force and let's do the best work we can with the conditions, the economic economy conditions that are

there but also have realistic expectations of like hyper growth career your hypergrowth is not realistic. There could be phases of hypergrowth, but it's just not. It's not going to be the norm, is it, usually? No.

The past couple years, you've been coaching software engineers and engineering leaders. Can you help us imagine? What does that, what does coaching mean? Yeah, so how I, if for someone I tell them this, how I made this career transition for now, it might surprise them because it seems like I'm, it seems very different. But in fact, it's not. I think managers, tech lease leaders do, or the good ones,

already do some form of coaching. So what I ended up doing is taking that form of coaching and bringing it into just my own practice of working one-on-one with people. To me is the number one goal that I'm focusing on is helping develop people. And helping them get from A to B. B. And what usually this means is defining A, defining B, and figuring out what's in the way, and also figuring out how we can remove what gets in the way and have a plan to get from A to B.

Usually coaching involves more of to figure out what gets in the way. That's where things get tricky. Sometimes they're external factors. Sometimes there's, you know, lack of skills or lack things that you can add, but there's a lot of mindset work that goes in. So in coaching, I cover essentially, it's like holistically looking at how to achieve your goals. You also focus on influence, especially for software engineers. How would you even define influence in a way that we don't define it as politics, which I think engineers we like to run away from? Yeah. So influence has, interestingly, at big tech companies, the concept of influence without authority isn't necessarily foreign.

People kind of know what it means because it's just maybe explicitly even part of the culture or some companies even mention it in their values. But outside of that, leaving aside the corporate world, influence isn't necessarily inherently a bad thing or it's just the way we've been introduced to it sometimes is through politics, for example, and let's say bad actors. But what influence really is is the input you put into a system and the system is your organization to affect its outputs. And what I mean by that is, for example, feedback is a form of influence, right? You've inputted your opinion and feedback into something with the hope to change something, right? Disagreement is a form of influence because,

again, you're inputting your disagreement with the hope to change someone's minds or to change an output or an outcome, right? Sharing any type of point of view or opinion is a form of influence. Trying to convince others. Negotiation is a form of influence. Getting by-in, if you have an idea, is a form of influence, right? So in a way, it's getting anything. done in a tech company. And that's why I say it's a vital skill for anybody, especially after, you know, at senior levels where you want, if you want to have a say in the strategy, in the why and what we do, not just the how we do it, but even the how we do it. Like if you want to have a say in any of it, you have to exert some sort of influence. I want to clarify

right, that there's a little bit of a distinction between to influence and to have influence. Because when we say to influence, people think, and that's where people usually stay at when they think of influence, is they stay at, oh, it's the act of influence. I'm trying to persuade you. I'm trying to convince you. What are the words that I need to use to convince you of something? versus to have influence is more of a state where it's like a push and pull. So, for example, when you influence, you go and influence someone. Versus when you have influence, you're at a state where people come and ask for your input because you're quote-unquote influential. People want to, people reach out to you and they want your input.

Yeah, and like talking, let's take a specific example. Like I'm a software engineer. I have a really good, which I think is a really good idea that we should refactor, we should remove this tech depth, you know, maybe refactor the architecture. And I think it's, we should absolutely do it. It's a lot of work, but it's necessary because of a bunch of reasons. And, you know, I'm like, okay, I go and tell people and people ignore me and I can't really do it by myself or, well, I could, but it's too much work.

And so now I'm looking to, I want to influence people. Like, is this the type of thing? you're talking about you're like oh i wish i could just go on you tell them they need to see what i see and let's just do it like right and like when when like you you talk with someone like this like what do you tell them right like i think now is it's a good time to talk about those differences yeah wanting to influence versus being influential yes so that's the thing that people forget they um and mistakes of influence they influence with without building credibility and without, or even visibility or without having a track record or a reputation.

But also, also sometimes people try to influence despite being very passive for a very long time. So then it becomes difficult to answer the question, like, why should people listen to you? And I know this is kind of kind of... mean, let's say, to ask yourself, but like, that's, it's humbling, I would say. It's humbling. People need to have reasons to listen to you. So part of the reasons it, part of the reasons, um, who you are and how, what people know of you, that's part of it. Then the second part is how you present your ideas. And part of the, figuring out how the how that works best is you listening to what matters to the people you're trying to influence.

I feel like somehow from the word influence, that's kind of left out that it needs to be too. And the most influential people I know are the ones who, you know, come in with ideas, but they often listen. And often they're like, you know, oh, you're right. We should, we should do your idea. Yeah. And maybe not get hung up on and whose idea it is instead of just looking at what is, whatever

the goal is that we're all trying to do here. Absolutely. And that's why relationships. and human connection and social capital is the foundation of this. Because, as you said, being willing to, if you have, for example, a precedent of actually admitting you were wrong or giving credit to someone else, people are actually more likely to listen to you next time. So, and the way I actually am teaching this is based on pretty much reverse engineering what worked for me as a tech lead and what didn't work for me, what I learned the hard way. And there are some case studies that I discussed in the course where my attempts to influence failed miserably.

And we try to understand why. But then I had some attempts to influence that succeeded beyond my expectation. and trying to figure out what work there. And when we look at what work there is a combination of track record, credibility, visibility, social capital, just being a helpful person and giving a lot. You know, without, because that's the thing. When we say we want to influence, we're making an ask, right, from others. do this, listen to me, and so on.

And so all these relationships, if we want people to be more likely to listen to us, we have to give first. Be helpful, be a go-to person, right? So let's say I'm a software engineer and on my team or in my organization, I don't feel my voice heard by my team or by my manager. What are some tactical advice, like three pieces of tactical advice that you could give that you could help debug what's going. on and maybe, you know, like, help build this influence, like being influential instead of just

influencing. Yeah. So I think an influential engineer should have key relationships. So I would first troubleshoot the relationship with the manager and, you know, why doesn't the manager listen to me? troubleshoot why, if there's a lack of trust, sometimes these things can be addressed from the engineer side of asking, specifically asking questions of what can I do more to demonstrate trustworthiness or what can I do more to build a track record? So not, instead of saying, hey, why don't you listen to me? sort of take

what do I need to be listened to and say, okay, how can I work on building those things? And I think manager is the number one person to go to for this type of advice. Your tech lead can also be a person. Your product manager. Product managers are usually very savvy about these things. So they might actually have better advice.

And I think the way to frame this is by partnering. How can I be a better partner? to you. And so when building these relationships, like even with product managers, they want to work with people who are able to influence because they oftentimes want input from engineers, right? It helps them do their jobs better. So if we start with this idea that all these key stakeholders just want to do their jobs,

right? And if we can help them do their jobs, right? We are able to build a better relationship with them and their friends. Therefore, they'll be more willing to listen to us. So that sounds like you're saying, you know, like turn it around and figure out, hey, who are these stakeholders? And then just ask them, honestly, or like, instead of like going directly, but, but hey, how can, how could I do more of this? What, what would you need from me? Yes.

And then they'll probably answer. Yeah. They will. It's simple as that. Now, another thing that sometimes comes up is, you know, like you've gained some level of influence. People do come to you. They ask you. They trust you.

But an uncomfortable thing can happen, which is you want to say no to some things. But now you're worried if you're going to be less influential for saying no for helping out on this project or even reviewing a doc for doing your thing. What is your advice on dealing with that? Like, you know, like you don't want to lose that influence by, but you could, right? I don't know if saying no specifically loses the influence. I think what's worse is saying yes and not being able to do it or keep your commitments. I've found that to be more damaging to trust. And people often trust people who say no more than people who always say yes.

Interesting. No is necessary. and also if anybody's in any leadership position like tech leading, it is your job to say no to what is impossible or not feasible. Now, one thing people need to keep in mind is that when you say no, you have to think about saying no to the idea, not the person. You're not rejecting the person. You're rejecting an idea.

So when you make it about ideas, it is less personal. Even hearing a no. you know, you're telling me that this cannot be done. You're not telling me, no, I don't want what you want to me to do. So. Yeah. Sounds like you shouldn't be that afraid to say no in the right way. And, you know, don't worry too much about, worry about saying yes to too many things.

Yeah, well, it's tricky with no because it's cultural often. In some cultures, more than others, no is seen as extremely rude. But also, there are ways to say no more softly without actually. saying no counter offering, buying more time to think about options, negotiating. A no can become a yes but a yes, then coming, going back to no, not really. You can always say yes, but. Yeah, but it's much more difficult. Yeah. So looking back at your career, both the software engineer, tech lead, tech lead manager, now coaching, engineering managers and software engineers. What do you think it's the most difficult part of being a software engineer?

Like what kind of skill set? Is it the coding? Is it people? Is it something else? For my experience, it's always been people. I started programming in eighth grade. That was decades ago, multiple decades ago. coding is fun and interesting and new and it's still exciting but it's it was never the roadblock

for my success or for anyone's success because we work in teams we don't work independently so even if I did my coding part perfectly what got in the way of success sometimes or achieving the goal was someone else or someone's misunderstanding of something or people in general. The most difficult part of tech isn't necessarily the software part is the collaboration part. And to be a better collaborator, collaboration is essentially leadership. To be successful as an engineer and to get to those levels, senior staff, senior staff and so on, you need to start building your leadership skills.

Communication, collaboration. strategic thinking, big picture thinking, and so on, in influence. Because that's the thing about leadership, is people think about leadership as the leadership that has the authority hierarchical titles. But that's not it. This is not just it. So if you want to get anything done, you need leadership skills, you need collaboration skills, you need influence skills. With that, let's go to rapid questions.

Okay. So what's the life philosophy or approach that has been helpful to you? I saw this TED Talk by Robert Waldinger called What Makes a Good Life? And essentially, and it's a lessons from a study on happiness. And essentially the lesson here is that the quality of your life is the quality of your relationships. And that applies to work as well as personal life. What is a nonfiction book and a fiction book you would recommend that you enjoyed? So, nonfiction book that actually helps with influence is called Think Again by Adam Grant.

I love anything by Adam Grant, but Think Again, it was exceptional. And then a fiction book is The Midnight Library by Matt Hague. Essentially, it's a library of all your possible lives. and it makes you think puts things into perspective literally okay i'll make a note of that and we'll have all these in the show notes below as well what's your favorite programming language and framework i used to be a c++ fanatic but um ever since i'm off to uber i'm a go lang girlie so go lang so i i feel like go lang takes c plus plus back to c

in a way and removes a lot of the complications. So I would say GOLANG. In GOLANG, do you use frameworks, or are they that helpful? Like in some languages, they are. I'm not sure how I'm watching Go. I'm not as much of a Go expert. GRPC, GRPC Gateway. Yeah.

I've used this so much. So I would say that's my go-to. Nice. And finally, what's a fun activity that you do to unwind from tech. I lift weights. I do CrossFit now, but I'm also actually a certified personal trainer. So I've been... Wow. Do you do personal training as well? No, I don't. I don't train people. I train friends. I train myself, but I've been fascinated by this space. And I do think working out has great mental health benefits as well. So CrossFit. And if it's not CrossFit, reading or cooking are my go-toes.

Awesome. Well, it was great to have you here. Likewise. This is a great conversation. If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. And if you're interested in reading more about promotions, see relevant deep dives from the Pragmatic Engineer linked in the show notes below. Thanks and see you in the next one.