How do you know it’s time to scale your development team?

How do you know it’s time to scale your development team – and when do you stop!?

As the CTO of a global RegTech, I get asked the following questions all the time:

• “If we took on more developers, could we build this feature?”

• “Could we work on these items in parallel if you had more people?”

• “Could we do this project faster if you recruit more developers?”

Asking about scaling the tech team is a time-honoured question, and the clients and partners asking the question are right to ask. I would be surprised if they didn’t. The answer though, isn’t always simple. 

Challenges CTOs face when scaling a Development Team

As tech leaders, we face challenges associated with building and scaling high performing tech teams. These challenges can be hard to explain to non-technical people and deciding when to scale the development team is often a complex problem.

For example, there is an upper limit to scaling a development team, not simply because budgets are finite, but because there is a tipping point at which scaling the team further becomes detrimental to delivery. This upper limit changes over time, and often the correct decision is a temporary pause whilst your team, your processes and your company culture catch up with the recent growth.

CTO Checklist: Is it time to Scale the Development Team?

Over the years I have evolved a checklist to help me decide if the time is right to scale the tech team, and it is this checklist I would like to share with you now. I wanted to make this a very practical post that really help tech leaders with this difficult decision. Because I know first-hand how hard it is. 

If you can answer yes to any of these 6 questions, then it is time to scale your development team:

1.Are you and your development team spinning too many plates, resulting in delivering little value, or making mistakes, or both?

Multi-tasking is a given in the world of technology and software development.  It is vital that every member of your tech team masters this skill in order to be a successful, growing team. 

However, there is an overhead to putting down work, and picking something else up.  At some point, this overhead dominates your day, and your productivity drops and/or you make mistakes.  When this happens, it is time to scale your tech team.

2.Is your software quality starting to suffer, because of time constraints?

Testing is an important part of delivering any software.  Personally, I love a good regression test, but I’ll leave that for another post.  A sure-fire sign that you need more people is when you constantly run out of time to properly test your releases. 

We all make mistakes, and no software is perfect – but if you are a tech leader reading this, I am sure you will have experienced a situation where you had to push releases out without having enough confidence in the final product.  When this happens regularly then you need to scale your tech team.

3.Are your development team missing key skills?

We all like to think we are “Masters of Technology”, and being part of successful, growing team requires that you are competent in a wide range of technologies and skills. 

At some point though, you will likely start to hit blockers simply because you do not have expert skills.  Learning is important, sure, but in a growing team you often do not have the luxury of having enough time to become expert in a particular tech.  If you find yourself in this situation it is time to scale your tech team and hire experts.

4.Are people in your tech team regularly getting tired, frustrated, and snappy?

If you join a small, growing development team then you should accept the fact that you will not be in for an easy ride.  In fact, many people who join smaller teams do so because they love the energy and fast-paced environments smaller companies offer.  However, there comes a point where people reach their limits and burn out. 

As a tech leader I am sure you have encountered this many times in your career.  Sometimes people do just need a holiday, but there will be a point in the team’s evolution where the pressure is just too much.  We all have bad days, but when you have more bad days than good because you are working too hard then it is time to scale your tech team.

5.Does your business demand more value than your team can realistically deliver?

Prioritisation is vital for any development team.  There will almost always be more work on the wish list than you can possibly deliver.  Often the key is to have a laser focus and to ensure your team are only working on the essential items, pushing back on the people asking for work in order to judge the real priority. 

As a tech leader you will almost certainly know when you are nearing the limit of what can be delivered, even after a laser focused prioritisation.  When you get here, it is time to scale your tech team.

6.Can you genuinely justify the extra resource costs?

Putting a value on hiring extra people can be difficult.  Many software increments are tough to put a financial value on, but value is not just financial.  Often a balanced scorecard approach and subjectivity is the way value is measured. However, you assess value, you must be able to justify any extra cost. 

Even contractors typically stay for six months or more on average, so you must be sure you can justify the expenditure over an extended period of time. If you can justify the resource cost, then it’s time to scale your tech team.

CTO Checklist: Is it time to stop, or pause, scaling the development team?

Assuming you are in the enviable position of having sufficient budget to keep on recruiting, there will likely be a point at which you need to pause or stop.  Over the years of building tech teams, I have learned to look for some key indicators that it is time to consolidate, or even stop, growing your development team. 

If you can answer yes to any of the below questions, then you may want to think about whether to stop or pause scaling the team.

1.Are your management controls still effective?

As a tech leader having management controls in place is vital to managing, let alone growing a team.  The controls you put in place when the team is small will be very different to those in place for a larger team. 

Indicators such as a drop in overall effectiveness of delivery, quality issues, information security incidents, communication breakdowns, strange prioritisation decisions all point to your management controls needing to be re-engineered. If you need to re-engineer your management controls, then it is time to pause or stop growing.

2.Are you losing control of the code base or your system architecture?

Staying on top of releases is much easier in a small team, simply because there is less code change.  Keeping the code tidy, re-usable, understandable and manageable is critical if you want to maintain quality.

Double the number of developers doesn’t always mean double the amount of code change, but it does double the effort required to stay on top of the codebase.  Losing control of your code is a sure-fire recipe for disaster.  If those responsible for looking after the code are struggling, then it is time to pause or stop growing.

3.Are you certain your team are following your information security best practices?

People are one of the main sources of information security risk. I once observed an employee of another company copy customer data into Excel and onto that company’s shared network.  These days you simply cannot take risks with information security, scaling at the right pace to ensure you don’t risk people taking information security risks is important. 

As a tech leader, you have to know for sure that you are providing effective information security training and your controls are effective.  If you think your rate of growth is adding risk, then it is time to pause or stop growing.

4.Is your culture diluting beyond recognition?

It is entirely natural for team culture to change as the team grows.  In fact, it is quite important that it does evolve.  However, many companies are desperate to maintain the essence of their original culture – a culture that invariably enabled the successes that led to the growth. 

Hiring the wrong people can really hurt team culture, but those people are often easy to spot and to address.  Harder to spot, and harder to deal with, is a gradual dilution of culture.  If you think this is happening, then sometimes pausing so that you can really double down on re-establishing a strong culture is the best course of action.

5.Are your knowledge transfer systems in place and effective?

The importance of this item does depend on the complexity of your product and codebase. However, the point to note is that if you have a sophisticated product or a large codebase, then onboarding new team members requires you to educate properly so they can become effective. 

Regtech companies for example, often need to train new starters in the domain regulations.  Companies providing enterprise level software often need to spend weeks orienting developers around the codebase.  If you cannot onboard new starters by educating them effectively then it is time to pause scaling and spend time on your knowledge systems. 

Final Thoughts from TAINA’s CTO

I hope you find these checklists useful. I am sure there are many different ways of looking at this problem, and many other questions you could ask yourself. However, after over 26 years in the software development industry, building, managing and scaling high performing team, I can say these do work. 

Please do reach out to me at rich.kent@taina.tech if you would like to make any suggestions or have any questions.

We would love to talk to you more about the newest technology TAINA is using in our fully automated FATCA and CRS Validation platform.

For more information on how our fully automated FATCA and CRS Validation platform can add value to your business, get in touch or request a demo to see it in action.