This guest post was kindly contributed by Guillaume Lesur, product manager at Bearer. Bearer helps you proactively find and fix data security risks and vulnerabilities across your application environment so you can prevent data breaches before they happen. They have been among Echoes’ most early adopters.

I’ve previously written on our blog about how pivoting the product at Bearer forced us to reassess how we build and ship. A crucial part of that new process is Echoes. Not only in what it offers as a tool, but also how it advocates a different approach to software development.

In this article I’ll explain why we find Echoes essential to shipping better features, faster.

The estimation fantasy

A common topic at planning meetings is determining how big a new feature is, how long it will take to build, and when it will be available in the product. It’s the job of product-engineering leadership to make these estimates so that other teams—like sales, marketing, and customer success—can plan accordingly. This is especially true for SaaS companies.

In a perfect world, this would be straightforward. You would know how big a feature is, and it would be sliced into doable bits. Then, it would receive approval and the estimate would be correct. Items would then be put on the roadmap and communicated to everybody.

The catch is that nobody knows for sure how big, how complicated, and how long it will take to develop a new feature. So you guess, and you over or underestimate. You predict to the best of your knowledge because you don’t know what you don’t know yet. Engineers building the feature will discover the unknowns during the development when they try to make all the cogs turn and deliver the outcome.

You can counter this by making cycles longer to allow for more research and account for discoveries and surprises, but it’s still just a guess.

Maybe you guessed right, or perhaps you missed something big. Because context-switching, or because it’s Friday. Or perhaps it’s summer and way too hot to be stuck in an office.

There must be a better, more honest, less frustrating approach to synchronizing every function relying on feature shipment.

Learn to drift like a pro

We had been stuck in this fantasy at Bearer for quite some time. Product-Engineering had headaches trying to figure out how long it would take to develop this or that. The business side was frustrated to see due dates for critical features being pushed, delaying when they could get back to customers waiting for them.

We decided to stop trying to have the best estimate possible of how big features were, based on t-shirt size or Jira points; we got rid of all those. Instead, we decided to acknowledge that everybody is doing their best in the team and that we will ship when features are good enough given the effort we are ready to commit.

Sounds great for product engineering because it’s honest. This is actually how software development happens. However, it’s a tough one to swallow for other functions in the company. Where is the accountability? How do you build a marketing roadmap if you can’t rely on an accurate product roadmap?

We deployed Echoes to instrument our development cycle. What we liked about Echoes is how it’s anchored in reality. Sometimes timelines move, or drift as unknowns come up. The team’s effort is analyzed based on the actual codebase being merged. No work is required from engineers, as all our pull requests are linked to Jira tickets. We assign Key Results to each PR, and Echoes accurately evaluates the real effort produced by the team.

This way, we can have an honest, open, and transparent discussion with other teams relying on feature shipment. Everyone can acknowledge the level of effort spent on items to be developed and accept that some stuff is bigger than expected and will drift at some point.

So we didn’t transform software development into what it’s not. We embraced drifting. We made it OK by being accountable for the drifts and transparent about them.

Advocate for Legacy & Throughput activities

Being transparent about our workload had an interesting side effect: we realized we weren’t spending enough time managing our legacy code base or building throughput activities like a preview environment.

It’s a recurring dilemma for product-engineering teams: should we spend time building features or fixing invisible issues before they are out of control? No one likes a messy closet, even if it isn’t hurting anything right now. However, you are constantly late if you are bad at predicting when to ship the essential roadmap items. That recurring sense of urgency doesn’t do good to convince you that you need to spend less time delivering customer value to improve your ability to ship. It’s counter-intuitive when out of the engineering context.

It’s a vicious cycle: the more you are late, the faster you need to ship features. To try to get back on schedule, the more you need to cut corners and generate technical debt. With more technical debt, you ship features slower, and ultimately, you will be even later to ship to customers.

This is where Echoes really helped us. Having embraced drift, the Bearer team got more confident in its ability to ship roadmap work accurately. It enabled us to let some of the team’s efforts be diverted to make the invisible parts of the product way better, to ship faster later. As a result, we broke the vicious urgency cycle, and that serenity is helping us stay on top of technical debt, legacy codebase, and shipment process.

Like roadmap work, we find all the data we need to know we are on track and spending the effort level we committed to each activity in Echoes, anchored in the reality of what’s merged into main.