12

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.

Improve this question
6

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.

Improve this answer
  • +1 - When you're the new guy, the thing to do is first learn how things are done, not try to change the current status-quo. – jmort253 Jun 28 '12 at 19:30
  • Thanks, I tried this, and it actually worked really well. – ashes999 Jul 3 '12 at 20:12
  • @ashes999 That's great! – Mark Phillips Jul 3 '12 at 20:39
3

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.

Improve this answer
  • So are you saying Ashes should still fervently argue his points with the team, but not say "this is how it is", yet at the same time he shouldn't just roll over and give in to the desires of the new collective without challenging them? Is this what you're trying to say? Thanks. – jmort253 Jun 28 '12 at 23:17
  • 1
    Exactly, Jmort253! I mean, I know it would frustrating to revisit passed decisions, and hopefully the team would agree to limit that; however, it is a new team, a new dynamic, a new direction, etc. Building the team trumps the inconvenience of it all, I think. – David Espina Jun 28 '12 at 23:37
  • Or said another way, the value of doing this all over again would exceed the cost of doing it.... – David Espina Jun 28 '12 at 23:38
  • I think it's also worth pointing out that results from research are subject to interpretation. Even numbers and statistics, which are generally looked at as concrete, must oftentimes be interpreted, and depending on who interprets them, the results of the interpretation may differ. – jmort253 Jun 29 '12 at 1:22
  • I know you tried to answer my question, but I feel like this is not really an answer I can use. – ashes999 Jun 29 '12 at 2:56
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.

Improve this answer
  • Should the new team members get an opportunity to scrutinize that research? If the op did the research, should he not present it and let the new members weigh in as well? Research results, after all, are subject to interpretation. – jmort253 Jun 29 '12 at 1:18
  • This doesn't really answer my question. – ashes999 Jun 29 '12 at 2:56
  • Edited to make it clearer. – Lunivore Jun 29 '12 at 6:41
2

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.

Improve this answer
1

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.

Improve this answer
  • Good points, I would add these as a comment. We have a defined strategy (a mix of consensus with some top-down directives); decisions are documented and written in stone, unless the stone gets obliterated by lighting bolts. We don't require them to agree, only to conform. – ashes999 Jul 3 '12 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.