7

Scaling your technical team

Build in squads

Create and empower squads

As you add functionality and richness to your product, you inevitably need more “Builders” to keep developing new stuff. You also need Builders to maintain and scale your existing stuff. This means your technical team is likely to grow rapidly, particularly in pure software businesses.

TYPICAL TECHNICAL TEAM COMPOSITION BY COMPANY HEADCOUNT OF 50 TYPICAL TECHNICAL TEAM COMPOSITION BY COMPANY HEADCOUNT OF 50

However, you can’t just keep adding engineers, product designers, data scientists, and others without creating a clear organizing framework. Squads (also known simply as “teams”) have become the near universally accepted route to scaling technical functions, an approach that dates back to a classic blog post published in 2012 by Spotify. The basic idea is to avoid prioritization by committee, and instead to create a North Star metric that each squad is empowered to deliver.

Some guidelines about squads to maximize their agility and productivity:

  • Each squad should have a blend of skills across Engineering, Product, Design, and potentially Analytics. Resources from other functions (including non-technical) might also be appropriate. Engineers are generally dedicated to a single squad at any one time. Other members may work across multiple squads depending on your overall capacity constraints and the need for their skill set.
  • Squads don’t have hierarchical leaders. The two key leads are the:
    | Product Manager (PM), whose role is to align the team members around shared priorities and objectives, but without any formal authority to direct. The PM's effectiveness depends upon their influencing skills, integrating and balancing everyone’s perspectives.
    | Tech Lead Manager (otherwise referred to simply as the Tech Lead, or TL), who oversees engineering aspects of the squad’s work, such as architectural or design decisions.
You need balance in your squads. If Product goes unchallenged, you can get endless new features, because Product people have a tendency to find problems where they didn’t see them before. If Engineering dominates, technical debt can be over-prioritized. If Design, you can get experiences which aren’t financially viable.

Gabriel Hubert, Co-Founder, Dust and Product Lead (former), Alan

  • Teams work best when internal trust is high, but where there’s a healthy tension and respect between the distinctive mindsets and priorities that each member brings.
  • There should be a maximum of eight to 10 members. Beyond that, you should look to split them again into more focused squads. This reflects Jeff Bezos’s canonical “two pizzas rule”: Every internal team should be small enough that it can be fed by two pizzas. This allows them to move fast.
  • Each squad should be aligned with a product part or business function that can be clearly defined.
  • The squad is given ownership and responsibility for how to achieve this goal, and teams should be as decoupled as possible, to minimize their need to coordinate or seek permission from anyone outside the squad itself.

Recognize that squads are not static

Squads might have persistent goals, while others might be assembled to work on a specific project or time-bound objective. A persistent squad might handle ongoing development and support of a specific product. Another might implement a new cloud service, or build the features needed to launch in a new geography. If a squad with a specific project achieves its goal and is disbanded, a persistent squad will need to inherit and maintain the codebase or service. This can create tension, and some technical thought-leaders push back on the idea of temporary, project-based squads. No clear consensus has emerged, which is true of several elements of technical team organization beyond the basic squad approach.

My philosophy is that if you build it, you run it.

Carlos Gonzalez-Cadenas, Index Ventures

The individual members of a squad will also change over time, although you need to strike a balance between change and continuity. The depth of knowledge in their area, as well as the mutual trust that builds up in a stable squad, are part of what makes them more effective. Staffing changes may be the result of:

  • Shifts in squad priorities. For example, if it progresses from “innovating”—adding new features or tooling at a high velocity—to more of a steady state—“maintain mode”.
  • Offering career development opportunities for squad members
  • Squad members leaving the company
The effort you put into a product is totally driven by where it is in the lifecycle. A one-size-fits-all approach doesn’t make sense. A nascent product could involve a squad with as little as one product manager and one engineer, while a mature product could have a 1:10 split.

Thomas Soulez, Chief Product Officer, Silae

At the start, technical squads will all be oriented to external customer problems, with metrics that link to commercial priorities and engagement. For example, in a marketplace you might focus one squad on users, another on suppliers, and a third on marketplace operations such as payments. As you scale further, though, you need squads which are more internally focused. For example, on infrastructure requirements or internal tooling to support other functions in the company.

In the early stages, our teams were all product-focused. This naturally extended to core infrastructure teams as we scaled. We resisted for as long as possible adding the third, middle layer: platform teams. The risk is that these teams are too distant from customers—things that sound like good ideas, but aren’t tethered to validated needs. So we only introduced platform teams once we went multi-product. That was four years ago [2019—as Datadog approached 1,000 headcount], when we needed our products to sit on top of a more consistent underlying foundation.

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

Expect your technical team to shrink in relative terms

As overall company headcount grows, your technical team will shrink relative to other areas of the business. However, this varies dramatically between business models, as does the balance between Engineering, Product, Design and Data Science. Software companies (B2C App and SaaS) retain the largest technical teams at scale in relative terms, falling slightly from 40% of employees at 50 total headcount, to 35% by 1,000 headcount. Marketplaces fall from 26% to 23% over the same period, while D2C companies have the smallest technical teams, falling from 24% to 20% of total headcount.

Other differences in technical teams are apparent between business models. For example, the ratio between product management and engineering is highest in pure software, at 6:1 in earlier stages and rising to 8:1 in later stages. In Marketplaces and D2C businesses, this ratio hovers nearer to 5:1. This reflects the fact that product managers in pure software are mostly delivering results through collaboration with engineers, without having to consider suppliers, inventory and other external factors.

As a second example, data science teams are significantly larger in pure software relative to Marketplaces or D2C, which instead rely more on business information (BI) analysts to support decision-making.

Each of these differences corresponds to how central tech is to delivering overall customer value, and to the intensity of integration required between software and operations.

Be mindful of how these factors related to your business model will shape your optimal technical team mix as it grows.

TECHNICAL TEAM MIX VARIES DRAMATICALLY BETWEEN BUSINESS MODELS TECHNICAL TEAM MIX VARIES DRAMATICALLY BETWEEN BUSINESS MODELS

Balance levels of experience

You want to aim for a balance between more and less experienced employees. Significant differences in seniority mix between more and less experienced founding teams persist as you scale your technical team, with less experienced founding teams continuing to make fewer senior hires. If this is you, you need to focus on counteracting this tendency, to ensure that less experienced team members can be supported and trained by more senior colleagues.

Highly successful companies retain a similar balance (to the bars above) of experience levels across their technical team even as they scale through to IPO-readiness. Active graduate recruiting and career progression can help here, allowing you to grow your own technical talent pipeline and be less dependent upon brutally competitive external hiring.

TECHNICAL TEAM SENIORITY MIX BY 50 HEADCOUNT—AND DIFFERENCES BY FOUNDING TEAM TYPE (%) TECHNICAL TEAM SENIORITY MIX BY 50 HEADCOUNT—AND DIFFERENCES BY FOUNDING TEAM TYPE (%)

Take a long-term view on ROI

Technical teams are the modern equivalent of factories in the industrial era. Your decision to invest in building a new squad is more like a capital expenditure, because you won’t know for years whether the investment was worthwhile. You therefore have to take a long-term view on ROI. This contrasts with investing in GTM teams, where ROI can be assessed quickly, and decisions can be reversed if necessary—for example, if salespeople aren’t hitting their quotas.

When interest rates are low, capex becomes more attractive. In software companies, this makes it more attractive to invest heavily in your technical team. In today’s higher interest rate environment, you need to think more carefully about it, because the hurdle for delivering positive ROI has gone up.

Mike Volpi, Index Ventures

If you’re on top of everything, you’ve got too many people. Scarcity creates friction which forces prioritization. Friction is where you get great software. Conversely, you’ve got too few people if you’re leaving low-risk money on the table due to capacity constraints. For example, if you’re unable to launch your sixth new country even though you’ve got a successful playbook for five already.

Simon Lambert, CTO, Birdie

When you’re small and racing towards PMF, things are clear and super tactical. You have aligned goals, with six or seven things to do or ship at any one time. At scale you need different DNA: clarity around metrics and resourcing, and concrete success criteria. These underpin your priorities and investment decisions.

Michael Manapat, CPTO (former), Notion

The long-term horizon of technical team investments can drive an unhealthy obsession with measuring technical team productivity or output. We recommend an alternative approach—measuring the impact being delivered relative to the investment.

Technical team productivity

I’ve never been a fan of directly trying to measure the productivity of technical teams. There have been so many rabbit holes and ridiculous attempts to quantify it. For example, “story points” shipped. As soon as you measure something like this, you end up with the wrong outcomes. The process of building product is just too nuanced.

Instead I recommend reframing the question as, “Should we have 0.5 × or 2 × the team size that we have today, or are we about right?”

You can review this team size question from two directions:

Top-down: Technical cost as a percentage of revenue, and technical headcount as a percentage of total headcount. Seek out benchmarks for both of these at comparable tech companies. [You can also use the TeamPlan companion web app to this handbook.]

Bottom-up: Consider your product’s surface area. Break it into chunks, and give each of these to a team or squad. Make sure you can cover all of them, taking account of complexity, operational load, the number of services, etc. More backend-oriented teams tend to be operationally intensive; the focus here is on maintenance and uptime, rather than innovation. For example, at Skyscanner our “flights processing service” was super intensive, with a focus on constantly putting out fires. By contrast, our frontend squads could move faster on introducing new features. Also look at where your surface area is increasing and will need additional teams in the next year or two.

We often see a period during which engineering bloat (declining productivity) becomes a problem for companies beyond a certain scale—generally when they exceed about 100 engineers. The root cause has to do with bottlenecks. This is largely solvable if you organize your teams and service architecture correctly. Focus on decentralization, breaking into small teams with clear remits and the autonomy to ship independently. Enable these teams with the right DevOps tooling and service-oriented architectures. The key question has now shifted to, “Who makes decisions on what individual teams do?” In my opinion, the right balance here is that teams should decide on 50–60% of their time allocation, with 40–50% being driven by company-wide objectives.

Overall the focus should be more on measuring the impact of what is being shipped, rather than measuring shipping productivity itself. Does the impact justify the additional investment? Are you delivering true value and differentiation, or spinning your wheels by introducing way too many minor tweaks that won’t be that impactful? This is how a culture of innovation truly dies.

Carlos Gonzalez-Cadenas, Index Ventures

Datadog’s approach to delivery velocity

Shipping velocity is easy to articulate but hard to measure. We think about it constantly. In simple terms, we aim to be a growing body of products and initiatives which are heading generally in the same direction, but which are allowed to move at different speeds because they are decoupled.

Our focus is on ensuring that the time we take to bring a product to market is as fast as it was in our early days. For example, it took us two years to get from the initial idea to deployment of Application Performance Monitoring (APM), one of our core products. So similarly complex products should not take longer as we grow.

But the two years doesn’t guarantee that we actually built the right thing. So we aim to bring products to market as quickly as possible, so that we can gauge customer reaction before deciding whether to push further, or to abandon them.

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

The longer time horizons required for technical teams are exacerbated by the time it actually takes to hire engineers and to fully ramp them. You need to have realistic expectations about how much product development is actually achievable, given this reality.

I’ve seen this happen repeatedly. A technical team needs to be scaled from 20 to 60 in a year, but delivery plans assume you already have the 60 in place to start building. Plan in terms of the team you have today!

Surabhi Gupta, SVP Engineering (former), Robinhood

Take active steps to sustain innovation

Innovative technologists will leave your company if you move too far into “maintenance mode”.

There’s also a danger at scale of creeping incrementalism rather than true innovation. Internal politics can favor risk-minimization—“It’s safer for me to deliver low-risk but tangible stuff, even if the impact is low.” It’s true that incremental improvements can generate significant benefits at scale. But on the other hand, new products capable of delivering step-changes in your growth trajectory aren’t born this way.

Once you sense that maintenance mode is creeping in, you need to intervene top-down by identifying individuals, or potentially teams, to focus on true innovation.

It’s not good enough for anyone to be merely a maintainer. Everyone needs to be customer-focused and entrepreneurial, so that you foster a culture of continuous innovation even in your core product. Call it, ‘Maintenance+++’.

Maria Angelidou-Smith, CPTO, Personio

You need both personas in your technical team: innovators and maintainers. But you have cycles as different teams shift between the two states. My solution is tactical intervention—moving the highly innovative people around more. They usually get bored if you don’t move and give them the opportunity to do what they do best, so they’re generally happier with this approach.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

Once your technical team grows beyond 100 people, we also recommend periodically reviewing it in terms of an 80–20 innovation split: Invest 80% of effort into your core business, and 20% into new (adjacent) developments. This differs from the more widely known 70-20-10 model of innovation which is better-suited to lower growth corporations in search of transformation. In a high-growth startup, you’ve already discovered your transformational innovation and don’t want to be distracted in pursuit of radical alternatives.

The challenge with any planned split between maintenance and product building is having visibility into the type of work being performed. Ideally, the tools for managing the day-to-day work of teams provide real-time insights as well.

Surabhi Gupta, SVP Engineering (former), Robinhood

About a year ago when our technical team hit about 200, we shifted to ‘portfolio’ thinking about our engineering organization and time. It hadn’t been much of an issue before, but we now aim for a split of 60% spent on current product priorities, 20% on longer term investments and 20% on technical excellence, such as repaying technical debt and UI polishing.

Michael Manapat, CPTO (former), Notion

Recognize the limits of the squad model at scale

Fostering innovation can be seen as part of a broader challenge with the overall squad model. Up to 15–20 squads, it appears to scale relatively well, and the benefits in terms of agility and speed are clear. However, beyond this point, when your overall tech team reaches about 200, cracks rapidly appear. Communication between teams becomes an issue, as does efficiency and duplication of core tasks. Interdependencies mean that things slow down as decisions need to be escalated, or incidents become more frequent and severe.

The original Spotify model had additional structural elements: tribes (for organizing groups of squads), chapters (groups with common interests across squad specialists, such as testing or security/privacy) and guilds (less formalized interest groups across squads). However, these have to some extent been discredited as not workable in practice, including at Spotify itself. There is no clear alternative consensus on how best to organize technical organizations at scale. However, certain elements of a more traditional management structure are required to supplement the squad model even at earlier stages of growth, and will be discussed below.

Many companies chase specific philosophies with weird labels. I’m not a fan. It’s just confusing and inefficient. To me, when you’re small and trying to go after multiple projects, it’s really hard for designers or data engineers to be part of squads. There’s simply not enough folks to dedicate someone fully to each project, plus it can be hard to mentor or develop them depending on seniority of folks at the company. You will need dedicated central teams, with a culture to support, say, a design studio, or informal interest groups. So there is no one-rule-fits-all. Your team model needs to evolve given the circumstances you are dealing with.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

Engineering

How to hire in the early days

Be wary of hiring folks straight from Big Tech who lack startup experience. There’s a temptation to go after “six years at Google” profiles. But while these companies teach great engineering practices, they tend to be about “how to do the job right” versus “how to do the right job”. At the early stage, you don’t particularly care about code accessibility—it’s all about shipping. Your early engineers will need to be their own product managers. They need to get their hands dirty, rather than being too process-focused.

This risk not only applies to hiring from post-IPO tech companies, but also to larger pre-IPO companies. The only exceptions are where big companies are housing segregated projects, such as Google Brain. These can attract specialists who are obsessed with their area, and who can be startup-oriented in their approach.

Domain experience matters less nowadays. For a start, there’s a broader set of tools such as MongoDB, which reduces the need to have your own database team. There will be even more of this in the coming years thanks to AI, with generalist engineers leveraging open AI APIs and LLMs. So unless you’re specifically building a database or an LLM company, domain specialties have less value. Likewise sector experience doesn’t matter much in engineering. It’s much more about the overall caliber of the individuals.

Shifting industries—for example from SaaS productivity into health tech—is far easier for engineers than for other functions.

Zabie Elmgren, Index Ventures

I’m definitely seeing the impact of AI on the strongest engineers already. Given the progress, I expect that over the next five years we can bank on a 40–50% velocity boost across the org as a result.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

Your location makes a big difference to the availability of technical talent, particularly at junior levels. In Silicon Valley or New York, there’s a high density of ambitious early to mid-level IC engineers who are interested in startups. Outside of major hubs density drops dramatically. You’re more likely to find senior profiles, who are also generally more open to remote opportunities. Similarly, more experienced founders are more likely to have the confidence to build a distributed or remote team early on, and therefore will be more able to leverage this senior talent.

Bring in engineering specialists as you scale

At the start, your engineers will mostly be generalists who can all write code and turn their hand to pretty much anything.

You always need people who are not necessarily experts in any one area, but they understand the tech enough to get 80% of the way there on anything they get their hands on. They’re hard to come by, but find them and empower them, particularly earlier on.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

Over time, functional specialties get more granular. This is partly a reflection of technical talent pools. True full-stack engineers are a rare breed who are particularly drawn to working at early stages due to the breadth of the role and the impact they can have. But the majority of engineers lack the interest or skills to be considered truly full-stack. Instead, they tend to focus on more narrow aspects of engineering—most frequently backend, but otherwise frontend or mobile.

If a mobile-native app is core to your offering, then hire iOS and Android developers. If you’re SaaS with important security considerations, then hire security specialists. It all depends on your product, and how you can gain competitive advantage.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

As your product matures and your company grows, you also need more specialist attention on “horizontal” considerations such as infrastructure. For example, as a startup, security needs are there, but they’re simple (e.g. SOC2 compliance). At scale though, you become a target for hackers, and the consequences of a security breach become existential, so you’ll need a specialist security sub-team. This shift towards specialists will be mirrored elsewhere in your engineering organization, where generalist developers are supplemented with security engineers, data engineers, DevOps engineers, and so on.

Once you hit 100 engineers, you’re probably into the rapid scaling phase, and will face a whole series of options and decisions about your technical stack. It’s critical by this point that you have some internal experts with deep specializations—for example, in data architecting or frontend foundations. Without them, you end up with solutions that need to be reworked (debt to pay back) which can halt your progress significantly as you scale.

Maria Angelidou-Smith, CPTO, Personio

By 250 total company headcount, you will also need to formalize roles and systems in:

  • IT—desktop support
  • Business applications—advice across the company on vendor selection, and to support implementation and integration
  • Data engineering and data science—creating a centralized data infrastructure and tooling, for users across the business

The traditional corporate model separates IT and business applications into a separate technical group, potentially overseen by a Chief Information Officer (CIO)—separate from the CTO—who focuses on customer-facing solutions. However, modern companies typically keep all of these activities within a single engineering group and leadership structure, recognizing the high degree of overlap between these areas. For example, business applications such as CRM are increasingly integrated into core product and customer workflows.

I’d previously seen the importance of reliable and timely metrics as you scale. We made sure to invest in data science and data engineering support before it became a problem for us.

Surabhi Gupta, SVP Engineering (former), Robinhood

But avoid over-specialization

While certain specialists become essential, over-specialization leads to fluffy positions, where people outsource or delegate the stuff they don’t like. For example, basic unit testing should remain a core responsibility of your developers. You may need some testing specialists at scale, but if so, their focus might only be on QA/testing tooling, or on particularly tough testing elements. While it’s straightforward to push out new releases for SaaS software, for example, mobile apps are trickier, so testing needs to be more comprehensive and systematic upfront.

QA is a classic. If you have a separate QA team, you’re signaling to your developers that quality is no longer their responsibility. It creates ‘moral hazard’.

Carlos Gonzalez-Cadenas, Index Ventures

The number of tests you can conduct is limited only by your imagination. So our guidance is: make sure the stuff you build works for the intended use cases. Release, and then observe for unexpected instances or breakage points which need to be fixed post-live.

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

When I started at Snap, we were a small engineering team and had the mindset that engineers should be wholly responsible for deploying and maintaining their own code. There were no separate test teams, no separate DevOps teams. We scaled this ‘no SRE’ model almost until my departure, at which point we had thousands of engineers, and it worked very well.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

As your organization scales, engineers need to shoulder additional responsibilities when it comes to developing productionlevel code. This includes broader testing requirements, improving alerting and observability, and optimizing performance. Implementing more rigorous testing standards can raise deployment quality and lower the incidence of issues.

Surabhi Gupta, SVP Engineering (former), Robinhood

SPECIALIZATION—THE EVOLUTION OF SAAS ENGINEERING TEAMS (%) SPECIALIZATION—THE EVOLUTION OF SAAS ENGINEERING TEAMS (%)

Find engineers who are effective people managers

With large numbers of engineers working in non-hierarchical and cross-functional teams, distinct management challenges arise. There are two approaches to handling people management issues in engineering teams:

  • Tech Leads (TLs) focus on engineering quality and shipping velocity within a single squad. Formal people management is handled by Engineering Managers (EMs) who each operate across two to four squads to ensure that execution is aligned and coherent, beyond the squad’s own immediate delivery goals.
  • Tech Lead Managers (TLMs) with combined responsibility for technical and people management within a single squad

In the first approach, the main disadvantage is the ambiguity of management responsibility, since TLs are overseeing the work of engineers in their squad on a day-to-day basis. The central challenge of the second approach is securing enough TLs who are foremost excellent engineers, but also strong at people management. Therefore, at scale most companies switch to the first approach, or to a hybrid model where some squads have TLMs, while others simply have a TL.

The TLM model is cleaner. It avoids having too many cooks in the kitchen. With separate EMs and TLs, individual engineers can end up with two bosses. But the downside is that tech leads often aren’t the best people managers! There’s no perfect solution or common industry conclusion. Companies tend to follow one route or the other, or they flip flop, or they might hybridize.

Carlos Gonzalez-Cadenas, Index Ventures

Even though there are different approaches to the precise role of EMs, they should not be writing code, although they may be reviewing code. For example, they may have responsibility to:

  • Ensure that commitments to automated testing are adhered to
  • Ensure that engineers are getting the learning opportunities to progress, such as paired-coding to nurture graduates

In even larger engineering teams, Engineering Directors (EDs) may also be appointed, who define and align these requirements across larger groups of 50–70 engineers (i. e. up to 10 squads, and potentially covering broader cross-squad topics such as testing).

It’s really tough as a CTO to keep on top of EM and ED effectiveness. They’re conceptually the right roles to introduce to set you up for long-term success. But when your focus is on immediate delivery goals, the EM/ED role can become an easy place to hide, delivering limited value.

Simon Lambert, CTO, Birdie

EDs are also a conduit for the CTO or VP Engineering to monitor progress. An ED should be able to explain in detail what’s going well or not across their teams—for example, where an intervention may be required, or what lessons were learnt. If an ED can’t answer these questions without asking someone else, this suggests that the model isn’t working.

We require our EMs and EDs to be deeply technical and fairly involved in the day-to-day of whatever their teams are working on. We concluded a while ago that it’s not sufficient for them to be great people managers. They also need to be capable of insightful written and verbal commentary. We expect them to proactively spot and fix challenges, and to explore opportunities.

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

KPIs for EMs & EDs are primarily people-focused, such as:

  • Employee satisfaction
  • Talent retention and development
  • Team productivity (impact)
  • Project success
  • Technical debt reduction

Be thoughtful about engineering leadership

Although half of successful startups have a co-founding CTO, only a small proportion of these are familiar with the demands of managing a large engineering team. In the early days, you want someone who can hack code rapidly and efficiently, taking you to an MVP and then towards PMF, iterating and hunting for shortcuts. But with multiple squads and specialist sub-functions in your engineering organization, you need an effective and enthusiastic People leader with a strong focus on delivery. This involves a very different skill set and draws on very different sources of motivation.

At the very least, co-founding CTOs should be supported to successfully adapt to these new needs by an experienced technical coach or mentor. But where they lack the desire or personality, a shift in technical leadership to a professional CTO or VP Engineering is an established solution. Sometimes this is a smooth transition, but it can also be fraught and painful to manage. It’s important that as co-founders and major shareholders, you are both upfront and clear about prioritizing the company’s needs. Managing the shift represents an important early test of maturity in managing leadership transitions.

MOST SENIOR ENGINEERING LEADER—SOFTWARE COMPANIES (%) MOST SENIOR ENGINEERING LEADER—SOFTWARE COMPANIES (%)
Datadog—A co-founding CTO leading an engineering team of 2,000

Now I focus almost entirely on the technical side, but in the earlier days it was everything and anything. I see my role as doing what needs to be done, from picking the right health insurance plan through to formulating strategy. I would ask myself what things we needed to be doing that we weren’t, but which could kill us. Conversely, what were we doing now that we shouldn’t be. I would observe how this was playing out across the company and dive in. I had stints running CX and HR along the way.

I focused on where I could have a singular impact, which is rare these days! But I also looked out for bottlenecks, where individuals were over-stretched and falling behind on important stuff. For example, in the early days when SaaS was only slowly being accepted by enterprises, I’d fill out security questionnaires, because other engineers were focused on coding, and I could complete them pretty fast. I did five, then 10, then 20, and then 50. I then said, “Ok, can we now figure out how to do this more systematically without relying on me?”

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

A common solution to leading large engineering teams is to hire a VP Engineering who takes on team management and delivery. In this case, you need to assess the best management structure with your co-founding CTO. If they are the right individual to retain overall engineering leadership from a technical perspective, the incoming VP Engineering may report directly to them. Alternatively, the co-founding CTO may step back from overall engineering responsibility, with a more focused role, which may include:

  • Overall vision and roadmap for technology in the company
  • Innovation, research and new product development—retaining a small team of their own
  • Architectural decisions
  • Technical liaison with key customers and partners and interfacing closely with commercial teams
  • Bar-raising and talent branding initiatives around technical hiring
  • Open source strategy—community collaboration and participation

In this setup, it’s healthier for the VP Engineering to report directly to the CEO rather than to the co-founding CTO (even if the co-founding CTO retains their title). Top candidates will also insist on this structure.

It was a multi-year journey, with a lot of emotional turns, to shift my co-founder’s role from CTO to a more narrow focus on research and innovation, relinquishing team and broader responsibility to a new VP Engineering.

Anonymous Founder

In some cases, the co-founding CTO would prefer to step away from the company entirely, in which case you may choose to directly hire a professional CTO.

The vast majority of excellent engineering leaders with proven experience of managing teams at scale are to be found in the major tech companies. Given the status associated with working for these firms, as well as the generous compensation structures, three-quarters of the potential candidates won’t even acknowledge an opportunity from an early (or even growth) stage startup. And most of these individuals wouldn’t be right for you either. You’re looking for the minority of leaders who still enjoy operating in the weeds and staying heavily involved with their teams.

As an incoming engineering leader at a growing startup, you’ve got to recognize that the role isn’t just about scaling, but also about cleaning up the mess. You’ve also got to recognize that creating a mess was what earned the right to get to this point.

Simon Lambert, CTO, Birdie

To some extent it’s a game of numbers and luck, but you can improve your odds by leaning on warm intros from your investors and network.

While I was at Snap, I had dinner with two Index team members in relation to angel investing opportunities, when one of them pitched me on Linktree. At first I just said no, but he persisted, and I ended up speaking to Danny Rimer [Index’s partner on Linktree], after which I started to get very interested.

Farnaz Azmoodeh, CTO, Linktree and VP Engineering (former), Snap

Wise—Hiring a professional CTO

I joined Wise in 2015 when there were 300 employees, with 40 in Engineering. I’m still the CTO today, with 750 in Engineering alone.

I relocated to London from the Bay Area, after 11 years at eBay and PayPal. The problem being solved by Wise was what appealed to me. I had direct experience of the pain of moving money across borders, having moved to study in the US from India. I knew that it was a complete ripoff. I had also witnessed the explosion of international payments at PayPal and eBay.

Kristo [Wise’s co-founder] convinced me to fly out on Thanksgiving Day to Estonia to meet the team. I was super busy with Black Friday preparations before the launch freeze at eBay, but I went, half-thinking that I must be crazy. But after spending three days there, I realized that this was something special. Young and driven people, aggressively learning. 24-year olds were launching new countries. Several of them reached out to me for insight before I even accepted. I was personally up for the challenge, as was my wife. We didn’t have kids yet so it felt like now or never. This all gave me the confidence to say yes.

Harsh Sinha, CTO, Wise

Create an engineering metrics dashboard

Once you establish multiple squads and lose direct visibility into what’s going on, it’s important, culturally as well as operationally, to set up a metrics dashboard in Engineering. Over time it will inform your leadership decision-making, and should cover four key areas, although the starting point might just be two or three metrics—for example, bugs created plus hiring versus plan:

  • Quality—bugs created, incidents recorded (with severity), reliability metrics, uptime, scaling validation
  • Velocity—sprint-level features shipped, experiment velocity (experiments shipped plus percentage of experiments that rolled out generally), aggregate code output, developer experience (cycle time from creation of change to deployment)
  • Cost—payroll cost, non-payroll people cost, cloud spend (with splits by service), tooling spend
  • People—hiring versus plan, funnel metrics (including offer acceptance rate), candidate NPS, attrition, eNPS

Open secondary engineering centers

The rationale for opening additional engineering centers (ECs) is in order to tap into new talent pools. This may be a function of the depth of the engineering talent pool in the city where you start, together with your success in creating an appealing and distinctive engineering talent brand. If you start in a smaller city, you’re limited both by the sheer number of suitable local candidates and by the appeal of the city as somewhere people want to relocate.

When I started, we had 40 engineers, with most of the team in Tallinn [Estonia], alongside a small team of seven in Ukraine. We now have 750 across seven product engineering locations and London is larger than Tallinn. We simply tapped out the talent pool in Estonia.

Harsh Sinha, CTO, Wise

You could also open secondary engineering hubs in lower-cost locations, with teams focusing on less complex aspects of your engineering stack. This allows your core team to focus on higher-value activity.

However, when you’re at pre-IPO scale, it’s more important to optimize for productivity versus cost, so be wary of opening up additional ECs that will pose travel or time zone challenges. US growth-stage companies should look to secondary hubs within the US, or otherwise in Latin America. Conversely, Western European companies might look first to Eastern Europe.

Notion’s engineering center in India

We inherited an engineering team in Hyderabad through an acquisition. They’re doing great and varied work for us (including AI initiatives). Each quarter, the mission and charter for the office gets clearer, meaning less real-time coordination is required. I’m grateful to the team there for their heroic work staying in sync with us given the time zone challenges. We now need to establish PMs on the ground so they can be more self-owned, rather than relying on a New York-based product lead.

It’s also been a learning journey to adapt to the hiring dynamics which are so different compared to the Bay Area, including interview style and offer process.

Michael Manapat, CPTO (former)

Give engineers special attention

Engineering teams are special in high-growth startups in at least three different ways:

  • They are “beta testers” for approaches to management. In software companies, engineering teams scale the fastest, so the need for People processes appears here first. This is accentuated because as you scale, you will increasingly be hiring from large tech companies, with sophisticated processes around career progression and job leveling. That forces you to follow suit to some extent. But engineering teams also represent a tough beta testing environment for HR processes, and for more traditional people professionals who rely on empathy and emotional attunement. By nature, engineers may ask more probing questions and expect strong rationales to support decisions that affect them.
  • Their compensation should be higher. Compensation for engineers is significantly higher than for other functions, as a simple reflection of supply and demand. This fact has to be accepted and translated into pay-grids with wide disparities relative to other functions, particularly at more junior levels. This applies to both cash and equity components of compensation.
  • They need specialist processes: Certain processes are also bespoke to Engineering. For example, incident management requires deep post-mortems, since downtime becomes so painful and expensive with scale. Incidents in other teams, such as Operations, rarely have such broad and deep implications, so can be handled with a lighter touch. As another example, retaining the best engineers at scale requires an IC track to career progression with no ceiling, separate from people management pathways (a manifestation of the “10 × engineer” philosophy).
In the early days, the engineers we hired didn’t care about job titles or levels. Stock options and their day-to-day work was what mattered. We also actively avoided hiring people for whom job title mattered. But when we needed to start hiring actively against the tech giants, we were forced to adopt their rules to some extent to remain competitive. The engineering mindset has a tendency to cover every eventuality, which leads to career frameworks being overly complicated, instead of rough guidelines. People can end up chasing promotions too often. We’ve pushed back and returned to a simpler and tighter model.

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

You need buy-in from Engineering for People processes if they are to have internal credibility, and therefore drive high performance. This means involving Engineering in their design and customization. The best candidates will also have strong views, asking detailed questions about how you stack-rank, what gets incentivized and rewarded, what ‘hard’ skills are expected per level, etc.

Maria Angelidou-Smith, CPTO, Personio

Product

At the start, you are the product manager

The story of scaling product teams is one of accepting the progressive shift and delegation of responsibility from the founder(s). But this needs to happen gradually.

It rarely makes sense to hire anyone in a dedicated product role in the early phases of a startup, i. e. as part of the first 10 hires you make. As founder(s), you are the product manager. The product vision, strategy, and roadmap is still going to be very much in your head, so you need to retain full responsibility and stay super close to it. Your early engineers should also act like “product engineers”—they need to stay close to relevant user and customer feedback to inform what they are building.

Having said this, we do sometimes see successful early product hires, particularly associated with one of two situations:

  • When the problem space encompasses specialist knowledge that the founders do not feel confident in—for example, tax compliance or IP law. Bringing this understanding in-house can accelerate your path to finding PMF, and also gives early customers more confidence in your capabilities.
  • In D2C models, where the founder may be more focused on and familiar with the physical product rather than digital, in which case it can make sense to hire a separate “digital product manager”.
PERCENTAGE OF STARTUPS HIRING A PRODUCT MANAGER PERCENTAGE OF STARTUPS HIRING A PRODUCT MANAGER
Seeing a seed stage company hiring a product manager is a bit of a warning sign to me. In most cases, the founder should be the PM at this stage and not rely on someone else. Design hires are often more impactful early on.

Zabie Elmgren, Index Ventures

Only make your first product hire once you’ve hit initial product-market-fit.

Gabriel Hubert, Co-Founder, Dust and Product Lead (former), Alan

Understand why you need product managers

Some founders are drawn to the Stripe approach to product management: Stripe had zero PMs until total headcount was over 250, with engineers instead taking full responsibility for designing and implementing new features as “product engineers”. While there’s something to be said for this philosophy, it has significant limitations for most companies for two key reasons:

  • Founder bandwidth—Once you’ve hit initial PMF and raised significant (Series A) funding, you’ll be drawn increasingly into hiring and selling. You’ll become a bottleneck to product development if you don’t find someone who can manage day-to-day interactions and decision-making with your engineering team. Shipping velocity will suffer.
  • Engineer bandwidth—With increasing numbers of users and use-cases, staying on top of customer feedback and evaluating priorities or tradeoffs becomes harder. If your users are developers themselves (as with Stripe), engineers might find this somewhat easier. But if your users are consumers, and even more so if they are non-developer B2B professionals (lawyers, doctors, marketers, etc), your engineers will struggle to get deeply inside the customer persona and quality will suffer.

Product managers help to bridge these gaps between your product vision, customer/market needs and optimal technical solutions. As you grow, this bridging role will get tougher:

  • Use-cases expand
  • Product surface area widens
  • Internal customer touchpoints become more numerous—Marketing, Sales, Customer Success, CX, etc
  • Existing technical architecture imposes constraints

You’ll therefore need more product managers, aligned with technical squads, to manage this increased complexity.

Notion—Product managers or product engineers?

We waited a long time to hire product managers, and it’s still a small team—less than 15 out of 550 in total headcount. We didn’t have any PMs until two years ago, at around 50 or 60 engineers. I’m not sure this was actually ideal. Both Notion and my former employer Stripe are very engineering-driven to start, and both companies have a very product-minded engineering core, which I think is a great thing.

That said, there is a difference between engineers who think about product, and product managers who are out there talking to users and bringing in user feed- back constantly, coordinating closely with go-to-market teams, and thinking deeply about product strategy. I think that was missing at Notion early on. So I’m glad we have PMs now and that we’re growing the product management team.

Michael Manapat, Chief Product and Technology Officer (former)

Credit: Lenny’s Newsletter (interview with Michael Manapat in May 2023)

First hire a technical product manager

Generally, we recommend that your first PM has a technical orientation, so that they can actively problem-solve with your engineering team. A mid-level IC (five to seven years experience) can work well. This could also be an internal appointment rather than an external hire—for example, a customer-centric early engineer or data analyst. You’re optimizing here for speed of experimentation and execution.

As founder you still need to be deeply involved in bringing your vision to life and setting product priorities and roadmap. This includes doing (at least) weekly product reviews with technical teams, maintaining a quality-bar for what gets shipped and ensuring a focus on the commercial outcomes that you want.

Your first PM critically needs to be someone who can quickly build trust with the co-founder responsible for product and manage arbitrage. If you have a very technical founder, then first hire a PM with enough technical chops to construct and explain their decision-making in terms the founder will be aligned with. But the PM must also be able to challenge the founder.

Gabriel Hubert, Co-Founder, Dust and Product Lead (former), Alan

Given how close you have to stay to product, it’s almost always an error to hire a senior product leader this early. At most, hire a Head of Product with five to eight years of experience who can help to hire and coach a further two or three PMs.

I hired a VP Product when we were 40ish people and delegated the roadmap to them It didn’t work out. We diverged between vision and reality, and between company versus product strategy. After hiring two PMs and two designers, the team fell into an overly comfortable, big company culture, with too much process. I had to dive back in and tear off the Band-Aid, which was tough.

Anonymous Founder

Steadily delegate product leadership to others

The pace at which founders hand over the reins for product decisions depends on your interest and capabilities. Being a technical founder can delay the shift, as you can more accurately consider the trade-offs involved in product decisions, such as new feature releases versus paying down technical debt. If you have specific experience in product management, you’re more likely to be drawn to it and to continue adding value. But for the majority of founders, directly overseeing product becomes more challenging with scale. An increasing proportion of feature requests and priorities will originate from your GTM team—feedback gathered from prospects, customers, user analytics or market research. You will also have a growing team of PMs who need day-to-day supervision and professional development. While your overall vision and strategy remain the North Star, you’ll need to bring in progressively more senior product leadership, and gradually delegate overall control.

Phase One—The first PM(s) manage the interface with Engineering, and ensure on-time delivery per sprint.

Phase Two—The Head (or Director) of Product oversees a small (less than six person) product team, consolidating customer/prospect feedback, market data and competitive analysis for you to jointly review. You still steer the product roadmap and priorities.

Phase Three—An executive-level product leader takes primary ownership of the product roadmap, and jointly agrees product strategy with you.

Phase Four—A CPTO with deep (15+ years) experience at-scale brings product and engineering leadership together, freeing you wholly from being a bottleneck. This is unlikely before your technical team reaches at least 250 headcount, and if you are a technically-oriented CEOfounder, may not be desirable.

There are two step-changes in startups: when the founders are no longer building product personally, and then when they’re no longer directly responsible for product.

Gabriel Hubert, Co-Founder, Dust and Product Lead (former), Alan

It inevitably ends in failure when a CEO has a super fine grained blueprint of what needs to be done. This applies to any area of the business, but it’s most likely to happen in product. With no opportunity to deviate and iterate based on progressive results on the ground, you also never know whether the failure is due to poor strategy or poor execution.

Maria Angelidou-Smith, CPTO, Personio

MOST SENIOR PRODUCT LEADER BY HEADCOUNT STAGE IN SOFTWARE COMPANIES (%) MOST SENIOR PRODUCT LEADER BY HEADCOUNT STAGE IN SOFTWARE COMPANIES (%)

VP Product—by comparison with a Product Director:

  • More comfortable with making decisions in conditions of ambiguity
  • Great communicators and/or great relationship-builders
  • More capable of interacting with sales and marketing teams
  • Builds high levels of trust and respect with rest of the leadership team
  • May have deep specific insight into your market or category

Chief Product Officer—by comparison with a VP Product:

  • Increasingly tied to product marketing competencies
  • Chooses where you play, incorporating signals from GTM team and customers
  • Able to rally the entire company in readiness for shipping new releases, including CX and operations teams
  • Deeply immersed in company financials, to align product decisions with company strategy and constraints
  • Builds relationship of respect and trust with founder across a broad landscape—from architecture, customer segmentation and pricing-for-value through to product suite, product names and internationalization priorities
Two contrarian views:

Datadog—Hiring a Chief Product Officer pre-revenue

Two years into our life, we had running software but we lacked a product and weren’t making substantial progress commercially. So we asked ourselves if a product person could help—and this turned out to be true! Amit joined us in 2012 before we raised our Series A.

We had a good sense of what we wanted our product to do and what it should look like. But we had far less sense of the commercial packaging and pricing. Amit naturally gravitated towards these aspects: What problems are we solving and how much value does this translate into? As engineers by trade, Oliver and myself weren’t very adept with these questions. So we formed a triumvirate, with fuzzy boundaries and complementary strengths. This was uniquely circumstantial to who we each were, and I don’t think you could put it into a formula. But you need to recognize when you have gaps in your approach that could benefit from outside thinking. We were lucky in Amit that we found someone senior and experienced, but who still took a first-principles approach rather than slavishly following shortcuts they’d learnt elsewhere. This was really important to the relationship working so well, as it still is, 11 years on.

Alexis Lê-Quôc, CTO & Co-Founder, Datadog

Remote—Founder acting as CPO at 1,000+ Headcount

Before starting Remote, I had been VP Product at GitLab. In my mind, the company IS the product. So I find it tough to work with product leaders. I expect so much, and care so much about the details, that they can’t replace me. In fact, I’m now directly leading the product team again. Yesterday I reviewed a new feature we released, even giving feedback on the color contrast on a screen. So yes, I’m involved from top to bottom. But I’ve figured that I now have to stand back from the “how” of implementation, while staying very involved in the “what” and the “why”. I give loads of feedback, from MVP right through to PR. Both month-to-month, and quarterto-quarter.

I’ve hired loads of product managers, and in my opinion there are huge differences in quality which are unrelated to compensation.

I’m also very aware of the danger of becoming risk-averse as we grow, and falling victim to the “innovator’s dilemma”. Looking ahead, I want us to continue to take risks, be bold and move quickly. I don’t believe in seeking validation beyond direct customer feedback. Avoid additional deep studies and surveys, which only stall you. The only true proof comes from asking, “Will you use and pay for this?”

At the same time, building via customer feedback alone can lead you into local maxima, versus pursuing a longterm vision which can drive long-term relevance and growth. Founders always need to look beyond what customers are asking for.

Job van der Voort, Co-Founder and CEO

Find product managers who inspire your engineers

The relationship between Engineering and Product is prone to conflict, leading to damaging delays and a loss of trust. What you need is a sweet spot of tension.

There are three major sources of conflict:

  • Product projecting an attitude of, “We’ll set the direction and you’ll follow.” The best engineers will rebel against this, leading to breakdown.
  • Engineering holding strong opinions about the product when they don’t understand the full context or dynamics at play
  • Product lacking the technical proficiency to be true partners in decision-making, so they can’t offer credible counterarguments to Engineering’s skepticism from which creative compromises and solutions can be forged

Fostering a culture of mutual respect starts with a strong relationship between your engineering and product leaders, who role model a recognition of the value brought by the other. They need to demonstrate a joint commitment to seeking out optimal solutions that balance ambition with achievability, and immediate versus longer-term success. If you spot a “blame” dynamic creeping in, you need to intervene immediately to diagnose the root cause, otherwise it will rapidly percolate throughout your entire technical team. Ask yourself: Are you setting sufficiently clear accountabilities and priorities? Can the relationship be put back on track through closer communication? Or does one of them need to go, because they lack the right capability or mindset?

Wise—The Engineering/Product relationship

We fundamentally believe that great companies have builders, who understand not just the “how”, but also the “what” and “why”.

Every engineer we hire has an interview round called the “product round,” where a PM and an engineer ask: “What have you built, how did you measure impact, and why did you build it that way?

The split between Engineering and Product is largely a function of time constraints. So there is a role, and need, for both. But we really push against a culture that says, “Engineering just does delivery.” The PM is the glue, but not the CEO, in a squad. Engineers can effectively fire the PM by just walking away. PMs must inspire.

Harsh Sinha, CTO, Wise

Blend four types of product manager

We can distinguish between four kinds of product manager

  • Project manager—focused on delivery: for example, internal coordination across teams to ensure the effective rollout of new products and features
  • Technical—former engineer who can rapidly translate needs into technical requirements and viability
  • Customer-centric—focused on determining customer needs: asks the right questions, with prior experience potentially in product marketing or management consulting
  • Market-centric—particularly in vertical or complex B2B, it’s essential to have some PMs who bring a deep understanding of your target market and industry structure
Being a great PM is as much about a mentality or mindset as it is about competencies. Do you care deeply about delivering something end to end? Are you willing to do whatever it takes to actually ship product?

Michael Manapat, CPTO (former), Notion

Product hires at Discord

My co-founder and I covered the PM role ourselves mostly until we were about 150 headcount. Our first two PMs were internal hires. It felt too risky to hire externally for the PM role. The first was a data scientist with great product sense. The second was a technical writer for our dev tools, who became our dev-facing PM. We continued this model for a few years—finding people in different roles internally who just came up with terrific ideas, and tapping them up. Our first external product hire was in growth, where our internal capabilities fell short of what was needed from a senior lead.

Jason Citron, CEO & Co-Founder

You should aim to add PMs as your overall technical team scales, aiming for one product manager per technical team. The optimal PM profile will reflect the specific team’s focus: If it’s focused on growth, you want a PM with growth experience; If it’s an infrastructure team, you want a technically-oriented PM.

You need different PMs at different lifecycle stages of a product. The product discovery skill set is very different from product-maintenance. Both are vital, but the same individual is highly unlikely to be good at both.

Thomas Soulez, Chief Product Officer, Silae

Product manager archetypes at Meta and Personio

At Meta I was the functional “guild” lead for product managers at Facebook, and I oversaw the promotion committee. I sponsored the introduction of career paths for PMs. This new model with four archetypes made it clear that PMs could progress through to a VP-equivalent level along any of these “superpower” pathways. This is extremely important, as in the business you need both senior ICs and experienced managers. The former is often much more valuable in a product and technology organization, especially when it comes to advancing complex and ambiguous initiatives. So the incentives system needs to allow for a clear progression along the IC path.

Specialist—experts in a specific domain (e.g. growth, ML, integrity) built up over years. Achieve impact through solving tough problems in their domain, building credibility and influence

Captain—can drive insanely complicated projects, which involve bringing loads of pieces together, beyond simply project management (i. e. can take executive decisions)

Entrepreneur—exceptional at conceiving, building momentum and delivering from zero to one. These individuals really need recognition and protection, as they can find themselves crushed in the corporate “machine” that over-optimizes for short-term gains.

Generalist—These are versatile folks and typically the majority of the product manager population.

Few individuals can be versatile across the archetypes. For example, great Captains tend to be terrible Entrepreneurs, and vice versa.

I’ve introduced a similar framework into Personio too. For example, we now have a Captain for our key markets, empowered end-to-end to identify gaps, set goals, and prioritize team roadmaps. We’ve also just hired someone who has Specialist experience in product growth.

Maria Angelidou-Smith, CPTO, Personio

Design

Decide if design is core or secondary

Users today have much higher expectations (both explicit and implicit) about ease of product use and product delight. Founders are recognizing this and adopting a stronger design-centric approach to both product and brand.

However, be realistic about whether you are truly design-centric, or simply being design-savvy. Not all startups need to be, or can be, design-centric. It largely depends on your founding team DNA, the nature of your product and market, and your source of competitive differentiation. Being design-centric leads to a certain set of decisions (such as building early in-house competency and capacity). If not, it leads to another (such as more agency usage, and a split between internal oversight of design and brand).

I advise founders to think of design more as a verb rather than a noun. It’s a way of operating rather than a function. So it’s less, ‘When should I hire my first designer?’ and more about, ‘Who’s designing right now?’ because someone inevitably will be.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

Most B2B products will not be differentiated on just design. The UI needs to be ‘good enough,’ but more importantly it should be modular, with a design system so you can iterate faster on feedback. If design is a differentiator, then it’s likely more around UX.

Thomas Soulez, Chief Product Officer, Silae

If you have a clear vision as the founder for what the product is going to look like, it’s more a case of bringing this to life, and you can go far without needing to hire a dedicated product designer. You could also work with a freelancer. However, if you’re still in the idea maze, and you don’t have strong design expertise as a founding team, then you should prioritize hiring a product designer to accelerate your iterations and make progress. Just under half (46%) of the startups we researched had a designer by the time they reached headcount of 10, rising to 88% by 50 headcount.

I get anxious if cycles are spent polishing work prematurely because the founders believe that’s where utility is concentrated. Google didn’t need to be beautifully designed on day one or even in year one.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

Hire a designer that can code

Your first design hire must also be able to put on a developer hat. Otherwise they won’t be flexible enough, given the overlap of roles between Engineering and Design. You need to ensure that your technical team is moving swiftly to give form to early product concepts, so that you can rapidly get user feedback, and determine whether it’s serving their needs. The focus of your first designer, or design tasks, is to give functional form to prototypes. Tools such as Figma make this much easier nowadays. Critically, designers can’t be touchy about feedback, and should be willing to create and refine continuously.

The first designer we hired [at a previous company that Simon co-founded] shared her ideas before they were ready. It was brave, and it was a revelation. It unlocked a dynamic and collaborative technical environment to have visuals that everyone could group around and discuss. Visuals are just so much more powerful than words.

Simon Lambert, CTO, Birdie

It’s a red flag for a startup if a designer is sensitive about sharing their work.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

When hiring designers, prior in-house startup experience is preferable, but too tight a filter. You should also look at agencies and at larger in-house teams, favoring candidates based on their bias for action and comfort with ambiguity. A designer coming from a late-stage company may not cope with the ambiguity, so you really need to assess this. Conversely, an agency designer, or even a fresh design graduate, could be a promising route. They’re by definition very raw, which could serve you well, and for this reason they’re a common hiring profile we see in startups.

I find hiring straight out of college can be great for designers. You’re looking for raw talent, with evidence of doing projects on their own initiative or for free, and just to gain the proficiency and experience. Curious and self-directed learners thrive in high-growth startups.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

Note that if you’re a D2C E-commerce startup, your first designer is more likely to skew to brand design rather than product design by background, since the early design tasks will be more focused on marketing and packaging elements than on software.

Pre-launch, I worked with a freelance creative to develop our logo and our packaging. Post-launch, one of my first hires was an in-house, well-rounded senior graphic designer. We had daily deadlines for creating community emails, blogs, and social posts, and we needed visuals and videos to accompany them. If you’re selling a visual product and need to generate desire on a daily basis, it’s hard to outsource that to an agency.

Marcia Kilgore, Founder, Beauty Pie

As you scale, think about other branches of design

By the time you reach 50 headcount, you’re likely to have hired a second or third designer. One of these might be a brand designer rather than a product designer, focusing their efforts more on marketing and brand collateral, and without a technical background or ability to code. If you’re a D2C business, this balance is more likely to be inverted, with two brand designers and one product designer.

Your product designers at this stage will report into either a Head of Product, or to your overall technical leader (CTO or CPO). Brand designers are more likely to be oriented towards your marketing team and lead, although it largely depends on the specific managers that you have, and the balance of work that the designer is doing.

Design effort at this stage will be a mix of supporting new product development and features, together with revisiting design work on product that you’ve already released (color palette, tone-of-voice on copy, logo representations), to ensure consistency and to improve finesse.

Your UI doesn’t need to be polished to demonstrate initial value. But once you have solid signs of PMF and enter a formal launch or growth stage, then you need to add some cycles on UI polish. Otherwise it’s like going to a new restaurant and finding that you have been given mismatching cutlery and no napkin. It’s not the primary reason to go to a restaurant, but you will notice and it will erode credibility and the overall experience.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

Hire more design generalists

As you scale further, the majority of designers that you hire should be generalists able to take on a range of roles and projects. Your strong preference should still be hiring designers who can code, to give you more flexibility between design and engineering aspects of building.

In the early stages, you are likely to accumulate ‘design debt’. You’re shipping product quickly, which isn’t entirely consistent in terms of overall design. As you scale, you want to smooth out these rough edges and offer a more cohesive user experience. This ‘design refactoring’ will put additional strain on your design team as they’re simultaneously trying to ship new features.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

Keep designers engaged

The conventional ideal is to have one designer dedicated to each of your product-oriented technical teams. However, this isn’t necessarily optimal. For a start, finding excellent product designers is tough. Furthermore, designers by nature are particularly hungry for variety, so tying them too closely to a particular team or problem runs the risk of losing them. This is one reason why agency roles can be so appealing to designers.

Here’s our advice for how to keep your designers motivated:

  • Regularly rotate designers between teams to keep them engaged and learning.
  • Develop a studio model for designers, allocating resources to teams and projects as required.
  • Separate product design from brand design, with the latter grouped under the marketing function.
  • Build better design libraries, training your engineers to use them in order to reduce the need to directly involve designers in every task.
It’s hard to ensure one-to-one mappings of PM and designer per team. PM's are a dime a dozen compared to excellent product designers. A studio model for product design can work better. You also build expertise and craft by pairing senior designers with junior ones.

Gabriel Hubert, Co-Founder, Dust and Product Lead (former), Alan

Ideally, you’d have a rich UI framework developed by your designers, including style guides and components, which can then be assembled by a UX-tilting product manager to minimize demands on design time. But this involves a lot of upfront investment, which is a rare luxury in highgrowth startups.

Thomas Soulez, Chief Product Officer, Silae

Later, look for specialists

With scale, you’ll also likely hire some specialists into your design team, with distinctive and non-overlapping skill sets, such as copywriting and illustration.

Illustrations were a key part of our design approach at Dropbox early on. We had a single individual on the design team who created them all. We needed to explain computing abstractions like files and cloud storage and security to potential users. Illustrations just worked way better than words to convey key concepts. For example, showing a person’s computer on fire but with their files safe inside Dropbox explained in a single visual what the product offered. A picture really is worth a thousand words.

Soleio, Designer × Investor, Figma Advisor and former Dropbox and Meta

Eventually you’ll have multiple needs around brand and graphic design, alongside product design: designing your website, marketing materials, recruiting events, sales collateral, TV ads, etc. These projects rarely fit into the technical team model, and some of the best brand and graphic designers are also specialists in these fields, rather than coming from a coding background.

Additional sub-disciplines of design activity will emerge as you scale, for example:

  • Growth and conversion-focused design
  • User research
  • Competitor research

These activities, together with brand design and design libraries, aren’t typically owned by distinct individuals. Rather, they can fit into the studio and rotation models discussed above. This also provides career development pathways for your designers, keeping them stimulated and supporting retention.

Understand how your business model affects your design needs

The balance of needs between product and brand design varies considerably between business models. Pure software business models have a balance of 2:1 or even 3:1 in favor of product designers. Marketplaces are closer to 1:1, while D2C will typically need more brand designers.

We split our design team in two: Assets inside the app come from our product studio, while marketing assets come from our growth studio. We ensure consistency but not 100% alignment. Product needs to be unified, but growth needs some wiggle room to appeal to different audiences and for different purposes.

Antoine Le Nel, VP Growth, Revolut

DESIGN TEAM SIZE BY TOTAL HEADCOUNT AND BUSINESS MODEL DESIGN TEAM SIZE BY TOTAL HEADCOUNT AND BUSINESS MODEL

Do you need a design executive?

A talented IC designer can have exceptional impact, so as with Engineering, you will need to offer a clear IC track offering career development outside of people management routes.

Within a studio model, you can encourage a mentoring path so that you develop the skills of your more junior designers. Great mentors also tend to make great managers, which is particularly important in design, as it’s unusual that creative people aspire to be people managers.

It’s great to cultivate ‘mentoring’ designers, since so many designers are anti-management, and want to remain individual contributors.

Gabriel Hubert, Co-Founder, Dust and Product Lead (former), Alan

MOST SENIOR DESIGN LEADER BY HEADCOUNT STAGE (%) MOST SENIOR DESIGN LEADER BY HEADCOUNT STAGE (%)

Only a minority of startups pre-IPO hire a design executive. Directors represent the most common level of design leadership. They generally report into the VP Product or CPO. In this setup, marketing executives (CMO or VP Marketing) are typically responsible for brand leadership. This creates a dilemma for unifying brand design and product design. The answer really depends on how fundamental design is to the company’s identity and competitive strategy. If it is, then hiring a design executive, with unified oversight including brand, could make sense. Either way, you need to foster a joined-up approach to design.

Unifying design and brand at Squarespace

For us, everything is brand. Every touchpoint tells a story about the company. Siloed thinking leads to a Frankenstein brand and organization, so my team are the brand guardians.

In design, your startup’s product and creative output is your strongest recruiting pitch. Design-centric startups such as Squarespace can offer designers 20 × greater creative satisfaction than roles at Big Tech companies. We offer impact rather than bricklaying.

Until recently, we had the same designers working across product and brand/ marketing elements. I looked for malleable individuals, who were both creatively and technically gifted. They enjoyed working across a broad range of areas, including media creative. We even created our Super Bowl ads entirely in-house. This has really helped with career development and retention too.

David Lee, Chief Creative Officer

Analytics

Analytics encompasses two areas that have previously been fairly distinct in terms of technical skills and therefore talent pools: data science (DS) and business information (BI). This is changing as low-code and no-code analytics tools are more widely adopted, offering some DS superpowers to more traditional, spreadsheetoriented BI analysts. The distinctions are blurring, and job titles with “data scientist” are becoming more widespread.

Be clear about what you need in an analytics role to make sure there’s a match between candidates’ technical skills and expectations. For many analytics roles, “premium” DS skills—such as real-time predictive models, machine learning and data pipeline management—are not necessary. Building growth models and company-level metrics dashboards, say, would benefit more from deeper marketing and financial knowledge. In early-stage companies, these important deliverables are often part of the remit of a Chief of Staff or BizOps analyst.

However, in pure software companies (SaaS or B2C Apps) the need to organize, analyze and interpret product data is more pressing, and you’re likely to hire a dedicated data scientist in your technical team by 50 headcount.

With growth, further analytics hires become necessary. True data scientists will almost all be embedded within technical teams, often dedicated to squads. They will work closely with Engineering to create a company-wide data warehouse, a “single source or truth” that pools and integrates data across different systems and functions.

The pressure to hire data analysts will also pop up across multiple functions: Marketing, Finance, Operations, Sales, CX, and People/Recruiting. Analytics is perhaps the function where the tension between centralization and localization is sharpest.

So long as you have clear responsibility and capacity for managing the data warehouse, including integrations with other systems and monitoring data quality, then hiring dedicated and embedded BI analysts into separate functions should allow you to scale effectively. The worst scenario is a fully centralized analytics team operating on a “ticketing” model. This will inevitably lead to frustrations and tensions.

At some point, you will need to bring in more senior leadership to oversee analytics across the business. The pressure to do so may come from “orphaned” data analysts who are deprived of learning or career progression opportunities, and who are therefore hard to retain. Or it might arise from the need to consolidate around one or two preferred and consistent data visualization tools and templates. Only a minority (29%) of pre-IPO scale companies hire an executive-level (VP+) Analytics leader, but half (49%) have already hired a Head or Director of Analytics by the time they reach 250 headcount. This individual can potentially report into either a COO or a financial, product, or engineering executive. In pure software companies, Analytics is more likely to skew towards data science and report into technical leadership. But more than anything, the decision usually reflects who’s the biggest data nerd at exec-level, and who’s keenest to take it on and drive it forwards.

ANALYTICS TEAM BALANCE BETWEEN DS AND BI BY BUSINESS MODEL AND HEADCOUNT STAGE ANALYTICS TEAM BALANCE BETWEEN DS AND BI BY BUSINESS MODEL AND HEADCOUNT STAGE

Pathless paths

As you navigate your city, town or village by foot, you’re likely walking in the shadows of long-dead urban planners, who once pored over maps and charts to plot out streets and footpaths. Yet humans are unruly beings, known to deviate from prescribed routes and blaze impulsive trails of their own. Unofficial shortcuts known as “desire paths” will spring up wherever there is foot traffic—think of the dirt track criss-crossing a park in defiance of a meandering pavement, a secret route through a tangled wood, or the worn cobbles of a back-alley bypass. These lines are chronicles of walkers’ urges and yearnings, both to get from A to B as quickly as they can, but also to stray beyond the bounds of the known.

Confronted with this record of pedestrian disobedience, eager bureaucrats can respond with fences, walls and other tools of deterrence for the wayward. But the more enlightened might choose to listen to the streetscape.

In Finland, some planners wait for snow so they can chart walkways based on where people choose to tread. In London, the architect Riccardo Marini used trails of cigarette butts and bubble gum deposits to figure out where to place rubbish bins along Regent Street. And administrators at Ohio State University in the early 20th century paved the asymmetrical desire paths that students’ feet had cut into the main oval, the center of student life on campus.

Desire paths may look like acts of rebellion, thwarting perfection and structure. But if they are embraced, they showcase how order can emerge organically when we decide to channel the maverick impulses of the many.

Stories of Chaos

Scaling your GTM team
9
Scaling your GTM team
9