Vom Prototypen, der funktioniert, zum System, das skaliert.
Product Architect, eingebettet in Ihr Team. 3 bis 9 Monate. Hands-on. Geplante Übergabe.
Ich bin Philipp. Fünfzehn Jahre lang Produktionssysteme bei Siemens, Deutsche Telekom und Mercedes-Benz gebaut, und die Architekten beraten, die sie verantworten. Die meisten Senioren, denen Sie begegnen, haben eins von beidem gemacht. Der Abschnitt, in dem ein Prototyp erwachsen werden muss, braucht beides, in einer Person, im Code.
Geprägt durch frog und Intuity Media Lab.
Der Moment, in dem Unternehmen anrufen
Eine Idee hat bewiesen, dass sie funktioniert. Der Pilot hat die richtigen Leute überzeugt. Jetzt steht die Produktion an, und die wirkt schwerer als gedacht. Das Team kämpft mit der Codebase. Mehr Köpfe haben es langsamer gemacht. Die Architektur, die bis zur v1 getragen hat, wird selten 100 Entwickler und echte Produktionslast tragen. Die Entscheidung, die als Nächstes ansteht, ist keine Technologieentscheidung. Sie ist eine Architekturentscheidung, und sie bestimmt die nächsten 12 bis 18 Monate. Genau dort arbeite ich.
Wie ich arbeite
Hands-on. Im Code. Ab Tag eins. Die erste Woche ist eine Diagnose. Ich lese den Code, setze mich mit Engineers, Designern, Product Ownern und Business Leads zusammen, und komme mit einer klaren Sicht zurück, was als Nächstes gegen Sie arbeiten wird. Dann schreibe ich Code mit Ihrem Team, designe die Architektur und treffe die Entscheidungen, die die nächsten 12 bis 18 Monate bestimmen.
Ich arbeite eng mit CTOs, CPOs und Tech Leads am Arbeitsmodus, der von 10 auf 100 Entwickler trägt. Mit Designern am Design-System: was bleibt, was angepasst wird. Mit Produkt an KPIs und Prioritäten. Mein Engineering-Schwerpunkt ist Frontend, aber ich arbeite fliessend über Backend und Operations hinweg, weil die meisten Architekturprobleme an den Nahtstellen zwischen Disziplinen leben, nicht innerhalb einer einzigen.
Ich plane meinen Abgang ab Tag null. Der Test ist einfach: Kann das Team in gleicher Qualität ohne mich weiterarbeiten? Wenn ja, hat der Auftrag funktioniert. Für spezialisierte Anforderungen oder Kontinuität bringe ich erfahrene technische Kollegen aus meinem Netzwerk mit.
Ich bin selbständig geworden, weil die Probleme, die ich am besten löse, an den Nahtstellen zwischen den Disziplinen liegen, nicht innerhalb einer einzigen. Die Architekturentscheidung ist auch eine Design-System-Entscheidung. Die Build-System-Entscheidung ist auch eine organisatorische. Die Frage, wo KI hingehört, ist auch eine Workflow-Frage. Innerhalb eines Teams sieht man immer nur eine Seite davon. Von aussen, eingebettet für drei bis neun Monate, kann ich sie alle ansprechen.
Diese Arbeitsweise wurde geprägt durch meine Jahre bei frog und Intuity Media Lab, wo das Verstehen der Menschen, der Workflows und des Geschäfts vor der Technologieentscheidung kam, und geschärft durch 15 Jahre Enterprise-Delivery bei Siemens, Deutsche Telekom und Mercedes-Benz.
So sieht das in der Praxis aus
Ich kam als Frontend-Trainer zur Deutschen Telekom: HTML5, CSS3, Vue.js, Git-Workflows für die ersten rund fünfzig Entwickler, die das neue Magenta View CRM bauten. Zwei Wochen später stellte ich dem Chefarchitekten Fragen dazu, wie die Plattform zusammenhalten würde, sobald jeder europäische Markt darin entwickelt.
Diese Fragen brachten mir eine andere Rolle ein. Ich wurde zu einem von zwei Frontend-Architekten ernannt. Das Trainingsprogramm blieb, aber es war nicht mehr der Weg, auf dem neue Entwickler produktiv wurden. Wir führten eine Pattern Library ein, die später zur Grundlage des Design-Systems wurde, das das UX-Team aufsetzte. Wir führten eine Finite State Machine für das State-Management ein, damit Teams das Verhalten verstehen konnten, ohne den Code der anderen zu lesen. Wir entwarfen eine framework-agnostische Microfrontend-Architektur, sodass jedes Team jederzeit ausliefern konnte, ohne sich abzustimmen.
Am Ende arbeiteten 200+ Entwickler über mehrere europäische Märkte hinweg parallel an einem CRM, das tausende Callcenter-Agenten bedient. Die Feature-Velocity stieg um 30%. Oracle Siebel wurde abgelöst. Die Patterns gingen 2023 sauber in das interne Architektur-Team der Telekom über.
Ich kam, um Vue zu unterrichten. Ich ging mit der Verantwortung für die Architektur-Governance von zweihundert Entwicklern.
Warum diese Kombination selten ist
Ich arbeite an den Nahtstellen zwischen Produkt, Design, Engineering und Betrieb, weil das Skalierungsproblem selten innerhalb einer einzigen Disziplin lebt. CTOs sprechen mit mir in Architekturbegriffen. Designer in Systembegriffen. Produkt in Outcome-Begriffen. Operations 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.
Der Wert entsteht selten in einer einzelnen Entscheidung. Er entsteht an der Nahtstelle, an der drei Teams aufhören, dieselbe Geschäftslogik dreimal unterschiedlich zu schreiben. An der eine 200-Entwickler-Organisation neue Mitarbeiter nicht mehr durch Schulungen einarbeitet, sondern über eine Plattform, die sich selbst erklärt. An der ein Prototyp zur Infrastruktur wird.
KI ist eine der Technologien, mit denen ich arbeite. Heute taucht sie in den meisten Aufträgen auf. Das Urteilsvermögen, das entscheidet, wo sie hingehört und wo nicht, ist dasselbe, das in den letzten 15 Jahren auf jede andere Technologieentscheidung angewendet wurde.
Ein kleines Beispiel derselben Denkweise
Ich betreibe eine KI-gestützte Optimierung über eine Wolf-Heizung, einen PV-Wechselrichter, einen Heimspeicher und eine Wetterprognose. 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. 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.
Was das ist, und was es nicht ist
Was es ist
- Erfahrenes Urteilsvermögen, im Code, mit geplanter Übergabe
- Eine Person, eingebettet in Ihr Team für drei bis neun Monate
- Architekturentscheidungen, belegt durch funktionierenden Code, nicht durch Folien
- Disziplinübergreifende Sprachfähigkeit: Produkt, Design, Engineering, Betrieb
Was es nicht ist
- Eine Strategiefolie für den Aufsichtsrat
- Ein Interim- oder Fractional-CTO mit voller P&L-Verantwortung
- Body-Leasing oder ein weiterer Frontend-Freelancer
- KI-Beratung mit fertiger Roadmap auf der Suche nach einem Problem
Für wen das gedacht ist
Gemacht für industrielle Software-Hersteller und Mittelstands-Engineering-Organisationen: ein v1-Produkt, ein KI-Prototyp oder ein Legacy-Plattform-Ablöseprojekt, das ein echtes System werden muss, ohne das zu zerstören, was bereits funktioniert. Üblicherweise 30 bis 200 Entwickler. Oft reguliert, immer betriebskritisch. In Deutschland ansässig, international tätig in Europa und den USA.
Ausgewählte Referenzen
Wenn Ihr Prototyp läuft und der nächste Schritt schwer wirkt, melden Sie sich.
Erster Schritt ist ein 30-Minuten-Gespräch. Kostenlos, kein Pitch. Schildern Sie mir Ihre Situation und ich sage Ihnen ehrlich, ob ich helfen kann. Wenn es passt, ist der übliche Einstieg eine Architektur-Triage: zwei Tage Code-Review, Stakeholder-Gespräche und eine schriftliche Einschätzung, was als Nächstes gegen Sie arbeiten wird.
Schildern Sie mir Ihre Situation