Once a startup grabs that multi-million investment, the CTO’s role flips 180°. As the expanded management tightens deadlines and requirements, developing a well-functioning product gets overshadowed by an avalanche of responsibilities. To prepare you for the wake-up call, I asked recognized technology leaders how CTOs can navigate their work in the scale-up phase.
When does a startup become a scale-up?
There’s no consensus in my circles when the transition happens, yet you can ask the CEO to keep you posted about planned fundraising talks.
Still, because the founding board might go through dozens of unsuccessful talks, I believe the leap from startup to scale-up can happen abruptly overnight.
From my experience, It’s around the time the management expects the product to earn real money.
Previously, the product development budget was abundant. That’s because early-stage financiers are ready to lose their money. Now after a new seed, the same people come in and expect to earn more than they spend.
Once that happens, the management suddenly expects the product to be super-scalable, super-safe, and super-fast, even though it wasn’t required in the past 2 years.
But the CTO won’t have the space to keep developers in check because someone has to figure out the cash flow investors now care about.
So you’ll recognize the leap from a startup to a scale-up when your responsibilities will center on technology strategy instead of development.
The biggest challenges scale-up CTOs face
A business-level change transforms the operations of the entire IT department. With one client of ours, we started work in an early growth stage, with flexible deadlines, moving around priorities to experiment with features.
Once a Seed B investor crashed the party, deadlines became as solid as a brick, and the management started peeking over our shoulders.
“Show me your security policy”
As the company was about to get sold, lawyers entered the stage to review our technology for compliance. If the CEO prepares to quote for the company, there will have to be a security audit for 100%.
The CTO witnessed a 180° shift from software development towards security work that none of the executives examined much before. To catalog security procedures in full, we spent months racing against the clock.
It’s best to register them step by step before a request for a mandatory audit comes in.
Maintaining code ownership
Copyright law becomes a hot button issue in a scale-up. In westernized countries, whoever writes the code is its proprietary owner. The company that the programmer works for might not sell or release software including that code without a documented transfer of ownership.
Now imagine there are no such papers for your system and some of the core developers already left the company.
When programmers tap out the code on a deadline, the copyright doesn’t bother them. That can put you as the CTO in a place where you need mass refactoring to verify what you own.
Remember “The Social Network” movie?” Facebook lost $20M after a year-long court battle over the use of ConnectU.com’s source code Zuckerberg obtained and adapted without the ownership.
Transferring the know-how back in
Outsourced developers are an essential part of many scale-ups, as their contribution can get the development unstuck.
Throughout The Software House’s history, I worked with companies that turned to outsourcing to combat three main problems in development: employee onboarding costs; the lack of some know-how like cloud engineering; and project delivery deadlines.
Some partnerships lasted a couple of months, but most span even beyond five years.
There’s a flip side to working with a software development partner. If the CTO relies on knowledge held by external developers, the company becomes impossible to sell.
Investors are fishing for a complete package that will be in their full control after an acquisition. To have an outside partner as an uncontrollable asset is unacceptable.
From my experience, the sales process for a technology product takes at least 2 years.
Knowing that a well-operated startup gets acquired in 6-10 years, the CTO must plan a cut-off point ahead of time to make their team self-sufficient again.
Q: What are the top 3 traps that CTOs should avoid in a scaleup organization?
Stop doing technical work yourself. CTOs are essential, direct contributors and often do a lot of coding themselves. If you get caught doing too much technical work, you will end up in a situation where you don’t have time for hiring and leadership. Budget one-third of your time devoted to hiring and the rest to leadership and management.
Avoid developing all software in-house. Too often CTOs like to hire a team competent in all aspects of their software stack. Hire engineers with core skills aligned with your strategic technologies. Look at other technologies (web or backend) that are not as business-critical and outsource those to allow more focus on the core.
Lastly, don’t assume you have a product-market fit. Engineering is all about the details, and you may be missing complete proof that your product fits the biggest use cases. Sit in on marketing calls, go through the requirements list, and confirm the fit for yourself.
Setting priorities for the IT department
Tech leaders in a scale-up must face a sudden outburst of requests that can cloud their sense of priority. At a point, you’ll see many responsibilities must be turned down. You might have heard of the MoSCoW prioritization method.
90% of clients I know describe all their wishes as a must-have, and it’s physically impossible to cover everything. Expect that you’ll have to defend your decision about the next step before the management. They might not believe that the team is lacking space.
Q: Which department operations a scale-up CTO should prioritize?
The department that CTOs need to focus on most heavily in this age of cloud-first development is clearly DevOps.
What I mean by DevOps (as, like other ‘newer’ terms, it has different meanings to different people) is a true full-stack capability that handles development from the provisioning of infrastructure through coding, testing, and continuous integration/delivery.
This type of capability needs to be tightly aligned with the security structure of your firm, though the modern Chief Information Security Officer (CISO) should be a partner to DevOps and not a blocker.
A fully agile DevOps organization removes wait time between ideas and solutions, it empowers employees to grow their skill sets and think critically about their choices throughout the solution architecture, and it unlocks the true benefits of your cloud platforms.
Developing the product in line with business goals
After the first seed, the founder and their employees enjoy a honeymoon period where the product is king. The mentality is that whatever they’re building must become a bestseller before the business grows its roots.
In that phase, coding practices matter, the team happily adapts new solutions, and design work shines through. Developers are so immersed in the experience of working with technology that it’s uncommon to discuss how the product will earn money.
It’s rare to hear about a startup with a commercial strategy. But once that big investor knocks on the door… the CTO catches a loaded document titled “We really need to earn paper now”.
Eventually, you have to learn how to handle finances, so secure time to do that with care.
Q: How can a CTO align product goals with a scale-up’s commercial strategy?
Everybody needs to have a good understanding of where the company is heading and which goals should be reached.
Make sure that these goals are up-to-date, transparent, and visible to everybody at any time. A goal-setting framework like OKRs could help you with that, but in the end, it’s all about communication and transparency.
Having the general direction set, let your teams create a product vision that matches and supports the company’s goals and establish metrics to measure the success of the team’s efforts.
This way each autonomous product development team has a clear direction given and can constantly measure and control if they are on track.
By sharing the product vision and the development roadmap with the company and by establishing an open-feedback culture, you make sure that everything stays aligned.
Outsourcing department work to a software development partner
You will have to outsource, period. There comes a time when the product needs several new developers because some of the key players quit in their dislike of the scale-up work tempo. Among them, you’ll find the proactive leaders and seniors who just don’t feel right in a more corporate setting.
The money for recruitment might be even there, but often, the HR department can’t source people so fast. There’s a need to buy… time.
Scale-up CTOs decide to outsource mainly because they need to avoid the time-drain caused by 1:1 onboarding. A software development partner, however, gets onboarded once, and the trouble of sharing the know-how is on them.
Q: When is it wise for a scale-up leader to outsource development?
Scale-up leaders should be clear about their objectives for outsourcing.
Traditionally, the main objective is to improve development efficiency, especially by tapping into cheaper labor markets.
Cost gains have been possible, but mostly for standardized services like internal IT. For individual and specific services, like developing a customized software platform, that is less the case.
Access to top-level expertise is another objective. For example, building teams to leverage specific AI methods can be hard and expensive. Tapping into specialized companies to outsource the development of a specific service often works well.
Work speed and short-term access to talent are probably the two primary drivers for scale-up outsourcing.
Take the example of Alibaba. Because of the scarcity of talented developers in China, they outsourced the development of the entire international website to a US-based agency to enter the market faster.
Knowing which operations contribute to the company’s scalability
When you hear the CEO say “scale-up” for the first time, be sure to ask what does scalability mean to stakeholders, even if you know. Actually, ask everyone in the company how they define scaling. The variety of answers will surprise you.
Does the board expect to reach thousands of new users? Are you pushing the product into new countries? Or is it that now you need multi-level customer service?
I wouldn’t hold back from creating a formal definition of scalability that decision-makers must agree on.
Not only do you need to grasp which business area you scale, but you also need an agreement on what the company won’t scale for now.
Q: What are the top 3 focus areas that contribute to a scale-up’s product scalability?
One — managed cloud services. Modern cloud platforms offer a plethora of such: databases, storage, serverless functions, content distribution networks, etc.
These services can be considered expensive at first glance, but it’s all about opportunity cost. In a scale-up company, investing in managed solutions whenever possible will free up valuable bandwidth in your engineering team.
Then, there’s observability. Invest in monitoring solutions and integrate them in your systems and services by design. This is a high-return investment that will allow you to foster a data-driven culture in your team and prevent unexpected surprises.
Last but not least, people. Yes, people. Technology is all about the people who build it! Invest in talent acquisition, retention, and engagement. This is the best recipe for success.
Discussions with fellow leaders will fill you in
There’s no one school to prepare you for a scale-up leadership role. What happens at a growth-oriented company might be predictable, but to develop your strategic intuition, you need to hear of the personal experiences of CTOs who are senior to you.
If you’re trapped in Slack like the rest of us, you might as well join one of these mastermind groups. The links below let you see the channels for each entry.
- CTO Craft (1324 members)
- The Ops Community (803 members)
- Product School (30935 members)
- IT Pro Community (810 members)