Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My team built a website for a client several years ago. The site taffic has been growing very quickly and our client has been asking us to grow our team to fill their maintenance and feature request needs.

We started with a small number of developers, and our team has grown - now we're in the double digits.

What management/development changes are the most beneficial when team grows from small "garage-size" team to 10+ developers?

share|improve this question
1  
You might want to split out the management portion of the question and ask it on pm.stackexchange.com –  blueberryfields Feb 18 '11 at 9:06
2  
What management practices was the team using before? –  chrisaycock Feb 18 '11 at 9:47
    
Originally we had 2 senior level developers, so they would usually just talk things out. As team and project was starting to grow there were junior developers, so we introduced WIKI, Bug tracking system, Source control etc... Now it seems like the team is too big to be managed by one senior developer, so maybe we should start dividing it into smaller teams. –  Mag20 Feb 18 '11 at 10:27
    
Buy more coffee. –  haylem Feb 18 '11 at 11:00
1  
What a great "problem" to have. Congrats on the growing team! –  Agile Scout Feb 18 '11 at 16:10
show 1 more comment

3 Answers

up vote 8 down vote accepted

I would say that there are roughly two main roads:

  • Split the team into two or three groups, each responsible for a specific field/aspect. this has the advantage that you can still work the way you are used to, within the smaller groups.
  • "The Surgical Team", on which you can read on The Mythical-Man-Month. also this link has a wonderful drawing about it.

Good Luck!

share|improve this answer
add comment

We've grown from about 10 to almost 200 in the last 7 years. The first thing that needs to change is that you will need better documentation and more standard processes. Requirements may have to get more formal as well.

You should also consider hiring specialists as you grow. If you have a database backend, you should have a at least one dedicated database specialist. You should probably spend money for a tester.

You will have more projects going on and a bigger need to manage tham, so if you aren't using one now, you need a project management system and a bug tracker. You need to create a deployment porcess and limit production right to only those people who will be doing deployments, no more making changes directly on prod. Your developers will need to be limited to select rights only on prod.

As you have larger teams, you will have more people problems and will be more likely to hire some less skilled people (relatively easy to get three good developers when that's all you have, much harder to hire 30 at one time). Even though you try to get the best people, the more you hire the more likely it is that you will get a dud, so be prepared to let people go as well.

Coordination between people is key. Two teams making mutually exclusive changes to a product is a bad thing.

With only two or three developers you can't afford to have junior people - everyone must be working at the senior level. With a lot of developers, you can't afford not to have junior people. Hire some junior and train them the way you want them trained. It's usually better to work somewhere that has a career path not everone at the same level.

As your team grows many of your current developers will become the new management staff. Some will hate that, make sure those have an opportunityfor a promotion to a senior developer rather than management. Don't lose all your technical expertise to management. Reward those who don't go into management because you need their detailed knowledge of the current system to get the new people up-to-speed.

share|improve this answer
    
Brilliant feedback. Thanks for posting this. –  Troy Alford May 22 '13 at 18:49
add comment

If the project is big enough for 10+ developers, it should be easy to break down into smaller areas. Split the team down into smaller teams of 3-5 people each, and give them autonomy over their area. API's will have to be developed between teams. I'd reccomend having each team figure out their requirements, and have one or two person from each team involved meet to discuss the API. It's easier to have a discussion and make decisions when fewer people are involved.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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