Roughly one year ago, an eternity in startup time, we shared what we were building at Echoes HQ. We went through YCombinator during the summer of 2021, and launched our first version of the product the following September. This post is an update to our vision, one year into the life of the product.

How our experiences shaped Echoes

In 2014, blown away by Docker’s potential for wide-scale developer empowerment, I left my job as software engineer in the banking industry in France to lead the Docker Engine team and its associated open source project. The mission spoke to me deeply: giving power to the builders, creating tools of mass innovation. I cannot understate how revolutionary this sounded as an outsider to tech companies and Silicon Valley: a world where engineers were at the center of value creation existed.

I later decided to take these learnings to Veepee which I joined as VP Engineering. My personal goal was to create the environment in which I would have wanted to evolve as an engineer. I tried to instill a culture of engineering empowerment, taking heavy inspiration from open source as to how code is maintained and how teams interact. In this journey, I learned the challenges of leading a successful engineering organization at scale.

The state of engineering management tools

Despite the variety of organizations I joined or advised, the same problems keep coming up. From one point of view: too many topics at once, and a difficulty to assess and communicate how we are succeeding (or not) as a tech organization. From another point of view: a perceived opacity of tech, and that nothing ever goes fast enough (the common disconnect between planning and execution). As widespread as these problems are, none of the solutions on the market are appealing to me.

On one end of the spectrum are top-down management tools, with a bias for control. They go against the engineers’ best interest in several ways: operationally, by imposing a unique view of how software development should be done; ethically, by imposing a form of surveillance which later feeds into misguided performance management.

On the other end of the spectrum are engineering productivity tools, measuring the efficiency of the development process through git and tickets analytics. Their insights are actionable to the teams but fail to inform management decisions (we covered that topic in the value of engineering metrics); when used as success metrics, they perpetuate the outdated idea that an engineering team’s responsibility is solely about shipping code.

What all these tools appear to have in common is an underlying assumption that an engineering manager’s role is to get more out of the engineers. They ignore the decades of learnings which have repeatedly proven how software development is a creative, poorly predictable, team effort. They define success in terms of outputs, but succeeding as an engineering organization takes a lot more than productivity. Arguably, engineering efficiency is not the bottleneck to most organizations’ performance (see also: beyond developer productivity).

Echoes approach

Echoes' mission is to empower developers everywhere, by helping engineering managers create the best conditions for success. Our first step in this journey is to offer managers a value-centric and developer-friendly way to follow and report on activity.

Value-centric

What we mean by value-centricity is that Echoes focuses on the purpose of the work over the velocity alone. It surfaces the determinants of an organization’s performance which a manager can directly act upon: the clarity of goals, the alignment to the strategy, the focus, and challenges faced by the teams. The question Echoes aims to answer is: does my team have what it needs to succeed?

This is not to say that engineering efficiency is irrelevant to the performance of an organization, but that it should not be an engineering manager’s primary concern, and of lesser and lesser significance as one goes up the management chain. Measures of efficiency belong where they can be acted upon: in the hands of the individual contributors.

An interesting side-effect of focusing on value is that it makes for a great communication medium. By connecting engineering day-to-day efforts to company impact, Echoes presents activity in a way that anybody can understand, including a non-technical CEO, CFO, or HR partner.

Developer-friendly

What we mean by developer-friendliness takes many different forms. At the most fundamental level, Echoes does not and will never surface any individual metrics, nor anything which could be misinterpreted as a proxy for individual performance. Echoes shifts the focus away from developer efficiency as the main lever to performance, and toward organizational effectiveness.

Echoes is designed to let the builders pick the tools and processes which make them most productive. This is no small feat, as aggregation across teams traditionally mandates a level of standardization incompatible with developer empowerment (the tension between management and developer needs). Echoes is designed around the smallest possible contract: code changes are to be linked to an intent; how each team choses to create this link is at their own discretion. Finally, Echoes knows to stay out of the way: engineers’ interactions with the platform can happen entirely through the tools they already use, such as GitHub and GitLab.

The results, one year in

What we’ve built with Echoes is different. It may look like a goal setting tool, but truly connects work to purpose. It may look like a measure of developer productivity, but truly says a lot more about the quality of management.

Echoes is different, and it shows in our user base. We naturally see Echoes being used by managers from the EM up to the CTO; but we’re also seeing it adopted by product managers, CPOs, Staff Engineers, and TPMs (Technical Program Managers). We see Echoes chosen by organizations of hundreds of engineers, where the pain of following activity is more acute; but we’re also seeing it in organizations under 10 engineers, where it helps focus efforts where they matter most.

We have learned a lot along the way, but as expected when trying something different, we are often left with more questions than we have answers. What is certain is that we are determined to continue exploring this path, because developers deserve it.