Monday, June 28, 2010

The Evils of Management

This post continues on the theme I started in the "Agile - An Elite Game Only?" post.   This installment covers the claim that Agile "fails to address the evils of management". 

Hear ye, hear ye.  Let it now be known that I am one of those pointy-haired bastards.  The Man.  High Priced Overhead.  The Management.  My current position is CTO at the Richard Ivey School of Business.  I've previously held positions at other companies in VP Engineering, Director Engineering, Manager, Team Leader roles.  In ancient times (more than a decade ago) I was a software developer.  I've led and managed teams over those years using both traditional planned methods and agile methods.  In my past I have been known to quote IEEE and ISO as well as, more recently, Sutherland and Beck.

I hate to deflate your balloon right off the bat but the expectation that any software development methodology will "address the evils of management" is flawed.  If we assume for the sake of argument that the use of "evil" here is a colourful metaphor meaning "incompetence" rather than actual malice it is difficult to see how any methodology would solve the problem.  Methodologies might somehow stunt the impact of incompetent management but that doesn't really address the problem.

I'll steal a page from my buddy AgileMan and define "incompetence" in a very broad sense to mean "unable, for whatever reason, to perform the necessary duties of the position."  This could be due to laziness or bad attitude or fear but it could also be due to lack of job knowledge, insufficient data, overwork, competing goals, or other factors. 

Companies need to realize that leading agile teams requires different time and attention from them.  It requires more direct interaction, more trust and empowerment, more vision and leadership.  So where do leaders find time for these new responsibilities?  Thankfully if you have a good teams and healthy culture, Agile requires less Management, less reporting, less approving.

What Have I Learned?

As a manager and leader coming who has worked in both preplanned and agile environments I have learned a few things.  While the following lessons might not apply to every situation they are more or less all true for all the situations I've been involved with so far.

Software Development Team Leaders Need To Be Technical

I'll start off with a controversial one.  I don't care what you call them... scrum masters, coaches, team leaders, development managers, etc. but the leader of a development team needs to be technical.  I'm not saying the leader needs to code every day but she should be capable of and have experience in doing so.  The leader needs to know that their primary responsibility is leadership and empowerment and her goals and objectives need to reflect that emphasis.  Part of those goals should include ways of staying current on both the leadership and technology sides of the role.

Agile Can Make You A Better Leader -- If You Let It

Leaders and managers who see the opportunity for personal growth and for team growth can leap ahead in their careers by leveraging agile principles.  Every modern business leadership book talks about empowering employees to make decisions, getting "out of the way", growing your team to achieve greatness.  Agile did not not define this game, agile is just one of the newer contestants.  A good leader will leverage the expectations around team performance that come with agile and do everything they can to empower their team.  Empower the team with knowledge, with responsibility, and with trust.  Frightened, insecure, or incompetent (in the broad sense) leaders will feel compelled to control, define, over-measure.  These actions end up stifling the real behaviours that will make the team (and the leader) successful.

Teams Must Understand That Managers Have Responsibilities Too

Too often I hear team members complaining that their manager just needs to trust them.  If only the manager wasn't meddling so much we could get more done.  If only the manager wasn't asking for us to work on "useless" things we could get more valuable work completed.  I'm here to say that Trust needs to go both ways.  Teams need to trust that a manager is asking for certain things for a good reason and not just on a whim or because that's what the process tells them to ask for.  Sometimes development teams are part of a much larger organization that, for reasons outside the control of the development group, finds value in artifacts that in the team's limited view seem worthless.  Trust that a good leader will ask teams for non-product deliverables only if there is a good reason.  Naturally teams have the right to ask questions about the deliverable including its perceived value.  In the end, the leader should be trusted to make good decisions.  That's her job after all.

Bad Management Repels Good People

Finally, it should be obvious that consistent bad management will cause good people to leave.  If you feel that your talents are going unrecognized or that "the management" continually screws things up and cannot provide good explanations for the decisions they make then vote with your feet.  Even in smaller communities like where I live there are opportunities out there for those who are motivated, energetic, and talented. Life is too short to be miserable in your job. 

Coming Up "Soon" - Software Professionals

8 comments:

cjg said...

Excellent post. I think there needs to be more Agile discussion on the role and expectations of management within an Agile culture. I think it will help people understand what Agile entails. Too often it seems to be a less-than-complete system with a lot of hand-waving explanations, even if that is not intended.

Kimota94 aka Matt aka AgileMan said...

The funny thing is: when we were bringing Agile in where I was the Agile Manager, I thought that we had a good understanding of what "Agile leadership" would look like. It didn't seem to me to be as much a case of not knowing what to do (among our leaders) as not being willing or able to do it. But maybe that was just delusion on my part.

Oh well, at least I got a couple of books out of the experience! :-)

cjg said...

Kimota94: I think that that management perspective never entered my mind because I was always on the implementation side. After reading your comment, I remember the idea of "light touch" management was always put forth. I think that maybe our organization missed out by not having a stronger and more obvious coordination effort between teams - a management role of a sort. However I don't know if that is the same idea.

Anyway, you were correct in the idea of "Agile leadership" and that was communicated well. Just because I forgot doesn't mean it didn't happen ;)

Kimota94 aka Matt aka AgileMan said...

Interesting thoughts on "technical ScrumMaster" vs "non-technical SM" showed up here.

David said...

Great post Pete. I worked under Pete 12 years ago as a programer and he was an excellent team leader then. He let me do my job, and trusted me, even though I was a graduate. And boy, did that guy understand programming. Enough for me to respect him, which was saying something. I can only imagine he has intelligently and sensitively moved up the food chain since then. I manage now myself (not in programming), and I worry I'm not doing as good a job as he did back then. I try to.

Anonymous said...

I constantly spent my half an hour to read this weblog's articles or reviews all the time along with a cup of coffee.
Feel free to visit my web blog - slots for money

Anonymous said...

Ahaa, its fastidious conversation regarding this
article at this place at this website, I have read all that, so at this
time me also commenting at this place.

Here is my web page ... Hdfc Forex Card

Anonymous said...

Magnificent beat ! I would like to apprentice while you
amend your web site, how can i subscribe for a blog web site?
The account aided me a acceptable deal. I had been tiny bit acquainted of this your broadcast provided bright clear concept

Stop by my web page; usa online casino