At some point, everything a business does affects the CFO. It’s no wonder, then, that any discussion of new technology involves the need for the CFO to be aware of, and at least rudimentarily, familiar with the technology.

When was the last time a CFO sat in a workshop explaining the cryptographic underpinnings of blockchain? Or the difference between supervised and unsupervised learning models in AI? They may not need to, and yet… When it comes time to evaluate the ROI on implementing an AI framework, it’s possible that the difference between, say the learning models for AI, become relevant. Which one is quicker, better, cheaper or burdens the organization with less future technical debt? While it’s definitely not a finance officer’s mandate to know the technical details, it is their mandate to have a very close and candid relationship with their VPs of IT, CIOs, CTOs and Directors of Engineering, and to have a framework for evaluating new technologies.

There are multiple, often competing, aspects to consider when new technology rises to the level of the CFO: impact to revenue, impact to the bottom-line, cybersecurity, change management and alignment with strategic goals, to name a few. Managing these priorities in forecasting the benefit and cost of new technology becomes an exercise in iterative community and consensus-building.

Establish and Communicate the WHY

We live in an endless sea of technology and software today. It’s no longer a question of “to technology or not to technology;” it’s about which one and where. So CFOs must ask why, which should lead to conversations of what technology, and where it should be applied. It’s possible that the suggestion is simply a distraction that solves only one person’s problem. If it’s not furthering the organization’s goals, no point in entertaining it further.

If, however, the answer is compelling enough, then start to ask this question over and over again to all the stakeholders. This not only helps to identify flaws in the logic of implementing the technology but also to bring stakeholders into the conversation and evaluation process. The benefit is easing the likelihood of process changes that may result.

Finally, if all key stakeholders have bought in, shift into communicating that WHY so that everyone understands that reason. While not everyone will accept the changes whole-heartedly, there’s a sense of finality to the decision.

Understand and Push on Implementation Nuances

There are multiple ways to implement any given technology, and it’s quite important to understand these. The first one is a build versus buy evaluation. If you have a team of developers, it’s likely that they’re not waiting for another project to implement; hopefully, they’re engineering for revenue impact. 

In the event you have the flexibility to scale your engineering department for this, then plan on multiple sessions with your CTO or Director of Software Engineering. They’ll recommend ways of building this out with time and effort estimates, but lost in those conversations may be the need to set up continuous integration. When you learn that your engineering team will need to build automated tests for continuous integration, you’ll wonder if that time and effort were already built into the original time and effort estimates.

On the flip side, if you’re buying software—the nuance between a perpetual license vs. annual license and service contracts may be the nuances. Or alternatively, you’re looking to host the software on-premise, but you may want to see if you could run the perpetual license on the cloud on Microsoft Azure, AWS or Google Cloud.

These nuances can make a project worthwhile or worthless in the long term both in terms of hard dollars but also your teams’ mindshare.

Remove Barriers to Implementation and Adoption

One of the most difficult aspects of technology after gaining initial buy-in is growing adoption and increasing use. In SaaS companies, the M(D)AU (monthly/daily average user) is a KPI everyone looks at. Having a similar metric for internal adoption would be amazing but this is unlikely. Here, the messaging depends on whether the technology is organization-wide (such as automated time and expense reporting systems) or if it’s a new tool for employee benefits and is more optional.

If the answer to the WHY earlier is such that this tool is expected to elevate the organization’s performance as a whole, identify key metrics and develop a framework to track and grow the adoption. It could be a blanket policy update that forces everyone to use the technology, or it could be routine training, or establishing internal support for that technology.


Parting note: there’s a lot of software out there that’s free to use which individual users in your organizations are likely already using to make their lives easier. For the most part, this is not something that will rise to the CFO’s level. However, this kind of crowdsourced technology adoption can actually be a blessing in disguise. If there’s technology that someone uses and swears by it, find ways to make that common knowledge even if it’s within that one department or team, so long as additional adoption isn’t going to create a material cost burden.

If Lakelet Strategy can help you with establishing a framework for evaluating technology, send us a note.