The Making of a Senior Engineer π‘: Guest Post by Addy Osmani
Guest post by Addy Osmani, Head of Chrome at Google
Hi fellow High Growth Engineer π ! Jordan here.
Today we have a special guest post from Addy Osmani.
Addy is the Head of Google Chrome Dev Experience, has grown to Senior Staff Engineer at Google, has written multiple software engineering books, and is the author of the newsletter on Substack.
Addy has progressed through the engineering ladder at Google to Senior Staff Engineer. Heβs going to share the mindset shift required to get to the Senior level and beyond.
I hope you enjoy π
Addy Osmani, Head of Chrome DevX and author of the Elevate newsletter
We all start out writing code, fixing bugs, and shipping features as junior engineers fueled by passion. But eventually, many of us feel a calling to transition into broader strategic leadership roles overseeing teams and solving higher-order business problems.Β
This progression requires fundamental mindset shifts that can be challenging without the right frameworks. In this guest piece, Iβll share more detailed practical advice, real-world examples, and actionable insights to help unlock your leadership potential as you navigate to senior levels. Iβll also include anonymous soundbites from engineers I spoke to about this topic.
βThe best senior engineers realize that their key role is not just individual contribution. It is empowering teams through technical vision and context to unlock autonomous passion towards collective goals.β
From Hands-On Work to Systems Thinking
Early on as an engineer, you likely spend most of your time heads-down architecting features, reviewing code, bug fixing, and technically executing. Your work satisfies tangible near-term demands like shipping the next release.Β
As you grow as a leader, more of your contributions come through intangible influence, vision, and enabling teams. Rather than building features yourself, you strategically rally groups towards common goals months or years out.Β Β
This means elevating your vantage point from narrow tactical details to broader ecosystems and outcomes. Trading hands-on coding for systems thinking about cross-functional interdependencies, timeline tradeoffs, resourcing constraints, UX implications, and financial returns.Β Β Β
βWhen I advanced from mid-level engineer to staff-plus roles like architect and principal engineer, I could no longer just focus on tickets in front of me. I had to elevate my perspective to systems thinking, considering cross-functional tradeoffs and long term objectives. While I still loved coding, I learned my influence came through enabling teams more strategically vs doing the work myself.β
This mental leap doesnβt mean discarding your technical experience. Leverage your engineering empathy to deeply understand the problems teams tackle.
Resist swooping in to solve issues directly, even if faster in the short term.
Instead, structure processes and remove systemic barriers for groups to solve challenges themselves in sustainable ways.
βAs a new startup CTO, I still loved coding and could crank through tasks much quicker than junior developers. But I soon realized doing so disempowered them long-term. So I focused on architecting the broader systems and platform to help the team deliver faster as a whole.β
Trust teams to implement tactical details tailored to their strengths while you maintain perspective on the horizon destination. Define guardrails but give freedom to steer exact solutions. This fosters intrinsic motivation through purpose and mastery over prescribed rules and micromanagement.Β
For example, my team was tasked with improving Chrome's real-world page load times and Core Web Vitals metrics. Rather than hand down specific technical mandates (when I may have had opinions), I outlined the performance guardrails we needed to hit and solicited proposals from the team on where browser bottlenecks could be reduced.
Ultimately, the team rallied behind prioritizing key resources (like hero images) and prefetching to optimize page loading sequences. By empowering the engineers closest to Chrome's internals to take creative ownership exploring tactical alternatives fitting their expertise, they uncovered novel optimizations leading to significant impact for users. I of course provided feedback where I felt it could help along the way.
This reinforced why, even when you have strong technical opinions, facilitating authentic debate and freedom aligned to strategic goals allows teams to produce solutions tailored to their complementary strengths.
Influence > AuthorityΒ Β Β
As senior engineers have less direct control and hands-on work, leadership comes through influence rather than pure authority. This means you need to:Β Β
Establish context around customer needs, market dynamics, and business outcomes technical work aims to satisfy
Set the product and technical vision but empower teams to determine the βhowβΒ Β
Proactively remove roadblocks and secure resources needed for project success
Frequently collect candid feedback to gauge alignment and improveΒ
You cultivate influence by building trusted relationships. Guide the mission but let cross-functional partners chart tactical details. Despite less hands-on control, you can shape outcomes by aligning and motivating everyone toward a shared purpose.
βAs I moved into senior roles, I continued focusing too much on exactly how work got done rather than why it mattered. I gave lots of feedback perceived as micromanaging which strained relationships and trust. Over time I learned to emphasize purpose, user value and culture - engaging teams as partners vs just resources.βΒ
For example, early as a tech lead, I once took over an important middleware migration project from another team. In an attempt to accelerate their progress, I dove into the code and refactored major components myself. While the developers appreciated my help at first, this quickly made them feel disempowered and resentful. They felt I implied they weren't capable technically. By taking over tactical execution, I failed to empower the team towards ownership and problem-solving.
This experience taught me that my code-level contributions often weren't the best use of my time strategically, despite good intentions.
Now, I focus my influence on aligning teams to priorities and arming them with the context, resources, and support to discover creative solutions themselves.
Even if at times slower, this builds more sustainable autonomy, engagement, and a growth mindset.
Set your teams up for autonomy by framing problems effectively:
Start with the βwhyβ: Here is the customer need weβre addressing, the market gap weβre filling, the business objective weβre pursuing - and why it matters.Β Β Β
Outline high-level requirements and outcomes: These guardrails define what success looks like while giving flexibility on how we get there based on your creative ideas.Β Β
Describe non-goals openly: Often itβs just as important to clarify whatβs explicitly not in scope, as teams self-organize execution.Β Β Β Β
Address questions & concerns: Get all issues out on the table to maximize understanding rather than assuming it.Β Β Β Β
In contrast, as a senior engineer, you should collaborate closely with teams on technical approaches while maintaining perspective on the broader objective. Leverage your expertise to outline the pros and cons of "how" alternatives. Help teams fall into "a pit of success" with validated best practices. But leave room for groups to customize tactics based on their strengths.
βMy approach with new projects evolved from handing fully fleshed out specs to teams as assignments towards a product kickoff workshop. We whiteboard priorities together, teams call out risks, complexity and non-goals upfront. We align on autonomy norms before anyone writes code.βΒ
Developing Critical Leadership Skills
The shift into senior engineering also requires building new capabilities like:Β Β
Empathy & Emotional Intelligence (EQ): Sense how messages and actions land with teams. Address tensions quickly before they compound. Understand intrinsic motivations and self-perceived worth of partners beyond work.Β Β Β
Communication: Distill complex concepts into compelling narratives and memorable simplification your audience connects with and acts upon.Β Β
Collaboration: Influence stakeholders without authority through trusted relationships. Resolve conflicts and facilitate cross-functional collaboration.
Systems Thinking: Understand cross-functional interdependencies. Evaluate engineering tradeoffs more holisticallyβweighing business objectives, timelines, resourcing, UX, returns, and opportunity costs. Consider 2nd/3rd order effects.Β
Execution Orchestration: Maintain alignment across groups through a clear understanding of priorities as circumstances evolve. Rally people around a north star while adapting tactical plans.Β Β Β
Here are 3 ways you can build these skills:
Audit meetings afterward against core competencies
Request 360 feedback grounded in perceived impactΒ
Establish mentor relationships focused on growth areas as you learn new capabilities building upon your technical foundation (Check out Jordanβs article on utilizing your mentor effectively)
βI realized persuading executive stakeholders on technical priorities took different skills than heads down coding. So I sought opportunities to present architecture recommendations, even when not required, to practice crisp communication. It helped me develop confidence translating technology implications to business value drivers.βΒ
Common PitfallsΒ Β
Despite best intentions, even seasoned engineering leaders commonly struggle with two primary pitfalls:Β Β
Pitfall 1: Losing the Tree View for the LeavesΒ Β
By nature, most engineers prefer concrete details over fuzzy uncertainty. So when issues emerge in projects, thereβs a temptation to get hands-on fixing things or closely managing the work. But this squeezes out time for long-term thinking and tends towards tactical whack-a-mole. It also reduces autonomy for teams to self-organize based on a galvanized vision.Β Β Β
βI repeatedly noticed myself neglecting important strategic areas like proposing R&D innovation pilots, employee growth planning, and refining technical roadmaps once projects were underway. I got lost in status updates versus thinking ahead.βΒ
I mitigate reactive tendencies by ruthlessly prioritizing my calendar. Every Monday, I block out 1-2 hour blocks for strategic thinking and planning. I treat this calendar space as sacrosanct, declining reactive meetings proposed during those times. This ensures I zoom out to assess key milestones and roadmaps, even when pulled into daily fires across multiple projects. By scaffolding dedicated time for long-term focus, I circumvent getting lost in the weeds.
Create forcing functions to ensure you periodically zoom out for strategic thinking, like scheduling regular working sessions protected from reactive firefighting.
Skip-level 1:1 meetings help me tune into the challenges teams are facing firsthand. This informs how I can then work with principal engineers and managers to unblock any constraints holding their reports and teams back.
Pitfall 2: Solving through ControllingΒ Β
When teams face obstacles, stressful scenarios, or confront uncertainty, leaders often revert to wrestling tighter control of the work through rigid check-ins, approvals, and oversight. But this excessive prescription erodes morale, signals a lack of trust, and hampers creativity needed to navigate ambiguity.Β Β
βI tended to tighten the reins through detailed specification documents anytime major launches approached or Anxiously mandated strict update meetings constantly checking work was 'on track'. My intensity stressed people rather than inspiring the best work and problem solving.βΒ
Counterbalance anxiety through compassion and psychological safety. Focus on emphasizing the connection of their efforts to meaningful outcomes.
Overcoming Anxiety and Self-DoubtΒ Β Β
In tandem with the logical shifts required in mindset and skills, transitioning into senior engineering can spur emotional self-doubt too:Β Β Β
Imposter Syndrome: Secretly feeling you donβt deserve your leadership role and fear of being deemed underqualified despite consistently delivering results.Β Β
Loss of Technical Identity: Less hands-on engineering work overtime dampening your self-concept previously tied closely to specific technical abilities and activities vs leadership of technology impact.Β Β
Weight of Responsibility: The pressure to get major decisions right for the business and customers while navigating uncertainty.Β Β
Stay centered by connecting with mentors who faced similar transitions to maintain perspective.
Remember, leadership is earned through consistent impact, not perfection.Β Β Β
Focus your purpose not on chasing position and prestige, but on progress toward solving meaningful problems. Celebrate group wins openly while normalizing periodic stumbles.Β Β
βWhen anxiety crept up, I talked myself through key milestones Iβd led successfully in the past grounded in my experience. I focused on the user impact at stake more than status, remembering no one person had all the answers.β
And embrace self-compassion. Leadership includes steep learning curves. Grant patience toward yourself similar to how you would compassionately coach rising leaders also stretching into new roles.Β Β
In Closing
The journey to senior engineer requires non-trivial mental model shifts. Aim to:
Adopt strategic thinking while empowering groups to handle tactical details
Develop new skills like communication, emotional intelligence, systems thinking, execution orchestration, and complex collaboration
Overcome self-doubt by grounding yourself in purpose, perspective, and supportive relationships
By intentionally and gradually incorporating these senior leadership behaviors, youβll grow the capacity to profoundly shape technology and business outcomes for the better.
Our industry needs more wise, compassionate technical leaders.
Are you ready to increase your positive influence through this growth journey?
Jordan here again π
Thank you, Addy, for such an insightful article π.
Some personal takeaways for me are:
The closer your thinking is to the higher-level business goals, the more impact and leverage you can achieve.
Influence, like networking, comes from building trusted personal relationships. Those relationships come through through intentional effort and time.
Know your skills gaps and work with your mentor to improve on those. Also, self-reflect after meetings and projects. Write down what you can do better. Then do those next time.
π£ Shout-outs of the week
- by - See how consistent effort can change your life with 1 year of focus.
How to Coach Engineers to Become Great Mentors on
by - Learn how to elevate the engineers on your teamSignposting: How to reduce cognitive load for your reader on
by - Learn how to make your writing clearer
Thank you for your continued support of the newsletter and the growth to 47k+ subscribers π
- Jordan
P.S. If youβre interested, here are a few other things you may be interested in:
Path to Senior Engineer Handbook (7k+ stars)βEverything you need to get to Senior
My LinkedIn: I write daily content to 50k+ engineers. Iβm also ramping on Twitter/X
Newsletter sponsorships: Feel free to reply to this email or check the Sponsorship packages
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like β€οΈ button at the bottom of this email to help support me or share this with a friend. It really helps!
The more you grow, the more you realize that individual contribution is less important! Great article Addy and Jordan!
This is a lot to take in, but the levels above Senior Software Engineer, without a doubt, need far more skills than just being really good at coding and problem-solving.
Thanks for this guest post for both of you! π€