When our customers bring Echoes to their new company

You’ll find below the testimony of Fabien Ducher, a newly appointed CTO at Gens de Confiance. Fabien told us how he presented and implemented Echoes when he arrived at Gens de Confiance, the steps he followed, and the benefits he was able to reap from it in just a month.

Gens de Confiance is a French startup that operates a trusted community-based marketplace app. It fosters peer-to-peer exchanges of goods and services, emphasizing trust and reliability among users. Fabien is leading a team of around 40 developers, and explained to us how Echoes enabled him to conduct an initial audit of his team's delivery and provide them with first directions for improvement, supported by facts and data.

Here is what Fabien told us:

"After just four weeks of use, I was able to gather enough information to explain to my teams and stakeholders the changes and improvements I wanted to bring to the team's operations on two initial subjects: QA & bug policy on one hand, and on the other hand, acceptance of tech initiatives in prioritization discussions, along with product initiatives”.

Which steps to follow to implement Echoes ?

Fabien achieved this result easily by measuring the efforts allocated to "keeping the lights on". This simple approach generated the reaction he expected when implementing Echoes.

He describes the process he followed in a few steps:

• Ask Engineering Managers for an estimation of the effort allocated to QA, for example. In this case, this effort was estimated at 15-25% depending on the teams.

• Implement Echoes, explain the labels, and how to tag PRs.

• Assist in the tool's adoption to ensure everyone understands which bucket to categorize each PR and achieve consistent tagging. In case of doubt, the instruction was simple: "What drives your action? And if it's a highly technical task, in the context of an initiative, would the initiative be the right tag?". Fabien illustrated his point with examples, real or imagined, that would resonate with everyone.

• Monitor customer value / technical value / risk mitigation counters.

• Share the measurement results.

• Observe the audience's surprise, and start a discussion.

Even though individuals were surprised facing the outcomes, each remained open-minded. These results opened up a discussion on two themes that Fabien was expecting.

First interrogation: "How do we improve?"

Below are the first outcomes of this team's conversation:

• By transforming shadow work into well-identified work and incorporating it, when possible, into the prioritization logic (especially technical initiatives).

• By working on code quality, to reduce the impact of maintenance on the effort allocated to customer value.

• By being clear that a project is completed when the scaffolding is also removed, not just when the facade is renovated. Maintenance tasks to remove scaffolding must be integrated into the project, estimated, and included in the roadmap. They can be performed six months later, but they are planned and linked to the initiative.

• By defining a clear bug policy (with SLOs on bug fix times according to severity, follow-up at defined frequency, exhaustive ownership map, etc.).

• By defining a clear policy on how to manage maintenance: having a quarterly-scale measurement to distribute the workload, agreeing on possible approaches (as-you-go and/or sprint focused on maintenance, etc.), and agreeing with the executive committee on a clear framework within which teams can evolve and be autonomous.

• By accepting that sometimes, we will have to step out of the frame, and collectively validating that it's okay to do so with a plan for repaying the debt thus generated (or left hanging).

• By sharing best practices: for instance, having rotating firefighter roles within teams whose job is only to handle maintenance tasks.

• By integrating maintenance tickets into the same backlog as the product build, not separately on another "magic time" backlog.

Another interrogation to answer: "What would be the right target for these indicators?"

Teams asked another question that Fabien has anticipated, which is the right value that should be achieved for the indicators of efforts allocation, that are now followed through Echoes?

Fabien's teams are focused on efforts allocation for the moment, but this question can be extrapolated to all indicators that can be followed through Echoes, including the notorious DORA metrics.

At Echoes, this is a question that comes up very regularly in our conversations with our prospects and clients. Should we take the targets promoted by Accelerate authors as a referential for all engineering teams? How can we benchmark an engineering team to another? and more broadly, what can we define as a good engineering performance?

In Fabien's opinion (and in ours too), this is a question that doesn't really have a definitive answer as the relevant targets varies depending on the teams and contexts. For instance, some squads will structurally always have more maintenance than others, whether the stack is very legacy or new.

Fabien set up a target for his teams in absolute terms, to give them a referential. For instance, in his opinion, not exceeding 30% of efforts spent on maintenance tasks seems already excellent. This is a target that we find back quite often among our customers.

Using Echoes to get an overview of a current situation, and start key conversations with an engineering team

Fabien is not the first of our customers to use Echoes to get a quick and sharp look on an engineering organization. The objective here is not really to define if the organization performance is good or not. It is more about getting data on how things are going, make a picture of the organization performance at a moment, and start conversations with squads on the main challenges the organization is facing. Echoes allow to open up discussions on common goals, and how to achieve them, as a team.