Empowered

Back in the day, I once attended a big software conference somewhere in Germany. As chance would have it, I struck up a conversation there with an agile coach who was working for a big customer of the product that I was serving for as Product Owner at the. During the course of the event, we would occasionally bump into each other again and chat about our respective challenges: Me, shepherding a medium-sized product team at an international software conglomerate, and him leading the agile transformation of one of the most stereotypically conservative organizations in the world: The federal government of Germany.

Many of the problems he had to face immediately resonated with me, albeit in his circumstances they were turned up to eleven. For example, the locations of government offices in Germany are scattered throughout the country, often placing them hundreds of kilometers away from flashy tech-hubs such as Berlin or Munich—as well as their respective talent pools. Furthermore, the government is bound to a strictly defined payment scheme which makes it impossible to attract rock-star developers with the otherworldly salaries some VC-backed startups can offer. Hence, many members of his teams were career changers in their 40s and 50s or fresh graduates without much hands-on experience.

And yet—contrary to popular belief—what they needed to accomplish was by no means an easy feat: To this day, they build and maintain highly scalable software systems that enable thousands of government officials to manage sensitive data of more than 80 million citizens—whilst never ending change in the legal, social, and economic environment necessitates speed and agility. My conversations with this coach therefore helped me put my own problems into perspective, but they also made me realize a profound truth about the tech industry: Most teams in most organizations aren’t made up of the superstars you’d find at Google or Microsoft, and yet those teams are perfectly capable of delivering outstanding results—if they’re set up in a way that allows them to live up to their full potential.

That being said, take a second to appreciate the subtitle of EMPOWERED, Mary Cagan’s new book:

Ordinary People, Extraordinary Products

Empowered is the much anticipated successor to Cagan’s 2008 INSPIRED, which I highly recommend to anyone who’s even remotely connected with designing or building any kind of tech-powered solution. But where Inspired puts most of its emphasis on the ins and outs of creating great products, Empowered moves one step up and discusses how to build an organizational environment in which teams can thrive. So, how exactly do you do craft such an environment, in a nutshell?

The approach that the German government’s agile coach applied was manifold, of course. But two central pillars of his strategy were empowerment—emphasizing autonomy, trust, ownership of outcomes, and so forth—and the fact that their teams were given problems to solve, not just a list of features to build. As it turns out, those are also Cagan’s key points in Empowered.

The hardcover edition of the book details what exactly that means on more than 400 pages—a fact that might slightly intimidate the casual reader at a first glance. But fear not, each of the 81 chapters spans a couple of pages at most, making for a quick and varied reading experience. Furthermore, Cagan sprinkles the content with profiles of outstanding product leaders as well as anecdotes of how they solved some of their toughest challenges. Like he already did in Inspired, he chose only to include female leaders though, which I find an admirable, yet subtle, contribution to the fight against the prevalent “white male nerd” stereotype in tech. Kudos!

Part I: Lessons from top tech companies

To my surprise, the first few chapters were quite far off from what comes to my mind when I think of (software) product companies. Instead, Cagan begins by attempting to bridge the gap between traditional organizations in industries other than software—organizations in which “IT” is often still perceived as a cost-factor, rather than the heart and soul of what they do—and what he refers to as great product companies, among which he counts Amazon, Google, Apple, and Netflix. Not only are the cultural differences huge of course, but also the managerial mindset is also in no way comparable—one would assume. And yet, Cagan argues, when those companies begin to shift how they view the role of technology, start fostering a strong product-focused culture, and ultimately empower their teams, they can transform entire industries.

Part II: Coaching

After this very broad introduction, Cagan hones in on how one would actually go about building that strong product culture. At this point, he turns down much of the initial emphasis he put on the challenges he sees with traditional organizations, thus making everything that follows easily accessible for pure-play software companies as well.

Keep in mind that this is a book written mostly for the managers of the individuals who constitute cross-functional product teams—people who have disciplinary responsibility for Product Managers, UI/UX-Designers, Software Developers, Architects, Product Marketers or Data Scientists. They, he argues have one job, and one job only: Developing the people who report to them, so that the product teams themselves can work on solving problems for their customers.

Cagan draws an important distinction here between management and leadership which at a first glance one could read as yet another proclamation of the “end of management”. After all, who needs all those hierarchies anymore when the core of the organization is the empowered, cross-functional product team, right? Wrong, Cagan says. To put it in his own words:

Empowering means creating an environment where your people can own outcomes and not just tasks. This doesn’t mean less management—it means better management.

At the heart of that better management approach, in Cagan’s view, lies coaching: The act of helping others to become more skilled at what they do—be that by sharing experience and insight, acting as a sparring-partner, or more generally providing them with the necessary tools to improve and grow in their respective roles. This, Cagan argues, should take up most of a managers time, and this explains why traditional, functional line management still is an absolute must-have even in organizations that fully embrace the concept of cross-functional product teams. After all, who could provide better coaching for Product Managers than an experienced Head of Product Management, who could better enable a team of junior UI/UX Designers than a battle-hardened VP of Design, and so forth.

Incidentally, taking that stance also answers a question that comes up time and time again in organizational design: How many direct reports should a manager have? According to Cagan, the answer is quite simple: Not more than they can seriously provide high-quality coaching for.

Part III: Staffing

In Part II, Cagan not only outlines the need for coaching as a cornerstone of empowering cross-functional product teams, he also goes into the details on what he thinks the individual contributors should actually be coached about, especially those in Product Management roles. Despite that fact that much of what he has to say here was previously stated in Inspired and elsewhere already, his points remain timelessly valuable and make Empowered a great read, also for those of us without managerial responsibilities.

Part III though is more useful for those in management roles: Recruiting, hiring, onboarding, and—if necessary—firing people clearly isn’t useful for everyone right away. Here, Cagan deliberately covers the entire employment lifecycle, again emphasizing the key role that the manager has to play, one which can’t be simply outsourced to an HR department or an external agency.

As I started a new endeavor myself just a few months ago, I couldn’t help contrasting the onboarding process Cagan lays out with what I experienced then. I took some inspiration from Michael D. Watkins The First 90 Days during this time, and together with the excellent process and support provided by my company came very close to the ideal experience that Cagan envisions. As it turns out, the key elements of getting to grips with a new product role are quite universal: Together with your manager, lay out a plan with deliberate checkpoints, aim for a few early wins, focus on learning over doing for at least the first 30-60 days, and try to get exposure to customers as early as possible.

Part IV: Product vision and principles

After Part III, Cagan shifts gears a bit, again reiterating some of the more general points previously made in Inspired. He details what constitutes a strong product vision, how to communicate it in compelling ways, and why it has to be be underpinned by non-negotiable core principles.

Those ideas again are generally useful and their applicability is by no means limited only to managers. He does however point out that as a manager, you can make great use of a compelling vision if you apply it as a recruiting tool: Outstanding product people, he says, don’t sign up just for the paycheck or the benefits package. They join your organization because they actually want to see the future your company is trying to build come true. Therefore, be proud of your product vision and communicate it actively when hiring.

Part V: Team topology

No man is an island, and neither is any empowered product team. Therefore, cross-team collaboration is a critical factor for success at any company once it outgrows the startup stage. Cagan dives into many interesting questions of team topologies here, such as: How should you structure your teams to ensure each one is empowered in its own way? How should such they interface with each other? What does defining, aligning, and measuring goals mean on an organizational, department, and team level?

The author’s views on many of those questions aren’t as radical as it may seem at first, though. And yet, putting them into action can be quite tricky. Whilst he goes into some details here which he underpins also with a semi-fictional case study towards the end of the book, he refers interested readers to Matthew Skelton and Manuel Pais’ much more comprehensive 2019 work Team Topologies—which I summarized here.

Part VI: Product strategy

As he did in Part IV, Cagan sprinkles more practical wisdom about how to actually build great products throughout his otherwise more management-oriented book. Part VI, product strategy, is again perfectly accessible and useful for those individual contributors as well—especially if they happen to be in Product Management roles.

The author again doesn’t refrain from borrowing bits and pieces from Inspired, but also taps into other, more general works on business strategy. In this case, he rephrases some of what Richard Rumelt outlined in his classic Good Strategy / Bad Strategy which he quotes more than once. Here’s my personal favorite:

Not miscalculation, bad strategy is the active avoidance of the hard work of crafting a good strategy. One common reason for choosing avoidance is the pain or difficulty of choice. When leaders are unwilling or unable to make choices among competing values and parties, bad strategy is the consequence.

That focus on focus, the act of deliberately limiting of the number of goals, targets or initiatives an organization pursues at any given point in time, clearly resonates with many readers—myself included. Cagan’s suggestion to limit yourself to 2-3 strategically important endeavors—rather than 20-30 as he states he often finds at the companies he consults—may sound a bit too radical though. On the other hand, how valuable can be 2-3 things executed really, really well as opposed to 20 or 30 jobs done poorly?

To quote Rumelt again:

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.

Complemented by Cagan’s take on product strategy:

If the leaders are not willing or able to make these choices, then the product strategy is doomed from the start.

Part VII: Team objectives

After this excursus on strategy, Cagan takes us back into the realms of organizational design. When it coms to how goals should be set and progress measured, Empowered puts a big emphasis on OKRs (Objectives and Key Results)—but not without a few words of caution. The simplicity of the concept made many organizations embrace it quickly, but not always in the most useful manner, as Cagan points out. Especially since Christina Wodtke’s classic Radical Focus made it sound so simple, some companies jumped on the bandwagon in the overly optimistic hope that this would solve all of their problems all at once, and now having to deal with the realization that, unfortunately, a silver bullet just doesn’t exist.

If, however, OKRs are defined in a stringent way, the organization is focused on a small number of strategically important goals, and the product teams are organized in a way that empowers them, extraordinary results become… at least a lot more likely.

Part IX: Business collaboration

In Part Part VIII, Cagan takes us through a fictional case study based on some of the clients he worked with in his role at SVPG. Step-by-step he outlines how to craft a compelling vision, how that vision translates to strategy and how different teams work together to deliver on that strategy, based don individual yet connected goals reflected by OKRs. Personally, I didn’t find the example he chose very insightful, thus I only skimmed much of the case study.

Nevertheless, the final part—business collaboration—attracted my full attention again. On the one hand, it ties back to the very beginning of the book, and the question of how leaders can transform traditional organizations into tech-powered product companies. On the other hand, it also underpins much of what I believe a good Product Manager should care about: Internal and external evangelism, collecting and sharing knowledge, alignment between and collaboration with stakeholders throughout the entire organization, or, in short: communication.

Summary & opinion

If you read thus far, my opinion of Empowered should have made itself pretty clear: I wholeheartedly recommend that anyone working on a product team, either as an individual contributor or as a manger, should read it. And, while your at it, grab a copy of Inspired as well. The coherence between the two is pretty strong, yet one doesn’t have to consume them strictly in order to derive the most value.

I can’t tell if the agile coach I met back at that conference ever layd eyes on any of Cagan’s books. Should he happen to read Empowered today, though, I’m convinced that he’d judge it to be a pretty good overview of what he had been practicing all along. Nevertheless, he’d probably also find one or two new ideas to take away. In other words: Don’t expect Empowered to bring anything radically new to the table. This book is not the Principles of Scientific Management or the Agile Manifesto, and surely it doesn’t want to be. It is, however, an outstanding summary of the state of the art in product development and can definitely serve as a source of inspiration for many organizations.