What are engineers working on?
As an engineering manager you’ve likely been on the receiving end of a similar question from your CEO, CPO, or business partner.
In the best case scenario, the question indicates a lack of visibility in how we allocate our efforts. What executive would not want reassurance that we are indeed executing on the company’s highest priority items? In the worst case scenario, the question indicates a disconnect and a lack of trust between technical and business teams. It implies that engineers would, from a certain point of view, be working on less valuable topics.
Project management tools to the rescue?
To answer this question, a common approach in many companies is to extract a view of the activity from the ticketing system or the project management tool (e.g., JIRA, Shortcut, or others). As we’ve discussed in previous posts, this approach is flawed in multiple ways.
The lack of exhaustivity
We’ve covered at length in “the ticketing conundrum” how ticketing systems seldom capture the reality of what teams are working on. Their usage is inherently biased toward the things we plan rather than the things we do. Aware of this issue, many organizations demand that every code change be linked to a ticket for reporting purposes. They soon discover engineers hate it, and therefore find creative way to avoid doing it.
The lack of business framing
We touch on that point in “managing technical debt”: an important step to effective communication is to frame work in terms of desired business outcomes, because that is the granularity executives expect. Another way in which extractions from ticketing systems fail to communicate activity in that they capture outputs instead of outcomes. They may describe the collective sum of actions we’re taking, but not the goals we are chasing.
In practice the question “what are engineers working on?” most often means “how are ongoing engineering efforts contributing to our business goals?”.
Echoes exists to answer this question and many more, and is designed with the following guiding principles.
A focus on outcomes
Echoes focuses on the purpose of work and helps you create this missing link between day-to-day engineering efforts and business goals. It captures the goals you are working toward as a product-engineering organization, and publishes them to a variety of platforms.
Measure activity where it happens
Echoes measures activity where it happens rather than where it is described. In the context of software development, the source control manager is where the majority of work happens. Using Echoes does not require efforts to be reported into third-party systems to be accounted for, which makes Echoes compatible with the variety of ways organizations operate (from having a single ticketing system, to multiple different systems, or none).
Echoes is engineer-friendly: the only action we require from them is to label their contributions within GitHub or GitLab. We integrate with ticketing systems, but strictly in ways which improve the developer experience!
Present information in ways anybody can understand
Echoes presents information in ways devoid of engineering jargon which anybody in the company can understand. Business outcomes are the universal language for the company, not commits and pull requests.
As an example, the Sankey diagram below will show how work is flowing from the organization tree on the left, to the goals on the right. It becomes clear how the Frontend team spends most of its effort on the “Sponsorship program” project, which itself contributes to the DAU and the repeat buying and serve our O1 objective of growing the business.
For a entire view of how the organization distributes its effort, the heat map will present each team and their contributions to company projects and goals.
As engineering managers “what is everyone working on?” is among the questions we hear the most. At its root is the universal need for visibility into the activity, a perennial problem in our industry.
Echoes unique approach creates the missing link between day-to-day efforts and business goals. It presents the activity of your product-engineering organization in a way anybody in the company can understand. It achieves it with close to zero overhead for your engineers, and without mandating the use of a single way to operate.