From Zero to Unicorn - Scaling Engineering Teams :: DevDaysEurope 2022

1. Scaling Engineering Teams
From Zero to Unicorn
by Pedro Gustavo Torres
DevDays
Europe 2022

2. Hello there!
Unicorn
“meter”
(10x)
Senior Engineering Leader
Leading Engineering for 14 years
Portuguese living and working from Portugal
CTO Portugal co-founder
Investor and Advisor
Star Wars and Lego fan
2015
2018
2022
(IPO)
Pedro Gustavo Torres

3. Disclaimer
This is what I’ve observed throughout my career and so it is not an absolute truth.
The way series are used here are for the sake of separation of stages.
It’s perfectly natural that different startups had different trajectories.
This is a work of fiction. Names, characters, business, events and incidents are the products of the
author's imagination. Any resemblance to actual persons, living or dead, or actual events is purely
coincidental.
No animals were harmed in the making of this presentation.

4. From Zero to Series A
Market fit and validation stage

5. Engineering team size
Very small (maybe a handful of engineers)
Creation of the Tech Lead role
Founder(s) still very active on the day to day of the engineering team (acting as CTO, CPO
or VP)
From Zero to Series A

6. YAGNI
YAGNI - You Aren't Gonna Need It
YAFAANG - You Aren’t Facebook, Amazon, Apple, Netflix, Google
YAMAANA - You Aren’t Meta, Amazon, Apple, Netflix, Alphabet
From Zero to Series A

7. Throwing money to the problem (and saving you time)
“Everything else” as a service
Scaling vertically
From Zero to Series A

8. Which tech stack to use?
Ruby, Python, something that runs on the JVM, .Net Core, etc.
Heroku, AWS/GCP/Azure with managed services
From Zero to Series A

9. Keeping it real and avoiding solving non problems
Forget about being afraid of “vendor lock in”, or planning for “multi cloud” and other things
that will only slow you down
From Zero to Series A

10. You are probably going to start with some sort of Scrum
The Agile process is super rigid
You might hire an Agile Coach
The beginning of your Agile process
From Zero to Series A

11. Biggest Advice
Forget about perfection and great engineering designs… this is the quick and dirty stage
From Zero to Series A

12. From Series A to Series B
Prepare to scale stage

13. Engineering team becomes bigger
Teams of 20 to 80 engineers
Do you need QAs?
Hire Engineering Managers (and Product Managers and Product Designers)
Solve the Tech Lead role (Should it stay? Should it be Staff Engineer? Should it be Engineer
Manager?)
Tailor your hiring process to meet your needs (mostly about optimize time-to-hire)
From Series A to Series B

14. Engineering culture
Assuring consistency of practices (e.g. unit testing, coding standards, test coverage),
principles (e.g. YAGNI, DAMP, SOLID, WET, BDUF, SOC) and values (e.g. Ten
commandments of egoless programming) is fundamental to a healthy engineering culture
From Series A to Series B

15. Goodbye (or not) monolith
Create independent systems (nano/micro/medium services)
Put the monolith on a “diet” (i.e. create plans to extract functionality)
Create the master plan™ to end the monolith (and start failing executing it)
Have databases per service / responsibility
From Series A to Series B

16. The career ladders and performance reviews
“Y shaped” ladder
“T shaped” engineers
360 feedback and competencies (not people) ratings
From Series A to Series B

17. The on-call program
From: one or two engineers carrying the pager and asking for help to the ones that, by
chance, are playing online at night
To: shifts implemented (e.g. daily, weekly), pager rotations, etc.
From Series A to Series B

18. From Horizontal to Vertical teams
Feature teams
Data team
Platform team
Mobile team
DevX team
Security team
From Series A to Series B

19. Avoid reinventing the wheel
Or the “not built here” syndrome
From Series A to Series B

20. The rise Engineering Blog
The idea of having an Engineering Blog always emerges… and maintaining it seems so easy
From Series A to Series B

21. The Agile process evolves
Scrum gets more “perfected” (meaning too much attention to “vanity metrics”)
Some teams move to Kanban (to avoid the metrics mentioned above)
Different schools of thought regarding estimates (e.g. time, points, throughput)
You might hire more Agile Coaches
The Agile process is less rigid (with teams having autonomy to do as they see fit)
From Series A to Series B

22. Biggest Advice
You really need to start thinking about processes that help you scale… otherwise you’ll face
the infamous “growth pains” or how I like to simply to call it: lack of preparation
From Series A to Series B

23. From Series B to Series C
Scaling stage

24. Engineering team size
Something around the 100+
There are always teams onboarding engineers (stuck in the first two stages of Tuckman’s
model: forming and storming)
Clear need for Engineering Directors/Head ofs (and Product Directors and Product Design
Directors)
From Series B to Series C

25. The introduction of Clusters
Clusters are a teams of teams
Grouped by parts of the product, personas, scope, ideally not by technology or part of the
stack
Bonus points for not using the name that the “Spotify model” uses: Tribe
From Series B to Series C

26. The introduction of Communities of Interest
The best way to assure consistency and shared best practices in several topics (e.g.
frontend, backend, testing, architecture, tech talks) across the engineering group
Bonus points for not using the name that the “Spotify model” uses: Guild
From Series B to Series C

27. Avoid creating the Architecture role and/or team
The architecture is owned by the engineering teams … not by a single person or even a
team that don’t have “skin the game”
Don’t create a tech radar… leave that to Thoughworks… it’s free!
From Series B to Series C

28. The more engineers you have the broader schools of thought you are going to have
Common sentence heard: “Coding language XXXX is rubbish and we should use coding
language YYYY instead because it would solve all our scale problems”
Strong opinions weakly held
Avoid reevaluating the entire tech stack
From Series B to Series C

29. OKRs or V2MOMs
Adopt tools to help you measure focus and create a shared understanding of your goals
From Series B to Series C

30. The DORA metrics
Measure only what matters
Peter Drucker: “What is measured improves”
Peter Drucker: “If you can’t measure it, you can’t manage it”
Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.
From Series B to Series C

31. Start using SLOs and SLIs
Reliability is more important than features
I rather have fewer features working all the time than multiple features working some of
the time
Keep in mind Pareto’s principle: you take 80% value out of 20% of your features
From Series B to Series C

32. Churn starts to kick-in
The pioneers usually don’t see themselves in the company culture and size anymore
A lot of the people that joined for reason “lorem ipsum” start to leave
A new kid on the block arrives
From Series B to Series C

33. The fall of the Engineering Blog
It’s way harder to maintain than it seems
From Series B to Series C

34. Lot’s of resiliency work
Infra as code
Systems migrations (e.g. databases, message/streaming systems)
Implement Avro, Protobuff, etc
Be more conservative regarding the usage of NoSQL databases (e.g. Mongo)
Disaster recovery, multiple availability zones, etc
From Series B to Series C

35. Remember the monolith?
Continue to fail at “killing” the monolith
Continue to create systems around it
From Series B to Series C

36. The Agile process looks like a “Beyond Agile” approach
Each team evolved the process to something meaningful to then
The delivery of the teams is better than ever
Difficult to find common team metrics (but are those really important?)
From Series B to Series C

37. Biggest Advice
Don’t disregard the evolution of your culture… and the sense of belonging… with scale
these two require a lot of nourishing
From Series B to Series C

38. From Series C to Unicorn
Paving the road to IPO stage

39. Engineering team size
Something around the 200+
From Series C to Unicorn

40. The introduction of PLTs (Product Lines)
PLTs (a.k.a. Business Units) are mini startups inside your org
Usually a mix of vertical lines (parts of the Product) with horizontal lines (e.g. Platform,
Infrastructure)
From Series C to Unicorn

41. Measure Business Outcomes
Business outcomes is much more powerful than any other metric
From Series C to Unicorn

42. Approach to compensation
Market alignment (with +% that you are willing to pay above it)
Anchors and not per individual negotiation basis
Fairness amongst engineers
Compensation is more “honest” and less “creative”
From Series C to Unicorn

43. Very little incidents / high reliability
At this stage the impact of an incident is very costly
From Series C to Unicorn

44. Ex-”yourcompany” on LinkedIn headlines
With success bragging is a natural consequence
From Series C to Unicorn

45. What about the monolith?
Will continue to be a vital system no matter what
A couple of people quitted because of the (failed) attempt to “kill” it
From Series C to Unicorn

46. The Agile process supports Predictable delivery
Planning per quarter (and not specific dates)
Have quarterly launches
Usage of meaningful team metrics (e.g. % of time in roadmap, bug fixing, tech investments)
From Series C to Unicorn

47. Biggest Advice
This is the stage of returning to “reality”... as in… it’s not “just” about scaling but also proving
to the investors that the company, in the future, can operate as a public company
From Series C to Unicorn

48. Scaling Engineering Teams
DevDays
Europe 2022
Thank you! Ačiū!