Mr. Lott has been involved in over 70 software development projects in a career that spans 30 years. He has worked in the capacity of internet strategist, software architect, project leader, DBA, programmer. Since 1993 he has been focused on data warehousing and the associated e-business architectures that make the right data available to the right people to support their business decision-making. Steven is a DZone MVB and is not an employee of DZone and has posted 139 posts at DZone. You can read more from them at their website. View Full User Profile

Layers of Management == Layers of Veto

02.13.2010
| 6659 views |
  • submit to reddit

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

Published at DZone with permission of Steven Lott, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Seb Cha replied on Sun, 2010/02/14 - 7:12am

Hello Steven,

I'm actually in this situation. We worked on an ESB architecture, but all software architects assigned to this project came from the MainFrame world. They knew nothing about ESB concepts, MOM, SOA, BPMs, how and when use them, etc... They imposed to write a kind of poor proprietary BPM language that generates ESB language (yes you're reading it right). It's like wrap a wheel with a square to improve the roundness.

The project is going crazy with more than hundred technical classes for each WebService operation, and more than thousand beans in spring applicationcontext (for each operation too). Managers said that all is "quite right" but asked why the application is damnly slow. We are Death Marching already.

I've done 3 proof-of-concept 1000 times simpler, with far better performances, which could end the project in few weeks only. But nobody want to see the evidence.

 

Artur Sobierajczyk replied on Sun, 2010/02/14 - 7:35am

Sadly, you are very right. My examples:

1) My proposal of evaluating a better PDF library was refused ("currently it works, no time for it"), but when some higher-level manager asked for it later it resulted in a high-priority task.

2) We (programmers) prepared list of needed refactorings/optimizations with explanations why they are needed. Management refused it without even trying to understand ("too much time, no effect; are you kidding?"). Now they are forced to implement some of our changes with bigger cost because of errors on production or unacceptable performance. Some of the improvements which eg. give significant improvement in coding time will never be implemented because they don't trust us and are too dumb to understand our proposals!

I'm really sick of such corporate structure and it's why I'm moving away of it...

Artur Sobierajczyk replied on Sun, 2010/02/14 - 7:56am in response to: Artur Sobierajczyk

One more comment about these "dumb managers". I'm wrong here - I know how they work and what are motivations for their decisions and they are not Bad People. It's simply corporate structure which forces them to think not in terms of real value produced by a project, but in terms of short-term "business" success politically defined by their director.

Endre Varga replied on Mon, 2010/02/15 - 4:38am

One serious problem is that the managers usually do not know a damn thing about software, and therefore they are looking at every proposal with suspicion. They are convinced that you are inherently lazy, and want to cheat them. It is very sad, as I *love* my work, and even if I am lazy, I am not lazy enough to make a shitty software.

Endre Varga replied on Mon, 2010/02/15 - 4:41am

Even worse if they know *something* about software, because that is usually plain obsolete. In this case they make a serious effort to look competent, and they refuse your proposals more brutally -- because it may make them look dumb.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.