- Designing the Performance Review Process for a Startup
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.
- Quarterly Business Reviews at LinkedIn: A True Game-Changer
Brian covers: • Why LinkedIn started using QBRs • How to run a QBR • The benefits that came out of QBRs • Best practices for implementing QBRs
- The Startup OKR Guide
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.
- In Defense of Not-Invented-Here Syndrome
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.
- Coaching vs. Managing
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.
- Empowering your engineering team with an effective decision-making process
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
- Hypothesis-driven development
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.
- How to manage your report’s unrealistic expectations
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’.