|After nearly twenty years of working as a professional software developer, working in many different industries and a range of diverse companies, it seems to me at least that there are certain key ways in which to build a strong development team. By strong I mean a team that is motivated and hyper
productive. The former generally leads to the latter. So how do you build a strong development team? Here are my thoughts.
Share knowledge and information
To be productive you need to know as much as possible about the various applications, tools, processes etc. that are used by your development team. Even if you are a self employed contractor, you still need an understanding of these things. Keeping information to yourself in a misguided attempt to
make yourself indispensable just means you will get calls out of hours, on weekends or when you are on holiday as you are the only person with that knowledge. Have regular sessions where you take turns going through areas where each of you are an expert and freely share your knowledge. Or where you discuss new ideas or upcoming technologies. If you have read an interesting article then share it with your co-workers. Make sharing ideas part of the fabric of the team.
Set good habits and be a good example
Be the example that other members of the team want to follow. Be professional and conscientious. Don't let sloppy habits or maverick individuals descend on the team. Set good habits with regards to testing, building, shipping, developing and every other aspect of the development cycle. Set the bar high and maintain it. Ensure you have a coding standards document and that everyone knows where it is, and has read it. Have regular code reviews and make this part of the development process. Ensure that testing is not an after thought and that quality is baked in from the ground up, not sprayed on afterwards. Developing software to a high standard should be part of the culture of the development team and inculated so that it remains that way. Writing good software is a habit. Habits require regular reinforcement. Don't let standards slip.
Everyone working to their strengths
As developers, we all have particular skills and knowledge where we excel, and areas where we are weaker. So match the skills to the appropriate developer when working on projects. That's not to say that weaker areas shouldn't be worked on and gaps closed, but simply being pragmatic in working to the strengths of the various individuals within the team. As knowledge is gained and weaker areas become strengths, then those developers can be assigned different tasks that relate to their newly acquired skills.
Make learning a habit
This applies especially to anyone working within software development. Keep your skills up-to-date and encourage your co-workers to do the same. Discuss that article you read the evening before and share a link to it with the other members of the team. Don't ever let your skills become stale, or worse obsolete. If you are not moving forwards, then you are going backwards. Progress stops for no-one, and whilst you may be happy plodding along using those legacy skills today, you don't know what's around the corner tomorrow. Make reading articles or books a regular occurrence. Subscribe to the newsletter from your favourite community. Contribute to an open-source project. Write technical articles and share your knowledge. Become active in any of the many online development communities. I am a regular contributor to the CodeProject community for example. Keep learning and keep it fun.
Strong development teams don't just happen by accident. It takes time and effort to build a strong team. But if you are prepared to make the effort, then it is well worth it. Strong teams thrive on challenges. They foster a can-do attitude. They get stuff done. If that's the type of team you want to be a part of, then start building a strong team today.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare