October 06, 2006
Architect Soft Skills - Part V: Organizational Politics
This is my fifth post on the architect's soft skills. The previous post talked about how the architect should understand where the organization is going. This post talks about how you as an architect should understand how the organization is working so that you can make things happen.
Udi Dahan and I co-architected a system awhile ago. One of the key elements of that systems was a servicebus component which we wanted to base on a commercial messaging middleware. Although we both explained why choosing messaging was the best choice for the project very thoroughly to the project leader, another solution based on a proprietary (and fundamentally flawed) distributed objects middleware was constantly suggested and eventually made a constraint (it took four iterations (and a lot of rework later) to convince that a messaging middle-ware is the (much) better solution for that project). What happened here?
Decision making, especially technical decision making, seems like such a logical process. You just look at the alternatives, analyze the merits vs. the problem at hand, and may the best option win. This works out well if you are the king (or work alone which makes you the king by default) -- otherwise there are other people and they won't necessarily agree with you. One reason for that may be they really have another solid opinion, in which case you need negotiate with them , but that has to do with the leadership skill (which I talked about here) or communications skill (which I'll discuss in part VI). The other reason for people to disagree, which is the focus of this post, is that they may have other interests, which run much deeper than the positions the externalize (i.e. their disagreement with you).
Organizations (and the larger they are, the more complex they get) tend to get to decisions by employing a system of rules which encompasses a lot of these interests on top of the rational reasons to agree or disagree. In a sense understanding Organizational Politics is understanding this non-rational influence on the decision making processes. Acquiring the the skill of Organizational Politics means learning to navigate this restless sea.
To return to the anecdote above, it didn't take us too long to understand the real motivation there. It turns out both the project leader boss and a few others recommended buying that component which cost a small fortune, now that it was there (for another project) it had to justify itself by being used everywhere. In this particular case the only way we found to reverse the decision was to prove that it was flawed and to minimize its infiltration into the project (so it will be relatively easy to remove it later). in other cases there might be more cost effective ways to do achieve the desired result.
To be able to do that the first thing to do is understand where you are. This is one of the reasons the first step in the SPAMMED framework is to understand the stakeholders. If you manage to uncover the agendas and interests of the different stakeholders as well as the influence they may have on your project will at least help you pin-point your problems. The complicated part in knowing to navigate and influence the organization . you need interpersonal skills, networking capabilities, schmoozing, and you also need excellent communication skills (which is what I'll talk about in the next part).
The point I am trying to make here is that even though technical people tend to regard organizational politics as dirty you cannot disregard it. Organizational politics can have a severe influence on your project and actions. I didn't talk a lot about how to become more judicious political animal, I am probably not qualified enough to do that (you may want to check some of the resources below though)
More resources:
Posted by Arnon Rotem-Gal-Oz at 03:00 PM Permalink
|
