I am currently writing a book with the working title Engineering Team Effectiveness: A Field Guide to Fostering Powerful Technical Teams. Here is a draft of the introduction:
I have spent the past twenty years answering the question: “Why do highly intelligent, skilled, motivated engineering teams come together and fail?”
There are often logistical factors as to why they eventually disband, such as running out of money or poor business decisions at the top. Yet very often their lack of expected performance comes down to interpersonal dynamics which masquerade as technical and process issues, as well as technical and process issues that compound interpersonal dynamics. Exploring the negative space around being smart, good at your job, and keen to do the right thing — and why bringing together people who exhibit these factors alone is simply not enough to form a healthy, high-performing engineering team — has been my journey toward writing this book.
The term “EQ” has sprung up to counterbalance our collective admiration of IQ. It is a useful metaphor, but to my mind little more than that. Trying to quantify EQ, as if to compile a league table of social acumen, reminds me of the joke about the meditation competition. At the end when the winner is announced, she leaps up out of the lotus position, fist-pumps the air, and shouts, “I am the serenest!” People with high EQ tend to inherently understand the perils of trying to quantify high EQ.
Many factors in team performance and team health, however, can be externalised — sometimes qualitatively, sometimes quantitatively — in order to be addressed. Throughout this book there are methods and models that are as useful for exploring team effectiveness as their analogous paradigms for technical architecture, user interface design, or statistical analysis. You can think of them as design patterns for people, and they include everything from conflict resolution and communication effectiveness to that elusive but essential quality–motivation.
Along the way we will address topics unique to engineering teams as well, such as settling ideological “religious wars”, celebrating neurodiversity in technical disciplines, why broken deployment pipelines are often a people matter, how exit interviews can be as important as hiring interviews, and the anti-pattern of individual heroism.
Threaded throughout the book is a fundamental premise: that engagement, which leads to effectiveness, can be diagnosed and improved for individuals and teams. Using a model called the Engagement Matrix, you will come to understand the underlying dynamics of team engagement. This will allow you to be able to spot when your team needs to be stretched and challenged, when they need backup and support, and when and how to celebrate successes big and small as a means to building group confidence. Navigating engagement is what keeps powerful teams both high-performing and healthy, on the edge of growth without tipping over into burnout.
Most of this book springs from personal experience subsequently backed up by research. Some of it comes from what I got right over many years spent building and leading engineering teams. A fair amount of it comes from what I got wrong, since those lessons that stung also stayed with me long enough to debrief and dissect them over time. Some comes from the inside as an engineer and later engineering leader, some comes from the outside as a consultant, and some comes from interviewing fellow technology leaders. I have also ported over many years of consulting and coaching outside the technology sector, bringing home to my people what I have discovered abroad.
My definition of “engineer”, by the way, is simple–anyone who makes things using technical skill. By technical I do not mean technique, as in craftspeople, but rather skills that trace their origins to mathematics and science. This book should apply to hardware and software engineers, data scientists, *ops engineers, and many other similar disciplines, some of which may not have yet been invented. It should apply equally well inside start-ups, scale-ups, intrapreneurial ventures, agencies, brand-name multinationals, skunkworks, and open source teams.
What is in here is more directional than proscriptive, opinionated for the sake of sparking thoughtful consideration rather than simply to pontificate. I hope it provokes you, consoles you, and above all gives you practical tools to make your own engineering team a group to be proud of and admired.