Tuesday, February 15, 2011

Serving Too Many Masters

Your boss's boss (BB) and your direct boss (DB) both have ideas about the project your team is running. More input is often good in these situations...except when it's not. BB and DB are amicable, good people who have completely different opinions on the exact same subject.

Which ideas do you implement? Since agreement is pretty much impossible, how do you know how to move forward?

Ok, now swap that example to a dotted line boss (DLB) and a Supervisor (S) and let's throw in the VP of your department (you're boss's boss's boss).

What's a person who wants to be both happy, productive and keep their job to do?

I had contemplated naming this particular article "Wonder Woman's Bracelets" or "Jedi Lightsaber 101." Both get the point across: you deflect.

The issues that arise because people in high positions cannot agree often fall on people further down the slope, as it were; and because that person further down the slope is charged with implementing the whatever-it-is, they take heat from people who do not see their specific concepts, ideas, and requests included. However, if you are getting conflicting requests from multiple locations, you really aren't to blame if they don't see what they want to see. And you will quickly end up under water (to really mix my metaphors here) if you don't put the kabosh on all this and manage your boundaries.

Basically, in the case with two people giving conflicting information you do the same thing as if you were getting conflicting information from five people; you deflect them onto each other. It works the same if the people are at your level, below your level, or above you. Find out whose decision it is for the whatchamacallit and firmly deflect the varying opinions to THAT person.

For my first example, DB and BB. BB outranks DB, so in theory his ideas should go first. But, DB manages your reviews and pay increases, making you a strong supporter of making DB happy. To solve the issue, you tell DB that you are confused and you are only going to do what DB says. Summarize that message in an email and send it to DB. When next BB emails you or asks for something, deflect BB to DB. If there is confusion among DB and BB, or BB is not happy, call a meeting of yourself, DB and BB and sort it out; assuming that your boss's are rational (assuming be dangerous in and of itself, but assuming rationality is also quite dangerous), they will either go with your solution--for BB to get his wishes to you through DB--or they will come up with another to take you out of limbo when you get conflicting direction. Like most people, they'll revert. In those cases, summarize an email or forward the one you got, and summarize the agreement while including DB and BB in the thread.

In this way you establish process and boundaries, and you stand by them.

Now, there will always be insane workplaces where doing something sane like this produces scary and unpredictable results. Feel free to reply to my post with situations that you'd like some insight on in regards to those types of things (or anything, really, related to management) and I will be happy to give your plight (hypothetical or no) some thought.

What about the situation with more than two guys? As difficult as it sounds, the same plan will work; start with your direct supervisor/boss and tell them the problem. Then round up all the conflicting responders and get agreement about who will manage your information flow. Then, deflect all future requests to your hero, the person who is making the final decisions for you.

What now, brown cow, if that person is you? In Agile/Scrum we call that person a product owner--their job is to collect business requirements and put them in order so that a project manager and a team can know what needs to be built and when, but don't have to sort through all the varying thoughts and ideas that people sometimes get when a new shiny project is being put together.

If it's your job to mesh all the business requirements (also called functional specifications, recommendations...the list goes on) into an order that people can follow to complete a task (more technical or not), then you will also use deflection. You will make sure that all the stakeholders and people with input go to no one else but you; them telling your project manager what they want when it's your job to know that is counterproductive (though sometimes people will do that in an effort to do an end run around process in a helpless attempt to get something they find important done...they will also do this occasionally because they just don't know what to do).

Once everyone is coming to you, I recommend starting with individual meetings. Meet with one or two of the stakeholders at a time and write down what they want and don't want. Reference the list with other stakeholders as you make the rounds. Once you've got a complete list of all the items, call a meeting and go over the list with all the folks involved. The top agenda item of the meeting is to determine which one of them gets final say if there is a conflict. Then sit back and occasionally direct the conversation back until you have an answer. Once you have an answer, go over the items on the list, get it blessed by that person, and move forward with your project, repeating this process as needed moving forward. Basically, deflect people from randomly bugging the people doing the work, and then get agreement on the authority figures involved so that if someone is unhappy they didn't get A, B or C, they have another person (who is not you) to work it out with.

What if you are one of the masters? What if you have someone working for you that also must respond to someone else? Maybe you get half their time on a project and the rest goes to a different project, or maybe they are a product owner for a project where you and your boss are a stakeholder. How can you help them?

The first thing to do when dealing with someone who has many masters, is to sit down and talk with them. Ask them how they are doing and if they need anything. Ask them if they lack clarity on anything on which they are working. Check in regularly on them in this way. If they have more than one master, they will eventually lack clarity on things. At that point you can help them with their deflection manuever--call a meeting and find out under which circumstances which boss's requests go through first. Or, call a meeting and help them find out which stakeholder's data reigns most supreme. Then, and this is really important: even if you are not the person whose data reigns supreme, SUPPORT THEM. Frequently when dealing with multiple bosses, you just don't have a choice, and passive aggressive behavior from a sore second-place boss is not going to make them any more productive.

You want people to want to work for you as a manager. To do that, you need to try to make life easier so all they have to worry about is doing the best job they can on their work. Whether you're one or one of a million bosses to someone, you always are shooting to be the best one and the one they work hardest for.


  1. I have generally found that if I put the contending parties in a room together and make sure they don't leave until I have specific marching orders that they agree on it forces a resolution. In fact I am doing that next Monday....so looking forward to it. I feel I shouldn't have to guess which is right, or put myself in a damned if I do/damned if I don't situation. This way they are very clear it is their problem. If they don't decide I either won't implement either of their ideas or that I will make the call and they will just have to live with it...suddenly decisions seem to magically happen :).

  2. Establishing and maintaining a chain of command can often be Step Zero in detoxifying a work environment. Great job analyzing it from a number of different perspectives.

  3. Thanks, Palecur!

    Kristina, I have found that if the total number of stakeholders is over four, putting them all in a room together isn't always helpful, especially if the stakeholders are at varying levels of authority.

    Weirdly, in large groups people don't like to speak their mind (or to their bosses or their bosses peers' in public), which leads to changes almost immediately after a large meeting which can leave you wanting to pull your hair out.

    Meeting with people individually first and getting agreement in the large group about items you know are important to each of them frequently solves that problem (or makes it easier to deflect to someone else after the big meeting). Basically, you're getting each person personally invested in the process, which makes it harder for them to randomly change their minds later (but, sadly, not impossible).

    For six or fewer people all of the same level who are equally ok talking in groups as they are individually, your approach can (and does) work and is often very entertaining in a "bring your popcorn and watch the car crash" sort of way.