Have you ever wondered if other companies are satisfied with how their IT works?

Would your CEO, CPO, or CTO have the same opinion?

After 16 years as an engineer and a leader, I believe development got harder because businesses expect every project to be tied to revenue growth.

But how do you measure the ROI of an example refactoring project that could prevent the product from crashing half a year later?

In the last 3 months, we interviewed a dozen technology managers about their challenges, management practices, and hopes.

Quite often, when we asked about introducing initiatives like generative AI or cloud cost optimization, the unspoken answer was, “It would be nice, but we have other priorities.”.

It seems to me that many technology initiatives hit the bucket because:

A) IT struggles to prove what business value their decisions bring

B) Business tends to decide what’s a priority for the core team

I’d like to help other technologists understand they can still launch experiments that could help engineering work better.

Better yet, there’s a way to get that buy-in from the Board.

And it won’t be only my opinion — quality reports confirm this.

The secret is to make technology projects sound like a common goal that can start as a low-risk investment.

Boards actually see innovation as critical

CEOs often have the final call over what IT does by shaping the commercial strategy that CTOs and CPOs then use.

When PWC surveyed 4,702 CEOs in 2024, 45% admitted their companies’ business model “would not be viable in 10 years”.

Almost half of the board and non-board respondents of a survey from Nash Squared believe adopting new technologies and improving customer experience allows businesses to outperform the competition.

That’s the opinion of 2,104 people, by the way.

Now, we have our first talking point for a future quarterly review.

Innovation projects should be a priority if they can help engineers create a better digital product that helps the business grow.

Remember to flash these report slides so that the argument really seems neutral.

Why Boards deprioritize IT initiatives

If you look at how this one engineering group categorizes their projects, you’ll see the overwhelming majority of them are tied to commercial goals (2024, LinearB).

Expecting a clear return from IT’s work is absolutely understandable, and I support it.

That’s also how I work.

At the same time, I think engineers must have a weekly or monthly time block for refactoring and refinement that is unmovable, like a boulder.

Of course, there’s always a good excuse to focus only on delivery.

Just from my experience of managing international development projects, boards also have little interest in new initiatives because:

• Stakeholders don’t want fewer in-house engineers available

• Technology leaders can’t tie engineering, technology, or product improvements to business continuity

Maybe you went through this yourself.

A CTO informs the business team some requests must be delayed because of IT’s internal work.

The group seems puzzled as to what the engineers are doing.

I’d advise technology leaders to always focus on the 3 important facts boards actually respond to: time, risk, and results

How to prove a case for a technology project 

To combat the lack of support my fellow technology managers have, The Software House designed Acceleration Sprints™.

They are intensive development cycles with the goal of overcoming technological or product challenges in a maximum of 2 weeks.

While this is in fact a service we offer, I also believe this is a valid engineering practice anyone can use at their organization.

Sprint rules

Since several leaders we spoke with found this exciting, let me explain how these Sprints work:

• Sprints start with discovery, KPI alignment, and a written agreement on the result
• Each sprint must end with a specific deliverable that connects to real business metrics 
• They are not a side project — there’s a dedicated team responsible for the project and the results
• The project team should only include senior-level professionals who know a domain by heart

A refactoring project with an estimated work time of 3 months might sound like a bad bargain.

But IT can lead a 1 or 2-week sprint that produces a feature demo or improves on-page performance with a promise to improve business metrics if they continue.

So by design, Acceleration Sprints™ take little time compared to any commercial project, have low or no risk if they’re led well, and produce something the Board sees as proof of value.

I won’t promise this is a framework for success.

That depends on how well you or an external partner lead discovery and on the team composition.

But I believe working on product or department improvements 1-2 sprints at a time could be a new way of thinking.

How companies innovate in 1-2 sprints

The Software House completed 3 commercial sprint projects.

Since our engineering created this version of a sprint, I can only refer to the results our partners saw.

One sprint slashed $36,000 in monthly cloud costs

A retailer with 100+ stores worked on a 1-week sprint with the goal of cutting down their bill.

Our Sprint team discovered their product didn’t delete Amazon Machine Images (AIM) and their snapshots from the cloud storage often enough.

In the end, the client saved $4,000 on EBS-backed storage and $32,000 on EC compute costs per month by:

• reducing cloud instances
• consolidating build pipelines
• reducing the number of Jenkins workers

Read the full story from Michał Rybacki, our DevOps Engineer, who was on that team.

2 sprints allowed a media company to save 99% on translation

A publisher paid $200 to translate a 4,000-character article into English, and there were volumes to process.

The goal of the sprint was to lower the translation costs. 

The Software House’s Sprint team:

• compared the long-term costs of using several language models
•  adopted the OpusMT from the University of Helsinki and the EasyNmt Python library.

After implementation, our partner’s Total Lambda Costs dropped from $200 to $1.95 for one translation.

Mariusz Richtscheid, our Software Architect, and Rafał Sikorski, our Node.js developer, created a fantastic breakdown of the project.

Automated observability introduced in one sprint saves $720 per month for one instance

Another retailer decided to introduce one proper observability process to catch all unnecessary cloud costs.

This time, Our Sprint team had a goal of enabling incident monitoring for the company.

We introduced automated instance shutdown and set up a Jenkins workflow automation that reduced the cost-per-instance to $720 per month.

Michał Rybacki strikes again with his story from the trenches.

How we selected goals for our sprints

I only speak about the results our Acceleration Sprints have.

There might be other organizations that could develop their own version of them.

Think about your backlog.

You could find time for two test sprints before quarterly planning.

Then, you could have results to present, and a good case for a new engineering priority to make.

We’re continuing our discovery process to find what are the most pressing challenges such sprints can solve.

In 2024 alone, we worked on 47 engineering projects for different partners and interviewed 27 technology leaders for our CTO vs. Status Quo series.

We’ll soon launch the 2024 edition of The State of Frontend, which already has responses from 200+ CTOs.

Based on the findings we have, we designed sprints that deal with:

• Cloud cost reduction
• AI rapid prototyping 
• React performance optimization
• Application modernization
• Observability strategy
• Accessibility implementation

All of them represent areas our partner wishes to improve.

And all of them can be tied to commercial goals the C-suite wants to talk about.

I hope you’ll find a smart way to manage your department’s priorities.