What management/development practices do you change when a team of 1-3 developers grows to 10+?

Question

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?

Answer 1

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!

Answer 2

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.

Answer 3

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.