How to partner with a scaleup

A scaleup’s challenges and needs are unique, both culturally and execution-wise, unlike a startup or an established enterprise.

Over the last few months, Thoughtworks has engaged with several scaleups, such as Sigfig, Greyscale, Apollo.io, Craft.co and Clipboard Health. 

We have curated our biggest lessons from these relationships for account managers, client liaisons and delivery teams. Before we begin, we recommend you read Martin Fowler’s article on scaleups. (A scaleup is a business working on expanding/experiencing exponential growth).

#1 It’s a sprint first and then a marathon

A scaleup is at an accelerated pace, already having significant momentum and raring to keep going. As a corollary, they are quick to judge and demand instant results. So, we ( consulting or engineering partner) need to be quick enough to show progress and value within a short period while being careful not to compromise our position. 

It is even more critical when the Chief Technological Officer (CTO) or the sponsor directly reporting to the CTO recommends us for the engagement. We must ensure they don’t feel undue pressure to justify the partnership to the board.

#2 Codebase is dear; change needs sensitivity

Contrary to what we may assume, scaleups, who have seen adoption for their product, are unlikely to be open to substantial architectural changes. Often, the CTO might have personally written a significant part of the codebase, and any mention of bottlenecks could be perceived as a direct challenge to their competence. 

So, any gaps, bottlenecks or incompetencies need to be addressed with the utmost sensitivity. For example, at one of our client engagements, we presented limitations  as ‘themes for scaling/sustaining productivity.’ This was received more eagerly.

#3 Budgets are counted in salaries

At scaleups, budgeting is often done as a multiple of team members' salaries. In one of our client engagements, the engineering leader directly equated the ‘salary,’ i.e., Thoughtworks rate card, to the compensation paid to his employee and questioned our value. This is a hard-wired behavior amplified by the system. 

So we must watch for the comparisons early on. It helps to establish value above and beyond the head count. If a discount is inevitable, it is best to stay at least 20% close to their senior engineer payscale. 

#4 Engineering culture may not be prevalent

While scaleups understand modern engineering practices, they might not practice them holistically. Not just code debt but the superficial practice of agile/XP processes is also more common-than-expected. However, while these practices lack depth, they are often good breadth-wise (e.g., frameworks). Understanding this is useful when making proposals that need multiple options.

#5 Even advisory needs to be hands-on

Scaleups want to cut to the chase fast. While they do appreciate advisory — concepts, systems etc. — they are more interested in the execution of solutions, which help them move more quickly towards next quarter’s deliverables. So, while bringing in advisory, be sure that the person spends more time on hands-on work. 

#6 The double-edged sword of working closely with directors

Depending on the size of the scaleups, partners might work directly with engineering directors regularly. This is a double-edged sword. On the one hand, it gives an excellent opportunity to influence the stakeholder. On the other hand, it runs the risk of reducing your organization to the individuals that the director closely works with. When a judgment is made on one individual, it can reflect entirely on the organization. This is always a bad thing, irrespective of the nature of the judgment.

#7 Sometimes, we build for the investors

Funding plays a disproportionate role in shaping scaleups. They may build products that are  ‘feature-heavy’ to attract investment, get short-term users and/or prepare for an  IPO. If there is no new funding in the past six months, budget cuts are likely in the immediate quarter. So, as an engineering partner, it’s essential to watch out for funding news, the strength of such investments and the promises made while receiving them.

#8 High volatility on capacity and visibility

At scaleups, not just their product but even their engagement would pivot very fast. Visibility is usually not beyond the next quarter. The roadmap is highly revenue-driven. Priorities can change overnight. What was defined in the scope of work would be outdated even by the time staffing is complete. Extreme swings in the capacity are to be expected, be it rapid increase or requests to off-board people. What’s worse is that these requests come on short notice. A good engineering partner must be able to expect and adapt to these changes.

#10 Multiple versions of the same product

Products that are light at the beginning become rigid as they scale. Without the ability to accommodate all of the end-user's requirements, scaleups end up with multiple versions of the same product. Engineering partners must understand this and encourage product modernization every 2-3 years. All these are great opportunities to assess and remediate issues regularly.

#11 Team composition and cross-functional roles

Given the nature of scaleups, onboarding a full team of specialists would be challenging. Therefore, the ideal team would have a handful of cross-functional people covering various skills. For instance, we once had the product owner writing stories  while  developers covered for quality analysts. Engineering partners must be flexible enough to make this work.

#12 Async is the norm

Scaleups also tend to have globally distributed teams. Activities are performed asynchronously. Standups are conducted on Slack. Developers are expected to read the stories and seek answers in quick huddles. This needs engineering partners to think of new ways to facilitate brainstorming or collaboration.

From experience, we’ve learned that scaleups are a rare combination of aspirations (of engineering excellence and growth) and limitations (of investor demands and process adherence). There is no right or wrong way, but only a unique way an organization of a scaleup’s maturity functions. Engineering organizations that partner with scaleups need to be technically and culturally prepared to adapt to this way of working.