Scaling from pre- to post-Product/Market Fit, Part 3: Scaling your technical teams

How fast?

How much and how quickly should you scale your technical teams? In general, we recommend that you grow your teams in line with your business needs and not with your revenue. You’ll want to avoid over-hiring but also not hamper your growth by being too conservative. For instance, if you’re in a very competitive and fast-moving market (such as many AI-based companies found themselves in 2023-24) then you may want to hire somewhat ahead of revenue and balance that with the risk of shortening your runway.

In our experience, it’s best to keep technical teams just slightly understaffed. This encourages focus on the top priorities. Oftentimes, doing the right things is more important than doing too many things.

For a successful post-PMF transition, you should start with growing people internally, by nurturing the people who will add value at this new stage. In particular, great leads and managers are much more difficult to hire externally than to grow internally. For this reason, you need to think about putting in place an internal “manager factory”.

As an example, at Criteo, out of about 100 dev leads in 2019, more than 90% had been “grown” internally, meaning they had transitioned to this new role from an individual contributor position. We found that this was easier to do at scale, and produced better results than trying to hire dev leads externally.

Scaling recruiting

Post-PMF, you will have to scale recruiting. If you’re a CEO, CTO or CPO reading this, don’t think this is just “the job of the recruiting function”! It’s an important part of your job as well. You will need to invest significant amounts of effort and time, and build a very close partnership with recruiting.

You should hire for the company of tomorrow by bringing in external talent that raises the bar. Remember Steve Jobs’ saying “A players attract A players. B players attract C players.” It’s better to avoid the latter since it’s very difficult to recover from that downward spiral, which can go all the way to “Z”.

Invest in your recruiting capabilities early and for the long run. If you’re considering whether to do in-house or external recruiting, we’d strongly advise in-house. In our experience, external recruiting rarely works well for hiring top-notch technical teams; it does work however for hiring execs and very senior managers.

Internal recruiters are part of the team and are as committed as the rest of the company; they’re best placed for selling the company’s vision to candidates. You may thus want to gradually build up an in-house team of highly dedicated and effective recruiters.

Keep in mind that you can’t scale recruiting overnight, and that a good recruiter will only be able to help you close between 2 to 4 “A” technical candidates per month. This is something you should anticipate when you plan hiring. E.g. If you need to hire 50 engineers over the next 12 months and you don’t yet have the recruiters, then you’ll need to factor in the time it takes to recruit the recruiters as well as their notice periods and ramp-up times. “50 engineers in 12 months” can easily become “50 engineers in 3 months” if you take their notice periods into account as well (here we’re assuming 2-3 month notice periods typical in the EU).

Some of your very best hires will likely come from referrals. Put in place a bonus program for successful referrals. The rest of your hires will mostly come from sourcing. Few (good) candidates will come through job ads, job fairs etc. at this stage. We’d recommend not bothering too much with those, as well as with employer branding, until you’re a well-known company. You can have a bigger impact by focusing on candidate experience during the interview process instead.

In a post-PMF company, you may significantly increase your pace of hiring and will have to deal with the volume while keeping the bar high.

A typical ratio for candidates is around 100:10:1 for sourced vs. in-process vs. offered (your mileage may vary, and more mature companies may see an even bigger ratio). Thus if you plan to hire 10 engineers, you’ll probably need to source 1000 potential candidates! Everyone should pitch in for sourcing; remember that engineers and PMs can be very good sourcers without having to invest inordinate amounts of time.

Sourcing is the best place where you can start injecting more gender, cultural, and ethnic diversity. Focused sourcing for diverse candidates helps a lot! At one of our previous companies, we used to regularly run focused diversity sourcing sessions with the Engineering and Product teams.

Since hiring is a numbers game, you and your teams need to be prepared to do a lot of interviews. Putting in place an interview process includes:

• Training interviewers to ensure assessments are done uniformly.
• Being very clear about what areas you want to probe.
• Splitting the areas among multiple interviews. For instance, a process for backend engineers could consist of a phone screen, 2 coding, one system design and one cultural fit interview.
• Making sure interviewers are aligned on what they need to cover and are calibrated in the way they score candidates.
• Defining what the minimum bar is for each stage and when to terminate loops.
• Having a clear and effective way of making hire/no-hire decisions.

Management layers and org structure

In most cases, it makes most sense to grow your team in a bottom-up manner: you hire the individual contributors initially (pre-PMF and continuing into post-PMF). Then you put in place dev leads (for Engineering) or Product leads (for Product). Typically, team sizes should be 4-8 reports for a lead. Once you have more than 4-6 teams, you can put in place a manager who will have 4-8 leads reporting to them.

As a general rule, you should keep management as hands-on and as flat as possible.

“Pure managers” don’t fit well in a tech company. When you start putting in place dev leads managers who don’t code themselves, they should still be deeply technical and able to dive into the technical aspects.

Should you experiment with non-hierarchical org structures? Our view is that your time and energy are better spent focusing on the customer. We suggest keeping the org classical but making sure you have the flexibility to deal with unexpected situations (such new projects, team choke points, etc.).

As a famous 20th century physicist used to say: “In theory, theory and practice are the same. In practice, they are not.” Various companies have tried approaches like Scaling Agile @ Spotify or LeSS. These are great… in theory, but unfortunately rarely work as advertised in practice (including at Spotify itself!) and are not the panacea they’re claimed to be.

Performance management

Effective performance management is essential for fostering a high-performance culture. This includes not only recognising and developing top talent but also addressing underperformance to maintain team efficiency and morale.

If you haven’t done this yet, this is the time to put in place a Career Development Framework (CDF) to formalise the various disciplines and tracks (e.g. software engineer individual contributor, dev lead, engineering manager, Product manager etc.). The CDF will spell out the expectations that you have for your people, as a function of their level.

You need to put in place a culture of continuous feedback, i.e. managers should provide feedback to their reports without waiting for the formal performance review cycle.

You can do annual or bi-annual performance reviews (we feel that quarterly may be a little bit too aggressive and time-consuming). We recommend a scoring process where direct managers are one of multiple inputs, with final performance scores being decided by a committee of senior peers and managers. It’s important to calibrate the process as much as possible for coherence across teams and disciplines.

You should refrain from imposing a forced distribution of scores. Companies that have tried this have had poor experiences and have seen an increase in internal politics as the competition for scarce resources (the top grades) intensifies.

Remove friction

As you grow your technical teams, you should remember to constantly remove friction which has a tendency of building up as your company scales. Some of the things you can try to achieve this include:

• Limiting the meetings overhead. If you’re not careful, more people tend to generate more meetings with more participants in them. Slash any useless meetings (litmus test: “this meeting could have been an email”) and make sure attendance is kept to the minimum useful one.
• Favouring offline over online: prefer documents over slides, pre-reads over presentations. As companies grow, many fall into the trap of a “presentation culture”: watch for meetings where 90% of the time is spent presenting and only 10% discussing. This is not an effective use of participants’ time and should be replaced as much as possible by pre-reads and spending the time in meetings actually discussing; it can also help having shorter meetings.
• Avoiding the “Slack immediacy syndrome”: except for production incidents, there is little point in people responding to Slack messages in seconds or even minutes. Each message creates an interruption that reduces focus and increases stress.
• Using the right tools for the job. E.g. bugs or tickets should be filed in Jira, not in Slack. This will allow you to maintain oversight, and build dashboard and reports as needed.

Differentiate roles and responsibilities

Growing technical teams also means that you need to start differentiating roles and responsibilities. For instance, at this point you may need to start building whole teams that focus on things like DevOps, MLOps, security (which could be part of DevOps initially), design etc.

As part of differentiation, once your tech team reaches 40-50 people, you may want to start investing in planning and coordination capabilities by building a Technical Program Manager (TPM) team. The TPMs’ role is to do “anything except coding” to make stuff happen - which means mostly coordinating between various teams and making sure that dependencies and risks are properly managed. The need for TPMs grows with the size of your organisation: for larger orgs, a ratio of 1 TPM to 20-30 engineers can be a good target.

While differentiation is needed to achieve focus and depth, one ought to create as much differentiation as needed but not more. For instance, we’re sceptical of some types of roles that in our view don’t really require differentiation. E.g. Agile coaches or Quality Assurance (QA) can and should be covered by engineers in most settings.

Standardise

Standardisation in organisational processes and ways of working is important for scaling your company effectively. By establishing repeatable and consistent processes you can avoid the inefficiencies that come from constantly "reinventing the wheel." This approach not only saves time but also ensures a predictable level of quality across the board.

• Process standardisation: implementing standardised processes across teams ensures that everyone is on the same page, reducing miscommunication and errors. This uniformity in how some tasks are approached and executed allows for smoother operations and easier onboarding of new team members.
• Testing and product quality: you can set clear quality benchmarks that all teams are expected to meet. This consistency in quality helps in building trust with customers and stakeholders, as they come to expect a certain standard from your products and services.
• Efficient hiring: as mentioned earlier, standardising the interview process ensures fair and objective candidate assessments, streamlines hiring for efficiency, and maintains high-quality hires by applying consistent criteria. This approach reduces biases and accelerates decision-making, guaranteeing that new talent aligns with company standards and culture.

As with many other aspects, you need to apply common sense concerning what should be standardised: as much as needed, but not more.

In Part 4 and 5 [coming soon] we will dive into the specifics of scaling Product and Engineering teams, respectively.