3 Steps to Build a High Velocity Engineering Culture

Startups live and die by their velocity – aka their ability to ship code and updates quickly. I’ve led several high output teams, including a 40-person team building self-driving car technology at Cruise, and most recently, our team at Unthread.

The most common problems with engineering teams as reported by their managers are:

• They're not fast enough
• They're not focused on the right things

These two problems are closely linked and can be fixed with the right process. Following the steps below, we've seen any organization turn into a high-functioning, high-output, and highly aligned team that's focused on the right goal.

Encourage engineers talking to users directly

This sounds crazy – don't engineers hate meetings? Yes, we all do. The reason to let engineers talk to users is because they need to deeply understand customer pain points as well as the product managers writing PRDs. Building the right solution means deeply understanding the problem.

How do you do this without drowning engineers in even more meetings?

The solution is async communication, and the best way we've seen this is with shared Slack channels between your company and your customer. Loop in engineers into this channels so they have a direct line of communication to hear what customers think and can chime in when necessary.

It's important that you also properly manage your Slack notifications so your team isn't drowning in alerts and can surface important information easily.

Bring engineers into the problem-solving process

The first step is key to get context in engineers' minds about the problems that they are solving. The second step is to let them use that knowledge to create the best solution.

In most companies, PMs create Product Requirements Documents, or PRDs, and send along to the engineering team to review. Before the solution is created, consider presenting the problem & context to the engineering team to solicit feedback and ideas on how to solve it. The problem here is that a solution is already suggested, and the path feels pre-defined.

Instead, present the problem statement and objective to the engineering team in a solutionizing exercise to brainstorm on a solution. In this case, you have a full team of smart folks contributing ideas towards a solution from a clean slate. The result is a more diverse set of ideas to choose from and a higher quality solution in the end.

Moreover, regardless of whether their ideas were selected, they'll feel ownership of the path forward and will be more committed to the solution.

Treat the process like a product; iterate on it

You don't build a product once, you're constantly iterating.  This means prioritizing fast feedback loops, making sure the team knows the goals and expectations, and creating space for learning and experimentation.

The same applies to your engineering process. Try new things, see what works, and make changes to the things that don't. No process is a one-size-fits-all solution, and with this process, you'll find the right formula for your team.

Why does this work?

Your customers provide a north star of what problems should be prioritized. When engineers deeply understand users, you'll find that they're more closely aligned with business goals (output) rather than overly complex design systems or code bloat (input).

We follow these principles at Unthread, and if you'd like to work with us, reach out to me directly and we'd love to hear from you.