Your Accountant is not a Software Consultant (and Neither Is Their IT Guy)

Let’s begin with a truth bomb:
Just because someone fixed your spreadsheet doesn’t mean they’re ready to lead your digital transformation.
And just because your accounting firm has an IT department or what they call a “Digital Team”, doesn’t mean it should be billing you for software strategy.

The Accountant’s View of IT: “Ugh, Overhead”

Here’s the thing about accountants: they love tidy books, cost efficiency, and overhead so low it has to duck to get through the door.

To them, IT isn’t a business enabler.
It’s not a driver of innovation.
It’s not even “technology strategy.”
It’s… a cost centre.

Ask them about IT, and you’ll hear things like:

  • “Why do we need five licenses for Power BI when we already have Excel?”
  • “Can we reuse this software subscription for multiple people?”
  • “Let’s move everything to the cloud. I heard it’s free.”
  • “Maybe we can outsource this offshore or use someone off Fiverr?”

The Dangerous Evolution: Internal IT Goes Billable

Here’s where it gets weird.
Despite seeing IT as a necessary evil internally, some accounting firms are now trying to resell their internal IT staff as a “value-added service.”

They’re billing clients for:

  • Basic SharePoint configuration (“enterprise portal solutions”)
  • Help setting up cloud software (“digital transformation initiatives”)
  • Setting up a Zap in Zapier (“custom workflow automation”)
  • Installing QuickBooks (“systems integration architecture”)

You’re not an MSP. You’re not a software firm.
You file taxes. You audit books.
Stay in your financial lane.

Core Competencies: Let’s Not Pretend

You wouldn’t trust a developer to reconcile your general ledger. So why are accounting firms pushing their helpdesk analyst to lead software advisory calls? This is what happens when a firm tries to monetize every non-billable human on payroll. IT becomes the office equivalent of the office microwave: underappreciated, overused, and somehow responsible for everyone’s mess. When the core competency is finance and not technology, you don’t have the mentors, practices, training, expertise and experiences to advise clients outside of what was previously done at the firm. This isn’t an issue that is limited to IT, other specialized areas like HR become “billable” under accounting firms. Just because a firm has an HR department doesn’t result in them being “People and Culture” experts. It’s funny how if the reverse happened, it would be more obvious: Software company now offers tax filing.

Clients Can Tell (Trust Me)

Your clients aren’t stupid. They know when the person “helping” them migrate systems doesn’t understand their business needs or the software they’re paying for. If the only recommendation is “try turning it off and on again” followed by an invoice, congratulations—you’ve now become a parody of value-added services.

IT Is Not Just a Cost (When Done Right)

Here’s the irony: If accounting firms treated IT as a strategic partner instead of an expense to be recouped, they might actually innovate. But instead, they try to slap a billable rate on Chad from IT for setting up email folders and call it “digital consulting.” Spoiler: Chad is not amused. And neither is the client. The software space is very complex and constantly changing, very much like the tax landscape. Staying on top of it is a commitment to lifelong learning which has to be focused and targetted because we can only be experts in so many things.

The Takeaway

  • Accountants should stay laser-focused on what they do best: numbers, compliance, and helping clients not get audited into oblivion.
  • Leave software architecture, systems integration, and product management to professionals whose job isn’t tied to the fiscal year.
  • If you’re an accounting firm trying to make your internal IT staff billable—stop. It’s not strategic. It’s just awkward.
  • If you’re a surgeon, don’t offer haircuts, if you’re a chef, don’t offer pest removal, if you’re an accountant, don’t offer software consulting.

100% Canadian, 0% Offshore

In today’s globalized tech industry and crazy political landscape, it’s not uncommon for companies to be influenced—or even controlled—by outside investors or foreign interests. That’s why we’re proud to say: our software consulting company is 100% owned and operated in Canada.

This isn’t just a tagline—it’s a reflection of our values, our independence, and our deep commitment to the clients and communities we serve.

What It Means to Be 100% Canadian-Owned and Operated

Being fully Canadian-owned and operated means that every decision we make, every line of code we write, and every solution we deliver is guided by a team that lives and works right here in Canada. We’re not beholden to offshore stakeholders or external investors. Instead, we’re accountable to our clients, our team, and our shared vision for excellence.

This independence allows us to:

  • Stay agile and responsive to client needs without layers of bureaucracy
  • Invest in local talent and contribute to the Canadian tech ecosystem
  • Build long-term partnerships based on trust, transparency, and shared success
  • Uphold Canadian values of fairness, inclusivity, and innovation

Why It Matters to You

When you work with us, you’re partnering with a team that’s fully invested in your success—and in the success of Canadian businesses and government. Our ownership model ensures:

  • Consistency: You’ll work with the same dedicated team throughout your project.
  • Accountability: We take full responsibility for the quality and outcomes of our work.
  • Local Expertise: We understand the Canadian market, regulations, and business culture.
  • Community Impact: Your investment stays in Canada, supporting local jobs and innovation.

No Maple Washing

Unfortunately, many companies with a Canadian locations are trying to spin themselves off as being Canadian. Don’t get me wrong, having global companies invest in Canadian employees is a great thing. It’s just different so it should be seen that way.

It’s hard finding Canadian Tech Platforms

There are certain areas where it is very challenging to find a Canadian alternative to an industry platform. Let’s take Microsoft 365 for example, there is no Canadian competitor subscription in that space. Our commitment to our clients and employees is that we will always look for Canadian options first.

Built by Experts, Run by Experts

Our leadership team and consultants are hands-on, experienced, and deeply involved in every aspect of our operations. We’re not just running a business—we’re building a legacy of excellence in Canadian software consulting.

Looking Ahead

As we grow, we remain committed to our roots. Our independence empowers us to innovate boldly, serve our clients with integrity, and build a company culture that reflects the best of what Canada has to offer.

We’re not just building software—we’re building trust, relationships, and a stronger Canadian tech community.

👉 Reach out today to explore how MERAK can modernize your Canadian business.

Guelph Predators Sponsorship

We are excited to announce that MERAK Systems Corporation has had the privilege of sponsoring the Guelph Predators U10 Ringette Team this season, and what an incredible journey it’s been!

This past weekend, March 22-23, 2025, the team capped off their season with a perfect performance at their final tournament in London. The Predators dominated, winning all 4 of their games and taking home the gold medals! Their defensive prowess stood out, allowing only 6 goals throughout the entire tournament, earning them the best defense title among all U10 teams.

As proud sponsors, we are thrilled to have supported such a dedicated and talented group of young athletes. Their hard work, teamwork, and sportsmanship have truly shone through this season, and we look forward to seeing all they accomplish in the future.

A huge congratulations to the Guelph Predators U10 Ringette Team on an unforgettable season!

We’re proud to continue supporting local talent and fostering community involvement.

Go Predators! 🏅

Free is Never Free

Episode 72

What could be better than free? For the last few months, I have been slowly building out a home lab. I bought my first rack, mounted a fancy router, ran ethernet cabling throughout the house, and installed a few access points. After a 6 month wait, I moved my workstation from an upright full tower into a rack mount 4U chassis. The new chassis had an issue: the intake and exhaust fan speed are controlled by the CPU temperature, but in this configuration, the CPU radiator is first to receive cool fresh air, then it dumps the waste heat on the GPU which is deeper in the chassis. For graphic intense games, the chassis fans would not spin up to give the GPU some help. After looking into external controllers, I was lucky enough to find open-source software that solved my issue completely. I could not be happier with the result. I donated to the developer; could have enjoyed the benefit with no cost, but is free software really free? This blog will explore the costs associated with free software.

We have almost certainly all used free software and services. Firefox for internet browsing, GIMP for image editing, VLC for media playback, Linux for operating system, and Blender for 3D graphics are a few popular open-source projects. Search engines and nearly all social media platforms are also free. While some applications are community developed, others are managed by some of the largest, and most profitable companies in recorded history. I would like to make the argument that most free software applications and services are profit driven but with some extra steps.

Why would anyone provide free software and who are they? There are two groups: independent developers and technology companies. There are many reasons why independent developers may release software for free: they are self-employed and can meet their needs through donations, they are building credibility, it’s a passion project, or the solution was for a problem where nothing was available, and lastly, they want to contribute to society with their talents. Motivations are a mix of entrepreneurship and altruism.

For technology companies, they may release free versions for users to test, for instance Alpha, Beta, or Early Access releases. This is used to gain early feedback before an official paid launch or build user numbers for a future sale to a 3rd party or switch to a freemium model, a very common practice in game development. Other models may include free base versions with paid enhancements or support. Lastly, the solution is always free because the users are the product being monetized.

If free software is largely a profit driven business model with extra steps, what are the costs if the product is free? All software requires maintenance. Who is going to pay for the maintenance and who is going to do it? If the software is free, is it realistic to expect any support, or if support is available what is the cost? If the owner of the software is not being compensated, is your organization dependent on their goodwill? What if they move on? Who has control? What happens if the ownership of the software changes? What if there are vulnerabilities discovered?

The most impactful is that most software solutions do not operate purely in isolation. Even if the software is free, it likely will be integrated into a larger system and what is the integration cost? If the software needs to be replaced for any reason, what is the replacement cost? Can the software be entrusted with sensitive data? What would the cost be of a failure or data breach? Then there are the human costs of adoption and training that need to be considered. It should be clear now that the incidental costs of software can be far larger than a licensing fee. If a paid version can mitigate any of these risks, the cost could be an order of magnitude cheaper than the free alternative.

Citizen Development and the Infinite Cloud

Episode 71

Software tools are becoming outrageously powerful. Developments in machine learning and AI are happening at a ridiculous pace. Research just a few years ago feels almost amateur relative to today, despite being cutting edge at the time. While research and development of these tools is done by specialized technical experts, the end user could be the average person. In between the average user and specialized experts are the citizen developers, also commonly referred to as power users. Some time ago (and still today), these were your business professional spreadsheet wizards writing complex formulas and maybe even some spicy VBA script. But the tools available today extend well beyond spreadsheets and now nearly anyone can build a fully featured application without a developer background. Combine powerful tools with the infinite scalability of the cloud, single individuals are able to do tasks that were impossible a decade ago. In this blog, I will highlight the promises and peril within the interplay of citizen developers and the infinite cloud.

The motivation for this blog came from my impression and conversations that followed the Microsoft Build 2022 conference. While there were a ton of announcements, one that struck me was the Power App Express Design feature that allows an individual to sketch a layout, take a photo, then configure the application with some drop down features. Anyone can sketch or take a photo. Another development is the mind-blowing image generation service DALL-E 2. With nothing but text prompts, an AI will generate a grid of images. Creative minds paired with such a tool may revolutionize design and art in the next decade. We may even see new professions emerge where top creatives thrive as they are able to make the best requests from these AI services.

In a previous blog, I looked at the promise and peril of low code development in relation to technical debt. What has become clear in my mind is that low code platforms very quickly outgrow simple templates or new user-friendly use cases and effectively become development projects. This is the first peril with citizen development. If an organization does not recognize this, they can very quickly find themselves in the modern equivalent of “Excel Hell”. We do not know what we do not know. Citizen developers come from all corners, but without training in proper development practices it is likely that they will not consider development governance practices like source control, environments, integrations, architecture, scalability, life cycle management, disaster recovery, or security.

A collage of various cloud technology icons such as databases, analytics and so forth.

These skills can be learned but the citizen developer needs to be aware of them. Increasingly low code platforms are baking some of these considerations either on the backend (basic security and backup done automatically) or in a feature like Power BI Premium’s support for development pipelines.

In a perfect world, the individual’s closest to the problem also have all the domain and technical knowledge needed to create a solution. In the real world, many problems are well beyond a single individual’s capacity to understand and as much as hiring managers would disagree, unicorns do not exist. Problems arise when either a solution outgrows the capacity of its citizen developers, or for more diverse teams, there is weak definition of responsibilities between citizen and professional developers. If citizen developers are left to build unrestricted, it is very easy to create a massive amount of bloat, likewise, heavy handed traditional IT controls can limit creativity, development velocity, and agility.

In the world of data analytics there is another peril to be avoided. We live in a world where a single individual, with a few clicks of a button, can procure access to truly monstrous computational capacity. Modern cloud providers often market the cloud for its flexibility and scalability. Ditch the fixed costs and performance of an on-premises data center and only pay for what you use. Sounds great right?

Through the last few years, I have been working towards expanding my data analytics skill set. In that time, I have focused on Learning Power BI as an extension to Excel and more recently SQL because if you really want to make Power BI sing, controlling the entire data pipeline is essential. I do not have a background in software development so what I have learned has come from exploration and tinkering. In this process, I have to say with some hindsight, I have done some ridiculous things. Examples are: DDOS myself with Power Query, bad joins, excessively large tables, wrong data types, unnecessary columns, overly complex DAX expressions, and data flow logic spread across multiple domains. Most of the time I have been learning with local resources so if I do something bad, it will either fail from lack of resources, or take a significant amount of time to compute. With an infinite cloud available at a button click, a citizen developer can just call for more resources. Cloud resources used poorly can be very expensive. Being very strict about application performance is a great way to learn the nuts and bolts of a system.

If we look back when Excel was the dominant citizen developer tool, in many cases the most technical person in the organization was the business professional acting as the organization’s spreadsheet wizard. The same goes for the modern day, the most technical person in the organization might be automating with Power Automate, creating Power Apps, or doing analytics with Power BI. We do not know what we do not know, and with the infinite cloud offering massive opportunity it is extremely easy to use such a resource inefficiently and not be aware. Just because an application works, does not mean it is performant, easy to maintain, and secure.

I am a tinkerer; I love rolling up my sleeves and pushing buttons and seeing the results. What has helped reveal the unknowns have been user group forums, Discord channels, in person community groups, and poking the minds of co-workers. Talk to people, it is ok to not know things. Be open to learning new things and get good by being bad and improving.

Rust Proofing Software

Episode 70

In the physical world, we are used to parts wearing down and requiring repair or replacement. If a physical system is not properly maintained, the risk that it will fail increases with use and time. Living in southern Ontario the winters here are especially rough on vehicles as the temperatures allow for road salting to be done for much of the season. To prevent rust, one must be proactive. I want to make the argument in this blog that digital systems experience the same phenomena. I will cover the mechanisms for Software Rust, why it is different from technical debt, and finish with some ideas around prevention.

A well functioning mechanical system will have had engineers work through the necessary design, simulation, and testing efforts to deliver an optimal maintenance plan that ensures the most value can be extracted from the system before its eventual replacement. Scheduled preventive or predictive maintenance are two methods to ensure a mechanical system remains in a well functioning state. Operating experience can provide lessons learned further enhancing efficiency. I will use these concepts and show where they apply to the digital space.

Running the same piece of code once is no different than one million or one billion times, however, digital systems have a direct connection to the physical world through the hardware that runs the software. Hardware failures, memory corruption, or physical disasters like fires and floods can reach into the digital realm. To protect digital systems, the most common method is replication. While the physical hardware is important, the causes of Software Rust are environmental. Here are some examples: changing development frameworks, discovered vulnerabilities, improvements in computation and storage, regulatory/accessibility requirements, and change in UI/UX best practices. Just like how a mechanical system wears down, environmental changes contribute to the increased fragility of a digital system, even if the hardware that supports the system is functioning optimally.

But how is Software Rust different from technical debt? Technical debt is taken on as a rational compromise to ensure a solution is delivered on time. Technical debt is accumulated when a short and quick solution is favoured over a complete one. Technical debt can be paid down, but at the cost of new feature development. Lastly, the removal cost of technical debt increases with time if not addressed. Software Rust differs from technical debt as it is a function of time and environmental exposure. Leaving road salt on your vehicle will result in rust more quickly than in a clean environment, likewise Software developed in a rapidly changing ecosystem will rust faster than a steady system. Here are examples of environments that could impact how quickly software could rust: consumer facings versus enterprise; open source versus custom developed; high computation resource needs versus low; many integrations versus very few; or, deals with highly critical information versus public.

A blue and cream 1950's car quietly rusting in the woods and overgrowth

Another dimension to Software Rusting is the human element. When individuals complete a feature, they likely learned from the process. Likewise, as projects are completed, both the team and organization grow in collective knowledge and experience. Knowledge management is a critical source of Software Rust prevention. Just as knowledge is gained over time, working knowledge of the systems we create is forgotten if left unvisited for a period. Mental atrophy can set in, making maintenance of past systems more difficult. This is especially true with large systems where retirements, staff churn, or the passage of time has resulted in knowledge gaps in how the system worked.

To summarize, Software Rust is a process by which the external environment increases the fragility of the digital system it contains. A critical piece in the puzzle are the humans that maintain the system. In the software world, everyone is learning continuously. It does not matter if you are a recent graduate or a 20-year veteran, the space changes so quickly, that to remain relevant, new skills must be constantly adopted. As individuals, teams, and organizations gain experience in new technologies, this is a generative process that allows for future development using the same systems to be built with greater efficiency. At least until the platforms change enough that the required skills to complete similar work no longer overlap.

So how to prevent Software Rust? We cannot control time, but we can control elements of the environment our digital systems live in and the processes we employ to ensure that our people can maintain working knowledge of the current state and apply new knowledge to improve on it. Rust prevention both in the physical and digital space is done through both at design (management of Technical Debt) and in maintenance of both the digital and mental space (Software Rust). Ensure that development frameworks are current, and vulnerabilities are both monitored for and addressed. Have developers revisit and refactor old code, when possible. A little bit of periodic maintenance and review can go a long way in ensuring that your organization’s digital systems remain resilient to change over time.

A case for not knowing

Episode 69

The world is a complex place. There is far more knowledge than any single individual could realistically understand. It is a chilling thought that no matter how hard you try, there will always be far more that you do not know, than know. Even a practiced learner will find that if knowledge is not regularly applied, it is lost in time. This means that if an individual wishes to complete a complex task they may be reliant on others. This model also scales up to the team and organization levels. If we look at any major human achievement it was from the result of thousands of individuals working together. This blog will argue that it is ok to not know things, provide a simple framework for defining solution types, and hopefully give some comfort to those overwhelmed by how little they know.

We have likely all come across the Dunning-Kruger effect, which is a cognitive bias where people with low ability at a task overestimate their ability. With the opposite bias being imposter syndrome, where high performers doubt and underestimate their skills. The one pattern I have observed is that individuals I have regarded as extremely competent are typically most comfortable with acknowledging both uncertainty and a lack of knowledge to appropriately address an inquiry. It takes little effort to see this phenomenon in action; simply contrast predictions/opinions between commentators and experts related to any complex current event. Our day-to-day challenges operate under similar mechanics, from simple tasks like how to split a date into its components in Excel, how to replace a piece of aging software technology, or how to best position our organization to take advantage of the emerging Metaverse.

A Filipino woman shrugs "I don't know" mannerism

With the Excel problem it can be classified as either a known or searchable solution. If known, the knowledge to implement the appropriate commands are known, but if not, the solution is likely available somewhere on the internet. For more complex problems known solutions involved a team and lessons learned were documented, with searchable solutions that may have involved research and business case development prior to implementation. Modern search engines have been a revolutionary technology. Gone are the days where one is required to memorize facts; now mental capacity can be focused on how best to process and rationalize information.

In the example of replacing aging software, the solution could be a discoverable one. A discoverable solution is differentiated from a searchable one in that the knowledge is not readily available. For instance, legacy software has been replaced numerous times by other organizations, but the specific software used by your organization is unique to your organization so there is no clear relationship. Another way to see discoverable solutions is as trade secrets, a market solution is available but “the how” will need to be reverse engineered. The core question remaining is whether the organization has the capacity and resources to discover such a solution. Would it need to seek outside help or build the capacity over time?

Lastly, there are novel solutions where no one has done it before. What does a fully augmented reality business look like? What systems and technology would we need for customers to see value in this new virtualized space? The competencies to commercialize research and development discoveries are no easy task. Tackling novel solutions is a high risk but high reward exercise as the investment builds knowledge in areas that might be very difficult to replicate, while providing the organization a first mover advantage.

With a simple solution classification system in hand, I want to make the argument that in today’s rapidly changing environment if your organization is not faced with seeking out unknown solutions, it is likely not innovating at a pace to remain technology relevant in the long term. Often, we will be faced with a situation where we do not know the answer and that is ok.

These forces are up against a culture that admires expert knowledge and mastery. There is room for deeply focused subject matter experts but at the same time, the deeper the specialization, the more reliant an individual or team will be on others when the scope of a problem expands across the bounds of their competency. Likewise, as technologies change, skill demands change as well. In the software development space, frameworks, development tools, architectures, and desired features change so rapidly that experts in this space must be constantly learning and experimenting to remain relevant. Therefore, it is critical that at all scales curiosity is encouraged. So be curious; it is ok to not know.

Technology does not solve organization problems

Episode 68

An organization’s capacity to change is the bottleneck on progress, not technology. There is no greater burden than great potential. Did a new technology implementation come with high hopes to solve numerous problems? Often hope is postponed disappointment. While I had no intention of writing such a downer introduction, this blog will explore the various reasons why technology does not solve organization problems. Before tackling this subject, it is important to define the components of an organization and their purpose. An organization is a mix of people, processes, and technology.

Without people there is no organization. People will vary in quantity, skills, experience, responsibilities, and motivation. Additionally, individuals will often be grouped into teams where structure, cohesion, and coordination have a massive influence over the effectiveness of the organization. Processes are the tasks and routines that people, with the aid of technology, perform. There are documented and undocumented processes. Processes can span individuals, teams, and departments. There are also processes whose purpose is to change processes, otherwise known as change management. Processes can operate with both parallel and sequential task structures. Lastly, technology: the resource that is responsible for enablement and amplification of people and processes. This foundational explanation is important as you can see if technology enables bad processes or unprepared people to do a task, or worse amplify their efforts, no amount of new technology will solve the problem the organization was originally trying to address.

To tackle organization problems, the most important question to ask is, what problem are you trying to solve? While an obvious question, it is very difficult to properly answer. One way to know if your planning is on the right path is the depth of understanding in the nuances surrounding the problem. A balance needs to be struck between analysis and action, but use caution when a new technology proposal is over-weight on technology considerations. Why is this a problem? Designing a technology solution to solve a people or process problem will likely lead to over-engineering. Over-engineering will create technical debt and unnecessary organizational friction which will hamper the organization’s ability to remain agile. Technology should not be deployed for technology’s sake. We can see this with attempts using blockchain and even more recently with organizations scrambling to get into the Metaverse. Both blockchain and the Metaverse could have huge potential, but both have major challenges with defining what changes are needed regarding people and processes to where an early adopter can generate market value with a clear competitive advantage.

Star Wars Lego minifigures of storm troopers surround nervous office worker at a desk (metaphor for office power dynamics)

With every introduction of technology there will be some adoption friction. It is important to understand that organizations contain inertia and change will almost always be resisted, because “it has always been done this way”. Therefore, to improve success, the complexity of the technology implemented must be minimized. Let’s use an example to highlight my argument.

A hypothetical organization that manufactures components for assembly downstream. Through its long history, it has numerous divisions for each market it operates in. Each division has its own finance, marketing, and operations departments. A centralized IT department provides support to the organization, and strategic decisions are the responsibility of an executive team. Now under this structure, consider a task like provisioning IT resources. Every department will need to make a request to the IT department and to manage the requests a ticketing system is used. There are complaints that tickets are open for too long. The high-pressure environment has resulted in high staff turn over in the IT department for years. I hope I do not need to go any further, but it should be crystal clear that no ticket management technology will completely solve the challenges with making IT resource requests.

I will close off the blog with some questions and measures to help mitigate organizational problems. How many work handovers, approvals, and stakeholders are involved in your organization’s processes? Do individuals, teams, departments, etc have clear lines of responsibility and ownership? Does the organizational culture support the creation of organizational heroes? How common are single individual dependencies? How many resources are spent on rework and technical debt servicing? How long does it take to go from idea to completion? How visible is work in your organization? How much work is in process?

Do not put what you want (New Tech Solution) ahead of what you need to accomplish what you want. Regarding technology implementations, quality wins over features; work in small steps, create wins, and build momentum.

Source Code Escrow

Episode 67

Custom development is very common. Despite the ubiquitous offerings from off-the-shelf solutions, organizations often find that their specific needs cannot be fully addressed by what is available on the market. In this case, a custom solution is developed, which will contain source code. This blog will cover source code escrow, a process to protect everyone involved if the relationship goes sour.

Some organizations manage development internally and exercise both full control and responsibility over the source code. However, some firms will outsource the development and potentially even the operation and management, too. If your organization is in this latter case, do you know where your source code is? If your vendor went bankrupt, or stopped supporting your application, can you recover the latest version of your source code? Maybe you do not own the software but license use of it; would you be able to recover the source code? Source code escrow is a service that protects both the user and the vendor by having a neutral 3rd party escrow agent hold the source code until a mutually agreed upon event occurs.

Work boot about to step on exposed screw nail (metaphor for risk mitigation)

From the user’s perspective, losing access to the source code is a major risk to the business. Sometimes it is not that the vendor goes bankrupt but either stops maintaining the application or service quality drops below an acceptable level. If the application runs mission critical services, then the organization is at the mercy of the good faith and capacity of the vendor. From the vendor’s perspective, if they own the source code, giving access to the source code could put their business at risk. How would the vendor keep the source code safe and secret? Another situation would be that the user owns the source code but it is stewarded by the software vendor, even in this case, it is very common for the user to not have a reliable way to access the most recent version of their source code.

To mitigate this risk for both parties, it is common practice to store the source code with an independent 3rd party escrow agent. When selecting an escrow agent consider the following: How long have they been in business? Where do they store the data? How confident are you in their technical expertise? Is there active development being undertaken on the code? How would changes be delivered to the escrow agent? What are the release conditions? If conditions are met, does the code get released or destroyed?

While likely never needed, this often forgotten risk mitigation step can be a critical piece of insurance for your organization.

Technology Cost Savings Versus Technology Investment

Episode 66

Whether it is finding and retaining IT resources, paying for cloud services, or purchasing and maintaining on premises infrastructure, let’s not kid ourselves, technology is expensive. Software critical to the good functioning of organizations are largely SaaS products licensed per user/month; $3 here and $12 there, an administrator has nothing to worry about until every employee in your organization has 10+ licenses of various SaaS products. With technology costs eating up more of the budget, eventually the leadership team will decide that it is time to find ways to cut costs. I want to use this blog to discuss the nuances around ensuring your organization gets the most value from its IT spending, and avoiding the cost cut spiral.

The worldview is dramatically different when organizational spending is classified as a cost versus an investment. Classic school of thought would be to minimize costs through negotiating better terms with suppliers, substitution, or the pursuit of more efficient uses of input resources. Input resources are acquired, then value is added to them through your organization’s core competencies, however the mindset with costs is that exchange is zero-sum. The cheaper we can source inputs, the greater the return for us.

A spoon with coins in the bowl and a potato on the other end is balanced on a calculator while it all sets upon printed financial papers

But ask yourself, is IT spending at your organization a cost or an investment? When we invest, we are performing the same action, but our expectations can be dramatically different. There is a generative mindset, where investment represents enablement, fostering growth beyond a simple value exchange. Applying a cost cutting mindset to an investment would likely lead to a result where there is a lack of resources preventing the initiative from generating a return. There is a complicated system at play here; if an investment lacks the required resources, proceeds to fail or struggle and there is now an even greater incentive to cut the losers and redirect resources. But if technology forms a critical backbone to your organization’s function, one must be very careful of the second order impacts when “investment” is cut. Has anyone experienced IT staff cuts or limited training? What follows is usually a major transformation push, only then to see the initiative get abandoned. Managing technology assets is not easy, but hopefully I can provide some warning signs to be aware of and a better guiding worldview.

Individuals, or a collection of individuals within an organization, cannot be experts in everything. Adoption of any new platform takes time and resources, scaling exponentially with complexity and business importance. Organizations are a mix of people, processes, and technology. Now applying the cost cutting mentality to any of these pillars, (insufficient staff training, little change management or process redesign) it should be obvious that the investment in technology is not going to return value.

Focus on return on investment over total cost. Treat IT spending like one would with an investment in a company, a critical piece of equipment, or real estate. Investments are viewed as generative. The last six months I have been neck deep in Power BI, a business intelligence platform. It is free to use, but Pro Licenses are required by users to view reports shared on the Power BI service. At $12 per user/month for every user in the organization can be a tough sell initially. I look at that $12 not as a cost but as a way to generate time savings. If an application like Power BI cannot save all employees 15-30 min of time per month or create a better decision that returns equivalent value, then it is not being used to its full potential. Repeat the same thought experiment with every other system in your organization.

It is counter intuitive, but the better your organization can use its technology assets the less it will spend on them in the long term. Fewer big bang replacements, fewer critical failures, less downtime, and fewer engagements with outside consultants. Growth and improvement come from an investment mindset, not cost cutting.