Navigating the Engineering Challenges from Start-Up to Scale-Up

What got you here won't get you there. The struggles many early stage engineering teams face when scaling up, and the need for novel approaches to successfully handle the transition.

Nov 28, 2023

We commonly refer to early stage start-up phases as the 0-to-1 phase. That's when companies go from a compelling idea to finding Product Market Fit (PMF). If you're in charge of the engineering team in such a context, you need to take advantage of specific tactics and approaches that will maximise your chances for success.

Once companies reach the longed for PMF stage (which isn't a binary thing, but let's park that for a separate discussion), they typically enter the scaling phase, often referred to as scale-up or 1-to-100 phase.

The worst thing you can do when moving into this second phase as an engineering leader is to think that you can pull it off by just hiring more people while operating the organisation largely in the same way as you've always done.

The goal of this article is to illustrate the different ingredients required to increase your chances of success in each one of those two phases.

The transition between these two phases can be more or less abrupt, but there is no quantic jump that happens on a random Thursday morning. The move from 0-to-1 to 1-to-100 is gradual and in some cases can last many years.

What works well for Start-ups, or 0-to-1 companies:

Here are some fundamental approaches and practices that will help you maximise your chances of success as an engineering leader for an early stage start-up.

This list is not comprehensive. It's rather the common subset of what I've seen working.

⏳= 💸 Time equals money burn.

As an early stage company, chances are you raised some money, but rarely too much. You likely count your runway in months, and would like to avoid having to raise more money too soon.

You're in a race against the clock to find PMF and starting to generate some healthy revenues. Until you get there, this should be your main and only goal.

Unless you're building a fundamental new technology - which isn't very common after all - you will want to use off the shelf components for most of your stack, be it provided as managed service or simply as an open source software.

You should strive to build as little as possible as that's the best way to keep your team lean and nimble.

⚡Prototype new features as fast as possible

Don't spend too much time perfecting them! You want to see what will stick, and most of what you build won't. As such, you'll need to learn to accept that most of what you push out to production will be a little more than a working prototype. It will be unpolished, it will be missing support for many corner cases, and it will have some unexpected behaviours.

This doesn't mean you should be sloppy with your code, skip testing or cowboying changes in production.

A good level of quality is what will allow you to move fast in a sustainable way. At the same time, accept that you'll have to throw away most of what you build during this phase, and make sure you keep waste low.

🙏🏼 Ask for forgiveness, not for permission

This is sometimes referred to as “bias for action”. It's a preference for taking decisive actions quickly, rather than excessive deliberation or procrastination.

This attitude should apply to both yourself and the rest of your team.

Make sure you hire people that are comfortable taking decisions when facing an opportunity or a lot of ambiguity. As everything is an experiment, there should no need to ask for permission to run one.

Just keep an eye out to avoid this being pushed too far. You need to ensure it doesn't become an excuse for internal fights, i.e. people undoing each other's work because they think they know better; or that it doesn't make your product drift through the current without any clear direction.

Push out too many random features and your users will get very confused.

📝 Documentation is limited to the minimum

The team is small, and things move very fast.

At this stage you'll likely have very little written documentation.

You will probably document some of the major product experiments you're running. You will have some documentation that outlines the overall infrastructure and architecture, but many of those details will likely be outdated.

People learn mostly by working with each other, and that is very effective due to the size of the team. You as a leader will probably carry in your head a lot of that information.

There are occasionally situations in which people complain about the lack of documentation, but very few will actually put in the effort to bridge that gap.

This might not be ideal, but definitely acceptable at this stage. You might not be around in 6 months, and lack of documentation is unlikely to be the main driver for your business to fail.

📐Very little time spent discussing architecture

There is no point in making big architectural investments when you don't know what part of your product is going to stick, if any. This is not to say there won't be architectural decisions being made.

Whenever you're building a software product, you're taking a ton of architectural decisions. At this stage you will want to optimise for what allows you to iterate faster, as such you'll likely opt for the simplest possible architectural setup.

You'll build a lot of monolithic applications, and that's perfectly fine, as it'll keep complexity down. As the engineering leader for the team you'll find yourself having to make a lot of architectural decisions yourself. Don't over-think them.

Remind yourself that if your business is successful, you'll have to rebuild the whole thing multiple times anyway.

Focus instead on building a deeper knowledge of your business and how users interact with it. These will be fundamental inputs for better architectural decisions you'll take in the future.

🛡️ Security is largely a non-concern

This might sound counter-intuitive. As your business might not be around in 6 months, you have more pressing priorities to deal with.

Unless your start-up operates in the security space, it's unlikely you'll have someone fully dedicated to security in your team.

At best you will have an engineer that has some interest in the security space. But even they will spend most of their time building or improving features in your product.

With very few users and a likely small valuation, there is very little to secure and protect.

This should not be taken as invitation to ignore baseline security fundamentals.

Don't store passwords in clear text, do encrypt your data in transit, don't expose database on the internet, etc…

Beside these basics, you're unlikely to get a lot of value by investing further in security now. Keep that budget for when there will be something valuable to protect.

Scaling from Start-Up to Success

You and your company have been doing a good job for a while, and users are starting to flow in.

If all goes well you might be able to close a sizeable round of investment, as VCs are interested in helping you accelerate your growth toward profitability.

This is often when things become challenging for the original engineering team.

Victim of your own success you might assume that you'll be just fine in the next phase by doing what has worked well until now…

In most cases that's a recipe for headaches, frustrations and some minor to very serious disaster.

I invite you to resist the urge to start hiring a lot of people into your team, doubling its size every 6 to 9 months. Chances are you're not ready for it, and you'll regret the move later down the road. That regret will be an expensive one.

Instead, when you're starting to shift into Scale-up mode, I recommend you put a lot more emphasis on the following aspects first. With those solid foundations in place, you'll get a much better ROI from any future hire.

📈 Build Scalable Processes, Systems and Architectures

Start by auditing your processes.

Is your development workflow clearly defined, or does it rely on people doing the right thing out of intuition?
Do you have clear processes for doing code reviews?
Do you have clear processes for budgeting? For responding to incidents? For introducing new major technical decisions?

Chances are you don't. Start here.

You want your processes to be in a good shape before you start adding a lot of people on a shaky foundation.

A lot more of your work going forward will require foundational and largely unsexy work. Get used to it, or seriously consider stepping into an IC role and let someone else lead the team. There is nothing bad in being self aware.

Once your processes will be in a better place, you will want to take a serious look at your systems and architecture.

Given the usage patterns you've seen in the product so far, which areas are likely to be suffering the most from spikes in traffic?
Which parts of the product require more frequent iteration as they're emerging as core domains for your entire business?

Make sure you start carving out separate bounded contexts that reflect the nature of the business. Replace generic or supporting domains with third party or internal “good enough” solutions, and double down on the core domains.

Look for bottlenecks, both in systems and processes. Look for ownership gaps. Don't aim for 100% clear boundaries just yet as it's unlikely you'll have all the answers at this stage.

Accept temporary and evolving mapping between teams and systems.

🗓️ Put a lot more emphasis on planning

The bigger your organisation, the more you'll want to build in predictability and reduce chaos, which otherwise would lead to waste.

You will need to level up your planning game.

From yearly strategies to quarterly goals, and then monthly and weekly plans. You will want to make sure you invest a reasonable amount of time thinking - and documenting your thinking - before moving full speed ahead with execution.

Moving very quickly in the wrong direction is the easiest and most common way to waste resources.

Since the cost of many initiatives will be increasingly higher as you build more sophistication in your systems, that will require and increased level of scrutiny.

Get used to it, and optimise your decision making processes to keep them lean and effective, but don't short-circuit them.

📝 Documentation becomes crucial

Gone are the days when you could keep all the information in your head, or just have a chat with the person sitting next to you to introduce major changes in the system.

Chances are you're hiring more people in your team. All these new joiners will lack the context that you and the original team so easily shared until recently.

Many decisions you've taken in your codebase might make perfect sense, but as they are largely undocumented it becomes increasingly difficult for people in your team to understand their rationale.

“Code is self-documenting” is lazy BS. The best written code will not tell you why you're doing things in a certain way. What are the options you've tried before. What are the conscious tradeoffs you're making. What is the business context underlying them.

A lot of your job now will be around documenting decisions, and making the information easily accessible to the rest of the team.

⚙️ Tooling and standards become a key area of investment

As you onboard more people in your team you'll see inefficiencies compounding. A quirky system that requires a couple of manual steps for every deployment is not a big deal in a team of 5.

The same will have a much bigger impact in a team of 20-30 engineers.

In many cases you'll be better off not hiring more people, but investing in making your current team more productive.

Invest in automation, tooling, developer experience. Make sure you understand where the bottlenecks are and try to get rid of them.

Try to “buy” as much tooling as you can rather than building, as everything you build is a liability that you'll be responsible for maintaining and evolving.

Your observability stack will become more and more important as the system grows in complexity and it becomes increasingly hard for any individual in your team to have a full mental map of it.

☎️ Reliability, on-call and incident response

You've probably got until now without formal on-call and incident management procedures in place.

You and the most senior members of the team are used to dealing with incidents whenever something happens.

Most of your incidents are triggered by someone in the Customer Support team, reacting to reports or complaints from the users. If not addressed, this explosive mix will burn your team down more quickly than you might expect.

Invest in establishing formal incident management procedures, a fair and compensated on-call schedule, monitoring and proactive alerting.

Establish the routine of post-mortems to learn from each and every incident and make sure your team becomes increasingly better not only at dealing with them, but more importantly at preventing them from happening.

As more users flock to your systems, you'll discover new and surprising failure modes that where not visible until very recently.

By having structured processes in place you'll mitigate the disruption on your workflow caused by every single outage.

🛡️ Security becomes key

As your company's success grows, so does the amount of stakes that are at risk in case of a major security incident.

As you grow, it's likely that your board of directors will start asking about your plans to protect the valuable assets they have now in their portfolio.

The reality though is that most companies start taking security seriously only after they've been victim of one or more serious incidents. It's a known human bias, the same that explains why people tend to install anti-burglar alarm systems after they've been robbed.

Prepare yourself for having to learn about the non trivial topic of cybersecurity. You'll likely need to build this function from scratch, and you might be tempted to start by hiring a random security engineer and have them do “security stuff”. There is a high chance you'll not be focusing on the right priorities if you go with this approach.

My recommendation is to look for an experienced Head of Security that will come in, assess the situation and help you build a security program for the years to come.

Conclusions

0-to-1 teams can rarely make a successful transition to the 1-to-100 phase unless they excel in self-awareness and have been through a similar journey before.

When no one in the team has prior experience with the scale-up phase, the organisation might naively assume it can be successful by simply doing what has worked well until recently.

Teams that take this approach are up for a bad journey, as a new operating paradigm is required to be successful in a very different stage.

If you start-up is maturing into the scale-up phase, congrats!

Make sure you audit your team's strengths and weaknesses, and address the gaps you'll identify via focused hiring or consulting.

Starting there is going to yield much better results than just throwing people at the problem, as many companies unfortunately end up doing.

I would love to hear in the comments section about your experience going from start-up to scale-up, and what have been some of the major changes you had to introduce in order to succeed!