Resilient Management

By Lara Hogan

Finding your bearings as a manager can feel overwhelming-but you don't have to fake it to make it, and you don't have to go it alone. Lara Hogan shares her recipe for supporting and leading a tech team-from developing your mentoring and coaching skills, to getting comfortable with having difficult convers

• Language: English
• Publisher: A Book Apart
• Release date: Jun 11, 2019
• ISBN: 9781952616648

Lara Hogan

Lara Callender Hogan is an author, public speaker, and coach for managers and leaders across the tech industry. As a founder of Wherewithall, Lara and her team run workshops, roundtables, and trainings on core management skills like delivering great feedback and setting clear expectations. Before Wherewithall, Lara spent a decade growing emerging leaders as the VP of Engineering at Kickstarter and an Engineering Director at Etsy. She champions management as a practice, building fast websites, and celebrating your achievements with donuts (and sometimes sushi).

Book preview

Introduction

Along my career path

—from self-taught front-end developer, to manager, to director, to vice president—I’ve learned a ton about the ways that humans interact with each other.

I’ve seen the good: teams who band together to ship incredible user experiences that improve people’s lives, or send a teammate flowers when they need to take time off to care for a loved one.

I’ve seen the bad: teams who blame each other after inadvertently knocking over a site, or moan endlessly about having to move their desks to another part of the floor.

And I’ve seen the ugly: layoffs, lawsuits, and internal company crises that create upheaval and strife across the team.

We might bump elbows or mess something up or miscommunicate, but being a part of a team means we’re also so much more than the sum of our parts. Whether in teams of two, twenty, or two hundred, it’s a privilege to work with others toward a united goal.

It’s even more of a privilege to manage or lead them. But with that responsibility often comes exhaustion, uncertainty, and fear. This book is here to help you navigate it all: good, bad, and ugly.

What makes a team?

A team is composed of at least two people (but, more typically, a handful of people) who share the same strategic objective. Sometimes they share a manager, and sometimes they have different managers—or no manager! Sometimes teammates all share the same skill set or discipline (like data analysis, or infrastructure reliability) and sometimes the people who make up a team each have a different role (e.g. one product manager, one designer, two engineers, and a tech lead). There’s no right or wrong way to define what makes a team.

Having a shared language about these atomic units is going to be necessary for understanding the rest of this book! For the purpose of consistency, I’ll be referring to the following:

Teammates: a term I’ll use throughout the book as a catchall for the people you’re responsible for as a manager. Often, the people you think of as your teammates have a direct reporting relationship to you; you have the ability to promote them, adjust their compensation, fire them, etc. In some cases, like in a matrix management structure, your direct reports might be scattered across different feature teams, and the folks on your functional or feature team might report to other managers; but at the end of the day you’re still responsible for the environment around them, for giving them feedback, and for verifying that they’re aligned and working toward their team’s goal.

Discipline: the skill set you primarily use at work. This might be as broad as design, or a more specific term like brand design, product design, or design systems. Management is also a discipline, but when I talk about disciplines in this book, I’ll be talking about the function-specific area of the organization you work in.

Functional team: a group of people who work in the same discipline. You can lean on the leaders within your functional team to communicate company vision, business priorities, and high-level strategy to their direct reports. Those reports, meanwhile, provide input, insights, and information to drive the leaders’ strategic thinking. I’ll talk a lot more about communication conduits in Chapter 4.

Feature team: a group of people from different disciplines who work together on a specific feature or product. For example, a Checkout Flow team might have teammates who come from engineering, design, and product management (Fig 0.1); I would expect them to define strategic objectives around how efficiently users can check out on a site or an app, and to work on projects like improving page load time and adding new payment method options.

Figure

Fig 0.1:

A feature team is often made up of individuals from multiple disciplines.

Sometimes, a team might be described as both a functional team and a feature team. A Mobile Platform team, for instance—one created to support other feature teams as they integrate new features across mobile platforms—might be made up of engineers specializing in mobile development, making them a functional team. But since they also help make decisions about new features’ implementations on each platform, and sometimes do the implementation themselves, they would also be a feature team (Fig 0.2).

Figure

Fig 0.2:

Feature teams are sometimes functional teams, as well.

Team structure can get complicated over time as people switch priorities, disciplines, and managers. Each structure has tradeoffs; for example, I typically see smaller startups optimize for ensuring individuals report to the same manager over time—like in matrix management, where a manager might have direct reports spread across feature teams. This structure can cause issues when that manager doesn’t have shared context about all their reports’ projects or priorities, because they’re responsible for a different team’s strategic objectives, and it’s tough to keep all that information in one person’s brain. On the other hand, a structure in which everyone on a team reports to the same manager has challenges, too: reports will have to re-explain their priorities, goals, and career trajectories each time they switch projects or teams and get a new manager.

Organizations will typically switch from one structure to another because it’s time to make various tradeoffs at that stage of growth, or because priorities have shifted. I’ve also seen organizations move from a discipline- or functional-based team model to a distributed model (spreading people with the same function across teams, rather than keeping them centralized) and back again, as the organizational needs change. This ebb and flow of team and organizational structure is normal and healthy. There’s no single right way to do it.

Teams are the atomic units of any organization, regardless of how it’s been organized; each team’s health contributes to the organization’s overall health. As a manager, you must be able to assess and improve your team’s dynamic—from understanding the individuals that make up the team, to defining the team’s operations and strategy, to diagnosing any friction or ambiguity standing between your team and a healthy state.

So before we get started with tactics, let’s check on how your team is doing.

Stages of group development

Think about your team for a moment. How well is it functioning?

Are you currently on a high-performing team, having found your groove and flow state as a group?

Are you on a team that isn’t quite in that magical state of being yet, but it feels like you’re on your way?

Are you feeling some friction—frustration, confusion—with your team?

Or have you just joined a new team, so none of these apply yet?

In 1965, psychology researcher Bruce Tuckman published Tuckman’s stages of group development (http://bkaprt.com/rm/00-01/). These are the four stages a group goes through as it evolves from a bunch of strangers to a unified collective with common goals:

Forming is when the group comes together in its new state. Your team might have a name, and probably has some understanding of its goal, but it’s likely that other processes or patterns still need to be defined or updated.

Storming is where you start to see some friction. It’s startling, because you just experienced the excitement of forming a team! But I promise: storming is a necessary part of these team dynamics. You’ve gotta feel some confusion and clashing to make it to the next stage.

Norming is where things start to iron themselves out. Individuals begin to resolve their differences, and clarity is introduced. You start to find your groove.

Performing is that coveted flow state. You’re effective, you’re communicating well, and you’re shipping.

These stages will repeat throughout the lifecycle of a team, even if you’ve been together for years. When a new person joins, or a manager changes, or the mission changes, these stages of group development can restart with those Forming stage feelings again. And since teams are in a constant state of change—as you hire, as you switch projects, as you develop roadmaps—you have an opportunity to address what’s missing and how your teammates want to grow.

That said, you’ve probably also found yourself floating in a sea of uncertainty that comes with any management or leadership role. New managers in product, design, UX, and engineering organizations rarely receive any training on how to be a manager; your own manager might not have enough time or focus (or training) to support you through the challenges you face as your role and your team evolve. This book can be your guide.

What’s in this book

Whether your title is lead, manager, or something else: if you’re responsible for supporting and leading a team of people, this book is for you.

There are lots of skills needed to lead successful teams. This book