Wednesday, June 24, 2009
Enterprise Architecture: Handling individuals who are always unappreciative...
In my travels, I have met lots of good people that are hard working, honest and accepts their mistakes. Nowadays, those who stand by their word are sometimes blamed for things they haven't done. The bar of what constitutes a valid reason for blame is constantly being lowered. The health and well-being of others in this culture is deteriorated to the point where the masses are popping pills for high blood pressure or other ailments, yet this can be rationalized as casual cliches that roll off the tongue such as perception is reality.
I believe perception management is important, but focusing on the human condition to be more important. Are you in the matrix where folks have forgotten the fine art of blaming oneself first? Is management pretending that they are leadership by allowing a culture to fester where someone or something has to take the blame? If we learn to look for causes of problems without looking for scapegoats, we may learn a way to convince our ultimate customer no to blame everything that goes wrong within an IT ecosystem on technologists.
One tactic that seems to work in some shops is to avoid blame by being absent. Consider that blame is usually spread whenever a hard decision has to be made late in a project due to problems with quality. The tradeoffs usually involve either shipping a sub-standard product on time or delaying the ship date in order to solve the quality problem. Both answers in a perception management culture will create negative impressions. The correct choice is difficult to determine but making the wrong one will have an impact on your career and compensation.
You cannot share in the collective blame of making the wrong decision if you are not present when it was made. It is best to position yourself where you can leverage hindsight which is always 20/20. When it becomes clear which decision was the correct one, you can support it retroactively. Practice phrases such as Obviously, I would have voted to ship late. I only wish I had been present for that crucial decision. I was shocked to find Lucas had decided to ship what was obviously a sub-standard product. You will of course reverse this if required.
This approach can be even more effective if you are absent at the beginning of the project. If it fails miserably, you can claim that you knew the project should never have been initiated in the first place. If it succeeds, it's only because you were brought in to save it.
Another approach is to get yourself deeply involved in other projects or business development activities, and then claim that you are just too swamped with other higher priority projects to worry about the one that is in trouble. With skill, you can shift priorities around and ensure that whichever project is in the most trouble at any point in time will have the lowest priority.
Links to this post: