A Standard of Performance for Engineering Teams

Bill Walsh is perhaps one of the best American football coaches in history. Between 1979 and 1988, as Head Coach of the San Francisco 49ers, Walsh won three NFC Championship titles and three Super Bowls. I know nothing about American football, but Walsh’s book on leadership, The Score Takes Care of Itself, is one of the most inspiring books I’ve read in a long time. And I haven’t finished it yet 🤓

The first chapter describes Walsh’s methodology for consistently performing at the highest level, which he calls his Standard of Performance. According to the coach, a team leader shouldn’t focus on the end result, in his case winning a championship, but rather have an “agenda of specific behavioural norms—actions and attitudes—that [applies] to every single person [in the team].” With this philosophy, if everyone follows a “very high internal code of ethics, ideals, and attitudes” and “practises relentlessly until their execution at the highest level [is] automatic”, then winning will take care of itself.

The approach is somewhat counterintuitive. Usually, professional sports teams are all about results. Scoring goals, winning games and championships is the typical agenda for coaches. But Walsh was different. He realised that results are just a consequence of skills and behaviours that are consistently displayed and improved over multiple seasons.

Applying this concept to an engineering team would mean that CTOs shouldn’t focus on typical metrics like Deployment Frequency or Change Failure Rate, but rather on the actions and attitudes required so that engineering velocity and quality would constantly be very high. The below table is an example of what those actions and attitudes would look like for a software developer.

As you can see from the above examples, I’ve tried to focus on what software developers should be doing on a daily (or weekly) basis, actions and attitudes, rather than the results. The whole idea here is that if each developer writes down technical architecture and assumptions before starting to code, schedules uninterrupted coding sessions, and reviews Merge Requests every day, then the team Deployment Frequency would be very high.

If these actions are indeed sufficient to create a high-velocity team, then the CTO or engineering manager “just” needs to identify what the skills required to perform these actions at the highest level are. In the book, Bill Walsh shares the following process to improve the players’ performance:

After careful analysis, [the coaching staff] identified thirty specific and separate physical skills—actions—that every offensive lineman needed to master in order to do his job at the highest level, everything from tackling to evasion, footwork to arm movement. Our coaches then created multiple drills for each one of those individual skills, which were then practised relentlessly until their execution at the highest level was automatic—routine “perfection.”

While a professional athlete trains 80% of the time and performs during the remaining 20%, a professional knowledge worker is expected to perform 80 to 100% of the time. Not the best environment to improve individual performance. A good practice would be to allocate ½ day to 1 day per week for individual improvement. Engineering leaders can organise peer programming sessions, collective code reviews, training sessions with external experts, etc. The key here is to have individual training programs, “drills”, for everyone in the team.

Finally, the most complicated part of this methodology is to convince all stakeholders that the team focus should be on the Standard of Performance and not on the results. Bill Walsh tells the story of a staff member who complained to the team owner about the coach’s lack of grandiose plan or timetable for winning a championship:

The staff member was wrong. I had very profound and organisation-changing goals, but he didn’t accept my philosophy and was fired when I heard about what he had done behind my back.

To avoid such a situation, a team leader should communicate their Standard of Performance and how this standard will generate high performance in the long run. In the case of a high growth startup, this could be a tough sell as founders and investors have very high expectations for the engineering team. A good way to establish this philosophy is to highlight the change of attitude impacts ahead of results. For example, suppose developers now communicate extensively with the product team and are involved in new feature requirements before becoming tickets to code. In that case, the product team will be more trustful and engaged than if developers were “just” coding tickets without much involvement. To quote the coach:

The culture precedes positive results. It doesn’t get tacked on as an afterthought on your way to the victory stand. Champions behave like champions before they’re champions; they have a winning standard of performance before they are winners.

In Summary