Scaling Fast – Engineering Lessons From ~15 Years of Tech Startups – Swizec Teller, TechLeadConf

Summary

Скрипт видео предоставляет уроки масштабирования технологических стартапов, основанные на 15-летнем опыте. Автор подчёркивает важность поймать момент экспоненциального роста в гонке Красной Королевы, где нет места для стояка. Для масштабирования бизнеса, команды и технологий необходимо сосредоточиться на увеличении продаж, улучшении цен и избежать сверху насыщения. Команды должны быть вертикально организованными, чтобы обеспечить независимость и экспертизу в доменах, что улучшает взаимодействие с продуктами и приоритизацию результатов. Инженеры должны сосредоточиться на простоте и упрощении архитектуры, сохраняя при этом долгосрочную владение и знание своего домену.

Takeaways

• 🏁 Начало взрывообразного роста - это ключевой момент для стартапа, когда необходимо быстро реагировать на рыночные возможности.
• 🔄 В технологической сфере существует 'гонка Красной Королевы', где необходимо улавливать момент роста, так как ни один тренд не продлится вечно.
• 📈 Для масштабирования бизнеса необходимо увеличивать продажи, расширять аудиторию или повышать цену продуктов.
• 🔄 При масштабировании бизнеса важно учитывать 'S-криву', когда рост достигает точки насыщения и начинает замедляться.
• 👨‍💼 Инженеры должны понимать, что рост бизнеса - это их топливо, так как это дает им больше возможностей для профессионального роста и новых вызовов.
• 🛠️ Инженеры должны стремиться к тому, чтобы не стать узким местом для роста компании, сосредоточившись на быстрой разработке.
• 💬 При масштабировании команды важно решать технические проблемы через общение, а не только через код.
• 🔄 Вместо горизонтальных команд, которые часто блокируют друг друга, следует создавать вертикальные команды, работающие в рамках определенной бизнес-области.
• 🌟 Команды должны обладать самостоятельностью, отвечать за свои решения и понимать свой домен, чтобы предоставлять ценность пользователей.
• 🔧 При масштабировании технологий следует использовать известные решения для известных проблем, минимизируя инновации там, где это не требуется.
• 🔗 Архитектура кода должна быть организована вертикально, чтобы уменьшить взаимосвязи и сложность, сосредоточившись на данных и структурах.
• 📚 Автор планирует написать книгу, основанную на данной презентации, и предлагает узнать больше через QR-код.

Q & A

Что означает фраза 'красная королевская гонка' в контексте технологических стартапов?

Фраза 'красная королевская гонка' используется для описания ситуации в технологической индустрии, где компании должны постоянно развиваться и инновировать, чтобы удерживать свое лидерство на рынке, иначе они могут быть отставлены конкурентами.

Какие три части компании нужно масштабировать для поддержания экспоненциального роста?

Для поддержания экспоненциального роста необходимо масштабировать бизнес, команду и технологию. Это охватывает увеличение продаж, улучшение команды и оптимизацию технологий для эффективной работы компании.

Почему автор считает, что рост бизнеса важный для инженеров?

Автор считает, что рост бизнеса важный для инженеров, потому что он приводит к большему количеству продвижения, новых инженерных вызовов и улучшению карьеры. В растущих компаниях возникают новые возможности, в отличие от стабильных или слабо растущих бизнесов, где карьера может оказаться в состоянии нулевой суммы.

Что означает S-круг и как он связан с ростом бизнеса?

S-круг - это концепция, описывающая жизненный цикл продукта или бизнеса, где рост доходов достигает пикового значения, а затем замедляется из-за насыщения рынка. Компания должна искать новые продукты или аудитории, чтобы преодолеть этот потолок и продолжать расти.

Почему автор предлагает создавать вертикальные, а не горизонтальные команды?

Автор предлагает создавать вертикальные команды, потому что они могут работать более независимо и эффективно, сосредоточены на конкретной области бизнеса и не блокируются другими командами. Это позволяет командам быстрее принимать решения и реализовывать изменения.

Что такое 'собственность проблемы' и почему она важна для команды?

Собственность проблемы означает, что команда несет ответственность за свое кодооборот, включая его разработку, тестирование и поддержку в продакшене. Это важный концепт, потому что он заставляет команду заботиться о своих продуктах и процессах, что, в свою очередь, улучшает качество и эффективность работы.

Почему автор считает, что быстрые рецензии кода важны для масштабирования команды?

Автор считает, что быстрые рецензии кода важны, потому что они сокращают время ожидания и ускоряют процесс разработки. Это позволяет команде быть более гибкой и реагировать быстрее на изменения, что особенно важно в условиях экспоненциального роста.

Какие рекомендации автор дает по управлению сложностью в инженерии?

Автор рекомендует бороться с сложностью, используя вертикальное разделение кода, тип- или контрактное программирование, а также сосредоточение на данных и структурах данных. Он также поддерживает идею 'не повторяйся' (DRY), но только в той мере, в которой это не приводит к чрезмерной сложности архитектуры.

Что автор предлагает делать с кодом, который не соответствует идеалам?

Автор предлагает принимать код, который работает, даже если он не совершенен, поскольку 'код, который работает, всегда лучше, чем идеальный код'. Он также рекомендует делать короткие запросы на вытягивание (PRs) и минимизировать время, затрачиваемое на рецензии кода.

Почему автор считает, что данные и структуры данных играют ключевую роль в инженерии?

Автор считает, что данные и структуры данных играют ключевую роль, потому что правильное управление и организация данных могут значительно упростить процесс разработки и поддержки кода. Если данные и структуры данных не соответствуют домену приложения, это может привести к ненужной сложности и повторному коду.

Outlines

00:00

🚀 Быстрый рост и необходимость масштабирования

Спикер начинает с обсуждения необходимости масштабирования бизнеса, команды и технологий при быстром росте компании. Он подчеркивает, что в условиях стремительного роста важно не стать узким местом для компании и упоминает о 'гонке Красной Королевы', в которой, несмотря на прогресс, приходится постоянно бежать, чтобы оставаться на месте. Важно понимать, что успешный бизнес приводит к карьерному росту и новым вызовам для инженеров. Основные показатели, на которые стоит обращать внимание — стоимость привлечения клиента и его пожизненная ценность, так как их разница определяет успех компании.

05:00

📊 Вертикальные команды: путь к эффективности

Спикер объясняет важность вертикальной организации команд в отличие от горизонтальной. Он утверждает, что горизонтальные команды создают узкие места, так как разные отделы зависят друг от друга, что замедляет работу. Вертикальные команды, организованные по бизнес-доменам, позволяют быстрее доставлять ценность пользователям, обеспечивают автономность и ответственность за весь процесс разработки, включая запуск и поддержку продукта. Такая структура способствует лучшему пониманию проблем пользователей и улучшает взаимодействие между продуктом и инженерами.

10:01

🔄 Ускорение процесса код-ревью и минимизация блокировок

В третьем параграфе обсуждается важность быстрой и эффективной проверки кода для поддержания темпов разработки. Спикер советует избегать долгих проверок кода, так как это приводит к накоплению 'несвежего' кода и усложняет его интеграцию. Рекомендуется проводить обсуждения дизайна и решений до написания кода, чтобы минимизировать возможные задержки. Также подчеркивается важность коротких, но качественных проверок, что позволяет быстрее обнаруживать и исправлять ошибки, если они возникнут в продакшне.

15:03

🛠 Масштабирование технологий и упрощение решений

Спикер рассказывает о масштабировании технологий, отмечая, что это проще, чем кажется, так как обычно решаются известные проблемы с помощью проверенных решений. Он призывает не усложнять задачи и избегать чрезмерной гибкости, которая может привести к увеличению сложности архитектуры. Вместо этого он советует использовать проверенные решения и адаптировать задачи под них, а не наоборот. Спикер также рекомендует избегать создания сложных универсальных решений, если можно обойтись простым и прямым подходом.

Keywords

💡Технологические стартапы

Технологические стартапы - это молодые компании, специализирующиеся на разработке и использовании инновационных технологий. В контексте видео, автор обсуждает, как стартапы могут достичь экспоненциального роста и как инженеры могут эффективно работать в таких компаниях. Примеры в скрипте включают различные стратегии роста и масштабирования, которые могут быть применимы для технологических стартапов.

💡Масштабирование

Масштабирование означает процесс увеличения размеров или объема чего-либо, в данном случае - бизнеса, команды и технологий. Видео посвящено методам масштабирования в условиях экспоненциального роста, что включает увеличение продаж, улучшение команды и технологические решения. Автор подчеркивает важность масштабирования для поддержания роста и конкурентоспособности.

💡Команда

Команда в контексте видео относится к коллективу людей, работающих вместе в компании для достижения общих целей. Автор говорит о том, как правильное масштабирование команды включает в себя создание вертикальных команд, которые могут работать в автономном режиме и не блокируют друг друга, что способствует эффективности и производительности.

💡Вертикальные команды

Вертикальные команды - это группы, организованные вокруг конкретной бизнес-функции или продукта, а не по технологическим специализациям. В видео автор предлагает организовывать команды таким образом, чтобы они могли вносить свой вклад в проекты от начала до конца, что упрощает их работу и повышает уровень ответственности.

💡С-кривая

С-кривая (S-curve) - это концепция, описывающая жизненный цикл продукта или бизнеса, где рост начинается медленно, ускоряется, достигает точки насыщения и затем замедляется. Автор использует этот термин для объяснения, что компании должны быть готовы к разработке новых продуктов или поиску новых рынков, когда они достигают точки насыщения.

💡Цена за клиента

Цена за клиента - это сумма, которую компания тратит на привлечение одного клиента. В видео автор подчеркивает важность определения этой метрики для оценки эффективности маркетинговых и продажных усилий и для определения, какая часть бизнеса является прибыльной.

💡Жизненный цикл клиента

Жизненный цикл клиента - это общее время, в течение которого клиент остается клиентом компании и генерирует доход. Автор говорит о важности понимания этого показателя для планирования стратегий роста и определения, как долго компании нужно поддерживать клиента, чтобы обеспечить выгоду.

💡Архитектура

Архитектура в контексте видео относится к структуре и организации программного обеспечения, включая классы, модули, сервисы и их взаимодействие. Автор говорит о том, как правильно выбранная архитектура может упростить разработку и поддержку программного обеспечения, а плохая архитектура может привести к сложностям и дополнительным затратам.

💡Кодовый ревью

Кодовый ревью - это процесс, при котором другие разработчики проверяют код на ошибки, стилистику и соответствие стандартам перед его внедрением. Автор говорит о том, что быстрый и эффективный процесс кодового ревью может существенно ускорить разработку и уменьшить количество ошибок в коде.

💡ДРЯ

ДРЯ (Don't Repeat Yourself) - это принцип программирования, при котором разработчики стараются избегать повторения кода, чтобы упростить поддержку и изменение. Однако автор видео высказывает точку зрения, что иногда повторение кода может быть предпочтительнее излишней обобщенности, особенно в случаях, когда это может снизить сложность и увеличить ясность.

Highlights

Tech startups require scaling business, team, and tech to handle explosive growth.

Tech is a 'Red Queen's race' where you must adapt quickly to maintain growth.

Scaling the business involves increasing sales or product prices, but be aware of the S-curve and saturation points.

Business growth fuels engineering challenges and career progression.

Engineers should focus on not being a bottleneck during the growth phase.

Scaling the team should prioritize vertical teams over horizontal to reduce blockages and improve autonomy.

Vertical teams should be organized by business domain for better domain expertise and collaboration.

Delegating decisions to those closest to the problem can significantly improve scaling.

Code review processes should be as short as possible to avoid work-in-progress bottlenecks.

Discussing solutions before coding can expedite the code review process.

Scaling tech is about solving known problems with known solutions, not over-engineering.

Adopting standard designs and adjusting problems to fit solutions can accelerate development.

Avoiding complexity in architecture is key to maintaining manageable codebases.

Vertical code organization can reduce complexity and improve maintainability.

DRY (Don't Repeat Yourself) can be detrimental if it leads to overly complex and intertwined code.

Focusing on data and data structures can simplify code implementation.

Control over API, data, and UI by vertical teams leads to better problem-solving.

The speaker is turning the talk into a book for further exploration of the topics.

Transcripts

[Applause]

[Music]

he

[Music]

[Music]

scaling fast engineering lessons from

about 15 years of tech startups uh I may

be old so your users are going now what

do you do what happens next what happens

at that inflection point where you go

from slow growth to a lot of growth

first thing you 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 happen

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 are 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 to more people that's like

uh 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 uh Indie

creators they start with like a $10

ebook and then eventually they have a

multi thousand video course that's the

same thing but when you're scaling the

business you have to be Ware 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 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 the you want

the business to grow because uh 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 uh your career grows your CV looks

more impressive all the good stuff comes

from growing the business and having

those business

results um and if you don't have growth

if you're in a stable Z 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 Su grain yeah

zero some game so the main numbers that

you have to care about when you're

thinking thinking about the business

side is your customer is your cost of

acquiring a customer and their lifetime

value the Delta between th 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 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

that they weren't able to do before

so one thing this this brings us to

scaling the uh scaling the team because

many Tech problems when you squint a

little are actually people problems uh

cuz 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

5-minute conversation and be like yo why

is the API not returning the data I need

cuz if you can solve it that way you you

like that five minute conversation can

save you a week's worth of work and it's

a lot faster uh it's a lot faster to

solve technical problems that way so how

you scale the team really impacts

everything else in your uh in your

company in your engineering

processes and the pro um 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 backend team

maybe some CIS admin 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

backend team to get their work done the

backend team is always waiting on the

front end team somebody is always

waiting on the CIS admins and the only

way that those teams wouldn't get

blocked by each other is if their uh

road maps are carefully in sync and

nothing ever takes longer than you plan

because you know engineering Pro

engineering projects always take exactly

the amount of time you plan for them

right um so instead what you really want

are vertical teams um they should be

organized by the business domain that

they're tackling the idea here is that

you should you organize your teams by

what they're doing not how they're doing

it the there's different names for this

some cons 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

it's all they always have the same goal

it's how can we have teams that deliver

value on their own without being blocked

by their 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 ction making sure

it works uh 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 and 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 longterm and

with that long-term ownership what you

get is domain expertise where you really

understand the the uh the users that

you're solving problems for and the

problems that they're that they have

which then unlocks a really good

collaboration between product and

Engineering where you can work in this

uh 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 whop I didn't mean to

press that yet um

so what you get from this is that

Engineers understand why they're

building what they're building which

then lets them prioritize business

outcomes over just writing full code and

getting distracted in Long debates about

what is the best way to write a for Loop

or whatever you know all the stuff that

you see on Twitter most of those debates

don't actually matter at all um and when

you have those Engineers that can that

understand their domain you can start

delegating decisions not just tasks and

this is probably the biggest the biggest

lever you can pull when you're scaling a

team or scaling a company is that the

people who are closest to the problem

the people who are closest to the domain

they're working with probably know best

what is the right solution because

ultimately you can't have one Central

decision maker who is doing the thinking

for everybody on the team when um that

that's very common early in startups

like the founder or eventually like the

head of product comes up with all the

ideas and everyone else is just building

and what you get is a very strong

bottleneck that has to get involved in

every little thing and is blocking the

entire company or the all of the

products and everything you're working

on from

advancing and unfort fortunately or

unfortunately this also means that

you're going to have to eat your ego

when you're dealing with code uh code

review and you're going to have to merge

some unperfect code because it is okay

it's fine code that works always beats

code that is perfect uh just have short

PRS what what was it going to say so

have have quick PRS uh as short of a

code review process as possible and

raise your hand if you measure your code

review time in

minutes two hands nice hours few okay

who has been in a code review that has

taken multiple days or weeks to get

something

merged I feel sorry for all of you um

work in progress is the fastest way to

kill all of your progress when you have

stale code lying around it becomes

harder and harder to merge and resolve

that uh code like merge conflicts all of

those things especially when you're in a

situation when you have multiple teams

working on the same product together or

you have multiple or you have teams

working on different microservices that

all talk to each other if you have code

that's just lying around in purgatory in

code review it gets harder and harder to

get that landed

so uh one way you can speed that up is

to talk to each other before you write

the code before any code get so what we

like to do in my team is to get together

for every new project agree on the

design agree on the solution ahead of

time before any code is being written so

that by the time we're making code

reviews it's just a very quick check we

can do most of our code reviews in like

2 or 3 minutes you get two people to

look at it smoke test maybe and be like

okay cool looks good to me if it's

broken in production we'll just fix it

later so that's scaling the team now how

do you scale the

tech don't think too hard about the tech

the tech is it's kind of the easiest

part of scaling a business for the most

part you're just solving known you're

solving known problems with known

Solutions um this is in how big things

get done this is a really good book it's

not about software engineering but it's

about large scale engineering projects

and it talks about how China is able to

ship a bazillion Bridges and power

plants per year whereas the USA isn't

and the main factor they talk about is

that in China they have like 10 standard

designs for everything and then the

engineers come in look at the situation

and just pick the most appropriate

design to apply to that situation and

then here's the thing they tweak the

situation to fit the design they don't

tweak the design of an off the shelf

component to fit the situation it's the

other way around change the problem so

it fits the solution you already have

and that way you can build much faster

and you're saving your Innovation tokens

for the things that are actually new and

differentiating in your

company which brings us to just solve

the problem not a different more

difficult problem uh the hardest thing

to do in software engineering is to

build a generic solution especially when

all you have is a specific problem it

is generally a good idea or rather I'll

say it this way the older I get the more

my code looks like a a very simple

step-by-step process it doesn't impress

anyone it's super boring to look at and

honest personally I think the biggest

compliment you can get on your code is

when somebody looks at it and goes wait

that's it if damn right that's it it is

simple it's easy to understand and it's

easy to maintain because you always have

to push back on

complexity um engineering is an endless

fight against complexity and

sometimes that means saying no to an

architecture as astronaut who's trying

to build a generic framework to solve a

problem forever when you just need you

know we need to ship this code tomorrow

we don't need we don't even know yet

what we're building in 10 days and

you're trying to build a framework just

fix the problem solve it uh and move on

and it this also means that again

because you understand your domain

because you have long-term ownership of

the stuff you're building you can push

back on your product as well on your

product managers very often you have

like One requirement that blows up the

entire story and makes it way harder

than it needs to

be you can usually push back on your pm

and be like hey this one thing is making

is making our work a lot harder and

they'll go oh yeah no we don't

actually need that we don't care just

drop that requirement and now you can

use a very simple solution

and where most complexity comes from in

a software engineering project is not

actually the code you're writing it's

the architecture you're creating so if

you think about your code as a series of

interconnected boxes the boxes are uh

like your code those are like those are

classes modules Services whatever you

want to call them and the lines are how

they talk to each other the more

connected these lines are the more the

more intertwined everything gets the

more complex it is and and one lesson

that I've learned is that you can always

change how a self-contained box works

you can rip out all of the code and

write new code that's cleaner or better

or whatever but it's very hard to change

those

connections

and uh one way to to limit that

complexity is to use vert to organize

your code vertically instead of

horizontally so instead of splitting

components hooks types utils or

uh or whatever you have in your uh I I

don't know what stack you use but if you

if you instead split your code by

everything that goes into a dashboard

anything that goes into a user profile

into a to-do list you then have modules

or like you have boxes that aren't as

intertwined and it's those clear apis

that make everything easier so one trick

I like to use is to use type driven or

for contract driven development where we

ahead of time we talk about what are the

different moving pieces of a story we're

building and then we talk about how

they're going to talk to each other and

then everyone who's writing the code is

empowered to build the internal

implementation whatever way they

want unfortunately or

fortunately um using vertical vertical

modules May mean that you will have to

copy paste some code and this is

probably one of my most uh controversial

takes is that drying code do not repeat

yourself is actually bad and whenever

possible you should lean on separation

of concerns more than you do on drying

up your code because when you dry up

your code your architecture ends up

looking like this uh if you dry it up

too much everything is overlapping you

get components or services that get that

take 10 billion parameters to configure

their uh their Implement their behavior

and you change one thing over here and

suddenly something completely different

that you weren't even thinking about

breaks that when that's happening to you

that means that your I'm running

out of time that means that your code is

interconnected in a way that uh that

causes problems for you so one of the

things that uh one of the things that I

like to focus on especially when talk

talking about architecture is to focus

on your data and your data structures uh

how you organize data in your database

how you organize data access patterns uh

stuff like that because it turns out

that when you get the data right your

code is so easy to implement that it

almost feels like you have nothing to do

all day and when you get your data wrong

when it doesn't fit your domain model it

feels like you have to keep bending over

back WS to make things fit together and

that is why you want to write ver you

want to use vertical teams that write

vertical code because it means that you

as a team are in control of your API in

control of your data in control of your

UI and you get to design everything so

that it fits together solves your

problems uh and not some generic straw

man that you find on the internet uh and

people are talking about

so that was my talk uh I'm turning all

of this into a book uh if you use that

QR code you can learn more about what

I'm doing and um thank you

[Music]