Der Product Architect, den Unternehmen rufen, wenn der Prototyp zum System werden muss.

Kurzfassung

Ich bin unabhängiger Product Architect. Ich helfe Unternehmen, vom funktionierenden Prototypen zu einem System zu kommen, das skaliert. Die Aufträge, die zu mir passen, haben ein gemeinsames Profil: Eine Idee hat sich bewährt, und Team, Codebase und Organisation brauchen jetzt eine andere Form, um zu wachsen. Die Architektur, die das Unternehmen bis zur funktionierenden v1 gebracht hat, wird es selten zu 100 Entwicklern und echter Produktionslast tragen. In dieser Lücke arbeite ich.

Mein Vorgehen, wenn ich an Bord komme, ist jedes Mal dasselbe. Analysieren, was bereits da ist. Geschäftsziel und Endkunde verstehen. Mit dem Engineering-Team zusammensetzen und den Code lesen. Mit Designern über das Design-System sprechen, was bleibt, was angepasst wird. Mit Product Ownern und Business Leads an KPIs und Prioritäten arbeiten. Mit CTOs, CPOs und Tech Leads den Arbeitsmodus erarbeiten, der von 10 auf 100 Entwickler skaliert. Und dann: Code schreiben, Architektur designen, gemeinsam mit dem Team in die Produktion liefern.

Meine Arbeit erstreckt sich auf Automotive, Telekommunikation, Smart Energy, Fertigung und KI-gestützte Schulung. Der gemeinsame Nenner: grosse Organisationen mit komplexen Plattformen, die liefern müssen, ohne das zu beschädigen, was bereits funktioniert. KI taucht heute in den meisten Aufträgen auf, ist aber eine Technologie im Werkzeugkasten, nicht die Überschrift.

Ich bin in Deutschland ansässig. Ich habe meine Karriere bei Hewlett-Packard und frog begonnen, beides amerikanische Unternehmen, und habe während meiner gesamten Karriere mit verteilten Teams in den USA, Europa und Indien zusammengearbeitet. Ich bin vor Ort, wenn die Arbeit es erfordert, ob in Europa, den USA oder anderswo.

Was ich mitbringe, das schwer einzustellen ist

Die meisten Senior Engineers kommen aus einem Stack. Die meisten Senior Consultants haben nie unter echter Produktionslast geliefert. Ich komme aus beidem. Das ist das Ungewöhnliche an meiner Arbeit, und genau das ist, was am Wendepunkt zwischen Prototyp und produktionsreifem System gebraucht wird.

Die andere Hälfte des Vorteils ist Bandbreite. Ich habe Produkte über viele Branchen und viele Disziplinen hinweg ausgeliefert und gelernt, zwischen ihnen zu übersetzen. CTOs sprechen mit mir in Architekturbegriffen. Designer sprechen mit mir in Systembegriffen. Produkt spricht mit mir in Outcome-Begriffen. Operations und Business Leads sprechen mit mir in Workflow- und KPI-Begriffen. Ich halte all diese Gespräche auf dasselbe Ziel ausgerichtet: ein Produkt, das ausgeliefert wird, skaliert und wartbar bleibt, wenn ich weg bin.

Die meisten Architekturprobleme leben an den Nahtstellen zwischen Disziplinen, nicht innerhalb einer einzigen. Die Entscheidungen, die die User Experience beeinflussen, sind auch Build-System-Entscheidungen. Die technischen Einschränkungen, die die Produktstrategie formen, sind auch Daten- und Governance-Entscheidungen. Die Modulgrenzen, die die Teamgeschwindigkeit bestimmen, sind auch Organisationsentscheidungen. Sie aus einem einzigen Team heraus zu lösen, reicht selten. Man braucht jemanden, der sich über alle hinweg bewegen und in jeder einzelnen glaubwürdig bleiben kann.

Die meisten Architekturprobleme sind ausserdem keine Technologieprobleme. Sie sind Zuständigkeitsprobleme. Unklare Modulgrenzen, gemeinsame Abhängigkeiten, die niemand warten will, Build-Systeme, die Teams bestrafen, wenn sie unabhängig deployen. Die Zuständigkeiten klären, und die Architektur folgt.

Die wichtigste Fähigkeit ist nicht die Wahl zwischen Frameworks oder der Entwurf einer Microfrontend-Shell. Es ist: in eine Plattform mit 200 aktiven Mitwirkenden einzusteigen, den Reibungspunkt innerhalb einer Woche zu verstehen und Entscheidungen zu treffen, die sechs Monate später noch standhalten.

Ich plane meinen Abgang ab Tag null. Ich habe genug falsche Entscheidungen getroffen, um den Unterschied zwischen einer Überzeugung und einer Vermutung zu kennen. Wenn ich sicher bin, sage ich es. Wenn nicht, sage ich das auch.

Wie ich hierher gekommen bin

Ich habe mit einer Berufsausbildung als Fachinformatiker bei Hewlett-Packard begonnen, dann Digitale Medien an der Hochschule Furtwangen studiert. Meine ersten Berufsjahre verbrachte ich bei frog (globale Design-Beratung), Jung von Matt/Neckar (kreatives Studio) und Intuity Media Lab (Innovationsstudio), wo ich Plattformen und native interaktive Prototypen (iOS, Android, Web) für Kunden wie Walt Disney Parks, Crytek, Walter AG und Mercedes-Benz aufgebaut habe. Diese drei Unternehmen haben mein kritisches Denken, meine fächerübergreifende Zusammenarbeit und mein Hands-on-Vorgehen geprägt. Dort habe ich gelernt, dass die eigentliche Herausforderung nicht ist, guten Code zu schreiben. Es ist, guten Code den Kontakt mit zehn Teams und drei Kontinenten überleben zu lassen.

Ich bin unabhängig geworden, weil die Probleme, die ich am besten löse, dort liegen, wo Produkt auf Design auf Engineering auf Operations trifft. Die Architekturentscheidungen, die die User Experience beeinflussen. Die technischen Einschränkungen, die die Produktstrategie formen. Die Build-Systeme, die die Teamgeschwindigkeit bestimmen. Diese Probleme überschreiten Organisationsgrenzen. Sie aus einem einzigen Team heraus zu lösen, reicht nicht. Man braucht jemanden, der über alle hinweg arbeiten kann.

Dieselbe Denkweise, zu Hause angewendet

Ein kleines Beispiel ausserhalb der Kundenarbeit: Ich betreibe eine KI-gestützte Optimierung über mein eigenes Energiesystem zu Hause. Eine Wolf-Heizung, ein PV-Wechselrichter, ein Heimspeicher und eine Wetterprognose, miteinander verbunden, um die selbst erzeugte Energie gegen den Heizbedarf der nächsten 24 Stunden auszubalancieren.

Ich habe es gebaut, weil der Heizungstechniker alles über die Heizung wusste und nichts über die PV-Anlage. Der PV-Techniker kannte den Wechselrichter und nichts von der Heizung. Beide waren in ihrer eigenen Disziplin exzellent. Keiner war darauf eingestellt, an die Nahtstelle zwischen den beiden zu denken, und genau dort liegt die Optimierung.

Die Denkweise, für die ich beruflich engagiert werde, ist dieselbe, die ich auf das Haus anwende, in dem ich wohne. Der Wert liegt an den Nahtstellen zwischen den Systemen, nicht innerhalb eines einzelnen.