The insider secrets of moving from start-up to scale-up
Reflecting on my experience working at multiple high-growth startups, here are my top 8 areas which I believe are most important when thinking about how to scale your tech from start-up to scale-up successfully.
1. Monitoring
When you start building a new piece of technology to scale fast, you can’t help but build things manually. It’s natural to feel like you need to build and ship things fast that works. However, sadly this often spirals into what leads to the common issue high-growth starts up experience, hiring too quickly to compensate weak tech in need of constant maintenance and patching as the business grows.
Avoid panic hiring with no strategy and let your team allocate time to curating your secret sauce for high growth success, exceptional monitoring.
I highly recommend introducing a monitoring tool early on in the development stage. At SAPI, we use datadog, which is blazing fast to get up and running. Having monitoring setup before building the product helps to identify and triage any issues in the system using evidence and real data, rather than guessing by human opinion on where could be improved.
A good monitoring tool should be able to process every log line and deliver actionable insights and weaknesses for the team to prioritise. Doing this early will pay off in the long run and ensure scaling 1 client to 100s isn’t an uphill struggle.
2. Automation
At the very start, it is inevitable that to go to market in a timely manner you find yourself building a product manually, which is fine, especially in your first SDLC (software development life cycle) iteration. However, the secret here is being okay with refactoring code with automation in mind.
At SAPI, we automate where possible as a principle. If like us you work in the realm of regulatory bodies, you can use automation as an example of how you minimise risk to your consumers.
Currently, at SAPI the product collects necessary data from the applicant and calculates a loan offer decision. This is an automated process which produces a credit limit based on data submitted. We also use machine learning algorithms to analyse data from similar companies and their historic behaviour to create our very own risk assessment analysis on the applicant.
For our proof of concept, we used a manual process which has now evolved. Automation also helps de-risk your business model from a regulatory perspective and ensures you are capable of delivering a product faster than competitors.
Lastly, having more automated processes saves the team valuable time.
3. Security
Every partner your business interacts with will need to know why they can trust you, which means managing security throughout startup to scaleup is crucial. Any new investor or partnership will check security during their due-diligence.
I have seen gaining ISO accreditations speed up onboarding with large partners which may be more risk-averse such as banks. Find an ISO accreditation relevant to your industry or begin by simply meeting the general Information Security 97001 standards and see how you can attract larger clients sooner rather than later.
It may feel unnecessary to meet every security standard in the early stages of a company, but ensuring you set security standards in line with your size and continually review as you scale will help keep out bad habits in your team.
4. Up-Time
A big measure of any tech company is their availability SLA, you may have heard of this by the number of “9s” such as “five 9s”, meaning a service is available 99.999% of the time. To put this into perspective, having an uptime of 99.999% equates to the service being down for 315 seconds in total over the whole year!
This is a huge ask, especially when in the early stages of a startup. From my experience, the uptime requirement on the tech team has had a direct effect on the work/life balance and job satisfaction for the engineers in the team.
Therefore, monitoring for kernel breaking issues (an error which causes the service to crash and can’t be restarted) and fixing them immediately is essential. This is also where choosing the right architecture is really imperative, for example at SAPI we use an event-driven architecture to ensure that we can always process important things like repayments in a timely manner and handle any intermittent failures without having an outage in the system.
The secret to success here is not giving over-inflated estimates of what uptime partners should expect. Instead, a more realistic target should be used to give both time and capacity to scaling the product realistically. While the end goal is five 9s it shouldn’t be in the contract from day one, rather in a long-term KPI to reduce the pressure felt on tech so that they’re not concentrating on just uptime but rather building the product as the team scales.
5. On-Call Process
Following on from up-time, in order to always be improving and getting better in the right direction, the team need to have a good on-call process. When working in a fast-paced startup there will always be things that go wrong and it needs to be known that errors and service outages are a normal part of tech. They shouldn’t be treated as a failure but rather as a growth opportunity in that fixing each issue that comes up means it won’t be seen again.
This is where point number one on monitoring ties in as having observability of the system pays dividends when it comes to on-call issues. When there is an issue which requires immediate attention, the alert should contain all information that the engineer will need to be able to determine what went wrong and how to resolve it. If the issue is already known and can happen again then there should be a runbook to handle these situations so that all team members can handle any on-call issues even if they aren’t familiar with the domain. If the issue is known but does not require immediate attention then it should not raise any on-call alert.
The on-call process includes setting up monitoring to raise alerts for any errors in the system out of office hours, setting up engineers on an alerting system to be notified when one of the critical errors occurs and the tools to be able to resolve any issues quickly. Side note: I have also written an article on my experience in improving the on-call process which you can read here.
6. Cost
Do you know the total cost of running your product? Because cloud service providers charge based on usage, one can’t be sure how much the invoice will be until it’s too late to make cost-cutting adjustments. This makes ongoing cost monitoring very important and one I recommend your DevOps team to report on regularly.
Before choosing technologies and cloud platforms, there should be a clear budget and expectation set for how much the tech team has to spend in order to ensure that the product can be built sustainably. While some cloud providers offer free credits for startups, this can be a double-edged sword as it makes building a proof of concept much easier with a choice of all the technologies on offer but turning all the features on means that when the free credits run out there will be a very expensive bill afterwards.
It’s easy to look past cost management, but at larger companies, cost management is a whole department in itself, which shows how vital this will be as a company grows.
When your priority is launching into market, it’s more about building a working product rather than how much it costs. But this analysis should frequently be undertaken to check that a selected tech is affordable and especially as the company grows and scales with it.
7. Product
You’re never too big to apply the lean startup thinking (by Eric Ries). Speaking with peers it’s surprising how many forget the importance of product process before handing work to tech. Completing customer research to drive a product roadmap which is then handed off to tech to build can be a make or break; especially when on a strict budget and timeline.
Following thorough product process before building gives tech the means to be able to scale successfully as the product has already been proven to be needed by customers and therefore less prone to changes.
One failure point for tech is when the goal-posts change, meaning large rewrites and no new features going into the product. The most common cause of this is because the product being built by the tech team wasn’t ever proven before it was developed. The actual cost of changing requirements is astronomical and in some cases can be fatal to an early-stage company.
While the mantra by Mark Zuckerberg of “move fast and break things” can instil a sense of urgency on the tech team, without knowing that what you are building is the right thing this can be dangerous. Moving fast in the wrong direction can have the single most detrimental effect on a young company. Therefore, a product development cycle should partially ensure that the product is on track with what customers want to use and ultimately pay for. In theory, this may not feel like a secret, but sadly in reality it can feel like it.
8. Team
I’ve saved the best secret for last! The team is very much a make or break at any size but especially so at a startup. While this is the pro and con of the job, the team has to be exceptionally driven and committed to deliver on this mammoth task.
Working in an early-stage startup is a very different mindset from any other size of company, where wearing many hats and working with changing/unclear requirements can be too overwhelming for some engineers. Another area where I’ve seen some engineers fall short of the mark is being able to deliver something which isn’t optimal in the sense of being complete but rather enough for what the company needs at that point in time and be open to changes later.
It’s this skill of being able to deliver value to the business, no matter the reasoning behind the requirements which is the challenge of working at a startup and this, in my mind, should be what motivates the founding members of the team.
I’ve also found that documentation of engineering values and technical decisions is also key within the team in order to ensure that new joiners are aligned and that the values are shared amongst the team and also wider company.
My last focus of the team is that everyone needs to be aligned on a common goal and especially with the wider company vision. This is the one mission statement that the company is trying to solve for and every member of the team is jointly responsible for making sure this happens. If the team are not clear on the 30-second “elevator pitch” of the company then they will likely miss the target of what they’re trying to build and why.
If you’ve enjoyed this read please do give it a like and let me know what you fancy reading next.
0 Comments