icecrime

We were happy customers with my startup (before we died).

Unleash does a lot more than it seems on first look. It helped us a ton as we were shooting in all directions searching for pmf.

Most tools in this space are about the efficiency of the development flow, sometimes down to the individual's level. With Echoes we're trying a different angle which is less about the efficiency of the process, and more about the value and the impact of our efforts. We are deliberately staying away from anything that could be interpreted as a proxy for individual performance.

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.

Absolutely! We have among our customers a YC company who uses Echoes exactly for that purpose. Their issue was that every two weeks during all-hands, engineering would present a list of merged GitHub pull requests which everyone would applaud to show support with little understanding of what it contributed to. Echoes helped them materialize the missing link between the day-to-day engineering work and the strategy. As you put it perfectly, it creates more visibility and more empathy across functions, and we're quite proud of that :-)

Interestingly we originally designed the product for companies of 50 engineers and above, but we quickly had to add a self-serve onboarding as we were seeing unexpected interest from startups as small as 6 engineers.

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.

That's not currently in the plan, but as Echoes models the engineering organization you could easily see how much of your engineering capacity goes toward maintenance versus new features.

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.

Our model of a unit of effort typically originates from a commit. Deployments are declared through an API: because we already know the commits, and most importantly their intents, this tells us what a given release aims to achieve. The next link is to connect that to observable impact.

I certainly hope too, especially as those teams are typically at the crossroads of every initiative and therefore unfairly perceived as "what is slowing us down" rather than "what carries everything else". Echoes can shine a light on their contribution, and on the challenges of being in the middle of it all.

At this point Echoes doesn't let you connect goals to actual metrics. In other words: we measures efforts invested into the goals, but not the observable impact of these efforts (yet!).

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!

Thank you! :)

Hi, author here! Appreciate the comment, we'll work on our copy.

Most companies have a quarterly planning cycle which starts with setting goals, ends with collecting results, and in middle is most often a blurry mess of juggling between priorities and the reality of the day-to-day.

Our customers choose us because getting consolidated visibility on how we allocate engineering efforts in a way engineers don't hate is an unsolved problem. Yet without it, your decisions and plans are very much based on hope and gut feelings. Our belief is that most organizations are held back by a lack of alignment, and a disconnect between planning and execution: if we can help prevent just one team chasing the wrong topic for a month, then the cost is well amortized, and for large organizations that is a no brainer.

We also have small startups adopting us because it helps them shine a light on the engineers work in a way that the non-technical groups understand. Their use case is less about decision making (because the uncertainty isn't so high when the number of engineers is <10), and more about communicating the value of their work.

Hope that helps!