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
• 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