Alessandro Orlandi
Ich entwickle Software.
Davor habe ich Entwicklung beauftragt.
Jahrelang habe ich auf Konzernebene entschieden, was gebaut wird, was es kostet und wer es umsetzt — ohne selbst zu entwickeln. Seit 2019 schreibe ich Code. Ich weiß, wie sich beides anfühlt.
Die meisten Software Engineers kommen aus einer Richtung.
Ich bin den entgegengesetzten Weg gegangen.
Ich habe auf der Business- und IT-Seite angefangen. Habe entschieden, was gebaut wird. Budget verantwortet. Entwicklerteams geführt — ohne selbst zu entwickeln. Dann habe ich angefangen zu entwickeln. Und mitgenommen, was ich auf der anderen Seite gelernt hatte.
HR Recruiting
Wie Unternehmen über Rollen, Teams und Talent entscheiden
Ich habe meine Laufbahn im Recruiting begonnen — nicht in der IT. Ich habe gelernt, wie Unternehmen intern über Rollen, Verantwortung und Teamstruktur nachdenken. Das war kein Umweg. Es war der Einstieg in ein Verständnis von Organisationen, das mir später niemand beibringen musste.
IT Solutions Architect & Technical Product Owner
Entwicklung beauftragen, bevor ich sie selbst gemacht habe
Ich habe Budget verantwortet, Make-or-Buy-Entscheidungen getroffen, Vendor-Auswahl betrieben und ein Change Advisory Board eingeführt und geleitet. Ich habe Entwicklerteams koordiniert und Stakeholder auf Managementebene aligned — ohne selbst eine Zeile Produktionscode zu schreiben. Das ist der Grund, warum ich heute weiß, wie sich die andere Seite des Tisches anfühlt.
Lead Frontend Engineer & Fullstack Software Engineer
Engineering von innen lernen — mit dem Blick von außen
Seit 2019 entwickle ich professionell Software. Direkter Kundenkontakt in allen Projekten, technische Beratung, Pilotverantwortung für neue Technologien. Zunehmend in frühe Planungsphasen eingebunden — bevor die eigentliche Umsetzung begann. Die Vorgeschichte hat meinen Engineering-Blick von Anfang an geprägt: Was soll gebaut werden? Warum? Macht das Sinn?
Architect, Consultant & Senior Engineer
Business und Engineering aus eigener Erfahrung verbinden
Bei Evora habe ich die Schnittstelle zwischen Business und Engineering übernommen: Anforderungsaufnahme mit Key-Usern, Übersetzung in technische Tickets, fachliche Führung eines remote Entwicklerteams. Als Selbstständiger habe ich eigene Produkte entwickelt — darunter DienstBuddy, eine mobile App für Rettungsdienst-Mitarbeitende. Heute bin ich Senior Software Engineer bei Peerigon.
Parallel im Rettungsdienst aktiv
AKTIVNeben meiner Tätigkeit in der Softwareentwicklung engagiere ich mich bis heute im Rettungsdienst. Diese Erfahrung prägt meine Art zu kommunizieren, Prioritäten zu setzen und auch unter Druck fundierte Entscheidungen zu treffen.
HR Recruiting
Wie Unternehmen über Rollen, Teams und Talent entscheiden
Ich habe meine Laufbahn im Recruiting begonnen — nicht in der IT. Ich habe gelernt, wie Unternehmen intern über Rollen, Verantwortung und Teamstruktur nachdenken. Das war kein Umweg. Es war der Einstieg in ein Verständnis von Organisationen, das mir später niemand beibringen musste.
IT Solutions Architect & Technical Product Owner
Entwicklung beauftragen, bevor ich sie selbst gemacht habe
Ich habe Budget verantwortet, Make-or-Buy-Entscheidungen getroffen, Vendor-Auswahl betrieben und ein Change Advisory Board eingeführt und geleitet. Ich habe Entwicklerteams koordiniert und Stakeholder auf Managementebene aligned — ohne selbst eine Zeile Produktionscode zu schreiben. Das ist der Grund, warum ich heute weiß, wie sich die andere Seite des Tisches anfühlt.
Lead Frontend Engineer & Fullstack Software Engineer
Engineering von innen lernen — mit dem Blick von außen
Seit 2019 entwickle ich professionell Software. Direkter Kundenkontakt in allen Projekten, technische Beratung, Pilotverantwortung für neue Technologien. Zunehmend in frühe Planungsphasen eingebunden — bevor die eigentliche Umsetzung begann. Die Vorgeschichte hat meinen Engineering-Blick von Anfang an geprägt: Was soll gebaut werden? Warum? Macht das Sinn?
Architect, Consultant & Senior Engineer
Business und Engineering aus eigener Erfahrung verbinden
Bei Evora habe ich die Schnittstelle zwischen Business und Engineering übernommen: Anforderungsaufnahme mit Key-Usern, Übersetzung in technische Tickets, fachliche Führung eines remote Entwicklerteams. Als Selbstständiger habe ich eigene Produkte entwickelt — darunter DienstBuddy, eine mobile App für Rettungsdienst-Mitarbeitende. Heute bin ich Senior Software Engineer bei Peerigon.
Parallel im Rettungsdienst aktiv
AKTIVNeben meiner Tätigkeit in der Softwareentwicklung engagiere ich mich bis heute im Rettungsdienst. Diese Erfahrung prägt meine Art zu kommunizieren, Prioritäten zu setzen und auch unter Druck fundierte Entscheidungen zu treffen.
Ich bin kein Engineer, der sich zum Business vorgearbeitet hat.
Ich bin jemand, der beide Seiten von innen kennt.
Ich schreibe Code und kann gleichzeitig beurteilen, ob das Richtige gebaut wird — weil ich weiß, wie sich beides in der Praxis anfühlt.
Es gibt Situationen, in denen stimmt etwas nicht —
aber niemand benennt es präzise. Diese Probleme haben selten eine technische Ursache.
Entscheidungen werden zu spät gestellt
Welches Problem soll eigentlich gelöst werden? Ist das die richtige Architektur? Macht es Sinn, das selbst zu bauen? Diese Fragen kommen oft erst, wenn die Umsetzung bereits läuft.
- Architekturentscheidungen werden rückwirkend korrigiert — mit hohem Aufwand
- Features werden gebaut, die das eigentliche Problem nicht lösen
- Technische Schulden entstehen durch falsche Ausgangsprämissen
- Entwicklung dauert länger als geplant — ohne klare Ursache
Ich stelle diese Fragen früh — wenn die Antworten noch etwas verändern können. Bevor eine Zeile Code geschrieben wird.
- Klarheit über das tatsächliche Problem, bevor Lösungen diskutiert werden
- Architekturentscheidungen mit nachvollziehbarer Begründung
- Weniger rückwirkende Korrekturen im laufenden Projekt
- Realistischere Aufwandsschätzungen von Anfang an
Klingt vertraut?
Gespräch aufnehmenProblem
Welches Problem soll eigentlich gelöst werden? Ist das die richtige Architektur? Macht es Sinn, das selbst zu bauen? Diese Fragen kommen oft erst, wenn die Umsetzung bereits läuft.
Das führt dazu
- Architekturentscheidungen werden rückwirkend korrigiert — mit hohem Aufwand
- Features werden gebaut, die das eigentliche Problem nicht lösen
- Technische Schulden entstehen durch falsche Ausgangsprämissen
- Entwicklung dauert länger als geplant — ohne klare Ursache
Genau hier setze ich an
Ich stelle diese Fragen früh — wenn die Antworten noch etwas verändern können. Bevor eine Zeile Code geschrieben wird.
Das Ergebnis
- Klarheit über das tatsächliche Problem, bevor Lösungen diskutiert werden
- Architekturentscheidungen mit nachvollziehbarer Begründung
- Weniger rückwirkende Korrekturen im laufenden Projekt
- Realistischere Aufwandsschätzungen von Anfang an
Wie ich arbeite
Ich fange nicht mit Technologien an.
Ich fange mit Fragen an.
Zum Beispiel:
- ›Welches Problem soll eigentlich gelöst werden?
- ›Warum wurde diese Architektur gewählt?
- ›Warum dauert Entwicklung länger als erwartet?
- ›Welche Annahmen wurden getroffen — und welche davon stimmen noch?
- ›Wo entstehen Reibungsverluste zwischen Business und Engineering?
Das klingt selbstverständlich. In der Praxis passiert es selten.
Ich schreibe weiterhin selbst Code.
Nicht weil es immer nötig ist. Sondern weil es mein Urteilsvermögen scharf hält. Ich kann technische Aufwände realistisch einschätzen, weil ich sie selbst trage. Ich kann Architekturentscheidungen bewerten, weil ich ihre Konsequenzen kenne. Ein Konzept, das ich nicht selbst umsetzen könnte, würde ich nicht empfehlen.
Kontakt
Wenn Sie das hier lesen, haben Sie vermutlich eine konkrete Situation im Kopf.
Schreiben Sie mir. Kein Pitch, kein Prozess — ein Gespräch.
$ Initiiere Kontaktaufnahme...