Pluralsight Top 10: Building a Great Software Development Team
- select the contributor at the end of the page -
1. Hire small.
Small teams are generally more efficient than large teams, and they are easier to manage too. Communication is easier with less people on a team (it's a smaller graph with less edges), and each person will be making more of a contribution, which is great for their morale plus each will connect with more of the code base. As Ron Jeffries wrote, "I'm not afraid to change my own code. And it's all my own code."
2. Hire senior.
Notice how the math works out in your favor? You're hiring a small team, so you can afford to pay more for senior devs. More experience and intuition means your team will generally arrive at better designs up front, which leads to less churn later on.
3. Hire craftsmen.
While your senior devs will make better design decisions up front, this doesn't help much when requirements change after the product has shipped. A senior craftsman will build SOLID code with a suite of tests that will get you closer to a Beck curve instead of a Boeme curve. Of course this also assumes something about your software development process. You won't attract craftsmen with a waterfall.
4. Hire humans.
Having a team that gels well and enjoys working together is much more important for most projects than herding a bunch of egotistical geniuses who don't get along. Lasting software is built simply, and it doesn't take a genius to do this. Obviously you want to hire the smartest people you can, but temper that by also hiring people who will fit with your team. A great way to weed out folks who wont fit in is to pair interview.
5. Hire women.
A study in 2008 showed that having an equal mix of women and men on a team (actually a bit more women) unlocks innovation.
6. Provide for them.
Ask them what hardware and software tools that they need, and then get it for them quickly. Craftsmen aren't going to ask for frivolous stuff that won't dramatically enhance their productivity.
7. Trust them.
Don't be afraid of letting your team pair program by default - it's a great way to share knowledge about the system and bond with each other. Don't micromanage them. Give them creative license to approach problems in their own way, unless you feel like they are misunderstanding important domain concepts. They need to own the code, not you.
8. Protect them.
Don't ask your team to work overtime. No death marches. Have a verbal agreement that they'll spend about 40 hours a week working for your company, and they will spend 20 hours a week of their own time keeping their skills sharp however they see fit (Bob Martin recommended this practice in The Clean Coder). Shield them from randomness in the rest of the company so they can focus and do their best possible work.
9. Manage as a meritocracy.
Don't let the politics of personal convictions get in the way of technical correctness, and don't try to be a democracy. Trust the people with the most knowledge of the system to drive technical decisions. You should care more about arriving at the right decision, not winning the most arguments.
10. Encourage growth.
Purchase subscriptions for each of your team members to Pluralsight, Safari Books Online, and whatever other technical training resources your team thinks might be helpful. Let them escape to conferences from time to time. Encourage them to participate in user groups, or start one of their own. These are all things that craftsmen need to do to maintain their level of proficiency in this fast-paced world of software.