cogitatio

In my nearly two decades of experience developing software, designing software, and managing software development teams, there is one style of management that is a sure indicator of something foul in Denmark – Command and Control.  As it turns out, a management style that was developed and adapted for use within military organizations, to ensure that in particularly chaotic and dangerous environments there is cohesion and a unitary vision, among a group of less educated team members, is particularly ill suited to managing a team of highly skilled, professional engineers, working in an office without the threat to life and limb.  In this type of environment, command and control is 1) devastating to morale, 2) inefficient to the extreme, and 3) is a self fulfilling prophecy for failure.  Yet time and again, I see this style of management employed within software development organizations, and this leads me to wonder why?

You know you are seeing a command and control management structure when 1) a unitary person, the commander, is responsible for breaking down big tasks into smaller sub tasks, and 2) the commander then parcels the sub tasks out to other people to work on, and 3) the commander monitors and dictates how the the other people execute on those sub tasks.  If you’ve worked a job, anywhere, surely you have had a manager who worked in this fashion.

I think that the reason why managers do this is quite simple.  They are being tasked with getting a job done.  Rather than trusting their team to break tasks up efficiently and collaborate, they trust themselves more.  The manager assumes that they were brought on to do just this – take big tasks and make their team work towards completing that big task, and who but “good ol me” is better at figuring out the component parts and their priorities?  Its a combination of ego, and a need to feel “in control”.  Sometimes this springs out of necessity to accomplish big things in as short a time period as possible and at other times it just grows within the organization as the organization grows.

Well, listen up – its a recipe for complete failure beyond a certain scale.  There are only so many things that a manager can micro manage, and the manager needs to be able to have a higher level picture for real growth and team collaboration.  If you are a manager of software engineers, ask yourself a few of these questions and think long and hard about where you see yourself in 2 years, rather than at the end of the next set of tasks.

1) Do you really want to hire folks who don’t ask you “Why?” – Because is not a good enough reason to do something, it wasn’t when your parents told you as a child, and its no better in the workplace.  Inherent in the “Because” answer is “Because I know better”.  Do you really know better?  And if you do know better, shouldn’t you be telling your team Why?

2) Would you want to hire someone you don’t trust to think critically?  Here’s where the trust comes in.  You need to hire the best, and you need to make sure that you trust the people who work for you to think about the big tasks and how they can be executed.  As your organization grows, and you move through the hierarchy, you will become less and less connected to the nuts and bolts of the technology.  Shouldn’t you trust those folks who are close to the technology to tell YOU what the most efficient way to approach the problem is?  And if you can’t trust them to do that, why did you hire them?

3) Do you really think you know better?  It is the ultimate in arrogance to think that you know more than the folks who you bring in.  You SHOULD bring in people who know MORE than you do about the technology.  You should trust them to bring value by thinking creatively, and applying the appropriate technology in the appropriate situation.

Command and Control management evidences a failure of trust.  Where that failure of trust exists, true collaboration cannot.  Where you can’t have true collaboration, you cannot leverage the power of a team.  And in that case, you have failed as a manager.