Meine Arbeitsweise
Ich bin kein Berater, der PDFs schickt. Ich trete Ihrem Team bei, schreibe Code, überprüfe Pull Requests, entwerfe KI-Pipelines und treffe Architekturentscheidungen mit echtem Verantwortungsbewusstsein. Das schliesst die Entscheidungen ein, die Ihr Compliance-Team unterzeichnen muss, und die, mit denen Ihre Ingenieure um 3 Uhr nachts leben müssen, wenn etwas driftet. Die Zusammenarbeit ist bewusst befristet. So sieht es aus.
Das Auftragsmodell
Diagnose (Woche 1)
Bevor ich mich zu irgendetwas verpflichte, muss ich verstehen, was tatsächlich passiert. Die erste Woche verbringe ich damit, Code zu lesen, mit Stakeholdern (Engineers, Designer, Product Owner, CxOs) zu sprechen, die Delivery-Pipeline zu erfassen und die eigentlichen Engpässe zu identifizieren. Ursachen unterscheiden sich oft von der anfänglichen Einschätzung. Deshalb ist die Diagnose-Woche wichtig.
Am Ende der Woche erhalten Sie eine ehrliche Bewertung: was ich gefunden habe, was ich empfehle und ob ich der richtige Partner für diesen Auftrag bin. Manchmal ist die Antwort nein, und das sage ich Ihnen im Voraus.
Umsetzung (4 Wochen bis 2 Jahre)
Ich trete Ihrem Team 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.
Bei KI-Architekturprojekten umfasst diese Phase die Modellauswahl und -bewertung, den Entwurf und die Implementierung von Datenpipelines, den Aufbau eines Governance-Frameworks und die Dokumentation unter Berücksichtigung der Anforderungen des EU AI Act. Ich schreibe den Code, nicht nur die Empfehlungen. Bis zur Mitte des Projekts prüft Ihr Team KI-bezogene Pull Requests mit derselben Sicherheit, die es für jeden anderen Teil der Codebasis mitbringt.
Meine Zeit fliesst in die Arbeit, die den Unterschied macht: Code, Architekturentscheidungen und direkte Zusammenarbeit mit Ingenieuren. Weniger Zeit in Meetings, mehr Zeit beim Ausliefern.
Die Projektdauer hängt vom Umfang ab. Manche Aufträge laufen einige Monate, andere erstrecken sich auf ein Jahr oder mehr, wenn das Problem wirklich komplex ist. Mein längster Auftrag hat drei Jahre gedauert. Den wahrscheinlichen Zeitrahmen kennen wir am Ende der Diagnose.
Ausstieg (Letzte 2 Wochen)
Die Übergabe wird von Anfang an geplant. 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 mit derselben Geschwindigkeit 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
- Klarheit über die KI-Architektur: welche Modelle und warum, wie Ihre Datenpipeline strukturiert ist, wo die Governance-Kontrollpunkte liegen und wo EU AI Act-Anforderungen wahrscheinlich greifen. Dokumentiert, nicht nur vermerkt.
- Architekturentscheidungen, die auf 15+ Jahren Erfahrung beruhen: was im grossen Massstab funktioniert und was scheitert
- 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 AI als Infrastruktur, nicht als Magie.
Behandeln Sie ein Modell wie jede andere externe Abhängigkeit: Es hat Ausfallmodi, es braucht Monitoring, und es 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 Framework 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 erste Woche aus?
Die erste Woche ist eine Diagnose. Ich lese den Code, spreche mit Ingenieuren, erfasse die Delivery-Pipeline und identifiziere die eigentlichen Engpässe. Am Ende der Woche erhalten Sie eine ehrliche Einschätzung: was ich gefunden habe, was ich empfehle und ob ich der richtige Partner für diesen 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 echtem Verantwortungsbewusstsein, 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 von Anfang an 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.
Auftragsformate
Diagnose
Eine schriftliche Bewertung, wo Sie stehen, was nicht funktioniert und was als nächstes passieren muss. Jeder Auftrag beginnt hier.
Einbettung ins Team
Integration in Ihr Engineering-Team. Architekturentscheidungen, Code, KI-Pipeline-Design. Für Teams mit einem klar definierten Problem und einem klaren Umfang.
Strategischer Aufbau
Vollständige Architektur und Umsetzung eines produktionsreifen KI-Systems. Vom ersten Use Case bis zum geplanten Ausstieg, mit Governance von Anfang an.
Alle Aufträge beginnen mit der bezahlten Diagnosewoche. Tagessätze werden im ersten Gespräch besprochen.
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.