Layers of Management == Layers of Veto

DZone 's Guide to

Layers of Management == Layers of Veto

· ·
Free Resource

In an organization with more than one layer of management, the default answer must be "no". Folks get needlessly frustrated by this. But it's a logical consequence of multiple layers of management. Consider that direction must come down from above. If you're suggesting something up to your manager (or in your role as an outsider) the response must be "no". What you're suggesting is not the direction that came from above.

If any manager not at the top says "yes" to you -- an underling our outsider -- they've just committed an act of insubordination to their actual manager. All managers in positions other than the apex, must say "no" or be insubordinate. And the top manager has "outside pressure" to say "no". Approval is largely impossible to obtain except at the very top.

Variations on the Theme

A "no" can come in a variety of forms.

For organizations that are CMM level 1, it's simply "no", without much justification. All ideas that didn't come down from above are inappropriate or unfunded or simply "not on our radar".

For organizations in CMM level 2, there are more complex and ritualistic forms of "no". Often they are filtered by "if it makes business sense." However, making business sense is largely impossible. Marketing doesn't have to jump through elaborate hoops to justify spending money on advertising. They mostly just do using vague back-of-the envelope justification.

For CMM level 3 or higher organizations, there's an approval process, that will net a big old "no" after a lot of work following the defined process.

What Gets Done?

Generally, ideas that come down from the top have a pre-approved "yes". After all, what comes from above was already in this year's budget. It was scheduled for this year. The schedule is sacred.

In a CMM 1 organization, you just do what you're told. In CMM 2 organization, there's some kind of "management" veneer wrapped around the word from on high. In CMM 3 organizations, there's a process to rubber-stamp the stuff that's trickles down from the top to be rubber stamped.

Process doesn't always help. Projects that are ill-defined -- but a pet project of a development director or CIO -- will still be vetted and approved. Projects that come from outside IT are often "more valuable" and get more ready approval, even though there are no more details in those project descriptions.

Projects that bubble up from below, however, have to be be rejected. They weren't in the budget.

Fixing The Approval Process

You pretty much can't fix the approval process. Taking things upstairs to your manager is -- generally -- insubordination. You weren't told to do it, so you're wasting your time, time that could be spent on things that were in the budget for this year.

You can be lucky enough to work for an organization that has little or no management. Such "entrepreneurial" organizations are characterized by more "yes" than "no"; more importantly an entrepreneurial simply has very little management. (Nothing is funnier than training managers to be entrepreneurial. You want entrepreneurial? Make the managers actually write code.)

The only thing you can do in a large organization is to take hostages. If it's a good enough idea, you have to start doing it anyway. Once people catch you at it, then you have to explain what a good idea it it. It will be an uphill fight all the way. No one will ever "greenlight" your idea.

If you're doing the right thing, it may be a struggle, and you will be in trouble until it appears in next year's budget. Then someone else will be assigned to it.

Interestingly, it more-or-less must work this way. Sadly, smart technical people are often unhappy with this. They either don't want to fight for their ideas, or fight too stridently for them. There's a happy medium in the middle of pushing a good idea without alienating managers that are forced to reject what is obviously a good idea.

From http://slott-softwarearchitect.blogspot.com


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}