Learn how to reinvent yourself when your startup enters the scale-up phase. #startups #scaleups #growth #pitfalls

1. SCALE-UP
GROWING PAINS

2. SCALE-UP
GROWING PAINS
How to reinvent
yourself when entering
the scale-up phase
H O W T O E A S E

3. WHOAM I?
3

4. MARC VAN NEERVEN
Chief Technology Officer
4
https://linkedin.com/in/mvneerven/
https://medium.com/cto-as-a-service
1992: Founder of Startup avant-la-lettre
1992: Lead Developer, Software Architect
1996: Enterprise Software Architect
2012: Cloud Solution Architect
2013: Chief Technology Officer
2017: CTO-as-a-Service

5. NEERVENTURE.COM PORTFOLIO
5
Company Types
• Startups in Every Phase (Ideation to pre-scale-up)
• Scale-ups
• ISVs
• Corporates
Engagement
• CTO-as-a-Service
• Strategic Advice
• Prototypes & Proof-of-Concepts
• Audits/Quickscans

6. THE DOMAIN OFTHE
CHIEF TECHNOLOGY OFFICER
Strategy, Strategy, Strategy!
6

7. WHOARE YOU?
7

8. Scaling up is like jumping directly
from childhood to parenthood,
skipping important phases of your life.
The play is over.
It’s serious business,
with serious responsibilities.
“
”

9. Ideation
Startup
Scale-up
AGENDA
9
COMPANY
STRUCTURE &
CULTURE
DEVELOPMENT
TEAM & PROCESS
ARCHITECTURE &
INFRASTRUCTURE
PRODUCT
DESIGN & ROADMAP
1
2
3
4

10. COMPANY
STRUCTURE &
CULTURE
Time to lose a
few habits
10
1

11. GROWTH CHANGES TEAM DYNAMICS
11
• Team Imbalance is lurking
• Roles need to get more Focused
• Reporting Lines may need to be adjusted
(carefully - potential trouble ahead)
• Split Conflicting Roles
• CTO ≠ (any Agile role)
• Lead Dev ≠ CTO ≠ CIO
• PO ≠ CTO
• PO ≠ Developer
• CEO ≠ PO ≠ HR ≠ COO (more later)
COMPANYSTRUCTURE&CULTURE

12. BEAWARE OF CHANGING DYNAMICS
12
• Risks when hiring more Juniors
• Coaching role may not suit every senior
• Issues with (perceived) Productivity
• Junior/senior Imbalance
• Risks when hiring more Seniors or changing Reporting Lines
• Team Members Feeling Undervalued
• Negativity
• Toxicity
COMPANYSTRUCTURE&CULTURE

13. QUIT STARTUP HABITS
13
• Re-evaluate Opportunistic Decisions
• Most early Startup decisions are extremely pragmatic
… but might hurt later on
• CEO/Founder roles need to change
• A Pioneer is (mostly) not a Manager
• Quit being the go-to-point for everything
• Hire Operational Manager?
• HR & Hiring Strategy
• Be clear about your Core Values
• Keeping developers Loyal is crucial but complicated
It’s a buyers’market
• Recruiters & Headhunters are a Reality to deal with
• Give your people a realistic Growth Path
• Care for a good Team Culture
COMPANYSTRUCTURE&CULTURE

14. TEAM CULTURE IS CRUCIAL
14COMPANYSTRUCTURE&CULTURE

15. TEAM CULTURE CAN BE INFLUENCED
15
• Make communication a priority
• Reinforce the Important Ideas consistently
• Show the Bigger Picture to Everyone!
• Help everyone understand how they contribute
• Value everyone’s Ideas
• Trust your team
• Let team members get to know each other outside work
• Have some Fun!
• Disrupt the all-male culture
It works ;-)
• Empathic, Facilitating Leadership
Instead of Directive Management ➔ How can you make people thrive?
• Promote a Culture of Learning
COMPANYSTRUCTURE&CULTURE

16. DEVELOPMENT
TEAM & PROCESS
Take it to the
Next Level
16
2

17. VALUE & EXIT STRATEGY
17
• Potential investors or purchaser will do Due Diligence on your company,
and they will look very closely at your Intellectual Property.
• Maintain focus on Intellectual Property through the entire life of the
business.
• Negligence in protecting IP influences the Selling Price.
…but…
What does this have to do with Team & Process?
DEVELOPMENT TEAM&PROCESS

18. IT’S THE IP, BABY
18
• Insource & Outsource pieces of Software Development based on…
DEVELOPMENT TEAM&PROCESS
YES NO
Insource
(if possible)
Outsource,
Contract,
Partner
One Simple Question:
Is Intellectual Property involved?

19. NOT EVERYBODY KNOWSAGILE ENOUGH
19
A few reminders about Agile…
Why work Agile?
• Decrease Time-to-Market
• Accelerate Product Delivery
• Improve Effectiveness to manage changing priorities
• Enhance Software Quality
• Enhance Delivery Predictability
• Improve Project Visibility
• Reduce project Risk
DEVELOPMENT TEAM&PROCESS

20. HOW TO DOAGILE?
20
There is no single “right” way
Agile Manifesto’s Values & Principles:
• Effective interaction between people is critical to any project success.
• Teams should be trained together, undergo deliberate team formation, and be
given the time to understand what it means to work in an Agile fashion.
• Do not underestimate the need for and impact of customer collaboration and
response to change.
• Trust of and within the team.
DEVELOPMENT TEAM&PROCESS

21. THE MOST IMPORTANT AGILE ELEMENTS
21
• The Rituals (ceremonies)
• Sprint Planning
• Daily Stand-up
• Iteration Review/Demo
• Retrospective
• Keeping Stakeholders Close
• Continuous Feedback
• Product Backlog is a Living Document
… and you need a dedicated PO (more…)
DEVELOPMENT TEAM&PROCESS

22. DEDICATED PRODUCT OWNER (PO)
22
• Product Backlog
Prioritized features list for the product
• User Stories
As a < type of user >, I want < some goal > so that < some reason >.
• Definition-of-Done
Consistent acceptance criteria across all User Stories
• Backlog Refinement (grooming)
• Removing user stories that no longer appear relevant
• Creating new user stories in response to newly discovered needs
• Re-assessing the relative priority of stories
• Assigning estimates to stories which have yet to receive one
• Correcting estimates in light of newly discovered information
• Splitting user stories which are high priority but too coarse grained to fit in an upcoming
iteration
DEVELOPMENT TEAM&PROCESS

23. CODE NEEDS TO SCALE TOO (1/2)
23
• The acronyms ;-)
DEVELOPMENT TEAM&PROCESS

24. CODE NEEDS TO SCALE TOO (2/2)
24
• Sustainable Code Base
• SOLID principles
• Clear Separation of Concerns (SoC)
• Modular / Reduced Complexity
• Require Documentation
• Unit Testing
• Reduce Technical Debt (structurally)
• Isolate Core and Integrations
• Attention to Non-Functional Requirements
Such as Robustness, Reusability, Fault-tolerance, Stability, Resilience…
DEVELOPMENT TEAM&PROCESS

25. CONTROL YOUR SH*T
25
• Quality Assurance & Control
• Peer Reviews + Peer decision making
• Testing at all levels
• Deployment (CI/CD)
• Technical Governance (CTO)
• Security
• Compliance
• GDPR/AVG
• SLAs
DEVELOPMENT TEAM&PROCESS

26. DOCUMENTATIONAND KNOWLEDGE SHARING
26
• Documenting is Developers’ least favorite activity
• Documenting has proven to improve software!
Especially if done early!
• Everyone’s responsible, everyone should contribute!
• Make Inline Documentation in code mandatory → DoD
• Implement a good Knowledge System
Consider a Wiki (such as Confluence)
• Implement Review Dates & Workflows
• QA is end-responsible
• CTO oversees & implements Governance
DEVELOPMENT TEAM&PROCESS

27. ARCHITECTURE &
INFRASTRUCTURE
Scaling to
Scalability
27
3

28. RECONSIDER YOURARCHITECTURE
28
• Don’t keep building on top of a Prototype/PoC
• Architecture & Release Platform are interdependent
Cloud is not just an alternative
Infrastructure!
ARCHITECTURE&INFRASTRUCTURE

29. CLOUD SOLUTIONS: REDUCED RESPONSIBILITIES
Focus on your Applications and Data
29ARCHITECTURE&INFRASTRUCTURE

30. CLOUD SOLUTIONS:A DIFFERENT SPECIES
You better adapt!
30
Traditional on-premises Native Cloud
Relational database Polyglot persistence
Strong consistency Eventual consistency
Design for predictable scalability Design for unbound scalability
Serial and synchronized processing Parallel and asynchronous processing
Monolithic, centralized Decomposed, de-centralized
Snowflake servers Immutable infrastructure
Integrated authentication Federated authentication
Design to keep app running (MTBF) Design for failure (MTTR)
Onetime big update Frequent small updates
Manual management Automated self-management
ARCHITECTURE&INFRASTRUCTURE

31. POLYGLOT PERSISTANCE
31
• Data is part of the architecture!
• Bottlenecks are often related to Storage
• Relational Databases are not Self-Evident anymore
• Consider Polyglot Persistance
• RDBMS (SQLServer, Oracle, MySQL, Postgres, etc.)
• Document Databases (Mongo, Cosmos/DocumentDB, etc.)
• Graph Databases (Neo4J, )
• Cache (Redis)
• Search Databases (ElasticSearch/Lucene, Solr, etc.):
• Binary Storage (Blob, etc.)
• Row Stores (TableStorage, etc.)
• Take Use-Cases into account for Choice of Storage
Transactional, high read throughput, high consistency?
ARCHITECTURE&INFRASTRUCTURE

32. AFEW CONSIDERATIONS
32
• Modularize!
(Micro)services, data layers, REST, etc.
• Use PaaS/Serverless where possible
(Avoiding Cloud lock-in doesn’t prevent that)
• Leverage ready-to-use Intelligent Cloud Services
• Remove Bottlenecks & Single Points of Failure
Queues, Cache, Events, etc.
• Think Async
The Mobile Revolution’s impact
• Invest in an integrated deploy pipeline
Only possible if you first invest in structural testing!
ARCHITECTURE&INFRASTRUCTURE

33. PRODUCT DESIGN
& ROADMAP
Circular
Thinking
33
4

34. AGILE ROADMAP
34
• Domain Knowledge is essential!
• In Agile, a product roadmap as a Statement of Intent
• Evaluate the Role of Time for your roadmap
• Remember the Audience of your agile product roadmap
and tailor to them
• Make it visible within the whole Team
PRODUCTDESIGN&ROADMAP

35. DESIGN THINKING
Continuous Loop
35PRODUCTDESIGN&ROADMAP

36. MAKE UX LEADING
36
• Personas ➔ Journeys ➔ Flows
• Storyboarding
• Use/Create a Modular Design System
Atomic design
• Use modern UX Tooling
Clickthrough Prototypes
PRODUCTDESIGN&ROADMAP

37. INVEST IN FEEDBACK LOOPS
37
• Direct Feedback about your product, preferably contextual.
• Take feedback serious and use it in for Continuous Improvement
(Design Thinking)
• Continuous Measurement of interaction with the product,
all feeding back into design and development.
Booking.com A/B ➔ Conversion ➔ auto-deploy
PRODUCTDESIGN&ROADMAP

38. QUESTIONS?
38

39. THANK YOU
Marc van Neerven +31 6 246 150 38
cto@neerventure.com
https://neerventure.com
39