Org. chart & git contributor mapping

The team structure is critical for understanding ownership, effort distribution, cycle time, throughput, and other health metrics and collaboration patterns. We provide manual and automatic solutions to keep your team structure up-to-date.

Getting a clean list of active contributors

After connecting your repositories, Codigy will analyze the list of contributors. Duplicates will be automatically merged to the best effort (i.e. engineer who contributes from the office environment and home environment). New contributors that appear after onboarding will go through the same flow.

Team & Tribe formation and updates

Automated: If you connect your WorkDay account, Codigy will automatically create teams, tribes(domains) and assign contributors with a 96% accuracy.

• Visual map will help you check the accuracy of automatic mapping;

• Dashboard notification will request human attention in case automation couldn't handle some contributors.

Manual: If your organization is not too big and your employee churn is low, you can use the interface to arrange contributors into teams. 

• Dashboard notification will remind you in case active contributor is detected, who is not assigned to any team.

Contributor entity

We've made an effort to prevent using Codigy in the wrong way. We purposely hide work hours and individual activity. Our apologies to productivity-frenzy managers, we don't believe this has anything to do with Engineering efficiency🤷‍♂️

Things that we track:

1. Last active stamp - the last event detected and processed by Codigy. Helpful indicator while configuring/updating team structure & merging contributor sources.

2. Source indicator - shows if there are any unconfigured sources that look similar (potential merge target, i.e. if an engineer is contributing from an alternate GitHub account).

3. Burnout indicator - shows if there were at least two days within a week, where no actions were detected from the selected Engineer. While it doesn't cover 100% of cases (Codigy can't detect work made outside of git), it can be a handy indicator to keep the team healthy.

4. Factual ownership - calculated per contributor, per file. Passed into the overall repository, module, team, and tribe stats.

5. Activity & Impact - all artifacts are automatically passed into the overall repository, module, team, and tribe stats.

Actions:

1. Merge - any number of sources can be merged. Some events can be identified as separate sources (i.e commits, PRs, and comments could be grouped under three different sources). Codigy will automatically merge this, but manual merge is also available for edge cases. 

2. Link with dashboard user - this associates the contributor with a dashboard user. The user's Name and Profile picture will be displayed in analytics, this helps make maps and insights more readable for your colleagues.

3. Team - each contributor can be assigned to a single team. A contributor can be re-assigned or unassigned at any time.

4. Exclude from analytics - contributor will be unassigned from the team, and activity and impact artifacts will be ignored. Factual ownership will be counted but displayed under the label "Unknown contributor".

5. Remove from the organization - contributor will be unassigned from the team and removed from the account. All activity and impact artifacts will be left associated with the team & tribe entity. Factual ownership will be converted into Lost Knowledge.

Team entity

A team is a group of engineers. It is the key entity for which Codigy will track metrics and produce analytical insights.

Tribe entity

A tribe is a group of teams. It's an optional organization unit usually used in larger organizations.

If your organization is using this, you will be able to:

• Group your Teams into Tribes (Each Team can belong to a single Tribe);

• Pivot insights for All tribes or by Individual Tribe.

Handling insights & metrics on re-assign:

If a contributor or a whole team gets re-assigned:

• All metrics related to activity & impact (i.e. cycle time, throughput, issues, features) that were collected will be saved for the old entity, new data after being re-assigned will be associated with the new tribe/team.

• Factual ownership gets transferred to a new entity. In example, if a contributor had 100% ownership in module X, this will be removed from the old team and added to a new team upon re-assign.