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.
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.
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.
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.
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.
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.
Look, the real headache isn't just balancing a spreadsheet. It's 'innovation bloat.' That's when you've got these pet projects sucking up cash for years without actually delivering anything. I've found the Run-Grow-Transform model is the only way to stay sane, but you have to be ruthless about it. You don't just cut costs to look good on a quarterly report. You take the money you saved from cleaning up your 'Run' operations and you funnel it straight into 'Transform.' It shouldn't be some abstract line item; it should be a portfolio of experiments fueled by the efficiency you've squeezed out of your core systems. We treat these projects like we're venture capitalists. You don't get a giant pile of cash upfront. You get a tranche. If you hit your milestones, you get the next one. If you stall? The money stops. We don't keep the lights on for a project just because we liked the idea when we started. It puts the burden of proof on the project leads. It keeps your best talent from getting trapped in 'zombie' projects that stopped providing value months ago. Honestly, the hardest part is having the backbone to kill off legacy projects. Even if they've been around forever, if they aren't serving the business, they have to go. Real innovation usually starts by clearing out that operational clutter so your best people aren't just stuck in maintenance mode all day.
A practical way to balance this is by separating IT spending into two clear buckets. One part is for running the business and the other is for growing the business. The first covers things like infrastructure, security, maintenance, and systems that keep daily operations stable. The second is for projects that create new capabilities or improve how the company works. What helps is reviewing these two areas regularly instead of letting operational costs quietly consume the whole budget. If most of the spending is only going toward maintenance, it becomes a signal that the organization might be falling behind in innovation. A simple framework that works well is thinking in terms of run, improve, and transform. Run is the cost of keeping systems reliable. Improve focuses on making existing processes more efficient. Transform is where new technology or ideas can change how the business operates. When leaders look at spending through these three lenses, it becomes easier to decide where money should go. The goal is to keep operations stable while still reserving a clear portion of the budget for projects that move the organization forward rather than just maintaining the status quo.
I try to balance operational IT spending and innovation investment by treating them as different kinds of risk management. Keeping the lights on protects continuity, reliability, and trust. Innovation protects relevance and future growth. If you underinvest in operations, the business becomes fragile. If you underinvest in innovation, it becomes stagnant. So the real question is not which one matters more, but where each dollar reduces the most important risk for the business. The framework that helps most is to separate investments into three buckets: business-critical operations, near-term efficiency gains, and long-term strategic bets. The first bucket has to stay healthy because it supports everything else. The second is often where technology creates the fastest return, because it improves cost, speed, or visibility. The third is placing smaller, more deliberate bets on future capabilities. What keeps this practical is tying each category to business impact, not just technical interest. In my experience, the best allocation decisions come from asking: Does this protect delivery? Does it improve how we operate? Does it strengthen where we need to go next? That helps you avoid two common mistakes—overspending on maintenance with no progress, or chasing innovation while core operations become unstable.
At a startup, this tradeoff is existential, and you can't afford to get it wrong in either direction. Neglect operations and your product breaks for existing customers. Over-invest in operations and you stop innovating while the market moves without you. The framework I use is customer-impact weighting. Every engineering decision gets evaluated through one question: does this directly improve the experience for the people using our product today, or does it make the product meaningfully better for the customers we'll have in six months? Operational work that prevents customer-facing issues gets funded immediately, and that's non-negotiable. Operational work that's purely internal efficiency gets deprioritized unless it's creating bottlenecks that slow down innovation. The practical allocation shifts over time. In the earliest stages, innovation should dominate because you're finding product-market fit and the operational footprint is small. As you scale and have real customers depending on reliability, operational investment naturally claims more of the budget. The mistake is treating this as a fixed ratio when it should be a dynamic conversation tied to where the company is in its growth cycle. One thing that helps: tagging every piece of engineering work as "protect" or "build." Protect work keeps current customers happy. Build work creates future value. When you can see the ratio in real time, the conversation about allocation becomes data-driven rather than political.
I balance operational IT expenses with innovation by treating cash flow as the primary planning lens and keeping a separate budget for experiments. I project cash and growth trends 6-9 months ahead to identify what must be funded to keep the lights on and what discretionary funds I can allocate to tests. Innovation investments start as small, measured experiments funded from that separate budget; only winners are scaled. I treat forecasts as working goals and remain ready to reallocate based on measured results so operations remain stable while transformation proceeds.
As founder of Profitjets, I balance operational IT expenses and innovation investments by treating the chart of accounts as the primary decision framework. I design the CoA from unit economics and separate variable costs that scale with customers from fixed costs so the true operating burden is visible. That includes classifying cloud and support as cost of revenue when they vary with delivery and keeping recurring software separate from one-off projects so spikes are obvious. Monthly P&L by segment and by cohort then shows where operational spend consumes cash and where targeted innovation improves margin, enabling evidence based allocation conversations.
I balance operational IT expenses with innovation by partnering with managed IT services to move routine operations to on-demand access to professional talent and elastic infrastructure. This converts fixed operational overhead into scalable capacity and frees internal teams and budget to pursue transformation work. My framework is to define a managed-services baseline that handles 'keep the lights on' activities, and to treat innovation as discrete, time-boxed projects funded from the freed capacity. Managed services provide proactive monitoring and infrastructure elasticity that accelerate new technology adoption while minimizing downtime, and they maintain threat detection, compliance monitoring, and rapid incident response so transformation can proceed without compromising data protection.
CEO at Digital Web Solutions
Answered a month ago
The mistake we often see is treating operations as fixed while innovation feels optional. We try to reverse that thinking by making operational cost a target that must keep moving. Each year we set a run rate goal that should decline as our capability improves. This pushes teams to automate routine work and simplify systems before they request more budget. We also stage innovation funding so ideas can prove value before they receive larger support. We start with a small discovery budget that focuses on data quality and customer signals. If early adoption appears we move to a build phase with a clear time window. We also hold a cross functional review where finance hears customer feedback alongside performance numbers.
The most effective way to balance operational IT expenses with innovation investments is to treat them as two interconnected layers of the same system rather than competing priorities. In practice, the framework that works best is separating technology spending into three categories: operational stability, optimization, and innovation, and then evaluating each category based on business impact rather than purely on cost. Operational spending focuses on keeping core systems reliable, secure, and scalable, which is essential because without a stable foundation, innovation initiatives rarely succeed. However, many organizations fall into the trap of allowing operational costs to expand unchecked, gradually consuming the majority of the technology budget. The key is to continuously evaluate whether operational systems are running efficiently and whether certain processes can be automated, consolidated, or migrated to more scalable platforms to reduce long-term maintenance costs. Once the operational layer is stable and efficient, a defined portion of resources should be intentionally allocated to innovation initiatives that directly support strategic business goals such as new revenue streams, improved customer experiences, or competitive differentiation. What makes this framework effective is that innovation projects are not funded simply because they are new or technically interesting; they are prioritized based on measurable business outcomes and the potential to create leverage across the organization. Over time, successful innovation projects often reduce operational costs by replacing outdated processes or introducing more efficient systems, which creates a positive cycle where transformation gradually funds itself. The real balance comes from disciplined evaluation, where leadership continuously asks whether each technology investment either protects the core business or meaningfully expands its future capabilities, ensuring that resources are not locked into maintenance at the expense of long-term growth.
The simplest way to balance operational IT costs with innovation is through splitting spending money into three piles or buckets: run (core operations - infrastructure, security, support, compliance), improve (gaining efficiencies - such as automation and cleaning up applications) and transform (larger initiatives - such as AI, new platforms or enhancing customer experience). This framework works because it allows leaders to protect their essential operations while investing for future growth. Most organizations start with a general mix of 60-70% for run, 20-30% for improve and 10-15% for transform. The objective is to review spender by determining if it reduces risk or generates some measurable business value, therefore maintenance does not take up the entire budget.
Balancing operational IT spending with innovation starts with clear visibility into what truly keeps the business running versus what improves it. Core systems that support daily work must stay stable and well funded. At the same time, innovation cannot wait for a perfect moment because transformation happens through steady progress. I usually treat operational expenses as a protected baseline. Once that baseline is clear, the next step is reserving a defined portion of resources for experimentation and improvement projects. Even small, consistent investments in new capabilities keep innovation moving without disrupting stability. Day to day, I rely on a simple filter when reviewing spending decisions. If an investment improves efficiency, removes recurring friction, or creates measurable value within a reasonable timeframe, it earns priority. This approach keeps operations reliable while ensuring the organization continues to evolve instead of standing still.
I balance operational IT expenses and innovation by treating stable operations as the baseline and protecting a dedicated fund for learning-driven experiments. My framework centers on two clear buckets: a must-run budget for keeping the lights on and a separate innovation budget governed by explicit learning objectives. Because I prioritize growth and learning in my own career, each innovation project must deliver short feedback loops and documented insights before scaling. This approach keeps core services reliable while letting us make small, fast bets that inform larger investments.
By separating operational IT expenditures from innovation investments into two specific decision processes, rather than one combined budget debate, I keep a balance of the two budgets. Operating IT expenditures relate to the operational resiliency (the ability for systems to continue functioning), security (the safeguarding of any confidential or sensitive information), compliance (meeting industry standards) and availability (the full-time access to applications). Innovation is characterized by speed (being quicker than your competitors), competitive advantages (any unique or superior position), and future state efficiencies (operating in accordance with future trends). There will be times when you mix the two and because of the urgent nature of operating expenditures due to the inability to take an organization down, and the excess resources required for maintenance projects versus innovation projects, you will often find yourself putting more emphasis on keeping the lights on than on innovating. The best framework to utilize is a three-bucket model for budgeting. The first bucket is run the business, which would represent the core infrastructure that keeps your business operating including support, security, licensing and continuity of business operations. The second bucket is improve the business. This includes process improvement (automation, workflow upgrades) and tools that reduce expenses or eliminate friction over the next 6 to 18 months. The third bucket is change the business. This would encompass your major transformation investments like platform modernization, data initiatives and AI capabilities. In practice, fund the first bucket as a non-negotiable and evaluate the second on measurable ROI with the intent of implementing these projects, and treat the third bucket as a portfolio of staged investments with clear milestones to be met prior to progressing to the next milestone. The trend in the industry today is for very effective IT leaders to be much more disciplined about demonstrating the value of their initiatives through each stage of the three-bucket investment strategy. This trend requires CIOs to evaluate all spend within their functional group by considering risk, return and time horizon and shift funding for the projects that generate either a reduction in future operating costs or provide a true strategic advantage.
So we had a fight about this in a leadership meeting last quarter. Not a polite disagreement. An actual argument about whether to modernize our CRM integration or keep patching the existing one. The framework that settled it was simple. We listed every system by how often it caused a support ticket. Top 3 ticket generators got innovation budget. Everything else stayed on maintenance. That forced the conversation away from opinions toward evidence of what was actually failing. About 70% of our IT spend goes to operations, 30% to new things. I do not think there is a correct ratio. It depends on how much technical debt you carry. The companies that get this wrong usually overspend on innovation while their core systems quietly fall apart. You have to be honest about what is actually broken before you start building what is new.