Von Reibung zu Flow - SmashingConf

Ich besuche die SmashingConf Freiburg als Mitarbeiter von Pax – vielen Dank an Pax für diese Möglichkeit. Ich habe mir Notizen zu den Talks gemacht und teile hier die Gedanken, die sie ausgelöst haben. Dies ist eine persönliche Konferenznotiz, kein Transkript und keine Aussage von Pax.

Dies ist ein weiterer Beitrag in einer Reihe von Notizen zur SmashingConf Freiburg. Die Konferenz 2026 findet vom 7. bis 10. September in Freiburg statt. Hier ist das offizielle Programm.

Joe Natolis Talk, Friction to Flow, beschrieb ein bekanntes Problem in der Produktentwicklung: Entwickler:innen haben oft das Gefühl, dass das Management sie nicht versteht. Umgekehrt fühlt sich auch das Management von Entwickler:innen nicht verstanden. Mit Design, Produktmanagement und Führung kommen mehrere Blickwinkel auf dasselbe Produkt zusammen – jeder mit eigenen Anliegen, eigener Sprache und eigenem Druck.

Das heisst nicht, dass eine Seite recht hat und die anderen nicht. Nach Joes Einordnung sind die unterschiedlichen Blickwinkel alle gültig. Die Aufgabe ist, sie zusammenzubringen, bevor daraus teure Überraschungen am Ende des Prozesses werden.

Reibung schützt meist etwas

Reibung geht in jedem Team auf und ab. Sie wird leichter handhabbar, wenn wir fragen, was jemand gerade schützen möchte.

Eine Entwicklerin, die sagt: «Das erzeugt technische Schulden», möchte vielleicht Code-Qualität, Architektur oder die Fähigkeit des Teams schützen, das Produkt später noch verändern zu können. Ein Produktmanager unter Druck aus mehreren Richtungen schützt vielleicht eine Zusage, ein Kundenbedürfnis oder überhaupt den Raum, eine Entscheidung treffen zu können. Produktmanager:innen sind oft in der schwierigsten Position: Sie sitzen in der Mitte und bekommen von allen Seiten Druck.

Darum kann Dissens persönlich wirken. Wenn Menschen ein Produkt sehr wichtig nehmen, senden sie durch ihre Formulierungen Signale. Diese Signale sind real, aber sie sind nicht unbedingt das ganze Argument.

Der hilfreiche Schritt ist, keine Seiten mehr zu wählen. Ein Konflikt ist selten schwarz oder weiss, und meist gibt es eine Lösung, die jede Person akzeptieren kann – selbst wenn sie nicht die bevorzugte Lösung ist.

Für das Produkt argumentieren, nicht für die Fachdisziplin

Ein Punkt aus dem Talk ist mir besonders geblieben: Ein Argument sollte nicht allein die eigene Fachdisziplin verteidigen. Statt zu sagen: «Das schadet der Architektur», sollten wir die Produkt- und Geschäftsauswirkung erklären: «Das könnte jetzt funktionieren, aber in drei Monaten negative Folgen für unser Geschäft haben.»

Es geht nicht darum, einen technischen Einwand in geschäftliche Sprache zu verpacken. Es geht darum, die zusätzliche Arbeit zu leisten und Ursache und Wirkung zu verbinden. Wenn eine Entscheidung einen späteren Release langsamer, fragiler oder teurer macht, ist das ein Produktanliegen. Menschen ausserhalb der Entwicklung können darüber mitentscheiden, wenn wir es in diesen Begriffen erklären.

Das gilt auch umgekehrt. Ein Liefertermin, eine Marktchance oder eine Kundenzusage sollten nicht als Druck behandelt werden, den die Entwicklung einfach aufnehmen muss. Sie sind Informationen über das Ergebnis, das das Produkt erreichen soll. Das Team kann den Trade-off dann gemeinsam beurteilen.

Dissens weiter vorne im Prozess ansprechen

Joe nannte das, upstream zu gehen: Reibung an einen früheren Zeitpunkt im Prozess zu bringen, an dem eine Frage die Entscheidung noch verändern kann. Alle Teams sind sich manchmal uneinig. Die wichtigere Frage ist, wann im Prozess sie sich uneinig sind.

Späte Reibung – am Releasetag oder danach – kostet mehr, weil dann weniger gute Optionen bleiben. Meist ist es besser, die unbequeme Frage früh anzusprechen, so bald wie möglich eine Vereinbarung zu finden und Zeit zur Anpassung zu lassen.

Das heisst nicht, jeden Dissens beseitigen zu wollen. «So lange uneinig sein, wie es nützlich ist» ist ein viel besseres Ziel. Produktteams brauchen genug Spannung, um Risiken und Alternativen zu entdecken. Sie brauchen keine Spannung, die still mitgetragen wird, bis nur noch Verzögerung, Nacharbeit oder Schuldzuweisungen übrig sind.

Mein Fazit: die Arbeit rund um die eigene kennenlernen

Für mich beschreibt der Talk ein sehr gültiges und oft erlebtes Phänomen. Alle Menschen in der Produktentwicklung sollten ernsthaft versuchen, die Arbeit und die Einschränkungen der anderen zu verstehen.

Aus meiner Entwicklerperspektive beginnt das mit einer unbequemen Frage: Womit verdient das Unternehmen eigentlich Geld? Selbst innerhalb eines Unternehmens lässt sich das manchmal erstaunlich schwer klar beantworten. Aber es verändert den Blick auf ein Backlog-Item oder eine technische Entscheidung, wenn wir die Kund:innen, die Dienstleistung und das damit verbundene Geschäftsergebnis verstehen.

Es hilft auch, mit Menschen ausserhalb des eigenen technischen Kreises zu sprechen. Job Shadowing, Pairing über Rollen hinweg oder zeitweises Job Sharing können Einschränkungen sichtbar machen, die weder ein Ticket noch ein Meeting offenlegt. Bei Pax habe ich erlebt, wie gut das funktionieren kann: Menschen nehmen sich Zeit, die Arbeit anderer Beteiligter zu verstehen, bevor sie entscheiden, was diese Person anders machen sollte.

Der Fokus sollte auf dem Produkt bleiben, nicht auf den Schwierigkeiten auf dem Weg dorthin. Bei jeder Iteration können Designer:innen, Entwickler:innen, Produktmanager:innen und Führungskräfte fragen: Wie sieht das aus der Perspektive der Kund:innen aus? Kund:innen entscheiden sich letztlich für das Produkt und finanzieren es damit. Dieser gemeinsame Bezugspunkt hilft einem Team, wenn die internen Blickwinkel auseinanderziehen.

Bei App-Produkten gehört das zu dem, was uns in einer guten App-Entwicklungspartnerschaft wichtig ist: nicht nur das nächste Feature zu bauen, sondern Teams zu helfen, gemeinsam tragfähige Entscheidungen zu treffen. Wenn du diese Trade-offs gerade im eigenen Produkt navigierst, melde dich.