Radu Spataru

30 years in IT.

Author of "Practical Guide for IT Leaders".

Founder of INGINES.

My story

I have spent 30 years in IT, in companies of every size and across most of the roles you can hold inside a technology organisation - engineer, team lead, manager, head of, director, CIO. I have built teams from scratch and I have inherited teams that were on fire.

I have run IT for companies that respected the function and for companies that resented it. I have sat in the meeting where the business says "the Roadmap is yours, why is it not done" more times than I can count, on both sides of the table.

INGINES is what I started after I had spent enough years inside IT to know exactly which problems are real, which problems are misdiagnosed, and which problems get the wrong people fired. The practice is built on one observation that took me ten years to formulate clearly:

Most IT teams are not weak. The structure around them is. Fix the structure, and the team you already have becomes the technology strong-power the business actually wins with.

That sentence is the spine of everything I do.

What I believe

A short list of the principles I will not move on. They show up in every assessment I deliver and every conversation I have with an IT leader or an executive.

The IT problem is almost always structural, not personal. The CIO who is being blamed is rarely the cause. The team that "can't deliver" is usually delivering at the speed the structure permits. Replacing people without changing the structure produces the same outcome 18 months later, with a more expensive payroll.

Hiring more rarely fixes it. The hire that did not change anything is a symptom of a role-definition problem, an incentive problem, or a delivery-model problem. Pouring more developers into a broken system increases cost without increasing output. The CFO is right to notice.

A Roadmap should be a real plan, not a wish-list. If the business reads it and assumes everything will ship, and the team reads it and knows two-thirds cannot, you do not have a Roadmap. You have an argument waiting to happen. A real Roadmap has capacity, sequencing, and a quarterly story the business can tell.

Speed and quality stop being at war when delivery is set up well. The teams that ship fast and ship right are not heroic. They have a lightweight Change Management cadence, one SLA the business actually cares about, and an operating rhythm that makes evidence visible. None of it requires more headcount.

IT must translate its work into outcomes the business can credit. "We deployed v2.3" is not a result. "Our customer on-boarding takes three days less than last quarter" is. The team that learns to talk about its work in business language stops being invisible, and the conversation about the IT budget stops being adversarial.

Business and IT should be partners, not opponents. This is the most common failure mode and the hardest to fix, because it is invisible to anyone who only sees one side. The work of fixing it is mostly translation: making each side legible to the other, and creating the rituals that keep the translation alive.

A CASE FROM INSIDE THE SEAT

I joined the company as the new CTO. The situation was critical.

Where we started:

Late delivery on most projects
10 to 20 incidents per month, each one a discovery - the team was reacting, not controlling
A technical team that was not motivated and not engaged
Every new idea from the business was implemented without analysis of load or risk - which usually meant 30 to 80 percent of the code never made it to final product
The business complaining about promises with no delivery
Technical managers who were senior developers - none of them were actually managing their teams
Two roadmaps - one business, one technical - inconsistent and not synchronized, both wish-lists

After 3 months:

One Roadmap. Explicit visibility of resources and priorities. The business and the team looking at the same document.
A bonus system tied to delivery, company results, learning, and team collaboration - not activity
Incidents down from 10-20 per month to 1 or 2. The ones that did happen were controlled and solved in minutes instead of hours.
The technical teams focused on the Roadmap as a real delivery commitment, not a ping-pong match with the business

After 6 months:

Management skills rebuilt through dedicated training and coaching - the Team Leaders became actual managers
Every team and every individual - team lead, developer, QA - had a defined growth plan with a level-up structure
Weekly meetings with the business on the Roadmap, with pure clarity on what will be delivered and when
The whole company was prepared. Delivery on time. Delivery with quality.
Incident levels kept falling

After 12 months - the handover:

The whole assignment was a single 12-month commitment. The promise on day one was clear: at the end of the year, all the changes above would be in place, and one or two internal people would be ready to step into the CTO role after me. Both promises were kept. Two internal candidates were ready. I handed over and left.

The function kept running at the new level after I left - because by then, the structure was doing the work, not me. That is the test.

The most telling number, by the time of the handover: top-management time spent on Technical and Product delivery discussions had gone from 50-80 percent of their attention to 5-10 percent. The function had stopped being a fire to manage. It had become a function the business could rely on, with internal leaders who could keep it that way.

This is what I do.

Radu

Practical Guide for IT Leaders

It is the book I wish someone had handed me twenty years ago. It is not a theory book. It is the working playbook of an IT leader who has run teams through every stage of growth, every kind of business pressure, and every kind of executive relationship.

It covers what an IT leader actually does, day to day and quarter to quarter: aligning IT with the business strategy, building the Roadmap, leading the team, mastering the budget and the operating processes, and the dozens of small decisions that decide whether the function is respected or resented.

It is written for the CIO, CTO, and IT Manager who wants the work to actually go somewhere - and for the executive who wants to understand what their IT leader is contending with, so the conversation between them gets sharper.

read on amazon

The IT Leadership Master-class

The Master-class is a tailored engagement, available after the IT Assessment.

Here is why that order matters. A generic leadership course is a brochure. The frameworks are useful in the abstract and rarely change anything in practice, because the room is full of people from different companies with different problems and the material has to stay general. The Master-class works differently: the assessment first surfaces what is actually broken in your specific situation, and the Master-class then applies the relevant modules from Practical Guide for IT Leaders to that exact context, in your room, with your real problems on the table.

The structure is fully customizable to what the assessment found. Below is the full menu - we pick the modules that map to your dominant culprit, and we go deep on those rather than skim everything.

Module 1 - The Strategic CIO: Aligning IT with Business Goals

Assessing the "as-is": tools and frameworks for evaluating the current IT landscape
Discovering the business strategy: how to collaborate with executives for alignment
Developing your IT strategy: key components and validation methods

Module 2 - Building Your Roadmap for Impact

Roadmap creation: prioritization, resource allocation, change management
Process optimization: SLAs, change management, security
Key technology domains: making informed decisions on architecture and tools

Module 3 - Leading Your IT Team to Success

Hiring and retention strategies: finding and keeping the best talent
Continuous learning: developing hard and soft skills for your team
Motivation and performance: building a high-performance culture

Module 4 - Mastering IT Budget, Processes and Operations

IT budget mastery: planning, optimizing, and justifying IT spending
Project management methodologies: choosing between Waterfall, Agile, and the rest, and implementing the right processes for your team
Essential KPIs and reporting: demonstrating IT's value to the business

Q&A and wrap-up

The session ends with a working Q&A on the specific challenges your team is facing, and concrete next steps for what to do in the weeks after the Master-class.

Format: typically a one to three days in-person working session, scoped against the assessment findings. Available for IT leadership teams, or as a joint Business + IT session when alignment is the dominant culprit.

book a scoping call