IT Operations Technology Roadmapping Team Leadership Cost Optimization Vendor Management Service Delivery

Is your technology holding your business back?

You don't need another consultant with a slide deck. You need someone who embeds into your team, takes ownership, and makes things actually work. That's what I do.

Get in Touch See what I do

93%

Triage time reduction. 190 days to 13.

See how →

80%

Overnight incidents cut. 50 per month to 2.

See how →

-75%

Failed change rate. Across 100+ changes per week.

See how →

2:1

Savings to project revenue. Converted into new work.

See how →

Experience across industries that know the pressure

Retail Telecoms Energy & Utilities Automotive PE-backed Software Managed Services

Who this is for

Built for businesses that can't afford to get technology wrong.

High stakes, real budgets, no tolerance for wasted time. If that sounds like you, we should talk.

Growing fast

Technology is starting to slow you down.

Your stack was built for a smaller company and it shows.

Infrastructure decisions are being made under pressure, not strategy.

No one owns technology at the leadership level.

Every bad hire or wrong vendor burns runway you can't recover.

See how I help

In transition

You need leadership now, not in six months.

The IT leadership seat is empty and decisions are stalling.

M&A, restructuring, or a major migration is underway with no clear owner.

Tech and executive teams are pulling in different directions.

No one is accountable for critical technology decisions.

See how I help

PE / VC-backed

High stakes, tight timelines, zero room for error.

Your investors expect results, not slide decks and discovery phases.

Technology due diligence needs to happen fast and without blind spots.

Post-investment transformation requires board-level visibility.

Cost and vendor bloat need to be cut before they hurt your EBITDA.

See how I help

How it works.

Simple. No surprises.

01

We talk.

A free 30-minute conversation. No pitch, no pressure, no strings attached.

02

I assess.

Where you are, what's blocking you, and what needs to move first.

03

I embed.

I work inside your team, not above it. Clear priorities, quick wins, and real execution from day one.

04

Things move.

Measurable outcomes, not reports. I stay as long as you need and leave you with something that holds.

Ready to stop guessing with your technology?

Let's invest 30 minutes figuring out where you are and what needs to change.

Get in Touch See more about me Request CV

About

I'm Miguel. I make things happen.

11+ years leading IT operations, building teams from scratch, and turning broken or directionless environments into something that actually works. Across retail, telecoms, energy, automotive, and PE-backed software.

I don't parachute in with a framework and hand over a report. I embed into your team, understand what's actually going on, and drive it forward myself. That's the difference.

Get in Touch See my experience

Most companies don't have a technology problem. They have a clarity problem.

Get clear on where you're going and the technology side gets a whole lot simpler. That's what I help you figure out.

No jargon. No politics. No bloated proposals. Real execution.

What I'm like to work with

Direct. Flexible. No committees.

I read the situation and do what it needs, whether that's sitting at the leadership table or getting into the weeds with the team.

I don't poll five people before making a call. That's not how progress happens. If you need someone to circulate a deck for three rounds of approval, I'm not your person. If you need someone to move, I am.

Get in Touch See what I can do

I adapt to what the situation actually needs.

I don't drop a plan on your desk and disappear.

Honest assessments, even when it's uncomfortable.

As involved as you need. No more, no less.

Three moments that shaped how I work

The situations that tested me are exactly why you can trust me.

The 30-Year Handover

Building a global team from zero.

First leadership role. No domain expertise in middleware. Tasked with building a global team while managing the handover of a client that had been with the same vendor for 30 years. No playbook. No safety net. I figured it out.

Both Sides of the Table

Operating in the grey zone.

Led the transition from a managed services model to in-house while simultaneously playing service provider and client. Had to protect my company's position, extend the contract, and manage egos on both sides without losing either. Nobody teaches you that.

Order Out of Chaos

Structure where there was none.

Took over a team with no leader, no docs, and no process. Built an operating model from scratch, cut daily standups in favor of bi-weekly 1-1s, and gave the team full visibility without anyone breathing down their necks.

Outside the work

I go deep. In travel. In work. In everything.

I travel as much as I can, and not the resort kind. I find locals, eat where they eat, and try to understand a place from the inside rather than through a curated itinerary.

That same instinct carries into how I work. I don't walk in with a framework and force it on everyone. I read the room, understand the culture, and figure out what's actually going on before I start making calls.

It's why I've been able to lead remote teams across EMEA, LATAM, and APAC without defaulting to a one-size-fits-all approach. People aren't resources. They're shaped by where they come from. That matters.

Who this is not for

If you need five sign-offs before anything moves, we won't work well together. I work with people who are ready to go and trust the person they brought in to help them get there.

Why this works

Every company has different problems, constraints, and culture. I've worked across all of them. That variety is what keeps my approach sharp, I don't bring a template, I bring experience.

Based in Portugal. Working globally.

Remote-first by design. I've led teams across time zones and cultures for years. Location is not a constraint.

Ready to work with someone who actually moves?

30 minutes. No pitch. Just an honest conversation about where you are and what needs to happen.

Get in Touch See more about me Request my CV

What I Do

Four ways I can help.

Whether you need a full strategy overhaul or someone to own one specific problem, every engagement is built around your situation, not a package.

01 Clear the fog

See case →

02 Build what lasts

See case →

03 Stop the bleed

See case →

04 Hold the line

See case →

🧭

StrategyRoadmap

You're spending on tech. Is it working?

Stop making expensive decisions in the dark. I help you build a clear roadmap that aligns your technology with where your business is actually going, not where it was three years ago.

Talk to me about strategy

Who it's for

Any business making consequential technology decisions without a clear strategy or dedicated technology leadership.

What it solves

Misaligned investments, reactive decisions, and technology that pulls in a different direction than the business.

What I do

You get a full picture of where your technology stands and where it's holding you back.
You stop overspending in the wrong places and start protecting what matters.
You leave with a prioritized roadmap tied to where the business is actually going.
Decision-making stops being reactive and starts being structured.

What you get

A clear, actionable plan and someone who helps you execute it. Not just hand it over.

See an example →

👥

LeadershipTeam Building

Your team needs a direction, not just a manager.

Clarity, ownership, and alignment don't happen by accident. I help establish direction, improve decision-making, and turn technology into a function that actually supports long-term growth.

Talk to me about leadership

Who it's for

Organizations that need stronger technology leadership, clearer accountability, and better alignment between business priorities and execution.

What it solves

Unclear direction, weak ownership, disconnected teams, and technology decisions that drift away from business goals.

What I do

Leadership becomes visible, consistent, and tied to business priorities.
Teams gain clearer structure, ownership, and direction.
Decision-making improves across executives, managers, and technical teams.
Technology stops operating in isolation and starts supporting long-term business goals.

What you get

Stronger leadership, better alignment, and a technology function built to support the business for the long term.

See an example →

💡

Cost OptimizationResource Efficiency

You're bleeding money you can't see.

More budget doesn't fix a broken setup. I find where your money, people, and vendors are being wasted and redirect them toward what actually drives results.

Talk to me about cost optimization

Who it's for

Any company investing heavily in technology but unsure whether that investment is actually delivering.

What it solves

Wasted budget, senior talent doing junior work, and vendor contracts that renew without anyone questioning them.

What I do

You see exactly where your technology budget is going and what it's actually producing.
Senior talent gets redirected to work that's worth their time.
Vendor spend gets reviewed and cut where it's not earning its place.
Resources shift toward the priorities that move the business forward.

What you get

A leaner setup, a clearer picture of what your money is doing, and no more budgets that disappear without results.

See an example →

🤝

Vendor ManagementAccountability

You're paying for performance you're not getting.

Bad vendor relationships quietly cost you more than you think. I help you negotiate, consolidate, and hold partners accountable so you get what you're paying for.

Talk to me about vendor management

Who it's for

Any business that depends on external technology partners but lacks the internal expertise to manage those relationships effectively.

What it solves

Poor contract terms, vendors that underdeliver, and a supplier list that grew without a strategy behind it.

What I do

You get a clear view of every vendor relationship and what it's actually costing you.
Consolidation and renegotiation opportunities get identified and acted on.
Vendors are held to clear performance standards, not just renewed out of habit.
Your team gains the frameworks to manage these relationships confidently going forward.

What you get

Vendors that perform, contracts that protect you, and less time managing relationships that should manage themselves.

See an example →

Not sure which fits?

That's what the free call is for. We talk, I listen, and we figure out together what actually needs to happen.

Get in Touch Request my CV

Let's talk

Let's figure out what your technology actually needs.

30 minutes. No pitch. No pressure. Just an honest look at where you are and what would make the biggest difference right now.

If it makes sense to work together, we'll talk about how. If it doesn't, you'll still walk away with clarity you didn't have before.

Book a time

Email

hello@miguelaabreu.com

linkedin.com/in/maabreu1

Response time

Within 1 business day.

Location

Based in Portugal. Working globally.

CV Request

Need my CV? Just ask.

I don't post it publicly. Fill in the form and I'll send it over within one business day.

A quick note about the role or context helps me tailor what I send.

Got it. I'll send my CV over within one business day. If you need to reach me sooner, drop me a line at hello@miguelaabreu.com.

Not sure where to start?

Book 30 minutes. No pitch. Just an honest look at where you are and what needs to happen.

Book a time See what I do Request my CV

Legal

Privacy Policy

Last updated: 24 May 2026

What this site collects

This site is a static portfolio. It does not use cookies, analytics, tracking scripts, or fingerprinting. No data is collected from you by visiting or browsing the site.

The only data collected is what you voluntarily submit through the CV request form on the contact page. That form collects:

Your name

Your email address

Your company name (optional)

The reason for your request

An optional message

How your data is processed

Form submissions are processed by Formspree (formspree.io), a third-party form handling service based in the United States. Formspree acts as a data processor on behalf of this site.

Formspree's privacy policy is available at formspree.io/legal/privacy-policy.

Your data is used solely to respond to your CV request or inquiry. It is not sold, shared with third parties for marketing, or used for any other purpose.

Legal basis for processing

The legal basis for processing your data is your consent, given by voluntarily submitting the form. You can withdraw this consent at any time by contacting me.

Data retention

Form submissions are retained only as long as necessary to respond to your inquiry. Once the purpose has been fulfilled, your data is deleted. You can request immediate deletion at any time.

Your rights

Under the General Data Protection Regulation (GDPR), you have the right to:

Access the personal data held about you

Rectify any inaccurate or incomplete data

Erase your data ("right to be forgotten")

Restrict processing of your data

Port your data to another service

Object to processing of your data

Cookies and tracking

This site does not use cookies, local storage, session storage, analytics tools, or any form of tracking. No third-party scripts are loaded during browsing. The only external connection is made when you submit the contact form to Formspree.

Contact

To exercise any of your rights or ask questions about how your data is handled, contact me at:

hello@miguelaabreu.com

404

Page not found.

This page doesn't exist or was moved. Let's get you back on track.

Back to Home

← Back to What I Do

Strategy Roadmap

Clear The Fog

Years of backlog. Four ticket systems. No unified process. No visibility. Here is how I turned chaos into a measurable operating model and scaled output without a single extra hire.

Work with me Request my CV

The House, M.D. problem

The situation

A PE-backed software company running multiple products across multiple development partners, each with their own tools, processes, and habits. Jira DC, Jira Cloud, Assembla, Azure DevOps. Four different systems, zero shared visibility.

Tickets aged for years. Nobody knew what was critical and what was noise. Development partners worked without any shared standards. Different branching strategies, no code review requirements, no testing hierarchy, no release process. Every partner doing their own thing.

The team was capable. The infrastructure around them was broken. Everyone was treating symptoms, moving fast, putting out fires. Nobody had stopped to ask what was actually wrong.

Starting state

Avg triage time 190 days

Active backlog 485 tickets

Ticket systems 4

Dev standards None

Before/After System Diagram: 4 disconnected systems to unified Jira operating model

The approach

3-Step Timeline: Centralize, Standardize, Scale

The Columbo method

Step 1: Centralize everything

First move: own all communication. Even when I did not have the answer, I needed to know what was happening. That single change gave enough signal to start seeing patterns across products and partners that nobody else was tracking.

Then I manually dug through years of ticket history across all four systems. Identified what was genuinely open, what was abandoned, and what was noise. Built a triage framework with clear priority and severity rules. If everything is a priority, nothing is a priority. Urgency is a planning failure, not a severity level.

The goal was never to close tickets for the sake of numbers. It was to build a framework that could handle both the existing backlog and everything coming after it, managed together with clear priorities driving every decision.

Triage Funnel: 485 tickets, prioritised, closed, 57 active

See what a broken operating model looks like up close

A 30-person team, daily incidents, no documentation, then a ransomware attack. Everything that went wrong and exactly how it got fixed.

Read Build What Lasts →

The Succession rollout

Step 2: Roll out development standards to all partners

Every development partner was operating independently. The output quality reflected that. I designed and rolled out a unified development standards framework across all tech partners, covering five areas.

Branching: GitFlow model with protected branches, enforced naming conventions, and mandatory CI checks before merge.

Code quality: standards covering duplication, dead code, exception handling, logging, and formatting.

Commits: every commit had to tell a clear story; no copy-pasting, no branch names as messages.

Pull requests: mandatory internal reviewer approval, senior engineer sign-off, and tests included.

Testing: unit tests after every PR, API coverage above 90%, automated regression for all products with existing frameworks.

Releases: semantic versioning, tagged artifacts, Confluence release notes, and post-deployment health checks.

Partners pushed back initially. Standards always create friction at the start. Within the first two delivery cycles with each partner, the friction was gone - the rework that had been causing it had gone with it.

Dev Standards Framework: Branching, Code quality, PR process, Testing, Release

The Martian approach

Step 3: Scale output without scaling headcount

Once visibility existed and standards were in place, the real question was scope. The team was debugging across .NET, Java, JavaScript, and PHP, reading source code daily, proposing fixes, and managing accountability across multiple development partners. That is an engineering function, not a support function, and it was running at capacity.

Instead of requesting more headcount, I built the case for scope expansion through leverage: structured workstreams, automated Jira workflows, and AI tooling that absorbed the extra load. Same team, more output, broader coverage.

The business case was built around three numbers that mattered to leadership, and once those were on the table, the conversation shifted from per-brand updates to holding company-wide patterns.

Throughput per headcount: tickets triaged and fix recommendations issued doubled quarter over quarter, headcount unchanged.

Upstream impact: fix recommendations accepted and findings that prevented customer-facing issues, proving the work landed, not just got produced.

Coverage breadth: multiple products and brands, 5 development partners, one lead, set out in a single operating map.

Output vs Headcount: throughput growing QoQ, headcount flat

How vendor accountability ties into this

When your team comes from the partners you are holding accountable, you cannot manage by trust alone. The governance model behind that is covered here.

Read Hold The Line →

The Moneyball extension

Step 4: Apply the model beyond the original scope

Marketplace expansion

The company had no clear presence across marketplaces despite operating in a space where they should have been visible. Too many options, no framework to evaluate them, and no one had volunteered to build one. I built one.

I ran a structured assessment of 35 potential marketplaces, spoke with marketing, analysed competition, and built a shortlist of 10. Within 4 months of finalising the shortlist, we entered 4.

Acquisition assessment

The company was evaluating a mid-six-figure acquisition: an AI-powered test automation platform. On paper it looked like a smart move. I went deeper and assessed three things:

Service contracts: obligations that would transfer with the acquisition and constrain what we could do with the product.

Tech stack: the actual build quality underneath the pitch deck.

Client base: interviewed key personnel to understand what was holding the revenue together.

What I found was a product we could build ourselves at a fraction of the acquisition price. I built the case, presented it, and the exec team voted against. Building cost a fraction of the asking price and came without the liabilities that made the target's valuation questionable.

On AI: what it changes and what it does not

I introduced AI tooling across the team and I am not against it. Used well, it is a serious force multiplier. But there is a version of the AI conversation that skips past the hard parts, and that version tends to come from people who have never worked a live customer issue at 2pm on a Friday. The parts it does not replace:

Live triage: workarounds, customer calls, bug retesting, and shipping fix code to partners under pressure.

Unreproducible issues: recordings, log pulls, live instance queries, and diagnosis without collateral damage. That is a judgement problem, not a token problem.

Context gathering: most customers will not share their application under test and many do not know their own tech stack. Extracting that is a skill, not a prompt.

AI as a sidecar: yes, absolutely. Replacing the person managing the live issue, the partner call, and the deadline simultaneously is still a human answer.

The cost case behind the scope expansion

Scaling output without headcount is one side of the equation. The other is removing the spend that was not delivering. Both happened in parallel.

Read Stop The Bleed →

The results

Avg Triage Time

190 → 13

Days. 93% faster over 2 years.

Active Backlog

485 → 57

Tickets. 88% cleared.

Output

2×

QoQ throughput. Zero added headcount.

Automations Built

20

Jira workflows. Manual handoffs removed.

Partner Onboarding

1 week

From zero to fully operational on standards.

Reporting

1 view

Holding-company visibility. Each GM previously saw only their own brand.

Halt and Catch Fire edition

What made it hard

Getting multiple stakeholders to agree on what mattered when everyone had their own version of priority was the first obstacle. The triage framework only worked once I had enough data to make the conversation objective rather than political.

External partners treated standardization as overreach. Some agreed in meetings and carried on as before. The only thing that changed behaviour consistently was enforcement through PR reviews and release gates. Agreement without consequence is just a conversation.

The scope of the role was easy to underestimate from the outside. It looked like support on paper. The work was closer to hands-on engineering accountability across multiple stacks and partner teams. Closing that gap between label and reality took time and a reporting structure that made the breadth visible to leadership.

The acquisition assessment was the highest-stakes call on this engagement. Recommending against a deal the exec team was already inclined toward required a watertight case and the willingness to be wrong publicly. The build-versus-buy argument only held because the due diligence was thorough enough to survive scrutiny.

Recognise this situation?

Let's talk about what is broken and how to fix it.

Get in Touch Request my CV See other work

← Back to What I Do

Leadership Team Building

Build What Lasts

I built a global middleware team from nothing, watched the early model fail, and fixed it. 30 engineers across 4 continents, 24/7/365, no inherited playbook. Then a ransomware attack hit and recovery fell to us.

Work with me Request my CV

Ted Lasso, but for middleware

The situation

A global energy provider running critical middleware infrastructure across APAC, EMEA, and LATAM. I was brought in to build and lead the team from the ground up. No existing structure. No documentation. No runbooks. The middleware engineers I assembled were specialists in silos, each owning one piece with no visibility into anything adjacent.

The early model failed fast. Incidents happened daily. Overtime was constant. When any middleware engineer was unavailable, their incidents sat open until they came back online. The team I had built was the worst performing in the organization, and I had built it.

Then a ransomware attack hit. 40 products affected. Recovery fell to us.

Starting state

Team performance Worst in org

Incident frequency Daily

Cross-team coverage None

Documentation None

Team Performance Timeline: Worst performing → Best performing, incident trend

The approach

Leadership Playbook: Learn → Build → Delegate → Scale

The Breaking Bad problem

Building domain expertise from zero

My background was in systems administration , not middleware specifically. Rather than manage that gap through delegation alone, I used the specialist contractors to get the team started, learned alongside the middleware engineers, and turned those contractors into a vehicle for documentation and structured knowledge transfer to the offshore team.

Once the middleware engineers could operate independently, the contractors were removed entirely. Three roles eliminated, €27k/month saved. The financial case for that decision - how it was built and approved - is covered separately.

How the cost case was built

The €27k saving did not come from cutting. It came from building internal capability first and removing the dependency once the evidence was there.

Read Stop The Bleed →

The Wire principle

T-shaped cross-training across APAC, EMEA and LATAM

The early model failed because each middleware engineer owned one area completely and nothing else. Coverage depended on individuals being available. When they weren't, incidents waited.

I redesigned the team around a T-shaped model. Every engineer kept their primary specialism and built working knowledge of adjacent areas. Runbooks were written. Knowledge transfer happened in structured sessions, not improvised during outages.

Incidents got picked up regardless of who was on call. Overtime dropped 80%.

Team Structure Diagram: 30 engineers across APAC, EMEA, and LATAM

The Chernobyl test

Ransomware recovery: 3 months, up to 16 hours a day

A ransomware attack took down 40 products. Damage was contained to the Windows OS layer. I coordinated credential resets across affected systems, ran server-by-server damage assessments with one middleware engineer, and restored applications through either clean deployments from validated backups or full rebuilds from scratch.

Normal operations continued in parallel. At peak, 16-hour days sustained for weeks. The team held because ownership was clear, the documentation existed, and the cross-training had already happened.

Full recovery in 3 months. No permanent outages. Automated recovery tasks that previously took 4 to 5 hours were rebuilt and reduced to under 1 hour.

Ransomware Recovery Timeline: 3-month recovery across 40 products

The Succession play

On-premises to Azure migration

The ransomware attack accelerated a migration that was already in motion. With roughly half the infrastructure affected, spinning up replacement VMs in Azure on Windows Server 2019 became the faster path to recovery than restoring everything in place. Availability and disaster recovery were the drivers, not cost. The cloud environment gave us a recovery posture that on-premises could not match.

I was hands-on across the full stack. The environment covered a wide range of middleware and application server technologies, each requiring separate installation, configuration, and validation:

Oracle Forms and Reports

IBM WebSphere

Oracle WebLogic

Apache Tomcat and HTTP Server

IIS and SQL Server Reporting Services

Informatica PowerCenter

SharePoint

Oracle Billing, FlexNet, ARIS

The governance side of the same engagement

The operational model built here fed directly into a broader vendor and change governance rebuild: failed changes down 75%, financial penalties to zero, and a clean managed services transition.

Read Hold The Line →

The results

Overnight Incident Frequency

50 → 2

Per month, 6pm to 9am Portugal time. Sustained.

Overtime

-80%

After cross-training rollout.

SLA Compliance

99.5%

Under 4 hours downtime allowed per month.

Documentation

450

Runbooks and SOPs created from scratch.

Recovery Automation

4h → <1h

Disaster recovery tasks automated.

Azure Migration

200+ VMs

20 products across dev, pre-prod, and prod environments.

Band of Brothers edition

What made it hard

The team started poorly because I built it that way. There was no predecessor to blame. The silos, the individual dependencies, the lack of documentation were consequences of the initial model I put in place. Fixing it meant acknowledging that clearly and rebuilding without losing the team's confidence in the direction.

Operating across APAC, EMEA, and LATAM meant the cultural translation was constant. How middleware engineers surface blockers, receive feedback, and relate to escalation varies significantly by region. Getting a consistent operating model to land across four continents required adjusting the approach without diluting the standard.

The ransomware recovery compressed all of it. Long days, sustained for months, on systems that had just been damaged, with a distributed team and no precedent to follow. What made it survivable was that the structural work had been done before the attack arrived.

Cutting the contractors was the call with the least margin for error. The business case was straightforward. The timing was not.

Dealing with a team that isn't performing?

Let's talk about what it takes to fix it properly.

Get in Touch Request my CV See other work

← Back to What I Do

Vendor Management Accountability

Hold The Line

Vendors underdelivering. Failed changes causing outages. Financial penalties stacking up. A managed services contract winding down with no governance to hold anyone accountable. Here is how I rebuilt vendor relationships from the ground up and kept the line clean.

Work with me Request my CV

The Suits problem

The situation

Vendor relationships managed by goodwill rather than governance. Performance issues raised in emails and forgotten. SLAs referenced in contracts but never enforced. Renewals happening automatically because nobody had built the case to challenge them.

One engagement had an unusual dimension: I was employed by the outgoing managed services vendor while simultaneously responsible for managing the transition to an in-house model. In effect, I was managing my own employer out of the contract.

In another, a multi-supplier environment with critical infrastructure required proper governance to keep vendors coordinated without any single one becoming a dependency.

Starting state

Failed enterprise changes High

Critical outages trend Growing

SLA enforcement Informal

Vendor governance None

Vendor Governance Timeline: Informal SLAs to structured governance to clean transition

The approach

Managing your own employer out

The dual-role transition

Being employed by the vendor you are managing out is professionally unusual. The only way it stays clean is complete transparency on both sides. I was accountable to my employer while also building the case for the client to operate without them.

The operating model was rebuilt on ServiceNow with change templates, automated workflows, and real-time visibility that teams had not had before. Process ownership was redefined. Governance structure was in place before the handover.

The transition completed without service disruption. The client took full ownership of a model they understood and could run. My employer knew what I was doing and why throughout.

Transition Timeline: Managed services to in-house model, zero disruption

The Halt and Catch Fire moment

Agile-ITIL hybrid and formal process ownership

Governance without measurability is just procedure. Agile gave the rhythm, the culture of continuous improvement, and the discipline to break down the departmental silos that had kept teams working in parallel without talking. ITIL gave the structure and accountability baselines. The two were not in tension: Agile defines how teams improve, ITIL defines what they are accountable for improving.

The Agile practices

Kanban for operational work: visualised flow, limited WIP, and a shared board that made blockers visible before they became incidents.

Backlog management: prioritised, maintained, and reviewed so work that mattered got done rather than work that was loudest.

Standups and face-to-face communication: kept teams aligned daily and replaced the email chains that had let issues drift.

Retrospectives: run at operational level and adapted for executive leadership. Structured reflection on what was working and what needed to change, at every layer.

Frequent delivery and simplicity: break work into deliverable increments, avoid over-engineering the process, and adjust regularly based on what the data showed.

The ITIL process ownership

Formal Process Owner accountability across five disciplines:

Incident Management: response structure, escalation paths, and post-incident review cadence.

Change Management: Process Owner and CAB Manager. Full story in the next section.

Problem Management: root cause tracking and trend analysis to prevent recurring incidents rather than just close tickets.

Availability Management: SLA thresholds defined, monitored, and enforced against vendor commitments.

Capacity Management: forward planning tied to real usage data rather than vendor estimates.

The Billions play

Rebuilding change governance to stop outages and eliminate penalties

Failed changes were causing outages and triggering financial penalties on both sides. When the client took a hit, the provider took one too. The exposure ran in both directions and compounded fast. For two clients, the downstream impact was not abstract:

Electricity distribution: a failed change could mean a household losing power.

Payment processing: a failed change could mean someone unable to pay at a grocery store.

Logistics: a failed change could mean a truck sitting at a warehouse because the system could not legally authorise the dispatch.

These were not IT incidents. They were real consequences for real people. The root causes were consistent:

No pre-change testing standard.

Unclear ownership at the point of failure.

No post-implementation review feeding back into the next cycle.

As CAB Manager and Process Owner, I rebuilt the governance model with mandatory pre-checks, rollback procedures, defined approval gates, and post-change reviews wired directly into Problem Management. The change advisory board got actual authority, not just a calendar invite.

Failed changes dropped 75% across roughly 200 changes per week. Critical outages dropped 10% quarter over quarter for four consecutive quarters. Financial penalties went to zero.

Change Governance Process: Submit, CAB Review, Approve/Reject, Implement, Post-review

The Succession risk

Multi-supplier governance and enforced SLAs

Managing multiple vendors across critical infrastructure meant keeping everyone accountable without letting any single supplier become indispensable. Process ownership, escalation paths, and performance review cadences were defined for each relationship under ITIL and COBIT frameworks.

SLAs were renegotiated where they were not fit for purpose. Performance was tracked against agreed metrics, not just reported. Vendors that underperformed were challenged formally, with documentation and a defined consequence.

Some pushed back. The governance held because it was applied consistently - to every vendor, every review cycle, every SLA breach. The enforcement structure was designed so that pressure in the room could not override the process on paper.

The Office problem, solved

A framework that makes accountability structural

Designed and implemented four service appendices covering development, QA, DevOps, and design partners. Each one defined what was expected, how performance would be measured, and what happened when it was not.

Performance conversations stopped being reactive. They happened on a schedule, with evidence, against criteria everyone had agreed to upfront. The system carried the accountability so the relationship did not have to.

Want to see how this works with development partners?

Same governance logic applied to a fragmented multi-product environment with four ticket systems and no shared standards.

See how the fog got cleared →

The cost angle of the same governance work

The $150k infrastructure decommission and €27k/month contractor removal did not happen in isolation. Here is how the evidence was built and the cases were approved.

Read Stop The Bleed →

The results

Failed Changes

-75%

Across 100+ changes per week.

Critical Outages

-10% QoQ

4 consecutive quarters.

Financial Penalties

$0

Avoided via SLA governance.

Vendors Under Governance

6

Peak at one engagement. 15 across all engagements.

Dual-Role Transition

22 months

Managing own employer out. No service disruption throughout.

CAB Meetings Chaired

190

Local and global. Local CAB: up to 40 attendees. May 2022 to March 2024.

Vendor Accountability Model: Before informal and reactive, After structured and evidenced

Severance edition

What made it hard

The dual-role transition required a level of professional separation that most people avoid. You are building the case for the client to operate without your employer. That only works if you are honest about it with everyone and committed to the outcome regardless of where your paycheck comes from.

Getting engineers to treat governance gates as protection rather than bureaucracy took time and evidence. The first two change cycles were a negotiation. After that, the data from the post-implementation reviews did the argument for me.

The infrastructure decommission cases required political courage as much as technical evidence. Legacy systems survive because nobody wants ownership of the risk if something breaks during removal. The CMDB-evidenced approach removed that ambiguity. If the system had no active consumers and no justified cost, the case was watertight.

Vendor accountability is only durable if it is applied consistently. The moment you make an exception, you have reset the standard. That means having the same conversation more than once, with the same outcome, until the vendor accepts that the governance applies every time.

Vendors not delivering what they promised?

Let's talk about what good governance actually looks like.

Get in Touch Request my CV See other work

← Back to What I Do

Cost Optimization Resource Efficiency

Stop The Bleed

Contractors filling gaps that should not exist. Infrastructure sitting idle. Vendor contracts renewing without scrutiny. Here is how I built the evidence, made the cases, and converted waste into savings without touching headcount.

Work with me Request my CV

The Office Space problem

The situation

The pattern repeated across every organization. Budget going to specialist contractors because nobody had built the internal capability. Infrastructure outliving its purpose with no one willing to make the call. Vendor contracts auto-renewing because challenging them required evidence that had never been gathered.

Each of these problems has the same root: nobody had visibility over what was being used, what it cost, and what it was actually delivering. Without that picture, every line item looks justified to whoever signs it off.

Patterns found across engagements

Contractors replacing missing skills Recurring

Idle infrastructure Untracked

Vendor renewals without review Automatic

Cost visibility None

The approach

The Moneyball case

Replacing external dependency by closing the capability gap

External contractors and development partners stay on the books for one of two reasons: the work genuinely requires specialist capacity, or the internal team was never built to cover it. The second case is a structural problem dressed up as a staffing one. The fix is not a headcount decision. It is a capability decision.

The approach was consistent across engagements, covering development partners, specialist contractors, and independent hires that had become structural dependencies rather than temporary capacity:

Identify: map what the internal team could not yet cover and why.

Build: close the gap through cross-training, process design, and tooling before removing anything.

Case to leadership: current external cost, what the team could now own independently, and a risk-rated view of what remained exposed.

Remove: dependency out once the capability threshold was documented and verified.

Total external spend removed: $100,000+. In one engagement, triage time dropped from 190 to 13 days as a direct consequence. The team-building story behind another is in Build What Lasts.

Contractor Cost vs Internal Capability Over Time

The team-building side of this story

How a 30-person middleware team went from worst performing to best, and how that created the conditions to cut the contractors in the first place.

Read Build What Lasts →

The CSI approach

Decommissioning infrastructure nobody wanted to touch

Legacy infrastructure persists because decommissioning creates risk and nobody wants to own it. The default position in every organization is to leave it running until someone else makes the call.

I cross-referenced monitoring data against the CMDB to build a clear picture of what was active, dormant, and genuinely idle. Where the data alone was ambiguous, I went directly to the teams responsible and had the conversation in the room. "We might still need that" does not survive a direct question backed by six months of zero-transaction logs.

The decommission case was approved. $150,000 in annualised infrastructure costs eliminated. The governance side of this - how the CMDB-evidenced approach was built and maintained - is covered in the vendor management case.

How the governance model made this possible

The infrastructure decommission did not happen in isolation. It was part of a broader vendor and change governance rebuild that removed $150k in costs and eliminated financial penalties.

Read Hold The Line →

The Dragon's Den format

Building cost proposals that get approved

Every cost proposal I submitted was approved by leadership. Not because the cases were uncontroversial. Some were. Because each one was structured around three things leadership actually needed: the current cost, the proposed change, and a risk-rated view of what happened if nothing changed. That format meant no follow-up meetings and no requests to come back with more data.

The governance framework covering development, QA, DevOps, and design partners (each with defined deliverables, performance metrics, escalation paths, and review cadences) is covered fully in Hold The Line. Once that framework existed, performance conversations moved from reactive to scheduled, with evidence on both sides.

The results

External Spend Removed

$100k+

Partner and contractor dependency eliminated across engagements.

Cost Proposals

0 rejected

Every case built to answer leadership's objections before they were raised.

Vendors Assessed

15

Reviewed across engagements. Agreements restructured or exited where justified.

The Big Short edition

What made it hard

Cost cases are political before they are financial. Every line item has an owner, and nobody welcomes the suggestion that their spend is not delivering. The approach has to be evidence-first every time. You present the data and let the room reach the conclusion rather than leading with the recommendation.

The infrastructure decommission required going in person when monitoring data alone was not enough. Some teams claimed they were still using systems with no recorded transactions in months. A direct conversation in the room resolved that faster than any email chain would have.

Removing contractors while maintaining output is a trust exercise. Management needs to believe the team can handle it before they will approve the change. Showing training progress against defined milestones in real time was what made that case land.

Zero rejections was not luck. Each case was built to answer the questions leadership would ask before they asked them. That preparation is invisible in the outcome but it is the entire job.

Know you are overspending but not sure where?

That is exactly where this starts.

Get in Touch Request my CV See other work