Fog Creek Software
Discussion Board

Software development team structure

I'm a software development professional, and I'm organizing a project team for a new development initiative.  This will include some recruiting of new team members and the use of team members from our partner company, a very large commercial software development company.  I have no experience in working on a commercial effort with resources from two different organizations.

I'm concerned about two issues.  First, how to define the roles of the team members that are recruited to work for my company versus the team members from the commercial development partner.  Their resources are supposed to be "experts", but we all know that the place where someone works is never a good indicator of their level of skill.  I have full control when it comes to managing the technical aspects of the project, so control of team structure and/or delegation of development assignments are not an issue.  What is the best way to make these two separate groups form a cohesive team?

The second issue I'm concerned about is team leadership.  I want to create several lead positions on the team to be responsible for certain product features.  What is the best way to communicate these messages to the team?  What can I do to help ensure that team members will not become disengaged from the project if they expect to be selected but eventually will not be?

Any feedback on this multi-organization project would be greatly appreciated.

software development professional
Monday, January 7, 2002

Get yourseleve the book called 'The Pragmatic Programmer'. You'll find some good tips in there. I highly recommend the book. It has helped me in more ways than I can ever be thankfull for. I too was in the same position once.


Nigel Soden
Monday, January 7, 2002

The Mythical Man-Month -- if you don't know it, shame on you.  Its the original about the topic.  I also liked a 2 book series called Professional Programming.  But I can't remember the writer....

Joel Goldstick
Monday, January 7, 2002

Of course I know about the Mythical Man Month.  I've read a number of books on these subjects, including the basics (MMM, Code Complete, Peopleware, etc.). 

I'm really looking for personal insights coming from readers who have had an experience working in such a team environment.  What worked?  What didn't work?  What made you want to throw your computer out the window?

Any insights would be appreciated.

software development professional
Monday, January 7, 2002

On assigning project leads:  be decisive and unambiguous.  Sounds obvious, but I've seen all too often a case where a manager invented a new team lead position, told that person they were the lead, and that was that.  No announcement to anyone else, no coaching the new person on what was expected of them as a lead, nothing.  With exceptional people and luck, you may still get good results, but most people will simply flop around like a dying fish, trying to figure out what to do, and not having the clear authority to do it.

Announce the changes (if possible) at some meeting where you have all of the affected parties present.  Make sure everyone knows who the new leads are, and who reports to them.  During the transition, follow up and ensure that all of a lead's reports know who they report to unambiguously.  Don't assume everyone is instantly going to get it just because you'd decided it.

Reinforce this by actually delegating responsibilty and authority to those leads.  If people come to you instead of the lead, refer them back to the lead.  Obviously, if that happens often, you may have a problem with that lead.  If you don't fully delegate, you might as well not delegate at all.  Few things are more morale destroying than being a line worker with two or more people giving them conflicting tasks.

Can't help you much on the two organizations problem.  Joint ventures are often troublesome, esp. when one firm turns out better product than the other.  I'd try to create a third "virtual" organization, and try to make everyone feel like they're part of THAT organization. Make them all feel responsible for the output of that organization only.  If you can avoid factionalism, it will work. 

James Montebello
Monday, January 7, 2002

A good start to a multi-organisational project is a (partly) informal project kick-off. It should be a meeting where everyone have a chance to know each other as a person. You should create a real project team instead of two organisational based teams, which might happen if the persons do not know each other very well.

Define responsibilities very clearly and communicate them to every person involved. In every case, you, as a project leader, have to concentrate into communication.

Treat every person equally, regardless of organisation they originate.

Reni Waegelein
Wednesday, January 9, 2002

my personal experience from having worked in a similar development effort where part of the team was from the customer & the other half from a 3rd party consultancy firm (mine)...

1. be sure that whenever you make a decision, the actual company to which the person belongs shouldnt be a factor.

2. teamleads should be selected based on their skills.. having a few team leads from the outside firm will go a long way in building a better cohesive team.

3. get a nice communication flow setup within the team... many times a developer feels really pissed off when he gets to know abt an important business rule change or design change very lately...

ramesh kr
Monday, January 21, 2002

*  Recent Topics

*  Fog Creek Home