Remote fractional CTO, anywhere in Italy.
I live in Conegliano, Italy. For the past five years I've worked almost entirely full-remote, in senior and lead roles, with companies in Milan, Verona, Venice and Vasto. Distance was never the problem.
Full-remote for 5+ years · Teams of up to 7 devs coordinated remotely · Slack + weekly call
What a remote fractional CTO is — and why it works.
A remote fractional CTO is a part-time CTO who leads technical strategy and development teams at a distance, through written processes, regular calls and shared tools — no desk in your office.
What a fractional CTO does — architecture, team coordination, roadmap, hiring — is covered on the fractional CTO page. This page answers the other question, the one I hear most often: how does it work if we're not in the same city?
It works because good technical work is written by nature: roadmaps, architecture decisions, code reviews, pipelines. Over the past five years I've coordinated teams of up to 7 developers remotely — remote isn't a compromise I accept, it's my normal way of working.
Distance doesn't reduce control: it increases it. Everything that matters stays written, readable and verifiable.
How I work remotely: processes, tools, rhythm.
Direct Slack
One direct channel, fast answers, decisions tracked in writing. What matters doesn't stay in a chat scroll: it becomes a document.
Structured weekly call
One fixed call with an agenda, for the decisions that need a conversation. No meeting marathons.
Written documentation
Every important choice leaves a written trace: context, options, decision. Whoever joins later reads, understands and moves on.
Written roadmap
Priorities live in a shared, readable roadmap — not in someone's head. You always know what comes next and why.
Code review
Quality is checked on pull requests, not by watching who sits where. Every change gets read before it reaches production.
CI/CD
Automated pipelines: every release is repeatable and verifiable. You see what ships to production, and when.
When on-site presence really matters.
- The kickoff of a complex engagement: one day on-site at the start can save weeks of alignment.
- Delicate team moments: tensions, reorganizations, conversations that deserve to happen in person.
- Long architecture or product workshops, where a physical whiteboard still beats the best call.
I live in Conegliano, in the province of Treviso. In Italy's Northeast I combine remote work with on-site days: see the dedicated pages for Treviso, Venice and Padua. For the rest of Italy I work remotely, with occasional travel (expenses reimbursed) when presence is truly needed.
That's the full picture: the Northeast in person too, all of Italy remotely.
Who this works for (and who it doesn't).
Who it's for
- Startups and SMBs anywhere in Italy, without a senior technical reference nearby.
- Teams that are already distributed or hybrid, internal or external: agencies and freelancers to coordinate.
- Founders who want written roadmaps and decisions, not verbal reassurance.
Who it's not for
- Anyone who wants someone at a desk every day: that's an in-house CTO, and if you need one I'll help you hire them.
- Anyone looking for a full-time dev writing code eight hours a day. If the problem is a stalled project, start from software project rescue.
- Teams that reject any written process: before a remote CTO, you need the will to document.
The questions I get most often about remote work.
We work across different time zones — is that a problem?
My clients are in Italy, so time zones rarely come up. If your team has developers abroad, written processes — roadmap, reviews, documentation — absorb a 1-3 hour offset well: decisions don't wait for a meeting.
How do we communicate, in practice?
Direct Slack for quick things, one weekly call with an agenda for decisions, written documents for everything that has to last. If something can be a message, it is a message: meetings happen only when they're needed.
How do I trust someone who is never in the office?
From week one I produce verifiable artifacts: a written roadmap, code review on pull requests, regular reports. Trust is built on what you can read and verify, not on presence. And the quarterly contract leaves you free to walk away if it doesn't work.
How does remote onboarding work?
First two weeks: access to repositories, boards and documentation, a call with the key people on the team, and a written snapshot of the state of code and processes. From there, the roadmap. It's the process I've used for years, always remotely.
If you're remote, how do I check your work?
Through the work itself: a prioritized roadmap, documented decisions, reviews tracked on pull requests, CI/CD pipelines showing what ships to production and when. You see results, not desk hours — and that's more control than you'd have with someone on-site.
Let's talk — on a call, of course.
Thirty free minutes to figure out if working remotely fits your context. If I think you need someone on-site, I'll tell you before we start.
Reply within 24 hours · All of Italy, remotely