Here’s the standard Silicon Valley story – you have a great idea, you dropout of college, build a small team, complete a prototype in the garage, get a bunch of investment and change the world.
The prototype in the garage is just the beginning, though - the hardest part is not establishing the company, but scaling it – and those first 100+ hires bring restructuring that can be painful if you’re not careful.
Over the course of my fifteen year career in tech, I’ve gone from an engineer working with just a few others on an early stage product to a mid-size CTO with around 100 other engineers, all in the same company, and now I’m an engineering leader at ServiceTitan – a hyper-growth startup that reached unicorn status in 2018 with 300+ engineers.
Here, I’ve summarized the most effective team structure at each stage from 1 to 100+ hires – and the challenges that can (and probably will) appear each time you restructure.
From Zero to Scalable Organization: One Small Team to Multiple Teams
The Early Stage Team (1-20 Employees)
In the early stages of a startup, you’re only responsible for communicating to a handful of people – typically all seated in the same room with an understanding of what they need to do, often working days and nights to build the MVP. Your main priority at this size is building the right product, getting your first customers, and making sure you don’t burn your entire runway – so, you end up with engineers that are all independent contributors to your small team, without much structure or process. This is all fine and good, for now.
Beginning to Expand (20-50 Employees)
Once your business starts to expand, you hire more and more people, and need to build several features/projects in parallel. With all these new hires to help you out, business as usual from the previous stage of your company starts to break.
In my experience, this starts to happen around 20 employees. When you hire more people with the same specialization (you suddenly have a bunch of backend engineers, frontend engineers, QAs, etc) it makes sense to organize them by disciplines. In this setup, you’ll have core team members who are experts in specific areas, and from there you can organize teams within that specialization with clear code ownership. As an added benefit, this setup easily allows engineers to share knowledge and help onboard each other as the team grows.
Organizing your team by discipline works for a while – but then you’ll find that you spend too much time coordinating between teams.
This is pretty common – there’s often a lot of pain around not having one team own a specific domain of your product because in order to complete a project, several separate teams (backend, frontend, mobile, API, etc.) have to touch it before it’s complete.
Conway’s law – the idea that organizations mirror their communication structures – manifests itself at around 50 employees. It becomes pretty obvious that the different parts of your product aren’t able to communicate – a direct reflection of the disparate nature of your team.
So, from here, what do you do? What’s the best structure for your team as a whole?
The Growing Organization (50-100+ Employees)
Once you get up there with more than 50 employees, the org starts to look and feel more and more like a larger corporation and less like a startup. Reflective of that, you need to restructure (again) – this time, aligning towards product areas and building platform teams to support growth.
Making changes to your team’s structure isn’t seamless – you’re working with people, after all. When you make changes to your team, it takes a toll on the organization, and change management is crucial. There are technical challenges as well – it’s also important to make sure that your product architecture supports your team’s setup, and that you are able to organize your codebase / code ownership accordingly before you reorganize your team.
The good news is, though, that once you make the move towards product aligned teams, it should support your team growth for quite a long time.
So, what are the functions of each team? How does having a separate product team and platform team benefit your org and make your development process more scalable?
Two Core Functions: The Product Team and The Platform Team
The Product Team
Many top tech companies structure their teams around specific product domains and fixed domain boundaries. These groups are usually called Product teams – they’re cross functional, and the complete team has all the knowledge and skills to be able to produce end to end solutions. Product teams are responsible for designing, building, and maintaining products from A to Z.
The Platform Team
There is usually some foundational work that doesn’t clearly fit within the scope of any one product team, so you need some platform teams that take care of building frameworks and libraries which help product teams move faster without duplicating efforts.
Platform teams can provide standard templates and tools to set up CI/CD, common libraries to manage monitoring and alerting, frameworks for automation testing, and much more. The important takeaway is that the platform team should not act as the authority on tech stack choices, but should aim to improve the developer experience and closely collaborate with product teams to get requirements, enabling them to concentrate on solving specific business problems.
Conclusion
At the end of the day, the best and most efficient way to structure your team will be completely dependent on the size of your team and the stage you’re at as a company.
The important KPI to evaluate the efficiency of your internal processes is how much time needs to be spent on communicating (literally, the number of people each teammate needs to talk to) in order to complete their work. Teams should be organized in such a way that they are able to work as independently as possible, but are still able to maintain strong cross team alignment towards larger company goals.
Separating your org into product and platform teams doesn’t mean that you should try to limit collaboration between teams – in fact, quite the opposite – you should encourage cross-team community practices, where people with similar interests and roles within the org can meet and share knowledge, best practices, and lessons learned.
Structure is a hard thing to get right, but It doesn’t make sense – and wouldn’t be effective – to structure your company like an enterprise when you’re only 20 people. As you grow, however, it’s crucial to continually monitor the efficiency of your setup and adjust accordingly. The best organizational structure and processes are not a destination, but a journey that changes along with your company and team.
BIO
Lusine Khachatryan is a vibrant engineering leader and currently Senior Director of Engineering at ServiceTitan. She brings over 15 years of experience building products and scaling teams with her. A mom of twins, she’s always busy - but with the extra time she has she loves to play pretty much any active sport - often choosing tennis or volleyball.