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

Rate this content
Bookmark

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
14 Jun, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Tech growth is a Red Queen's race. Scale the business, team, and tech. Beware of the S-curve. Business growth fuels promotions and engineering challenges. Engineering teams get involved early in the process to develop the best solution.

1. Inflection Point and Scaling

Short description:

Tech growth is a Red Queen's race. Scale the business, team, and tech. Beware of the S-curve. Business growth fuels promotions and engineering challenges. Care about cost of acquiring customers and their lifetime value. As an engineer, build fast and don't be a bottleneck for the company.

Thank you. So, what's next? What happens at that inflection point where you go from slow growth to a lot of growth? 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've 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 ten dollar eBook 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. 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.

2. Scaling the Team

Short description:

Engineering is the tool, not the goal. Scaling the team impacts engineering processes. Build vertical teams, organized by business domain. Teams should deliver value on their own. Own your destiny and mess, understand your domain. Engineering teams get involved early in the process to develop the best solution.

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. Because many tech problems, when you squint a little, are actually people problems. Because, 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, like, that five-minute conversation can save you a week's worth of work. 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. You're always waiting, like 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 plan.

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's different names for this. Like, 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? 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. You get an idea, like 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, and 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 – whoop, I didn't mean to press that yet.