Put Me In Coach!
I feel pretty strongly (if you already know me, you know those four words could be my entire bio, frankly) that a manager should be a coach with extremely limited player time, if any.
When I first started out in UX leadership there was a lot of discussion about the difference between coach vs. player/coach leadership that has only gotten more intense. A coach is someone who acts primarily as a coach and leader and rarely, if ever, does the hands-on work. A player/coach leader is someone who coaches their team and also acts in an individual contributor (IC) capacity beside their team. The arguments for having a player/coach leader sound well-intentioned, but they rarely account for the infrastructure or understanding from top-level leaders to make it successful.
Staying close to the work.
The argument: A player/coach leader is closer to the work and more involved day to day.
I’ve found instead: Leaders can stay close to work without being involved in the details by trusting their staff and managing expectations. I once worked for a director who expected our department leadership to produce a detailed account of any designer’s work at any time, “in case you run into the CEO on the elevator.” But the CEO doesn’t want details; they want to hear what impact the team is making on the company's goals. That’s a view from a higher level than an IC can usually provide. Using JIRA or similar tools to track work can provide valuable reports, and regular check-ins fill in the gaps.
Protecting The Team’s Bandwidth.
The argument: A player/coach leader helps take on work that gets in the way of juicier projects for the team.
I’ve found instead: A coach can help the team to manage stakeholders directly, so work is prioritized more accurately in the first place. If a player/coach is busy doing the work, they are losing time they could spend on strategy, or growing their senior people. As a manager, I often volunteered to help when projects were in a crunch, but I also empowered my team to push back on stakeholders themselves, and to support one another when they need boots-on-the-ground help, so they are learning and improving.
Flattening the org.
The argument: A player/coach model means a flatter organization.
I’ve found instead: An organization’s views and attitudes on hierarchy don’t have anything to do with the org chart. It’s about how well employees are empowered to work with one another and take ownership of and accountability for their decisions.
Saving Money.
The argument: A player/coach leader saves the company money.
I’ve found instead: This leadership model costs more in the long run. You know the drill; you’ve likely been here before. The company you work for lays people off, combines roles, or otherwise makes a short-term band-aid move. It’s not a bad temporary solution if funds are on hold, or if you have a candidate who wants a trial period and isn’t certain management is for them. But unless there is structure and support in place to see either solution succeed, you’re likely to underpay, burn out, and lose one of your best employees.
In my own experience as a full-time coach leader, I didn’t have much time to handle IC work at all. My days were more than full with empowering my team, coaching them to their next level, building stakeholder partnerships, and creating process frameworks for how work moved between product, UX, and engineering, and that didn’t even include my own growth and learning.
I’ve also seen too many leaders who struggled with this shift, bouncing between player and coach when it suited them, competing with their own ICs, and confusing everyone in the process. Most companies don’t have the infrastructure to skill or support the player/coach model.