fp.Fabio
Petriccione

Applied AI / customer engineering

I make complex
technology
useful.

A little about me

Understand what isn’t working.
Make it work.
Build it to work again.

Fabio PetriccioneEngineer. Operator. Builder.My story so far ↗︎

Mainframe engineering, VTS

Understand the system.

Banking workloads, automation and monitoring. Where I learned that production means something.

Move to explore · drag to turnChoose a chapter to explore

The person behind the systems

I learned engineering
in the control room.

My first engineering job was automating mainframe operations for banking systems in Italy. A missed step wasn’t just an inconvenience. It could become a production incident.

That taught me a habit I’ve carried through every job since: don’t just fix the problem. Understand why it happened, then build something that makes it less likely to happen again.

I still gravitate toward the messy parts of engineering: production systems, enterprise adoption, and now AI. My work is to understand what isn’t working, make it work, then build the mechanism so it can keep working without me.

Backstory

My story,
so far.

I’ve never really planned my career around a particular technology.

The common thread is the kind of problem I like: complicated systems, incomplete information, real consequences, and a need to turn what I learn into something other people can reuse.

  1. 2020

    Engineering foundations

    Computer Engineering degree, UNISA

    Full-stack development, Evja

  2. 2020-2022

    Learning what production really means

    Mainframe Systems Engineer, VTS

    Banking systems, monitoring and automation. Learning to prevent the next incident.

  3. 2022-2024

    Learning to operate under pressure

    Escalation Engineer, AWS

    Led critical production incidents across distributed systems. Built automation that cut incident-response time by 60%.

  4. 2024-2025

    Moving from reaction to prevention

    Technical Account Manager, AWS

    Moving upstream: from resolving incidents to advising partners on architecture and modernisation.

  5. 2026-now

    Making AI useful in the enterprise

    Customer Success Engineer, GitLab

    Working where AI adoption, developer workflows and customer outcomes meet.

Selected stories

Find the signal
behind the symptom.

Two different settings. The decisions, constraints and people behind the work.

01 / GitLab · Internal tooling

Spend the time on judgement,
not gathering context.

I built an agentic solution that brings scattered customer information together, assesses risk against defined parameters, and produces scheduled analysis for our assigned accounts.

Applied AIRisk analysisShared tooling
From context to a signal
01 / GatherThe relevant context.

Usage, conversations, commercial context.

02 / Set guardrailsControl where it matters.

Team-defined risk criteria + deterministic checks

03 / SynthesizeA structured assessment in ~15 minutes.

Scheduled analysis for assigned accounts

Inside the buildThe problem, choices & outcome

The problem

Coverage takes more than a dashboard.

A useful customer health assessment brings together information that rarely lives in one place. Gathering it manually could take more than two hours before any analysis had even started. Repeating that across an assigned customer portfolio limited how much we could understand, and how often.

GitLab’s public handbook describes the assessment model: recurring assessments of adoption, technical risk and customer health. The workflow here is the internal implementation I built around it.

The choices

Build a repeatable workflow around the agent.

Collect across sources.
Bring the information together as part of the workflow, reducing the manual preparation needed before analysis.
Give risk analysis boundaries.
Use parameters defined by the team and deterministic hooks where behaviour needs to be controlled.
Run on a schedule.
Make signal analysis a recurring capability across assigned accounts.
Make it a shared tool.
Distribute the plugin centrally and keep it open to contributions from colleagues, so improvements can reach the wider team.

Observed in my workflow

~15 minto produce the analysis

2+ hoursto gather the information manually,
before analysis

The bigger change is coverage: recurring analysis across more customers than the same manual process could support. The comparison is not like-for-like: the manual process was mostly context gathering, while the workflow produces a full assessment. The change is in coverage, not only the clock.

Public contextCSE Assigned ↗︎Health assessments ↗︎

02 / AWS Summit London · 2025

Modernising rail health.
A story told together.

At AWS, Steamhaus was my partner customer. I co-presented their work with Sperry Rail: how a rail inspection business modernised its platform to turn growing volumes of data into useful decisions.

Partner collaborationCloud modernisationSpeaking
FROM PROOF OF CONCEPT TO PLATFORM
APP216 / 30 April 2025AWS × Steamhaus × Sperry Rail
Inside the sessionThe partnership & technical story

My role

Build a story the room could use.

I worked with Tom Misiukanis, Principal Consultant at Steamhaus - the AWS Partner I supported - and Bobby Gilbert, Senior Director of Digital Transformation at Sperry Rail, Steamhaus’s customer, to turn a complex modernisation programme into a breakout session worth presenting at AWS Summit London. It had to be strong enough to hold a room of hundreds: clear on the operational problem, honest about the constraints, and useful to people facing similar work.

The session showed what partner-led AWS support looks like when the three sides work as one team. Sperry brought the operational context and outcomes; Steamhaus brought the implementation; I brought the AWS perspective and helped connect the technical choices to the business problem.

On stage, I opened with skills, legacy dependencies, governance and continuity. Sperry then shared its operational journey, and Steamhaus explained the implementation.

The engineering story

A working proof of concept still has to scale.

Sperry’s AI rail-data analysis tool, Elmer, could identify potential rail defects, but the processing platform struggled to keep up with the incoming data. The platform did not follow a prescribed architecture: it evolved from an EC2 proof of concept to managed containers, orchestrated processing and a cloud data platform as the workload grew.

Fargate and ECS handled container workloads, while Step Functions coordinated processing. Automated ingestion and repeatable infrastructure reduced manual hand-offs; the choices followed production constraints and reduced the operational work left to the team.

A takeaway from the session

Change the boundaries.
Change what you operate.

A compact way to think about where complexity lives.

01 / One deployment
A shared release boundary.

Responsibilities live inside one application. Deployment is straightforward, but a change can require releasing and scaling the whole application together.

And serverless?

A separate operating choice. Managed compute such as Lambda or Fargate changes who manages the underlying infrastructure. It can support different application structures; it is not simply the next step after microservices.

Conceptual illustration adapted from the session. Architecture choices depend on the workload; more services also introduce coordination and operational complexity.

Sperry & Steamhaus · Published outcomes

~35%lower monthly cost for Elmer, Sperry’s AI rail-data analysis tool

Near real timeprocessing, replacing an eight-hour queue

What I brought to the stage was the partnership story: Sperry’s domain knowledge, Steamhaus’s implementation expertise, and AWS connecting the technical choices to the operating problem. The delivery outcomes belong to Sperry and Steamhaus.

Read the customer storySperry Rail & Steamhaus on AWS ↗︎

Away from the keyboard

Strong coffee.
Strong sets.

Outside work, I’m usually training or trying to find an espresso good enough to justify walking across Dublin for it. Tiny improvements, repeated obsessively, eventually add up.