This Guest Post was authored by Rob Zuber, CTO of CircleCI. CircleCI is the world’s largest continuous integration and continuous delivery (CI/CD) platform. Below, Rob continues from Part 1 to look at finding product-market fit during the very early 10-20 engineer stage.
The article below is an excerpt from The Startup Founders’ Guide to Software Delivery from CircleCI, available in full here.
At 10 to 20 engineers, you probably don’t have a person dedicated to developer efficiency or tooling. You might, but it’s not common. It’s more likely everyone is contributing to the cause. And your team will benefit from deferring creating a dedicated Dev Experience or Tooling team.
Why? Because at this stage you will be building this mindset into your culture precisely by deferring the dedicated team. You get further by having everyone be responsible than by relying on a single person. Then people are creating tools, processes, and code that can be shared across teams.
At 10-20 engineers, you have some practices in place, you’re keeping your software simple. You’re finding product-market fit. That’s the benchmark. Once you get there, you can invest.
Before product-market fit, everything you build has a high probability of being thrown out – the goal is to build as simply as possible so you can pivot or throw things out easily. Once you have fit, you can start making investments.
This is the awkward stage where you are trying to manage your ability to work independently without creating unnecessary complexity in your operating environment. Should you break into teams? There are too many people for one team, but your priorities are still shifting. But it does feel cumbersome to be working on the same thing.
At 10-20 engineers, you’ll be tempted to build services, but it’s too early. You’d be adding unneeded deployment complexity that you’ll pay for later.
Rather, create boundaries and stability with components and libraries. Whether you end up using libraries or just well-defined boundaries between your monolith (i.e. a modular monolith) – you can still pull it all together and deploy in a monolithic fashion This will give you room to operate with more independence, while keeping your deployment simple.
Breaking your codebase into services will add a whole new layer of decisions: What kind of inter-service communication should you use? How should you do service discovery? Or retries? There is a massive amount of cost and complexity that comes with your first service.
So put it off.
You will want to change your continuous integration (CI) process without changing your continuous delivery (CD), or in other words: change your build model without changing your deploy model.
What to Do
- Keep deployment simple. Keep your build and deploy as simple as you can. Resist the urge to create services or overly complicate anything you can defer instead.
- Maintain efficiency and productivity as you grow past the 2-pizza mark. Look for more fluid ways of creating independent work streams without concrete team definitions.
- Expose engineering to customers’ feedback. You want an engineering team that understands why customers want a given feature and what it is solving. There is a time and place for large product management teams that curate information and focus the team around core principles and maintain consistency across a product portfolio, but this isn’t now [early in GTM]. As you hone product-market fit, you can best take advantage of your small team by optimizing for direct channels of communication between customers and engineering and maintaining tight feedback loops.
What Not to Do
- Microservices. Building services where you could use components or libraries instead will create deployment overhead that a team of this size shouldn’t have to deal with. Defer.
Read the complete The Startup Founders’ Guide to Software Delivery from CircleCI.
