When your boss asks you what you did this week, how do you answer her? Do you look at your calendar for what meetings you attended? Do you search your git history for what commits you made? Do you look at your Jira board and see what issues you resolved?

At Atlassian, for me it was the last option. Jira tickets were how things were planned, tracked, and measured. For a company that was historically an on-premise company, this was a great answer. However, as it evolved into a more dynamic, continuously deployed cloud company, I grew to realize it was time to do better. In the old world of shrink-wrapped software, developers created changes and let someone else deliver it to customers, and often yet another team to manage it in production. This long chain of actions involving multiple teams lent itself well to the more abstract tracking system of issues or tickets. However, what it also did was remove a developer from the customer value they were delivering, negatively impacting the customer empathy necessary for a delightful, intuitive product.

Cloud software platforms, combined with the unification of development and operations in DevOps, has revolutionized how a developer delivers value to customers. Hand-offs are eliminated, allowing a developer to ship their change directly to customers and monitor its impact. I first realized this in 2013 when I joined the HipChat team soon after their acquisition by Atlassian.

I was used to being a good agile citizen, creating tickets, resolving them, and feeling satisfied I was contributing. Very quickly, I realized none of that mattered - the only thing my teammates (and customers) cared about is what I shipped. It didn't matter what meetings I went to or what tickets I closed, only whether I fixed that bug that was bothering that one big customer or improve our onboarding flow to stop losing customers at a certain step.

Furthermore, I was solely responsible for delivering these things. Team members were expected to be part designer, part product manager, part developer, and part operations. It took some adjusting but I quickly took to the new way of working and measuring value to heart. Even later, when I ran a small group in a much larger Confluence team, I found that measuring value in deployments still held true, even if it wasn't quite as smooth with a large monolith.

When I joined Dylan and Michael at Sleuth, I saw an opportunity to encode this new way of thinking into my tools. In the early 2000s, we built Jira to help automate extreme programming and agile methodologies, built around tickets as the core unit of value, and with Sleuth, I see an opportunity to explore and automate a world where deployments are the core unit of value. One early, if not a bit tongue-in-cheek, manifestation of a deployment-centric mindset in Sleuth is the Leaderboard.

The Leaderboard scores team members based on their deployments and the impact of those deployments. Its simplistic method of scoring per deployment, as opposed to measuring the size or issues involved in a deployment, encourages small, frequent deployments, which have been shown by the State of Devops 2019 report to be a hallmark of high performing teams. I knew it hit the mark when, a few days after it shipped, Dylan's deployment frequency increased and he didn't hesitate to playfully let me know I was now number 2 (not shown as I quickly rectified the situation).

The Leaderboard scoring also includes points for the impact of a deployment; so it isn't just about deploying frequently, but deploying with the desired results. Right now we measure that by tracking changes in error rates, but you could see tracking Service Level Indicators (SLIs) or usage analytics as an obvious next step.I'm excited to automate many of the best practices my teams were developing around continuous delivery and DevOps, and I'm not just doing it myself, but with a team of top notch talent, partnered with progressive, innovative customers.

If you were solely measured by what you deployed, how could a tool like Sleuth make you more successful?

‍