Lara Hogan - Resilient Management

Along my career path from self-taught front-end developer, to manager, to director, to vice presidentIve learned a ton about the ways that humans interact with ea ch other.

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

Ive 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 t he floor.

And Ive 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 were also so much more than the sum of our parts. Whether in teams of two, twenty, or two hundred, its a privilege to work with others toward a un ited goal.

Its 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.

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 managersor 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). Theres no right or wrong way to define what mak es 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, Ill be referring to the following:

• Teammates: a term Ill use throughout the book as a catchall for the people youre 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 youre still responsible for the environment around them, for giving them feedback, and for verifying that theyre aligned and working toward their tea ms 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, Ill be talking about the function-specific area of the organization yo u 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. Ill talk a lot more about communication conduits in Chapter .
• 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.

  

  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 instanceone created to support other feature teams as they integrate new features across mobile platformsmight 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 ).