Hey there! I am Dhruv Agarwal, one of the co-founders of MiddlewareHQ. Today, we’re open sourcing the core of our product - https://github.com/middlewarehq/middleware Being both an engineer and an engineering manager in the last decade I observed that builders are stuck in slightly sized orgs (>40 engineers) and leaders have a meek sense of the blockers. So, I observed 2 types of leaders: micro-managers or gut feeling wingers. The end result in both cases are unhappy and stuck developers. Hence, we built Middleware. This version offers DORA metrics out of the box to help any engineering team get started on tracking their delivery pipeline health (both in speed and quality). Engineering productivity is a complex topic and a crucial decision is to pick a framework which is non-monitoring, non-gameable. DORA metrics fits well right in and being open source Middleware makes it easy to start within your infra/env securely. Looking forward to your feedback and thoughts! Do consider giving a ⭐️ to the repo, means a lot to us 🙂

@Ivan Porollo looks more spam - this is the only comment the poster has ever made, it's an ad, and it's unrelated to AI (generic dev tools project)

It’s in the self promotion channel so it looks fine to me

Hey @Don Alvarez, thank you for noticing it and putting your best foot in maintaining the decorum of the group. I am new to the group 🙂 So nice to e-meet you. Thanks @Ivan Porollo for considering it in good light 🙂

@Dhruv Agarwal I'm actually super glad you're real and not just slack spam (which has been hitting a number of slacks I'm in in clearly automated ways) because the project you're working on is one I care a lot about. Are there ways to add additional scoring metrics? The DORA metrics are obviously the right place to start, but I find having some additional team- and organization-focused metrics gives me a better understanding of where to look to improve my DORA metrics: (1) Mean time (or distribution of times) between raising a PR and starting code review on the PR. In my experience, healthy teams talk internally about what they are doing, and are aware of what PRs are coming and are ready to jump on them. Unhealthy teams neither know nor care about each other's PRs. (2) Mean time (or distribution of times) between code review approved and first deployment to customer. Having watched a lot of companies, latency that happens downstream from engineering is often huge and poorly tracked. Healthy organizations get merged code into customer hands quickly (even if that's a beta or early-access branch). Unhealthy organizations put working code through slow, human, interdisciplinary processes before it can reach a customer (eg. when marketing, customer support, documentation, etc. teams don't start thinking about the deployment until engineering is "done"). (3) Fraction of commits that never PR and fraction of commits that never reach a customer. We're all supposed to be doing lots of experiments and learning from customer feedback and pivoting rapidly, so it's OK (in my experience) to have code that doesn't deploy to the true production branch. That said, in my experience organizations where lots of code never makes it to a customer aren't actually doing real experiments, they're just waffling and failing to make decisions, wasting resources in the process. The main thing I like about these metrics is they are 100% team health/organizational health measures, and if you try to "game the numbers" you're almost certainly going to end up genuinely improving the health of your team and organization. The challenge with them is they can be tricky to measure because you often need to add additional tags or whatever to have a way to measure when some of these events happen. Add in some of the statistical "high performing teams/low performing teams" industry-wide numbers like LinearB has been starting to publish and you've got some really useful insights into team and organization health, which I find is the best way to think about making improvements to DORA metrics.

These are some interesting and valid points @Don Alvarez! Like you mentioned a contrast b/w healthy and unhealthy teams, every organisation is likely to have both. The leader’s job is to create a culture of enabling the unhealthy ones to become healthy 🙂 And that’s where a tool like this becomes handy. The state of devops report by Google publishes their industry standards and we keep our product updated with that to show a score and help you steer the teams in the right direction. The other intent we had was to make the starting point easy, accessible and secure with open source DORA 🙂 Find a glimpse of how it sets up and looks below!