EMPOWERED Review: I Needed This Book 4 Years Ago

I'd been an engineering manager at Uber for a year on a team of 10 when my manager pulled me aside to talk about team structure.

"What do you think about a reorg, where instead of the current full-stack teams, we have a mobile team with 20 engineers and backend teams? It would be so much cleaner. Oh, and you'd head up this new and larger team. Sounds good?"

Who would say no to a bigger team as a manager?

I did.

It felt wrong. Our team owned an experience - by splitting to a mobile team, we'd only own features. I couldn't put it into words at the time - but what my manager was proposing was going from the empowered team model to the feature team model. As the book EMPOWERED by Marty Cagan and Chris Jones will reiterate countless times, a recipe for lower team output - and I could not agree more.

As I read the EMPOWERED, I kept having Deja Vu moments: the authors have encountered exactly the same situations that I went through during the high-growth phases at Uber. My life would have been far easier if I had the vocabulary and case studies that EMPOWERED brought. And I was amazed at how Marty and Chris in the Bay Area came to the same conclusions on team autonomy, ownership, coaching, and other challenges as I did at Uber, in Amsterdam.

Note that none of the below links are affiliate links or sponsored. See my ethics statement on the lack of such links.

A Manual for Silicon Valley-Like Engineering Teams

I've previously written how and why Silicon Valley-like tech companies operate with more autonomy and better results. The book EMPOWERED ends up with the same conclusions but does this with more depth and backing than I have read before.

All topics of the book are actionable to tech leads, engineering managers - and beneficial for engineers to read. The book is an easy read, with 10 sections, and each section split in short, few page chapters. These are the sections of the book:

1. Lessons from top tech companies, the most notable one being what differentiates tech companies from non-tech ones, how top companies trust and empower teams, and what it says when engineers report into a CIO or IT (it typically signals you're not a tech company, and you won't have empowered teams or product-minded engineers)
2. Coaching: this section is written in the context of coaching product managers. However, half this chapter applies to coaching engineering managers - and engineers! Topics like seeking out teaching moments, managing time, effective 1:1s, effective meetings, integrity, or ethics are all relevant topics. Writing down a team narrative is something engineering managers should do with their PMs - it's been a great help for me at Uber. There's a section on coaching tech leads that was unexpectedly thoughtful.
3. Staffing is a practical section walking through responsibilities as a manager from hiring, onboarding, performance reviews, promotions through the difficult task of terminating people on your team. The complete chapter applies not just to product people but also to engineers. I especially agreed with hiring for character, having a "No assholes rule" and looking for people who are clearly not like yourselves.
4. Product vision is a section specific to product leaders - but engineering leaders will take a lot away on what they should expect from a strong product team. At Uber, we did all things described in the chapter: North Star, validation, communicating it, and evangelizing it.
5. Team topology is a must-read part for any engineering leader. How do you organize teams for ownership, autonomy, and alignment? Platform and experience teams are important parts, as are the different strategies to empower each. The part closes with proximity and topology evolution. This was one of my favorite parts of the book.
6. Product strategy goes through pillars of good product strategy and how to build one. Most companies and teams are terrible at doing so - I've been lucky to have worked with product folks at Uber who did all that the book describes from the start. As an engineering leader, you'll want to understand what a decent product strategy looks like, help your product team get this in place, and hold them accountable for the lack of a coherent strategy.
7. Team objectives is a hands-on section that discusses how OKRs can help execute (and when they do not), tweaking team ambition and commitment, and how management should help teams succeed. It's a refreshingly honest take on what makes for good team execution.
8. The case study section is an unusually detailed example of a jobs marketplace tackling its growth problem. The case study follows the structure of the book and puts all the theory in practice.
9. Business collaboration reminds of the importance - and challenge - of working with the other business units outside product and engineering. The CEO will judge product and engineering based on business results - and everything depends on having strong product and engineering leaders who build trust with the rest of the business and also deliver results.
10. Leader profiles are authentic reads between each part, with perspectives from ten different product leaders. I really liked the thought from Judy Gibbons on top-down management: "Marty asked me why I thought so many companies still prefer command-and-control-style leadership versus empowerment. I don't know if it's a preference or even conscious: in many cases, it seems to be the only model the leaders know."

What I Missed from the Book

(Not) talking about tech debt was the most important thing I would have talked about. Tech debt is something product folks need to very aware of, especially at high-growth companies. I felt the authors were a bit hand-wavy on "Keeping the lights on" work, assuming it's just a small thing. My experience says it's not when you're growing very fast. How you handle tech debt can make or break a high-growth company.

The parts that I did not get much value out were the case study - too long for my liking, though product leaders will find it useful - and the last few parts (business collaboration and the final part) seemed to be less focused than the majority of the book.

The book absolutely topped my expectations in how it touched on platform teams, empowering platform teams, and the take on team topology.

Verdict

The book EMPOWERED resonated better with how to run an innovative tech company than most book I have read so far - together with An Elegant Puzzle: systems of engineering management. The reason this was surprising is because EMPOWERED is not an engineering-focused book. However, at companies where engineers are product-minded, engineering managers get exposed to product work: which is what I have been doing for years. So it should be little surprise much of the product thinking will apply to engineering, and engineering management thinking.

The book is very well written and easy to read, with each chapter having a specific takeaway. Though it circles back to the title of the book - empowered teams - it manages to not stay repetitive. The book is deep and rich on specifics, which is less common in the (product) management book genre.

If you want to get an understanding of how and why the likes of Uber, Airbnb, Opendoor, Discord, and other "Silicon Valley-like companies" work the way they do: read this book. If you want to see where the "cutting edge" of product thinking in 2021 is: read this book.

If you're a product or engineering leader in an innovative company, you need to read this book. For engineers: the value is perhaps more questionable. However, if you work at a place with high autonomy, or if you are preparing to become a lead, or a manager, you should read this book.

My only regret? That I did not read this book years ago.

You can get the book here.

Favorite Quotes

On feature teams vs the agency model:

"Feature teams look superficially like a product team. (...) But a feature team is really very similar to an agency model. (...) It should be no surprise that companies that use agencies for design and development have much the same problems as they have with feature teams."

On using the OKR model with feature teams:

"If the company is still using feature teams, as most unfortunately are, then the OKR technique is going to be a cultural mismatch, and almost certainly prove a waste of time and effort. The OKR technique came from companies that had empowered product teams in their DNA. OKRs are first and foremost an empowerment technique."

On delivery teams:

"(Outside empowered product teams and feature teams) there is a third type of technology team, referred to as a delivery team (or "Scrum team" or "dev team"). (...) There is a product owner and some number of engineers. They are purely about output (code and ship). If you're running a process like SAFe, then this is unfortunately you, and truthfully, I have no idea why you would want to read this book, since what I describe here is the polar opposite both philosophically and practically."

On coaching tech leads, and the importance of this:

"I absolutely love coaching teach leads. More often than not, these are the people behind the world's most impressive innovations. (...) Every single minute you invest coaching a tech lead on either customers or business context will be among the best possible uses of your time.

A suprising percentage of the tech leads I've coached have told me that, ultimately, they would like one day to start a company of their own. I strongly encourage this and point out the many successful CEOs in tech who started as engineers. When this is their goal, I often encourage the tech lead to consider the product management role for a year or two. Even if they go back to engineering, this experience is invaluable and positions them much better for a startup co-founder role."

On the secret of Amazon's success that is out in the open, if only companies would have the discipline:

"Speed and scale are weapons, and Amazon has already told everyone its secret (writing out a narrative explaining your argument and recommendation)... if only they have the discipline to implement it."

On platform teams:

"Platform teams provide leverage because they allow for common services to be implemented once but used in many places. (...) In a small company, the platform may be provided by a single platform team. In many of the large, top tech companies, as many as half the product teams are platform teams. Moreover, platform teams reduce the cognitive load for experience teams."

On the lack of product strategy for most companies:

"Remarkably, most product organizations I meet don't even have a product strategy. (...) Seriously, this is really what I see in so many companies I visit. They have product teams that are more accurately feature teams, and they're slaving away - pounding out features all day - but rarely getting closer to their desired outcomes."

On avoiding common objectives, and how it hurts companies:

"Companies that avoid shared or common objectives in the name of autonomy or communication often limit their ability to solve the toughest and most important problems."

Featured Pragmatic Engineer Jobs

1. Full-Stack Engineer at Farmlend. £85-95K + equity. London.
2. Senior Backend Engineer at Farmlend. £85-95K + equity. London.
3. Senior Full Stack Engineer at Perfect Venue. $150-180K + equity. San Francsico or Remote (US).
4. Senior Software Engineer at AI Build. London or Remote (Europe).
5. Senior DevOps Engineerr at AI Build. Remote (US).
6. Full-Stack Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
7. Backend Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
8. Technical Lead - Platform at Vannevar Labs. Remote (US).
9. Senior Software Engineer, Fullstack at Vannevar Labs. Remote (US).
10. Computational Geometry Engineer at AI Build. London or Remote (Europe).
11. Senior QA Engineer at AI Build. London or Remote (Europe).
12. Lead Backend Developer at Cineville. €53-79K + equity. Amsterdam.
13. Senior Software Engineer, Distributed Systems at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
14. Senior Software Engineer, Fullstack at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
15. Principal Engineer at Shoplift. $185-205K. New York.
16. Senior Engineer at Sixfold AI. New York.

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.