I recently shared a short note about a brilliant list of observations from an engineer’s 14 years at Google. It struck a chord with me because it isn’t a manual of clever algorithms — it’s a handbook for the human side of product work: user obsession, alignment, clarity, and the hard art of working with people. If you haven’t read it, start with 21 Lessons from 14 Years at Google — it’s the source for much of what follows.
1. Make user obsession operational — not aspirational
“User obsession” is a phrase that sounds great on a values slide. The difference between rhetoric and results is operationalising it. The original article makes the point plainly: the engineers who create the most value start with a deep understanding of the user problem, not the technology.
Practical steps for leaders:
- Embed engineers in the feedback loop: rotations into support, regular customer interviews, and shared backlog items from real tickets.
- Measure outcomes, not outputs: pair speed metrics with quality or risk indicators so the team doesn’t optimise the wrong thing.
- Treat compatibility as product: design migrations and deprecations with timelines, tooling and empathy.
Amazon’s obsession with the customer is often-cited for a reason: processes, incentives and org design all point to user outcomes. Product leaders should ask: what would change in your team if every decision had to pass a simple customer-impact test?
2. Autonomy with alignment: strong opinions, weakly held
One of the clearest lessons from the Google piece is that technical skill alone won’t carry a project. The engineers who thrive are the ones who navigate people, politics and ambiguity. That requires two things simultaneously: empowered teams and explicit alignment.
How to get there:
- Set clear outcomes, not solution constraints: allow teams to choose implementation but hold them accountable for measurable outcomes.
- Make interfaces contractually clear: for cross-team work, APIs, SLAs and prioritisation rules are the governance that lets autonomy scale.
- Model curiosity: leaders admitting uncertainty make rooms safe for real conversation — it’s how alignment actually surfaces.
Spotify’s and other modern engineering model experiments show the power of small, accountable teams. The trick is to design the rest of the organisation around those teams — support their boundaries with clear incentives and minimal coordination cost.
3. Ship early, prefer clarity to cleverness
The article nails a cultural tension: the seductive pull of the perfect architecture versus the reality of learning through contact with users. “First do it, then do it right, then do it better” is advice every experienced leader should repeat.
Practical guidance:
- Ship a slightly-embarrassing MVP: one week of real feedback obliterates a month of debate.
- Code as a strategy memo: optimise for comprehension — your future on-call colleague is more important than your one-off elegant pattern.
- Use innovation tokens: limit non-standard technology choices so the platform doesn’t become an operational zoo.
Organisations like Netflix and many high-velocity shops have shown how rapid experiments and disciplined rollbacks are a healthier path than endless design theatre. The senior trade-off is obvious: cleverness that makes systems brittle is a strategic cost.
4. Make invisible work visible — and valuable
Glue work — documentation, onboarding, coordination — keeps systems running but is often unpaid in career terms. The Google list warns us about burning out on invisible kindness. The fix is to make that work deliberate and legible.
Ways to do this today:
- Timebox and rotate glue responsibilities: avoid single-person dependencies and keep skills distributed.
- Turn glue into artifacts: docs, templates and automation that reduce future friction.
- Credit it publicly: include maintenance and coordination in performance conversations the same way you include feature delivery.
Stripe’s developer docs are a reminder that clear documentation is both product and competitive advantage. Making work visible changes incentives — and careers.
Where AI fits — an enabler, not a distraction
One quiet thread through the Google lessons is the value of tools to extend human attention — from simple automation to AI. Use AI to reduce menial toil, to prototype faster, and to make writing and explanation cheaper. But don’t outsource judgment. The human coordination problems — alignment, trade-offs, migrations — remain the manager’s domain.
A short list of actions for this quarter
- Run an engineer-on-support week and capture five concrete product changes from it.
- Publish one API deprecation plan with tooling and timelines for a public product.
- Set an innovation-token policy and list current non-standard tech that will be retired.
The original 21 lessons are short, sharp and almost all practical. They remind product leaders that success is rarely about a superior algorithm — it’s about shaping teams, incentives and clarity so teams can learn faster than the competition. If you’re a CEO, CPO or CTO, pick one lesson from that list and force it into your next quarter plan. The payoff is human — less friction, more learning, and products that actually solve people’s problems.
Leave a Reply