Scaling Happy Engineering Teams - RubyConf 2021

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

Transcript

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