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

Transcript

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

0:00
SPEAKER_0: When you arrived at Uber, how did you feel internal tooling compared to Google?
0:03
SPEAKER_1: Definitely not at the same level.
0:05
SPEAKER_1: Google had everything internal, so I had to learn the equivalent of whatever Google had.
0:10
SPEAKER_1: And I remember my ex-Googler co-workers literally made a document translating the various tools like Code Search, Phabricator, Grafana, I didn't know any of these things.
0:21
SPEAKER_1: Google had a great culture of design docs.
0:23
SPEAKER_1: It was unheard of to not have a design doc for something.
0:27
SPEAKER_1: They wouldn't even talk to you if you didn't have the design doc.
0:29
SPEAKER_1: You couldn't just go and say, "Hey, I have this idea, let's do this."
0:32
SPEAKER_1: They're like, "Where's the design doc?"
0:34
SPEAKER_1: 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 sharing it with people and they're like, "Wow, this is cool."
0:44
SPEAKER_0: 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 Mnemonic.
0:52
SPEAKER_0: In this conversation, we cover what Google is like from the inside, from a software engineer's point of view.
0:56
SPEAKER_0: We touch on internal tools at Google, like Critique and Borg, and unique engineering processes like the concept of readability review.
1:03
SPEAKER_0: Irina shares practical advice on how to think about promotions at these large companies, and we'll close with tactical pointers on how to become more influential as a software engineer within your team and organization.
1:13
SPEAKER_0: If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube.
1:18
SPEAKER_0: One thing that I really appreciate about this episode is just how candid Irina is about how things work at Google and Uber.
1:24
SPEAKER_0: 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 her newsletter called The Caring Techie.
1:33
SPEAKER_0: So, with this, let's jump in.
1:35
SPEAKER_0: Irina, welcome to the podcast.
1:36
SPEAKER_1: Hi.
1:37
SPEAKER_1: Thanks for having me.
1:38
SPEAKER_0: Can we talk about on Google Fiber, when you worked there and you moved over to Google's tech stack, how was a project done in terms of this might've been a product development or building a feature.
1:51
SPEAKER_0: How did you all do planning, coding, tracking progress, code reviews, those kind of things?
1:59
SPEAKER_0: And what kind of tools did you use?
2:01
SPEAKER_1: I was as a tech lead given a big problem, TV ads on live streams, for example.
2:10
SPEAKER_1: I would then start the design process, talk to product managers, figure out if we had, "What is the set of requirements?"
2:20
SPEAKER_1: Do the design doc.
2:22
SPEAKER_1: Get the design.
2:22
SPEAKER_1: I was given the problem with the requirements including and was asked to design the solution, not to figure out the product.
2:34
SPEAKER_1: We did have a product manager who was actually very helpful and we had a great relationship.
2:44
SPEAKER_1: 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.
2:55
SPEAKER_1: So, I could say, "This is not really feasible.
2:57
SPEAKER_1: This is feasible."
2:59
SPEAKER_1: And I feel like in other companies, engineering is involved a little later than ideal, and that was that.
3:06
SPEAKER_1: And then design docs, we had a good process of design docs.
3:11
SPEAKER_1: We used Google Docs for that.
3:13
SPEAKER_1: Not a lot of internal tooling for that.
3:16
SPEAKER_1: Manual approvals, I think-
3:19
SPEAKER_0: But by the way, this was a time where design docs were not really common, right?
3:22
SPEAKER_0: I think now it's pretty common or people know about it, but back then this was-
3:27
SPEAKER_1: Google had a great 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.
3:41
SPEAKER_1: For the projects that I led, it was a lot of cross-organizational coordination with DoubleClick, for example, they wouldn't even talk to you if you didn't have the design doc.
3:52
SPEAKER_1: Like, "Where's the design doc?"
3:54
SPEAKER_1: And they're great people, by the way.
3:56
SPEAKER_1: I collaborated very well, but you couldn't just go and say, "Hey, I have this idea, let's do this."
4:02
SPEAKER_1: They're like, "Where's the design doc?"
4:04
SPEAKER_1: Seriously.
4:06
SPEAKER_1: 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 sharing it with people and they're like, "Wow, this is cool."
4:19
SPEAKER_0: Yeah.
4:19
SPEAKER_0: Well, it later changed, right?
4:21
SPEAKER_0: Like years later, as you said, it did change, but early on, no, it was more of a nice to have.
4:26
SPEAKER_1: It was more like, "Oh, you had the problem.
4:27
SPEAKER_1: Okay, let me go code."
4:30
SPEAKER_0: This episode was brought to you by WorkOS.
4:32
SPEAKER_0: If you're building a SaaS app, at some point your customers will start asking for enterprise features like sample authentication, skin provisioning, and fine-grained authorization.
4:40
SPEAKER_0: That's where WorkOS comes in, making it fast and painless to add enterprise features to your app.
4:45
SPEAKER_0: Their APIs are easy to understand and you can ship quickly and get back to building other features.
4:50
SPEAKER_0: WorkOS also provides a free user management solution called AuthKit for up to one million monthly active users.
4:56
SPEAKER_0: It's a drop-in replacement for Auth0 and comes standard with useful features like domain verification, role-based access control, bot protection, and MFA.
5:04
SPEAKER_0: It's powered by Radix components, which means zero compromises in design.
5:08
SPEAKER_0: You get limitless customizations as well as modular templates designed for quick integrations.
5:13
SPEAKER_0: Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Vercel, and Perplexity.
5:20
SPEAKER_0: Check it out at workos.com to learn more.
5:23
SPEAKER_0: That is workos.com.
5:26
SPEAKER_0: This episode was brought to you by Sonar, the creators of SonarQube Server, Cloud, ID, and Community Build.
5:32
SPEAKER_0: 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.
5:44
SPEAKER_0: Sonar analyzes all code regardless of who writes it, your internal team or gen AI, resulting in more secure, reliable, and maintainable software.
5:53
SPEAKER_0: Combining Sonar's AI code assurance capability and SonarQube with the power of AI coding assistants like GitHub Copilot, Amazon Q Developer, and Google Gemini Code Assist, boosts developer productivity and ensures that code meets rigorous quality and security standards.
6:08
SPEAKER_0: Join the over 7 million developers from organizations like IBM, NASA, Barclays, and Microsoft who use Sonar.
6:15
SPEAKER_0: Trust your developers, verify your AI-generated code.
6:18
SPEAKER_0: Visit sonarsource.com/pragmatic to try SonarQube for free today.
6:23
SPEAKER_0: That is sonarsource.com/pragmatic.
6:28
SPEAKER_0: So, the design docs, they were engineering design docs, right?
6:30
SPEAKER_1: Mm-hmm.
6:34
SPEAKER_0: What did a typical design doc look like?
6:35
SPEAKER_0: In this project, for example, what would it contain?
6:39
SPEAKER_1: Yeah.
6:39
SPEAKER_1: So, a brief description of what the problem was and exactly what the goals were.
6:46
SPEAKER_1: Maybe a link to the PRD.
6:48
SPEAKER_0: The product requirements doc?
6:51
SPEAKER_1: Yeah.
6:51
SPEAKER_1: Product requirements docs.
6:53
SPEAKER_1: And then, on kind of like a high level, architecture proposal.
7:00
SPEAKER_1: Then more in-depth details of proposed interfaces, but not everything very fine-grained.
7:07
SPEAKER_1: That's the thing.
7:08
SPEAKER_1: There were 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?
7:21
SPEAKER_1: I didn't want to be the tech lead that just does everything and everybody just has to execute.
7:28
SPEAKER_1: Right?
7:29
SPEAKER_1: Especially when I was a tech lead manager, I wanted those people to grow in their career, to have what to say in their promo packets and everything.
7:35
SPEAKER_1: So, I didn't want to do everything.
7:37
SPEAKER_1: So, that was that.
7:40
SPEAKER_1: And then, very important to have timelines, risks, and then also a launch plan.
7:52
SPEAKER_1: I think that was because at Google, everything that went out had to be approved by SREs and production readiness, it was called.
8:02
SPEAKER_0: Oh, so site reliability engineers look through the things and they're like, "Okay, we think this is good or this needs some work"?
8:10
SPEAKER_1: 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?
8:30
SPEAKER_1: We can postpone this for some later time.
8:33
SPEAKER_1: We'll be on call for now and it's fine."
8:37
SPEAKER_1: But yeah, they didn't like our acronyms.
8:39
SPEAKER_1: They're like, "This is unintuitive."
8:44
SPEAKER_1: And we're like, "Sorry."
8:48
SPEAKER_0: I guess the downside of a large company, every team has different goals or focuses.
8:52
SPEAKER_1: But what I did appreciate was a part of the readiness review, you had security audits, making sure everything is done properly.
9:04
SPEAKER_1: Which at Uber, you can do something and launch it tomorrow, put it in production.
9:10
SPEAKER_1: It was a very different world.
9:12
SPEAKER_0: That's kind of how it worked, right?
9:13
SPEAKER_0: Every team's spun up multiple microservices.
9:15
SPEAKER_0: I mean, over time it changed, but early on, yeah, that's-
9:18
SPEAKER_1: Yeah. And I'm not saying-
9:18
SPEAKER_0: Yeah.
9:18
SPEAKER_0: It's a huge contrast.
9:22
SPEAKER_1: ... either one is good or bad, it's just the contrast.
9:23
SPEAKER_1: And obviously, product readiness takes time.
9:27
SPEAKER_1: 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-"
9:39
SPEAKER_0: Well, and you have this plan during the design docs, right?
9:42
SPEAKER_1: Yeah.
9:43
SPEAKER_0: So, even before you would get really into coding, you already thought about, "How are we going to launch this?"
9:48
SPEAKER_1: Yeah.
9:49
SPEAKER_0: And I'm assuming experimentation was always an option, right?
9:53
SPEAKER_0: You must have had internal systems.
9:54
SPEAKER_1: Actually, for Fiber, definitely Google definitely had experimentation platforms and the systems, but we didn't use it as much at Fiber, like A/B testing types.
10:07
SPEAKER_1: We did gradual rollouts or monitoring and that was separate.
10:13
SPEAKER_1: But yeah.
10:15
SPEAKER_1: So, continuing from planning.
10:17
SPEAKER_1: Now, interestingly, because you mentioned, you asked me about planning and task tracking and all that.
10:26
SPEAKER_1: I actually used the spreadsheet.
10:28
SPEAKER_1: I was the spreadsheet fan of-
10:32
SPEAKER_0: Really?
10:33
SPEAKER_0: Google Sheets?
10:34
SPEAKER_1: Yeah.
10:35
SPEAKER_1: I would just scope out the work in Google Sheets.
10:37
SPEAKER_1: And I actually took that with me at Uber because I didn't quite like Planning and Phabricator.
10:42
SPEAKER_1: And so, once I had everything in a nice, pretty spreadsheet, I would assign owners and just file bugs and track that.
10:51
SPEAKER_1: The reason why I used spreadsheets is to make sure everything gets done, right?
10:55
SPEAKER_1: 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?
11:03
SPEAKER_1: And spreadsheets is hard to track progress other than done, not done.
11:10
SPEAKER_1: And it's hard to see a projection of, "Are we on track or not?"
11:13
SPEAKER_1: So, it depends on what you use the spreadsheet for.
11:16
SPEAKER_1: Does it help answer your question as a product manager?
11:20
SPEAKER_1: I don't know.
11:21
SPEAKER_1: But does it help me as a tech lead to be on top of everything that's happening?
11:25
SPEAKER_1: Yes.
11:27
SPEAKER_0: Inside Google, Google is famous for having pretty much a custom everything of anything you can think of from whatever we call GitHub, they'll call it something else.
11:36
SPEAKER_0: And they have an internal tool for that and for everything, tracking bugs, monitoring, alerting, et cetera.
11:42
SPEAKER_0: What are some interesting tools that you worked with at the time?
11:45
SPEAKER_1: I used Code Search a lot because it's like a repository of how to do anything.
11:56
SPEAKER_1: If you wanted to learn how to use RPC or certain libraries or whatever you want, you can probably find an example.
12:04
SPEAKER_1: It was just CS slash and then you just search.
12:07
SPEAKER_1: It was so fast for me.
12:10
SPEAKER_1: And even as a tech lead, if there were debates sometimes, I'm like, "Let's just look at the code.
12:16
SPEAKER_1: Let's just look how this works.
12:17
SPEAKER_1: Let's just settle this with real information."
12:20
SPEAKER_1: So, that's why accessing the code was so important.
12:25
SPEAKER_1: And also, you forget how things work, so it's nice to just get refreshers whenever you want, to just double check things, make sure things work the way you remember them.
12:37
SPEAKER_1: 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 looks good to me.
12:53
SPEAKER_1: And CL is a change log.
12:55
SPEAKER_1: LGTM means you essentially get a stamp of approval so you can submit your code.
13:01
SPEAKER_1: And interestingly, what I keep telling people is when with code reviews, we had two reviews.
13:08
SPEAKER_1: One was a readability reviewer, so Google prioritized readability.
13:13
SPEAKER_1: You had to get either readability certified or have people who had readability certifications in that specific language to approve your changes.
13:23
SPEAKER_1: And this is part of the culture, right?
13:25
SPEAKER_1: Google really cared about readability.
13:28
SPEAKER_1: Why?
13:28
SPEAKER_1: 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.
13:41
SPEAKER_0: Wow.
13:41
SPEAKER_0: And what did it mean to get certified for readability?
13:44
SPEAKER_0: I'm assuming it means that you're now an expert and you can do the things, but how did that go?
13:52
SPEAKER_1: So, readability, each programming language had a big readability guideline document.
14:01
SPEAKER_1: To get certified, you had to submit enough code changes that follow the guideline, on your own essentially.
14:09
SPEAKER_1: You can get feedback here and there, but if you keep making the same mistake, then the person who gives you readability won't give you readability, would say, "You're not ready.
14:21
SPEAKER_1: Keep working on your readability."
14:24
SPEAKER_0: I like it.
14:25
SPEAKER_0: It seems like it's not something you can kind of game.
14:28
SPEAKER_0: I mean, you can game it by giving good feedback, writing good code.
14:33
SPEAKER_1: Yeah.
14:34
SPEAKER_1: But you need to demonstrate you actually know.
14:38
SPEAKER_0: Yeah.
14:38
SPEAKER_1: I really appreciated readability.
14:42
SPEAKER_1: It was such an essential part of the culture because they prioritize making things intuitive for everyone.
14:49
SPEAKER_1: I felt like it was a way of caring for everybody.
14:51
SPEAKER_1: It was googly.
14:57
SPEAKER_0: Yeah.
14:58
SPEAKER_0: It's rare to hear, but I guess, I'm not too surprised to hear from Google.
15:02
SPEAKER_0: It's pretty awesome.
15:03
SPEAKER_1: Because it's part of the culture.
15:04
SPEAKER_1: You only have to invest at the beginning in making sure everybody writes code the same way, similar style, and it's not all over the place.
15:13
SPEAKER_1: And it just becomes a habit.
15:14
SPEAKER_1: People don't even think about it.
15:15
SPEAKER_1: 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 have to take notes for something, it's not clear enough."
15:33
SPEAKER_0: And what are other tools that were memorable or unusual?
15:39
SPEAKER_1: Well, Memegen was one of them.
15:40
SPEAKER_1: I think memes are an essential part of the Google culture to this day.
15:48
SPEAKER_1: And I think it was interesting sometimes to find out news-like stuff from Memegen, and then read it in TechCrunch.
15:54
SPEAKER_0: So, is it a GIF generator?
15:56
SPEAKER_0: What is Memegen?
16:00
SPEAKER_1: Yeah.
16:00
SPEAKER_1: Yeah.
16:00
SPEAKER_1: So, a meme generator essentially.
16:01
SPEAKER_1: So, you can pick the template and write whatever you want, and then you would see the latest memes that were created and you can upvote them.
16:09
SPEAKER_1: So, the ones that were really good would become the internal version of viral.
16:16
SPEAKER_0: Nice.
16:18
SPEAKER_1: And it's always good to have this sort of tool to go to, even in hard times, right?
16:24
SPEAKER_1: You would make fun of the situation and use humor to overcome both good and bad things.
16:33
SPEAKER_0: One system that I think if you research Google a little bit comes up as Borg.
16:37
SPEAKER_1: Yes.
16:37
SPEAKER_0: Did you use Borg and what was it for?
16:40
SPEAKER_1: Yes.
16:41
SPEAKER_1: Yes.
16:41
SPEAKER_1: So, essentially we were tracking the jobs that were deployed and the resources we had.
16:47
SPEAKER_1: I think now if people use Google Cloud, it's given to see your Kubernetes clusters and resources, but at the time, it wasn't ... I had not seen that anywhere else, like dynamically allocating jobs and resources on 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.
17:23
SPEAKER_0: 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?
17:33
SPEAKER_0: Basically, advice you wish you would've gotten when you joined Google.
17:37
SPEAKER_1: Yeah.
17:38
SPEAKER_1: So, I would say number one is build relationships early.
17:41
SPEAKER_1: I think it's easy for people who are new to play the, "I'm new," card.
17:46
SPEAKER_1: And it's easier to schedule one-on-ones with people.
17:50
SPEAKER_1: 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 decision maker, who's the owner of various things?
18:01
SPEAKER_1: "Who do I go to and ask questions?"
18:04
SPEAKER_1: And this is the second point is not be afraid to ask questions.
18:09
SPEAKER_1: But one thing, and this is kind of a generic advice, but one thing I want to mention here is to distribute your questions.
18:15
SPEAKER_1: I think people tend to go ask questions to one person, which is the tech lead, who can be overwhelmed a little bit, but actually, if you go ask your questions to multiple people, it actually helps you connect with them even more, because people want to help.
18:33
SPEAKER_1: That's the other thing, it makes people feel good to help you.
18:36
SPEAKER_1: And then what else?
18:38
SPEAKER_1: Credibility.
18:39
SPEAKER_1: 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 kickstarted, let's say, as soon as you join the company.
19:01
SPEAKER_1: 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 any new engineer should start right away.
19:17
SPEAKER_1: And these are not things that I knew actually when I joined.
19:22
SPEAKER_0: What are good ways that you would see a new engineer build credibility?
19:26
SPEAKER_1: 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.
19:38
SPEAKER_1: And so, that combination of asking the great questions first.
19:45
SPEAKER_1: And then, executing, being reliable with execution.
19:50
SPEAKER_1: That combination of two is what actually makes me trust people more, trust my reports more, and so on.
19:56
SPEAKER_1: And that comes hand-in-hand with credibility, because if I trust them, then I find whatever they have to say is believable, right?
20:05
SPEAKER_1: That's what credibility means.
20:07
SPEAKER_0: So, talking about promotions, your first promotion was unfortunately rejected at Google.
20:13
SPEAKER_0: Can you tell me how promotions work at Google and why this rejection came and what did you do about it?
20:21
SPEAKER_1: Yeah.
20:22
SPEAKER_1: I call it my blessing in disguise because it taught me a lot.
20:27
SPEAKER_1: So, what ended up happening is when I joined Google, I was on serving ads.
20:32
SPEAKER_1: And I didn't love it there because there was some organizational changes and wasn't quite finding my place.
20:42
SPEAKER_1: So, after nine months I transferred to Google Fiber.
20:45
SPEAKER_1: At Google Fiber, because I worked on the embedded side of things and I wasn't exposed to the Google3 monorepo and the Google world, my work was kind of niche.
21:00
SPEAKER_1: Because it was embedded, I actually worked on the kernel at some point.
21:03
SPEAKER_1: I did very low-level things-
21:05
SPEAKER_0: Oh, cool.
21:06
SPEAKER_1: ... directly on the Google Fiber devices.
21:09
SPEAKER_1: And now where the promotion at Google and my rejection came in.
21:14
SPEAKER_1: 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.
21:27
SPEAKER_1: These promo committees were committees of people from all around Google that were presented with your promo packet.
21:36
SPEAKER_1: 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.
21:50
SPEAKER_1: So, what ended up happening with my promotion is because it was sort of decoupled and kind of hard to understand and 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.
22:12
SPEAKER_0: Mm-hmm.
22:13
SPEAKER_0: That word, impact.
22:16
SPEAKER_1: Yes.
22:16
SPEAKER_1: And the problem is when you have really small startup 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.
22:38
SPEAKER_1: So, impact didn't get translated accordingly.
22:42
SPEAKER_1: So, they're like, "Try in six more months, or come back.
22:45
SPEAKER_1: You're doing great.
22:46
SPEAKER_1: Keep going, but not promoted."
22:49
SPEAKER_1: It was kind of a shocking, to be honest, at first.
22:51
SPEAKER_1: And it went back to my initial insecurities about Google of like, "Am I really supposed to be here?
23:00
SPEAKER_1: Am I good enough?
23:01
SPEAKER_1: I don't know."
23:02
SPEAKER_1: But also then I thought, "But I did everything that I was asked to do."
23:06
SPEAKER_1: Right?
23:07
SPEAKER_1: So, it was kind of an unfortunate rejection.
23:09
SPEAKER_1: But what my takeaway here was like, "Okay.
23:13
SPEAKER_1: Clearly if my manager tells me what to do and I do it, it's not enough.
23:18
SPEAKER_1: I need to 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?"
23:31
SPEAKER_1: And what it actually meant is to show you're operating at the next level.
23:35
SPEAKER_1: So, then I looked and I said, "Okay, what is the next level?
23:40
SPEAKER_1: What do I need to do?"
23:41
SPEAKER_1: Right?
23:42
SPEAKER_1: And just start to do those things.
23:44
SPEAKER_1: And ever since, it actually became something that I drove in working with my manager to say, "I think these are the things I'm supposed to work on.
23:57
SPEAKER_1: This is how I see showing these competencies or building these skills."
24:04
SPEAKER_0: At Google, promotions run every six ... Was it every six months or every year?
24:11
SPEAKER_1: Yes, I think it was every six months. Yeah.
24:11
SPEAKER_0: So, you were rejected at this point, and then how did you approach it?
24:15
SPEAKER_0: So, you said, you decided like, "All right, I'm going to go for promotion again."
24:18
SPEAKER_0: And you turned things around and talked with your manager saying, "Hey, here's what I'm planning to do.
24:25
SPEAKER_0: Here's my approach.
24:26
SPEAKER_0: Here's my interpretation of the next level."
24:27
SPEAKER_0: Because Google had pretty detailed competencies, right?
24:30
SPEAKER_0: It was pretty clear what's expected at the L4 level, which was the next one for you.
24:34
SPEAKER_1: Yeah.
24:36
SPEAKER_1: So, what ended up happening is I had a conversation with my manager and we thought that by doing a specific project, I'll be able to show the impact.
24:47
SPEAKER_1: 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.
24:58
SPEAKER_1: So, in the integration of that driver would've been my promotion package.
25:03
SPEAKER_1: After my evaluations, I didn't think adding that driver would actually help us.
25:08
SPEAKER_0: And driver, you mean like a low-level driver?
25:11
SPEAKER_1: Yes.
25:11
SPEAKER_0: Kernel driver.
25:13
SPEAKER_1: Kernel driver.
25:14
SPEAKER_0: What programming language was this?
25:15
SPEAKER_1: C.
25:15
SPEAKER_0: C. Wow.
25:15
SPEAKER_1: C.
25:15
SPEAKER_0: You're coding away in C. Awesome.
25:20
SPEAKER_1: C. Well, so in college my specialty was operating systems and compilers, and I actually was a teaching assistant for operating systems.
25:30
SPEAKER_1: And my first job was actually networking, doing low-level networking protocols.
25:35
SPEAKER_0: Awesome.
25:35
SPEAKER_1: So, that's my background and that's why I chose Fiber, because I thought it would be closer to my background.
25:43
SPEAKER_1: And so, my move to distributed systems happened more towards when I started doing TV ads.
25:49
SPEAKER_1: So, I stayed with the team, try to show the impact.
25:52
SPEAKER_1: Sadly, I realized it's still not showing the impact that Google committee wanted.
25:58
SPEAKER_1: So, I didn't try again after six months.
26:00
SPEAKER_1: But what I did instead is I changed teams, which seems like a risky decision in hindsight.
26:07
SPEAKER_1: I wouldn't recommend people just change teams whenever.
26:11
SPEAKER_1: Sometimes it's better to actually wait and stay on the same team and get that promotion and only after change.
26:16
SPEAKER_1: But for me, this opportunity with TV ads came, it was a new team, so I thought, "Perfect.
26:22
SPEAKER_1: I just need a lot of work.
26:24
SPEAKER_1: So, a new team seems like a lot of work."
26:27
SPEAKER_0: Can you help explain how that happened?
26:30
SPEAKER_0: Some companies, it's easy to change teams.
26:32
SPEAKER_0: Sounds like Google is one of them.
26:33
SPEAKER_0: Some are harder.
26:35
SPEAKER_0: A new team was formed and a manager was telling people, "Hey, if you're interested"?
26:40
SPEAKER_0: Or, how did this happen?
26:42
SPEAKER_0: Because it doesn't sound that simple at most places.
26:44
SPEAKER_1: Yeah.
26:45
SPEAKER_1: I think context here definitely helped.
26:49
SPEAKER_1: And also, keep in mind, Google Fiber was small, so we kind of knew, the director knew, I could ask, "What other opportunities are there?"
26:59
SPEAKER_1: I met with my skip level actually.
27:02
SPEAKER_0: Oh, nice.
27:03
SPEAKER_1: Yeah.
27:04
SPEAKER_1: And that's how I found out about this team that was actually in the same cubicle I was, was just getting started.
27:10
SPEAKER_0: Oh, awesome.
27:10
SPEAKER_1: So, I didn't even change my desk.
27:13
SPEAKER_1: Interestingly, that's also how I found my first mentor because my first mentor ended up being my tech lead from the embedded team.
27:22
SPEAKER_1: He ended up being my mentor for the TV ads team.
27:26
SPEAKER_1: And the way I started that mentorship relationship, which again, I didn't think in hindsight now, I would advise people to approach it like this, but I met with him and I said, "Hey, you've worked with me for the last year, year and a half almost.
27:44
SPEAKER_1: What do you think I should do between these two teams?
27:46
SPEAKER_1: How do you think about this?"
27:48
SPEAKER_1: And just genuinely asked for his advice.
27:50
SPEAKER_1: And then, afterwards he sort of offered and said, "Hey, we can do this at a cadence if you want."
27:56
SPEAKER_1: And then he became my mentor and he was amazing.
27:58
SPEAKER_1: And in fact, it's because of him I got promoted to senior after one year, which was-
28:04
SPEAKER_0: Oh, wow.
28:04
SPEAKER_0: Yeah.
28:05
SPEAKER_0: So, you had a bit of a disappointment for the first promotion to eng 2 and then a lot faster promotion to senior.
28:12
SPEAKER_1: Yes.
28:12
SPEAKER_0: What happened there?
28:14
SPEAKER_1: Yeah.
28:14
SPEAKER_1: So, it took me two-and-a-half years to get to eng 2, and it took me a year to get to senior.
28:19
SPEAKER_1: I think it showed why the first promotion was rejected, wasn't because I wasn't growing 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.
28:39
SPEAKER_1: When I switched teams to this new team, I was hungry.
28:42
SPEAKER_1: I told myself, "I don't like this feeling of hitting my head against the wall all the time.
28:53
SPEAKER_1: I'm ready.
28:53
SPEAKER_1: I know what to do.
28:55
SPEAKER_1: Show me.
28:55
SPEAKER_1: Let me show you what I can do," was kind of my spiel to my manager.
29:00
SPEAKER_1: And then, he just did.
29:02
SPEAKER_1: And that's when I told him I want to be a tech lead.
29:05
SPEAKER_1: I was an eng 2.
29:06
SPEAKER_1: What did I know?
29:06
SPEAKER_1: Right?
29:07
SPEAKER_0: Yeah.
29:09
SPEAKER_1: I said, I told him, "I want to help you build this team and just give me work."
29:15
SPEAKER_1: I was like, "Give me all the work.
29:16
SPEAKER_1: I'll do whatever it takes."
29:17
SPEAKER_1: And so-
29:18
SPEAKER_0: 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.
29:24
SPEAKER_0: 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?
29:33
SPEAKER_0: We're talking to a huge company and a very small team here.
29:35
SPEAKER_0: It sounds like that's kind of a pretty good advantage, especially if you have that a relationship with your manager, you tell them, "All right.
29:42
SPEAKER_0: I want to be your right hand.
29:43
SPEAKER_0: I want to help you.
29:44
SPEAKER_0: I'm going to put in the work."
29:44
SPEAKER_0: Sounds like that's what you did.
29:46
SPEAKER_1: Yes.
29:47
SPEAKER_1: Yeah, I think that's what ended up working for me.
29:51
SPEAKER_0: Well, I think it's pretty nice to remember that just because it's a big company it doesn't mean that working like it was a startup, it sounds like it kind worked for you.
30:02
SPEAKER_1: Yeah.
30:02
SPEAKER_1: Yeah.
30:05
SPEAKER_0: It sounds like you got the work and you got promoted to senior.
30:11
SPEAKER_0: Later, when you joined Uber, I mean, you observed promotions there.
30:15
SPEAKER_0: How similar or different were promotions at Uber than Google?
30:18
SPEAKER_0: Again, earlier stage company, but also a very large company already.
30:22
SPEAKER_1: Yeah.
30:23
SPEAKER_1: So, when I joined Uber, promotions were done by managers.
30:27
SPEAKER_1: Then in 2018 with Uber 2.0, and I think what ended up happening ... And 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.
30:50
SPEAKER_1: Amazon, maybe a little bit of Facebook.
30:52
SPEAKER_1: Move fast.
30:53
SPEAKER_1: Promotions were decided by managers.
30:55
SPEAKER_1: And then because of 2017 and what ended up happening then, there were leaders coming in from Google who then they brought a little bit of the Google culture in.
31:05
SPEAKER_1: So, in 2018, we had the self-assessment, literally exactly the same process as Google, right?
31:13
SPEAKER_1: But then people were like, "We can't spend months doing this promo packet."
31:18
SPEAKER_1: It would take so long to write a promo packet.
31:21
SPEAKER_1: 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.
31:31
SPEAKER_1: So, with long peer assessments, you lose these people.
31:35
SPEAKER_1: You sometimes don't have the people to add and you lose the context.
31:39
SPEAKER_1: So, it didn't quite work.
31:41
SPEAKER_1: And then in 2019, later on, they changed it again to more of a you had an internal resume and now it was decided by people within your org, but you had to participate in an interview.
31:57
SPEAKER_1: So, I've seen all these-
32:00
SPEAKER_0: Yeah. Where the committee probably-
32:00
SPEAKER_1: Yeah.
32:05
SPEAKER_0: Yeah.
32:05
SPEAKER_0: I was actually manager at Uber when these changes happened.
32:06
SPEAKER_0: So, for the first promotion in ... We all joined in 2016, and then we still had ... As you said, it was managers.
32:15
SPEAKER_0: I wasn't involved there, but I was actually involved the first time ... In 2017 we had the Holden report, which one of the recommendations was to have an unbiased promotion process.
32:25
SPEAKER_0: And as you said, it felt like it was a exact copy from someone at Google or multiple people at Google.
32:31
SPEAKER_0: And it was a very heavyweight process.
32:33
SPEAKER_0: I was a manager.
32:34
SPEAKER_0: There was managers and also engineers in a room reviewing ... It was a committee reviewing and you had to recuse yourself if you knew the person.
32:43
SPEAKER_0: It was just very long and very exhausting.
32:45
SPEAKER_0: And then, every six months Uber just quite iterated on it.
32:48
SPEAKER_0: So, they took the feedback and they made it more lightweight.
32:51
SPEAKER_0: And towards the end, they also changed it so that ... Initially a committee would look at all the promotions including from eng 1 to eng 2, and then eng 2 to senior.
33:01
SPEAKER_0: And later they changed that, 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 where context of the manager was very helpful.
33:17
SPEAKER_0: And yeah, also as you said with the peer reviews, interesting because I did see as a manager, it was a big problem that people left.
33:28
SPEAKER_0: Someone, like let's say a very experienced engineer, like let's say a staff engineer who the senior engineer was working with, they're going for a staff promotion and they were counting on getting that recommendation from the staff engineer.
33:39
SPEAKER_0: And the staff engineer said, "I'm going to give it to you."
33:41
SPEAKER_0: But then they left.
33:43
SPEAKER_0: 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.
33:51
SPEAKER_0: So yeah, I guess it's a good observation.
33:54
SPEAKER_0: Yeah.
33:55
SPEAKER_0: It did change.
33:56
SPEAKER_1: I ended up having to, when one of the staff engineers at Eats left, I asked him before he left, "Hey, write me a peer review.
34:05
SPEAKER_1: I don't know when I'm applying for promotion, but I need your review."
34:09
SPEAKER_1: You have to come up with all these defensive mechanisms for the future, all these workarounds.
34:15
SPEAKER_1: But Google also changed, by the way, they don't do promo committee promotions either for, I think, L3 and L4.
34:25
SPEAKER_0: Sounds like they ended up where Uber ended up after a while.
34:27
SPEAKER_1: Yeah.
34:27
SPEAKER_0: Nice.
34:28
SPEAKER_1: 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 ... Like your relationship to your manager, how much of a determining factor it is to your career growth.
34:46
SPEAKER_1: They wanted to decouple that from the process.
34:52
SPEAKER_1: And there would be cases where your manager maybe wouldn't support your promotion, but the promo committee decides you do deserve the promotion.
35:03
SPEAKER_1: So, it's also those types of cases.
35:06
SPEAKER_0: To be fair, as a manager, what I've seen is when the manager didn't support, it was really hard to get it.
35:11
SPEAKER_0: I mean, theoretically, yes, the promo could smell out if there's biases or some of these things.
35:18
SPEAKER_0: But also, one thing that made it difficult is the committee didn't have context.
35:23
SPEAKER_0: At least initially, anyone who knew this engineer had to recuse themselves.
35:27
SPEAKER_0: So, there were some awkward situations as well of a mobile engineer being decided by not necessarily mobile engineer.
35:35
SPEAKER_0: It was interesting challenges.
35:37
SPEAKER_0: But knowing what you know, and you went through multiple promotions at Google, you observed them at Uber, how would you recommend the software engineers at larger companies or even mid-sized companies think about promotions?
35:51
SPEAKER_1: Be intentional about it, and have a goal in mind.
35:55
SPEAKER_1: You driving the process is very important.
35:57
SPEAKER_1: Now, I don't want people to only focus on promotions.
36:02
SPEAKER_1: If I focused on promotions, I would be so upset with myself and feel so bad about not getting promoted for my first promotion.
36:09
SPEAKER_1: Who knows if I would even end up to the level that I am today if I just focused on that failure.
36:17
SPEAKER_1: 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.
36:26
SPEAKER_1: 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.
36:42
SPEAKER_1: So, I think those things are very, very important.
36:44
SPEAKER_1: And surely, when you drive the process, you can then have the conversations with your manager.
36:49
SPEAKER_1: You can have your own career plan.
36:51
SPEAKER_1: 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.
37:00
SPEAKER_1: Not a lot of managers do this.
37:02
SPEAKER_1: 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.
37:14
SPEAKER_0: And what does career plan, in your mind, or a good career plan look for you?
37:19
SPEAKER_1: Yeah.
37:19
SPEAKER_1: So, something like if we based a career plan on a promotion strategy, we would look at, "Okay.
37:29
SPEAKER_1: I need to develop these competencies or these skills or show this type of impact."
37:35
SPEAKER_1: And sort of list or brainstorm, "Okay.
37:39
SPEAKER_1: Maybe work on this type of project or maybe find more opportunities from these other activities."
37:46
SPEAKER_1: So, for example, Google had a citizenship criteria for a promotion.
37:50
SPEAKER_1: Right?
37:51
SPEAKER_1: So, for citizenship, maybe a plan could say, "Oh, run more interviews or participate at Grace Hopper or some citizenship showing."
38:04
SPEAKER_1: So, it's a way to sort of strategize what your options are to demonstrate the impact or to build those skills.
38:11
SPEAKER_0: 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.
38:20
SPEAKER_0: AI companies are exceptions to this.
38:23
SPEAKER_0: But what would your recommendation be to figure out how much promotions have slowed down at my company and also just how to potentially reevaluate promotions given that it's not going to be as a given as it might've been a few years ago?
38:37
SPEAKER_1: Yeah.
38:38
SPEAKER_1: So, I think this is where managers are key in communicating and setting the right expectations.
38:44
SPEAKER_1: Even with a career plan, that's why I call it a career plan, not a promotion plan necessarily, right?
38:52
SPEAKER_1: 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.
39:14
SPEAKER_1: And so, whether there are times where economy slows down and then there's times ... Inevitably it never stays like that.
39:22
SPEAKER_1: So, things catch up, things adjust and balance out over time.
39:28
SPEAKER_1: What people should focus on, I think, is growth.
39:32
SPEAKER_1: And by growth I don't mean career growth.
39:35
SPEAKER_1: I mean, developing skills, competencies, and there's always something to work on.
39:42
SPEAKER_1: Or, working on interesting things, you can always increase your knowledge, working on new things.
39:47
SPEAKER_1: There are ways to explore, to keep things interesting.
39:51
SPEAKER_1: And I do think in this day and age, people also are less inclined to say, "If I don't get promoted, I'll just leave."
40:01
SPEAKER_1: Because also moving to different companies is not as easy as it used to be, because there are not as many openings.
40:08
SPEAKER_1: So, I think, let's help each other here between the manager and of course let's do the best work we can with the economy conditions that are there, but also have realistic expectations of ... Hyper-growth, career hyper-growth is not realistic.
40:28
SPEAKER_1: There could be phases of hyper-growth, but it's just not ever-
40:33
SPEAKER_0: It's not going to be the norm, is it, usually?
40:33
SPEAKER_1: No.
40:33
SPEAKER_1: No.
40:36
SPEAKER_0: The past couple of years you've been coaching software engineers and engineering leaders.
40:40
SPEAKER_0: Can you help us imagine what does coaching mean?
40:44
SPEAKER_1: Yeah.
40:44
SPEAKER_1: So, for someone, I tell them how I made this career transition for now, it might surprise them because it seems very different, but in fact it's not.
41:00
SPEAKER_1: I think managers, tech leaders, or the good ones, already do some form of coaching.
41:07
SPEAKER_1: 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.
41:16
SPEAKER_1: To me is the number one goal that I'm focusing on is helping develop people and helping them get from A to 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.
41:50
SPEAKER_1: Sometimes they're external factors, sometimes there's lack of skills or lack of things that you can add, but there's a lot of mindset work that goes in.
41:59
SPEAKER_1: So, in coaching, I cover essentially, it's like holistically looking at how to achieve your goals.
42:08
SPEAKER_0: You also focus on influence.
42:09
SPEAKER_1: Yes.
42:09
SPEAKER_0: Especially for software engineers.
42:12
SPEAKER_0: How would you even define influence in a way that we don't define it as politics?
42:18
SPEAKER_0: Which I think as engineers we like to run away from.
42:21
SPEAKER_1: Yeah.
42:22
SPEAKER_1: So, interestingly, at big tech companies, the concept of influence without authority isn't necessarily foreign.
42:29
SPEAKER_1: 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.
42:39
SPEAKER_1: 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.
42:56
SPEAKER_1: But what influence really is, is the input you put into a system, and the system is your organization, to affect its outputs.
43:06
SPEAKER_1: And what I mean by that is, for example, feedback is a form of influence.
43:10
SPEAKER_1: Right?
43:11
SPEAKER_1: You've inputted your opinion and feedback into something with the hope to change something, right?
43:17
SPEAKER_1: 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.
43:29
SPEAKER_1: Right?
43:30
SPEAKER_1: Sharing any type of point of view or opinion is a form of influence.
43:34
SPEAKER_1: Trying to convince others.
43:35
SPEAKER_1: Negotiation is a form of influence.
43:40
SPEAKER_1: Getting buy-in if you have an idea is a form of influence.
43:43
SPEAKER_1: Right?
43:44
SPEAKER_1: So, in a way it's getting anything done in a tech company.
43:52
SPEAKER_1: And that's why I say it's a vital skill for anybody, especially at senior levels, where 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.
44:16
SPEAKER_1: I want to clarify that there's a little bit of a distinction between to influence and to have influence.
44:23
SPEAKER_0: Mm-hmm.
44:24
SPEAKER_1: 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.
44:33
SPEAKER_1: I'm trying to persuade you.
44:34
SPEAKER_1: I'm trying to convince you.
44:35
SPEAKER_1: Oh, what are the words that I need to use to convince you of something?"
44:41
SPEAKER_1: Versus to have influence is more of a state where it's like a push and pull.
44:46
SPEAKER_1: 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 "influential."
44:57
SPEAKER_1: Right?
45:01
SPEAKER_1: People reach out to you and they want your input.
45:06
SPEAKER_0: Let's take a specific example, like, I'm a software engineer.
45:10
SPEAKER_0: I have what I think is a really good idea that we should remove this tech debt, maybe refactor the architecture, and I think we should absolutely do it.
45:21
SPEAKER_0: It's a lot of work, but it's necessary because of a bunch of reasons.
45:25
SPEAKER_0: And 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.
45:33
SPEAKER_0: And so, now I'm looking to, I want to influence people.
45:37
SPEAKER_0: Is this the type of thinking you're talking about, you're like, "Oh, I wish I could just go and tell them they need to see what I see and let's just do it"?
45:43
SPEAKER_0: Right?
45:44
SPEAKER_0: And when you talk with someone like this, what do you tell them?
45:50
SPEAKER_0: Right?
45:50
SPEAKER_0: I think now it is a good time to talk about those differences, wanting to influence versus being influential.
45:55
SPEAKER_1: Yes.
45:56
SPEAKER_1: So, that's the thing that people forget, mistakes of influence, they influence without building credibility or even visibility, or without having a track record or a reputation.
46:15
SPEAKER_1: But also, sometimes people try to influence despite being very passive for a very long time.
46:22
SPEAKER_1: So, then it becomes difficult to answer the question, "Why should people listen to you?"
46:29
SPEAKER_1: And I know this is kind of mean, let's say, to ask yourself, but it's humbling, I would say, it's humbling.
46:39
SPEAKER_1: People need to have reasons to listen to you.
46:43
SPEAKER_1: So, part of the reason's who you are and what people know of you, that's part of it.
46:51
SPEAKER_1: Then the second part is how you present your ideas.
46:56
SPEAKER_1: And part of figuring out the how that works best is you listening to what matters to the people you're trying to influence.
47:06
SPEAKER_0: I feel like somehow from the word influence that's kind of left out that it needs to be two way.
47:11
SPEAKER_0: And the most influential people I know are the ones who come in with ideas, but they often listen and often they're like, You know what?
47:18
SPEAKER_0: Oh, you're right.
47:18
SPEAKER_0: We should do your idea."
47:20
SPEAKER_0: And maybe not get hung up on the whose idea it is, instead of just looking at whatever the goal is that we're all trying to do here.
47:28
SPEAKER_1: Absolutely.
47:29
SPEAKER_1: 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.
47:59
SPEAKER_1: 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.
48:10
SPEAKER_1: And there are some case studies that I discuss in the course where my attempts to influence failed miserably and we tried to understand why, but then I had some attempts to influence that, succeeded beyond my expectations and trying to figure out what worked there.
48:30
SPEAKER_1: And when we look at what worked there is a combination of track record, credibility, visibility, social capital, just being a helpful person and giving a lot.
48:45
SPEAKER_1: Because that's the thing, when we say we want to influence, we're making an ask from others, "Do this.
48:56
SPEAKER_1: Listen to me."
48:57
SPEAKER_1: And so on.
48:57
SPEAKER_1: And so, all these relationships, if we want people to be more likely to listen to us, we have to give first.
49:05
SPEAKER_1: Be helpful, be a go-to person.
49:08
SPEAKER_1: Right?
49:09
SPEAKER_0: 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.
49:18
SPEAKER_0: What are some tactical advices, like three pieces of tactical advice that you could give, that you could help debug what's going on and maybe help build this being influential instead of just influencing?
49:31
SPEAKER_1: Yeah.
49:31
SPEAKER_1: So, I think an influential engineer should have key relationships.
49:41
SPEAKER_1: So, I would first troubleshoot the relationship with the manager, and why doesn't the manager listen to me?
49:49
SPEAKER_1: Troubleshoot, 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?"
50:09
SPEAKER_1: Or, "What can I do more to build a track record?"
50:14
SPEAKER_1: So, instead of saying, "Hey, why don't you listen to me?"
50:19
SPEAKER_1: Take what do I need to be listened to and say, "Okay, how can I work on building those things?"
50:26
SPEAKER_1: And I think manager is the number one person to go to for this type of advice.
50:30
SPEAKER_1: Your tech lead can also be a person, your product manager.
50:33
SPEAKER_1: Product managers are usually very savvy about these things.
50:36
SPEAKER_1: So, they may actually have better advice.
50:40
SPEAKER_1: And I think the way to frame this is by partnering, "How can I be a better partner to you?"
50:50
SPEAKER_1: And so, when building these relationships, even with product managers, they want to work with people who are able to influence, because they oftentimes want input from engineers, right?
51:02
SPEAKER_0: Mm-hmm.
51:03
SPEAKER_1: It helps them do their jobs better.
51:05
SPEAKER_1: 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 therefore, they'll be more willing to listen to us.
51:24
SPEAKER_0: So, that sounds like you're saying turn it around and figure out, "Hey, who are these stakeholders?"
51:32
SPEAKER_0: And then just ask them honestly, or instead of going directly, but, "Hey, how could I do more of this?
51:39
SPEAKER_0: What would you need from me?"
51:40
SPEAKER_1: Yes.
51:41
SPEAKER_0: And then they'll probably answer.
51:42
SPEAKER_1: Yeah, they will.
51:45
SPEAKER_0: Simple as that.
51:46
SPEAKER_0: Now, another thing that sometimes comes up is 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?
52:14
SPEAKER_0: You don't want to lose that influence, but you could, right?
52:20
SPEAKER_1: I don't know if saying no specifically loses the influence.
52:23
SPEAKER_1: I think what's worse is saying yes and not being able to do it or keep your commitments.
52:30
SPEAKER_1: I found that to be more damaging to trust.
52:34
SPEAKER_1: And people often trust people who say no more than people who always say yes.
52:40
SPEAKER_0: Interesting.
52:41
SPEAKER_1: No is necessary.
52:43
SPEAKER_1: 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.
52:55
SPEAKER_1: 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.
53:03
SPEAKER_1: You're not rejecting the person, you're rejecting an idea.
53:06
SPEAKER_1: So, when you make it about ideas, it is less personal.
53:10
SPEAKER_1: Even hearing a no, you are telling me that this cannot be done.
53:14
SPEAKER_1: You're not telling me, "No, I don't want what you want me to do."
53:18
SPEAKER_0: Yeah.
53:19
SPEAKER_0: It sounds like you shouldn't be that afraid to say no in the right way, and don't worry much about ... Worry about saying yes to too many things.
53:28
SPEAKER_1: Yeah.
53:28
SPEAKER_1: Well, it's tricky with no, because it's cultural often.
53:33
SPEAKER_1: In some cultures more than others, no is seen as extremely rude.
53:38
SPEAKER_1: But also, there are ways to say no more softly without actually saying no.
53:42
SPEAKER_1: Counter-offering.
53:44
SPEAKER_1: Buying more time to think about options.
53:48
SPEAKER_1: Negotiating.
53:49
SPEAKER_1: A no can become a yes, but a yes then going back to no, not really-
53:55
SPEAKER_0: You can always say, "Yes, but..."
54:02
SPEAKER_1: Yeah, but it's much more difficult.
54:04
SPEAKER_0: Yeah.
54:06
SPEAKER_0: So, looking back at your career, both as a software engineer, tech lead, tech lead manager, now coaching engineering managers and software engineers, what do you think is the most difficult part of being a software engineer, what kind of skill set?
54:24
SPEAKER_0: Is it the coding?
54:25
SPEAKER_0: Is it people?
54:26
SPEAKER_0: Is it something else?
54:27
SPEAKER_1: From my experience, it's always been people.
54:29
SPEAKER_1: I started programming in eighth grade.
54:34
SPEAKER_1: That was decades ago, multiple decades ago.
54:39
SPEAKER_1: Coding is fun and interesting and new, and it's still exciting, but it was never the roadblock for my success or for anyone's success, because we work in teams, we don't work independently.
54:54
SPEAKER_1: 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.
55:10
SPEAKER_1: The most difficult part of tech isn't necessarily the software part, it is the collaboration part, and to be a better collaborator ... Collaboration is essentially leadership.
55:24
SPEAKER_1: 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, and influence.
55:42
SPEAKER_1: Because that's the thing about leadership is people think about leadership as the leadership that has the authority hierarchical like titles, but that's not it.
55:54
SPEAKER_1: This is not just it.
55:58
SPEAKER_1: So, if you want to get anything done, you need leadership skills, you need collaboration skills.
56:03
SPEAKER_1: You need influence skills.
56:05
SPEAKER_0: With that, let's go to rapid questions.
56:07
SPEAKER_1: Okay.
56:08
SPEAKER_0: So, what's a life philosophy or approach that has been helpful to you?
56:14
SPEAKER_1: I saw this TED Talk by Robert Waldinger called what makes a good life?
56:22
SPEAKER_1: And it's lessons from a study on happiness, it's called, and essentially the lesson here is that the quality of your life is the quality of your relationships, and that applies to work-
56:35
SPEAKER_0: Love it.
56:36
SPEAKER_1: ... as well as personal life.
56:38
SPEAKER_0: What is a non-fiction book and a fiction book you would recommend that you enjoyed?
56:42
SPEAKER_1: So, a non-fiction book that actually helps with influence is called Think Again by Adam Grant.
56:50
SPEAKER_1: I love anything by Adam Grant, but Think Again, it was exceptional.
56:55
SPEAKER_1: And then a fiction book is The Midnight Library by Matt Haig.
57:01
SPEAKER_1: Essentially, it's a library of all your possible lives and it makes you think, puts things into perspective literally.
57:15
SPEAKER_0: Okay.
57:15
SPEAKER_0: I'll make a note of that, and we'll have all of these in the show notes below as well.
57:17
SPEAKER_0: What's your favorite programming language and framework?
57:21
SPEAKER_1: I used to be a C++ fanatic, but ever since I moved to Uber I'm a Golang girlie.
57:27
SPEAKER_0: Golang.
57:27
SPEAKER_1: So, I feel like Golang takes C++ back to C in a way and removes a lot of the complications.
57:40
SPEAKER_1: So, I would say Golang.
57:43
SPEAKER_0: In Golang do you use frameworks or are they that helpful?
57:47
SPEAKER_0: In some languages, they are.
57:48
SPEAKER_0: I'm not sure how much in Go, I'm not as much of a Go expert.
57:51
SPEAKER_1: I mean, gRPC, gRPC-Gateway.
57:54
SPEAKER_0: Yeah.
57:56
SPEAKER_1: I've used this so much.
57:57
SPEAKER_1: So, I would say that's my go-to.
58:03
SPEAKER_0: Nice. And finally, what's a fun activity that you do to unwind from tech?
58:04
SPEAKER_1: I lift weights.
58:06
SPEAKER_1: I do CrossFit now, but I'm also actually a certified personal trainer, so I've been-
58:13
SPEAKER_0: Wow.
58:13
SPEAKER_0: Do you do personal training as well?
58:14
SPEAKER_1: No, I don't.
58:15
SPEAKER_1: I don't train people.
58:16
SPEAKER_1: 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.
58:27
SPEAKER_1: So, CrossFit.
58:29
SPEAKER_1: And if it's not CrossFit, reading or cooking are my go-tos.
58:34
SPEAKER_0: Awesome.
58:34
SPEAKER_0: Well, it was great to have you here.
58:35
SPEAKER_1: Likewise.
58:36
SPEAKER_1: This was a great conversation.
58:38
SPEAKER_0: If you enjoy this podcast, please do subscribe on your favorite podcast platform and on YouTube.
58:43
SPEAKER_0: And if you're interested in reading more about promotions, see relevant deep dives from The Pragmatic Engineer linked in the show notes below.
58:50
SPEAKER_0: Thanks, and see you in the next one.