October 01, 2024
Editor’s Note: This article first appeared in The Current, Jellyfish’s LinkedIn newsletter. You can subscribe for monthly updates and articles like this one here.
Software capitalization categorizes software expenditures into two buckets: capitalizable investments and expenditures that cannot be capitalized. The former includes things like new features or products and / or significant enhancements while the latter includes minor updates, bug fixing, keeping the lights on, and so forth. Capitalizing software expenditures involves recording these capitalizable costs as long-term assets (amortization), rather than realizing the expense of these efforts in real time. This process helps businesses match the costs with the benefits received from the software over time and ultimately provides a financial boon to the business.
Capitalizing software isn’t controversial. It provides immense benefit to any business that develops software for either internal or external use. But the means of doing so can be a sticking point between the parties involved: finance and engineering.
The software capitalization process has historically involved either time tracking with the use of a tool like Tempo or through estimation – as either a percentage of roadmap or distribution of the engineering team’s time.
Neither is it ideal. For engineering leaders, time tracking often contributes to decreased team morale, increased attrition, and even recruiting challenges – all of which can be extremely costly. For instance, replacing an engineer can cost 2x retaining an existing hire and take anywhere from six to 12 months.
So what are well-meaning finance leaders and their engineering counterparts to do when it comes to software capitalization? They must take a more collaborative approach to software capitalization to save time (and their sanity). Here are essential communication best practices your team should follow to make the process of software capitalization even efficient.
1. Ensure Everyone Understands the ‘Why’ of Software Capitalization
For many engineering leaders, one of the most frustrating parts of software capitalization is that they’re asked to collect and report on specific data without fully understanding the end goal.
If your teams are struggling with software capitalization, take a moment to pause and have finance explain why it’s important to report on software capitalization. Similarly, be sure everyone knows the risks that go along with poor or inaccurate reporting. Ie why is software capitalization important in general? Why is it important to your company, specifically?
While this might sound rudimentary, making an effort to ensure everyone is aligned on the “why” of software capitalization sets a precedent for better collaboration and more open communication between both teams.
2. Collaborate on Granular Details at the Beginning
Finance must provide specific, detailed evidence around software capitalization — which is often at odds with how engineering teams approach and track work. To avoid misunderstandings down the line (or, even worse, risk finding that teams haven’t tracked work at all), finance should meet with engineering leaders early to align on how they can get the inputs needed from engineering with enough context to defend those inputs.
This meeting should be collaborative and conversational. You should make sure everyone knows the answer to the following questions before the reporting cycle begins:
- What individuals and/or teams do we need to report on?
- What individuals and/or teams are not necessary to report on?
- What contextual information do we need to support reporting?
- Is everyone aligned on critical financial requirements?
- How will finance and engineering collaborate to ensure the proper categorization of work and depth of information is provided?
While finance does not need to lead the charge in determining what mechanism(s) engineering teams use to track capitalizable work in Jira, for example, finance leaders must be familiar enough with engineering processes to facilitate informed conversations.
3. Make Sure Everyone Understands Their Roles and Responsibilities
Everyone involved in reporting needs to know their role and how to do it accurately. Taking extra care to ensure good change management and understanding throughout your teams can reduce the likelihood of finance doing corrections or chasing people down for answers after a deadline has passed.
While it varies from company to company, you should confirm that all engineering leadership is clear on their roles and responsibilities within the software capitalization process.
While less frequent, teams should also make sure to communicate when any new processes are introduced or when major revisions come through.
4. Keep Up Regular Communication
Regular, proactive communication about software capitalization efforts can save engineering and finance leaders from small misalignments or misunderstandings that escalate into more significant problems.
In addition to strategy meetings that cover the “why” and execution details around software capitalization, teams can hold regular “data hygiene” meetings that cover topics such as:
- Is there anything surprising or that feels directionally off we should investigate further?
- Is there any data missing that we still need to collect?
- Q&A session: This is a no-judgment period for team members on either side to ask “stupid questions” and further break down cross-departmental language barriers.
While each company should establish its own best practices and procedures on meeting format and frequency, intentional, regular communications can serve as an opportunity for finance and engineering teams to build a better working relationship that extends outside of software capitalization initiatives alone.
Jellyfish makes it simple to combine financial workflows with your development work and automatically generate reports on software costs. Ready to learn more about DevFinOps? Get started here.
Looking for more insights like these? Subscribe to The Current from Jellyfish on LinkedIn to explore the trends and technologies shaping engineering organizations.
