A Standard of Performance for Engineering Teams

How American Football coach, Bill Walsh, Standard of Performance can be applied to engineering teams

Daniel Jarjoura
Daniel Jarjoura

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.

Performing

Collaborating

Improving

Writes down technical architecture and assumptions before starting to code

Attends and participates in daily team meetings/standups 

Spends time every week to read about key areas of expertise and share findings with the team

Uses Clean Code principles (KISS, DRY, YAGNI, Composition over inheritance…)  

Analyses and discusses new features with Product Managers before they become coding tasks

Spends time being mentored / peer programming with senior members of the team (or external experts)

Schedule uninterrupted coding sessions, rather than doing multiple things at the same time

Spends time mentoring / peer programming with junior members of the team

Attends industry conferences and meetups related to key areas of expertise

Peer reviews Merge Requests every day and comments when needed

Empathises with users and spends time understanding pains and problems

Regularly experiments new technologies or practices and shares findings with the team 

Clean bugs and reviews old code at least once a week

Is on time for team meetings and shows respect to other teams (Product, Sales, etc.)


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

💡
High performance is not an end goal but rather a result of ongoing actions and attitudes that can be summarised in a Standard of Performance
💡
Every individual team member should strive for improving skills and behaviours through "drills", individual training programs
💡
High performance will follow if your team behaves like great professionals and high performers.

Are you ready to scale your engineering team and grow as a leader?

Membership includes weekly live learning sessions, online resources, exclusive events and a community of 100+ engineering leaders

APPLY FOR MEMBERSHIP

Essays

Daniel Jarjoura

Helping CTOs scale their team and grow as leaders | Founder @ The Unicorn CTO | Solopreneur