Servant Leadership
Trying to catch up with some more of my “backlog”…
This one is from early December. Joel Spolsky wrote an article for Inc.com titled How Hard Could It Be?: My Style of Servant Leadership. It’s short and to the point, and I think every manager or manager-to-be should read it and heed his words.
In particular, I identified with a couple of passages:
In our company, management’s job is to get things out of the way so that all the great people we’ve hired can get work done. … Our company was built on the idea of hiring smart and productive people and then clearing the decks.
This is something I’m really striving for in my leadership capacities. Especially coming from an expert background, sometimes it’s difficult to let go and allow your team to thrive. Sometimes I feel an impulse to jump in and do the work myself, but I have to remind myself that my team is made up of experts for a reason. I should trust in those experts and let them do their jobs… and I will stand back and remove all the white noise that gets in their ways.
I still contend with the problem from my own superiors that sometimes I am not trusted for my expertise. This is very frustrating for an intelligent and productive software engineer (or any other expert)… why would you hire a supposed expert in his field if you’re just going to tell him how to do his job? Experts want the ability to thrive in the work environment and build good products without interference. They will quickly grow bored with implementing someone else’s ideas.
Not long ago, we had a management trainee who sat around waiting for us to give him a formal title and promotion so he could “get stuff done.” Problem was, he had never managed to win enough respect or influence from the development team to actually do things.
At the same time, you must be willing to wade into the thick of things and build a rapport with your team. Someone who demands respect simply because of his or her position is only going to get it grudgingly.
This is where I strive to help my team grow. I’m not opposed to pair programming with my team members when they get stuck, or offering up ideas to improve the overall architecture, or even just dealing with annoying stuff for them.
Commanding subordinates and leading a team are two very different things. Leading by example is even a step ahead of that.