November 01, 2023
Financial controllers are accountable and responsible for the software capitalization process, but they’re not totally autonomous throughout it. Controllers require engineering managers to aggregate the necessary data for the calculations, and every second that engineering managers spend manually tracking the time they spent on certain projects, or making estimates based on their limited information is a sunk cost to the business. Teams must find a way to get engineering managers out of cost reporting, and back to developing software, while ensuring that the Finance team has what it needs to help the business.
There are several steps that financial controllers can take to ensure the process goes as smoothly as possible. With a little education upfront, finance teams can minimize the back and forth between departments, obtain more defensible data quality, and save your company significant resources.
Having worked with engineering management across hundreds of companies, we’ve found there are commonly shared questions that can slow down software capitalization. In this post, we’ll cover the three most commonly asked questions related to software capitalization, and address where engineering teams could use additional direction and clarity.
Question #1: What work is capitalizable?
Some back and forth is inevitable when it comes to determining what constitutes capitalizable work. As we discussed in our last post, we gave the general guideline:
“The core development work, from the completion of design to product/feature release, related to new products or significant improvements to your current product as capitalizable.” (see original post)
Obviously, this guidance is meant to cover a wide variety of work types. Sometimes similar work from a development perspective varies in its capitizability based on the type of release it’s supporting. The key important takeaway is that it can be helpful to start by examining work based on the objective of the work at the Epic level, then work through if that specific work falls outside type of work (such as design) that is usually not capitizable. Blanket assuming that similar work types across initiatives, projects, and Epics can result in a lot of clarification and back and forth later, so it’s important to coach an approach that avoids this pitfall.
Question #2: What data is required by the finance team?
In short, the finance team needs to know how much time went into certain parts of the development process (post-design until release). The cleaner the data set you use to make these calculations, the easier it is to distinguish if work is capitalizable. It makes the calculations much more precise, making them more defensible during an audit. If you’re asking engineers to time-track, or managers are guesstimating time spent, then the data will be “clean” at the cost of precision.
If you’re using issue-tracking software (such as Jira), the data has the potential to be more precise, but it’s largely dependent how diligent the engineering team is. Good Jira structure and hygiene can help a smooth cost-reporting process. The key step is ensuring unlinked PRs are as low as humanly possible. As much as possible, every pull request should have an associated Epic. With PRs linked, it’s much easier to sort work by Epic and drill down into each ticket as needed for further inquiry.
Question #3: What methodology is preferred?
Before Engineering Management Platforms (EMPs), software capitalization had two primary methodologies. The first involves manually tracking the time engineers spend on capitalizable work through some type of time card system. The second involves engineering managers and developers making educated guesses, based on their limited tools and recollection of the project, about how much time was spent on the capitalizable work. Simply put, we don’t recommend either option anymore, as the first erodes team culture, and the second is imprecise, opening your company up to indefensible data as audits are conducted.
The way moving forward that can reduce time spent on software capitalization by as much as 98% while providing more defensible data is through the Engineering Management Platform. An EMP ingests signals from the tools that developers are using already to develop capitalizable software work.
Building Financial Acumen Across the Business
As every company becomes a software company, it becomes increasingly important for Finance and Engineering teams to better understand and communicate with one another. This means that teams need to continue to voice their pain points in planning, cost reporting, and budgeting throughout the year. Even though it may seem that software capitalization challenges impact the financial controller role, there are significant and quantifiable benefits for the engineering team to make this process more efficient.
Jellyfish has worked with companies like Optimizely, Salsify, and Iterabe to make software capitalization pain points a thing of the past. If you’re curious about how we did this, check out our DevFinOps product tour, or schedule a demo today.
