Have you felt frustrated by your team's speed of execution? Have you asked yourself, perhaps in the middle of a sprint planning session: Are we stuck? Why do some teams seem to work faster than others? Why do some people perceive a team as too slow, while others consider the same team fast enough? And engineers on some teams appear to be more satisfied and more motivated than those on other teams; why? Engineers don't lack motivation -- it is systems that fail to create an environment for engineers to make magic. In this talk, I’ll lay out a step-by-step guide for managers and ICs to ask the right questions towards this problem.

- Alignment: Are the team’s goals and metrics aligned with the business? Is the team aware of broader priorities and constraints? Is there agreement around when to optimize for user-visible features vs technical debt? Is there alignment around what exactly the team owns?
- Doing Too Much: Is the team keeping too many projects active at the same time? We’ll talk about how to identify if this is happening, and how to use metrics and models to choose what to prioritize.
- Thrashing: Big and frequent changes in priority can make engineers take the priorities themselves less seriously— but such change is a reality in a fast-growing company. How do you reduce thrashing as well as increase adaptability to change?
- Deep, slow projects: Some projects simply take a long time. This is especially true for infrastructure work. In this context, it’s important to demonstrate value early— engage with users, go deep before going broad.

As a manager or lead developer, this talk will give you a playbook to analyze and work on your team’s engineering velocity— and ultimately, to create an environment where people work together at their highest potential.