The First Myth Of Management Is That It Exists

My Personal Beliefs on Management


I often like to quote the age-old adage that 'the first myth about management is that it exists'.

Rather I view the role of manager as a facilitator, almost equivalent to an umber grunt. The manager's job is to listen and eradicate blockages with the ultimate goal being to get better utilization out of existing resources. Good managers realize they work for their employees, not the other way around. Micro managing is bad; mentoring is good. Some of my fondest success stories are hiring interns who gradually became full time productive coders who may even out grow the job and leave, but if they want to work with you again, that is the best compliment you can get.

Firing employees is not management. Anybody can do that. Rather converting an unproductive resource to a productive resource is the goal. Obviously part of this requires being able to measure performance but it is deeper than this. Without getting too psychological, programmers are basically artists and they come in all shapes and sizes. Some like to be challenged, some not so much. This is not necessarily a bad thing. Some people love to be given the impossible and get bored at a task they know they can complete in a short period of time while others thrive on being able to quickly complete a task and move on to the next. Some coders produce consistently on a daily basis, others go through down periods where their output is barely discernable but then bam, they go through a period where they produce some fantastic results in a short period of time. A manager's job is to understand the individuals as well as to be able to measure their performance and create a plan of success based on the individual's unique characteristics.

I also believe in positive versus negative reinforcement. Most people respond to accolades and atta'boys better than having their mistakes amplified. Good programmers enjoy the ability to show others how creative and intelligent they are. They like to share their success stories far better than their failures even though we can all learn from our failures. It is more productive to allow them to surface their mistakes and show how they eventually got on the right path rather than to lament the lost time they spent going down the wrong path. Subtle peer pressure is far more effective in motivating coders. I can't think of one time a boss yelled at me and my take away was, boy do I want to work harder for that guy.

While business is not always a democracy I do believe that consensus works better than trying to impose one's will on others. An example of this is the conventions surrounding an organization's code base. The placement of curly braces, the level of indentation, the design patterns used, etc are better to come from group consensus rather than some big dog imposing their will on the team. Understanding that while 'this is how we have always done it' produces consistency, maybe 'this is a better way to do it' is an important part of constant process improvement and constant process improvement should always be a goal since perfection is a myth.

A good manager should always be trying to mentor their co-workers and encourage them to communicate what they like to do and what they don't like to do. In this way, you can avoid giving folks tasks they are not motivated to accomplish. At Amazon I worked with tons of project managers who were Harvard MBAs who considered the work they were doing below their dignity. As a result a lot of these project managers did not do a very good job of managing their project. A healthy engineering organization in my mind (which is actually anti-Amazonian) is not a bunch of PHDs who are gifted geniuses but rather a mix of younger coders who are learning on the job, mid tier guys who just love doing the work, and guys who are already at the top of their game. In this way you have resources who are not always doing something they consider grunt work. One person's grunt work is another person's challenging and fun task. Part of a manager's job is figuring this out.

Finally, on a personal note, I like fungible assets. This allows me to run a Kanban type operation rather than strictly Agile. In Kanban, workers pull the next request from the board and can often select which task they would prefer to do. While this is not always possible it is a goal. To this end I like paired programming where periodically, coders of differing skill sets are paired with the goal being cross training. Maybe a front-end coder and a back-end coder pair up on a task with the goal being they will cross-pollinate. Over time you may end up with two coders who can both do front-end and back-end work which means at some point in the future someone can take a vacation and the organization doesn't come to a screeching halt. Kanban is also designed as a ground up constant process improvement discipline where changes in how things are done are initiated by the actual people who do them rather than some ivory tower type who may or may not get it.

Obviously all this takes time to develop and is based on the concept that an organization is growing and evolving over time. Change can be disruptive in both directions and organizations sometimes just have to get work done quickly in order to meet higher order business objectives. Keeping the lights on should always take priority but it doesn't mean constant process improvement needs to stop. Knowing how to balance these seemingly competing priorities and when to take the time to pay down technical debt as well as when to move on to new technologies is part of what goes into effective management which as my opening quote claims, doesn't exist :-)