Wie wir Projekte bei lennlay führen
Drei Leute, Enterprise-Kunden, regulierte Umgebungen. Wie Projektführung aussieht, wenn es keinen Spielraum für Overhead gibt.
Wir sind drei Personen. Unsere Kunden sind Volkswagen Financial Services, KfW, Baloise, Deutsche Post. Zwischen diesen beiden Tatsachen liegt eine Spannung, die jeder kennt, der versucht hat, Enterprise-Projekte mit einem kleinen Team zu führen.
Die übliche Lösung für diese Spannung ist Prozess: Statusberichte, Projektmanagement-Tools, Eskalationshierarchien, Dokumentationsstandards. Alles mit der Begründung, dass Struktur Sicherheit gibt - für den Kunden und für das Team.
Das Problem mit dieser Lösung ist, dass Overhead in einem kleinen Team nicht abstrakt ist. Overhead ist Zeit, die nicht für das eigentliche Problem aufgewendet wird. Und in regulierten IT-Umgebungen, wo Deployments, Compliance-Nachweise und Konfigurationsänderungen echte Auswirkungen haben, ist das ein Risiko, das wir nicht eingehen wollen.
Deswegen haben wir eine andere Antwort auf diese Spannung entwickelt.
Die Person, die den Code schreibt, spricht mit dem Stakeholder
Das ist die wichtigste Entscheidung in unserem Modell. Es gibt keine Account-Manager, die zwischen Kundenanforderungen und technischer Umsetzung übersetzen. Die Person, die ein Playbook entwickelt, ist dieselbe Person, die in der wöchentlichen Abstimmung mit dem Kunden erklärt, was das Playbook tut - und warum es so und nicht anders gebaut ist.
Das hat praktische Konsequenzen. Anforderungen, die in einer technischen Umsetzung nicht sinnvoll sind, werden sofort sichtbar - nicht nach drei Iterationen durch verschiedene Kommunikationsebenen. Rückfragen beim Kunden landen direkt bei der Person, die die Frage stellen kann. Fehlgelaufene Annahmen werden in der ersten Projektwoche erkannt, nicht am Ende.
Das setzt voraus, dass das Team kommunikationsstark ist - nicht nur technisch kompetent. Beides zusammen ist schwerer zu finden. Aber es ist der Kern dessen, was wir bei Einstellungen suchen.
Wöchentliche Synchronisierung, alles andere asynchron
Mit jedem Kunden gibt es einen festen wöchentlichen Synchronisierungstermin. Der Slot ist kurz - in der Regel 30 bis 45 Minuten. Der Inhalt ist konkret: was wurde seit letzter Woche geliefert, was kommt diese Woche, was steht im Weg.
Alles, was über diesen Termin hinaus kommuniziert werden muss, läuft asynchron. Das bedeutet: schriftlich, strukturiert, so formuliert, dass es ohne Nachfragen verständlich ist. Keine offenen Chat-Nachrichten, die eine sofortige Reaktion verlangen und dann nirgendwo dokumentiert sind.
Intern gilt dasselbe. lennlay ist remote-first. Das Team ist über verschiedene Standorte verteilt. Die Kommunikation läuft nicht über kontinuierliche Verfügbarkeit, sondern über klare, dokumentierte Zwischenstände. Wer eine Entscheidung braucht, formuliert das Problem, die Optionen und seine Empfehlung schriftlich. Antworten kommen zeitnah, aber nicht in Echtzeit.
Das hat einen Nebeneffekt, den wir schätzen: Es zwingt zur Klarheit. Wer ein Problem schriftlich beschreibt, hat es meistens schon zur Hälfte gelöst.
Git ist das Protokoll, nicht Confluence
Wir dokumentieren in Git. Konfigurationen, Playbooks, Deployment-Logik, Variablenstruktur: alles versioniert, alles mit Commit-Nachricht, alles mit nachvollziehbarer Historie.
Das ist keine ideologische Entscheidung, sondern eine praktische. In regulierten Umgebungen ist Auditierbarkeit keine optionale Eigenschaft. Wer nach einem Incident erklären muss, welche Konfiguration wann auf welchem System aktiv war, braucht eine zuverlässige Quelle. Ein Git-Repository mit sauberer Commit-Historie ist eine solche Quelle. Ein Confluence-Wiki mit zehn veralteten Seiten und einer neueren Seite, die keiner gepflegt hat, ist es nicht.
Dokumentation, die nicht in Git lebt - also Beschreibungen, Entscheidungsgrundlagen, Architekturskizzen - geht in Repository-eigene Markdown-Dateien oder strukturierte README-Dateien. Der Aufwand, ein externes Wiki zu pflegen, entsteht damit nicht. Und die Dokumentation ist immer nah an dem, was sie beschreibt.
Deliverables statt Statusberichte
Was wir Kunden liefern, ist das Ergebnis - nicht eine Beschreibung des Wegs dorthin. Das klingt selbstverständlich, ist es aber in der Praxis nicht immer.
In Projekten mit langen Laufzeiten gibt es einen Druck, Fortschritt durch Berichte sichtbar zu machen. Das ist verständlich. Aber ein wöchentlicher Statusbericht, der aus drei PowerPoint-Folien besteht, ist kein Fortschritt. Er ist Fortschritts-Simulation.
Wir zeigen Fortschritt durch ausführbare Ergebnisse: ein Playbook, das in einer Testumgebung läuft; ein Compliance-Report, der greifbare Zahlen enthält; eine Konfigurationsänderung, die live gegangen ist und deren Auswirkung messbar ist. Wenn in einer bestimmten Projektwoche kein ausführbares Ergebnis da ist, sagen wir das im Synchronisierungstermin - mit dem Grund und dem Lieferdatum.
Was dieses Modell voraussetzt
Diese Art zu arbeiten funktioniert nicht in jedem Kontext. Es setzt voraus, dass der Kunde Direktkommunikation schätzt - und bereit ist, Fragen direkt zu beantworten, statt sie durch mehrere Freigabe-Ebenen zu routen.
Es setzt voraus, dass das Team Eigenverantwortung trägt. Es gibt bei lennlay keine Person, die Arbeit verteilt und dann Ergebnisse einsammelt. Jeder im Team führt seinen Bereich eigenständig und kommuniziert Probleme früh.
Und es setzt voraus, dass alle Beteiligten verstehen, dass Qualität in diesem Modell durch Klarheit entsteht - nicht durch Volumen. Weniger Berichte, mehr Ergebnisse. Weniger Abstimmungsrunden, mehr direkte Kommunikation. Das ist der Kern, wie wir Projekte führen.