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