Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Scaling Technology Organizations

•Download as PPTX, PDF•
•
Sergey Sundukovskiy
Sergey Sundukovskiy

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 of 54
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
Scaling Technology Organizations
3 Agenda
Debt Management 4
CEO/CTO Story I Have Not Seen Organs Like These 5
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
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
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
Broken Window Theory One Broken Window Leads to Ruin 9
Broken Window Theory Do Sweat the Small Stuff 10
Debt Tipping Point 11 Product Death Year 2 Year 1 Tipping Point
Snowball Effect 12 No Turning Back Now! SPLAT!
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
 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 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
Team Structure Big Rocks First 16
Separate Development Teams 17 Rapid Development vs. Core VS.
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
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
Process Debt How Do They Know? 20
Process Complication Do Not Make It Complicated 21
Process Complication  Do Not Make It Complicated  Complicated = Bad  Complicated = Unsustainable  Complicated = Not Followed  Complicated = Edge Case Centric  Complicated ! = Useful  Complicated = Unintended Consequences 22
Planned vs. Agile 23 VS
Planned vs. Agile  Planned Process  Exhaustive Planning (plan until you are exhausted)  Prescriptive  Document Centric  Agile Process  Iterative Planning  Non-prescriptive  Practice Centric 24
Agile Umbrella 25
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
False Agile Just Because You Call It Agile It Does Not Mean It Is 27
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
Infrastructures Debt Avoiding Infrastructure Debt 29
IaaS + PaaS Use As Much of the Stack as You Can 30
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
Team Hiring and Scaling 32
 Strong Link Games  Weak Link Games  Right People on the Bus  “First Who Then What, Then How” 33 Hiring as Game Theory
 Superstar Driven = Invest in Superstars  Very Few Touches to Score  Very Little Collaboration  Short Execution Cycles  High Scoring  Example: Basketball 34 Early Stage Hiring
 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 Ideal Hire
 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
 Google Story  Theoretical Questions  Adjacent Possible  Actual Job Activities 38 Daily Activities
 Bad Questions  Good Questions  Can’t Google It  Brain Teasers  Only 1 Question 39 Google Questions
 Take Off Velocity (5/10/20h)  Resource Coupling  Outcome Centric 40 Fractional Hiring
Team Scaling You Can’t Outsource What You Do Not Understand 41
Offshore Development It Is Not Going To Be Cheaper 42
Fixed Bid Projects 43 Just Do Not Do It
Someone You Trust 44 Have Somebody On Your Side Of The Table
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)
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
Vendor Speak 47
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 (?)
Works Locally We Are Not Shipping Your Computer 49
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 (?)
90% Done Problem What Do They Mean by That? 51
Congruent Culture Pick a Congruent Culture 52
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)
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

More Related Content

Scaling Technology Organizations

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