Startup Software Delivery. Part II — scaling Up

6 min readMar 24, 2018

In the first part (https://medium.com/@chrpopov/startup-software-delivery-part-i-2cc905565eac ) I shared my experience and thoughts about what a CTO should do in early days. Once a roadmap is decided and the first developers are recruited, it is time to build the MVP.

Product Development Process

There are tons of books and articles about software project management. In recent years everyone is trying to be more agile and embracing the so called “DevOps” culture. In a startup, after validating your idea and having hired a small team, you need to build your product.

Almost every startup I have seen uses some form of Agile process. And I am not going to propose something else. I have used Scrum, Kanban or a combination of the two.

Startup = Product Design

You may or may not have a dedicated product manager. In general, the product is designed by the founding team, or actually by everyone in a startup. Startup = Product Design in early stages. In general one agile team (5–7 persons) working with marketing and operations is enough to build the MVP. This is good because you won’t be able to afford a bigger team with seed funding. And this is the optimal agile team size.

Product Design = Business Strategy

Many founders are building their product starting from an idea and then doing trials and errors. This is not a bad way and it fits with the agile model. However this can slow down the time to market, the company may run out of money and the team can run out of patience. A successful software product is at the core of the business model. We assume that the company has already defined its vision, strategy and roadmap.

In Scaling Lean, Ash Maurya defines the traction model as the key metric to watch for confirming the validity of the product and the business model.

So, it is important to define and measure traction early on (together with other metrics). This, in my experience, is more important than the best software architecture. Many technical leaders fall for this trap in startups by trying to build the ideal solution when they haven’t achieved traction. The technology should always a step behind the business. I have seen this happening in one company where we were developing a highly scalable platform for hundreds of millions of users, while we only had 0! The faster you deliver, the faster you can get a feedback if what you do is needed or if you need to make changes.

Business Operations Automation

The business is typically separated between customer facing side and internal operations. You will get demands from operations to develop internal tools to automate operations. While this is very important for the scaling phase, at MVP phase, this can lead to waste. The key objective is to build an MVP, i.e. to find a product market fit and to validate the business model. Anything you do that would delay the validation is a form of waste. An exception to that rule can be some quick wins, tasks that can be easily automated with software and are highly repetitive. Try to leverage SaaS solutions as much for those needs.

Prioritisation

Based on personal experience and on startup strategy books, this is the optimal order of priority for new features:

Highest Business Risk
Highest Technical Risk
Operational tasks

Team Management

Even with a single Scrum team, as a CTO you will find that you never have time to code. I think it is still important to code at this stage though. This will keep you engaged with the team, you will know the stack inside out and you will know what is feasible and what is hard, in order to build the product effectively and in a short time frame. But you need to learn some management basics. You can’t do it all alone. I find that following agile delivery principles help with this. You have a self managed team and a continuous delivery process. The team is able to resolve problems and to ship incremental features daily. In “The Manager’s Path”, Camille Fournier shares her experience and provides advice on how to become a Team Leader and what it means to manage people.

Scaling Up

Once your business has achieved traction and you have built a software team, that continuously delivers business value, you will start hitting scale issues:

Systems will be under heavy pressure
Everything will start breaking down
You will need to cater to different customer groups and different stakeholders

What it means in practice is that you won’t manage with one agile team. You will need to start splitting the teams into product teams and different technical teams (platform team for example). This will also mean that you need to hire tech leads, product managers, etc. You will need to learn how to hire and manage managers. What is really bad is that productivity will never be as fast as it was with your first agile team. This is for many reasons: management and communication overheads, and also the fact that breaking things comes at a very high cost. The management aspects of this are well summarised in “The Manager’s Path”, by Camille Fournier.

Scaling Engineering Culture

How can you retain the startup culture while hiring multiple teams? One way to do it, is going “corporate”. That means having program and project managers managing budgets and streams of work. But this mean loosing the startup culture and capacity to innovate. I like the approach used at Spotify and Transferwise (Watch this presentation by Harsh Sinha, VP Engineering @ TransferWise). The key idea is that each team is a product team and run as a mini startup. They have very large autonomy and the board only acts as a VC, providing funding and monitoring KPIs. Silicon Valley startups are famous for their product engineering culture.

System Architecture

What architecture you build depends on the kind of system you are building. In a content heavy environment, scaling is trivial. It is all about caching content and leveraging Content Delivery Networks (CDN), such as Cloudflare, Akamai. Also, most traditional databases have master-slave replication and are optimised for data reads. However, in a transactional environment, where fast writes and transaction processing is required it becomes less trivial. There are many architectural patterns to do that, such as CQRS (https://martinfowler.com/bliki/CQRS.html) and Event Driven architectures, sharding (splitting) data, replicating data, etc. There are many books about software architecture patterns used for scaling like Software Architecture Patterns, by Mark Richards.

In practice scaling will require the development of a micro-services platform. In recent years, Docker containers and container management frameworks such Google Kubernetes and Apache Mesos have enabled the easy deployment and management of micro services.

Three stages of tech: MVP, Scaling up, The nice and shiny

I would argue that a start-up needs to redo its tech (at least ) three times:

Building an MVP with a small agile team. This is where you apply the Lean Startup principles, and you iterate quickly to discover a product-market fit. You use cloud services and stacks that allow rapid iteration, like Node.js, Ruby on Rails, Python. At this stage you have huge time and budget constraints.
Scaling up the business and the technology. This where you have a working product and you need to scale. You start building your micro-services platform with all the infrastructure management tools and best-practices. This also where you rewrite many of your components with some more reliable and robust stacks. However you still have budget and time constraints.
Transition to an established business. Once you have scaled the tech and the teams, the business has probably matured and there is stable revenue. This is the enterprise stage, where you will typically deal with projects, you could afford the services of enterprise level consultancies and software vendors.