Recently, we published a post for finance leaders on how to break open the black box that is software development. Now, I’d like to share some guidance for their technology counterparts on how to avoid being perceived as a black box in the first place.
First, let’s review the issue at hand from the perspective of technology leaders. Software development has, over the past decade or more, become the fastest-growing and largest expense line item in virtually every industry. The professional management of software development is a relatively new field, continuously evolving as software development itself has continuously evolved. Many technology leaders began as developers and have grown into leadership roles as they’ve progressed in their careers.
Part of the issue is that the way software developers have been taught to measure their own productivity does not align with the way the business measures the value of their work. Agile/DevOps metrics are aimed to optimize how efficiently a development team operates, but don’t necessarily speak to whether the outputs are aligned with the business’ strategic goals. And while such operational and activity metrics measure defined development deliverables, they fail to take into account the time spent on the front-end or back-end of the software development lifecycle, such as business approvals, testing, release etc, which are often where the most time is spent in the software development lifecycle
While a technology leader might optimize for, and delight in, metrics around the number of deploys in a day or number of lines of code written in a given period, these metrics do not translate into business outcomes in a way that finance leaders can understand. This is why software development, to finance leaders, is seen as a ‘black box.’ But it doesn’t have to be.
It’s not that technology leaders just like to be elusive or cagey towards their outcome-driven business counterparts. It’s more likely that technology leaders feel obligated to defend their development teams and the rising costs associated with them. However, the larger question at hand is, “What business outcomes have resulted from these increased investments in software development?”. If a technology leader isn’t already explicitly measuring those outcomes, they instead feel compelled to answer, “What have your people been doing all this time?”
Rather than feeling in a position to defend their teams, technology leaders can proactively communicate, optimize for, and structure activities to encourage transparency and give business leaders the insights they need to justify rising development costs. When technology and finance are on the same page, everyone wins.
Here’s how technology leaders can avoid being a ‘black box’ to the business:
Talk the Talk: Focus on Delivering Business Metrics
Aligning the way software teams measure their performance with the way the business measures it, can go a long way. No matter how impressive they are (or how useful they are to development teams), DORA metrics will never be able to justify or quantify software development costs. To do this and therefore keep progress moving forward, technology leaders need to embrace the outcome-driven “talk” the business uses. This means working with business leaders to establish realistic Objectives and Key Results (OKRs), and reporting business metrics that actually relate to outcomes.
Stable-Fund Products, Not Projects
Technology leaders have been saying it for years: When it comes to delivering software-enabled customer experiences, it’s not about optimizing costs. It’s much more nuanced than x dollars in equals x dollars out. There’s long been a disconnect between the real value of software development, and the way that work is funded: Funding by projects might help make the numbers neat, but it doesn’t reflect the reality of the business.
Project-based funding can put technology leaders on edge, because it makes it seem as though all resources are fungible; as if the work and the people performing it are interchangeable (something technology leaders know to be false). One of the goals of Agile is to maximize value for the customer. But when we fund by project, we often stop funding a piece of work – declaring it done – before it actually starts to generate value. Strict plans declare a false end date that doesn’t reflect the actual ending of the value that we funded to create. Moreover, because governance is tied to an approved plan, teams are incentivized to stay on budget on time and on task, instead of driving actual business outcomes or increasing customer satisfaction.
This structure also puts constraints on flexibility and agility, increasing overall waste. With heavily governed project-based funding, the people doing the work don’t have the ability or motivation to react to new information and quickly shift focus and budget. When adaptations need to be made, it requires lengthy change management processes and there are limited opportunities for teams to abandon the project until the next planning cycle. This means time, money and resources are wasted on the goal of simply ‘completing the project’ rather than providing the opportunity to invest in a new solution or approach that will ultimately deliver more value.
Instead, finance organizations should move to the stable-funding of products: Funding an outcome and providing persistent teams the ability to stop, change, or extend their work to achieve the business outcomes of the product. Aligning the way we fund software development work with the way products actually exist in the world, can help technology leaders prove the true value of their work. The continuous flow of budgeting and planning includes space for incorporating new data, feedback, and information, and pivoting plans accordingly to meet shared, defined goals. This approach reduces costs, improves delivery times and increases engagement when collective business objectives are met.
Visualize the Flow of Value with Flow Metrics
Finally, both technology and business leaders would be better served if we stopped treating the collection of technology metrics and business metrics as two separate, unrelated efforts.
As mentioned above, one way to encourage clearer communication between teams is to use OKRs to naturally tie software development objectives to tangible business results. The more we practice drawing connections between technology and business metrics – the less software development will be seen as an elusive black box.
A key part of this is communicating operational metrics differently: Developing a core set of metrics for tracking the flow of business value in software delivery, and providing a mechanism that correlates the investments for an individual product’s value stream with the business results for that value stream.
Visualizing the flow of value in a software development process may not be as easy as watching value flow on a manufacturing floor – but that doesn’t mean it’s impossible. Thanks to the vast number of data and visualization tools at our disposal, it is possible to make software products and their value streams just as visible as production lines.
The Flow Framework, created by Dr. Mik Kersten, addresses the pivotal challenge of breaking open the black box of software development and bridging the gap between business and technology to optimize the flow of business value to customers.
