A recent thread at Workplace Stack Exchange about managing developers who are more talented than you contains a comment that neatly sums up how to lead subject matter experts:
You don’t even need to be competent, as long as you listen to competent developers and don’t claim to know better.
I have written previously about being careful not to get stuck in your previous mentality as an individual technical contributor. Technical skill is often one of the factors considered when deciding whom to appoint as a team lead, and it is tempting to act like your leadership in scrum is still based on technical merit. But what happens when you’re assigned to lead people who are much, much better at something than you are (like at my current job)?
In scrum, this is a non-issue. The Scrum Guide clearly says,
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality
Their skill level in relation to yours is completely irrelevant. A large part of your job is to foster a work environment where the development team can do their best work. You do this by listening to the developers’ needs and then working to remove any obstacle that keeps those needs from being met. Your ability to do that is not principally determined by your knowledge of object-oriented programming or web services.
Does that mean that a scrum master is not allowed to talk shop with the developers? Not at all. But if you’re going to talk with them in technical terms, and the developers really are in a different league than you in terms of skill, then you need to realize that almost any technical conversation you have with them will be for your own benefit more than theirs. One could argue that you are wasting their time by doing so. Be appreciative when they take a few minutes to explain something to you.
It is always helpful for a leader to have some understanding of the work done by those he leads. It increases your empathy with them, which helps you understand their challenges and what needs to be done to resolve them. But being good at what the developers do is not required (maybe it’s not even a significant plus) as a scrum master. I continue to be humbled in my job as I keep realizing how little my technical background actually matters. As we more deeply internalize the fact that our job is to help others do their job, any arrogance or intimidation we feel from comparing our technical skills with theirs will be replaced by the security that we are providing far more value to the organization by making their job easier than by trying to do it ourselves.