February 27, 2023
Engineering is often the function that’s perceived as a “black box.” Lots of important stuff goes on inside, but to those on the outside, they’re not entirely sure what’s going on. Questions continuously arise around which initiatives to prioritize, and what is their financial justification. This concept is not new to us here at Jellyfish, where we talk about aligning engineering outcomes with business objectives on a regular basis. The Jellyfish Allocation model, the foundation to the Jellyfish engineering management platform, is a fundamental look at ensuring that engineering teams are focused on the right things, but with the introduction of Jellyfish DevFinOps, we’re able to add yet another layer onto the allocations model.
As a broader term, DevFinOps allows for leaders within an engineering organization, from team leads and managers up to the heads of engineering and CTOs, to leverage financial data along with Jira/git/ops data, to ensure continuous alignment of the engineering organization with the business. While this may sound like a lofty goal, the reality is that continuously reporting on alignment with the business using a cost basis is both smart engineering and financial management.
In this post we’ll dive a bit deeper into the multiple tenets of DevFinOps beyond annual budget planning and software R&D cost reporting including:
- Roadmap check-ins with automated reporting to continuously align development costs with business priorities:
- Forecasting and anticipating cost changes instead of being surprised by over-budget projects
- Engaging with testing alpha and beta builds to understand what’s working well, and what’s not.
- Performing retrospectives on current software to evaluate resource consumption of maintenance.
Aligning development costs with business priorities on a continual basis
A major aspect to any engineering leader is working with the product management team to determine what work is occurring now, but most importantly in the future. All groups within the company, from sales and marketing, to product and engineering, have an important role to play in helping determine a product roadmap. However, roadmaps are always subject to change based on changing priorities. Leveraging financial data as part of the development process can be done on an ongoing basis, using the development cost data to ensure transparency in the roadmap progress.
Using this strategy ensures that as the engineering teams work on the roadmap, the costs associated with the work are consistently compared to the expectations of the business plan. This methodology allows for greater context to be given in light of new information that may impact the future work later on in the roadmap, or may indicate that complete changes may be needed as a whole in two related ways:
- Monitoring the financial cost data associated with development projects reduces the chance for ‘surprises’ to occur. For example, if more engineers are needed to be allocated towards a new project that’s proving to be especially difficult to complete, tracking not only the allocations (time/effort) but also the cost data associated with that effort helps engineering leaders forecast potential cost overruns. Major go/no-go decisions can be made earlier in development cycles if a project is considered to be ‘not worth it,’ potentially avoiding the often-cited ‘sunk cost fallacy’ of continuing unprofitable projects simply because the organization has invested so many resources in the projects to date.
- A more granular analysis of effort and costs can be applied to testing and understanding the financial implications of production velocity for a given deliverable or project. For instance, being able to analyze financial data as a project goes from an alpha stage build, to a beta stage build, one can better forecast budgetary build costs for future projects, where that budget should be allocated on a timely basis, and understanding if “throwing more resources” at an issue actually expedites delivery or fixes a problem.
Auditing resource consumption for current/maintenance projects
An often-referred to allocations category for many of our customers (and Jellyfish itself) is “Keeping the Lights On,” or “KTLO.” A colloquial term for us, but wildly useful for engineering and product leaders to determine what is “worth it” to continue maintaining.
As organizations grow, introduce new products, and expand their scope, invariably the infrastructure, support, and ongoing development costs of their software projects will grow as well. This expansion of product offerings and an associated code base requires continuous maintenance to ensure that all the current software applications are running in addition to the new shiny stuff that the engineering team has been working on.
It’s at this point where these continuous maintenance costs can start to grow and do so somewhat quietly. The quiet growth can balloon and become much more unwieldy if not audited until it noticeably impacts the business. This type of maintenance work can go by many different names; technical debt, ongoing compliance and security work, technical enablement, even bug fixing post-launch could be considered KTLO.
Associating financial data in conjunction with the allocations data gives technical leaders the ability to know how much effort and resources are being spent on maintaining current projects, as opposed to working on new projects. If an engineering organization is mired in technical debt, with every small change requiring hours of time to remediate nested issues, this may be an indication to establish a plan to continue with fixing issues ad-hoc, overhauling the application, or even retiring it altogether.
Such decisions cannot be made on ‘gut feel,’ or whichever personality shouts the loudest, especially when it comes to intelligently allocating resources to the right things. This is especially important when the KTLO costs are able to be compared to product/project revenue, to ensure that making the right decisions on product maintenance are made with full transparency of the business aspect of each decision.
Where do we go from here?
DevFinOps as a practice is a potential high-water mark for technical and finance leaders to better understand each other in how decisions are made to appropriately allocate resources to engineering initiatives. The continuous nature of looking at the financial implications of engineering’s work brings another dimension to the ‘agile’ nature of software engineering in today’s work. Technical implementation paired with financial ramifications mean that decisions can be made with a quicker, more data-driven approach, that summarily ties back to impact on business performance.
Jellyfish launched its DevFinOps product as part of the Jellyfish Engineering Management Platform, designed to automate and improve the alignment between R&D cost reporting and engineering effort. To learn more about Jellyfish DevFinOps, visit our solution page or request a demo today.
