As a Manager, You’re the Referee, Not the Coach
This is the fourth article in a series on moving into leadership. Read the previous articles:
- Part 1: Help! I’m a Leader Now
- Part 2: The Leadership Impact Curve
- Part 3: How Managers Can Use Trust as a Tool
It’s the middle of a soccer game, and the action is moving down the field. Suddenly the referee steps into the fray and kicks the ball. The players stop to watch, confused. The ref starts heading toward the goal, grinning as they go. The defenders get out of their way.
The ref kicks the ball into the goal and starts celebrating. Everyone else stands around wondering what just happened.
Why is the ref kicking the ball? If you block the ref, do you get sent off the field with a red card? Who gets the point the ref just scored?
Nobody challenges the ref’s behavior, at least not to their face. So the ref walks away congratulating themselves on their incredible performance. They saw a ball that needed kicking and they got the job done.
The “ref” in this analogy is the agile software leader: you. You probably got this job because you were a very strong individual contributor, and you do actually know how to kick the ball very, very well. You’re probably used to deriving feelings of confidence from being really close to the action. You might even think you’re teaching the team when you take over a task. But you’re not. You’re making them doubt themselves, and you’re making them doubt the whole game.
What happens after this sort of behavior is normalized? The players lose motivation because their contributions aren’t going to matter if the ref is just going to kick the ball whenever they feel like it. The ref winds up getting tired and burned out from having to be involved in every play and in every goal that gets scored. The ref stops trusting that anyone else knows how to play the sport.
Eventually the game dissolves. The few players who are left wind up checking with the ref before they do anything on the field; after all, that’s the only way to really be sure that the ref isn’t going to stop you halfway through and do it themselves. If you’re not sure you’ll get to finish the work, why even start?
And the ref no longer has time for the actual work of a referee: ensuring that the rules are fair, that the game can proceed and that everyone on each team is able to contribute their very best, that they can learn and grow, succeed and fail.
As an agile software leader, you’re responsible for ensuring that the team is moving in the right direction, that they have psychological safety and that they can be successful delivering software. You’re responsible for the environment the team works in, the systems that punish and reward, for choosing what to celebrate and who to hire in the first place. Your work creates the game; it’s not your job to win it.
This is a huge shift from your time as an individual contributor. The tools you used to use, the ways you used to gain confidence and feel success no longer work. You need to do higher-leverage work that pays off over longer timescales. Instead of fixing a problem yourself, you need to set others up to successfully do it. You need to celebrate the problem-solving attributes your organization needs, and ensure that who gets celebrated (and who has a chance to do praiseworthy work in the first place) is fair.
When everything is new, or when things aren’t going well, it’s easy to rely on the tools that you know. It’s tempting to want to get in there, get your hands dirty, do some work, and score some goals yourself to show ’em how it’s done. Resist that temptation.
You’re the referee now. Dont. Kick. The ball.
For more practical management advice born out of years of experience working with software teams in a wide variety of industries, download the ebook “Mindsets and Tactics for New Leaders of Software Teams.”