The Interface Upgrade Project has it down to three vendors, finalists who’ve made it to the last round after an extensive evaluation process. What’s left now is for the project team to put questions to the finalists, ascertaining technical specifics about how their products can integrate with existing systems. After that, the project team will make a decision.
Project manager Carl was too busy to set up the meetings himself, so he asked team lead Arul to do it. Right away, Arul found arranging the meetings was more complicated than he’d expected because critical team members were scheduled to be away at client sites and, although one of the vendors is local, the others have to travel in for the meeting, so more lead time is needed than the schedule allowed for. Arul has his hands full finding conference rooms, making sure everyone who needs to be there will actually be there, and putting together an agenda for the vendors in advance, including the questions they’ll need to answer.
Days into the assignment, as Arul awaits confirmation from the vendors about the new dates he’s proposed, project manager Carl, impatient as he often is, independently sends emails to each vendor.
Hi – Our final review meeting with you is the first week in October. You have received a document with the questions your tech specialists will be asked, the specifics about how we can integrate your product into our environment. Make sure the people you send to us can answer these questions and others that may arise.
Arul is surprised when Carl’s note is forwarded back to him from the vendors with questions: Is Carl handling this now? Have you sent us a document with questions? We haven’t seen it. Is the meeting now back to the first week in October? Or is it still the second? Are the names and job titles of the people we proposed sending not satisfactory?
This isn’t the first time Carl has asked someone to do something and then taken it over himself. Arul, quite annoyed with Carl (once again!), replies to the vendor’s emails and cc’s Carl.
Sorry for the confusion. Please continue to work with me on these arrangements. As you know, the meeting is now scheduled for the second week in October, not the first. The document with questions goes out tomorrow morning. The team you proposed sending is fine. We look forward to meeting you all in person.
This is a small but not uncommon example of both a communication problem and a problem with delegation. In this case, no one was confused for long because the vendors had the good sense to ask. But what if, instead, the vendors had notified their teams of the change in dates and they, meantime, had booked something else? What if the vendors responded to Carl, leaving Arul out of the loop, complaining about not having received the document in question, accusing Carl’s company of providing an advantage to the competition whom, they assumed, already had the document.
You can see how this could go south in a number of ways, and on a larger scale it could be costly, both in time and money.
Delegating
Bottom line: If you ask someone to do something, leave it with them to do it. If you’re wondering how it’s going, ask them. Don’t ask anyone else, and don’t take it over and start doing it yourself. If the person you’ve asked isn’t doing to your satisfaction, tell them so, and be specific. This needs to happen faster. You forgot to notify senior management. Or whatever the specifics are. Give them a chance to fix it.
If it’s an emergency and you can’t wait, explicitly take it back and reassign it or do it yourself. But don’t just jump in and start messing around — even if you think you could fix everything in an instant. That’s probably not how it’s going to end up.
Flat vs. “Tall” Organizations
Some organizations have a “chain of command” to communicate through. In this case, Arul would have been the first line of defense, then Carl, then Carl’s boss, and the further “up” the chain of command you go, the less likely the details are to be correct (e.g., when Carl forgot the meeting had been moved out a week).
But some organizations don’t have this kind of communication protocol. Flat organizations have fewer levels of management than “tall” ones, which have many managers and layers of management. In tall organizations, it’s more customary to follow a chain of command through the task owner to his boss to her boss and so on, following unwritten rules about who talks with whom. Whereas in flat organizations, a lot of communication happens horizontally — that is, people text, Skype, Slack, email, and meet with anyone, regardless of their “level” in the organization.
Does that mean the Carl/Arul problem only happens in tall organizations?
No. Neither the traditional “chain of command” method of communicating nor the open horizontal communication of flat organizations would make much difference in this case because the communication problem between Arul and Carl — and the vendors and the project team — is about ownership. Arul owns the responsibility, and Carl usurped his authority. Whether he did so intentionally, I guess we’ll never know, but regardless of Carl’s motive, that’s what it’s about, appearing to assume responsibility for a work assignment he’d already delegated.
When someone owns a problem or an assignment — it’s been delegated to them, and they’re underway with it — they own it until it’s done, cancelled, or explicitly re-assigned to someone else. The person who owns the assignment also owns the communication about its status, progress, obstacles, triumphs and tribulations, and that applies equally whether lines of communication are open across all levels, as in flat organizations, or whether communication follows a chain of command protocol.
Motives
Why does someone usurp authority from someone else? There are plenty of answers to that, and some of them are noble and kind.
For example, maybe they don’t know intervening is a problem. When someone is new to delegation, they’re more likely to lack clarity about how delegating should work, even if they’ve been delegated to before. Suddenly they’re trying to make sure things they’ve delegated are progressing, are on track, because they know ultimately the responsibility rolls uphill, and suddenly they find themselves uphill.
And maybe they honestly thought their help would be appreciated, not resented. They didn’t anticipate the confusion they were causing, or even see the confusion that resulted.
Another reason someone might hold too tightly onto a responsibility is that it was theirs in the first place and they were forced to delegate it. That means they’ll have a bigger than usual stake in the outcome and they’re probably going to hover over the person who’s got it now.
I realize that’s not how most people who’ve had their authority usurped see things. Like Arul, most people get annoyed, and when a manager does it repeatedly, it damages relationships. Why? Because those of us who’ve had our responsibility meddled with feel that our ability to do the job is in question, and if there’s one thing we guard pretty carefully it’s our reputation. A manager who snatches back a responsibility that we thought we were handling just fine becomes, in our mind, an adversary.
And then there’s the reason we usually ascribe to the problem of the meddlesome manager trying to seize our authority: they’re power mongers trying to swing their weight around and make us look bad. Yeah, maybe. I worked for someone like that once, and it was her consistent pattern to do this. But in all the managers I’ve had in my career, she was the only one on a power trip. The others who’ve been problematic delegaters have done so for reasons that are understandable.
So if you’re in a position to delegate to others, watch out for the line between helping and meddling, and try not to cross it. And if you’re being meddled with, maybe you could forward this article along with a note saying how much you enjoyed reading it and maybe they would too.
Susan de la Vergne is a writer and communication instructor who worked in software development and Information Technology leadership for a very long time. Susan is the author of Engineers on Stage: Presentation Skills for Technical Professionals. Find more of her Cogent Communicator columns here.
