Vor Kurzem haben wir für einen Kunden ein neues Frontend gelauncht. Der Go-Live lief durch, alles sah auf den ersten Blick gut aus – bis jemand aus dem Team ein ungewöhnliches technisches Problem entdeckt hat. Es war nicht offensichtlich. Du musstest in die Daten schauen, um es zu sehen. Das eigentlich Auffällige war aber nicht der Bug, sondern dass sich niemand dafür verantwortlich fühlte. Die Person, die den Großteil der Arbeit an diesem Projekt gemacht hatte, hatte das Thema nicht aufgenommen. Und als wir nachgefragt haben, wurde klar: Er wusste gar nicht, dass das von ihm erwartet wurde. Er dachte, er wäre „nur“ Entwickler. Wir anderen hatten ihn die ganze Zeit wie den technischen Lead behandelt.
Dieser Moment war der Auslöser für einen längst überfälligen internen Shift. Er hat uns gezwungen, einen blinden Fleck in unserer Verantwortungsverteilung anzuschauen. Und er gehört zu den wichtigsten kulturellen Verbesserungen, die wir seit Langem gemacht haben.
Eigentlich war es niemandes Fehler. Das Projekt lief gut, die Kommunikation war okay, und das Problem hatte keinen direkten Impact auf den Kunden. Aber es hat etwas Entscheidendes sichtbar gemacht: Wir hatten Verantwortlichkeiten nie wirklich klar ausgesprochen.
Weil diese Person den Großteil der Implementierung übernommen hatte, sind wir automatisch davon ausgegangen, dass er sich selbst als technischen Lead sieht. Aber wir hatten das nie explizit gesagt. Es gab keine klar zugewiesene Rolle. Kein gemeinsames Verständnis von Ownership.
Und in einem wachsenden Team ist das eine gefährliche Art zu arbeiten.
Unser erster Reflex war: Lass uns Checklisten bauen. Vielleicht brauchen wir einfach ein Framework, damit jede Checkbox abgehakt wird.
Aber je mehr wir darüber gesprochen haben, desto klarer wurde: Checklisten können zur Krücke werden. Sie fördern Abhaken – aber keine Verantwortung. Menschen erledigen Aufgaben, um sie „fertig“ zu haben, statt einen Schritt zurückzutreten, kritisch nachzudenken oder bessere Fragen zu stellen.
Was wir brauchten, war nicht mehr Prozess. Es war Klarheit. Und Selbstvertrauen.
Wir wollten, dass Leute ihre Rolle wirklich verstehen. Dass sie sich ermächtigt fühlen, Verantwortung zu übernehmen. Und dass sie sich trauen, den Mund aufzumachen, wenn etwas komisch aussieht – auch dann, wenn es nicht explizit auf einer Liste steht.
Wir haben eine bewusste Entscheidung getroffen: Ab jetzt hat jedes Projekt eine:n klar benannte:n Technical Lead. Und diese Person versteht, was diese Rolle bedeutet.
Du bist für die Qualität verantwortlich. Du bist für die technische Gesundheit des Projekts verantwortlich. Und das bedeutet: Du triffst Entscheidungen – du führst nicht nur Tickets aus.
Es bedeutet auch, dass du das Recht hast, zu widersprechen. Wenn ein Kunde etwas Unvernünftiges möchte – zum Beispiel einen 120-Megabyte-animierten Splashscreen –, dann ist es dein Job zu sagen: „Das ist keine gute Idee, und hier ist der Grund.“
Du setzt die Vision des Kunden immer noch um – aber nicht ohne Input. Dein Job ist es, dich zu kümmern. Zu führen. Und die langfristige Qualität der Arbeit zu schützen.
In unseren internen Runden haben wir viel über das Wort „Nein“ gesprochen. Nicht alle fanden das angenehm. Manche fanden es zu hart. Aber mein Ziel war nicht, dem Team beizubringen, wie man Kunden abblockt. Ich wollte zeigen, dass sie die Erlaubnis haben, Ideen zu challengen – und die Verantwortung, sich zu melden, wenn sich etwas falsch anfühlt.
Das klingt simpel, ist es aber nicht.
Einer unserer Entwickler kam nach dem Meeting auf mich zu, weil er einen Konflikt im Kalender hatte. Er stand zwischen zwei überlappenden Projektanforderungen. Also habe ich ihn gefragt: „Nach allem, was wir gerade besprochen haben – was glaubst du, solltest du tun?“
Ich habe gemerkt, dass er noch nicht ganz sicher war. Er hat die Logik verstanden, aber war es nicht gewohnt, in diese Führungsrolle zu gehen. Also habe ich ihm gesagt: „Das ist der Stuhl. Du darfst dich jetzt reinsetzen. Du hast dir diese Verantwortung verdient.“
Uns ist auch klar geworden, dass wir unsere Teammitglieder anders sehen müssen. Nicht als Ressourcen. Als Menschen.
Das klingt selbstverständlich, aber in einer schnelllebigen Tech-Agentur gerät das leicht in den Hintergrund. Menschen werden reduziert auf ihre Rolle, ihre Ticket-Queue, ihre Velocity. Aber hinter der Tastatur sitzt ein Mensch – mit Gedanken, Frust, Ideen.
Nur weil eine Entscheidung auf dem Papier Sinn ergibt, heißt das nicht, dass alle sie gleich verstehen. Gute Führung bedeutet, das „Warum“ zu erklären – nicht nur das „Was“ zuzuweisen.
Du musst Menschen mitnehmen. Und dafür ist emotionale Intelligenz ein Muss.
Parallel dazu haben wir klar gemacht: Jede technische Lead-Rolle bekommt eine:n strategische:n Partner:in an die Seite. Jemand, der:die auf einer höheren Ebene die Kundenkommunikation hält, Blocker aus dem Weg räumt und Kontext liefert.
Diese zusätzliche Ebene macht einen riesigen Unterschied. Sie gibt Technical Leads das Gefühl, nicht allein zu sein. Sie gibt ihnen eine Anlaufstelle, wenn die Aufgabenliste überhand nimmt. Und sie hilft, das Gleichgewicht zwischen technischer Integrität und Kundenwünschen zu halten.
Seit wir diese Änderungen eingeführt haben, sehen wir deutliche Effekte.
Teammitglieder sind näher dran an ihren Projekten. Die Kommunikation ist besser geworden. Und das Selbstvertrauen ist spürbar gewachsen.
Die Leute verstehen: Es ist nicht nur okay, etwas anzusprechen – es wird erwartet. Und sie wissen, dass sie Unterstützung bekommen, wenn sie sich in solchen Gesprächen unsicher fühlen.
Noch wichtiger: Die Qualität unserer Projekte steigt. Es gibt mehr proaktive Planung. Mehr Ownership. Weniger vermeidbare Themen, die irgendwo durchrutschen.
Für unsere Kund:innen bedeutet dieser kulturelle Shift bessere Ergebnisse. Ihre Projekte werden mit mehr Sorgfalt und technischer Weitsicht geführt. Potenzielle Probleme werden früher erkannt. Lösungen werden hinterfragt und geschärft, bevor sie zu echten Risiken werden.
Gleichzeitig entstehen stärkere Beziehungen. Wenn unser Team selbstbewusst auftritt, wird auch unsere Kommunikation mit Kund:innen offener, transparenter und strategischer.
Dieses Vertrauen baut bessere Software.
Mach Dinge explizit. Geh nie davon aus, dass jemand seine Rolle kennt, wenn du sie nicht klar benannt hast.
Erwartungsmanagement ist eine der meist unterschätzten Fähigkeiten in Unternehmen. Gerade in kleinen Teams, in denen Jobtitel verschwimmen und alle mehrere Hüte tragen, ist es extrem leicht anzunehmen, dass schon jede:r weiß, was erwartet wird. Aber das ist selten der Fall.
Klarheit schafft Selbstvertrauen. Und Selbstvertrauen schafft bessere Arbeit.
Du brauchst keine riesigen Task-Listen oder starre Checkbox-Prozesse. Du brauchst klare Verantwortlichkeiten, emotionale Intelligenz und eine Kultur, in der Menschen ermutigt werden, ihre Stimme zu erheben.
Wir haben das in der Vergangenheit nicht immer gut gemacht. Aber wir arbeiten jetzt aktiv daran. Und der Effekt ist deutlich – für unser Team und für unsere Kund:innen.
Image from John Lockwood on Unsplash
Starke Teams funktionieren nicht auf Basis von Annahmen. Erzähl mir, wie ihr Ownership verteilt – oder lass uns eure technischen Rollen schärfen, damit Probleme gelöst werden, bevor sie eskalieren.
