Irina Stanescu spent over 14 years as a software engineer and engineering leader at Google and Uber, and now works as an engineering leadership coach. In this episode, she gives an insider’s look at how Google operates from an engineer’s perspective: the internal tools, the promotion process, the culture of design docs and code readability, and how to build influence as an engineer. She contrasts Google’s highly structured, tool-rich environment with Uber’s faster-moving, less formal culture, and shares hard-won lessons from having a promotion rejected at Google early in her career.
Google’s engineering culture and internal tooling
Google had an unusually strong culture of design docs — written proposals that describe a problem, goals, high-level architecture, proposed interfaces, risks, timelines, and a launch plan. Teams like Double Click would refuse to engage with engineers who didn’t have a design doc. This was already standard practice around 2012–2013, before design docs became widespread in the industry.
Design docs at Google were typically written in Google Docs, not a specialized internal tool. They included links to product requirement documents (PRDs) and were reviewed with manual approvals.
Irina, as a tech lead, deliberately left parts of the design open so senior engineers on her team could own pieces of it, giving them material for their own promotion packets and career growth.
Readiness review was a formal gate before anything could launch in production. SREs and a separate production readiness team reviewed services for security, naming conventions, and operational readiness. This sometimes caused friction — for example, the readiness team rejected service acronyms as “unintuitive” — but it ensured security audits and proper operational practices were in place before launch.
This contrasted sharply with Uber, where teams could push changes to production almost immediately.
Code search was one of Irina’s most-used tools — a fast, searchable index of Google’s entire monorepo that let engineers find examples of how to use any library or API. It was invaluable for settling debates by looking at real code and for refreshing one’s memory about how systems worked.
Critique was Google’s internal code review tool. Approved changes were marked “LGTM” (looks good to me), and “CL” stood for changelist.
Readability certification was a distinctive Google practice. Each programming language had a detailed readability guideline document. To get certified, an engineer had to submit enough code changes following the guidelines on their own. If they kept making the same mistakes, the reviewer would withhold certification. Once certified, that person could approve others’ code for readability in that language.
The goal was to ensure code across the entire codebase was clear and maintainable, reducing the cognitive load for everyone who had to read or modify it later. Irina felt this was lacking at Uber, where she sometimes had to take notes just to understand colleagues’ code.
Memegen was an internal meme generator that became a cultural institution at Google. Engineers could pick templates, write their own text, and share memes internally. It served as both a news source and a way to use humor to cope with difficult situations.
Borg was Google’s internal cluster management system for dynamically allocating jobs and resources across clusters. It predated Kubernetes and gave engineers significant power to fine-tune and customize their deployments. Irina noted she hadn’t seen anything comparable outside Google at the time.
Planning and task tracking
Irina preferred Google Sheets over dedicated project tracking tools for planning. She would break down work in a spreadsheet, assign owners, and then file bugs to track execution.
She carried this habit to Uber because she didn’t like Uber’s internal planning tool (Fabricator). Spreadsheets helped her as a tech lead stay on top of everything, though she acknowledged they weren’t ideal for product managers who needed progress projections.
Navigating a large organization as a new engineer
Irina’s advice for engineers joining a company like Google:
Build relationships early — use the “new person” window to schedule one-on-ones and learn who the tech leads, managers, decision makers, and owners of various systems are.
Distribute your questions across multiple people rather than overloading a single tech lead. This also helps build connections, because people generally enjoy being helpful.
Build credibility quickly — credibility takes time and requires a track record of results. Start getting hands-on as soon as possible. The combination of credibility and visibility needs to be kickstarted early.
Good ways to build credibility: demonstrate that you’re a good listener first, show understanding before jumping to opinions, ask great questions, and then be reliable in execution. That combination builds trust, which is the foundation of credibility.
How promotions work at Google
At the time Irina was there, all promotions (from new grad through senior levels) were decided by promotion committees — groups of people from across Google who reviewed promo packets containing self-assessments, manager assessments, and peer assessments. The committee would meet and decide whether to promote.
This was intentionally designed to be unbiased — to decouple promotion decisions from any single manager’s influence. In theory, a committee could promote someone even if their manager didn’t support it, though in practice that was very difficult.
Engineers had to recuse themselves from committees if they knew the person being reviewed, which sometimes led to awkward situations like a mobile engineer’s promotion being decided by non-mobile engineers.
Promotions ran on a six-month cycle.
Google has since changed the process: L3 and L4 promotions are now decided by managers rather than committees, converging toward where Uber eventually landed.
Irina’s own promotion journey
Irina’s first promotion to L4 was rejected. She had transferred to Google Fiber after nine months because she wasn’t finding her place on her initial team. At Fiber, she worked on embedded systems and the kernel — niche work with a small user base. The promotion committee’s feedback was that she executed everything asked of her but didn’t show enough impact, because her work was decoupled from the scale that other engineers (handling millions of requests) demonstrated.
The rejection triggered self-doubt but also taught her a critical lesson: doing what your manager asks is not enough. You need to understand what the promotion committee is looking for and demonstrate you’re already operating at the next level.
She worked with her manager to identify a specific project that could demonstrate impact, but after six months she realized the niche embedded work still wouldn’t show the kind of impact the committee wanted. Rather than try again, she changed teams — which she acknowledges was risky and wouldn’t generally recommend.
She moved to a new TV ads team that was just getting started. She found the opportunity through her skip-level (her manager’s manager) and a director she knew. She didn’t even change desks.
On this new team, she told her manager she wanted to be a tech lead and help build the team. As the second engineer on a new team, she had the opportunity to take on significant ownership.
She also found her first mentor — her former tech lead from the embedded team — by genuinely asking for his advice about the team decision. He offered to continue meeting at a regular cadence, and that mentorship relationship was instrumental in her career.
She was promoted to senior (L5) after just one year on the new team, compared to the two and a half years it took to get past the initial L4 rejection. The difference was context, her understanding of how to write a promo package, and working on projects the committee could recognize as high-impact.
Promotions at Uber vs. Google
When Irina joined Uber in 2016, promotions were decided entirely by managers — a much lighter-weight process influenced by Amazon and Facebook’s “move fast” culture.
In 2018, after organizational changes and leadership changes in 2017, Uber adopted a process modeled on Google’s: self-assessments, peer reviews, and committee-based decisions. This proved unwieldy because Uber had higher turnover than Google — peer reviewers would leave before the promotion cycle completed, and the long peer assessments lost context.
By 2019, Uber shifted again to a lighter process with an internal resume and an interview-like component, decided by people within the org. Eventually, managers were given authority to decide promotions up to senior level, with committees reserved for higher levels.
Irina noted the challenge of peer reviews at Uber: she once had to ask a departing staff engineer to write her peer review before he left, as a defensive mechanism for a future promotion application.
How to think about promotions
Irina’s core advice: be intentional about promotions but prioritize growth over promotions. Focusing too much on the promotion itself can be demoralizing if it doesn’t come through. Focus on excitement and growth, and the promotion will follow.
Drive the process yourself — have a goal, have conversations with your manager, and create your own career plan.
A career plan (not just a promotion plan) involves identifying the competencies, skills, and types of impact needed for the next level, and then brainstorming specific projects or activities to demonstrate them. For example, Google had a “citizenship” criterion for promotions, so a career plan might include running interviews or participating in events like Grace Hopper.
In the current economic climate, where promotions have slowed at many companies (with AI companies as exceptions), Irina recommends:
Managers should communicate clearly about expectations and the factors that influence promotion decisions.
Engineers should recognize that careers are long, there aren’t enough levels to be promoted every 18 months, and hyper-growth career trajectories are not the norm.
Focus on developing skills, competencies, and working on interesting things. There’s always something new to learn.
The job market is also tighter now, making it less practical to leave a company solely over a missed promotion, so manager and report should work together to do the best work possible under current conditions.
Influence as a critical engineering skill
Irina defines influence as the input you put into a system (your organization) to affect its outputs. Feedback, disagreement, sharing opinions, negotiation, convincing others, and getting buy-in are all forms of influence.
She distinguishes between to influence (the act of trying to persuade someone) and to have influence (a state where people come to you because you’re recognized as credible and valuable).
Common mistakes engineers make when trying to influence:
Trying to influence without having built credibility, visibility, or a track record first.
Being passive for a long time and then suddenly trying to push an idea — people will wonder why they should listen.
Not listening to what matters to the people they’re trying to influence. Influence needs to be two-way.
The foundation of influence is relationships, human connection, and social capital. Being willing to admit you were wrong, giving credit to others, and being helpful without expecting anything in return all make people more likely to listen to you in the future.
Irina teaches influence by reverse-engineering what worked and what didn’t work for her as a tech lead, including case studies of both failed and unexpectedly successful influence attempts. The common factors in successful attempts were track record, credibility, visibility, social capital, and being a helpful, generous colleague.
Tactical advice for engineers who don’t feel heard
Troubleshoot the relationship with your manager first — ask directly: “What can I do to demonstrate trustworthiness?” or “What do I need to do to build a track record?” Frame it as “How can I be a better partner to you?”
Talk to your tech lead and product manager as well. Product managers in particular tend to be savvy about organizational dynamics and may have better advice. They also want engineers who can influence, because good engineering input helps them do their jobs.
Approach all key stakeholders with the mindset that they just want to do their jobs well, and figure out how you can help them do that. This builds better relationships and makes them more willing to listen to you.
The importance of saying no
Saying no is sometimes necessary, especially for tech leads who need to push back on ideas that are impossible or not feasible.
Say no to the idea, not the person. Frame it as “this can’t be done” rather than “I don’t want to do what you’re asking.” This makes it less personal.
Saying no does not necessarily damage influence — but saying yes and failing to deliver is far more damaging to trust. People trust those who say no more than those who always say yes.
Cultural context matters: in some cultures, saying no is seen as extremely rude. Alternatives include counter-offering, buying time to think, or negotiating a modified version that becomes a yes.
The hardest part of being a software engineer
For Irina, the hardest part has always been people and collaboration, not coding. She started programming in 8th grade and still finds it fun and exciting, but it was never the bottleneck. Miscommunication, misunderstandings, and coordination challenges were what got in the way of success.
To be successful at senior levels and beyond, engineers need to build leadership skills: communication, collaboration, strategic thinking, big-picture thinking, and influence.
Leadership in this context doesn’t mean hierarchical authority — it means the ability to get things done through others, which requires influence and collaboration skills.
Rapid fire
Life philosophy: A TED Talk by Robert Waldinger on the Harvard Study of Adult Development — the quality of your life is the quality of your relationships, at work and in personal life.
Non-fiction book: Think Again by Adam Grant, which helps with influence.
Fiction book: The Midnight Library by Matt Haig — a library of all your possible lives that puts things into perspective.
Favorite programming language: Go (Golang). She used to be a C++ fanatic but feels Go takes C++ back to C and removes a lot of complexity. Her go-to framework is gRPC/gRPC-Gateway.
Fun activity to unwind: CrossFit and weightlifting. She’s also a certified personal trainer. When not working out, she reads or cooks.
