This document discusses strategies for outsourcing software development work to remote teams. It outlines two approaches to outsourcing ("Outsource 1.0" and "Outsource 2.0") and recommends "Outsource 2.0" which involves hiring a dedicated remote team on a long-term basis. The document provides tips for companies using outsourced teams, including establishing strong management processes, frequent communication, training the remote team, and clearly defining expectations and performance metrics to ensure project success.

1. Path to success
Using Outsource
for a Startup
Roman Smolgovsky
Head of Engineering
SORT Financial

2. To Outsource or Not to
Outsource?
❖ Benefits
❖ Cost (Duh?)*
❖ Talent attraction
❖ 24x7 development cycle
❖ Drawbacks
❖ ‘Knowledge distribution’
❖ Regulations compliance (Government, financial, security, etc.)
❖ Distributed team

3. “The road so far…”
❖ Outsource 1.0 - “Give us a spec and we will build it for you”
❖ Charge per hour (disaster!) or per project (try to get it!)
❖ Requires:
❖ Very detailed and accurate specification - impossible to
make!
❖ Coordination and alignment effort (often billable!!!)
❖ Project management and activity tracking - time
consuming and boring!

4. “The road so far…” -
Continued
❖ Outsource 2.0 - “Here is your team…”
❖ Charge per person per month
❖ Same personnel for long period of time
❖ Has a Delivery Manager (may even not be billable) that
is responsible to assure your success
❖ Very often residing in US
❖ You manage the team any way you want (Agile -
suggested, more about it later)

5. What to look for in Outsource 2.0
provider
❖ Personnel retention, no personnel rotation
❖ Personnel is 100% dedicated to your project
❖ Adequate development/testing equipment (at times it is OK
to pay extra for some testing stuff)
❖ Facilities: conference rooms, videoconferencing facilities,
ability to easily reach the team (e.g. US phone numbers)
❖ Personnel engagement and interest
❖ Teams training and intra-team knowledge sharing

6. Set your expectations…
❖ “Out of the box” the team is not yours!
❖ They may (and will) see you as a ‘stranger’
❖ They may not push back when needed
❖ They may take requirements and procedures literally!
❖ They will not ‘fill the blanks’
❖ Language barriers (lots of funny stories)
❖ Even the best speaking team may not understand all the subtleties
❖ Cultural differences
❖ Amount of vacation time
❖ Start time and working habits

7. Expected from you…
❖ Strong engineering management at the home office
❖ Manages your remote team and represents them within your company
❖ Establish connection with your team
❖ Meet them in person - periodically spend time at their facilities
❖ Identify the key events (new release planning, etc.) and spend a few weeks at their
location working together
❖ Establish daily call with a video
❖ Establish the right attitude towards the remote team in the home office
❖ Eliminate ‘they’ attitude
❖ Establish collaboration outside engineering; e.g. QA-Product Management, UX
designers - UX developers, etc.

8. Expected from you…(Cont.)
❖ Figure out the mechanisms to motivate your outsourced team
❖ ‘We are all in it together’ - work with your team in their office
❖ Cool technology/‘You can learn cool stuff’ - exposure to the
Silicon Valley new tech. Presentations, training, etc.
❖ US visits
❖ Souvenirs, team lunches, team dinners
❖ Bonuses

9. Expected from you…(Cont.)
❖ Develop relatively formal processes. Clearly establish:
❖ What is expected from the remote team
❖ What is expected from the home office
❖ Collaboration between the home office and remote team:
requirements, planning, artifacts, etc.
❖ Measurements of performance and success
❖ Assure that requirements, artifacts, etc. are completely ready in
advance way before the development effort is expected to start

10. Expected from you…(Cont.)
❖ Establish formal SDLC
❖ Recommendations:
❖ New Development:
❖ Scrum, 2 weeks iterations
❖ Planning in ideal time. You must assure relatively stable throughput after 2-3 sprints
❖ Continuous integration (Unit, Integration, System Tests on every GitHub merge)
❖ Maintenance/Operations
❖ Kanban with the regular planning
❖ Constant effort
❖ Clear understanding of the priorities
❖ Automated deployment

11. Performance and Success
Measurement
❖ Estimates Vs Actuals - delta should decrease
❖ Steady throughout when nothing changes
❖ Investigate any deviation
❖ Number of critical bugs post release - should be 0
❖ Number of mid-air substantial requirements changes - should be 0
❖ Number of midair requests for the requirements clarifications
❖ Number of deviation from the requirements
❖ Number of re-opened bugs and number of the re-opening of the same
bug (per developer)

12. Thank you!
Questions, Comments, Concerns