Approach

How I work

I'm Massimo Selvi — an Engineering Manager with a Cloud Architect's hands, based in Ravenna, Italy. I've been building software since 1999 and building it on AWS since 2019. What I actually do for a company is narrower and more useful than a job title: I design the systems engineers work in — hiring, onboarding, 1:1s, training, review process, ceremonies, metrics, decision records — and then keep them running long enough that they outlive me.

Background

My career started in full-stack development — Apple/NeXT WebObjects in early 2000s, then PHP, then Ruby on Rails, then Laravel, then Node.js and TypeScript. In 2019 I moved to AWS cloud architecture, designing event-driven serverless systems for production workloads — a run of engagements that took me from lifting legacy PHP onto managed infrastructure to owning a multi-region stack across two continents.

Between late 2023 and mid-2025 I was interim CTO at Toky Digital, with strategic oversight of the cloud infrastructure and of software development for a critical communications platform: the first time I owned the whole technical function rather than a part of it. Since February 2026 I've held a fractional mandate at F.technology, an Italian software company, spanning engineering management, cloud architecture and tech lead work: designing the governance systems the development team runs on, while still writing production code on the hardest parts of it.

That combination is the point. Most people who design the system can no longer write the code, which is why so many engineering processes fail on contact with a real codebase. I can still challenge an estimate, because I wrote the equivalent code last month.

The operating principle

Make the right thing faster than the wrong thing.

Engineers are rational about friction. If going around a process is faster than going through it, they will go around it — and they should; they are trying to ship. So the job is not policing habits, it is designing the environment so the right path is also the cheapest one.

I learned this the expensive way. In my first month at an interim-CTO mandate I wrote a thorough documentation hub; months later a new engineer was blocked in a public channel, and a colleague told him not to bother with it because it was out of date, then sent him the working config privately. The hub had lost to a single person acting as the team's search engine — and it was stale by construction, written before the system had stopped moving and months before it had any audience. What fixed it was setup scripts that failed loudly and printed the exact fix: a script cannot drift from reality without failing, where a document drifts silently and nobody finds out until someone is blocked in public.

That is the principle applied in three places:

Setup & documentation — executable over descriptive. A script that runs beats a page that describes.
Architecture & governance — decision records inside the pull request, where review is already happening, not in a separate system nobody opens.
Delivery — rituals and expectations that remove micro-decisions, so early alignment costs less than late rework.

Some things cannot be made faster than skipping them — a security review, a design for something genuinely new, a conversation about underperformance. Where friction cannot be reduced, the cost of avoiding it is made visible instead, which is why thresholds are written down in advance: five critical bugs and feature work stops is a rule agreed when nobody is under pressure, not a judgement call made under it.

Two honest caveats. Self-executing scripts need continuous maintenance; when a toolchain shifts, someone updates them, or they become the new stale wiki. And making a path frictionless gets it adopted — it does not make it right. That still takes judgement.

The operating model

An engineering manager is the single point of accountability for people, process and team health. Not for architecture — that belongs to the Tech Lead. Not for the timeline — that belongs to the PM. Most role descriptions are a shopping list of strengths; the lines below are what actually make the role work, so I publish them before an engagement starts rather than discovering them during one.

What I own

People & career development: Structured growth paths, biweekly coaching 1:1s, honest and timely feedback, quarterly check-ins, decisive handling of underperformance. Psychological safety as an explicit deliverable, not a hope.
Team composition & hiring: Workforce planning, role profiles, interview design, onboarding design, graceful offboarding, bus-factor monitoring.
Process & delivery system: Sprint cadence, ceremonies, Definition of Ready and Done, review SLAs, a 70/15/15 capacity model splitting project, operations and growth work, and a 24-hour escalation path for a blocked engineer.
Engineering culture & standards: Trunk-based development, architecture decision records, code review culture, testing philosophy, Tech Radar co-ownership, and a training system with a budget attached.
Metrics & visibility: Team health, velocity trend, PR cycle time, review turnaround, sprint completion rate. Measured to detect a pattern before it becomes a crisis — the system is measured, the person is coached.
Cross-functional collaboration: Supplying the capacity ceiling that product and delivery plan against, and mediating when delivery pressure meets sustainability. Scope cuts, not overtime.
Organisational health & communication: Cascading decisions so nobody learns about a change affecting them from a rumour, and filtering noise without creating an information vacuum.

What I don't own

Boundaries beat good intentions. Everything here belongs to somebody else, by design.

Technical architecture decisions: Tech Lead
Code review and PR approval: Tech Lead
Client communication and expectations: Project Manager
Sprint delivery and timeline commitment: Project Manager
Product backlog prioritisation: Product Owner
Task assignment within a sprint: The team, self-organising + Tech Lead
Commercial contracts and budget: Project Manager + CEO

Who decides what

The three roles overlap constantly. Naming the decider in advance is what stops the overlap becoming a standoff.

How should we build this?: Tech Lead
When will it be done?: PM, with Tech Lead feasibility input
Who should build this?: EM, with Tech Lead skill-fit input
Is the team healthy enough to sustain this pace?: EM
Is the code good enough to ship?: Tech Lead
Does the client accept this deliverable?: PM
Is this person growing?: EM
Should we refactor or ship?: Tech Lead + PM, EM arbitrates if stuck

One operating rule holds all of it together: no unresolved conflict survives a sprint boundary.

Working style

Remote & EU-basedAvailable across European time zones, fully remote.
Async-firstSlack, Loom, and Docs over meetings — written communication by default.
Long-term engagementsA permanent seat, or a 6+ month mandate — not one-off audits.
Guide & ValidateIntensive initial collaboration to establish patterns, then advisory review as the team builds.

Selected work

This site itself is a case study: a static site on S3/CloudFront, infrastructure defined with AWS CDK, following Well-Architected practices. Zero JavaScript bundles, no third-party trackers, and the architectural decisions written down as numbered records rather than recalled from memory.

View on GitHub

Open to a permanent EM role — fractional mandates considered, but the fit matters more than the format. I'm most useful where the systems don't exist yet.