How would you describe your ideal team composition?
...cliche, but it's depend...
“How would you describe your ideal team composition?” This is a common question I encounter when I have a job interview. Until now, I still don't have a definitive answer. It depends on various factors, such as the hiring budget and the types of platforms involved- whether it's mobile, web, or both, the company's scale, and many more.
I have experienced many ups and downs in various roles and team setups across different companies. From the beginning of my career in the early stages of a startup and progressing through growth and unicorn phases has shaped my perspective on the entire process. While some may have different setups, the goal remains the same: to improve processes, reduce toil, and enhance overall effectiveness for everyone.
I’m not an expert or a seasoned manager in this field. Speaking from my experience as an individual contributor in this industry. Though I may be a bit young, I believe I’ve gained enough knowledge to share my insights here.
In this article, I share how my response evolves over time when people ask me, “How would you describe your ideal team composition?”
One Team For the Whole Organization
After graduating from a local college in Indonesia in 2016, I secured a position at a small startup with just five engineers: three seniors, myself as a junior, and the CTO. We focus on having fun while learning. During this period, I learned countless lessons. As a team of five, we handle everything from backend and frontend to infrastructure. It's important to be able to learn quickly and take on various roles to ensure we can deliver a working product within the following week or days, allowing us to secure the deal by creating a demo for the customer. In these early startup days, swift execution is crucial, and we must be ready to pivot at any moment.
One advantage of this is that we, as engineers, have a comprehensive understanding of the entire process. We can quickly identify any issues that arise. Frontend problem? It will be resolved by tomorrow. Backend issue? That will be fixed in two days, and so on.
For new joiners, the challenges can be overwhelming. Not only do they need to grasp new technologies, but they also have to understand the user journey and domain knowledge, as well as interpret customer needs.
There are also occasions when we, the engineers, are invited by the co-founder to participate directly in customer interviews at the customer’s office. We observe their problems directly and attempt to solve them. It is fundamentally straightforward and very hands-on to build the product at this stage.
But the takeaways that I can conclude with this approach:
Engineers must be generalists who can adapt swiftly, focusing solely on delivery. Sometimes, we just listened to customer feedback in the morning and directly developed solutions by night!
It is easier to manage and can quickly adapt to changing product requirements.
Context switching also becomes a major challenge. In the morning, you might focus on front-end development, and in the afternoon, you need to address a database issue at the infrastructure level. You may discuss feature A today, but then an urgent request requires your attention on feature B. While it may seem productive, it can be quite draining at times.
Is this my ideal team composition?
When people ask me about the ideal team composition, when I was in this situation, I said, Yes, that’s the ideal team composition. It’s a situation when you don’t have too many people, making too much communication overhead. But you also don’t have too few people, making it overwhelming. On the other side, as an engineer, I can learn the complete user and product journey, gaining extensive experience across various tech stacks. My resume boasts buzzwords that people don't expect. I’m evolving into a “Rockstar Developer” with Infrastructure, Backend, Web, and Mobile knowledge.
Team based on the Role
In the following year, in 2017, I moved to another startup. This is a growing stage startup, where the people are big enough (20-30 engineers), so this company makes some groups instead.
Backend Team
Mobile Team
Frontend Team
Machine Learning Team
Every team member shares the same role, and although their experiences may vary, everyone on the same team communicates on the same ground. For instance, the backend team discusses backend issues only, discussing the database performance issue, API refactoring, Backend best practices, etc.
However, roles like Designer and PM don't belong to this team; they have separate teams, which seems unusual. Engineers become a kind of squad or tribe, or more like a software house with different skill sets.
One benefit of this setup is that, as a new junior engineer, I can quickly contribute to the team. The Seniors can onboard me easily; the knowledge is at the same level. I can ask anyone on the same team. Everyone supports each other because it’s a squad with the same skillset. Although some senior members might attend alignment meetings, junior and mid-level engineers primarily focus on project delivery. Unlike my first job, it’s much easier to begin contributing to the team since the focus is solely on backend tasks.
One of the major challenges that I foresaw back then is when developing a new feature that involves multiple teams. Establishing a clear alignment/contract from the project kick-off is crucial; for example, API contracts need to be defined and finalized so both the backend and mobile/frontend can work independently. Any mid-project changes should be communicated immediately to all teams so that everyone can adjust to the changes.
Whether we like it or not, placing blame on others will happen indirectly (or unconsciously). For example, one might say, “The Backend team has blocked us, so we cannot proceed with testing,” or “The Frontend team is blocking us because they are focused on Feature B,” or “The Mobile team is preventing us from moving forward; they haven't addressed our requests.”
If I encountered a blocker when I was still working at my first company, I would resolve it directly, eg, apply changes to the web app, mobile, or the backend, and configure the infrastructure as needed. There was no excuse not to tackle the problem. However, in this second company, people often find excuses to avoid stepping out of their comfort zones, perhaps out of fear of “breaking” things. Also, because the team setup has been like that, it’s hard to contribute anyway.
At least, that was my personal feeling at the time. I'm not sure about the others. Gradually, I started thinking this way, repeatedly making excuses and saying things like, “Oh, I don’t know about mobile, I can’t handle it. Can you all take care of it? I've created the Jira ticket on your board." Or some ML engineer says, "Oh, we don’t know about Golang. We created the ticket on your Jira board. Please help fix it.”
Is this my ideal team composition?
If I were in this condition/stage, if people asked me whether that’s my ideal team structure and composition, yes, I would likely describe it as my preference. This is where I feel most comfortable. I focus primarily on backend development, where I believe significant improvements can be made. I concentrate on resolving backend technical issues without overthinking. I don’t dwell on the product's features or appearance on mobile devices, as that task falls to the mobile team. My responsibility is limited to ensuring the mobile team's API responses are correctly served.
Also, there is not too much bureaucracy because only the lead will gather and align the requirements if it’s related to another team.
But, one unique situation back then was that even though we’re the same team in the backend, we also have a small sub-team that handles domain-specific tasks. But in the end, it’s still one team. Everyone can easily support each other because the skill sets are the same.
Team based on Product/Domain
Later, in 2019, I moved again to one of the unicorn startups. This new company has more people. It’s a multi-national, globally spread organization. The team is divided based on product, where each product team consists of
Frontend Engineer
Backend Engineer
Infra Engineer
QA
(some team) Also have an Android/iOS/Flutter engineer
In this arrangement, the team concentrates on a single product. If frontend development is necessary, they will include a frontend developer. If mobile development is required, they will hire a mobile engineer. So the team ensures they can support their roadmap, with the right investment (eg, hiring a new engineer with a new skillset)
While not common, some teams prefer their engineers to be polyglots, enabling them to work on various tasks as long as they stay within the same product scope. So instead of hiring a specialist engineer, the team have generalists, who can be a mobile engineer, a web engineer, a database engineer, an infrastructure engineer, or even a QA engineer who is setting up their automation test. However, the idea is still the same: the team is self-sufficient to do their product work.
This enables the team to focus and iterate more rapidly without blaming others, such as saying they are “blocked” by different departments/teams. Each member operates like a “mini startup” within the company. That can act freely and autonomously. The team possesses all the necessary skills to implement changes related to their product.
When I refer to a mini startup, I mean that the product team will create its own roadmap, develop the product it aims to sell, and so on. In this setup, the Product Manager (PM) functions as the CEO, while the Tech Lead takes on the role of CTO within this mini-startup.
Domain / Area Level
This arrangement extends up to the Domain area level, where a higher-level manager oversees the teams below.
The unique role that I experienced in this setup was the architect role, where I was positioned. I was one of the group architects who oversaw several product teams. The ideal situation is that every product should implicitly have an “Architect” role. So these architects will align with the group architect to ensure the integration within the domain/area is less friction. Architect and Techlead (on product level) or Architect and Engineering Manager (on Group /Domain /Area level), it’s like two brains in collaboration. The Engineering Manager/Techlead focuses on process and people management, and the Architect focuses on technical decisions, owning the architecture roadmap, etc.
However, the downside of this structure is that the bureaucracy can be overwhelming. Numerous layers must be navigated when proposing changes that impact the entire domain. Implementing changes is time-consuming because each product team has its own roadmap and priorities. As a result, it often feels like a competition to see whose roadmap wins support at the higher management levels.
However, it is relatively easy for higher priorities that come from the top level because everyone will make it their priority. And it’s easier to navigate because everyone will be autonomous, running independently. This is where you need an Architect to navigate the changes, by making a kind of “Architecture Northstar”, so that everyone will still align with the future, avoiding duct-tape solutions across the products when working on one priority altogether — read my blog post about Writing Architecture Northstar Document.
The birth of Platform Domain
Another interesting concept I learned in this setup is the birth of the “Platform Team”. As every team now functions like a product. However, referring to something like the API Gateway as a product feels strange. Therefore, instead of using the term Product team, we designate it as a Platform team. This team doesn't serve the customer directly; instead, it supports the product teams within the organization.
For instance, the dashboard platform team created the Microfrontend. This setup allows any Frontend Engineer in the product team to contribute by integrating their Microfrontend with the platform's core. Similarly, the Public API Gateway team is working on a Gateway Platform, enabling any Backend Engineer in the product team to expose and register their APIs for public access. Likewise, the Mobile Platform aims to foster the Mobile ecosystem, creating libraries, modules, and more, so that mobile engineers across all teams can easily contribute and implement their changes.
When I refer to the Platform, I mean that the platform team focuses on building the platform itself, rather than developing product features or fulfilling requests from other product teams. So it’s not like, for example, Product Team Payment, asking Platform Team to implement some changes in Mobile or Web because the Payment Team doesn’t have any Mobile or Frontend engineers. Instead, the platform team creates a way for the Payment Team to implement it by themselves easily, without waiting for the Platform team to implement it.
This distinction can sometimes be challenging for people to grasp, as it requires a certain level of understanding to differentiate between the platform and the product. For more insights, check out my previous blog here: “Product vs Platform: the Struggle to Make the Domain Boundaries”
Is this my ideal team composition?
At this stage, this is my preferred team structure. Considering the tradeoff involving considerable bureaucracy, it’s a necessity. As the company expands, alignment among individuals becomes increasingly essential. As long as team members are open-minded, ready for challenges, and willing to evaluate and question the status quo critically, I believe this represents the ideal team composition.
I remember how my team worked on expanding our product to one country to deliver new product payments. It was during the COVID pandemic time, and we could finish it in two months. We had a whole team: backend, frontend, database/infra engineers, designers, product managers, QA, and tech leads. There were no blockers; if something was blocked in the API gateway, we made changes, and if something was blocked with Mobile/Web, we made the changes directly to the repository — that later also became configurable and decentralized eventually when the Platform team made fixes.
However, the challenge with this setup primarily affects the platform team. Since it is utilized by several product teams, implementing versioning or breaking changes becomes difficult. Requesting product teams to upgrade their versions or transition to a new workflow will require time and alignment. Moreover, the product teams have their own priorities to consider.
For example, I remember rebuilding our new Auth Platform, and it takes a lot of alignment with the team, needs some hard push from management, so every product team complies with it, eg, consuming new headers returned from the API gateway after using the new Auth Platform, etc.
Another example, sometimes the platform team must be proactive and occasionally interact with other product repositories to facilitate library/client version upgrades. I can't recall how many times I've raised PRs while being on the platform team. People often recognize me from my GitHub contributions to their repositories due to upgrading the client version of our platform API in their repositories, even before we meet in person. 😅
My Ideal Team Composition?
So, given all my experience, what is my ideal team's composition? It largely depends on the stage I find myself in. In the early stage of a startup, I believe that one team for all roles is effective. However, during the growth stage with 20-30 engineers, having one team focused on a single role seems optimal. This approach allows me to oversee all product features while ensuring high-quality engineering output.
When operating at a unicorn or enterprise level, working within specialized domains is advantageous. This structure enables me to zoom in and out of different contexts. Zoomed out, I can see the broader eg, Payment Domain, and when zoomed in, I notice various products within it, each managed by a dedicated team. This setup facilitates smooth context switching between high-level and low-level discussions.
As the company evolves, a different approach is required. What was effective three years ago may not work today. Back then, the company was smaller, with a limited user and customer base. The risks were manageable, and implementing changes was straightforward, requiring minimal discussions about potential risks or persuasion. A single team for all tasks seemed efficient.
However, as the company grows, this structure becomes burdensome, requiring specialized teams for each stack: backend, frontend, and mobile. As the company expands, complexity increases, demanding individual attention for each product. Therefore, a single team structure is insufficient. Instead, adopting a product or domain-based separation is the optimal solution, allowing each product to concentrate on its development.
Ultimately, it all depends on the situation. I may encounter more examples of team composition in the future. But if hiring budget is not the issue, I will definitely have one team with various skill sets, where in one team, I will have Backend, Frontend, Mobile, Designer, Infra, QA, and Product manager, — like a “mini startup” that focus on one domain that may have sub-domain (products/features). With this setup, I believe we can achieve many things as a team, unblock ourselves, and not depend on other teams.
Have a different viewpoint? Please share your thoughts in the comments below. If you agree with my perspective, feel free to share this so others can see it.
Such a comprehensive and insightful breakdown of team structures. I really appreciate how you explained the evolution with real-world experience, Loved the insights, and the flow was top-notch. Would be cool if you add a piece on how to deal with managers who keep reshuffling teams every month!"