How to Politely Refuse Changing Decisions

Question

I just launched a game with a small virtual team of three (plus myself). It was quite successful. We made some decisions like using email as our primary communication medium, and iRC as our primary chat mechanism.

Now, three other new people have joined the team. (We're an informal collection, unpaid, collaborating on a common interest.) Some of those decisions, and others, are being challenged.

I know that the right move is to remain with the decision, because I personally spent countless hours researching and reaching the same conclusion from different angles about these decisions. I cannot indulge in churn from re-opening old decisions every time someone new shows up.

So for now, the decisions are irreversible, barring unforseen circumstances.

How do I communicate this? I need ultimately to get buy-in from the team on any given decision, don't I? But it's a team of individuals with strong opinions -- some may buy in and go forward accepting it, and others may do so because it's required of them on the team, while still others may continue to challenge it at every opportunity.

Answer 1

If you want to build consensus, tell the new team members that this how the team currently operates. Over time, as the new team members become more integrated and you each learn more about each other, you may want to revisit the choices.

If consensus doesn't work or it doesn't fit other constraints on the project (e.g. time), tell them that that's the way it is.

Answer 2

A critical success factor for a team like this is for it to be high performing, a team whose members are in sync, collaborative, supportive, with a sense of collective success/failure. The team roles, like if you use Belbin's definitions, need to be filled by the individuals, which almost naturally occurs with a bit of coaching and guidance. If you buy into the teaming process--forming, storming, etc.--then you need to go through these stages to get to a high performing state. The introduction of new members, a member leaving, or some other change can and most likely will cause the team to decompensate, returning to an earlier stage. So when you go through this change, the dynamics of the team change, roles are up for grabs again, and the team starts over from the forming stage.

Trying to squelch this because it is inconvenient will likely mean your team will never gel, members will be disgruntled, and eventually your team will likely implode.

You have the alternative of not altering your team and sticking with the original three. If you must change it, then you must accept the decompensation and go through the process again, which means addressing rules of engagement, identifying roles, revisiting decisions made, and getting angry with each other. But through that process, the team will return to its high performing state and, with the additional team members, may be even more productive than before.

So either kick them off or invest the time to make them true team members.

Answer 3

Here are some questions I'd like to ask them:

• Software isn't free. Every change requires maintenance. If you have to stop spam or create security for two or four or ten channels instead of one, that will be expensive. How are they planning to ensure maintenance for these going forward, given that they're volunteers with no guarantee of being around?

• Working on one capability always happens at the expense of another, and the only things keeping your software alive are the things which make you different to other competing products. Does this help you differentiate yourself? Or are you able to survive in your niche without it? Will it help you to grow your share of the market?

• Because you're working as volunteers, you've done it out of passion and a desire to learn. The newcomers are approaching with ideas that you're not passionate about. What are they offering you in return for trying those ideas out? What are they offering you in return for learning on your code base?

Chances are that the answers to questions like these aren't things they've thought about, but which will be behind your reluctance to adopt their ideas. Helping them to understand the cost of their ideas is a polite way to refuse them.

I would also share the words you've written here - that you've already done a lot of research and that you don't want to indulge churn by re-opening new decisions. It might be useful to put those decisions into the backlog with a note about why they were made that way or (better) who to talk to about the decision, so that the team can understand that this isn't arbitrary.

Answer 4

First off, I would think your question does not really mean, how to refuse the ideas. Probably, you are thinking on what to do, and find good reasons for that.

Considerations

You should admit many factors and consider them very carefully:

1. Developers tend to come up with ideas of dumping everything and re-writing from scratch. It's just like things are, you cannot change it;
2. Time to market. Often, a buggy program in a vacant market niche is more successful that perfect one that came a month later;
3. Motivation of team members, both "old" and "new" ones; If you follow suggestions, you may demotivate your existing team members; If you resist, you demotivate the others.
4. If your team is multicultural, I would also consider this;
5. Development costs for each decision, each individual task or assignment, as @Lunivore noticed. Not only coding itself, but effort of QA, Architects, and even Tech Writes should be counted.

What can be done

Now, when the factors are listed, one can find adequate solutions. Here are some:

1. Define costs. It does not matter if you're unpaid. A simple tracker counting work hours, not dollars, would be your friend.
2. Educate your team. Even if they are "just coders" (I hate this word, but it's too much common), spend your time to teach them the major principles.
   • In particular, they should learn about costs, quality, and time. Teach them about the PM triangle;
   • It would be great to show your new team members the chart and say them, "the change you are suggesting would make these 50 man-hours obsolete. What do we get in return?"
   • Teach them about time-to-market. In my experience, many developers have never heard about it, perfecting their code.
3. Always record all change requests in your issue tracker. The issue may even stay Closed/Won'tDo, but it will never be forgotten and may have important discussions (versus searching it in mailbox).
   • You may promise them a meeting just after initial public release for re-considering those ideas (don't forget to keep the promise:).
4. Misc
   • Kicking them off is the last resort, and should be used carefully, simply because those who uphold their point may grow your next Lead Developer.

As conclusion, all factors have different weight, depending on your very team and project. Here you may get some suggestions, but actual priorities are to be set individually, according your PM talent, expertise, and intuition.

Answer 5

Do you have a defined governance strategy? Is it hierarchical, consensus, something in-between?

Are these "cast in stone" decisions well-documented as such? Or are they merely "team folklore?"

Does your process for adding new people require them to agree to existing, documented agreements?

These questions may not help your current situation, but they will be useful to address before you do such a thing again.