Was folgt, ist meine Lesart des Handwerks, mit Bezug auf die Essays, die ich geschrieben habe. Es ist kein Handbuch: Es ist die Sicht von jemandem, der seit fünfzehn Jahren in hybriden Rollen Software macht — Architekt, Advisor, Manager — und versucht zu verstehen, was sich wirklich ändert und was bleibt.
Letzte Überarbeitung: 7. Mai 2026.
Die These in einem Satz
Software ist ein Handwerk im vorindustriellen Sinne des Wortes: Lehre, Geschmack und Grenzen. Die meisten „Best Practices” sind Default-Entscheidungen, die aus den falschen Gründen getroffen und beibehalten wurden, weil niemand je die Kosten ihrer Übernahme gemessen hat.
Wie ich es sehe
- Eine Architektur ist eine Reihe vererbbarer Entscheidungen. Wenn nach zwei Jahren niemand weiß, warum eine Wahl getroffen wurde, ist diese Wahl keine Architektur: Sie ist ein versteinerter Unfall.
- Technische Führung ist ein Autoritätsproblem, kein Hierarchieproblem. Man folgt dir, weil man oft genug gesehen hat, dass du recht hast. Der Rest ist ein Kostüm.
- Europa muss das Silicon Valley nicht kopieren. Es hat nicht die Voraussetzungen — weder das Kapital noch das Ökosystem noch das sozial akzeptierte Scheitern. Unser Vorteil ist die lange Zeit: Projekte, die dauern, stabile Teams, treue Kunden. Statt das schnelle Modell zu imitieren, lohnt es sich, dieses zu kapitalisieren.
Essays zu diesem Thema
Lass uns zusammenarbeiten
Mein Engagement zu Architektur und technischer Führung läuft fast immer auf eines dieser drei Dinge hinaus: eine Entscheidung, die jetzt richtig getroffen werden muss; eine Architektur in Schwierigkeiten, die geradezurücken ist; eine technische Person, die wachsen soll.
Für wen das nützlich ist
CTOs und Heads of Engineering, die einem Vorstand eine bedeutsame Architekturentscheidung präsentieren müssen und davor einen zweiten Kopf wollen
Technische Gründer, die merken, dass die Architektur, die sie hierhergebracht hat, sie nicht zur nächsten Größenordnung führen wird
Plattformteams, die ein komplexes System erben und entscheiden müssen, was zu behalten, was umzuschreiben, was zu verwerfen ist
Wachsende technische Führungskräfte, die einen externen Mentor wollen, um die unbequemsten Entscheidungen zu besprechen
Wie ich arbeite
- Architecture Review (2–4 Wochen)
Ich nehme eine bestehende oder geplante Architektur, spreche mit den Verantwortlichen, lese die Design-Docs und ADRs und liefere ein dokumentiertes Urteil: Was zu behalten, was zu ändern, was zu messen ist, bevor man es ändert.
- Entwurf einer neuen Plattform (4–8 Wochen)
Von Grund auf oder aus einer Situation, die nicht mehr trägt. Ich arbeite mit dem internen Team, um eine Reihe von ADRs, einen begründeten Stack und eine Roadmap mit messbaren Meilensteinen zu produzieren.
- Mentoring für technische Führung (laufendes Engagement)
Ein, zwei Calls pro Monat mit einem CTO, Tech Lead oder Architekten in Entwicklung. Geschützter Raum, um schwierige Entscheidungen ohne interne Politik zu besprechen.
Operative Fragen
- Übernimmst du auch Coding oder Code Review?
Nein. Das ist nicht mein Mehrwert. Die Beratung dreht sich um Perimeter-Entscheidungen, nicht um die Umsetzung.
- Arbeitest du mit jedem Stack?
Ich arbeite mit Stack-Entscheidungen, nicht innerhalb eines einzigen Stacks. Mein Wert ist sprachunabhängig — es geht darum zu verstehen, welche Trade-offs auf zwei Jahre wirklich zählen.
- Wie lange dauert ein typisches Engagement?
Zwei bis vier Wochen für eine Review, ein bis zwei Monate für einen Entwurf, laufend für das Mentoring.
- Wie wird abgerechnet?
Nach dokumentierbarem Output, nicht nach Tag. Der Preis ist fix und an zu Beginn vereinbarte Liefer-Dokumente gebunden.
Schreib mir an hello@margiovanni.it mit zwei Zeilen Kontext. Ich antworte innerhalb weniger Werktage mit einem konkreten Vorschlag oder einem höflichen Nein, wenn es nicht in meinen Bereich fällt.
Questions & answers
Warum „Handwerk“ statt „Ingenieurwesen“?
Weil Ingenieurwesen ein kodifiziertes, wiederholbares Wissen voraussetzt. In der echten Software — der, die in Produktion geht, drei CTOs überlebt und in zehn verschiedenen Lastenheften landet — ist das Wissen weitgehend implizit, wird durch Lehre weitergegeben und ändert sich mit dem Kontext. „Handwerk“ beschreibt die Realität besser.
Was macht das für einen Unterschied?
Es ändert alles: wen du einstellst, wie du ihn wachsen lässt, wie du dokumentierst, wie du entscheidest. Wer als Ingenieur denkt, sucht Prozesse. Wer als Handwerker denkt, sucht Meister, Geduld und ein Erbe vergangener Entscheidungen, von dem er ausgehen kann.