Management

Maggie Hsu, Global Business Development, Amazon Web Services (AWS)

Maggie covers: • How to define the CoS role for your specific needs • How to find and hire the right CoS for you

Matt Nemenman, Director of Engineering, Lyft

Matt describes how his team launched a heavy-weight performance review system at a 50 person startup that took up too much managerial time. They then switched to a lightweight monthly system; employee morale improved and it became quicker to fix employee mistakes.

Brian Rumao, Chief of Staff to the CEO, LinkedIn

Brian covers: • Why LinkedIn started using QBRs • How to run a QBR • The benefits that came out of QBRs • Best practices for implementing QBRs

Rachael Twumasi-Corson, Co-Founding Managing Director, Afrocenchix

Rachael provides a practical guide for rolling out OKRs at a small company, with a 3-step quarterly OKR process: 1. Brainstorm 2. Communicate 3. Reflect & Score

Joel Spolsky, CEO, Stack Overflow

Eli Portnoy, Co-founder & CEO, Sense360

Eli defines the difference between coaching and managing by explaining a common pattern he sees with first-time managers: expecting to control the actions of your direct reports, rather than focusing your team on teaching them how to perform well.

Cate Huston, Engineering Director, DuckDuckGo

Cate covers definitions for what does a good decision look like and a multi--step process for how to make decisions that includes: • Answer, what are you deciding (and why)? • Answer, what is the necessary context? • Foster discussion • Make and communicate the decision • Follow up on past decisions to see if they were successful

Rod Begbie, Senior Engineering Manager, Discord

Hypothesis-driven development is a scientific approach to problem solving that involves defining and stating hypotheses at the beginning of design, and measuring the success through a process of incremental, phased development. A good hypothesis is a statement about what you believe to be true today, and should contain neither the words 'if' nor 'then'. Predictions are used to define the smallest possible piece of work that could be built and produce a learning. This approach allows teams to stay focused on projects that will move their product to deliver their business goals, without over-investing in work that doesn't move the needle. It also encourages more-junior engineers to confidently throw out suggestions, as the discussion is focused on the simplest ways to test the hypotheses. This approach has been used successfully by product growth teams, but can be applied to different engineering problems.

Katie Wilde, VP of Engineering, Buffer

Katie describes an experience where the 1:1s with a direct report became toxic over time. She recommends a 4-step solution to prevent this in the future: 1. Set expectations during recruitment 2. Set expectations during onboarding 3. Set boundaries and be firm about acceptable behavior 4. Teach ‘disagree and commit’.

Gergely Nemeth, Engineering Manager, DoorDash

Gergely takes us through the standard components he recommends when creating a team charter: • Team history • Mission statement • Vision statement • Risks • Goals and KPIs • Inventory