Launch HN: Echoes HQ (YC S21) – Developer-friendly activity reports
I've been an engineering manager for over a decade, and I know how hard it is to navigate the chaos of product development. Engineering management requires data — to inform decisions on priorities and hiring, and to communicate activity to our partners in other functions. But how software development insights are collected and used today is at odds with the developer’s experience. The data is typically gathered by enforcing heavyweight, one-size-fits-all processes, such as manual timesheets or mandatory tickets for every commit. Its use can easily turn into individual surveillance and misguided performance management. Indicators focused on efficiency of the development process alone perpetuate an outdated view of engineering as a "feature factory". For all these reasons, we created Echoes. Echoes provides engineering organizations with the data they need to succeed, without compromising the developer experience.
Many existing solutions collect data from GitHub and issue trackers to produce insights, but Echoes differs in important ways:
* We care about the purpose of engineering efforts over the efficiency of the development process. Purpose is defined in Echoes a the set of outcomes your are pursuing as an organization (e.g., reducing the onboarding time for your users) and the initiatives aiming to influence these outcomes (e.g., a templating feature). Echoes publishes this configuration to your development tools of choice (e.g., as repository labels on GitHub, as a custom issue field in JIRA, or labels in Linear) and allows to tag day-to-day efforts with their intent, consistently throughout the organization. Echoes’ focus on purpose makes the reports understandable beyond engineering, and shifts the conversation away from engineering productivity to the collective prioritization choices.
* We strive to answer engineering managers needs without compromising on developer experience, in its broadest sense. We believe that builders should pick the tools and workflows which make them most productive and that management needs should accommodate for that, not the other way around. Echoes’ contract is that engineering efforts be tagged with their intent, but leaves tooling and workflow choices to each team. The resulting reports are team-centric and never about the individuals.
Check out our website (https://echoeshq.com) and introductory video (https://www.youtube.com/watch?v=Y2ochIr4obw#t=58s) to learn more. We offer free trials (no credit card required) if you’d like to give it a try.
We look forward to hearing your feedback and answering your questions. Many thanks!
17 comments
[ 3.9 ms ] story [ 69.1 ms ] threadI've found that often without connecting to actual measurements, it's easy for teams to do dozens of hours of effort where a single hour of that effort achieves the majority of the effect, because when measurements aren't used directly, people will often just throw energy at the problem until it "feels" done. Sometimes this even means all that effort accomplished nothing. This is why I'm such a big fan of Impact Mapping[1].
1. Impact Mapping: https://smile.amazon.com/Impact-Mapping-Software-Products-Pr...
Your question is however absolutely spot on as this is where we going. But in order to measure impact we needed to start by capturing _why_ we're doing what we're doing in the first place, and what we realized is that this in itself was solving a significant pain point for engineering organizations.
I haven't read Impact Mapping, thank you for the recommendation!
Disclaimer : I am running a non profit in my country called "The Maintainers", this is why I look for products that can give more merit to code maintainers.
I'd be happy to show you a demo of the product and how it can fit your use case! My time as engineering manager for the maintainers of the Docker open source project was a significant inspiration in creating Echoes, and I'm very familiar with the difficulty of highlighting maintenance work.
I think there are two different challenges at play:
- For larger organizations, the difficulty to understand how efforts are allocated and get a consolidated view they can communicate across the company. Some example we are seeing 1) balancing product and technical roadmaps (for example in companies who have agreed on spending some % of their capacity in paying off technical debt, but who don't know how to measure that) 2) assessing during the course of the quarter whether "the rubber meets the road" and if we're properly executing against our objectives (avoiding the pitfall of realizing only at the end of the quarter that we got sidetracked).
- For startups, the need to be extremely deliberate in how you allocate your limited engineering capacity. This is pretty much our own dogfooding use case at Echoes (a team of 3), where there's an infinite amount of things we _could_ be doing, but we have to be laser-focused on the things we _should_ be doing. In our case Echoes acts as our compass and a forcing function to stay focused.
We believe that the bottleneck to most organizations is not engineer's productivity but a lack of clarity & focus, and improving the development process alone is a bandaid rather than a solution. In the end Echoes tells you less about the quality of the engineer's work, and more about the quality of the organizational context.