10 Things to Consider when your Startup Reaches the Scale-up Phase
Wow, your startup is getting noticed. You just allocated more resources, and you’ve managed to pass that invisible line where you suddenly get called a Scaleup.
Now what? You obviously did well in order to get here, but can you just continue doing things like before?
Take it from an experienced CTO: you can, but you’ll be better off by changing a few things.
#1 — Take a deep breath… Now reconsider your Architecture
In the startup phase, you want to be “Lean”. In fact, you want to be leaner than lean, focusing on getting a Proof-of-Concept, a prototype or even an MVP out. Perfect, but now that you’re scaling up, it makes sense to reconsider a few things.
As an Interim CTO, I have seen many scaleups just keep building on top of prototypes, sometimes not even noticing that until much later. Sometimes, there is even a complete absence of an architectural foundation (which wasn’t needed before).
Being a scaleup means getting yourself ready for the big one. It’s great when the audience for your product grows exponentially, but is the software ready? It could perform great now, but can it handle 10 or maybe 100 times more users simultaneously? You should know, not guess.
#2 — Leverage the true power of the Cloud
Many startups I’ve met start out with building their initial software as they’ve always done. Some use IaaS (virtual machines, container technology), some use (entry-level) PaaS (Cloud Web Apps, Cloud-serviced databases), but in most cases, the resulting platform doesn’t have the scalability and flexibility that is possible in the Cloud.
Using the Cloud at this level is like owning a race car, but staying in first gear. To really leverage Cloud power, you need to adopt new Cloud Architecture Patterns. These patterns were derived from best practices in Enterprise-level applications and are well-documented starting points to redesign applications for scale, complexity handling and robustness.
Think big, act small here. Try to isolate individual components that can be redesigned instead of doing a big bang rewrite, unless you’re ready to dismiss what’s been developed during your Startup phase as a PoC or prototype.
#3 — Insource Smartly — It’s the IP, baby!
When growing, especially when investors come in, it’s important to evaluate where it is exactly that your intellectual property lies. All too often, I meet with startups who have spent a lot of time on pieces of software that, in hindsight, have little to do with their actual proposition.
Lesson number one here is: always ask the question whether a component to be built will contribute to IP that makes your company more valuable. If not, consider isolating and outsourcing it.
#4 — Secure your Companies’ Knowledge
In line with #3, the collected knowledge within your company, apart from being in the brains of people involved, should be secured in a company knowledge base, and shared wisely. This includes all technical, architectural, algorithm, data scheme related stuff.
I know: this generates a lot of overhead. So be it. Overhead can be reduced by the way, by using modern wiki-style documentation platforms.
Anyways, it should be a mindset that is all pervasive throughout the organization, to document all important things around process, procedures, architectural patterns used, quirks, workarounds, etc.
Every developer knows that documenting stuff makes it better: once you go through the motions of trying to write down what you have been building, chances are high that you’ll find flaws in your thinking and improve it.
Needless to say that it might make sense to have some governance (QA/CTO) on the documentation standards and efforts ;-). Also, modern tools have ways to assign review dates on pages, with workflows attached to signal review dates being due. You don’t want your carefully built documentation to become stale.
#5 — Separate your Concerns — even more!
Separation of Concerns (SoC) is one of these design principles that allow for modularity and that makes building complex systems easier. It also facilitates testing and reuse of components. Every single developer knows how to take SoC into account.
My point here is: apply SoC even more. It will help implementing #3 by having clearer boundaries between components and will make it easier to apply #2 by having clearly defined (and well-documented) interfaces.
The more you apply this principle, the less painful your growth will be.
#6 — Add Technical Governance
Scaling up is like jumping directly from early childhood to parenthood, skipping many important phases of your life.
The play is over. It’s serious business, with serious responsibilities.
Security, compliance, GDPR, SLAs, stricter deadlines, all that not-so-fun stuff is getting more prominent, and investors are looking over your shoulder.
This is stuff you need a CTO for, but adding a C-level role to the organization can be a big decision.
Luckily, there are freelance CTOs who can help out and cover this strategic role part-time and hand over once you’re ready.
#7 — Beware of Changing Team Dynamics
Scaling up will almost always mean adding people to your development team. This will however add the need for delegation and a stricter team process, and existing team members will have to adjust to new responsibilities. Maybe coaching new, more junior developers will reduce the seniors’ productivity at first. In fact, the social dynamics at work here need careful guidance and monitoring. Negativity and stress may lurk, strong communication skills are needed to keep a positive, productive culture.
#8 — Free the CEO from Operation
At first, the CEO, mostly one of the founders, will act as a jack-of-all-trades. He/she is Head of Sales, Senior Account Manager, Chief Marketing Officer, Chief Recruitment Officer, HR, Operational Manager, and sometimes even more.
This has to stop.
In a more mature organization, CEOs are mostly external-facing, leading investment rounds, doing (premium) sales, managing brand image and PR, and being the Chief Evangelist.
To get there, first, the mindset of the CEO must change. He/she needs to see that combining all of the previous roles is no longer possible, especially those that have to do with operational management, and delegation (while keeping some level of control) is key.
#9 — Consider an HR strategy
Building a larger team, then holding it together, isn’t easy. Developers and other software-related roles are extremely popular and recruiters and headhunters keep fishing. Making employees loyal, giving them a growth plan, just listening to them, taking into account their wishes, and investing in team-building, makes sense both from a personal perspective and from a business perspective. A strategy in HR has to be developed, and now is the time.
#10 — Close the Gap with your Audience
User Experience Design (UX) and Customer Satisfaction should play a major role in the product development cycle, from start to finish. Now is the time to make sure your software development is UX-driven and both UX research and customer feedback are first-class citizens in defining and adjusting user experience with your product.
This means structures need to be set up to guarantee market validation of product development ideas (the area of UX research), users have an easy (make that really easy — like one click away) way to provide feedback about your product, preferably contextual. Also, you could invest in tooling around continuous measurement of interaction with the product, all feeding back into design and development.
