The early days of your tech team
When establishing tech teams in young companies, one widespread practice is to form these teams around technical or system domains. For example, if you are working on a product, you might split your large teams into UI, backend, DB, QA, etc.
As you grow, this form of organization has numerous drawbacks, including a detrimental effect on productivity and efficiency, compared to other organizational forms. But if that’s true, then why is this organizational structure still so popular and the predominant structure in most product companies, despite its drawbacks?
Why are many teams initially formed around technical silos?
The primary reason that contributes to its popularity is that it is very simple and straightforward to implement. It is simple and straightforward because it does not require a lot of thought – thought about how best to structure your organization to achieve maximum productivity and efficiency. You just copy the architecture of your software. For example, if your software is split into backend, UI, and DB, and you have QA engineers, then instead of spending time analyzing your organization and creating the proper structure to achieve maximum productivity and efficiency, you just follow your product architecture and create the corresponding engineering teams or even departments – in this case, UI, backend, etc. You have probably already noticed that this phenomenon is almost identical to Conway’s law, which states that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. It’s questionable whether the software architecture follows the organizational structure or the opposite – the organization follows the software architecture – but there is definitely a link between them.
This model is simple and straightforward, not only because it just copies your software architecture but also because you do not have to bother with complex topics like productivity. It doesn’t mean that these complex topics do not exist – no, they are still there. It is just that when your tech team is small, neglecting them doesn’t have a big impact on your team, so you just don’t bother with them. Also, you always have the excuse that “everybody does it” or that it is common sense.
The symptoms of change
Once your tech team starts to grow, you start noticing a change – things just don’t seem right. The symptoms can vary, but in most cases, they are these:
- longer times to release a new version of your product or service
- increased feature implementation times
- deteriorating product quality
- increased average age of defects
- big batches of work in progress.
While the above are symptoms signaling a need for change in your system, they also might result in the following:
- increased attrition rate
- difficulty in attracting top talent
- decreased satisfaction and motivation of your employees
- people doing the wrong job.
When you face the increasing occurrence of these problems, you inevitably ask yourself why you didn’t have them before, what happened, and at what moment in time they appeared. The reality is that characteristics like productivity, efficiency, lean wastes, cycle and lead times, time to market, etc. are relevant to every organization, whether the company acknowledges it or not. The only reason why you haven’t experienced the effect of neglecting them is simply that your tech team was too small. Now, as your tech organization has grown, it is a matter of acknowledging that they do exist and proactively addressing them in your organization. Once you acknowledge that these characteristics do exist, you will start to understand that they are not simple at all and they exist in a very complex interdependence with your organizational structure. In the first place, the very fact that you acknowledge their existence will force you to define them for your company; for example, what does productivity mean for your organization? You’ll see that this is far from an easy task. After defining what productivity is, you’ll have to see how this definition is applied not only to the organization as a whole but also to each individual team and even to the individual engineer.
Transformation journey
We’ve reviewed an example of a transformation journey and the associated definition, measurement, and improvement of productivity in our blog post “Measuring and improving the productivity of your tech organization in its transformation journey“. Let’s briefly recap the steps.
- Identify and quantify the problems
Why do you need to quantify problems? Imagine, for example, that you have many defects. This is definitely a problem, but how do you know whether this is the biggest problem in your tech organization? Aren’t there other issues which are bigger and more important? Quantifying the problems allows you to make sure that you’re tackling your biggest problems. In addition, quantifying the problems allows you to measure how you are resolving them throughout your transformation journey.
- Avoid Big Bang transformations
Many books or gurus suggest the following three-step approach:
- Analyze the current state.
- Depict the future north star state.
- Prepare a plan to reach it.
I don’t recommend this because, quite often, the gap between the current state and the future state is too big and your plan has to be huge, containing many phases and steps. People won’t necessarily understand all of them, and some of them might solve problems which are not yet visible but hidden behind other problems which are currently exposed. If you tackle a few top problems in your organization, people don’t see this as an org update but as a very focused effort to resolve very specific problems in a very clear way.
- Always focus on your top problems and measure the impact of resolving them
In our previous blog post, “Measuring and improving the productivity of your tech organization in its transformation journey“, we’ve reviewed an example of this. It’s important to remember that measuring the impact will not only help you to track the success of your transformation journey but will also help a lot with the communication with the rest of the company, especially the non-tech people. Remember, not everyone is required to understand cross-functional teams or technical improvements, but everyone will understand if you clearly demonstrate a 50% improvement in the productivity of your tech organization.