☕ The Blend - Issue #8

Welcome to the Issue #8 of The Blend ☕!

In this issue, we are continuing the journey into the metrics. In a previous newsletter I’ve shared how can we divide metrics into 3 different groups (crawl, walk, run). This time I am going to share what metrics I am tracking, why and how can you influence them to the benefit of your team.

We are going to tackle the most important ones, giving you the best overview of what is going on in your team. Let’s start with the WHY, and understand what are measuring for in the first place. Engineering metrics help us:

1. Track the performance over time. It gives you the ability to spot trends, making more data driven decisions. (Examples below)

2. Identify bottlenecks. By measuring various aspects of the SDLC, teams can pinpoit where bottlenecks are occurring, whether in coding, reviewing, testing or deploying.

3. Improve productivity. Metrics can highlight areas where processes need improvements or be streamlined. Ultimately enhancing productivity of the whole team.

4. Predictability. By analysing historical data, teams can make more accurate predictions about project timelines.

5. Continuous improvement. Regular measurement and review of metrics enable teams to engage, iteratively refining their processes.

6. Alignement with business goals. Metrics help ensure that engineering efforts are aligned with the broader goals of the organisation. They can demonstrate how technical work contributes to the business objectives.

Engineering metrics

Now as know why engineering metrics are important, let’s dive into the metrics themselves. I’ll start with the metrics that in my opinion is one the most important ones:

CYCLE TIME - represents the average time Pull Requests have spent across the ‘in progress’, ‘in review’, and ‘ready to merge’ stages before being merged. It’s the amount of time from when work starts on an item (like a feature or a bug), until it is delivered. It indicates the efficiency and speed of your development process. It helps you identify bottlenecks and highlights the team’s ability to deliver.

PULL REQUEST IN PROGRESS - represent the number of pull requests that are currently open and being worked on. It helps in understanding the workload of the team and the distribution of tasks. (Too many open pull requests can indicate bottlenecks in code review or testing)

TOTAL THROUGHPUT - Measures the number of items completed in a given time frame (The total number of merged PRs). This metrics is crucial for comprehending team’s productivity and can assist in planning capacity and making future projections.

TIME TO FIRST REVIEW - This measures the time it takes for the first review to happen on a pull request after it was requested. It’s an important indicator of how quickly the team responds to new work and can highlight issues in the review process.

MERGE TIME - Tracks the duration from when a PR is approved to when it is actually merged into the main branch. Shorter merge times can indicate a more efficient code review process and a healthy flow of work. Depending on the workflow, it can also indicate how long the ticket is going through a QA process, as it passed the Code Review, but is still being tested separately form the main branch.

Investment of time balance. This metric looks at the balance of time invested in different activities (new feature development, technical debt reduction, bug fixing, etc.). It’s crucial for strategic planning, ensuring that the team's efforts align with the company's goals and priorities. This metric is super interesting, as when looked at from a really high perspective (a year) it can show things like (based on the example above):

• the team tends to work more on bugs in the summer months, where application usage is slower due to holidays

• most of the work on the new features in happening in the last 2 months of the year, yet again, due to slower period, making sure there is a lot to shout about in the new year from the marketing perspective.

This quote is commonly attributed to Peter Drucker. It emphasises the importance of measuring performance in order to identify areas for improvement and drive progress. For even more in-depth understanding of how your team performs, you should combine code-related metrics with people-related metrics.

As we all know, engineering teams are creating value collectively. Yet to understand the full picture you also need to work on individual metrics. The most basic and important one is eNPS (Employee Net Promoter Score). eNPS provides a numeric value that represents the overall employee satisfaction within an organization.

There is MUCH MORE you can learn about your team, and understand the whole picture. It can help you with:

1. Understanding Employee needs. Metrics like 'Personal Growth', 'Recognition', 'Relationship with Peers', and 'Happiness' provide insights into what employees value in their workplace. Knowing this helps manager create a better work environment that supports the personal and professional development.

2. Improving retention. Factors such as 'Satisfaction', 'Alignment', and 'Ambassadorship' are linked to employee retention. By tracking these, a company can take proactive steps to improve employee loyalty and reduce turnover.

3. Enhancing productivity. Engaged employees are typically more productive. Metrics like 'Wellness' and 'Relationship with Manager' can signal areas where improvements could lead to higher productivity levels.

4. Identifying problems early. A low score in any area, such as 'Relationship with Manager', can serve as an early warning system for deeper issues that could affect employee morale and productivity if not addressed.

5. Aligning with Company Goals: 'Alignment' measures how well employees' personal goals match the company's direction. High alignment can enhance team cohesion and drive towards common objectives.

We’ve learned know ‘WHY’, now let me tell you ‘HOW’

This part of the newsletter will be quite short, as I want to give you low hanging fruits. There are tons of products that can help you achieve all that, and understand the metrics. I’ve been using many of them, but there are 2 that stole my heart:

1. Swarmia - this tool integrates with you Github repository, and your project management tool ( I use Linear - you can learn why 👉🏻 here ), and Slack. It is super easy to install, and get ton of value straight out-of-the-box. It scans your repository, and based on each activity it gives you a historical overview.

2. Officevibe - it’s a tool that helps leaders like myself, understand the engagement and performance of each team member. I’ve been using 15five.com before, but Officevibe stole my heart, and gave me much more value and better integration.

Make them stick

I’ve written an Linkedin article, explaining why Working Agreements are great ( You can read it 👉🏻 here ). After you get your first metrics about the team, the next step is to optimize them, and keep the continuous improvement mindset.

Swarmia has a built in feature to track the defined rules. Working agreements are meant to be 'habits’ for your team, and like all habits, you need to make them easy to follow ( Swarmia has them predefined, so you don’t have to think about it ). They need to reflect what type of team you are. Saying out load that “We are the team that…” builds the identity and culture.

These are working agreements that helped me and my team to deliver more and keep the continuous improvements:

1. We are the team that… merges PR’s in less then 7 days

2. We are the team that… avoids pushing directly to main branch

3. We are the team that… limits the in progress to max 10 PR’s

4. We are the team that… links all PR’s to issues

5. We are the team that… reviews PR’s in less than 2 days

This approach creates the environment of accountability, and helps optimizing the metrics.

How to stay on top of everything?

What is best, is the fact the Swarmia integrates seamlessly into your workflow. Each day you’ll se a daily digest of all the things that are important - how many PR’s are waiting to be reviewed, how many is in progress, and it will show it agains the defined working agreements.

🏁 Stay curious

That will be all, when it comes to basic and fundamental metrics of engineering teams. Please remember about the wise words from Charles Goodhart: