Next week I'm giving a talk about Scaling Fast: Engineering lessons learned from tech startups at C3 Fest in Amsterdam. Decided to publish my notes because they look pretty useful on their own. Although I hope my stage presence adds a little something something. Enjoy :)
- hook: your users are going 🏒 now what?
- pic of a hockeystick graph
- you need to scale 3 things
- business
- team
- tech
- scaling the business is simple, but hard
- more sales
- higher price
- beware the S-curve
- pic of S-curve
- every business hits a ceiling when growth and churn balance out
- you then need to figure out something new
- linear growth (adding same N users per time unit) will never work long-term
- why this matters?
- this is your fuel
- CAC + LTV = salaries and all
- transition slide
- gif of gromit laying track in front of train
- while all this business stuff is happening, you’re trying to keep up with tech
- DONT BE THE BOTTLENECK
- scaling the team
- like this (vertical teams), not like this (horizontal teams)
- this is a sketchy sketch
- different names for this concept
- empowered teams
- stream aligned teams
- business capability centric teams
- always the same goal – deliver value without being blocked
- like this (vertical teams), not like this (horizontal teams)
- a team should
- own their destiny
- own their mess
- understand their domain
- Get us across the water, not build us a bridge
- pic of empowered team
- Involve engineers early, they understand the domain
- Set goal, let team execute
- you have lots of smart engineers, use them
- Delegate decisions, not just tasks
- person closest to the problem knows best
- it feels good to be needed, but you can’t scale if 1 person is the bottleneck
- this goes fractally up and down the org
- build trust, then start taking decisions off their plates
- work in progress kills your progress
- obsess with getting things to done
- measure PR time in minutes
- merge straight to main
- deploy many times per day
- keep it all integrated
- large discussions in PR are way too late - collaborate early - agree on the design before you write the code - shift left!
- what about the tech?
- in a way, tech is the easy part
- 90% of the time you’re solving problems with known solutions
- don’t overthink the tech
- the older I get, the more my code looks like a step-by-step recipe
- use off-the-shelf solutions where possible
- adapt to your tools rather than reinventing
- save your innovation tokens for differentiators
- just solve the problem, not a different more difficult problem
- biggest source of WIP and slow-downs is solving a bigger problem than you need
- focus on what’s in front of you
- aggressively cut anything that isn’t strictly required
- make followup tickets
- if any one requirement blows up complexity, push back
- be a good partner to product
- you’re the inputter
- they’re the decider
- you know best when something is easy or super hard
- push back and you’ll be surprised how often the answer is “Oh, not worth it then”
- prioritize architectural complexity
- how your boxes connect matters more than how clean your boxes are
- you can fix an isolated box
- you can’t detangle a rat’s nest
- use vertical modules
- like this, not like this (similar pic to earlier teams)
- orient your code on the business domain
- not on the tech it uses
- what does it do? forget the how, that will change
- you can call these services, microservices, modules in a monolith, components in the UI, internal libraries, or whatever else you want
- doesn’t matter. Just keep them separate and use clear APIs!
- DRY is the root of much evil
- better to have extra code you’ll merge later
- than to have diverging concepts that are tied at the hip
- don’t entangle code just because it looks similar right now
- get your data right
- "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
- "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -Linus Torvalds
- code can come and go, but data is forever
- the right data makes your code easy
- the wrong data makes you do awful things in the code
- that’s why vertical teams and code!
- when your teams own their destiny
- they can design the data and the code to work together
- no weird handoffs and APIs that don’t quite do what you need
- building software is like kicking a can
- you’ll never know exactly what you need until you try
- product development is a cycle
- fast feedback loops beat big up-front design
- only universal engineering rule
- make it work
- make it right
- make it fast
- first get something out there, when you know it’s doing the job clean it all up, then look for performance hotspots and fix those
- thanks
- go here for book: boop
Cheers,
~Swizec
Continue reading about Notes for my Scaling Fast talk next week
Semantically similar articles hand-picked by GPT-4
- Can I get your opinion
- You do have time to build it twice
- When to join and leave a company, project, or trend
- The 3 types of scalability
- What I learned from Software Engineering at Google
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails đź’Ś on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. đź‘Ś"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️