Working for a startup is fun, because a small group of people get to make all the decisions. You know the whole team well, and decisions can be made with a few simple conversations.
As a company grows, you don’t know all your colleagues as well, but it’s still fairly easy to think of them as part of one big family. Each team can have its own autonomy to decide things, and teams can operate in spite of cross-team differences.
But when a company grows to have 50 or 100 software teams, team differences can start to take their toll. It can become very cumbersome to determine who is responsible for which product, and which team’s deployment broke your team’s product.
At this point it’s time to make some quality changes. Here are five you should consider:
Naming
When you’re at a small company, it can be fun to give your teams whimsical names: The Jetsons! The Hobbits! It’s easy to know who’s who because there are so few teams. But the more teams you have, the harder it’s going to be to figure out who does what. Which team should you talk to about authentication? Is it Team Magneto, or The Borg? Which team pushed a change to their API which broke your entire backend: Team Fluffy Bunnies, or Team Doge?
At a large company, team names should reflect either the product the team works on or the team’s function. Yes, having serious names is less fun, but trying to remember whether you should page Team Black Widow or Team Hawkeye when your site goes down is also not fun.
Documenting
At a small company, knowledge can be passed down tribally. If a new hire has questions, they can just ask you, and you can spend a few minutes with them telling them what they need to know. You can even keep this going for a while at a medium-sized company, if you have some motivated people who are happy to spend time answering others’ questions. But at a large company, trying to spread tribal knowledge becomes an incredible time suck.
Documenting information not only helps with cross-team communication, it can also lessen your workload. If you are the only person who knows how to do something, who’s going to get called when that something needs to be done? You, that’s who! Providing training to a few others can be helpful, but that just means the workload has been spread to a handful of people, who will all be overwhelmed with inquiries. But if you can create clear documentation so that anyone can read exactly what to do and do it without asking any questions, you’ve just freed up a ton of time for yourself and for your fellow experts.
Monitoring
At a small company, everyone knows what’s going on. A deployment is a common knowledge, because most of the company has been working on it. Even at a medium-sized company, it’s fairly easy to keep track of what other teams are doing. But at a large company, a team that you don’t even know about can do a deployment that you don’t know is coming, and that deployment can have ripple effects on your team’s product!
This is why monitoring is so important. It’s not just the changes that your team is making that can result in failures of your product. It’s not even just the teams adjacent to you that can affect your product. Having monitoring in place can alert you the second things go wrong with your application. You may even be able to pinpoint the issue, identify the team that caused the failure, and have them fix the problem before any of your end users notice.
Standardizing
Can you imagine a scenario where each developer on a team decides to code in their favorite language? One might choose Python, and another C#. Of course it’s easy to see that this makes no sense. How could the team share their code? But for some reason, teams don’t realize that this is also a problem with test automation code. In large companies, the different systems are dependent upon one another. One team creating a chat feature will be dependent upon another team’s authentication software, and yet another team’s notification software. Having automation code that is in the same language and follows the same standards from team to team makes it easy to understand all the automated tests. Moreover, it makes it easy to set up systems where a build in one team’s product can trigger tests in another team’s product. It also makes it easier on the team setting up the CI/CD environment, because they don’t have to set up systems to accommodate many different test frameworks.
Measuring
In a small or medium-sized company, it’s pretty easy to notice when there is a quality problem. When a product is unreachable or when a customer complains about a critical bug, everyone hears about it. But the larger the company gets, the more likely it is that some problems won’t be common knowledge. For this reason, it is a great idea to set up metrics to measure team success. Metrics to measure could include bugs found by the team, bugs found by customers, average response time, and average error rate.
As I mentioned in a previous post, you often can’t compare the metrics of one team to the metrics of another team. But you can compare a team’s metrics to their previous metrics. What was the team-to-customer bug ratio six months or a year ago? Was it better or worse than it is today? And if one team’s metrics seem wildly different from all the other teams’ metrics, that might be a data point worth looking into.
Change is not often easy, especially when it comes to companies that have become used to their own way of doing things. But as your company grows, it’s important to grow in your quality maturity as well, and this can mean adopting new standards for naming, documentation, monitoring, tool standardization, and success metrics.