Lessons Learnt Building a Development Team
A year ago I joined a company with the goal of building a brand new team to support their web sites. In January we launched massively overhauled and enhanced ecommerce systems, in record time and exceeding expectations. This is some of what I’ve learnt:
Hire people who know more than you.
They will push you and inspire you. They don’t need to know more of everything but everyone needs to bring something to the table. As a system architect I hired developers with wider coding experience than me for their insight; and those with experience of different project management styles brought valuable lessons to a new team.
Hire based on emotion.
Interviews and tests will never reveal the full scope of a person but if you can select for pride, drive and passion you’re halfway to a good hire. Both the quietest and loudest developers can show these traits in their own way, so look for these when interviewing. Gut feelings go a long way.
Stay humble to be receptive to new ideas.
If you’ve hired people with great knowledge and experience then listen to them. You won’t always agree but by listening not only do you get insights but they also feel appreciated.
The size of the team matters less than the trust in the team (big is not necessarily better).
Our team really hit its stride when I couple of developers left us and the remaining team had a good level of trust and respect for each other. The smaller team of 7 delivered more than the team of 10 as we reduced the overhead in communication and hand holding.
A single bad hire can drag the whole team down.
An incompatible team member takes more than they contribute, from the whole team. Even if they are great developers, if they don’t have the trust of the team then they’re eroding the trust within the whole team. In short: Avoid management’s instance that ‘something is better than nothing’ when it comes to people.
Think ahead then act as if you’re already there.
Plan for the future and act as if you’re already there. If you’re planning to implement DevOps, code reviews, etc… it’s a lot easier to do so at the start and scale up than to retrofit a process later on once you’re approaching monolith status.
There are plenty more lessons and micro-lessons each day but these are what I’ll be bearing in mind when growing teams.