Servanthood
I've been at my current job for almost seven years now. About two years into it, Bert and Helen decided that we had grown enough to warrant some kind of project management. None of us really knew what we wanted from this new role and while I began to study this field quite a bit, it still took almost two more years to make the role useful.
At the beginning, Bert and Helen tried to impress upon me the importance of being a good leader. They advised me that I could not lead by mere authority. Just because I was the Project Manager, that didn't give me the right to boss anyone around or make flippant decisions. I would never be given respect, I had to earn it. I could not dictate decisions, I had to earn consensus.
In response, I suggested that a good leader should go even further than this. In my words at the time, I said that a good leader should be a servant. A good leader should strive to make things easier for everyone else and should be willing to do the jobs that no one else wants to do. In retrospect, my words were more than a little naive.
My explanation that a leader must be a servant was straight from Jesus' example in the Bible in John 13. And while I still think that the principle is correct, my words certainly didn't translate well into the business world. Funny enough, I remember both Bert and Helen looking at me quizzically when I said the "servant" bit and only later did I understand how strange my words must have sounded.
Over the past five years, I think that I have learned what it takes to be an effective manager. The largest part of that actually came from my time as leader of the youth worship team at Faith Congregational, in addition to my professional experience. I've been studying statistics and essays from a variety of Project Managers in the software industry since the time that this role was first offered to me and I've grown a lot since then.
My belief still stands: A leader should be a servant. As director and manager at my company, it's my job to give my co-workers the projects, tools and answers they need and then give them the space and time to do their work. Our programmers, QA people and tech writers should not have to randomly ask people for advice or direction. They should get what they need when they need it without being forced to sit in endless meetings and without dealing with politics and red tape. It's my job to make that happen. It's my job to help them, it's not their job to help me.
As for earning respect, that's the only option that I even had for most of those years. To quote myself, "I trade in favours." I scratch your back and you scratch mine. If I need you to do something for me, I probably volunteered to do something for you already. I'm like the Godfather in that way.
At this point, in the my role as Director and as one of the most experienced programmers at my company, I could probably use my position and authority to get the job done. More to the point, I have seen new employees at both my company and at other places attempt to do just that. We so often think that a strong hand will get the job done and while we may see some short term results from this approach, we need to understand that we're eroding people every time we do this and it costs us all in the long run.
We're not supposed to break people down, we're supposed to build them up. We're trying to help people grow and let them look forward to coming into work in the morning, we're not just trying to get today's deadline done. We need to see that every negative reaction we have and every extra rule that we implement takes away from people. And if we don't invest in people then we haven't invested in anything.
1 comment:
"I trade in favours", I'll have to remember that. Although, it's not really fair if a person needs you more than you need them, but maybe you take emotional bank account into consideration as well ; - )
Post a Comment