Notes for my Scaling Fast talk next week
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