The standard way to manage software engineering is to break the job into parts. We improve someone's performance, deliver a project, or run a process. But that makes the job harder, not easier. The list never ends, and every leader ends up hitting the same wall: there is always too much to do.
"How do I get time to do everything?” This is the question I hear most from the managers I work with. The answer is that you don't. You will not get to the bottom of the list by working through it faster.
You have to approach the problem from another angle. Instead of fixing each part in isolation, improving one person's performance here, rescuing one project there, you lead the whole. The product you build, the way you build it, and the people who build it. You manage them together rather than separately.
This book comes out of more than 20 years of doing that work and advising managers who do it. It proposes a framework, but not one with a fancy acronym. It is built on one of the oldest ways to handle complex problems: thinking in systems. It is not a recipe, but it will apply to any problem you face, from helping one engineer grow to evolving your team’s architecture.
It is opinionated and direct. You will not agree with all of it. But it will change how you see your team, how you lead it, and how you grow as an engineering leader.