Categorizing work

9min

Categorizing work is central to Echoes data collection. There are two aspects to categorizing engineering work:

  • Tagging efforts. Echoes lets you define your taxonomy of work and provides the tools for frictionless and consistent tagging of engineering efforts at scale.
  • Attributing efforts to teams. Engineering success in Echoes is measured at the team-level, never for the individual, which makes the attribution of efforts to teams crucial to proper data reporting.

Tagging efforts

Taxonomy

Engineering efforts are tagged using a customizable taxonomy. How engineering efforts are tagged plays a role in all three aspects of success reports:

  • In measures of alignment by indicating what the work item is about.
  • In measures of delivery in order to compare performance across different areas of work.
  • In measures of health when used by engineers to surface challenges faced during implementation.

The taxonomy consists of a combination of categories and initiatives.

Data consistency

Data consistency for activity reporting is a major pain point, especially at scale. Echoes overcomes this issue by guaranteeing a consistent taxonomy of work across teams and product development tools. Third-party systems are updated live as Echoes configuration evolves. For example, labels and custom fields entries are created as a new dimension node get created; labels and custom field entries disappear as an obsolete initiative gets archived.

Attributing efforts to teams

Default teams

Reports in Echoes are at the team-level, and all registered engineering efforts are attributed to a team. Every organization has two special teams:

  • Organization root. The root of the organization from which other teams can be created. Like any other team, the root of the organization can have members in it (typically the organization's leadership, or anyone who wants to see the activity of the whole group by default).
  • Undispatched contributors. The undispatched contributors team is the team where members get created by default, for example when a new joiner contributes their first pull request. The efforts of that new engineer will be attributed to the undispatched team until they are dispatched to one of the other teams. This also makes it possible for Echoes to be adopted progressively over a large organization.

Effort attribution

Contributors in Echoes belong to one and only one team at any point in time, and always contribute on behalf of their team. This make the teams definition within Echoes particularly important. Every member of the organization has a join date in the team that marks the moment from which this member's contributions are attributed to that team. It is possible to change the join date of a member within a team, and contributions will be reattributed to reflect that change.

Effort attribution is achieved through solely through team membership, and never by looking at the repository where the work was contributed. This makes Echoes compatible with multi and mono repositories setup, as well as with inner source environments.

Frequently asked questions

Categorization can be enforced on platforms that support it.

  • For GitHub, Echoes provides a builtin check which can be selectively enabled to verify if pull requests have the expected labels.
  • For GitLab, Echoes provides a reusable job which can be used to verify if merge requests have the expected labels.
  • For JIRA, the "Echoes - Intent" custom field can be marked as required in the field configuration scheme.

Within Echoes, uncategorized efforts are reported as "Untagged" and can be categorized directly from the product.



Updated 02 Nov 2024
Did this page help you?