Building

The Practitioner Rule

A few years ago, I was with a peer group of other CEOs, and we made a spellbinding discovery. With more than 70 years of collective hiring experience in the room, we identified one trait that existed in every great leader we had ever worked with.

The trait is what I now call the “Practitioner Rule.” Leadership can’t just be about people skills; they have to be a practitioner. Practitioners are skilled — preferably 10,000-hours-level skilled — in at least one area that matters to their team’s success.

In other words, practitioners know what great looks like. They are in the details. They can be hands-on when the team needs support and push the excellence bar ever higher. A manager who can’t do those things has less of an impact, and I’ve yet to see an exception to this rule.

The conventional wisdom shared by many is to “hire smart people and get out of their way.” However, in my experience, this is terrible advice. Farhan Thawar, Head of Engineering at Shopify, described the flaws of this approach in an interview, suggests a new phrase that resonates strongly: “Hire smart people and pair with them on hard problems.” This is the spirit of the Practitioner Rule.

Being “as close to the details as possible” is a feature, not a bug.

Of course, leaders have to learn to leverage their practitioner skill set to empower the team, not to hold them back or micromanage. When that happens, it’s relatively easy to identify and correct. It’s much more difficult, if not impossible, to correct the opposite issue: a leader who isn’t pairing with their team on hard problems.

Interviewing for the practitioner skillset is pretty straightforward. For instance, if you are hiring an Engineering Manager, and a candidate’s practitioner experience is uncertain, I ask them to do the same project as the Senior Engineers on their team. Their output may not be at the same level as a full-time engineer, but it should demonstrate that the candidate knows what great looks like, and enjoys operating in the details. If they are unwilling to do a hands-on project, or believe that work is not key to success in the role, it’s an obvious red flag.

In some cases, the Practitioner Rule influenced how we organized teams. For example, we tried several approaches, but ultimately organized engineering teams by function, not by project or area. Engineering Managers who specialize in JavaScript only manage JavaScript engineers. This decision has tradeoffs, but it enables the manager to truly pair with their team on hard problems.

As a leader, hiring is high stakes. Getting it right can propel a company to incredible heights, but correcting mistakes can be costly, to say the least. Following the Practitioner Rule does not guarantee success, but it drastically increases your chances. Anything that simple, which de-risks a high-leverage activity, feels like a cheat code.