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 outlines Afrocenchix's three step process for implementing OKRs: brainstorming ideas, communicating OKRs to the team, and reflecting on and scoring OKRs. Following this process has helped Afrocenchix triple production capacity, grow customer base by over 250% and increase online sales 17 times in one year. She recommends keeping the system simple, training the team, collaborating, delegating OKR organization, focusing on the present quarter over past scores, and refreshing resources regularly to keep the team engaged.

Joel Spolsky, CEO, Stack Overflow

Joel argues against the common view that code reuse and avoiding reinventing the wheel are always good, while the Not-Invented-Here syndrome is always bad. He claims that for core business functions, it is better to develop solutions in-house rather than outsourcing, even if that means reinventing the wheel. Outsourcing often leads to poor quality, lack of control, and inability to meet customer needs. Truly valuable companies write their own excellent code that forms their core competitive advantage, rather than relying on third-party solutions. However, for non-core functions, outsourcing and code reuse can make sense.

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