Uplevel Labs provides early access to the new Uplevel insights for you and your team:

Deep Work Variation

A healthy amount of average Deep Work time is important to be able to focus and dive deep into projects. The average daily Deep Work hours may mask underlying daily or weekly variability that impacts people’s feeling of productivity and connectivity. Some people may want approximately the same amount of hours per day, some may want a day each week without meetings, and others may want something different depending on what projects or stages of project they’re involved in at the time. There is no good or bad amount of variability as long as people have sufficient Deep Work time arranged in a way that they personally can best make use of it. And the variability requirements for a person may change over time. It’s good to check in every so often to discuss whether the variability is conducive for focus.

Knowledge Silos

Knowledge silos can be detrimental to an organization. A person could exit the company, leaving a critical knowledge gap. They could also simply go on vacation, and code needs to be updated in their absence. One proxy to detect these silos is to inspect the percentages of individual contributions to a given code repository. If a single person has contributed a large share of the code, then that repository is at risk of being a knowledge silo.

Assumptions:

• 6 months of code merged into the repository through PRs
• Lines added and deleted are given equal weight
• Only authors are considered
• 1 PR per month over 6 months was required for each repo to be considered active
• Repositories estimated to be personal repos were removed
• Max of 16 repos shown

Risk bucket definitions:

• High risk: greater than 96% contribution from a single person
• Medium risk: 85% to 96%
• Normal: less than 85%

Release Cadence

This includes the frequency of 'releases' per week from the past 3 months for the most active repositories. Since we do not yet capture external CI/CD data, the release is estimated as a branch in git that meets one of the following criteria:

• A branch name that includes 'release', 'production', 'distribution' (but does not include 'prerelease') or a versioning pattern that matches '#.#' or '#.x'
• The most frequent final branch that commits are observed to be merged into over a 6 month period

Only the repos with the most frequent releases are shown for clarity.

Release Cycle Time

The release cycle time is defined as the difference between the first commit and eventual merge into an estimated release branch. This data includes PRs created and released within the past 3 months for the most active repositories. The release cycle time should be considered a potential lower limit to the dev time, as this does not take into account time worked before the first commit or any subsequent CI/CD mechanisms.

The release is estimated as a branch in git that meets the following criteria:

• A branch name that includes 'release', 'production', 'distribution' (but does not include 'prerelease') or a versioning pattern that matches '#.#' or '#.x'
• The most frequent final branch that commits are observed to be merged into over a 6 month period

Only the repos with the most frequent releases are shown for clarity. The shaded region per repo represents the 25%-75% percentiles of the cycle time, and the vertical bar is the median.