[HN Gopher] Launch HN: Echoes HQ (YC S21) - Developer-friendly a...
___________________________________________________________________
Launch HN: Echoes HQ (YC S21) - Developer-friendly activity reports
Hi HN! I'm Arnaud, founder of Echoes HQ (https://echoeshq.com).
Echoes lets you connect engineering work to its intent directly
from your product development tools, and uses this information to
create activity reports that focus on the purpose of engineering
work. 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!
Author : icecrime
Score : 79 points
Date : 2022-04-25 14:42 UTC (8 hours ago)
| mehdim wrote:
| We have never been successful showing that internal maintainers
| of the legacy were the ones really paying the bills and
| delivering the current value of the company. Fame and payroll was
| mostly towards the cool engineers working on new tech not yet in
| production serving real customers. I hope Echoes helps giving
| merit to the one contributing to the economic value of the
| company
| icecrime wrote:
| 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.
| mehdim wrote:
| What is the "Unit of technical/economic value you identify
| for that? You do it at the Commit level? Build? Deploy?
| icecrime wrote:
| 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.
| mehdim wrote:
| Nice. Do you plan to match it with marketing/sales budget
| per product line or Business unit? To be sure that the
| effort of "maintaining legacy" is equally measured versus
| over funded efforts on new features for growth?
|
| 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.
| icecrime wrote:
| 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.
| mehdim wrote:
| Yes! an "Echoes for Open source" contributions may be one
| day. Nice work btw, I will try Echoes with my team.
| 0xferruccio wrote:
| At what number of engineers does this become important to do? I'm
| curious to learn at what stage and employee count do you see
| companies struggling the most
| icecrime wrote:
| 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.
| quaunaut wrote:
| I love the shift in focus, specifically toward what your
| organizational goals are. However, it isn't clear to me where
| many of these metrics are coming from- are they manually input,
| or is it possible to connect them to a data source?
|
| I'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...
| icecrime wrote:
| 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!
| czbond wrote:
| Finally - someone who GETS it. There is a huge gap in
| stories/epics relentless grinds to map them to context - which I
| feel is often lost. EM's and PM's in many cases are not the right
| personalities to communicate this context well, so I like your
| effort.
| icecrime wrote:
| Thank you! :)
| AnhTho_FR wrote:
| Awesome, I think it can also help other non-tech teams to have
| more visibility and empathy towards what engineers are building,
| right? Have you seen this use case?
| icecrime wrote:
| 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 :-)
___________________________________________________________________
(page generated 2022-04-25 23:01 UTC)