Revolut is known for its fast product development. Vaidas learned the way they work while leading Revolut Business. They did not "use LeSS". But for sure they used many practices that LeSS advocates for. When he joined Uncapped as a Chief Product Officer, he had a chance to build organizational structure, culture, and ways of working from scratch. Vaidas summarized it in this article early days of this journey. In this talk, he will share more details of the lessons learned, LeSS practices they used (without calling them LeSS), and why everyone willing to build a Unicorn should learn LeSS as early as possible.

1. 1
LeSS to Scale
Unicorns
experiences from Revolut
and Uncapped
Vaidas Adomauskas
2022-09-23
LeSS conference, Warsaw

2. 2
How many unicorns
are out there?

3. 3
https://news.crunchbase.com/unicorn-company-list (2022-09-18)
1403
companies

4. 5
Which Agile scaling
framework do
unicorns use?

5. 6
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

6. 7

7. 8

8. 9
Context:
Revolut & Uncapped

9. 10
Customers:
● Consumers: 7M -> 15M -> ±20M
● Businesses: 200k -> 0.5M -> ±1M
Employees:
● Total: 1.3k -> 2.2k -> ±5k
● Business product team: 70 -> 150 -> ?
Distributed: London, St. Petebourg,
Moscow, Vilnius, Berlin, Krakow.
www.revolut.com

10. 11
Employes: 20 -> 120
Product team: 10 -> 55
Fully remote: Five Lessons Learned Fully
Remote, while scaling from 20 to 120+
www.weareuncapped.com

11. 12
The Million Dollar Question:
How do you Scale a
Multi-Product Business?
https://www.linkedin.com/pulse/million-dollar-question-how-do-you-scale-business-vaidas-adomauskas/

12. 13

14. 15

15. 16

16. https://www.slideshare.net/vaidasa/agile-and-agile-methods-what-is-the-most-important-to-understand-to-succeed 17

17. 18
Decentralisation (2019) -> centralisation (2020) ->
decentralisation (2021) -> ?
ROI = revenue / cost
Revolut

18. 19
Example: build (new) banking services:
• Build basics fast -> optimise for delivery (even with bugs)
• Fix based on data -> optimise for quality (fix bugs, optimise UX…)
• Add value -> optimise for learning (customer interviews, pains, gains…)
Uncapped

19. 20
Execution = what2 *
how

21. 22
What structure was the
most fun and efficient
you worked in?

22. 23
Startups within startup

23. 25
“Culture follows structure” -
systems-thinking thought leader John Seddon
“Attempting to change an organization’s culture is a
folly, it always fails. Peoples’ behaviour (the
culture) is a product of the system; when you
change the system peoples’ behaviour changes.”
https://less.works/less/structure

25. Product Owners - CEOs
29
1. Product Owner (as defined in Scrum Guide)
1. Visioner and leader (aligned with company/founders vision)
1. Line manager (team member’s career and development goals)

26. 30
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

27. 31
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

28. 32
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

29. 33
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

30. 34
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

31. 35
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

32. 36
KPIs - quarterly + yearly
• Company, department, team (POs accountable)
• Business numbers driven
• Attached bonuses - WARNING!!!
Revolut

33. Uncapped
37
OKRs - quarterly + 12 months rolling
• Company Objectives - mostly cross-department
• Key Results business numbers driven - owned by teams (POs
accountable)
• Prioritised - as we had more than advised - WARNING!!!
• Alignment tool - not used for performance management

35. Functional managers
39
1. Hiring: skills interviews
1. Development: 1:1s, reviews etc., shared competency matrix
1. Performance reviews & promotions: 50/50 split with PO (line
manager)

37. Splitting teams at high growth stage
43
1. Hire into existing team
1. Split team when >±9
1. Hire into both teams till ±7 (avoid small teams)

38. 44
1. Build co-located teams to build new products failed - WARNING!!!
1. Splitting teams too early failed (many too small teams) -
WARNING!!!
Revolut

40. Additionally to each team ceremonies
47
1. Weekly prioritisation: one company backlog
1. Weekly design review: one design system
1. Bi-weekly product demo: continuous delivery
1. Bi-weekly retrospectives: continuous improvement
1. Weekly operational meeting: operational topics

41. Direct, candid opinions and discussions are key
48

42. 49

43. 50
Were we “doing”
LeSS?
https://less.works/less/rules
(Structure, Product, Sprint)

44. LeSS Structure
52
• Structure the organization using real teams as the basic organizational building block.
• Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.
• The majority of the teams are customer-focused feature teams.
• Scrum Mastersare responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product
Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system.
• A Scrum Master is a dedicated full-time role.
• One Scrum Master can serve 1-3 teams.
• In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product
work to improving the value-delivering capability of the product development system.
• Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over
conformance.”
• For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption.
• For the larger organization beyond the product group, adopt LeSS evolutionarily using Go and See to create an organization where
experimentation and improvement is the norm.

45. LeSS Product
53
• There is one Product Ownerand one Product Backlog
for the complete shippable product.
• The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with
customers/users and other stakeholders.
• All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and
customer/users and other stakeholders.
• The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might
expand. Broader definitions are preferred.
• One Definition of Done for the whole product, common for all teams.
• Each team can have their own stronger Definition of Done by expanding the common one.
• The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).

46. LeSS Sprint
54
• There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated
whole product.
• Sprint Planning consists of two parts: Sprint Planning Oneis common for all teams while Sprint Planning Two is
usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items.
• Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on that
Sprint. The Teams identify opportunities to work together and final questions are clarified.
• Each Team has their own Sprint Backlog.
• Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs.
• Each Team has their own Daily Scrum.
• Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal
networks via communicate in code, cross-team meetings, component mentors, travelers, scouts, and open spaces.
• Product Backlog Refinement (PBR) is preferably done with multiple teams to increase shared learning and to exploit coordination opportunities.
• There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the information needed for effective inspection and
adaptation.
• Each Team has their own Sprint Retrospective.
• An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by
Product Owner, Scrum Masters, Team representatives, and managers (if any).

47. 55
Wrap up
More with LeSS

48. 56

49. Takeaways
57
1. LeSS (LeSS is more) is very well suited for scaling high growth companies
1. Many unicorns are using structures similar to LeSS, but… work those out
organically
1. Huge opportunity for LeSS community to be more active within unicorns
1. Huge opportunity for high-growth companies to avoid “reinventing the
wheel”

50. 58
Who will share the next
LeSS story from high
growth company?

51. 59
Thank you!
Vaidas Adomauskas
www.agilecoach.lt