6 Ways to Balance IT Operational Expenses with Innovation Investments

We use a simple 70/20/10 framework that I adapted from Google's old innovation model. 70% of our IT budget and engineering time goes to keeping current systems running, secure, and performant. 20% goes to incremental improvements on existing products and infrastructure. 10% goes to experimental projects that might fail completely but could unlock new revenue streams or major efficiency gains.

The key insight that made this work for us was getting honest about what actually falls in each bucket. Before implementing this framework, we had a habit of disguising maintenance work as innovation. Rebuilding an API that should have been maintained properly is not innovation, it is technical debt repayment. Being ruthless about categorisation meant we could see our actual innovation spend was closer to 3% before we started tracking it deliberately.

The way I determine the right allocation quarterly is by asking one question: if we stopped all innovation spending tomorrow, how long until our competitive position erodes? For a software house that answer is about 12-18 months because the industry moves fast. That urgency justifies protecting the innovation budget even when operations feel underfunded. The framework also gives me language to push back when clients or stakeholders want to cut R&D during tight quarters. I can point to the numbers and show that our 10% experimental budget is what generated two of our most profitable service lines.

We use a simple two lane framework that focuses on outcomes and time horizons. The first lane is Run and Protect, which includes availability, compliance, incident response, and data integrity. The second lane is Change and Learn, which focuses on building new capabilities that shorten feedback loops. Each quarter we assign every initiative to a lane, name an owner, and set one clear constraint that measures either risk reduction or time saved each week.

We start allocation by setting a minimum share for Run and Protect based on past incidents and expected risk events. After that we create a fixed innovation reserve that cannot be moved unless there is a real emergency. Inside this reserve we rank projects by how quickly they help the team learn. Work that creates reusable automation and cleaner data models usually ranks higher because it supports steady improvement over time.

As a small technology consulting and software firm, we approach the balance by keeping operational IT spend intentionally lean so it never competes with innovation for resources. That means continuously evaluating infrastructure decisions, eliminating unnecessary overhead, and maintaining a bias toward simplicity so baseline costs stay predictable. Innovation is then treated as a deliberate investment—primarily in building our own platform, Kalos—where we focus on creating long-term leverage rather than incremental improvements.

For our clients, the equation shifts slightly. As an AWS Partner, we help them tap into AWS funding programs and technical resources to support innovation initiatives. That allows them to pursue new product development and transformation efforts without significantly increasing their internal spend. The result is a model where operational costs remain controlled, while innovation is accelerated through a combination of disciplined architecture and strategic use of partner-backed investment.

Every IT leader I know fights the same quiet war: keeping today's systems running while funding the future. The tension is real because both sides are non-negotiable. Skip maintenance and you get outages. Skip innovation and you get irrelevance.

The framework that changed how I think about this is deceptively simple. Instead of splitting the budget into just operations and innovation,I break it into three buckets: Run, Return, and Re-Tool.

Run is the keep-the-lights-on spend. Infrastructure, security, compliance, licensing. This is your floor, not your ceiling. The goal here is stability and waste reduction. If a cost doesn't clearly belong somewhere else, it lives in Run by default. That discipline alone prevents bloat.

Return is where every dollar must prove itself. These are initiatives with a measurable payoff within a defined window: automating a manual workflow, fixing a bottleneck that slows revenue, upgrading a tool that measurably improves retention. The rule is simple. If it's in this bucket, it needs an owner, a KPI, and a deadline. You won't hit the estimate every time, but the habit of tying spend to outcomes changes how the whole organization thinks about technology.

Re-Tool is your forward-facing bet. Pilots, proofs of concept, platform shifts, and capability plays you can't honestly attach an ROI to yet. This bucket carries the most risk, so it starts small and grows as governance matures. Think of it as R&D for your operational future.

The real shift isn't the framework itself. It's the conversation it forces between the CIO and CFO. When you stop debating whether something is operational or strategic and start asking what outcome it drives, you move from defending line items to managing a portfolio. Security and compliance become baselines, not bargaining chips. Innovation earns its seat by showing results, not just potential.

One practical habit that makes the whole thing work: a monthly portfolio review with a shared scorecard covering growth, efficiency, risk, and customer impact. Agreed-upon triggers, a regulatory change, a missed SLA, a unit-economics threshold, automatically release, pause, or reallocate funding.

The companies winning right now aren't the ones with the biggest IT budgets. They're the ones extracting the most value from every dollar because they stopped treating technology as overhead and started managing it like what it is: strategy in motion.

Keeping the lights on stops being a black hole when I tag every dollar as Run, Grow, or Transform and force a monthly conversation on what moves lanes. I use TBM-style unit costs, cost per user, cost per ticket, cost per environment, to make Run spend visible, then I set a hard bar for innovation bets, a clear owner, a measured outcome, and a kill switch if it is not landing. Cloud is where the balance drifts, so I pair this with simple FinOps habits like chargeback tags and weekly cost reviews, so experiments do not become permanent overhead. That framework keeps ops honest and makes innovation a portfolio you can manage, not a vibe.

I balance operational IT expenses with innovation investments by centering decisions on adaptability. My framework is simple: stay agile, continuously reassess priorities, and shift resources as needs and opportunities change. That approach ensures core systems remain reliable while preserving capacity to test and iterate on new ideas. In a fast-moving software business, adaptability is my primary guide for allocation decisions.