Introduction

Over the past two decades, I've lead teams in different contexts: corporate companies, tiny family-run businesses, and startups at different stages. Year after year the same patterns emerged in radically different scenarios.

It didn't surprise me to spot the same ideas while solving different technical problems. After all, there is a substantial amount of technical literature on "design patterns".

On the other hand, I was often surprised to spot patterns while leading people. Regardless of the methodology we used, the language, how agile we thought we were --- some patterns emerged.

People complained about not being informed, they felt taken out of the decision-making forums, promotions always created discontent among some members, the structure of the teams made no sense to half of the people, the doers stated that the managers were clueless. It's a long list; I could go on for a while.

I bet you are familiar with most of these topics. This book discusses the patterns I've recognised and the leadership techniques I learned to adopt throughout the years.

I consider my book a collection of common sense driven processes, structures, and advice. Yet, when I talk to people about the way I lead teams, people label my ideas as radical and idealistic. Most feedback I get looks like this:

Nice in theory but it doesn't work in practice, does it?

What I present in the book worked multiple times. However I'm uneasy with the argument "it works for me"; it's weak. Instead, my argument is as simple as this:

What I call "common sense" other leaders call "nice theory".

I believe in my ideas because I believe in people. I believe people come first, and my experience convinced me that you can benefit from these ideas. I saw my ideas validated in people's rapid growth, in their happiness, and productivity. I want to help you do the same with your teams.

Why I wrote this book

I want to help engineering leaders to shift their focus towards these values:

• Your leadership style must evolve together with the structure of your teams. No leadership style is universal.
• You work for the people, no one works for you. Your job is to make people happy. Happy means productive, happy means high retention rate.

A book is the only media I can use as there is so much to say.

On a more personal level, I wrote this book because too many times I found myself wishing I could refer to this book in a conversation around product development.

Who is this book for

The book is best suited for:

• People in charge of one or more product development teams.
• People who aspire to lead product development teams.

The ideal reader of this book is an early-stage startup CTO/Head of Engineering which is why I say "product development" instead of "engineering" or "development".

While I'm sure engineering managers at a large organisation will find this book valuable, some important parts of the book discuss scenarios that are more relevant to leaders in charge of a whole product development organisation.

As the entire book is about leadership, you should not read it unless you care more about the people than the code they produce. I won't be discussing any technology, so if you are looking for a technical book, this isn't the one.

A great deal of this book is dedicated to diversity. I assume you are open to discussing why you need to put as much effort as you can into increasing diversity in your teams. If you are asking yourself why you should do it, then this book isn't right for you.

How the book is organised

I tried my best to make chapters as independent as possible from each other, but I consider the order relevant.

There is a logical path I'm trying to guide you through, so I recommend you read the book in the presented order:

• People

  I discuss how to build a diverse team while slowly hiring the people you need and quickly firing the ones that don't fit.

• Culture

  I discuss how to create a safe environment for people to grow and make mistakes while making sure the experience is fulfilling and consistent for you and your team members.

• Communication

  I discuss how to use different channels for different purposes and how to ensure a productive and enjoyable communication environment in a growing team.

• Process

  I discuss the processes you need, the ones you don't and, above all, the ones you don't know you need.

• Evolving teams

  I discuss how to design an organisation where people know who is doing what and the structure isn't in their way.

• Leadership and you

  I discuss the lonely aspects of leadership and how to take care of yourself so that you don't burn out and always remain useful to your teams.

I hope you enjoy reading the book as much as I enjoyed writing it!