Scaling Fast – Engineering Lessons From ~15 Years of Tech Startups

Rate this content

Building a business is a slugfest to see who gets more customers first. You have to adopt that mindset when writing code. As an old boss told me once: Clean code won't matter if we're dead. You have to shift your mindset from best practices to getting shit done. But you can't go too wild or the tech debt will kill ya. 

Swizec Teller
Swizec Teller
27 min
15 Jun, 2024


Sign in or register to post your comment.

Video Summary and Transcription

Tech startups require scaling the business, the team, and the tech. The goal of an engineering team at a startup is to not be the reason for the business to slow down. Engineers prioritize business outcomes over code debates. Simplify your code and prioritize solving the specific problem. Organize your code vertically to limit complexity and improve clarity. To avoid code problems in the future, focus on getting the data and architecture right rather than striving for perfection today. Balancing dry and duplicating code can be achieved by allowing patterns to develop and observing for common solutions.

1. Scaling fast, engineering lessons

Short description:

Tech startups require scaling the business, the team, and the tech. The business side is the fuel for engineering growth and career progression. Care about the cost of acquiring customers and their lifetime value.

So, we invite you to join me in welcoming one of the speakers to the room. And, of course, I'm sure you're all excited to hear what he's going to be talking about.

Scaling fast, engineering lessons from about 15 years of tech startups. I may be old. So, your users are going... Now what do you do? What happens next? So, what happens at that inflection point where you go from slow growth to a lot of growth? The first thing you've got to remember is that tech is a Red Queen's race. That means that you have to catch that explosive growth right now while it's happening because no mode lasts forever, and if you found something that's worth chasing, there's at least five other companies trying to do the same thing while you're chasing this growth.

So, to keep up with the growth, you're going to have to scale three parts of your company. You're going to have to scale the business, the team and the tech. Now, scaling the business is pretty simple. Forget what all the business people are telling you. There's only two things you can do here. You can either sell more products to more people. That's why everything is a subscription these days. Or you can sell products for a higher price. That's why every company you see starts as B2C, and then they go to B2B and Enterprise, or if you follow any influencers or indie creators, they start with a $10 e-book and then eventually they have a multi-thousand dollar video course. That's the same thing.

But when you're scaling the business, you have to beware of the S-curve. Every business or product hits a saturation point where your churn and your customer acquisition start to balance out and you kind of stop growing, and that's when you have to figure out something new. You have to either release more products, find new audiences, or just, you've got to figure out something new to do when you hit the saturation point. But as an engineer, I think we're all engineers here, why would you even care about any of this? That's because the business side is your fuel. You want the business to grow because fighting the market means you're not fighting each other within the company. When your business is growing, that's where the promotions come from, that's where more engineering challenges come from, your career grows, your CV looks more impressive, all the good stuff comes from growing the business and having those business results. And if you don't have growth, if you're in a stable, low-growth business, your career kind of turns into a zero-sum game. You have to steal your promotion from somebody else who's not getting promoted. You have to, you know, everything becomes a zero-sum game. So the main numbers that you have to care about when you're thinking about the business side is your cost of acquiring a customer and their lifetime value. The delta between those two numbers fuels everything else in your business. Now, while the business people are taking care of that side, you're looking like this as an engineer. You're just trying to build as fast as possible so that you're not the bottleneck for the company.

2. Scaling the team and vertical organization

Short description:

The goal of an engineering team at a startup is to not be the reason for the business to slow down. Scaling the team involves organizing vertical teams based on business domains, allowing them to deliver value independently. Each team should own their destiny and mess, understanding their domain and taking responsibility for the entire process from idea to production. This ownership leads to domain expertise and enables collaboration between product and engineering for the best solutions.

The only goal you have as an engineering team at a startup going through that inflection point is to not be the reason that the business has to slow down. And remember, engineering is the tool, not the goal. You're building that flower, but what you're selling is those awesome people who can do cool shit that they weren't able to do before.

So one thing, this brings us to scaling the team. Many tech problems, when you squint a little, are actually people problems. Yes, you can write some really amazing code that does wonderful things and makes you feel super smart, but it would be so much easier to just have a five-minute conversation and be like, you know, why is the API not returning the data I need? Because if you can solve it that way, that five-minute conversation can save you a week's worth of work and it's a lot faster. It's a lot faster to solve technical problems that way.

So how you scale the team really impacts everything else in your engineering processes. And the mistake that many companies make at this stage is that they build horizontal teams instead of vertical teams, so you end up with a front-end team and a back-end team, maybe some sysadmin people, and this is a really great way to ensure that everyone is always blocked by somebody else. The front-end team is always waiting on the back-end team to get their work done. The back-end team is always waiting on the front-end team. Somebody is always waiting on the sysadmins. And the only way that those teams wouldn't get blocked by each other is if their roadmaps are carefully in sync and nothing ever takes longer than you planned, because engineering projects always take exactly the amount of time you planned for them, right?

So instead what you really want are vertical teams. They should be organized by the business domain that they're tackling. The idea here is that you organize your teams by what they're doing, not how they're doing it. There are different names for this. Every consultant that talks about teams and stuff has a different name for this concept. Some call them empowered product teams, stream-aligned teams, business-capability-centric teams, but whatever you call it, they always have the same goal. It's how can we have teams that deliver value on their own without being blocked by other teams. So the goal is that each team, or you in a team, should be able to own your destiny, own your mess, and understand your domain. Owning your destiny means that you can ship value from idea to production. Your team comes up with an idea and can get it all the way to production, delivering value to users. Owning your mess aligns incentives and means that you are in charge of keeping your code running in production, making sure it works, and all of that stuff. There's no writing some code and throwing it across the wall to QA and deployment teams and so on. You should be in charge of that because that way you care about it more. You get to feel proud of the stuff you've built because you're there to see the impact it has on your users. With that long-term ownership, what you get is domain expertise where you really understand the users that you're solving problems for and the problems that they have, which then unlocks a really good collaboration between product and engineering where you can work in this product development cycle where you can focus on getting us across the water, not just building a bridge. The idea here is that engineering teams, especially product engineering teams, get involved early in the process, as early as possible, and ideate together with the product to develop the best solution to the problem, not just a solution that somebody else thought of. You can do this because you understand the domain and understand your...