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

Scaling Happy Engineering Teams - RubyConf 2021

Afdf9188c9590a083b4e58f7428a6ab9?s=47 Zaid
December 01, 2021

Scaling Happy Engineering Teams - RubyConf 2021

Approach and philosophy Wrapbook uses to scale happy and effective engineering teams



December 01, 2021

More Decks by Zaid

Other Decks in Technology


  1. Scaling Happy Engineering Teams 😌 A quick guide to building

    happy engineering organizations
  2. About me Engineering leader with over a decade of experience

    in building strong teams I currently lead Engineering at Wrapbook Previously IC and Manager at GitHub, before that founder at Sandglaz B.Eng. Computer Engineering & M.Sc. Machine Learning at McGill
  3. Scaling Happy Engineering Teams

  4. What makes an engineer happy? • Impactful work • Time

    to focus/get into the flow • Timely Feedback • Learning and growing • Great coworkers and mentors • Being heard • Using the best tools
  5. On working remotely Make the implicit, explicit: • Foster Trust

    • Communicate • Create space for building relationships • Write things down • Accommodate different personalities and communication preferences
  6. General Principles Start small, have a feedback loop, iterate Do

    things that don’t scale to learn Lean on 1:1s and qualitative conversations first Automate and delegate later Build Trust
  7. Making Decisions

  8. Making Decisions • Consensus-driven decision making only works in tiny

    teams • Otherwise as teams grow, decision making grinds to a halt • Empower people to make decisions • Make it explicit: ◦ Who is accountable ◦ Who needs to be consulted ◦ Who needs to be informed • Disagreement is ok. Know when to disagree and commit
  9. Making Decisions • Provide guidelines for: ◦ Code Reviews ◦

    Technical design documents and how to solicit feedback on them and communicate decisions • Never penalise mistakes (unless for repeated carelessness), ◦ Use them as a learning opportunity ◦ Fix the root cause
  10. Making Decisions • What if there is a strong disagreement?

    ◦ It’s a coaching opportunity ◦ Give all points of view a chance to be heard ◦ Be explicit about tradeoffs ◦ Disagree and commit • Don’t give one person a Veto over the whole team ◦ Even if they are right most of the time. ◦ The rest of the team learns to not voice their opinion ◦ The ability to scale is gone
  11. Design your Organization

  12. An organization is a product to be designed.

  13. Designing an organization What to do about repeated behaviour or

    outcome that is not desirable? • Design them away! • Adjust process, trigger, or affordance to result in better outcome
  14. Example: No one is reviewing code! • Establish agreement on

    turnaround time for code reviews • Establish responsibility for driving PRs forward • Establish a single person responsible for doing the code review Observe, adjust, repeat
  15. Don’t hide problems Engineers are natural solvers → tend to

    solve organizational problems If a problem is not visible, the root cause will not be addressed and designed away Make Problems VISIBLE Example: no one is reviewing code -> I will review all PRs to fix problem
  16. Design the Process

  17. Design the right agile process • The right process for

    the appropriate confidence level ◦ Updating copy on a page → easy to estimate ◦ Write a self-driving car algorithm → 🤷 • A more rigid process is ok for the first, but will hinder progress and result in constant conflict for the second • Most projects are in-between • Keep process lightweight and flexible to respond to new information • Alignment on goals > the perfect process
  18. Design the right agile process • What are the process

    parameters ◦ What is the cadence? (e.g. weekly, biweekly, monthly?) ◦ When are scope, priorities and goals set? ◦ How to we improve the process and how we work? • Example from Wrapbook: ◦ Weekly Goals meeting ◦ Daily async stand-up ◦ Weekly Engineering+Product Leads prioritization ◦ Weekly Retrospectives + 1:1s
  19. Design the right agile process • What is the unit

    of work? • How to get feedback on work? • How often to deploy changes? Example: • PRs do one thing only (< 3 days of work) ◦ Easier to review ◦ Easier to test • Feedback: ◦ CI test suite running on each commit ◦ Code reviewed by 2 engineers (within 24hrs) ◦ Review app for each PR for easy feedback from stakeholders • Deployed multiple times a day • Feature flag changes that shouldn’t be visible by customers immediately
  20. Building Strong Teams

  21. None
  22. Building strong Teams 5 Key behaviours of successful teams 1.

    Focus on Results 2. Accountability 3. Commitment 4. Unfiltered conflict around ideas 5. Trust
  23. Break Silos: First Teams Allow individual teams to focus Limit

    team size To maintain alignment and collaboration: think of your peers are your FIRST TEAM This applies cross function too: Product+Engineering+Design
  24. Forming new teams

  25. Forming 🌱 Norming 👀 Storming ⛈ Performing 🚴 (Mourning)😢

  26. When forming new teams • Minimize disruption to the rest

    of the organization • All new hires on a new team does not usually work well • At Wrapbook, we split teams to form new ones → we even call it mitosis • Overgrow a team then split
  27. Hire and grow the right people

  28. Define career levels and tracks There are three tracks: •

    IC • Technical Leadership • People Leadership The goal is to provide a common language to speak about expectations Provide a clear understanding of how to transition to different tracks
  29. Hire the right people Remove bias from the process ←

    check your ego Look for complementary strengths to those on the team Decide on the needed job level, and test appropriately for it Be respectful of candidates’ time
  30. Onboarding Create a repeatable onboarding process For example: • Each

    new hire has an onboarding buddy • Create onboarding checklist: things to read, people to meet, expectations to meet by a timeline, etc.
  31. What can you do today?

  32. • Reframe organization as a system that involves decisions and

    flows of data • Fixing problems = debugging <- You know how to do that! • Make problems visible ← observability What can you do?
  33. Remember: General Principles Start small, have a feedback loop, iterate

    Do things that don’t scale to learn Lean on 1:1s and qualitative conversations first Automate and delegate later
  34. None
  35. Wrapbook’s engineering team while small has big plans! We bias

    for action and impact by keeping our tech stack simple. Engineering philosophy and tech stack
  36. Our Core Values Compassionately Direct Seek to understand each other

    while communicating transparently Be Yourself Respect and celebrate our diversity. Bias Towards Action Lean into taking action, fast in low stakes and deliberate in high stakes. Delight Customers Win users’ hearts with seamless, compliant, and secure services. Own Your Work Be accountable to our impact. Surface issues to learn together.
  37. We put a lot of care into who we hire

    We are looking to work with teammates who are empathic, curious, and excited about building modern software tools for creators.
  38. We Are Hiring Engineering • Senior Engineering Manager • Engineering

    Manager • Staff Engineer • Senior Software Engineer • Platform System Engineer • Platform Software Engineer Product • Manager, Design and Research • Principal User Researcher • Senior Product Designer Marketing • Product Marketing Manager • Senior Brand Designer • Digital Marketing Manager • Marketing Operations Manager Operations • Director, Legal Counsel • Director, Risk Management Sales • Account Executive, SMB Success • Customer Success Manager Finance • Senior Data Analyst
  39. Apply Now https://www.wrapbook.com/careers

  40. Join Wrapbook wrapbook.com/careers → zaid@wrapbook.com