How to build the perfect development team
It is easy to feel comfortable around people just like you. With the same experience and culture, same mind set. But having a successful developer team is not about being comfortable, it’s about new ideas, being dynamic and being the best.
Assembling a team of coders for a start-up is one of the biggest challenges a new CTO will face. No matter how great the idea, it’s the people in your team who will make the idea become a profitable reality as you work together to try to beat the clock, working on a knife’s edge. It’s also your team who will enable you to scale quickly when the time comes.
Today’s start-ups create a unique ecosystem where monocultures of preferred technologies flourish. It might be Python, Ruby on Rails or PHP, the symptoms stay the same no matter what the language or framework.
From lack of experience (or open mindedness) many CTOs fall into the trap of creating a cult of their preferred technology, searching for the purest way to adhere to its principals. Unfortunately this is short sighted as they never look up from their immediate milestones to think about the bigger picture and address the question of how the technology can be rapidly scaled to meet customer demand (it can hit so fast!)
It is a hard lesson to learn as many of the new start-up CTOs have never built anything of scale and yet are in charge of running the tech of a fast growing company.
Let me give you a personal example – an experience from quite a few years back that taught me some hard but valuable lessons.
Ruby on Rails is the currently most popular web framework in the start-up scene – and for very good reasons. You can quickly develop your application while having convenient ways to test your software. It also abstracts the database layer of your application to a level where you never need to directly write database queries.
Many developers see this as a big plus, since learning the ins and outs of SQL can be a daunting task, and I was no exception. So when building a web service for a picture sharing community, I chose rails without a hint of doubt – it was my tool of choice. I didn’t have a diverse team around me to feed in new ideas. I was so focused on the task at hand, using my one ‘language’.
Luckily (or sadly) the app became extremely popular in a very short time and the service kept getting slower and slower. At first I had no idea what caused these problems, but as I dug deeper I realised that my database was causing the issues. So began my journey through the postgres documentation. I learnt about indexes, joins, table locks, database design, datatypes and sharding. Most of these things are very foreign to rails developers, as it is not taught in tutorials and almost never mentioned in standard books.
Over time I figured out that postgres is vastly more powerful than the small fraction of functionality rails uses. For example, many functions can be performed directly in the database and often 100 times faster.
I was forced to learn all this in a very short time – if the app was hindered by slow service, my company wouldn’t earn any money. I had to realise that rails wasn’t the perfect tool for the job. Its inherent weaknesses in building high speed JSON APIs that need to service millions of users became clearer as I moved on with my optimizations.
If I had to build it all again, I would chose a very different approach.
I would do what I have done with adeven and build a team of diverse people and skills from different coding languages and fields of expertise that complement each other.
I am extremely proud of all the cool features that coders have brought to the table and enriched our products with. The best stuff that we have built is behind the scenes and can’t be seen, BUT it makes the magic work.
Coming back to today, I can see many start-ups making exactly the same mistake as I did in my early days; great coders, writing great code, testing everything and practicing the latest agile development methods. Yet a homogeneous team of developers will never realize that they are in fact are using a golden hammer. One solution, one choice, one tool in the tool box.
It is a problem that I see in the industry as a whole, even in some of the most hyped companies. These people will eventually learn through failure, their stuff will break and hopefully they will understand why. But while I learnt this on my own dime, many of them spend investor’s money while doing so.
So what should look for when building your awesome, diverse and dynamic team?
In the interview, ask them what they have failed at. What task brought them to their limits? When did their favourite technology prove the wrong choice? What alternatives do they know for the task at hand? Are they aware of the drawbacks of the technology they are using? Do they have an idea of the scale of the task? Do they understand the bottlenecks of their solution?
This should help you to understand if your team will be able to handle the scaling of a successful web company and compete in a global, diverse world.