Can any tool live up to the expectations of being both good for collaboration and good for reporting?

A lot has been written about engineers’ aversion for tickets, best embodied in the widespread rejection of JIRA. This is a topic close to our hearts and to the product we’re building.

The starting point to this conversation is the observation that a product/engineering organization must typically balance:

1. The engineers’ need to get work done in the best possible conditions and with the least possible overhead.

2. The management’s need for data to inform decisions on priorities, hiring, and execution.

3. The stakeholders’ need for visibility into the engineering activity and plans.

Getting work done

If you were to form a completely self-organizing product-engineering team, chances are that they would eventually decide on a tool to collaborate on tasks. Whether they decide to go with GitHub or GitLab issues, Linear, JIRA, Shortcut, or any other is mostly a matter of taste and irrelevant to this discussion. The point is that teams rightfully see value in such task management tools to keep track of work.

Where things break is when we start mixing in the needs of management and stakeholders.

Freewill, or the lack thereof

Let’s talk about #2: the need for management to get data to inform decisions. There’s a sweet spot to be found between navigating in the dark and micromanaging, and it’s not an easy thing to achieve. What modern product engineering practices have taught us is that while managers need confidence that progress is being made in the right direction, progress is best achieved when teams have autonomy on the how.

And so the natural answer is to start extracting the data from the task managers. But similarly to Goodhart’s law, I’d argue that when a team’s task manager becomes the de-facto reporting tool, it stops being a good task manager.

Conflicting needs

Reporting requires two things: homogeneity, and exhaustivity.

Homogeneity is needed to aggregate data across teams, regardless of the size of the organization. The tendency then becomes to force a single task management tool, and a single way of using it, on all teams. Doing so ignores need #1 and the autonomy teams deserve in their selection of processes and tools that will make them most effective in their day-to-day. In some cases this could be considered an acceptable tradeoff, if it wasn’t for exhaustivity.

Exhaustivity is needed for the extracted data to be representative of reality. The tendency then becomes to request all tasks be filed in the tool for the sake of reporting. What originally started as a useful collaboration tool has now turned into a chore. In its worst possible incarnation we have witnessed teams file placeholder tickets to comply with the rules, defeating the purpose of the process which now reports arbitrary data.

Now what?

Our belief is that those needs cannot be easily reconciled with the tools at our disposal, which is why we’ve created Echoes. We solve this tension by:

• Embracing the diversity of processes and tools inevitable at scale, and leaving teams in control of the choices that make them most productive.

• Addressing homogeneity by centralizing the definition of outcomes that teams are collectively working towards, and using it as the pivot for data aggregation.

• Addressing exhaustivity by measuring work where it happens rather than where it is described, with the least possible overhead and busywork for engineers.

• Communicating activity at the right level of details, without micromanagement, and in a way that non-technical stakeholders will understand.

However you want to balance the different tradeoffs, remember that what you decide will be the reflection of what you value as an organization, and ultimately a marker of your engineering culture.