Wie hilfst du technischen und nicht-technischen Teams, einander besser zu verstehen?

Question

Accepted Answer

Das Kernproblem ist nicht Intelligenz, es sind **unterschiedliche Vokabulare und unterschiedliche Ziele**. Entwickler denken in Systemen, Constraints und Edge Cases; Sales, Marketing und Support denken in Kunden, Deals und Ergebnissen. Meine Aufgabe als Tech Lead ist es, ein Übersetzer zu sein und Gewohnheiten aufzubauen, die den Übersetzungsbedarf mit der Zeit reduzieren.

## Was ich in der Praxis tue

- **Jargon in beide Richtungen übersetzen.** Ich verbanne Akronyme in funktionsübergreifenden Meetings und formuliere technische Konzepte als Business-Wirkung um: nicht „die Queue ist verstopft", sondern „Bestellungen brauchen 10 Minuten zur Bestätigung, deshalb bekommt Support Beschwerden".
- **An gemeinsamen Artefakten verankern.** Demos schlagen Dokumente. Ein funktionierender Prototyp, ein Dashboard oder ein Customer-Journey-Diagramm gibt beiden Seiten dasselbe konkrete Ding, auf das sie zeigen können.
- **Empathie durch Exposition aufbauen.** Ich lasse Entwickler gelegentlich bei einem Sales-Call oder einer Support-Schicht zuhören. Einen echten Kunden kämpfen zu hören bewirkt mehr als jede Spezifikation. Umgekehrt lade ich nicht-technische Leute zu einem vereinfachten Architektur-Walkthrough ein.
- **Analogien verwenden, nicht Abstraktionen.** Eine Migration mit „ein Haus renovieren, während Menschen noch darin wohnen" zu vergleichen, kommt bei einem nicht-technischen Publikum sofort an.
- **Eine einzige Source of Truth für den Status schaffen.** Eine gemeinsame Roadmap oder ein Status-Board in klarer Sprache verhindert das Stille-Post-Spiel, das Misstrauen nährt.

## Ein wiederholbares Framework

1. **Höre** auf die echte Sorge hinter der Anfrage („kannst du einen Button hinzufügen?" bedeutet oft „ein Kunde ist blockiert").
2. **Formuliere** sie in der Sprache der anderen Seite um.
3. **Bestätige** das Verständnis, indem du es zurückspielst.
4. **Dokumentiere** die gemeinsame Entscheidung, damit sie das Meeting überlebt.

## Fallstricke, die es zu vermeiden gilt

- **Herablassung.** Nicht-technisch bedeutet nicht unintelligent; Über-Vereinfachung beleidigt Menschen.
- **Sich hinter Komplexität verstecken**, um ein Nein zu vermeiden. „Es ist kompliziert" ist keine Antwort.
- **Einseitige Übersetzung.** Auch Entwickler müssen den Geschäftskontext verstehen, nicht nur davor abgeschirmt werden.

## Warum es wichtig ist

Die meiste organisatorische Reibung ist ein Kommunikationsversagen, kein Kompetenzversagen. Wenn technische und nicht-technische Teams einander wirklich verstehen, werden Entscheidungen schneller, Erwartungen realistischer, und Vertrauen ersetzt die Wir-gegen-die-Dynamik, die still alles verlangsamt.