What follows is my reading of the craft, with references to the essays I’ve written. It isn’t a manual: it’s the view of someone who has spent fifteen years making software in hybrid roles — architect, advisor, manager — and tries to tell what actually changes from what only seems to.
Last revised: 7 May 2026.
Thesis, in one sentence
Software is a craft in the pre-industrial sense of the word: apprenticeship, taste, and limits. Most “best practices” are defaults chosen for the wrong reasons, kept because nobody measured the cost of adopting them.
Everything that follows is the reasoning behind that sentence.
How I see it
- An architecture is a set of inheritable decisions. If two years later nobody knows why a choice was made, it isn’t architecture: it’s a fossilised accident.
- Technical leadership is an authority problem, not a hierarchy one. People follow you because they’ve seen you be right often enough. The rest is costume.
- Europe shouldn’t copy Silicon Valley. It doesn’t have the preconditions — not the capital, not the ecosystem, not the socially acceptable failure. Our edge is the long horizon: projects that last, stable teams, loyal clients. Instead of imitating the fast model, it’s worth capitalising on what we actually have.
Essays on this topic
Work with me
On architecture and technical leadership my engagement is almost always one of three: a decision that needs to be made well now, a struggling architecture that needs straightening, or a technical person who needs growing.
Who it's for
CTOs and Heads of Engineering who need to present a significant architectural choice to a board and want a second head first
Technical founders realising the architecture that got them here won’t get them to the next order of magnitude
Platform teams inheriting a complex system who need to decide what to keep, rewrite, or throw away
Emerging technical leaders who want an outside mentor for the hardest decisions
How I work
- Architecture review (2–4 weeks)
I take an existing or planned architecture, talk with the people maintaining it, read the design docs and ADRs, and return a documented judgement: what to keep, what to change, what to measure before changing it.
- New platform design (4–8 weeks)
From scratch, or from a situation that no longer holds. I work with the internal team to produce a set of ADRs, a reasoned stack, and a roadmap with measurable milestones.
- Technical-leadership mentoring (ongoing)
A couple of calls per month with a CTO, tech lead or architect in growth. Protected space to talk about hard decisions without internal politics.
Engagement FAQ
- Do you do coding or code review?
No. It isn’t my added value. The advisory is on perimeter decisions, not on implementation.
- Do you work with any stack?
I work on the decisions about the stack, not inside a single stack. My value is language-independent — it’s knowing which trade-offs actually matter at the two-year horizon.
- How long does a typical engagement last?
Two to four weeks for a review, one to two months for a design, ongoing for mentoring.
- How is it billed?
Per documentable output, not per day. Fixed price tied to deliverables agreed up front.
Email me at hello@margiovanni.it with a couple of lines of context. I reply within a few business days with a concrete proposal, or a polite no if it's not my scope.
Questions & answers
Why 'craft' instead of 'engineering'?
Because engineering presupposes codified, repeatable knowledge. In real software — the kind that ships, survives three CTOs, and ends up in ten different contracts — knowledge is largely tacit, transmitted by apprenticeship, and changes with context. ‘Craft’ describes the reality more honestly.
Does the framing matter?
It changes everything about who you hire, how you grow them, how you document, how you decide. Engineer-thinking looks for process. Craft-thinking looks for masters, patience, and a body of past decisions to build on.