Addy Osmani, Director of Google Cloud AI, is an experienced software engineer and thinker who spent nearly 14 years as Head of Developer Experience at Chrome, working on projects such as DevTools, Lighthouse, and Core Web Vitals. Currently, he coordinates work between Google DeepMind, the engineering, product, and developer relations teams.
On the 3rd, he published an in-depth article on his personal blog, sharing his years of experience and professional qualities at Google. He summarized 21 valuable suggestions regarding communication, technology selection, and career planning, which are compiled and edited below:
When I joined Google about 14 years ago, I thought the job was about writing perfect code. I was only partly right. The longer I stayed, the more I realized that the best-performing engineers weren't necessarily the best programmers, but rather those who had learned how to navigate everything outside of code : including interpersonal relationships, workplace politics, consensus alignment, and uncertainty.
These are lessons I wish I had learned sooner. Some saved me months of frustration, while others took me years to truly grasp. None of them are related to any particular technology: technology changes too quickly to matter. They are about patterns that repeatedly appear across different projects and teams.
I'm sharing this because I've benefited greatly from engineers who are willing to mentor younger ones. This is a small token of my gratitude.
1. Top engineers are obsessed with solving user problems.
It's incredibly tempting to fall in love with a technology and search for its applications. I've done it, everyone has. But the engineers who create the greatest value work "in reverse": they're obsessed with deeply understanding user problems and letting solutions emerge naturally from that understanding.
User obsession means spending time studying customer service tickets, talking to users, observing their operational difficulties, and constantly asking "why" until you get to the heart of the matter. Engineers who truly understand the problem often find that elegant solutions are simpler than expected. Engineers who start with solutions often add unnecessary complexity in order to rationalize their solutions.
2. "Proving yourself right" is worthless; the key is to achieve the correct goal together.
You can win every technical debate, but lose the entire project. I've seen brilliant engineers accumulate silent resentment because they always try to be the smartest person in the room. This cost later manifests as "mysterious execution problems" or "unexplained resistance."
Skill lies not in being "correct," but in participating in discussions to align on issues, creating space for others, and maintaining skepticism about one's own certainty. Strong opinions and an open mind —this is not because you lack conviction, but because decisions made in uncertain situations should not be tied to your self-esteem.
3. Action-oriented. Go live! You can fix a broken page, but you can't fix a blank page.
The pursuit of perfection can lead to paralysis. I've seen engineers spend weeks discussing the ideal architecture for something they've never actually built. Perfect solutions rarely stem from pure thought—they arise from a clash with reality. AI can help in many ways.
Do it first, then do it right, and finally do it better. Present the ugly prototype to the users. Write a messy first draft of the design document. Release that slightly embarrassing MVP. You'll learn more from a week of real feedback than from a month of theoretical debate. Drive brings clarity; analytical paralysis leads to nothing.
4. Experience is reflected in clarity, intelligence in taking on responsibilities.
The instinct to write "smart" code is almost universal among engineers; it feels like proof of ability. But software engineering is a chemical reaction produced by "time" plus "other programmers." In this environment, clarity is not a style preference, but rather a way to reduce operational risk .
Your code is a strategic memo written for strangers who might be fixing bugs at 2 a.m. Prioritize their comprehension, not your elegance. The senior engineers I admire most always choose to trade "cleverness" for "clarity."
5. "Novelty" is a high-interest loan borrowed from maintenance, recruitment, and cognitive load.
Think of your technology choices as a limited-budget "innovation token" company. Spend one token every time you adopt a truly non-standard technology. You can't afford to spend too many. The point isn't "never innovate," but " only innovate where you'll get unique rewards ."
Everything else should be assumed to be "boring," because boredom implies that its failure mode is known. The "most suitable tool for the job" is often the "tool that performs the best across multiple jobs" —because running a tech zoo would be a real burden.
6. Code won't speak for you, people will.
Early in my career, I thought excellent work performance would speak for itself. I was wrong. The code sits quietly in the repository. What matters is whether your manager mentions you in meetings and whether your colleagues recommend you for projects.
In large organizations, decisions are made in uninvited meetings, by people with only five minutes to address twelve priorities, based on summaries you haven't written. If no one can articulate your influence when you're not present, then your influence is negligible. This isn't entirely about self-promotion; it's about making the value chain clearly visible to everyone, including yourself .
7. The best code is the line you never write.
Engineering culture celebrates creation. No one gets promoted for deleting code, even though deletion often optimizes the system more than addition. Every line of code you don't write is code you'll never need to debug, maintain, or interpret.
Before building, ask yourself this question thoroughly: " What would happen if we didn't do it at all? " Sometimes the answer is "nothing bad," and that's your solution. The problem isn't that engineers can't write code or can't use AI to write it; it's that we're so good at writing code that we forget to ask "should we write it?"
8. When you reach a large enough scale, even your bugs will have users.
When you have enough users, any observable behavior becomes a dependency—regardless of what you originally promised (Hiram's Law). Someone is scraping your API, automating your quirks, and cached your bugs.
This leads to a professional-level insight: you can't treat compatibility work as "maintenance" and new features as "real work." Compatibility is the product itself. When designing deprecation solutions, treat it as a migration process with time, tools, and empathy. Most "API design" is actually "API retirement."
9. Most "slow" teams are actually "out-of-focus" teams.
When projects stall, the instinct is to blame execution: insufficient manpower, wrong technology choices. Usually, these aren't the core issues. In large companies, teams are your concurrent units, but coordination costs increase exponentially with the number of teams. Most slowdowns are actually alignment failures —people are building the wrong things, or building the right things in incompatible ways. Senior engineers spend more time clarifying direction, interfaces, and priorities than "writing code faster," because that's where the real bottleneck lies.
10. Focus on what you can control, and ignore what you cannot.
In large companies, countless variables are beyond your control—organizational restructuring, management decisions, market changes, product shifts. Dwelling on these only breeds anxiety and is ultimately futile. Rational and efficient engineers focus on their sphere of influence .
You can't control restructuring, but you can control the quality of your work, your reactions, and what you learn. When faced with uncertainty, break down the problem and identify specific actions you can take. This isn't passive acceptance, but strategic focus. The energy spent on things you can't change is stolen from the energy you can change.
11. Abstraction does not eliminate complexity, it merely transfers it.
Every abstraction is a gamble, a gamble that you don't need to understand the underlying principles. Sometimes you win, but abstractions always leak. When it fails, you need to know what's happening at the bottom. Senior engineers continue to learn about the "lower levels" even as their technology stack grows higher and higher. This isn't out of nostalgia, but out of respect for the moments when abstractions fail. Use your toolchain, but master a mental model of its underlying failure modes.
12. Forced writing leads to clarity; teaching is the fastest way to learn.
Writing forces you to think. When I explain a concept to others—whether in documents, speeches, code review comments, or even just chatting with AI—I find gaps in my understanding.
Making content clear to others also makes it clearer to me. This isn't just about generously sharing knowledge; it's a selfish learning technique . If you think you understand something, try explaining it simply. Where you get stuck is where your understanding is shallow. Teaching is about debugging your own mental models.
13. The work that makes other work possible is invaluable, yet also invisible.
"Glue work"—documentation, onboarding, cross-team coordination, process improvement—is crucial. But if you do it unconsciously, it can hinder your technical growth and leave you exhausted. The trap is treating it as "helping out" rather than as a conscious, bounded, and visible contribution . Set time limits, take turns, and translate it into outputs (documents, templates, automation tools).
It should be viewed as an influence, not a personality trait.
14. If you win every argument, you may be building up silent resistance.
I've learned to question my own certainty. When I "win" too easily, something's usually wrong. People stop arguing not because you've convinced them, but because they've given up trying—they express this opposition in execution, not in meetings. True alignment takes much longer.
You must truly understand others' perspectives, incorporate feedback, and sometimes even openly change your mind. The short-term satisfaction of winning an argument is far less valuable than the long-term value of working with truly convinced partners.
15. When a metric becomes a target, it is no longer a good metric.
Every metric you present to management will ultimately be "manipulated." This isn't due to malice, but because humans optimize for what they're measuring (Goodhard's Law). If you track lines of code, you'll get more lines. If you track rate, you'll get inflated estimates.
A seasoned approach: For each metric request, provide a pair of metrics. One for speed, and one for quality or risk. Focus on interpreting trends , not worshipping thresholds. The goal is insight, not surveillance.
16. Admitting "I don't know" creates a greater sense of security than pretending to know.
Senior engineers who say "I don't know" aren't showing weakness; they're creating "permission." When leaders acknowledge uncertainty, it sends a signal that the room is safe for everyone else. I've seen teams where senior staff never admit confusion, and that's incredibly damaging: no one asks questions, no one challenges assumptions, and junior engineers remain silent because they think they're the only ones who don't understand. Demonstrate curiosity, and you'll build a truly learning team.
17. Your network is longer than any job you've ever had.
Early in my career, I focused on work and neglected networking. In hindsight, that was a mistake. Colleagues who invested in relationships (both inside and outside the company) have benefited immensely for decades. They heard about opportunities first, built bridges faster, got job referrals, and started businesses with people they'd built years of trust with. Jobs aren't forever, but networks are. Build relationships with curiosity and generosity, not a transactional mindset.
18. Most performance improvements come from "removing work," not "smart algorithms."
When a system slows down, the instinct is to add: cache layers, parallel processing, smarter algorithms. Sometimes this is correct, but I've seen performance improvements come more often from asking, " What are we computing that we don't need? " Removing unnecessary work is almost always more impactful than doing the necessary work faster. The fastest code is code that never runs.
19. Processes exist to reduce uncertainty, not to create paper records.
The best processes make coordination easier and reduce the cost of failure. The worst processes are "bureaucratic dramas"—they exist not to help, but to deflect blame when things go wrong. If you can't explain how a process reduces risk or increases clarity, it's probably just a burden. If people spend more time documenting than actually doing the work, then there's a big problem.
20. Ultimately, time will be more valuable than money; act accordingly.
Early in your career, trading time for money is fine. But at some point, the calculation reverses. You realize that time is a non-renewable resource. I've seen senior engineers burn out trying to chase the next tier or optimize their pay by a few percentage points. Some get it, but most later wonder if it was worth the price. The answer isn't "don't work hard," but rather " know what you're trading and trade consciously ."
21. There are no shortcuts, but there is the effect of compound interest.
Professional expertise comes from deliberate practice—slightly beyond your current skill set, reflecting, repeating, and continuing for years. There is no abbreviated version. But the hope is that it compoundes when learning creates new options rather than just fragmented knowledge. Write (for clarity), build reusable prototypes, and compile painful lessons into an instruction manual. Engineers who treat their careers as "compound interest" rather than "lottery tickets" tend to go much further.
One last thought
These 21 points may sound like a lot, but the core ideas are actually just a few: stay curious, stay humble, and remember that work is always about people —including the users you build the product for and the teammates who build it with you.
An engineer's career is long enough for you to make many mistakes and still succeed. The engineers I admire most are not those who never make mistakes, but those who learn from their mistakes, share their discoveries, and persevere.
If you're just starting out on this journey, know that it will only get better with time. If you've been working in this field for years, hopefully some of these points will resonate with you.
