Five things managers should stop doing right now

Managers get a bad rap a lot. Heck, many agile officianados thing we should let Darwinism take us to extinction. Well, there are definitely those who give the rest of us a bad name. But, people forget to realize that managers are just people doing a job as well. We have good days and we have bad days and we’re learning on the job too. Despite all of that, it is useful to listen to all feedback, good or bad, and find that nugget of gold that we can polish and use to improve our job performance. Better performing managers usually leads to better performing teams. I’m currently in my fifth year as a manager, so I thought I’d post the top 5 things I think managers should stop doing now.

Making all of the decisions

The people that work for you are there because they have a skill to do a particular job. If they don’t that’s another blog post entirely. As a manager, your true value is not in making all of the decisions for your team. Your value is in helping your team generating more value for your company. Instead of doing your team members’ jobs, focus on understanding your team members and their needs. Focus on understanding the business goals as deeply as possible. Then, decide what you truly need to be doing to connect your team’s strengths and those key business goals. Making all the decisions is almost never the answer. In most cases, especially once you’ve been away from being an individual contributor for a while, your team members will really have the best knowledge to make the right call.

If you have read “Drive” by Daniel Pink and follow the science behind the book’s principles, you know that giving sensible autonomy to employees makes them feel more empowered and, thus, more driven to achieve mastery in their fields. Instead of finding the fastest path to completion of a task, an empowered, autonomous team generates more holistic solutions that better withstand paths other than the happy one. Just one more reason to let the team make the decisions it should be making.

Finally, if you’re going to make decisions that will affect the team members, by all means, make sure you understand the impact. Occasionally I’ll be asked to make a blanket rule about what IDE my team must use because we have to standardize, or something to that effect. Well, this choice affects me very little, but will affect each of my team members all day, every day. This is a decision I’d much rather either defer to the team on or get input on before “making a ruling.” Making bad choices without realizing the impact is a sure way to lose the respect of your team.

Measuring without understanding the consequences

Eliyahu Goldratt sums it up well: “Tell me how you’ll measure me, and I’ll tell you how I behave.” Rules and metrics have intended and unintended consequences. Put it simply, every metric can be gamed. Managers, and their managers, love metrics. Managers often implement metrics to gauge employee quality but rarely think it completely through to their various potential endings. Whenever you’re tempted to say “Jim is such a bad developer!,” make sure to look for any rules, spoken or otherwise, that may cause him to make the choices you dislike. We often blame people for system problems.

Let’s take an old, but good example of this problem. Manager Joe tells his team that they will be measured on the number of lines of code they commit to the repository. The thought behind this is that the more lines a person commits, the more productive she has been. A few weeks later, Sally decides not to remove that bit of the code that we don’t really need anymore because that will subtract from their lines of code totals and Sally really needs a good raise this year.  She’s trying to buy a house. Jim has been doing really well writing efficient code. However, due to that, his lines of code results are much lower than all of the others on the team. So, Jim decides that he’ll write this week’s code in a much more verbose way. It will still do what it needs to do, but his metrics will start to “right” themselves. Poor team… both of these actions will bite them in the ankles later. But, they’ll worry about later, well… later.

The moral of this story? Only measure what you absolutely have to and then make sure you’re measuring it and positioning it in such a way as to minimize the desire to game the system. Even good people can be tempted on bad days.

How do you measure programmer productivity?
When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.

http://www.computerhistory.org/atchm/macpaint-and-quickdraw-source-code/

Changing team priorities every 5 minutes

There is one universal truth that many managers just don’t think through. Context switching is one of the biggest productivity killers in existence. It is not merely annoying. There is a financial cost to running around like a chicken with it’s head cut off. I once measured the impact of context switching on my 10 person team and found that a mere two interruptions a day could easily cost me 3 developer days a week! This isn’t necessarily changed priorities, but even just a 10-min ramp down and a 10-min ramp back up from middle-of-the-day meetings or the too-oft-heard “Hey, do you have a few minutes to answer this simple question?” can have this kind of monetary impact on your team. (With that information, even if you aren’t changing priorities often, you should be really looking hard at what you allow to impact your team!) In my first year as a manager I was initially dumbfounded as to why my team worked so hard but took forever to finish anything. Well, we had way too much work going on. One developer was assigned to ten things and it took ten times as long to get anything done. This is when I discovered Kanban, by the way.

Beyond the cost of context switching itself, too often things are started, interrupted and then never finished. Remember “out of sight, out of mind?” If you hear the phrase “let’s shelve it for now,” you probably know how often those shelved items never get revived. Well, its pretty darn often. Over time, unfinished work adds up to a huge opportunity cost for the company.

We need to move in a direction that recognizes that finishing work is the real goal of a business.  With stocks, you get no value until you sell them. Work is very similar. The work you do provides absolutely no value to the company (other than various things you discover along the way in case you’re playing devil’s advocate on me) until it is delivered! Somewhere along the way we are trained to think that starting = good and that constantly changing priorities is something you have to deal with. It’s time for us to make a change. As a manager, visualize the number of interruptions. Calculate the cost to the company. Provide that data to your leadership.  Then implement a system for your team (at minimum) that introduces the concept of cost of delay so that all interruptions can be evaluated in such a way that you can choose the path with the least negative impact to the company.

Taking credit for the good stuff but not for the bad

Too many managers like to take credit for their team’s successes but blame their employees for the team’s failures. It is a slimy way to behave and it shows a true lack of leadership. No wonder many managers lose the respect of their team. Let the light shine on those who actually do the work being praised. Face it, its usually not the manager who did the work. I’d rather be praised as a manager who has set their team up for those individual successes, providing a thriving environment for those employees to shine. This kind of marketing is not only good for your team, but its good for your career too. I mean, if your team is viewed to only be surviving because of you, how will you ever get promoted?

On those days where stuff just hits the fan, man up and take the blow. If you want to be praised for setting up your team for its successes, how could you not have culpability in its not-so-great moments? This leadership behavior can encourage others on your team to pay it forward and build a strong cohesive team who has a unified feeling of ownership rather than a bunch of fearful individuals.

Cultivating a fear of failure

Variability isn’t going away anytime soon. Agile and Lean practices assist you in creating systems that don’t crumble in the face of variability. Failure, like variability, is inevitable. Instead of fighting the inevitable, we should do what we do with variability and create a system that makes it safe to fail. In my team I tell them that I want them to be the people that start by saying “Hey, I F’d this up. Learn from me and let’s figure out how to avoid this in the future.” We learn from these individual mistakes and employ measures like small batch sizes, regular demos, continuous delivery, etc. so that the inevitable failures are small ones and not dangerous to our group or our company. Eventually I want to get to the point where we’re focusing on “Hey I nearly F’d this up. Learn from me so you can avoid it too.”

This is what I describe as a truly safe to fail environment. Most safe to fail environments are all about the workflow and process measures we use. But, I think the narratives are important as well and what really remove that fear of failure from the team. This doesn’t mean that we want to continually fail because failure is awesome.  This means that managers have to go beyond the mere words that it is safe to fail and make it safe to share failures with the entire team in order to get the most learning value from those mistakes. If you are all talk and no action, your team will never believe you and you’ll still be living in a culture of fear. Start with sharing your own mistakes, learning from those and that may open the door to your team doing the same.

“Never doubt that a small group of thoughtful, committed, citizens can change the world. Indeed, it is the only thing that ever has.” 
― Margaret Mead

If you’re a manager and any of these scenarios hit too close to home, don’t ignore it. Face it and begin to make a better work environment for yourself and your team. Check out the Lean community online or in your area. You’ll find a lot of really smart folks that are dealing with or have dealt with the same things. You’re not alone and you can make a change.