As your business grows, it becomes necessary to expand the teams within your organization to maintain productivity at an optimal level. Business and Technology team growth are not interdependent. As software products need regular revision and improvements to benefit your business and boost company scales, technology team scaling is inevitable to boost the growth and development of your business. However, it is critical to pick the right time, model and organizational structure to start scaling your product and technical teams, so as not to fail this process overall. Technology Team Structure and Organizational Process Technology Teams Separation of Concerns Technology Team Budget and Scaling Models Appropriate Technology Team Separation, Reporting and Relative Headcount Technology and Business Team Engagement and Collaboration

1. S E R G E Y S U N D U K O V S K I Y P H . D .
Scaling Technology Organizations
1

3. 3
Agenda

4. Debt Management
4

5. CEO/CTO Story
I Have Not Seen Organs Like These
5

6. Common Story
 CEOs Tale
 We Were Very Productive
 We Kicked Butt
 We Became Complacent
 I Fired Them All
 I Hired a New Team
 They Are Not Productive Either
 Must Have Chosen Wrong
 I Fired Them All
 SAVE ME
6

7. Common Story
 CTOs Tale
 We Were Very Productive Through Debt Accumulation
 We Kicked Ass But Burned Out
 We Slowed Down Due to Debt
 We Got Fired
 New Team Got Hired
 It Does Not Know Where Skeletons Are Buried
 We Got Fired As Well
 I have Not Seem Organs Like These
7

8. Support to Innovation Ratio
You Are in the Support Business
8
Support
(15%)
Innovation
(85%)
Support
(50%)
Innovation
(50%)
Support
(85%)
Innovation
(15%)
Year 1
Year 2
Year 3

9. Broken Window Theory
One Broken Window Leads to Ruin
9

10. Broken Window Theory
Do Sweat the Small Stuff
10

11. Debt Tipping Point
11
Product Death
Year 2
Year 1
Tipping Point

12. Snowball Effect
12
No Turning Back
Now!
SPLAT!

13. Technical Debt Elements
 Technical Debt Elements
 Lack of Architectural Blueprint
 Lack of Unit Testing
 Lack of CI/CD Process
 Lack of Code Reviews
 Lack of Starting Platform
 Lack of Starting Framework
 Monolithic Design
 Lack of Development Recipes
13

14.  Schedule feature holidays
(every 5th release)
 Refactor as you go
 Make debt mitigation as part of
the process
 Give estimates considering
debt mitigation
 Invite outside experts
14
Technical Debt Mitigation

15. 15
Teams Separation of Concerns
Architecture Development Dev OPS QA/Automation OPS
Product
Architecture
Server
Development
Environment
Provisioning
Manual Testing Security
Management
UI
Architecture
UI
Development
Source Control
Automation
Functional
Testing
Production
Monitoring
System
Architecture
API
Development
Continuous
Integration
Test Automation Infrastructure Cost
Management
Recipe
Development
3rd Party
Integrations
Continuous
Delivery
Performance
Testing
Problem Alerting
Product Spikes Unit Testing Access Control Stress Testing Scalability
Management

16. Team Structure
Big Rocks First
16

17. Separate Development Teams
17
Rapid Development vs. Core
VS.

18. Work Separation
18
 Core Development
 Core Platform Project (3+ months)
 Rapid Development
 Bug Fixes (2 weeks)
 Small Enhancements
 Small Features
 Client Development
 Client Specific Enhancements

19. Organizational Structure Debt Elements
 Organizational Structure Debt Elements
 Adhoc Organizational Structure
 Lack of Separation of Concerns
 Lack of Specialization
 Lack of Cross-Training
 Lack of Career Management
19

20. Process Debt
How Do They Know?
20

21. Process Complication
Do Not Make It Complicated
21

22. Process Complication
 Do Not Make It Complicated
 Complicated = Bad
 Complicated = Unsustainable
 Complicated = Not Followed
 Complicated = Edge Case Centric
 Complicated ! = Useful
 Complicated = Unintended Consequences
22

23. Planned vs. Agile
23
VS

24. Planned vs. Agile
 Planned Process
 Exhaustive Planning (plan until you are exhausted)
 Prescriptive
 Document Centric
 Agile Process
 Iterative Planning
 Non-prescriptive
 Practice Centric
24

25. Agile Umbrella
25

26. Process Debt Elements
 Process Debt Elements
 Lack of Articulated Process
 Lack of Process Documentation
 Lack of Repeatability
 Lack of Clear Process Identification
 Presence of Numerous Process Exceptions
 Process Busters
26

27. False Agile
Just Because You Call It Agile It Does Not Mean It Is
27

28. You Are Not Agile If
 Requirement Frontloading
 QA Backloading
 You Move Dates Instead of Feature Negotiating
 You Extend Sprints/Iterations
 You Are Not Producing Code by Third Week of the Project
 You Have No Business Representation
 You Are Not Tracking Requirements
 You Do Not Keep Track of Velocity/Drumbeat
28

29. Infrastructures Debt
Avoiding Infrastructure Debt
29

30. IaaS + PaaS
Use As Much of the Stack as You Can
30

31. Infrastructure Debt Elements
 Infrastructure Debt Elements
 No Utilizing IaaS/Pass
 Lack of Monitoring
 Lack of Redundancy
 Lack of Disaster Recovery
 Lack of Environment Separation
 Dev Ops Debt Elements
 Lack of Deployment Framework
 Lack of Continuous Integration
 Lack of Effective Source Control
31

32. Team Hiring and Scaling
32

33.  Strong Link Games
 Weak Link Games
 Right People on the Bus
 “First Who Then What, Then
How”
33
Hiring as Game Theory

34.  Superstar Driven = Invest in
Superstars
 Very Few Touches to Score
 Very Little Collaboration
 Short Execution Cycles
 High Scoring
 Example: Basketball
34
Early Stage Hiring

35.  Weak Link Avoidance = Invest
In Upgrading Weak Links
 Lots of Pivots
 Low Scoring
 Long Execution Cycle
 Lots of Collaboration
 Example: Soccer
35
Late Stage Hiring

36. 36
Ideal Hire

37.  Many Candidates In a Tight
Race
 Cross the Line First
 Threshold of Viability
 Access and Move On
 Muddy Water
37
It Is Not the Olympics

38.  Google Story
 Theoretical Questions
 Adjacent Possible
 Actual Job Activities
38
Daily Activities

39.  Bad Questions
 Good Questions
 Can’t Google It
 Brain Teasers
 Only 1 Question
39
Google Questions

40.  Take Off Velocity (5/10/20h)
 Resource Coupling
 Outcome Centric
40
Fractional Hiring

41. Team Scaling
You Can’t Outsource What You Do Not Understand
41

42. Offshore Development
It Is Not Going To Be Cheaper
42

43. Fixed Bid Projects
43
Just Do Not Do It

44. Someone You Trust
44
Have Somebody On Your Side Of The Table

45. All The Wrong Reasons
45
 Wrong Expectations
 Solution to Ignorance (outsourcing what you do not understand)
 It Will Be Cheaper (min 30% overhead)
 We Can Achieve Instant Scalability (it takes time to hire)
 Poaching Is not a Problem (no difference)
 We Can Minimize Office Distractions (hallway magic)

46. All The Right Reasons
46
 Right Expectations
 Somewhat Easier to Find Talent
 24 h Dev/QA Cycle
 Improved Ramp Up/Ramp Down Cycles
 Specific Expertise

47. Vendor Speak
47

48. What Do They “Really” Mean
48
 We Can Do Anything (we do not have a specialization)
 We Need a Product Spec (we are going to sit and wait until you
give us specification on stone tablets)
 We Can’t Tell You Finish Date (we have not looked at the
details)
 This Can’t Be Done (we do not know how to do it)
 Code Is Documentation (we developed everything without a plan)
 We Made It Work on a Local Machine (?)

49. Works Locally
We Are Not Shipping Your Computer
49

50. What Do They Mean
50
 We Are Making Good Progress (things have likely stalled)
 We Are Working on the Back-End (we have not done much)
 We Will Tie Lose Ends Later (it will not be our problem)
 We Are 90% Done (?)

51. 90% Done Problem
What Do They Mean by That?
51

52. Congruent Culture
Pick a Congruent Culture
52

53. Offshore Team Selection Criteria
53
 Congruent Culture (challenge authority)
 Language Gap (make sure you speak it)
 Working Hours Overlap (4+)
 Right Size (30+ large enough to have a bench)
 Right Size (100- small enough to care)
 Right Focus (we do everything)
 Do Not Let It Grow (micro-teams)

54. S E R G E Y S U N D U K O V S K I Y P H . D .
Q and A
54