x=Control, y=Responsibility: A Simple Principle For Managing Smarties

Someone once asked me if I could give one bit of advice to an aspiring manager what would it be. At first I said, “Go kill yourself.” But then I remembered how hard it was for me at first leading a platoon at 18 in Army basic training. Instead, this is the one piece of advice I’d like to give every aspiring manager:

Control must be correlated with responsibility.

By “control” I mean the authority to make decisions. The person in a situation making the decisions is the one in control, not the person doing the work. Many managers and team leads wrongfully believe that since they allow the team to do the work that the team is in control and therefore responsible. If management decides the tools, working arrangements, room temperature, desk quality, chairs, budget, or anything about their environment then management is in control.

By responsibility I mean the rewards or punishments for the outcomes. People will gladly accept responsibility when there are rewards to dish out, but the second things go wrong they start shifting the responsibility elsewhere. The person who gets punished when it goes bad or rewarded when it goes good is the one responsible. I’m repeating this because it’s very important for when you start to shift responsibility around the team to correct deficiencies.

Where things go wrong in management is when control is given to one person yet responsibility is put on someone else entirely. When this happens the people in control tend to do whatever they want and the person who’s responsible is miserable, quits, goes insane, or stops caring. This causes most of the conflicts in your organization and once you make this mistake it’s difficult to correct it.

However, when control is correlated with the person responsible many of the conflicts go away. This can be done by either moving control over to the person who is held accountable, or simply make the people in charge accountable for their actions.

It Starts With You

As the leader you have to lead by example and demonstrate that you are ultimately responsible. Managers sit behind the team and tell them what to do while a leader gets out in front and says, “Follow me if you want to live!” Even though you give the team control and make them responsible for the outcome, it’s really your fault if things go wrong. Make this clear to them and demonstrate it at times. Do this and when they screw up they’ll be more inclined to accept responsibility themselves.

Once you’re established as the leader and they know that you’ll take the rap for bad decisions (shielding them from your bosses) you can start to restructure who’s in control and responsible on the team. It won’t be easy because you’ll be taking control away from people who don’t deserve it, or potentially making people responsible for their actions. Nobody really likes this but in the end it’ll make for a healthier situation since the new setup will give people a feeling of ownership.

There’s a few other things you need to really make this work. First, make your expectations clear and potentially measurable so that they know what you want and you can make sure it’s getting done. Next, I try to follow the “trust but verify” model. I trust them to do what they were hired to do, but I verify that what I’m being told is true. Finally, I never dictate how things are done, but instead focus on the results of the process. If I have to get involved in how something is done then I make a point of sitting down, pairing with the developer who’s in control, and doing it with them.

Story Time

Here’s a few little stories and examples that should help you understand

the concept. It’s pretty simple but having examples usually helps to clarify things further. Anyway, they’re funny and should be familiar to everyone.

Example: BOFH

My favorite example of a disconnect in control and responsibility is not from a manager but actually from a system administrator. This guy was able to

convince management that the developers were responsible for huge amounts of downtime. He did this without any proof and managed to gain control of all the machines in order to lock us out. In fact, we rebelled and were able to show that this asshole was the cause of all the down time but management wouldn’t listen.

So BOFH locked all the machines down and wouldn’t let any developers in without permission from him. He controlled everything from permissions on files to what servers ran where to what our logins would be on each machine. However, when a server when down, someone breached the machine, a log file overflowed, or any other number of problems BOFH would blame us and we’d have to work weekends to fix the problem.

The sad thing is in every case we’d demonstrate that the BOFH was to blame. Great example is I spent a Sunday and Monday tracking down why our server didn’t work to find out it was because he wasn’t rotating the Apache logs. The logs grew to 2G in size and Linux choked on the file so Apache aborted the connection. The BOFH however managed to convince management that this was all our fault even though he controlled everything on these machines.

Management screwed up because they put this guy in control but didn’t make him responsible for the results. They let him blame the developers even though none of them could get onto the machines to fix them without his permission. What was even worse is management ignored all the information we gave them and our constant complaints because once they gave BOFH full control he used it to blackmail them into keeping his job.

Now, if management had instead made BOFH responsible for the uptime of the machines and measured it the results would have been different. I’ve actually implemented this change at a few organizations and immediately the BOFH starts handing out passwords to people and getting them involved in the planning process. The BOFH sets up monitoring to prove his uptime metrics to get his bonus. He wears a pager constantly and wants to be a part of the deployment planning of the team.

In other situations I’ve had to take control away from a BOFH and give it to the developers because he refused to take responsibility. This was at a different company but the guy would spend hours deploying applications that took the development team five minutes and one command (yay for capistrano! yay). The guy implemented draconian firewalls, ridiculous security restrictions, and didn’t listen when we told him how the application should be deployed.

When things went wrong he blamed us so we had to move development off-site and do it all ourselves in order to get the control we needed. We took responsibility and suddenly our uptimes improved, our deployment was a snap and working with consultants became a breeze. The guy eventually quit but it was probably a good thing. He once told me, “You are a good developer but you know nothing about deployment.” It was a rails project using Mongrel. Yeah, I know nothing.

Example: Strippers And Steaks

From the management side my favorite example is what I call the Strippers And Steaks Maneuver. It usually goes something like this:

  1. A sales guy takes your manager out for a huge steak dinner and to a strip joint.
  2. Based on this (and usually half drunk) the manager signs a deal to buy their crap.
  3. The next day the PHB walks in hungover and announces that you’ll start using this new thing he just bought.
  4. Everyone then spends the next week working this rotten thumb of a product into their usual tool set and process only to find out it is total junk.
  5. But, management has already spent millions of dollars on it so you’re forced to use it.

The other way this goes is when some idiot manager reads an article in Fast Company or CIO magazine talking about a new process or tool that worked at one place on one project nobody cares about.

This is a classic control and responsibility disconnect. The manager takes control of the tools and processes being used, but being uninformed makes bad decisions. However, the manager never accepts responsibility when the tool turns out to be a dud because, well, “It worked for NASA!”. Since the developers can’t make the tool work obviously they are idiots. Can’t be that the tool just sucks.

The correct way to do this is to never make a tool purchase decision without making the sales guy pitch to your most vocal developer and without letting the developer try the product. Also never make someone use a tool unless you’re willing to admit it isn’t good and back out. I’ve actually taken the stance that if the sales guy can’t setup a live demo involving my team in less than a day then there’s no way the product is viable. The rationale for this is that if the company that wrote the tool can’t get 10 engineers to configure it in a day, then how is my untrained team going to do it?

Warnings

My first warning is if you try this and it doesn’t work then don’t keep doing it. Geeks are notorious for getting a process and using it despite all evidence proving the process invalid. Take the time to analyze why it’s failing and then adjust things to fit your situation. This is just a general rule I’ve used that worked, but I haven’t followed it blindly myself.

My second warning is I don’t advocate firing people unless they are incredibly incompetent and can’t be trained. I’ve been able to train plenty of people so usually the only people I’ve had to fire were the arrogant ones that couldn’t learn because of their egos. In fact, I haven’t fired people but instead moved them to a different team where they’ll fit in.

Finally, this one rule won’t make you a competent manager by itself. You’ll need to read up on tons of other things like how to measure processes, motivating people, morale, hell even just basic time management. I’ve read so many of these books that there’s nothing new out there. Just keep looking for little nuggets of information, trying stuff slowly until you find what works for you.

And that’s the best advice I could give for an aspiring manager. Good luck.