Your engineering team isn't moving fast enough

I interviewed with Bonusly for the VP of Engineering role in November 2023. The role was being filled to achieve one primary objective: make Bonusly Engineering fast. High engineering velocity is a competitive advantage for any company. Bonusly wanted to reclaim that advantage.

So I shared my ideas about how that could be achieved. And they were predicated on creating a shared understanding of what “fast” actually is. Is it output velocity?

In 2023, Bonusly Engineering was regarded as “slow.” It pushed over 3,300 software updates to customers.

In 2024, we improved, and our team was regarded as fast. Evidence of this was everywhere. It was in new bottlenecks forming; we were shipping help-center-worthy features faster than our help-center could be updated. Design had an untouched backlog in prior years. Now they were stretched to feed those hungry engineers. And, most important, internal sentiment around team velocity shifted favorably.

But the Engineering team pushed only 3,400 updates to customers, which was a 3% improvement over 2023.

How does a 3% increase in year-over-year output completely flip the perception of this team? What do people mean when they say “fast”?

Fast is not about output velocity.

I’ve seen this play out everywhere in my career. When people say, “your team is slow,” they rarely have data to substantiate that statement. Instead, it’s a feeling. And that feeling is usually right, as it’s rooted in the intuition we all develop operating our companies every day. We expect to see important improvements to customer experience at a rapid clip. We remember what that looked like when our company was smaller, and we don’t see those valuable customer outcomes land with the frequency they used to.

Fast is about the rate at which we produce valuable customer outcomes.

What are valuable customer outcomes?

Here are but a few examples relevant to our company:

• Large reports being emailed via PDF instead of having to wait on the website hoping it hasn’t timed out.
• Enabling Admins to allocate points to managers based on the number of direct reports they have.
• Rolling out a new pricing package so companies can use Bonusly without having to fund a rewards program.
• Illuminating how someone works and what they worked on based on recognition data so managers can get a more complete view of team performance.
• Introducing “groups” as a concept to make it easier to recognize and reward large numbers of people.

Those are valuable customer outcomes not because they’re features we’ve shipped, but because they’re features we shipped and that customers use. Fast teams create useful features often.

The most important change we made was holding Engineering accountable to this new definition of velocity. What matters isn’t the amount of code we ship, but the rate at which we drive valuable customer outcomes.

Is it fair to hold engineers accountable to outcomes?

Anchoring on the idea that velocity is outcome-oriented, not output-oriented, often doesn’t land well with Engineering teams. It didn’t with some Bonusly engineers. Indeed, the most common response they had to this idea is that they’re not in control of outcomes; sales and marketing and customer-success people drive customers to the features they build. What engineers control is output. Output is a fairer measure.

Understandable. But I call BS.

Are sales and marketing and customer success people in control of the product they sell and support? No. But we accept that they should be held accountable to selling it (pipeline and bookings and expansion quotas) and supporting it (ticket throughput and sentiment goals). Holding people accountable to objectives they can’t fully control is what we do in business.

That is, except for Engineering. And I don’t think that makes sense.

How is outcome-oriented engineering different?

I mean, we’re still writing code. We still care about code structure. But there are important differences in how we expect engineers to do their jobs relative to how it was before.

• It’s not about maximizing coding time. Engineers spend time with stakeholders and listen to customer calls to understand what customers need. This is time well spent.
• UX design can be done as we code. Engineers build great experiences working from low-fidelity (or no) UX designs. They jam with Design in real time to solve customer problems.
• What happens after we ship matters. Engineers make it easy to observe how effective the features they build are. Do customers use them? This insight is shared with the company, and when usage is low, engineers advocate unplanned work to help customers find and understand what we built for them. That work is not necessarily in code; sometimes it’s about arming Sales, Marketing, and CS with information to convey to customers.
• Large structural projects (technical debt) are undertaken by product-engineering teams only when conviction is high that customer outcomes will improve because of them.

Shifting the culture

We borrowed much from these outcome-oriented ideas to change our culture in 2024. I’ll write more about all of this throughout the year. But here’s how we landed the change:

• Redefining our Engineering levels and expectations to be outcome-oriented.
• Creating smaller teams helmed by an Engineering DRI (directly responsible individual) instead of an engineering manager or product manager, and empowering the DRI to own OKR, roadmap, and scoping decisions.
• Writing. A lot. RFCs, weekly team updates from DRIs to the whole company.
• Weekly demos (where we often run out of time).
• Changing our hiring process to screen for customer-centric engineers. Some great engineers won’t operate this way. That’s cool. It’s just not what we want at Bonusly.
• Having tough conversations with engineers about adapting to this change.
• Rolling out an on-call process that put every engineer on the frontline to address customer issues during their rotation. This helped create even more customer empathy.
• Re-positioning the engineering manager role; they’re people managers and code contributors. That includes me, the VP of Engineering. I write a lot of code here.

And we’re not done. I think we can be even faster than we are today. More soon.

‍