Learn 21 proven lessons from Addy Osmani's 14 years at Google. Essential career insights for founders building sustainable companies and scaling teams effect...
21 Lessons From 14 Years at Google: Essential Wisdom for Startup Founders
Introduction
Addy Osmani, a Director at Google Cloud AI with over a decade of impact in Chrome development, recently distilled his 14 years of experience into a powerful article: 『21 Lessons From 14 Years at Google』. What struck me most wasn't the technical depth—it was the profound career wisdom embedded in every lesson.
As a startup founder, you're likely grinding through rapid growth, making tough calls with incomplete information, and questioning whether you're building the right way. Osmani's lessons speak directly to these challenges. These aren't abstract principles; they're hard-won insights from someone who's navigated scaling systems, managing teams, and maintaining sustainability over the long haul.
Osmani, who authored numerous technical books for O'Reilly and has shaped the web development community's direction, shares this wisdom with a humble goal: "I'm sharing these because I myself have benefited immensely from engineers who have similarly shared their experiences. Consider this my attempt to pay that forward."
That sentiment resonates deeply with startup culture—the idea that sustainable success comes from community, learning, and intentional choices, not shortcuts.
Key Insights: The Core Message
- Problems before technology: Build solutions that solve real user problems, not solutions searching for problems to solve
- Alignment beats speed: Most delays stem from team misalignment on direction and priorities, not lack of talent or effort
- Sustainability matters: Career and company longevity requires conscious trade-offs between speed and sanity
- Visibility builds momentum: Great work that's invisible doesn't advance your company or career—make impact tangible
- Network > networking: Genuine relationships outlast jobs and create unexpected opportunities for founders and team members
Principle 1: Start With User Problems, Not Technology
The Trap Most Founders Fall Into
You've just discovered a powerful new technology—maybe it's a cutting-edge framework, AI model, or cloud architecture. Your immediate instinct? Find a way to use it in your product. This is how mediocre features get built.
The Right Approach
Osmani's first lesson reorients your entire product thinking: The best engineers are obsessed with solving user problems.
For your startup, this means reversing the question. Instead of "Where can we use this technology?", ask "What problems are our users actually facing?" This single shift transforms how you build.
Spend time observing real user behavior. Read support tickets obsessively. Talk to customers who churned. Notice the friction points they mention casually—those are often more valuable than formal feature requests.
Here's what happens when you prioritize problems over technology: You discover that elegant solutions are often simpler than anyone predicted. Sometimes the best solution isn't a new feature at all—it's removing complexity or fixing something that's been broken for months but felt "normal" to your team.
Why This Matters for Startups
Your competitive advantage isn't access to the same technology as larger companies—it's your ability to move faster toward solving specific customer pain. When you nail this, your product feels intuitive to your target audience while competitors are still debating architecture.
Principle 2: Collaboration Beats Being Right
The Argument You Can't Win
You've done the research. You understand why your technical approach is superior. You present the data in a meeting, and it's undeniable—you're right.
And yet, the project stalls.
Osmani captures this perfectly: You can win every technical argument and lose the project.
This hits differently for startup founders. You're not just an engineer trying to convince peers; you're trying to align a team of people with different backgrounds, incentives, and pressures around a shared vision. Winning arguments fragments that alignment.
The Mindset Shift
The concept of "holding strong opinions, weakly" sounds contradictory until you understand it: You have conviction about what's right, but you don't attach your identity to being correct in a specific decision made under uncertainty.
This is crucial for startups because:
- Most decisions are reversible. Your stack choice in month two might be wrong by month six, and that's okay.
- Team cohesion is irreversible. Resentment from being continuously overruled silently erodes company culture.
- Context changes. What was right yesterday might be wrong today as you learn more about your market.
Instead of proving you're right, ask: How do we reach the best solution together? This approach builds trust, speeds decision-making, and creates ownership across your team.
Principle 3: Build First, Think Later
The Perfectionism Trap
Your team could spend months designing the perfect architecture, planning every edge case, and creating detailed specifications before writing a single line of production code. You'll feel prepared. You'll feel certain.
Then you'll release and discover that users want something completely different from what you designed.
Osmani's directness here is refreshing: You can edit a bad page, but you can't edit a blank one.
Action Over Perfection
The founder mindset often drives you toward perfection—the right name, the perfect branding, the flawless MVP. But the companies that win are the ones who follow: Build first → Get feedback → Fix → Improve.
Feedback provides exponentially more learning than internal discussions ever will. A rough product in users' hands teaches you more in a week than a perfectly designed product in your head teaches you in a month.
Practical Application for Your Startup
This doesn't mean shipping broken products. It means:
- Release features that solve the core problem, even if they're 70% of what you imagined
- Get real usage data to inform the next 30%
- Iterate based on how users actually behave, not how you predicted they would
The founders who move fastest are the ones comfortable with "good enough now" instead of "perfect later."
Principle 4: Write Code (and Products) for Other People
The Clever Solution That Haunts Your Team
You've written some impressive code—elegant, compact, using advanced patterns. Your team looks at it with a mix of admiration and confusion. Six months later, during a 2am outage, someone has to debug it.
This is where Osmani's perspective cuts through ego: Your code is a strategy memo to strangers who will maintain it at 2am during an outage.
Clarity Is a Professional Skill
Code (and product design) that can be understood instantly by another person—especially when stress is high and time is critical—is what separates professional work from clever work.
For startups, this principle extends beyond code:
- Product UI: Can a new user understand what to do without a tutorial?
- Documentation: Can your team onboard someone in a week instead of a month?
- Architecture: Can someone unfamiliar with your system understand why decisions were made?
Clarity isn't stylistic preference—it's operational risk management. Every time you optimize for cleverness over clarity, you're creating future risk for your company.
Principle 5: New Technology Adoption Is Like Taking on Debt
The Seduction of the Latest Stack
You read about a hot new framework or database, and it promises to solve your scaling challenges elegantly. You want to adopt it immediately.
Osmani reframes this brilliantly: The "best tool for the job" is often the "least-worst tool across many jobs."
Hidden Costs of Tech Adoption
Every new technology you introduce incurs "debt" in the form of:
- Learning costs: Time your team spends understanding it instead of building features
- Recruitment friction: Harder to hire people who know that specific tech
- Operational risk: Less information available online, smaller community, fewer debugging patterns established
For startups with limited resources, this is critical. You need to move fast, and context-switching to learn new tech stacks slows you down.
Strategic Innovation
The lesson isn't "never innovate." It's "innovate only where you're uniquely rewarded."
Use mature, "boring" technology for everything else. Boring has known failure modes, established debugging patterns, and a large talent pool. Save your technical innovation budget for the areas where you're trying to build competitive advantage.
Most successful startups aren't built on the latest tech—they're built with tools that let engineers focus on the business problem, not the tooling.
Principle 6: Your Work Disappears If No One Knows About It
The Invisible High-Performer Problem
You've shipped features that measurably improved user experience. You've reduced latency by 40%. You've mentored three junior engineers who are now thriving. And yet, when promotion time comes, you're overlooked.
This happens because: If no one can articulate your impact when you're not in the room, your impact is effectively optional.
Making Your Work Visible
This isn't about self-promotion or ego. It's about ensuring your value actually registers with the people making decisions about your career and your company's future.
For startup founders specifically, this means:
- Share wins transparently: When your team ships something significant, make sure stakeholders understand what changed and why it matters
- Document impact: Tie your work to business metrics. Faster onboarding led to 20% reduction in early churn. Better architecture supports 3x user growth.
- Create artifacts: Blog posts, internal case studies, and documentation aren't just nice-to-have—they're how your work becomes real in the organization's collective memory
The hardest part is that doing this feels self-promotional when it's actually essential communication.
Principle 7: The Best Code Is Code Not Written
The Engineering Paradox
Your instinct as a builder is to build. See a problem? Write code to solve it. But every line of code you write:
- Creates future bugs
- Requires maintenance
- Needs to be understood by someone else later
- Adds cognitive load to your system
Osmani's challenge is simple but profound: Before you build, exhaust the question: "What would happen if we just… didn't?"
Strategic Deletion, Not Just Addition
For startups, this is survival wisdom. You don't have unlimited engineering resources. Every feature you don't build is engineering capacity freed for what matters most.
This plays out in real scenarios:
- That elaborate admin panel? Could you just give a trusted person database access?
- That complex notification system? Could a weekly email digest work?
- That migration tool? Could customers do it manually in batches?
The problem isn't that engineers can't write code—it's that we're so good at it, we forget to question whether we should.
Practical Application
Before approving any new project, mandate this discussion:
- What problem does this solve?
- What happens if we don't solve it?
- Could we solve it with something we already have?
- Is this worth the maintenance burden?
You'll be amazed how many planned projects don't survive this filter.
Principle 8: Bugs Have Users Too
The Uncomfortable Truth at Scale
As your user base grows, something strange happens: people start relying on your bugs. They build workflows around quirks in your system. They depend on edge cases that were never intentional features.
Osmani captures the absurdity: At scale, even your bugs have users.
Compatibility Is a Product
This completely reframes how you think about maintenance work. It's not technical debt to be minimized—it's a product decision with real user impact.
When you deprecate an API, you're not just "cleaning up old code." You're asking users to change how they work. That's a product decision that deserves the same rigor as shipping a new feature.
For startups scaling from dozens to thousands of users, this becomes real quickly. You can't treat backward compatibility as "technical work" separate from "real work." It is real work.
Why It Matters
The teams that scale successfully are the ones that treat compatibility as a feature, not a burden. They:
- Document what will and won't change
- Provide migration paths for breaking changes
- Count compatibility as a product deliverable
Most API design is actually API deprecation. Get this right, and your users trust you even through changes. Get it wrong, and frustrated users churn.
Principle 9: Slowness Is Usually Misalignment
Why Your Startup Feels Slow
Your team is working hard. People are putting in long hours. And yet, everything takes longer than it should.
The instinct is often to blame: "We need more people" or "We don't have enough talent." But Osmani points to a different root cause: Most slowness is actually alignment failure.
Alignment vs. Headcount
When a team moves slowly, the bottleneck is rarely execution speed. It's usually:
- Unclear direction: People aren't sure what matters most
- Misaligned priorities: Different functions optimizing for different goals
- Undefined interfaces: Teams aren't clear on how their work connects
- Repeated rework: People are solving the same problem in different ways because they didn't know it was being solved elsewhere
A team of 5 aligned people will outship a team of 15 misaligned people, every single time.
The Founder's Leverage Point
Here's the secret: a senior engineer's (or founder's) job isn't primarily to "write code faster." It's to create and maintain clarity about direction, priorities, and how work connects.
Spend less time in the code and more time on:
- Are people crystal clear on what matters and why?
- Do different functions understand how their work affects others?
- Are people encountering surprises about what others are building?
Fixing alignment typically delivers a 2-3x productivity improvement. Hiring another person usually doesn't.
Principle 10: Focus on What You Can Control
The Energy Drain of What You Can't Change
There are countless forces outside your control: Market downturns. Regulatory changes. Larger competitors entering your space. Organizational restructuring. Management decisions you disagree with.
It's easy to spend enormous mental energy worrying about these things. Osmani's principle is stark: Energy spent on what you can't change is energy stolen from what you can.
Strategic Acceptance
This isn't passive acceptance or fatalism. It's strategic focus on the input factors you control.
You can't control whether a funding market crashes. You can control:
- The quality of work you do this week
- How you respond when plans change
- What you learn from setbacks
- How your team feels about their work
- The decisions you make with the information you have
For startup founders, this is especially critical. You'll face unexpected headwinds constantly—investor feedback, competitive pressure, team departures. The founders who stay sane are the ones who distinguish between "things I must influence" and "things I must accept and move forward despite."
The Sanity Dividend
Focusing on what you control isn't just philosophically sound—it's practically effective. It keeps your energy directed toward decisions that matter, instead of spiraling on things outside your influence.
Principle 11: Abstractions Hide Complexity Until They Don't
The False Comfort of Abstraction
Using a library or framework? It abstracts away complexity, which feels like it's gone. But complexity doesn't disappear—it just hides until the day something breaks.
Osmani's warning is specific: Abstractions don't eliminate complexity. They merely shift it to the day you're on call.
Understanding the Layers Below
As your startup scales and the tech stack grows taller, there's pressure to stay focused on the high level. But the engineers who survive 3am outages are the ones who understand what's happening underneath their abstractions.
This doesn't mean diving deep into everything—that's not practical. But for your core systems (authentication, payments, data integrity), understanding how the abstraction works matters.
Practical Application
- Pick 2-3 critical systems where you maintain "layer knowledge"
- For everything else, reasonable abstraction is fine
- When hiring senior engineers, look for people who still care about "low-level" understanding even as systems get complex
- When debugging production issues, allocate time for understanding root causes, not just patching symptoms
The strongest teams have at least a few people who can trace a system from the highest API call down to the database level.
Principle 12: Teaching Others Deepens Your Own Understanding
The Multiplication Effect of Knowledge
You think you understand something until you try to explain it to someone else. Suddenly, you find gaps, vague assumptions, and places where your mental model breaks down.
Osmani captures this perfectly: Teaching is debugging your own mental model.
Output as Input
One of the highest-ROI activities a founder or senior person can do is create teaching artifacts:
- Blog posts explaining how your system works
- Documentation that walks through decision-making
- Mentoring sessions where you work through problems with others
- Internal talks about lessons you've learned
This serves multiple purposes:
- Deepens your own understanding through the process of explaining
- Creates organizational memory that survives individual departures
- Builds your personal brand (crucial for attracting talent and future opportunities)
- Multiplies your impact through people you've taught
Why This Matters for Startups
As you grow, your time becomes your bottleneck. But when you teach—whether through documentation, talks, or mentoring—you multiply your leverage. One good internal presentation on your architecture decisions scales across your entire team.
Principle 13: Invisible Work Doesn't Count in Your Career
The Unvalued Labor
Documentation maintenance. New hire onboarding. Cross-team coordination. Mentoring. Code reviews that take your time but aren't "shipped work." These are indispensable to a healthy organization, but they're often invisible to people making career decisions.
The hard truth: Being valuable and invisible is a dangerous combination for your career.
Making Behind-the-Scenes Work Visible
This isn't cynicism. It's recognizing that if your contributions can't be articulated in a meeting where you're not present, they won't advance your career trajectory or your company's understanding of your value.
Strategies for Visibility
- Create deliverables: Transform ad-hoc help into templates, checklists, or documentation
- Measure impact: When you improve onboarding, quantify it. "Reduced new hire ramp-up time from 8 weeks to 4 weeks"
- Timebound it: Don't let invisible work become your default mode. If you spend 20% of time on mentoring, make that explicit
- Rotate it: Don't let one person become the bottleneck for all behind-the-scenes work
- Document it: Keep a running list of projects you've contributed to, even if you weren't the primary owner
For founders, this principle extends to your team. Make sure systems-level contributions are recognized and valued as highly as individual projects. Otherwise, you'll lose your most conscientious people to burnout.
Principle 14: Continuous Winning Creates Hidden Resentment
The Cost of Always Being Right
You've developed a reputation for being technically correct. You win arguments consistently. People have learned not to push back because they'll lose anyway.
But something's shifting beneath the surface: People stop arguing not because they're convinced, but because they've given up.
The Resentment That Doesn't Show in Meetings
Dissatisfaction from repeatedly being overruled doesn't manifest as objections in meetings. It shows up as:
- Slower than necessary execution
- Passive resistance to your decisions
- People checking out and doing minimal work
- Good people leaving the organization
- Decisions getting implemented differently than you specified because people feel unmotivated
Osmani notes: The short-term feeling of being right is far less valuable than the long-term reality of building things with motivated collaborators.
Rebuilding Trust
If you've been winning arguments consistently, consider:
- Explicitly asking people for pushback: "What am I missing here?"
- Changing your decision based on input, even when you disagree
- Acknowledging when someone had a valid point, even if the outcome was right
- Creating space where it's safe to disagree with you
The smartest leaders spend less time being right and more time being trusted.
Principle 15: Metrics Shape Behavior in Dangerous Ways
The Measure Creates the Problem
You implement metrics to track progress: lines of code shipped. Velocity estimates. Feature count. Suddenly, you notice:
- Code is growing in complexity unnecessarily
- Estimates inflate to make velocity numbers look better
- Teams are optimizing for metrics instead of outcomes
Osmani's insight is profound: People optimize what is measured. Chasing a single metric will always lead to distortion.
Measurement Strategy
Instead of tracking one metric, always measure in pairs—one for speed, one for quality or sustainability.
Examples:
- Features shipped paired with ** bugs reported per feature**
- Velocity paired with ** code review cycle time** (to catch rushing)
- Customer growth paired with ** churn rate** (unsustainable growth is worse than slow growth)
- Response time paired with ** error rate** (fast but broken is worthless)
For Startup Founders
Avoid the metric trap by:
- Questioning any single metric request with: "What else should we track alongside this?"
- Interpreting trends instead of hitting targets. Targets create gaming incentives.
- Rotating metrics quarterly. What matters to measure changes as your company evolves.
- Making metrics transparent but not public. Publicizing metrics invites distortion.
The goal is insight, not surveillance. Use metrics to understand reality, not to enforce behavior.
Principle 16: Leaders Who Admit Uncertainty Create Psychological Safety
The Permission to Not Know
If you're the smartest person in the room and you act like it, juniors will never ask questions. They'll assume everyone else understands. They'll stay quiet instead of raising concerns. They'll assume it's their job to figure it out alone.
Osmani identifies the antidote: When a leader admits uncertainty, it signals that it's safe for others to do the same.
Creating a Learning Culture
The teams that win are the ones where:
- Senior people can say "I don't know, let's figure this out together"
- Juniors ask clarifying questions without fear
- Assumptions are challenged openly
- People bring problems early instead of hoping they'll resolve themselves
For Founders
This is especially critical early on. You need your team bringing you information, not hiding problems. You want them thinking critically, not just executing your vision.
Model this by:
- Openly discussing decisions you're unsure about
- Asking questions about work you could just review
- Changing your mind based on new information and explaining why
- Thanking people when they catch something you missed
The "I don't know" permission you grant creates exponentially more value than any single piece of knowledge you possess.
Principle 17: Your Network Outlasts Your Job
The Long Game of Relationships
Early in your career, it's easy to focus entirely on your current role. Head down, executing, proving yourself. Networking feels optional or even disingenuous.
But Osmani points to a different timeline: Your job isn't forever, but your network is.
Why This Matters
The colleagues you build genuine relationships with become:
- Your first call when an opportunity emerges
- Your advisors when you're facing challenges
- Your bridge into new companies or ventures
- Your collaborators in future projects
Strategic Relationship Building
This isn't about collecting LinkedIn connections. It's about investing in relationships out of curiosity and sincerity, not calculation.
For founders specifically:
- Your early team members might be your future co-founders or board advisors
- Your customer interactions might become business partnerships
- Your competitive peers might become collaborators
- Your mentors and mentees create a network that spans decades
The most successful founders have networks built over years of intentional relationship investment, not transactional networking events.
Time Horizon
Think in terms of 5-10 year relationships, not 5-week projects. The person you help today might be in a position to help you (or your company) in a critical way five years from now.
Principle 18: Speed Comes From Elimination, Not Optimization
The Scaling Paradox
Your system is slow. Your instinct is to make it faster: add caches, parallelize, optimize database queries.
But Osmani reveals the true bottleneck: The fastest code is code that isn't run.
Elimination Before Optimization
When you want to speed up a slow process, the most effective approach is often to ask: "Is this process even necessary in the first place?"
Examples:
- That approval workflow that adds days to launch? Can it be async or removed?
- That data processing job running nightly? Can you calculate it on-demand instead?
- That feature you built last year? Do enough users actually use it?
- That manual process everyone thinks is necessary? Has anyone actually tried eliminating it?
Application for Startups
Before your engineering team spends weeks optimizing performance, ask:
- Do we need to do this at all?
- Do we need to do this as frequently?
- Do we need to do this for all users or just a subset?
Eliminating unnecessary work almost always has greater impact than making necessary work faster.
This is where startups have a massive advantage over large companies: you can eliminate processes and features that have become "the way we do things." Large companies are trapped by organizational debt.
Principle 19: Processes Should Reduce Uncertainty, Not Provide Comfort
The Bureaucracy Trap
You've implemented a new approval process "just in case." A code review requirement "for safety." A status reporting format "to keep everyone aligned."
Before you know it, these processes that were supposed to help are now slowing down the team: If you can't explain how a process reduces risk or increases clarity, it's probably just overhead.
Auditing Your Processes
For each process in your startup, ask:
- What specific risk does this reduce?
- How would we know if it's working?
- What would happen if we eliminated it?
- Is there a lighter-weight way to achieve the same goal?
Healthy vs. Unhealthy Processes
Healthy processes:
- Make adjustments easy and failures cheap
- Create clarity about how decisions happen
- Surface information early when you can still act
- Scale with the team instead of becoming the team's bottleneck
Unhealthy processes:
- Exist to assign blame when things go wrong
- Create the illusion of control instead of actual control
- Slow down every decision, not just risky ones
- Are rarely questioned once established
For Startup Growth
As you scale, you'll feel pressure to "add process." Resist this unless you can articulate what uncertainty you're reducing. The best processes in fast-moving companies are lightweight—they create just enough structure to prevent chaos without becoming bureaucratic.
Principle 20: Time Becomes More Valuable Than Money
The Career Arithmetic
Early in your career, the trade-off is clear: trade your time for money. Extra hours for bonus. Career sacrifice for promotion.
But at some point—sometimes suddenly—the equation inverts: Know what you're trading, and make the trade deliberately.
The Regret Pattern
Osmani observes a pattern: seniors who burned themselves out chasing promotions often ask in retrospect: "Was it actually worth it?"
The time you spent working 60-hour weeks is gone. The relationships you missed building because you were overworked don't come back. The skills you didn't learn because you were too focused on short-term delivery are harder to acquire later.
Conscious Choice
The point isn't "don't work hard." It's "understand what you're trading, and choose it consciously."
For founders especially, this is critical. There's tremendous pressure to sacrifice everything for the company. But sustainable success requires you to stay healthy, maintain relationships, and avoid burnout.
Questions to ask yourself:
- What am I giving up for this goal?
- Will I regret this trade-off in 5 years?
- Is there a way to achieve the goal that costs less in time?
- What would "enough" look like?
Time is the one truly non-renewable resource.
Principle 21: Compound Interest Beats Lottery Tickets
The Patient Builder
Osmani's final lesson cuts against startup culture's obsession with overnight success and lightning-strike moments: The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
Daily Compounding vs. Waiting for Big Wins
The approach that works:
- Learn a bit every day
- Build reusable systems, not one-off solutions
- Write clearly (for your future self and others)
- Collect failures into playbooks
- Create artifacts (documentation, code, ideas) that retain value
Over years, these small deposits compound dramatically. You develop judgment, patterns, and leverage that lucky people never achieve.
For Startup Founders
The companies that win aren't the ones betting on a single feature or market shift. They're the ones:
- Consistently shipping and learning
- Building systems that compound in value
- Creating culture and processes that improve over time
- Maintaining the health and learning of their team
Compounding requires patience. You won't see the impact of good documentation for six months. The junior person you mentored extensively won't show their impact for a year. But by year three, these compounding investments create enormous leverage.
The Unsexy Path
This path is less exciting than dramatic pivots or viral moments. It's:
- Writing documentation that gets better
- Hiring slowly, well, and building a strong culture
- Improving processes incrementally
- Learning from failures and building playbooks
But it's the path that creates sustainable businesses. It's the path that keeps founders from burning out. It's the path that outlasts competitive ups and downs.
Conclusion
Addy Osmani's 21 lessons distill into a powerful philosophy that directly addresses the challenges startup founders face daily:
Stay curious — Never stop learning from users, your team, and your failures.
Stay humble — Be willing to say "I don't know" and collaborate toward solutions rather than defending being right.
Don't forget people — Build for your users with genuine empathy, and build with your team by creating psychological safety and clarity.
The engineers and founders that Osmani admires most "aren't the ones who got everything right—they're the ones who learned from what went wrong, shared what they discovered, and kept showing up."
In the relentless pace of startup growth, these lessons serve as a reminder: sustainable success isn't about brilliant moves or lucky breaks. It's about making conscious choices about what matters, building clear communication with your team, and creating systems that compound in value over time.
The most important insight for founders might be this: The way you work now creates the culture, patterns, and health of your organization later. If you're constantly chasing speed, you'll build a team that burns out. If you're constantly proving you're right, you'll build a team that hides problems. If you're constantly writing clever code, you'll build systems nobody can maintain.
But if you're consciously building with clarity, collaborating with humility, and thinking in terms of long-term compounding, you're creating a company that can scale sustainably—one that your team actually wants to be part of, and one that wins not through luck, but through accumulated advantage.
Start implementing even one of these principles in your startup this week. Notice the difference it creates in how your team works, how decisions get made, and how you feel about the work itself.
Reference
Original source: 21 Lessons From 14 Years at Google - Addy Osmani
This article is an interpretation and expansion of the original work. For the full original insights and specific examples, refer directly to Osmani's article.
Original source: 「Googleでの14年間で学んだ21の教訓」を 個人的な解釈でまとめてみた - Qiita
powered by osmu.app