The Engineering Leader

Chapter 13. Driving Improvement

Engineers often look for definitive answers—it’s part of the training. We take the desired output, and we use our knowledge of the way things work to meet that output. We verify it. We claim it is correct.

Of course, this has some limitations. As Donald E. Knuth said, “Beware of bugs in the above code; I have only proved it correct, not tried it.”¹ I take this to be about the limits of mathematical justification applied to complex systems.

When we apply organizational reasoning to actual humans, we face the same problem. The constraints of working in a regulated field like medicine or finance are vastly different from the constraints of working for a small startup trying to find product-market fit. The constraints of running a larger, more established team are different from those you face when building out a small team in a smaller organization.

There are many people out there who would like to tell you how to run your team. I am not one of them. I believe the solutions of team functioning are uninteresting compared to the problems and causes of teams that don’t function as well as they could. In this section, we will talk about solutions, but to focus exclusively on solutions misses the point. This section is about the conditions that make those solutions useful.

Individuals scale through their own efforts. Teams scale through the structures and clarity that make groups of people work together more effectively. Early on in the leadership journey, ...