The only way to know how evil management is, is to be part of it. An anecdote.

I turn up at work, wearing a three-piece suit, a white shirt, a tie and shiny shoes. My colleages greeted me with supprised faces: "It suits you, but it really isn't you. Why are you all dressed up like that?".

Me: "Remember, we have a meeting today and our customer is bringing some big brass".

Colleages: "Yeah, so?".

Me: "Also remember what is on the agenda? A presentation from the technical project leader".

Colleages: "Yeah, but what has that to do with you?"

Me: "Well, I am the technical project leader. It is my presentation, today".

Colleages: "You? How come? Since when?".

Me: "You never asked why I was present at your interview for this project?"

Colleages: "Hm, no".

Me: "You never wondered why I am the one asking for your estimates about the tasks you are assigned? Or why it is me who suggest what to do next and reviewing your work with you?"

Colleages: "No. That is just what you do".

Me: "You never stopped and thought why it is me who introduces you to those in the company that you will need to coordinate your efforts with? Why I often attend those meetings and why I talk to you about how a certain meeting went that I wasn't present at?".

Colleages: "No. It kind of works that way."

Me, to one of the colleages: "You never thought is was strange that I was the one who told you to continue and to only come back to me when there is a problem?"

Colleage: "No, but as I am working independent now, what is it that makes you the project leader?"

Me: "Simply: if you screw up, I am the one that gets the blame. That goes for every one of you."

For a big part, I have it easy. At heart I am still a programmer and every bit as good as the best programmer of the team. I am always a step ahead of my collegeas because I know where things are heading. Basically, we work on my design, so I understand what is going on. And I have programmed in over fifty programming languages on over ten different platform (including CP/M, DOS, VAX/VMS, System/36, Windows, Unix SystemV, MacOS/MacOSX and many, many others), so I kind of have a huge reference framework that I think not many developers have.

I do the "heavy-lifting" modules that my colleages then use in various modules. This allows me to keep track of what they are doing in a very natural way.

However, being screwed is only a mind-set. In the early phases of a project I write some documentation. Part of it is a list of factors that are critical for the project to succeed. Remember, I am only the leader responsible for the technical aspects of the project. So, at a certain point some of the prerequisists aren't met yet: a server isn't made available, we don't have the kind of location where we can work or talk, staffing is less then planned, access to certain apps or to certain services isn't implemented, purchases aren't made. That kind of things.

These points I take up with several managers. They make choices: either they fullfill the requirements or they don't. The only thing I have to do is to make sure that the manager understands the choice he is making. If they understand and still are not helping to get everything in order, then they simply choose that the project will fall behind. It is no more complicated then that.

As long as I am only an employee, why should that bother me to the point that I loose sleep over it or get angry? Even as the responsible manager? It is the project that is screwed, not me. Any conversation about not meeting goals can be restricted to simple facts: I am only the messenger. A manager higher then me who doesn't like the current state of the project needs to take that up with his peer manager who chose not to provide nessecary requirements.

The same goes with "difficult colleages" that are in a position where I depend on them. Simply make them say out loud that they are not helping you or show how a promiss is broken over and over and make that a point for the next progress meeting for the project. There is no reason to fight that person: if a manager wants to see the project succeed, they'll pick that fight for you. If the manager doesn't see a reason to take action, why should I? (The choice I made some time ago: from a technical point of view, if it can't be fixed in software, it is not my problem. I am rather flexible, but this is where I sometimes draw the line.)

Just as I say to my teammembers that if they screw up, that I am to blame, so I say to a manager above me that if I screw up that he is to blame. I use it as a trump to delegate upwards. When played correctly, it works. You can play that card up the highest level of management that you can get an appointment with.

Ok, I wasn't that relaxed the first time I happened to be in such a situation. Or the second time. Nor the third. But I am doing whatever I can do. I still try to make progress. I still try to conduct the lightning bolts from angry members of the team so nobody gets hurt. I still try to get all the requirements met. I am responsible for the work my colleages do and for the project in general.

However, there is no reason for me to take a project more personal then colleages with more responsibilities. Perhaps here in lies a key: I see no difference between the colleage wiping the floor and the colleage that has a plate on the door of his office saying "CEO".

If a project is at a track to nowhere, then it is time to look outside the box. The result has been that I had to make "career choices": stay with a company or find work elsewhere, move between departments or business units. These are difficult decissions, but sometimes that is the only thing left to do.

If you find yourself in a situation that nobody takes your work seriously, then there is just one thing that you need to focus on: portable skills. Make sure you are not working with yesteryears tools or last-century's platforms. You can always make a case that it is for the benefit of the company, although you might need to bend the truth on how it relates to the project you are supposed to be working on. Make sure that if you need to jump ship, that you know how to keep yourself afloat.