Meine Arbeitsweise
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 fliessend über Produkt, Design, Engineering und Betrieb hinweg, weil die schwersten Skalierungsprobleme an den Nahtstellen zwischen ihnen leben. Die Zusammenarbeit ist bewusst befristet, der Ausstieg ab Tag null geplant. So sieht es aus.
Das Auftragsmodell
Analysieren (2 Tage)
Die Diagnostik. Ich lese den Code, spreche mit Engineers, Designern, Product Ownern und Business Leads und erfasse die Workflows. Ich schaue, was heute funktioniert, was Skalierung tatsächlich verlangt und wo Architektur, Team oder Arbeitsmodus als Nächstes gegen Sie arbeiten werden.
Sie erhalten drei Ergebnisse: eine priorisierte Sicht auf die Reibungspunkte, die Skalierung blockieren werden, eine Empfehlung, was zuerst zu fixen ist und warum, und eine ehrliche Einschätzung, ob weitere Arbeit überhaupt sinnvoll ist. Manchmal ist die Antwort "Bauen Sie das jetzt nicht", und das sage ich Ihnen im Voraus.
Validieren (2 bis 4 Wochen)
Ein fokussierter Sprint auf die wichtigste Entscheidung aus der Diagnostik. Das kann ein Proof of Concept gegen echte Daten und echte Rahmenbedingungen sein, ein technischer Spike auf eine Architekturwette oder ein kleiner Slice produktionsreifen Codes, der zeigt, dass die neue Form des Systems trägt.
Das Ziel ist Evidenz für eine Bauen-, Ändern- oder Verwerfen-Entscheidung, keine Demo. Wenn das Konzept nicht standhält, hat Ihnen diese Erkenntnis Monate erspart, in denen Sie das Falsche gebaut hätten.
Bauen (Wochen bis Monate)
Hands-on. Im Code. Mit Ihrem Team. Ich trete als arbeitendes Mitglied bei. Tägliche Standups. Pull-Request-Reviews. Architektur-Sessions. Pair-Programming, wenn es sinnvoll ist. Ich treffe Entscheidungen, schreibe Code und etabliere die Muster, auf denen Ihr Team nach meinem Weggang aufbaut.
Die Arbeit umfasst, was der Auftrag tatsächlich verlangt: Modulgrenzen und Build-System, Frontend-Architektur und Design-System-Integration, Datenpipelines und Integrationspunkte, KI-Komponenten dort, wo sie hingehören, Governance und Dokumentation. Ich schreibe den Code, nicht nur die Empfehlungen. Bis zur Mitte des Projekts reviewt Ihr Team meine Pull Requests mit derselben Sicherheit, die es für jeden anderen Teil der Codebase mitbringt.
Meine Zeit fliesst in die Arbeit, die den Unterschied macht: Code, Architekturentscheidungen und direkte Zusammenarbeit mit Engineers, Designern und Produkt. Weniger Meetings, mehr Zeit für das System, das skalieren muss.
Übergeben (Letzte 2 Wochen)
Ich plane meinen Ausstieg ab Tag null. In der Abschlussphase verlagere ich mich vom Tun zum Lehren. Entscheidungen dokumentieren, eng mit der Person zusammenarbeiten, die die Architektur nach mir übernimmt, und sicherstellen, dass die von mir etablierten Muster verstanden werden, nicht nur implementiert.
Der Test ist einfach: Kann das Team ohne mich in derselben Qualität weiterarbeiten? Wenn ja, war der Auftrag erfolgreich. Wenn nicht, habe ich meinen Job nicht getan.
Was Sie erhalten
- Eine ehrliche Diagnose, die Ursachen benennt, auch wenn das nicht das ist, was Sie erwartet haben
- Architektonische Klarheit: Modulgrenzen, Zuständigkeitsmodell, Design-System-Integration, Build-System und der Arbeitsmodus, der von 10 auf 100 Entwickler trägt. Dokumentiert, nicht nur vermerkt.
- Entscheidungen, die auf 15+ Jahren Erfahrung in Automotive, Telekommunikation, Fertigung, Smart Energy und KI-gestützten Produkten beruhen
- Eine einzige technische Stimme, an der sich Designer, Engineers, Produkt und Operations gleichermassen ausrichten können
- Muster und Prozesse, die über den Auftrag hinaus Bestand haben
- Ein Team, das danach eigenständig weiterarbeiten kann, ohne auf mich angewiesen zu sein
- Wissen, das bleibt: Ich schule die Menschen, mit denen ich arbeite, damit sie die Architektur wirklich verstehen und nicht nur erben
- Ein sauberer Ausstieg ohne Abhängigkeit von mir
Was ich nicht tue
- Slide-Decks und Lenkungsausschüsse
- Personalerweiterung ohne Architekturverantwortung
- Offene Mandate ohne Übergabeplan
- Technologieempfehlungen ohne Implementierung
- Aufträge, bei denen ich keinen Code schreiben kann
Typischer Arbeitsrhythmus
| Rhythmus | Was das bedeutet |
|---|---|
| Täglich | Standup mit dem Team. Code-Review. Hands-on-Arbeit. |
| Wöchentlich | Architektur-Session, Entscheidungen als ADRs dokumentiert. Fortschrittsgespräch mit dem Auftraggeber. |
| Zweiwöchentlich | Breiteres Update mit der Führungsebene bei Bedarf. Ehrliche Einschätzung, wo wir stehen versus wo wir sein müssen. |
| Zum Projektabschluss | Schriftliches Übergabedokument. Wissenstransfer-Sessions. Klare Zuständigkeitszuordnung. |
Zusammenarbeitsprinzipien
Ich habe Meinungen. Ich lasse mich gerne vom Gegenteil überzeugen.
Ich sage Ihnen, was ich für die richtige Entscheidung halte und warum. Wenn Sie ein besseres Argument haben, möchte ich es hören. Was ich nicht tue, ist absichern. "Es kommt drauf an" ist nur nützlich, wenn ich erkläre, worauf es ankommt.
Ich denke immer zuerst ans Team, das nach mir da ist.
Jede Entscheidung wird mit der Frage getroffen: "Wird das noch Sinn machen, wenn ich weg bin?" Wenn ein Muster meine Anwesenheit erfordert, um zu funktionieren, ist es das falsche Muster.
Ich bin direkt bei Problemen.
Wenn etwas nicht funktioniert, sage ich, dass es nicht funktioniert. Wenn eine Entscheidung falsch war, sage ich das auch, einschliesslich meiner eigenen. Höfliche Meinungsverschiedenheit ist in Ordnung. Schweigen, wenn etwas schiefläuft, ist es nicht.
Ich behandle neue Technologie als Infrastruktur, nicht als Magie.
Jede neue Technologie, ob KI-Modell, Plattform-Framework oder Build-Tool, wird wie jede andere externe Abhängigkeit behandelt: Sie hat Ausfallmodi, sie braucht Monitoring, und sie wird Sie im schlechtesten Moment überraschen. Meine Aufgabe ist es, Systeme zu entwerfen, in denen diese Überraschung überlebbar ist. Das erfordert dieselbe Strenge, die Sie auf ein Datenbankschema anwenden würden, nicht denselben Optimismus, den Sie einem neuen Tool entgegenbringen würden.
Arbeitsstil
Pragmatisch, nicht dogmatisch
Mir liegt, was in Ihrem Kontext funktioniert, nicht was gerade trendy ist. Wenn eine "langweilige" Technologie die richtige Wahl ist, werde ich das empfehlen.
Zusammenarbeit als Grundhaltung
Ich stelle viele Fragen. Ich gehe davon aus, dass Ihr Team Dinge weiss, die ich nicht weiss. Die besten Lösungen entstehen aus der Kombination dessen, was ich schon gesehen habe, mit dem, was Sie über Ihr Unternehmen wissen.
Direkt bei Problemen
Ich sage Ihnen, wenn etwas nicht stimmt, aber mir geht es nicht darum, recht zu haben. Mir geht es darum, die Sache richtig zu machen.
Häufige Fragen
Wie sieht die Diagnostik aus?
Die Diagnostik dauert zwei Tage. Ich lese den Code, spreche mit Engineers, Designern, Produkt und Business Leads, erfasse die Workflows und identifiziere, was Skalierung tatsächlich verlangt. Sie erhalten drei Ergebnisse: eine priorisierte Sicht auf die Reibungspunkte, die Skalierung blockieren, eine Empfehlung, was zuerst zu fixen ist und warum, und eine ehrliche Einschätzung, ob ich der richtige Partner für den Auftrag bin.
Wie integrieren Sie sich in ein bestehendes Team?
Ich trete als arbeitendes Mitglied bei. Tägliche Standups, Pull-Request-Reviews, Architektur-Sessions, Pair-Programming, wenn es sinnvoll ist. Ich treffe Entscheidungen mit Skin-in-the-Game, nicht von der Seitenlinie. Das funktioniert in der Regel reibungslos. Typischerweise fühlt sich die Zusammenarbeit bereits innerhalb der ersten Woche natürlich an.
Was passiert nach Ihrem Weggang?
Die Übergabe wird ab Tag null geplant. Ich dokumentiere Entscheidungen, arbeite eng mit der Person zusammen, die die Architektur nach mir übernimmt, und stelle sicher, dass die von mir etablierten Muster verstanden werden, nicht nur implementiert. Der Test ist einfach: Kann das Team ohne mich mit derselben Geschwindigkeit weiterarbeiten?
Was wenn wir Sie länger brauchen?
Verlängerungen gibt es, wenn der Umfang es wirklich erfordert. Aber ich werde ehrlich sagen, ob eine Verlängerung ein echtes Problem löst oder eine Abhängigkeit schafft. Das Ziel ist immer ein selbsttragendes Team, kein dauerhafter Berater.
Sind Sie ein KI-Spezialist?
Nein. Ich bin Product Architect. KI ist eine der Technologien, mit denen ich arbeite, und sie taucht heute in den meisten Aufträgen auf, ist aber selten die Überschrift. Die Arbeit ist die Skalierung von Produkt, Team und System gemeinsam. KI ist eine Entscheidung darin, nicht der Grund für den Auftrag.
Auftragsformate
Architektur-Triage
Code lesen, mit Produkt, Design, Engineering und Operations sprechen, die Reibungspunkte erfassen, die Skalierung blockieren werden. Drei Ergebnisse, mit denen Sie arbeiten können, mit oder ohne mich.
Validierungs-Sprint
Fokussierte Arbeit an der wichtigsten Architekturentscheidung: ein Proof of Concept, ein technischer Spike oder ein Slice produktionsreifen Codes, der zeigt, dass die neue Form des Systems trägt.
Embedded Delivery
Integration in Ihr Team. Architekturentscheidungen, Code, Design-System-Integration, Build-System, Datenpipelines, KI-Komponenten dort, wo sie hingehören, Governance. Für den Weg vom validierten Konzept in die Produktion.
Übergabe und Ausstieg
Dokumentation, Wissenstransfer, klare Zuständigkeiten. Vom ersten Gespräch an geplant. Das Ziel ist ein Team, das eigenständig weiterarbeitet.
Die meisten Aufträge beginnen mit der Architektur-Triage. Umfang und Konditionen werden je Auftrag vereinbart.
Interesse geweckt?
Der erste Schritt ist ein Gespräch. Normalerweise 30 Minuten, keine Vorbereitung Ihrerseits erforderlich. Schildern Sie mir Ihre Situation, und ich sage Ihnen, ob ich helfen kann.