This is the second post in a series of posts under the topic of “Managing” Software Development.  If you haven’t read the first post, you probably should start there by clicking here and reading that post.

For those of you that have read the first post, welcome back.

Don’t tell anyone, but I really don’t “manage” software development teams.  I spent my formative years early in my career working at a mid-size bank.  Hiearchical management practices and organizations were all the rage.  I wanted to be the “boss“.  I wanted my “people” to do what I told them because I said so.  I knew what needed to be done.  After all, I had two years of experience and a bachelor degree from Ball State.  By now, you can probably guess I had a rude awakening coming!

My first team was made up of mostly folks who had less experience than I did, and were rebellious, independent, and a heck of a lot smarter than I was.  Trouble was coming, and I didn’t have a clue.  I will never forget how shocked I was when I showed up for a meeting with Paul McGinnis and Dan Lehman.  My entire team was waiting on me.  My memory of the meeting was the team was patient, but yet firm in telling me that I was screwing up.  I was sucking the enjoyment out of their jobs, and they weren’t happy about it.  I walked away with one key point:  My team could have ambushed me, but was still with me and needed me to do what they could not.

At the time, I didn’t have a clue about servant leadership, or what it was.  I knew that I was going to fail as a manager if I kept “managing”.  I knew that a group of people could get more done than an individual, but how did I get this group of people to do what I wanted?  How do I control them?  After all, I was working on an MBA.  I knew it all!  I should be able to do this.  Hiearchial management had been working for 70 years.  The industrial age and the modern assembly line made quotes like “Why is it every time I ask for a pair of hands, they come with a brain attached?” seem accurate.  All that was needed was an employee who wouldn’t think, but would do exactly the same thing over and over.  I thought managing software development was just telling developers what to do, and then kicking back and relaxing.

I didn’t realize it at that time, but my team was telling me that control is an illusion, and that I needed to be a servant leader.

What is Servant Leadership?  Robert K. Greenleaf defines Servant Leadership as “The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead.”  How can you lead if you are a servant first?  I got lucky.  My team jolted me into a servant leadership style management without even understanding what it was.  My team wanted me to switch my approach, enabling them to do their job.  The team knew how to write code and had a great knowledge of the systems that we were charged with maintaining.  The team wanted me to provide overall direction, and get rid of anything that kept them from doing their job.  That’s what I did.  I bought them donuts occasionally, respected them as professionals, and protected them from everything else.  It worked.  They didn’t quit on me, and I started serving them.

Over the years, my teammates at various stops have continued to reinforce that Servant Leadership is the right approach for me.  As an avid reader, I have found several excellent Servan Leadership references that have reinforced the approach.  I have found that most teams have evolved into a state of dysfunction, not because of the members of the team, but because the “manager” of the team doesn’t get Servant Leadership.  Those managers set the bar so low, that being a servant leader has an immediate impact on the team dynamics.  Often, being a Servant Leader is all that is required to turn a team around.

Servant Leadership has certainly changed my career, providing me a fulfilling career, with some great friends and even greater memories.

Thanks for coming in today.

Chris