Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Onboarding at Scale: An Engineering Problem

Onboarding at Scale: An Engineering Problem

A talk given at Velocity 2016 in Amsterdam, The Netherlands.

Of the myriad challenges in scaling up an engineering organization, onboarding new employees is probably the least well-understood. There are relatively common solutions for large-scale recruitment, finance and administration, but onboarding remains a question that many organizations struggle with.

At Wix we've been struggling with massive scaling challenges: over the last two years our company headcount has doubled itself, and we had to learn to cope with the influx while maintaining velocity. In this talk we'll share with you the story of how we set up Wix Academy, an engineer-driven training organization, the solutions we've developed (and still are!), and what we've learned in our first year of operation.

Tomer Gabel

November 07, 2016
Tweet

More Decks by Tomer Gabel

Other Decks in Programming

Transcript

  1. Wix is… • A web publishing platform • Distributed R&D

    – Tel-Aviv (Israel) – Be’er-Sheva (Israel) – Dnipropetrovsk (Ukraine) – Kiev (Ukraine) – Vilnius (Lithuania) • Growing rapidly – Jul 2013: 120 engineers – Now: 400+ engineers
  2. Product Suite Kickstart Training Kit Crash Course Images: Jeff Robins

    (CC BY 2.0), Vernon Cunningham (Public Domain), Paul Fisher (CC BY-SA 2.0)
  3. Training Kit: Customers As a Guild Lead, I want to:

    • Start onboarding early • Reduce overhead • Have quality reference material Image: KCNA
  4. Training Kit: Customers As a Team Lead, I want to:

    • Simplify training of new hires • Minimize disruption to my team • Have quality reference material Image: John Kennicutt, USMC (Public Domain)
  5. Training Kit: Customers As a new hire, I want to:

    • Understand the technology stack • Be productive quickly • Learn on my own (and not be a pest) Image: Cubmundo (BY-SA 2.0)
  6. Kickoff • Meet the Guild Lead – Validate assumptions –

    Identify key (technical) partners • Scope definition – Meet key partners – Set scope and expectations – Generate “bucket list” of desirable topics • Review and prioritize
  7. Development • Guild Days – Ask for some volunteers –

    Host them for a full day – Volunteers pick subjects – Volunteers search & evaluate material
  8. Feedback Collection • Per-subject feedback – Simple web form –

    Highlights substantial issues (if any) • Guild Day (one-off) – Technical review by experts • Interviews (one-off) – Team leads – New hires
  9. Lessons Learned Assumptions • Content – Only developers can evaluate

    content – Minor post-processing – Focus on learning • Structure – Topics are atomic units – Customizable set/order Reality – Dedicated professional can take over – Most of the actual work – Need actionable content (exercises, koans etc.) – Topics are interrelated – Modules are necessary
  10. Lessons Learned Assumptions • Marketing – R&D will self-market –

    No need for special effort • Maintenance – Mostly ad-hoc – Developer pull requests • Future efforts – Proper UX Reality – Little known, little used – Initial push insufficient – Constant, significant work – Little participation – Not that useful, for now
  11. So what’s next? 1. Dedicated content/training developer 2. Revise structure

    for modularity 3. Significant in-house marketing effort Image: Booyabazooka (CC BY-SA 3.0)
  12. Kickstart: Overview Takes juniors as input, outputs web developers 9

    weeks, fully salaried End result: professional web developers
  13. Recruitment • Unique requirements – Experience/skill level – Recruiting in

    bulk – Cost mitigation • A dedicated pipeline – “Recruiting days” – Carefully orchestrated
  14. Lessons Learned Why do this? • The social element –

    Company culture – Built-in “buddy system” • Sustainable recruiting – Easy to plan for – Marketing-bound, really – Great people! Why not? • Expensive – Facilities, staff, amenities… – And fully salaried to boot • Hard to do consistently – Staff turnover – Buy-in is a constant effort – Dedicated staff is critical
  15. Planning • Week 1: Ramp-up – Heavy on doctrine (TDD,

    CD) – Tech stack (Scala, TypeScript) • Weeks 2-3: Project time – Guided bootstrapping – Constant mentorship
  16. Lessons Learned Why do this? • Break down the wall

    – The server-client divide – Reinforce TDD, CD etc. – Makes our stack accessible • Reduces new employee friction • Huge marketing boon
  17. Lessons Learned Why not? • Expensive – Facilities, staff, amenities…

    – And fully salaried to boot • Tight scheduling – Lots of ad-hoc adjustments – Everything needs a backup • Minimal recruiting rate Image: Jenny Poole (CC BY 2.0)
  18. Lessons Learned • These are long- running projects • For

    best results: – Assign dedicated staff – Long-term • This means you can’t rely on engineers – Trust me, I am one… Program Manager Project Manager Training Developer
  19. Lessons Learned • Scaling up is hard • Doing it

    ad-hoc works! • Until it doesn’t – It’s not about size – It’s about growth • Consider ROI carefully! Image: Damian Gadal (CC BY 2.0)
  20. Lessons Learned • Mentors are your biggest asset – You

    need their buy-in – You need them to come back • Give them what they need – “Soft skills” workshops, simulations – Expectation setting and guidance – Hold status/venting sessions. Pay attention!
  21. Lessons Learned • These are big projects • Success is

    about logistics – Huge todo list – Scheduling hell – Constant interruptions – Follow-ups • That’s a lot to keep track of • Hire a Project Manager. “Behind every great leader there was an even greater logistician.” - M. Cox Image: Rom Logistics (CC BY-SA 3.0)
  22. QUESTIONS? Thank you for listening [email protected] @tomerg http://engineering.wix.com To contact

    Wix academy (ask us anything!): [email protected] This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.