It’s Time We Retire Player-Coach in Software Engineering
Enacting a player-coach model in software engineering is a guaranteed path to failure in 99% of scenarios, and this is why.
The player-coach model follows the premise that a people leader can also maintain their role as an individual contributor, and do both jobs at the same time (albeit at 50% capacity for each role as a rule of thumb). This works great in very small teams, made up of senior individuals, and can be perfect for those ICs looking to dip their toes into leadership. Unfortunately a lot of organisations have taken this model and completely misused it outside of the parameters of very small, senior teams and the results are…not good.
The player-coach model is a tempting proposition for organisations — no need to backfill the original role (saving dollars), and gives the individual truncated exposure to leadership (career development box ticked). But unless its applied to the above scenario of managing a very small, senior team, the end result is two-fold: ineffectiveness at both roles and strong risk of burnout.
Engineers Require Focus, Leaders Require Availability
Engineers require long, dedicated periods of time on deep work. This might look like muting slack notifications, putting headphones on or maybe even heading deep into the mountains with no phone reception and a slack status that says they’ll be back in a few days. Either way, the engineer is not readily available.
This is much, much harder to do in the player-coach model. Leaders need to be available to their team members, and their superiors. Team members may have questions (especially the less senior ICs), and there may be immutable meetings that need to be attended. Availability is a must. Not all of the time, but certainly more than needed as an IC.
Balancing these conflicting needs in the player-coach model is hard and stressful.
Assigned Workload Never Matches the 50% Capacity…for Either Role
Another unfortunate affliction is although IC productivity naturally reduces to match the 50% capacity applied, expectations around delivery and productivity rarely do, and a 50% backfill is typically never enacted…leading to an overinflated workload to try and counterbalance with delivery expectations and a whole other role with its own workload and accountabilities.
The inverse is also true. Player-coaches are nearly always assigned far too many direct reports to fulfil leadership needs within the constraints of 50% of time with the exact same outcome…overinflated workloads.
The Direct Reports Are Always the First to Suffer
Whether it’s verbalised or not, there is always the unspoken rule of which role is to take precedence, and it’s never the leadership role. When push comes to shove, the expectation is to jump on the tools and drop the leadership work.
This comes in part down to the the whole reason the player-coach role was implemented in the first place…it’s perceived as simply experience for the player-coach and isn’t actually a real role, which has the flow-on effect of perceiving the direct reports assigned to that leader as not really being that important. This is very obviously problematic for several reasons.
It’s extremely hard to get right, and it yields very little reward for the amount of effort it takes to get right, so why don’t we just put the player-coach model to pasture and call it a day.
Have you made a player-coach model work? I’d love to hear how you did it!
