At Brainstorm
last night, one of the subjects we discussed was the common practice of
management from below and how some of its effects can be downright devastating
on a business. In fact, several of the biggest failures I have ever witnessed
were the direct result of subordinates knowingly hiding information from their
superiors. It was a spirited discussion, as more than a few people copped to
regularly utilizing the practice, and one participant emailed a few of his
subsequent thoughts:
I wanted to share some thoughts from last night's Brainstorm on "Managing from Below". No real solutions; just some experiences from work.
My experience with "management from below" comes as part of mentoring junior officers and enlisted on the larger concept of Leadership. I'm currently group lead for [single-digit] people, all junior to me in rank. We have about [double-digit] projects or tasks ongoing at any one time. My peer and I dole out tasks to the group members and pick the critical ones to keep for ourselves. These projects usually are interrelated or are builders - one relying on another. We layout processes for completion where needed and lay down internal timelines to meet external requirements. Pretty standard.
For the more junior of the staff, the challenge is how to balance responsibility for their project with how much decision authority do they have, or as my guys would say, flexibility in solution. In most cases, before they start the work, we've talked about what output is needed, the deadlines to hit, external groups who require coordination along the way, possible roadblocks, and how to get past them. Guidance I give is (1) I want the output we agreed upon, (2) I want to meet the time line we agreed to follow, (3) I want to know if there are internal or external factors or "bad actors" the staffer can't sort out, and (4) I want periodic status updates. Outside these parameters, unless it's illegal, immoral, or unethical, find me a solution and get the output to me on time.
The threat for the junior staff is that they don't want to be seen as someone who needs hand-holding or someone who can't do their job, so they struggle with things longer than they should, trying to find the solution on their own and avoiding help. Just as you pointed out last night, they start dissembling and getting vague with status. The problem is they now unknowingly (or knowingly) violate Rule 3 above. We call that "Blindsiding Your Boss", and its a no-no.
A solution that worked for me is the 15-minute stand-up. A weekly meeting where each team member has about 90 seconds to give hard facts on project status and a meets/does not meet status for the project time line. Invariably, the people who are having problems with Rule 3 go soft on data. The "softy" gets pulled aside after the stand-up to get some private questions and sort what the real issues are. Rule 3 compliers fess up and tell the boss what's up. At this point, one or more other staff usually volunteer to help and its tabled. We finish the 15-minute meeting and go into a huddle to discuss how to resolve the road block.
The staffer who needs help either gets a support intervention to solve an external threat by me or my peer, or a leg up from another junior staffer. The staffer in the bind still leads the project unless they
ID themselves as unable. We'll juggle the projects a bit in most cases and figure out how to get the staffer spun up through another task or project.
This method seems to work in most cases. Most staffers who see roadblocks or issues now don't wait for Monday to let my peer and me know about issues they can't solve. Often a short huddle gives them a couple fresh ideas and they go back at it. Sometimes we have to do more to sort the issue, but we aren't surprised by it before it is too late to recover. We call this "managing the boss" and its really about keeping the boss informed so the project can succeed, but it's not what you were talking about last night. What you were talking about is "assuming responsibility you don't have".
My concern with some of the folks in Brainstorm is that as subject matter experts, we get to thinking we *know* the real solution. Why can't management see it? Why can't the boss understand it? This is usually due to the subject matter expert having a very narrow view of the problem. This then devolves into taking actions without talking to management and leadership, due to either fear or pride. Problem is if the SME has no clue as to the larger organizational challenges or direction they can tank the larger projects. People get used to your version of "managing the boss", thinking they are saving the company when they do it or it became a self-preservation tool, and they stick with it when they go elsewhere in many instances. It's hard to break someone out of this once they fall into this habit.
I wanted to share some thoughts from last night's Brainstorm on "Managing from Below". No real solutions; just some experiences from work.
My experience with "management from below" comes as part of mentoring junior officers and enlisted on the larger concept of Leadership. I'm currently group lead for [single-digit] people, all junior to me in rank. We have about [double-digit] projects or tasks ongoing at any one time. My peer and I dole out tasks to the group members and pick the critical ones to keep for ourselves. These projects usually are interrelated or are builders - one relying on another. We layout processes for completion where needed and lay down internal timelines to meet external requirements. Pretty standard.
For the more junior of the staff, the challenge is how to balance responsibility for their project with how much decision authority do they have, or as my guys would say, flexibility in solution. In most cases, before they start the work, we've talked about what output is needed, the deadlines to hit, external groups who require coordination along the way, possible roadblocks, and how to get past them. Guidance I give is (1) I want the output we agreed upon, (2) I want to meet the time line we agreed to follow, (3) I want to know if there are internal or external factors or "bad actors" the staffer can't sort out, and (4) I want periodic status updates. Outside these parameters, unless it's illegal, immoral, or unethical, find me a solution and get the output to me on time.
The threat for the junior staff is that they don't want to be seen as someone who needs hand-holding or someone who can't do their job, so they struggle with things longer than they should, trying to find the solution on their own and avoiding help. Just as you pointed out last night, they start dissembling and getting vague with status. The problem is they now unknowingly (or knowingly) violate Rule 3 above. We call that "Blindsiding Your Boss", and its a no-no.
A solution that worked for me is the 15-minute stand-up. A weekly meeting where each team member has about 90 seconds to give hard facts on project status and a meets/does not meet status for the project time line. Invariably, the people who are having problems with Rule 3 go soft on data. The "softy" gets pulled aside after the stand-up to get some private questions and sort what the real issues are. Rule 3 compliers fess up and tell the boss what's up. At this point, one or more other staff usually volunteer to help and its tabled. We finish the 15-minute meeting and go into a huddle to discuss how to resolve the road block.
The staffer who needs help either gets a support intervention to solve an external threat by me or my peer, or a leg up from another junior staffer. The staffer in the bind still leads the project unless they
ID themselves as unable. We'll juggle the projects a bit in most cases and figure out how to get the staffer spun up through another task or project.
This method seems to work in most cases. Most staffers who see roadblocks or issues now don't wait for Monday to let my peer and me know about issues they can't solve. Often a short huddle gives them a couple fresh ideas and they go back at it. Sometimes we have to do more to sort the issue, but we aren't surprised by it before it is too late to recover. We call this "managing the boss" and its really about keeping the boss informed so the project can succeed, but it's not what you were talking about last night. What you were talking about is "assuming responsibility you don't have".
My concern with some of the folks in Brainstorm is that as subject matter experts, we get to thinking we *know* the real solution. Why can't management see it? Why can't the boss understand it? This is usually due to the subject matter expert having a very narrow view of the problem. This then devolves into taking actions without talking to management and leadership, due to either fear or pride. Problem is if the SME has no clue as to the larger organizational challenges or direction they can tank the larger projects. People get used to your version of "managing the boss", thinking they are saving the company when they do it or it became a self-preservation tool, and they stick with it when they go elsewhere in many instances. It's hard to break someone out of this once they fall into this habit.
