How to communicate effectively and tackling politics inside the team?

Hello,
In order to stick with his own decision, what should be the approach of an architect so that everyone agrees with his decision without showing much resistance? Is it required to be of dominating nature to some extent?

Also, since there is a chance to become a victim of politics when going against management (mostly in negotiating some technical decision with management,most of them are very unlikely to have strong technical background). How to overcome this problem?

Thanks,
Zico

Zico Gupta wrote:Hello,
In order to stick with his own decision, what should be the approach of an architect so that everyone agrees with his decision without showing much resistance? Is it required to be of dominating nature to some extent?

Also, since there is a chance to become a victim of politics when going against management (mostly in negotiating some technical decision with management,most of them are very unlikely to have strong technical background). How to overcome this problem?

Thanks,
Zico

Hi Zico,

What i have seen from experience is that due to the fact of dealing with non-technical people we have to have quantitative facts to back up our ideas. For once we needed a much required application server upgrade as well as architectural changes which the management perceived as too risky. Once we did a load test on both the new and old architectures/application servers, and showed them the load times and CPU utilization etc they were convinced. Since they do not have the necessary technical backing to take a solid decision, i believe this is the only way you to convince and have a win-win situation. Being dominating will adversely effect on yourself as well the company culture so i will not advice on that.

Hope this helps

Cheers

Dinuka

Zico Gupta wrote: In order to stick with his own decision, what should be the approach of an architect so that everyone agrees with his decision without showing much resistance? Is it required to be of dominating nature to some extent?

It isn't just one person's decision. It is about what is best for the team/what makes sense and the reasons can be communicated so the team buys in. Sometimes the reason is "X and Y are both equivalent, but we are going with X to limit the number of technologies in use". You want people to understand why so they understand the decision and it becomes a team decision. And ideally you want the team's feedback before the decision is made so you can make it a stronger decision.

Zico Gupta wrote:Also, since there is a chance to become a victim of politics when going against management (mostly in negotiating some technical decision with management,most of them are very unlikely to have strong technical background). How to overcome this problem?

Explain it in their knowledge. You are making decisions for cost, quality, maintenance cost, time to market, etc. What benefit does your decision give management. The architect and management should want the same thing - on time, on budget releases for not just this release but future ones. (compromising quality or maintenance inhibit this ability for the next release.) Management may be focused on one because of current pressures, but you can still have the conversation and negotiate.

Hello Dave,
Could you please provide your view on this?

Hi Zico,

Getting everyone to agree is nearly an impossible challenge.

Most major architectural decisions need to be made with a 360 degree view.
• How will the executives perceive the decision? Have you talked to them yet? What do they think? What risks are at play?
• How will new product development perceive the decision? Have you talked to them yet? What will they think? What new capabilities does this bring to market? What is the return on investment? Where does this decision sit with respect to your completion?
• How will technology management (directors, managers, …) view this decision? Do they have the staff to deal with this? How will this affect the budget?
• How will the developers perceive the decision? Is this a direction that will inspire them? Will they want to own and implement it?
• How will this decision affect operations?
• ...

There is no clear cut answer or approach.

You need to account for all of the stakeholders and make the best decision you can. Not everyone will be happy, but if they understand the decision and the rationale behind it – most people will support it if it is in the company’s best interest.

There is an opportunity to build some sales skills when you are doing this – you need to relate the decision to them from their perspective, not yours.

Good question!

Thanks Dave for this useful explanation. From the perspective of Indian IT industries, the point "How will the developers perceive the decision? Is this a direction that will inspire them? Will they want to own and implement it?" is really surprising for me that an proper architect also consult with developers in such extent. Generally, most of them here are manager turned architect and they focus on getting things done 'somehow' by developers without consulting with them in order to earn higher management/client's praise. Most of the time it ends with a highly complex/ tough to maintain features.

You should also be able to explain your point of view. If you really want the rest of the team to follow your policy, rather than another policy, you must convince them your policy is better. And you can only convince them if your policy really is better.

Zico Gupta wrote: with them in order to earn higher management/client's praise.

Getting the software done and meeting commitments also earns praise.

As far as consulting other developers: different people know or think of different things. Getting more opinions makes the decision stronger.