Software Delivery Intelligence: How It Started, How It's Going
Metrics alone do not improve dev teams. For continuous improvement, engineering orgs need visibility, context and workflow automation.
Join the DZone community and get the full member experience.Join For Free
How It Started
Five years ago when I was the VP of Engineering at the second scale-up I had helped lead, software development was identified as more of an art form than something that could be measured. Having been a software developer, team leader, and manager in the past, I didn’t necessarily disagree.
There are many ways to solve for x, and the best developers, like great artists, use a combination of knowledge and creativity to get the highest quality results. But developers also have to make hundreds of micro-decisions every day when building a new feature. I always told my teams, “There is a business decision in every line of code.”
Sales and marketing are forms of art as well, yet the leaders of those organizations at both of my scale-up journeys were very capable of measuring their form of art. As the engineering leader, I knew something was missing.
Metrics Alone Do Not Improve Dev Teams
I was not the only one who wanted a dashboard to help measure the progress of my engineering organization. CTOs and VPs at modern companies either built their own scripts or bought early technology that would help them track engineering productivity.
Unfortunately early attempts at this had a blindspot to the cultural impact when they tried to mimic Sales and focused on individual developers' impact. Which very quickly led to bad culture and undesired behaviors.
During this first attempt, engineering leaders learned two painful lessons:
Measuring individual performance hurts team culture.
Giving metrics only to CTOs and VPs does not improve dev teams.
I knew the engineering community needed to try a different approach. My idea at the time was to bypass individual performance and take a more team-based approach. Software development is a team-based sport at all.
By starting to measure team-based metrics I was able to track meaningful data without hurting the culture I had so carefully cultivated. It was great! I was able to walk into the CEOs weekly staff meeting and present a dashboard just like my counterparts in Marketing and Sales. But now that I was tracking numbers, I had to start showing improvement, week over week.
Building for Continuous Improvement
How can an engineering organization apply data to create continuous improvement?
After I left my second scale up organization, which was acquired by a large company, I couldn’t stop thinking about this question. This was also the time when I reached out to my LinearB co-founder and like-minded friend Dan Lines. We both agreed that software delivery pipeline visibility is great, but it didn’t actually help dev teams improve. We needed to break down the problem before we could understand how to solve it.
There are 3 major levels in engineering organizations:
The Engineering Executive: This role entails setting the strategic vision, creating budgets, hiring, deploying resources and reporting to the CEO.
Supplemental Responsibility: Translating engineering to executives
Dev Team Leader: This role runs a team, manages people, cares about delivery and seeks out multipliers for team-level improvement.
Supplemental Responsibility: Helping the team improve how they work
Software Engineer: Set architecture, develop new features, keep security, SRE, testing, automation et al. top of mind.
Supplemental Responsibility: Helping your teammates
Engineering organizations needed technology that would go beyond metrics and visibility. They needed technology that was going to help translate why engineering leaders needed additional resources for non-functional stories by providing context across development lifecycle systems. They needed a platform that would help team leaders detect bottlenecks for team-level improvement and one that provided developers with the right information in the right place at the right time.
If engineering leaders wanted development teams to improve, they needed a framework that was dev-first and bottom-up, not a top down scorecard. They needed Software Delivery Intelligence.
Software Delivery Intelligence
I had both felt pains due to a lack of visibility into basic data about the performance of my teams and projects. I realized that metrics weren’t quite enough to solve the problem because many teams weren’t sure what the metrics meant and what to do with them to improve. So in 2020 LinearB expanded it's mission and gave it a new name: Software Delivery Intelligence.
Software Delivery Intelligence is the combination of three efforts, each relating to one of the three levels and responsibilities in an engineering organization.
Visibility: The actual responsibility of the VP of Engineering is to translate what is happening in engineering to the other executives. Resource Allocation, Efficiency, progress, cost and forecasting all have to be visualized and translated to the business.
Context: The actual responsibility of a dev team leader is to manage projects across systems. They need to detect bottlenecks in the development lifecycle, unblock team members, keep the work focused and make sure the team is not overloaded.
Workflow: The actual responsibility of a developer is to focus on their craft, own their areas of responsibility, and to understand when other team members need help.
We learned early on that metrics alone do not improve software development teams. We could put all of the data in the world into the hands of executives and still see a lack of improvement. We knew that metrics were never going to be enough. Engineering leaders need context to understand what engineering metrics mean, and they need actionable ways to apply them to create improvement.
As a product, we knew our continued success was based on our ability to complete the continuous improvement cycle. So that’s what we did, and that’s why Software Delivery Intelligence works.
How It's Going
We have discovered a significant way to help software development teams improve how they work. Many platforms provide metrics for dev teams. Our secret sauce is that we complete the continuous improvement cycle by providing project context and workflow automation for the people who are actually doing the work. We built our platform for developers.
80% of organizations improved their Cycle Time by 48% or better after implementing Software Delivery Intelligence
CTOs and VPs of Engineering use our Software Delivery Intelligence platform on a weekly basis to review team-level metrics, and Team Leaders use it to identify bottlenecks and focus the team at the project level. Developers, individual contributors, use Software Delivery Intelligence EVERY DAY because it saves them time.
From Unicorns to Scale-ups, the most modern teams in the world are implementing a continuous improvement culture at the developer level. I am proud to say that over 1,100 dev teams decided to adopt Software Delivery Intelligence in the past 6 months, leading LinearB to a $16 million Series A funding round.
If you’re learning about Software Delivery Intelligence for the first time today, please don’t hesitate to experience it for yourself.
Published at DZone with permission of Ori Keren. See the original article here.
Opinions expressed by DZone contributors are their own.