When an organization is scaling up headcount, it is usually done without consideration given to how communication pathways need to adjust to facilitate scaling. Hence, once organizations attempt to scale up headcount and do not modify their communication pathways, execution speed suffers or even stops entirely.
The primary issue an organization faces in this case is not the question of who to hire, but when the cost of coordinating activities becomes greater than the opportunity cost of each team member's contribution to their overall performance.
This white paper outlines what explicit headcount thresholds will be necessary, a decision rights framework, as well as key metrics for success, so as to enable effective scaling of a tech startup team structure without diminishing execution velocity.
The Foundation Phase: Building the Core Team
The Best Starting Group
Healthcare and technology start-ups do not require complex layers of management or extensive reporting procedures. Instead, an optimal unit for most early stage start-up organizations consists of a company founder (CEO), technical founder (CTO), and an initial engineering staff of two to four.
A flat organizational structure creates a rapid feedback loop with respect to product development, allowing for rapid iterations of product design.
Adding management to the product or operational team (that is, establishing large managerial functions) at the early stages of development is a tremendous drain on an early stage start-up's resources.
Generally, the initial marketing, sales and extensive customer support functions will not be able to deliver any meaningful professional value until the company's product has reached a point where its characteristics match those in the market.
Setting Work Rules
Even when an initial product team consists of only four individuals, each individual will have multiple responsibilities. It is important to define job functions for all individuals on the product team (regardless of how many people make up that team).
A product organization should be mapping out day-to-day operations for individuals, not just defining job titles in a broad fashion.
It is also advisable for early stage start-ups to create, on a single page document, a definition of each employee's scope and daily responsibilities, along with an appropriate performance metric for each.
A company should not rely on oral agreements for defining technical standards, such as what constitutes a continuous integration or continuous deployment process, or the types of tests that will take place prior to the release of a product.
To establish a habit of implementing these processes early, and to prevent the accumulation of technical debt, clear technical standards should be put in place from the first day of the establishment of the product team.
Job Titles vs. Responsibility
Job titles will be less important during the foundation phase than how clearly you define ownership of the vision, fundraising and market discovery activity for a company.
The CEO must be responsible for defining the overall company vision, supporting fundraising and overseeing initial market discovery, whereas the CTO has responsibility for defining the architecture of an application, selecting the technical platform to be used, and leading the engineering team's technical output.
As soon as responsibilities overlap, there is a risk of teams spending too much time on discussions about decisions and too little time on developing code for the product. Clearly define who has the ultimate authority over the product roadmap versus technical execution.
Moving Past Your Startup's Early Stage Team Structure
Finding What Slows You Down
Most startups will encounter an extreme operational bottleneck when they reach a size of approximately 10-15 employees. As the number of employees increases rapidly, the number of communication paths also increases exponentially, and the original flat structure of an organization becomes extremely chaotic.
While founders must monitor their companies for certain recurring failure modes, they must also be careful to look beyond simple headcount as a measure of success.
It is easy to place too much emphasis on headcount or the expectation of employee promotions as the size of a company grows. When a company's employee count increases, it is important to create an employee lead when you have enough of a technical workload or a reporting structure such that it dictates the need for it.
Forcing your company into a hierarchy too soon could hinder the delivery of a product.
Using a 48-Hour Review Rule
It is crucial that companies make promotions based on hard data. A clear indication of an organization having a problem with their structure is if the turnaround time for a pull request to be reviewed exceeds 48 hours.
The implication is that at least one of your senior engineers is unable to manage an excessive amount of pull requests being submitted to them.
If a founder's only direct report is someone and there are more than two weeks where the technical review of the pull requests has not occurred, then it is necessary to add an engineering lead immediately.
The lack of a timely hire for this role will directly slow down the overall cycle of a company's product release, as well as cause frustration for an engineering team.
Who is in Charge of What
It’s common for people to get mixed up about who is responsible for which decisions when additional layers are added within an organization. Once this confusion starts, it’s not long before everyone is questioning which individuals within the organization are in charge of making specific decisions (e.g., hiring, finance/budgeting, software architecture).
Once you know who is going to be responsible, accountable, consulted on, and informed as related to all significant product-related decisions, you have effectively created a RACI matrix and have assigned clearly defined roles to everyone involved.
Many times, the structure of the organization can be a cause for confusion regarding decision-making, especially as the tech startup team structure expands. A classic example of this would be when company founders attend all meetings.
By utilizing the RACI framework, you can clarify accountability/decision rights at all levels of the organization, thereby reducing the tendency for founders to have to attend every meeting.
The Squad Model: How to Grow Your Tech Startup Team Structure
How to Create Mixed Product Teams
Establishing a cross-functional team will help you scale effectively. A functional organization typically breaks down when you have 15-plus developers. At this point in time, designers, product managers, and engineers will all sit in their own siloed environment.
This separation in physical and operational locations adds to the challenges associated with handing off work between different departments and will cause a huge delay in cycle time.
One way to address this issue is to create cross-functional product teams. A product manager, product designer and 3 to 5 developers are grouped together.
These teams are often referred to as a “squad” or “pod” and have end-to-end ownership of a portion of the product.
Rules for Making Product Teams
The ideal product squad will have 5 to 9 people total. This is consistent with the “two pizza” team concept that is well known and used to optimize communications, while at the same time allowing for building deeper trust within the squad.
Multiple teams can potentially duplicate a feature, resulting in unnecessary expenditure if there are no oversight mechanisms to ensure a coordinated programme. Therefore, to avoid duplication, there needs to be a consistent and coherent system established horizontally across the enterprise.
It is imperative that you create, in essence, contract-type agreements about how each of these diverse groups will integrate their codes into one another's work to produce a streamlined product without being entirely interdependent.
Setting Up Shared Groups
Guilds or chapters can be useful for keeping all technical standards high. For example, if an individual works in the front end engineer group, they would meet weekly as a group to discuss best practices and build a common infrastructure for tooling.
A joint operational layer should also be established to share the common operational requirements that will allow squads to avoid spending time and money setting up their own cloud hosting solutions or deployment pipelines.
How to Find and Fix Team Problems
Founders Stuck in Daily Meetings
When a founder has spent almost an entire week in tactical meetings executing tactical activities, it is an indication that there is a structural failure.
The hoarding of decision rights at the top layer prevents the organisation from being able to move quickly enough for the organisation to maximise its potential in a timely manner.
To fix this structural failure, you must devolve responsibility for execution to operational leads. You will use the RACI template to assign authority for decision-making at the squad level.
You must make sure that there is a weekly leadership alignment meeting with a defined agenda and that you decline invitations to attend tactical meetings.
Building the Same Thing Twice
When multiple teams release competing versions of a user profile page, there are poorly defined structural boundaries within the organisation. Lack of communication between squads and lack of an agreed-upon architectural vision are the keys to developing an effective product strategy.
To address this duplication of effort, it is important to have shared operational capabilities and a technical documentation standard that documents how squads can work together effectively.
Designating a technical lead or architect responsible for the platform’s overall technical integrity is critical. This individual will work to develop and implement strategies for sharing components between teams (i.e., libraries) instead of every department creating their own duplicates.
Signs of Slow Handoffs and Working Alone
When developers experience long turnaround times for assets, or when product managers are unable to obtain engineering resources in a timely manner, the functional model is negatively impacting speed. Each silo is focused solely on its internal metrics and not focused on the product’s release.
The easiest solution to fix this problem is to eliminate the functional isolation and create a cross-functional pod structure to better support the overall tech startup team structure.
By creating pods, the designer, product manager, and engineers work together on a single workflow and can develop cross-functional performance metrics so they can succeed or fail together.
Tracking Team Health with Numbers
Measuring Engineering Speed
To derive measurable business results from the organizational framework, organizational design must directly correlate with measurable outputs. You must measure how engineering speed changes with the change in your team structure. One way to measure this is to monitor how often you deploy to the customer.
Monitoring the lead time between when you commit code and when it becomes live is critical. For instance, if you divide a large engineering department into small, cross-functional squads, you should see a drastic reduction in lead time.
Tracking Bug Rates and Update Speed
Running fast without regard for product reliability is meaningless. As you grow your tech startup team structure, you also want to monitor the failure rate for changes. For example, when adding management layers, if communication fails, you will see an increase in the number of critical bugs being deployed to the live environment.
Additionally, the structure of your teams will have a direct effect on how quickly issues can be resolved. For example, a small accountable pod can identify and address production issues much faster than a large, generalized engineering department.
Product Reliability
The effectiveness of the team design plays an important role in determining how successful the commercial product will be. In order to know whether or not the current team design supports building and executing plans correctly, it is necessary to monitor the company's ability to hit its roadmap goals for a certain period of time (e.g., 3 months).
If a team fails to hit its roadmap goals or milestones for a period of two consecutive quarters, this indicates that the current team design may be problematic and in need of re-structuring.
A strong team design (structure) will enable teams to create a better level of predictability with what they can deliver. The ability of product managers and engineers to create highly accurate sprint plans is directly related to the alignment of their goals and objectives.
If a team is consistently missing its roadmap goals, then this could indicate that there is a lack of alignment between the authority to plan and the capabilities to execute.
New Hire Ramp-Up Time
The amount of time a new employee takes to ramp up is one of the most important operational metrics you can measure. A well-structured team should be able to get a new engineer up to speed and actively writing and submitting code within two weeks of working on the team.
If this process takes a full month or longer, it means that your team has failed to effectively utilize its internal documentation system to document the knowledge of a new engineer.
When you have a lengthy onboarding process, it means that your structure is primarily dependent on oral history, rather than documented processes.
As a result, you will need to invest time in creating and maintaining asynchronous documentation so that new hires are able to ramp up without imposing additional burdens on the time and productivity of senior engineers.
30-60-90 Day Team Change Plan
Month 1 - Finding the Baseline
The first step in migrating from a flat organizational structure to a more defined squad model will be to create a roadmap for the migration process. As such, do not make any changes to your structure overnight.
The first month of the migration process should be used solely to document the current team's workflow, and to pinpoint precisely where any inefficiencies and bottlenecks occur.
The second step in the migration process is to develop job descriptions for each of the roles in the new team, and to develop a RACI matrix that will provide managers with the information they need to communicate to the organization regarding the reasons for and benefits of the new structure.
Create dedicated communication channels for each squad, like Slack or Teams. Set up regular meetings for each pod instead of large all-engineering syncs. Create horizontal guild meetings for technical alignment.
Month 3 - Making Pods Work Best
After day 90, cross-functional pods should have been working seamlessly. You will measure impact by reviewing deployment frequency, time taken to review pull requests, and cycle times.
Determine whether the team sizes should be adjusted. If the delivery of work is taking too long, there is either too many members on the pod or a lack of a specific skill. Use the output metrics to determine the optimal structure.
Choosing Between Inside and Outside Workers
The founders of a company usually debate between hiring internal employees or using an external service. The main rule of thumb is to retain control of any company-owned intellectual property and architectural decisions.
Do not outsource the CTO role or the product management function. Anyone who is determining the company's development direction needs to be a committed employee of the company.
Balancing Fixed and Agency Costs
Outsourcing certain tasks is a good option for temporary fillers or noncore features. By utilizing a global workforce, organizations can maintain low-fixed costs and extend their financial operating periods.
Nevertheless, an internal technical team must dictate all coding standards. Developers outside of the organization are expected to work within the established CI/CD pipelines and code review standards set by the internal product and engineering leaders.
Setting Communication Rules
Your organization's communication standards – whether you use freelancers remotely, an agency model, or hybrid internal team model – are essential to the success of your organization. Communication within a remote-first organization requires a default asynchronous model for effective communications through time zones.
Create strict meeting budgets to avoid the calendar clutter of excessive meetings. Establish precise boundaries and timelines for response to each communication tool so that focused work is not disrupted frequently by instant messages.
Matching Your Tech Startup Team Structure to Growth
The key to scaling a startup is managing operational complexity. Successful startup founders view organizational design as an evolving concept rather than a static piece of paper on the wall.
Founders develop and adapt their structure based on quantitative data triggers (e.g., the average pull request review time, roadmap hit rate) that indicate to the founders when they have specific, measurable operational bottlenecks that require a specific number of management layers to be added to the company's structure to resolve those issues.
An effective engineering and product organization is dependent on the continuous measurement and ongoing courage needed to dismantle what has historically worked well for your organization.
By tying your team's structure to quantitative measures (e.g., deploy frequency and onboarding ramp time), leaders will have clear indications that a flat structure has now become a liability. The process of transforming from a lean core structure to cross-functional teams allows a company to maintain early stage speed in execution while pursuing complex, multi-faceted market growth strategies.
Common Questions About Growing Your Team
At what point does a flat structure become dysfunctional?
A flat structure typically becomes dysfunctional at 10 to 15 employees. While a break in function is often not observed on a raw headcount basis, it will be seen clearly on the execution metrics related to that structure.
When pull request review times surpass 48 hours or founders are acting as bottlenecks for basic architectural decisions, the flat structure is hindering your cycle time, and layers of management must be established immediately.
How should a tech startup organize its hiring plan concerning using AI tooling?
AI tools have shifted the baseline requirements for engineers who begin working within a startup. Startups are now hiring fewer junior developers to complete simple coding tasks and, instead, hiring more senior engineers who can utilize AI to magnify their personal outputs.
Therefore, the focus of structural emphasis has been shifted away from coding and now resides firmly in the areas of systems architecture, code review, and oversight of AI integration.
What are the quickest ways to break down functional silos that delay the launch of products?
If product managers, engineers, and designers are waiting on one another within different functional departments, it is imperative that you disband those silos immediately. Instead of separating individuals into separate functional departments, organizations should create a cross-functional team around a single metric or feature for the product.
By creating common goals and goals for the new unit, each member of the team (design, product, and engineering) will share the same common success criterion and succeed or fail together as a team.