Let’s say we have a bunch of things that need to get done, of varying size and priority.
Generally we want to do the highest priority things first, but the other factors that come into play are:
- Who is available (i.e. not working on something else)?
- Who wants to work on what - we try to match engineers with their interests as much as possible
- Who can be most efficient in working on what - we want to get things done as quickly as possible
Generally we just sort this out as a group, with various engineers volunteering to take on different projects, and where there’s occasionally not a clear answer, Zach asking folks to take particular tasks.
Right now, we have about 5 pods going, focusing on different features and infrastructure areas – everything from single-user improvements to Teams and cloud infrastructure.
Project leads
At Warp, for now we don’t have any standing “tech leads” who “own” different parts of the code. Instead, when there is a significant project to be done that requires more than one engineer, we generally ask one engineer to be the “lead” for that project.
What does it mean to be a “project lead”?
- The lead should be the “driver” on a project rather than a gatekeeper - the lead needs to keep the project moving forward, should be responsible for communication about its progress, timeline, goals, etc
- The lead should coordinate the work associated with the project - creating the tasks, driving the design, talking to users
- The lead is responsible for the overall quality and timeline of the outcome - ultimately for any project what matters is (a) how well does it work and (b) how long did it take and (c) was it built well so that we can continue building on it.
- This is similar to the concept of Directly Responsible Individual in use at other companies
Being the lead does not mean:
- Managing other engineers working on the project
- Making all the product or engineering decisions on a project or even having final say on them - being a lead is about guidance and propulsion, not authority