Getting developers to work together

You have a classic clash of wills. Your team can be likened to a bunch of rebellious teenagers who relish defying you just for the hell of it. Many techies are notorious for pushing a manager's buttons because they want to do things their way. I have a couple of suggestions. Don't get tough, not now at any rate. They expect it. The idea is to get things done or the heat from management will only become more intense. What's needed is unity and that comes from a meeting explaining the results of not working together. The CEO will be furious, products will suffer and customers will be outraged. The result is lower margins. The boss of boss, the CEO, calls the shots and defiant developers will have to tow the line or they're history. And, I strongly suggest that you take some management courses so you know how to handle this sort of problem when it occurs again. You sound like you're floundering.

You seem to be in a unique situation of having good qualified developers who have good solid experience!! By virtue of these people having suitable working experience (notwithstanding their egos), they should be in a position to see the big picture and work towards it. You would probably be better off in taking your developers into confidence, share the plans, or better still evolve the plans and designs in full consultation with them. With this, they will get the ownership and bring commitmentto the project. You also need to reinforce and impress the importance of teamwork. In a typical development environment, all the cogs in the wheel have to work in unison for the success of the project and themselves. Once these people understand these fundamental tenets of teamwork, they should be able to turn around and you should be able to direct their egos to the success of the project and yourself. You might have tried some or all of the above, and I am sure that you are aware that there are no short term solutions for this. In the meanwhile, keep your supervisors informed about the progress (or even lack of it).

There is another way that I have seen employed that seems to work just fine with team members who are not compatible. As the team leader, you must divide the project into divisible segments and then assign a segment to each of the team members. Then they communicate only with you; who coordinates each members contributions so they will mesh with each others contributions. Each works independently of the other and as such has not reason to criticize the others work or opinions. As the team leader you retain full control and responsibility, which you obstensibly have anyway. The other option is to let them know in no uncertain terms that you make all the final decisions and anyone who cannot accept that can leave the team. There is a time for democratic team building and a time for an enlightened monarchy.

One of the key issues in project management is to have Executive level support & guidance. If you can't negotiate a win/win solution with the team, have an executive member join the group and provide direction. Another method would be to set up a group decsion support system where all could air their ideas and differences without anyone knowing specifically whose idea it was, and then as group, decide upon the best method of how to handle the issues at hand from the ideas presented.

Ask each one to define "suggested improvements" for each of the other solutions. By doing so they will each understand what the other solutions are and will see by the suggested improvements to their idea that they can create better solutions by working together.

Try and promote team work by open communications and "Brain Storming" sessions etc. But at the end of the day, you are in charge of the project and in which direction the project will go.

You are obligated to let you team know that you are the boss, and that your choices are final (even if it means removing individuals from the team!!!).

If you need to feel more comfortable, inform upper management of what you are doing and get suggestions on how to handle the situation, but by no means invite them into your discussions with your subordinated. If you did envite your superiours in, you will loose all authority over the project.

Good luck, and hang in there

I've handled some situations like this, where this was one of the problems I've seen, but I hesitate to say anything without knowing a little more. If we were having some coffee in the office, I'd ask, what's the environment? how much authority do you have with them? is this your first leadership role, and if so, how comfortable with it are you? what about your team? Are they new hires too? Did they know each other? Do they have history? Are they from different groups on loan? are they jugglingyour project along with many others? What about the project itself? Is it delayed? Is it doomed? Were there morale issues and other problems when you came on board? How about now? Was this a turnaround assignment? How is it doing today? Answering these questions may give you some insight into the root causes of these conflicts.

The first goal should be getting them to work together, just for an hour.

Next time you have a technical issue, have a brainstorming session. Pull everyone into a conference room with a really big white board. Set out the problem, and go aroundthe roon and getting suggestions of solutions from each person. Write each one down, leaving plenty of spain between.

Go back to the first solution. Go around the room and ask everybody to identify a "pro" for that solution. Write these on thewrite board under the first suggestion. Then have everybody identify a "con" with the first solution. Write these down, too. Repeat this for each of the suggestions.

Be strict in running this meeting. If anyone gets personal, shut them down. Make them focus on the suggestion, not the other egos at the table. Make them be constructive, thinking of "pros" as well as "cons" to other people's ideas.

If you can keep it constructive for an hour, you've got a chance.

First things first. You're in charge. Your boss ppicked you for obvious reasons and I would like to think it was, you can get the job done.

Second, have you had a sit down session with the developers on the goals and objectives of the project?Have you delineated responsibilities? Do you know your key peoples weaknesses and strengths? Who can you count on to do various specialty type work?

I think you just need to establish two organization charts, one for Operations and the other for Administration. You ought to establish some sort of review process to address suggestions from the "ranks."

There are a host of other areas that could be discussed, but I only have time to offer these to you.

Good Luck,

Javier

When dealing with large egos, it is absolutely necessary to be seen as in charge. From personal experience and being one who can have a large ego, I will walk all over or try to manipulate the person in charge if I see they are being weak or indecisive. It?s not something that is intentional, it is instinct. Like being an experienced and talented hunter. You just know what prey to take that will be the easiest.

A team of developers with a minimum of eight years of development experience cannot have entirely different ways to reach the specified goal. However, if their egos are as large as you imply, then they may see their ideas as completely independent. Perhaps it would be a good idea to review the various proposals and ideas andfind some commonality among them. Sure the ideas may be presented in different terms with different words, but a rose by any other name is still a rose. Then from there, find where they diverge.

Then sit with them, go over the similarities. A person with a big ego will then latch onto how different their ideas are then the others. After all, they are vying for rank like rams during mating season. Once everything is established and positions are taken, consider doing what the Senior VP of my company did during a battle of developers who wanted their projects put at the top of the list.

He got the developers and asked them who would stake their jobs and reputations that their ideas would work and are the best. No one stood up, and they went back and began to review the other proposals.

Big egos wont put themselves in a position to be publicly humiliated in front of executive management

I have seen this problem persists with the technical
groups. They develop big egos and want to project
that, they are better than others. They indirectly start
hitting the other person with a simple sentence 'don't
you know this? This isthe basic man'.

We can use their egos to produce the results. Just ask
them to produce their designs and each make a
presentation to convince the others. Let the design that
is best and practical be selected through voting to go
ahead.Do not forget to go ahead with the following.
Call a meeting and tell them with their big agos they are
jeopardizing the project. Finally every body would get
fired for not delivering the right product , despite having
the best skills.
The first thing to make it clear to them is, 'we are all
here to work together and all are tested thoroughly
before being recruited for the job. Any body making
effort to test others is showing off and it would not be
tolerated'.

Thanks,
Rama

Establish a list of key criteria that must be satisfied and have each developer write how his/her approach satisfies the criteria. then show consolidated results to everyone and discuss. Recommend you read the book "GEtting to the Yes", which provides excellent guidance on effective negotiation.

If strong disagreement continues after the above discussion, consider dividing the team into smaller teams and have all of them work the same portion/module of software. See who completes development and successful test first, and go with their approach with the rest - in other words, consider a competition of parallel efforts, which is one schedule risk reduction technique for complex software.