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

when you arrived at Uber how did you feel internal tooling 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 exg googler 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 would even talk to you if you didn't have the design doc you couldn't just go and say hey I have this idea let's do this they're like where's the design do 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 arus tesu 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 St called pneumonic in this conversation we cover what Google is like 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 we close with tactical pointers on how to become more influential as a software engineer within your team and organization if you enjoyed 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 professional and writes your newslet are called the caring techy so with this let's jump in Arena welcome to the podcast hi thanks for having me c can we talk about on on Google Fiber when you worked there and you moved over to Google's Tech stack how was a a project like done in terms of this this might have been a product development or or building a feature uh 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 in um on live streams for example I would yeah then start the the design process talk to product managers figure out if we had what is like the the set of requirements do the design dog get the design up I was given the problem in with the requirements including and uh was asked to design the solution not to figure out what you know the product we did have a product manager which was um was very actually very helpful and we had a great relationship um and one of the things I really appreciated Google is I had a good relationship with product in the sense that I was involved in the product um definition so I could say this is not really feasible this is feasible and I feel like another 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 who we use Google Docs for that not not a lot of like internal tooling for that um manual approvals I think but but by the way this was a time where design docks were not really common right like like this was I I I think now it's pretty common or people know about it but had a great culture of design docs even before my my time I would say and this is like 2012 2013 um it was unheard of to not have a design dog for something for the projects that I led was a lot of cross organizational um coordination with double click for example they would wouldn't even talk to you if you didn't have the design dock like where's the design dog and they're great people by the way we I collaborated like 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 dog I want to read like no seriously and that was shocking to me to come to Uber 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 it did change but early on no it was more of a nice it was more like oh you had the problem okay let me go code this episode is brought to you by workos if you're building a SAS app at some point your customers will start asking for Enterprise features like Sam authenication skim provisioning and fine Gren authorization that's where work comes in making it fast and painless ad Enterprise features to your app their API are easy to understand and you can ship quickly and get back to building other features work also provides a free user management solution called Au kit for up to 1 million monthly active users it's a drop in replacement for odd zero and comes standard with useful featur features like domain verification role base Access Control bot protection and MFA it's powered by radic components which means zero compromises in design you get Limitless 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 versel and perplexity check it out at work.com to learn more that is work os.com this episode is 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 assistant and improves the developer experience with streamlined workflows sonar analyzes all code regardless of who writes it your internal team or gen 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 co-pilot Amazon Q developer and Google Gemini code assist boosts developer productivity and ensures that code meets Rous quality and security standards joined over 7 million developers from organizations like IBM nza barley and Microsoft who use sonar trust your developers verify your AI generated code visit sonar source.com pragmatic to try sonar Cube for free today that is sonar source.com pragmatic ni so the design talks they were enging design docs right so this is like you know like a summary of what did a typical design doc look like like in in this project for example what would it contain yeah so um a brief description of what the problem was and exactly what the goals were um maybe a link to the PRD um the product requirements St yeah product requirements stocks and um then kind of like a highlevel architecture proposal then um more in-depth details of proposed interfaces but not everything very fine grain that's the thing there were components or little things that could be I 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 I I didn't want to be the techly that just does everything and everybody just has to execute right especially when I was a techly 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 um so that was that and then very important to have um risks PL like timelines risks um and then also a launch plan I think that was um because at Google everything that went out had to be approved by sres and and um production Readiness it was called oh so Cyro lob 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 cuz they were other teams MH um but they were looking at these things because I remember that part of the checklist was um Sr 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 uh they're like this is unintuitive and we're like sorry I guess a downside of a of a large company every team has different goals or focuses but what I did appreciate was a part of the the Readiness review you had security audits you had um you know making sure everything is done properly which um 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 that's kind of how it work right like every team's SP up like multiple micros Services 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 the contrast and obviously product Readiness takes time and but it's important what I 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 um well and you had this plan 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 at we did definitely Google definitely had experimentation platforms and the systems but I didn't use it we didn't use it as much um at fiber like AB testing types we did gradual roll outs or monitoring and that was separate um but yeah so continuing from planning now interestingly because you mentioned you asked me about PL like T 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 cope out the work in Google Sheets and I actually took that with me at Uber because I didn't quite like um planning and fabricator and so once I had everything in a nice pretty spreadsheet I would assign owners and just file bugs and track that the reason why I use spreadsheets is to make sure everything gets done right other people H want to have access to all this planning like for example produ managers because they want to see when is it going to be done spreadsheets is in 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 no I don't know but does it help me as a techly to be on top of everything that's happening yes it's like Google Google is famous for having pretty much ACC 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 for that and so and for everything Pro tracking bugs monitoring alerting Etc what are some interesting tools that you worked with at the time I used code search a lot because it's um it's like a a repository of how to do anything if you wanted to learn how to use our PC or certain libraries or whatever you want you can probably find an example it was just C slash and then you just search it was so fast for me when and even as a tech lead if there were um 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 um and also you forget how things work so it's nice to just get refreshes when ever you want like to just double check things make sure you know things work the way you remember them critique was our um sort of code review and it's fun cuz like 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 so and cl is a change log lgtm means you essentially get a stamp of approv so you can submit your um code and interestingly what I keep telling people is uh when with code reviews we had two reviews one was a readability reviewer so Google prioritize 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 C 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 now an expert and you you can do the things but was it like how did it go so um 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 um you can get feedback here and there but if um if you keep making the same mistake then the person who gives you readability won't uh give you readability would say you're not ready keep keep working on your readability I like it it's it seems like it's not something you can kind of game I mean you can game as by you know giving good feedback writing good code yeah but you 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 it's rare to hear but I guess I'm not tooo 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 I felt it cuz I sometimes I I would be at Uber trying to read someone's code and I had to take notes and I was like this at at Google would be if I had it was if I have to take notes for something it's not clear enough and uh what what other other tools that were kind of memorable or like unusual um well meme genen is one of them I think memes are an essential part of the Google culture to this day um and it's I think it's it was interesting sometimes to find out news like stuff from mem genen uh and then a generator or what does yeah yeah so a meme generator essentially so you can pick the template and write whatever you want and then uh you would see the latest memes that were created and you can upload them so the ones that were really good would become the ver internal version of viral nice so um and it's 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 to overcome both good and bad things one system that I I I I think if you research Google a little bit it comes up as Borg did you use Borg and what was it for yes so um 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 um but at the time it wasn't like there was no out there I had not seen that anywhere else like dynamically allocating jobs on the and resources on clusters and and all that and being able me as an engineer to actually go and fine-tune some of these things or customize um it felt like a lot of power so as an engineer who might be joining Google or or a similar size company 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 joined Google yeah so I would say number one is build relationships early um 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 um you know help you understand your org and figure out who's who in the sense that who's the tech lead who's the manager manager who's 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 uh go ask your questions to multiple people 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 um what else credibility I didn't realize but credibility takes time to build and you do need a track record of result 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 um kickstarted let's say as soon as you join the company so getting handson as soon as possible and creating that track record and um intentionally building this credibility and this pool of knowledge I think so any any new engineer should start right away and I these are not things that I knew actually when I joined so what are good ways that you would see a new engineer build credibility I really appreciate it 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 com like that combination of two is what actually makes me trust people more uh trust my reports more and so on and that comes hand inand with credibility because if I trust them then I I I find whatever they have to say as believable right that's what credibility means so talking about promotions your first promotion was unfortunately rejected at Google can you tell tell me how promotions work at Google and you know why this rejection came and what did you do about it yeah so I call it my uh my blessing in disguise because it taught me a lot so what H what ended up happening is when I joined Google I was on um serving ads and um I didn't love it there because I there was some organizational changes and um wasn't quite finding my place so after 9 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 um Google 3 monor repo and the Google World um my work was kind kind of Niche because it was embedded I actually worked on the colonel at some point I did very lowlevel things directly on the Google Fiber devices um and now where the promotion at Google uh in my rejection came in so the way promotions were done then and I know this changed a little bit um all levels new grad all all of them to for promotions they would go to promo committees these promo committees were Committees of people from all around Google that were um 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 um with my promotion is because it was sort of decoupled and kind of hard to understand and like it wasn't the 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 M that word impact yes and the problem is when you have um 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 try in six more months or comeback you're 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 might take away 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 um a something that I drove um and in working with my manager to say I think these are the things I'm supposed to work on I think these are um I 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 months yeah yeah so you were rejected at this point and then how did you approach it so so you said you decided like all right I'm going to go for promotion again and you turn things around and talk 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 cuz Google had pretty detailed competencies right like 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 um 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 in integrate a driver in a thing so um in 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 and like driver you mean like a a lowlevel driver yes colel driver language was this c c wow you're coding away in C awesome C well so in college my specialty was operating systems and compilers and I actually was a teaching assistant for operating systems so 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 it would be closer to my uh my background and so my move to distributed systems happened um more towards when I started doing tv ads so I stayed with the team try to show the impact sadly I I realized it's still not showing the impact that Google committee wanted so I didn't try again after 6 months but what I did instead is I changed teams which seems like a risky decision in 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 us explain like how that happened like you know like some companies are it's easy to change team sounds like Google's one of them some are harder like a new team was formed and like a manager was telling people hey if 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 opport OPP unities out there I could I met with my skip level actually oh 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 um interestingly that's also how I found my first Mentor because my first Mentor W 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 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 year and a half almost um what do you think I should do between these two teams like how do you think about this and just genuinely asked 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 which was W yeah so so you had a you had a a bit of a disappointment for the first promotion to n 2 and then a lot faster promotion to senior how what happened there yeah so it took me two and a half years to get to N2 and it took me a year to get to senior I think it showed why like the first promotion was rejected wasn't because I wasn't growing and or because I wasn't good enough or because I wasn't learning things um it was the context but 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 do 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 show me let me show you what I can do was kind of my my Spiel to my to my manager and then he just did and I that's when I um I told him I want to be a tech lead I was an inch to what did I know right um I said I told him I want to help you build this team um and just give me work I was like give me all the work I'll do whatever it takes and so so it it kind of sounded like a bit of a small start 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 or even a team inside a massive company right we're talking 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 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 that's what ended up working for me well I 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 so you got to Pro like it sounds like you know you got the work and and you got promoted to senior later when you joined Uber I mean you observed promotions there how similar or different were promotions at at Uber than Google again earlier Stage Company but also a very large company already yeah so when I joined Uber promotions were done by managers they in 2018 with Uber 2.0 and I think what what ended up happening so and I'm curious to hear your thoughts on this about how we would describe the Uber culture but to me it felt like it was very um sort of Amazon influenced and um move very move fast Amazon 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 are leaders coming in from Google who then then they brought a little bit of the Google culture in so in 201 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 packet 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's stick around longer than they do at 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 um more of a you had like an internal resume and um it was still now it was decided by people within your org but you had to participate in an interview so yeah yeah I I I was actually manager at at rubber when these changes happened so for the first promotion in 20 we we joined in 2016 and then we still had that was as 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 exact 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 you had to recurse yourself if you knew the person it was just very long and very exhausting and then every six months we were to credit 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 a committee would look at all the promotions including like from n one to two then two to senior and later they changed that to so that managers could actually the organization could could decide on the up to senior promotions which were arguably not as I guess challenging uh ones to deci side and where like context of the manager was very helpful yeah and yeah also as as you said with the with the peer reviews interesting because I did see as a manager there was a big problem that people left uh 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 staff promotion and they they were counting on getting that recommendation from the staff engineer and the staff engineer was said 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 it yeah even if you could have reached out it didn't really matter so so yeah that was I guess it's a good observation yeah it did change I I ended up having to um when one of the staff Engineers on my on edit 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 um they don't do promo committee promotions either for I think L3 and L4 and sounds like they ended up where Uber ended up after a while yeah but just 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 your career growth they wanted to decouple the um that from the process because and there there would be cases where your promot your manager maybe wouldn't support your promotions but the promo committee decides you do deserve the promotion yeah so it's all those be as a manager like what I've seen is when the manager didn't support it was really hard to 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 recurse themselves so there were some award situations as well of you know like a mobile engineer being decided by not necessary mobile engineer it was interesting challenges but knowing what what you know and you went through multiple promotions at Google You observe them at Uber how would you recommend that software engineers at larger companies or even midsize companies think about promotions be intentional about it and have a goal in mind um D 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 if I I just focus 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 um 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 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 mhm um not a lot of managers do this very few that I know actually do career plans but that doesn't stop individuals software Engineers um ic's to do that and run it by their manager and and what is a what is a career plan uh in your mind or a good career plan look for you yeah so something like um if 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 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 um you know these other activities so for example uh Google had a citizenship criteria for your promotion right so for citizenship may be in a plan could be could say oh be be run more interviews or participate at Grace Hopper or some some citizenship showing so it's 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 are exceptions to this but what would your recommendation be to figure out you know like how how much promotions have slowed down at my company and also just how to potentially re-evaluate promotions given that it's it's not going to be as 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 pro even with a career plan that's why I call it a career plan not a promotion plan necessarily right um I think in a way there's been um 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 things catch up things adjust and balance out over time what people should focus on I think is growth and 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 um and I do think in 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 it's a let's help each other here between the manager and report and let's do the best work we can with the conditions the economical economy conditions that are there um but also have realistic expectations of like of grow hyper growth career hyper growth is not realistic there could be phases of hypergrowth but it's just not it's not going to be 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 what does coaching mean yeah so how I if for someone I tell them this how I made this career transition for now um it it might surprise them because it seems like I'm it's very it seems very different but in fact it's not I think managers techy 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 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 uh involves more of um to figure out what gets in the way that's where things get tricky sometimes they're exter external Factor sometimes there's you know lack of skills or lack things that you can add but there's a lot lot of mindset work that goes in so in coaching I cover essentially it's like holistically looking at how to achieve your goals youve you also focus on influence yes especially for software Engineers how would you even Define influence in a way that we don't Define it as politics which I think as Engineers we like to run away from yes so influence has in interestingly at Big tech companies the word like the concept of influence St Authority isn't necessarily foreign like people kind of know what it means because it's just maybe explicitly even part of the culture or some some companies even mention it in their values but um 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 um let's say Bad actors but what is influence really is is the input you put into a system to and 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 inputed your opinion and feedback into something with the hope to change something right disagreement is a form of influence because um again you're inputting your disagreement with the hope to change someone's minds or to change an output or or an outcome right sharing any type of point of view or opinion as a form of influence convin trying to convince others negotiation is a form of influence um getting Buy in if you have an idea is a form of influence right so in a way um 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 SE at senior levels where um 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 that there's a little bit of a distinction between to influence and to have influence mhm because when we say to influence people think and that's where people people usually stay at when they think of influence is they stay at oh I'm it's the act of influence I'm trying to persuade you I'm trying to convince you oh what are the words that I need to use to convince you of something versus to have influence is more of a 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 are at a state where people come and ask for your input because you're quote unquote influential right people want to um people reach out to you and they want your input yeah and and like you know like talking let's say let's take a specific example like I'm I'm a software engineer I have a really good which I think is a really good idea uh that we should refactor we should remove this Tech Dept you know maybe refactor the architecture and I I think it's we should absolutely do it it's a lot of work but 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 it's too much work and so now I'm looking to I want to influence people like is this the type of thinking you're talking about you're like oh I wish I could just go and you know 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 is 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 I and mistakes of influence they influence with without bu building credibility and without um or even visibility or without having um a track record or a reputation but also um 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 uh 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 two-way and the most influential people I know are 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 and maybe not get hung up on on Whose idea it is uh instead of just looking at what is what 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 of this because um as you said being willing to if you have for example a precedent of actually admitting you were wrong or um giving credit to someone else people are more actually more likely to listen to you next time so um and the re 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 We 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 there I had some attempts to influence that succeeded beyond my end my expectations and trying to figure out what work there and when we look at what work there is a combination of um track record credibility visibility Social Capital um just being a helpful person and giving a lot at 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 so let's say I'm a software engineer and on my team or in my organization I I don't feel my my voice heard by my team or by my manager what 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 and maybe you know like like help build this this influence like being influential instead of just influencing yeah so I think an 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 um troubleshoot why if there's a lack of trust sometimes these things can be addressed from the engineer side of um asking specifically asking questions of what can I do more to demonstrate trustworthiness or what can I do um more to build a track record so not instead of saying hey why don't you listen to me sort of take what do 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 might actually have uh better advice and um 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 B to influence because they often times want input from Engineers Engineers right it helps them do their 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 therefore they'll be more willing to listen to us so so sounds like you're you're saying you know like turn it around and and figure out hey who are these stakeholders and then just ask them honestly or or like instead of like going directly but but hey how how can how could I do more of this what what you need from me yes and then they'll probably answer yeah they will as simple as that now another thing that sometimes comes up is you know like you've gain some level of influence uh people do come to you they ask you they they 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 for saying no for helping out on this project or even reviewing a doc for 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 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 being able to do it or keep your commitments I I 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 um 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 me to do so yeah um sounds like you shouldn't be that afraid to to say no in 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 um 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 um 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 um it's much more difficult yeah so looking back at your career both as a software engineer Tech lead tech lead manager now now coaching uh engineering managers and uh software Engineers what do you think it's the most difficult part of being a software engineer like what what kind of skill set is it the coding is is it people is it something else for my experience it's always been people I I started programming in 8th grade that was decades ago multiple decades ago um coding is fun and interesting and new and it it's still exciting but it's it was never the roadblock for my successful 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 achieve achieving the goal was someone else or some someone's misunderstanding of something or um 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 to those levels senior staff senior staff and so on you need to start building your leadership skills communication collaboration um strategic thinking big big picture thinking and so on and influence because um 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 not it is not just it um so if you want to get anything done you need leadership skills you need collaboration skills you need influence skills with that uh let's go to Rapid questions okay so what's a life philosophy or approach uh that has been helpful to you I saw this Ted Talk um by Robert waldinger called um what makes a good life and essentially the and it's a lessons from a study on happiness it's called and essentially the the lesson here is that the quality of your life is the quality of your relationships mhm and that applies to work as well as well as personal life what is a non-fiction book and a fiction book you would recommend that you enjoyed so um non-fiction book that actually helps with influence is called think again by Adam Grant I I love anything by Adam Grant but think again it was exceptional um and then a fiction book is the Midnight Library but by Matt Hig um essentially it's a library of your all your possible lives and um it makes you think puts things into perspective literally okay I'll 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 of tuber I my golang gly so golang so I I feel like golang takes C++ back to C in away and removes a lot of the complications um so I would say goang in goang do you use Frameworks or or are they that helpful as like in some languages they are I'm not sure how much in go I'm not as much of a go I mean expert grpc drpc Gateway yeah every I've used this so much so I would say that's my go-to nice and and finally what's a fun activity that you do to unwind from Tech I lift weights I do CrossFit now but um 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 um I've been fascinated by this space um and I do think working out has a has great mental health benefits as well so CrossFit and if it's not CrossFit reading or cooking are my go-tos awesome well it was great to have you here likewise this was a great conversation if you enjoy 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