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
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
On working remotely Make the implicit, explicit: ● Foster Trust ● Communicate ● Create space for building relationships ● Write things down ● Accommodate different personalities and communication preferences
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
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
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
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
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
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
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
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
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
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
Building strong Teams 5 Key behaviours of successful teams 1. Focus on Results 2. Accountability 3. Commitment 4. Unfiltered conflict around ideas 5. Trust
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
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
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
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
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.
● Reframe organization as a system that involves decisions and flows of data ● Fixing problems = debugging ● Make problems visible ← observability What can you do?
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
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
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.
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.