Recently, I have switched over from leading the software and design team at iHub to a new role at Twiga foods.
Just like iHub, Twiga has a great development team which I am proud to be a part of.
The big difference is that the organization is rapidly growing. In this environment, it has become critical to once more ponder the question, “What makes for a well-composed software team?”.
In this entry, we are going to go through some of my thoughts on what to consider when you have to rapidly scale your team.
Is there a right balance of junior and senior engineers?
I can’t tell you how many CTOs I have met who brag of an all-senior team. Don’t get me wrong, a senior team works much faster, gets higher quality work done. But when everyone is a senior, who is going to do the plumbing work?
Plumbing work is the necessary rote work in development. An example would be building out an email notification feature. Getting it right is simple in principle but time-consuming in practice. This kind of work would bore a senior engineer but present an exciting learning opportunity for someone greener in the field.
Junior engineers also tend to be a bit more amenable and thus more likely to fully buy into your vision.
With that said, you really don’t want a team skewed too much on the junior side. Their lack of experience means they will not see architectural land mines guaranteed to come back to bite you.
A ratio of 4 senior to 1 junior should work fairly well.
Is there someone with domain knowledge?
On paper, I learnt to drive from a driving school, in truth, I actually learnt from my uncle. One of the things he used to say was
You can only be a great driver of your own car, on the others you are at best mediocre
This statement might seem ridiculous, I mean, aren’t the control’s standard for all vehicles?
Yes, they are. But what about the time the car takes to break? Or accelerate? How has performance been fairing since the last service? In reality, you gain some knowledge of the performance of your car, something like its personality over time.
In the same way, a developer who has worked in the banking industry has some knowledge that a developer who has worked in Agri-tech just doesn’t and vice versa. You thus want in your team at least one person who has some tacit knowledge of how your industry works.
Does there exist a level of cognitive diversity?
In the current heydey of gender diversity, it’s easy to think that is all that matters. There is an even greater consideration, how do your people think through problems?
In a homogenous team, everyone comes to the same conclusion all the time. This is great for speed but it also means you lose out on creative ideas which would have possibly been a better fit for the problem at hand.
You also don’t want a team so diverse, no decisions can ever be fully agreed on. In this kinds of situations, all the energy is spent thrashing ideas which would have been better placed executing on any one of them.
Is the team cross-functional?
The most obvious question in agile, yet still worth mentioning. From a corporate level, functional teams are more legible than cross-functional ones. This means there will always be pressure to split up the team to functional roles.
Even developers do this to themselves, why do so many profiles have the tagline “PHP Developer” or “Angular Developer”? It’s because it’s so much easier to define yourself and your team by what you do rather than by what you produce.
Fight this tendency, focus on your outputs, you can better build a team that carries all the skills necessary to get the job done.
Do you have any advice for me as I embrace on this journey? Talk to me in the comment section below or on my twitter @jchex