Warum Rollen keine Regeln sind

Ich kam 2016 als externer Mitarbeiter zu Figma in ein Team mit 12 Entwickler*innen. Damals war ich zugegebenermaßen skeptisch, ob wir ein kollaboratives, leistungsfähiges Tool in einem Webbrowser entwickeln könnten. Heute scheint das eine Ewigkeit her zu sein, aber damals waren die Schwerpunkte und die Begeisterung für Apps und mobile Geräte klar, und es gab eine Reihe bemerkenswerter Fehlversuche, Web-Erlebnisse zu schaffen, die ihren nativen Gegenstücken gerecht wurden. Was wir brauchten, war ein grundlegender Wandel, der technische und kulturelle Veränderungen antreiben und Figma möglich machen konnte. Mit der Einführung von Browser-APIs auf niedrigerer Ebene – zum Beispiel WebGL und Web Assembly – konnten wir die Möglichkeiten im Web neu konzipieren. Hinzu kam eine Generation, die mit Tools wie Google Docs aufgewachsen ist und mit der Hybrid- und Remote-Arbeit der letzten Jahre gelernt hat, den Wert synchroner Zusammenarbeit zu schätzen.

Heute wird erwartet, dass unsere Tools standardmäßig zunehmend multiplayerfähig sind. Und es sind nicht nur die Erwartungen an unsere Tools, die sich geändert haben, sondern auch die Art und Weise, wie wir miteinander umgehen und welche Erwartungen wir aneinander haben. In meiner Laufbahn von den ersten Tagen als Externer, der Code entwickelte, bis hin zur Leitung des Teams, habe ich viel darüber nachgedacht, was genau das für Entwickler*innen bedeutet. Wie entwickelt sich unsere Rolle, wenn die Produktentwicklung zunehmend nichtlinear wird? Wie sollte Zusammenarbeit für Entwickler*innen eigentlich aussehen? Und ist sie immer von Vorteil?

Es kommt leicht vor, dass man sich auf die Extreme versteift. Wenn eine enge Zusammenarbeit zu besseren Ergebnissen führt, warum dann nicht ständig Feedback einholen und iterieren? Im Allgemeinen bin ich zu dem Schluss gekommen, dass der Grat zwischen dem Rückgriff auf das Wissen anderer und dem Sich-im-Kreis-Drehen ohne klare eigene Richtung schmal ist. In der Praxis wird es Zeiten geben, in denen wir unabhängiger arbeiten müssen, und Zeiten, in denen wir uns bemühen sollten, andere mit einzubeziehen. Ich habe die Erfahrung gemacht, dass das ideale Gleichgewicht zwischen Abweichung und Konvergenz für jeden anders ist – abhängig von der Kultur, den entwickelten Produkten und den verfolgten Zielen. Damit du das richtige Gleichgewicht findest, möchte ich dir erzählen, wie wir über unseren eigenen Sweetspot bei der Zusammenarbeit in Technik und Produktentwicklung denken.

Die Produktentwicklung beginnt nicht länger mit dem Design und endet mit der Entwicklung. In vielen Unternehmen sind jedoch nach wie vor Produktmanager*innen und Designer*innen für die Festlegung der Roadmap verantwortlich, während Entwickler*innen diese Roadmap umsetzen. Das ist etwas, das Yuhki Yamashita, mein Kollege im Produktteam, und ich richtigstellen wollten. Wir arbeiten sehr eng zusammen, und das überträgt sich auf den Rest des Unternehmens. Die Entwickler*innen bestimmen nicht nur, wie etwas gemacht wird, sie legen auch fest, was gemacht wird, indem sie eng mit ihren funktionsübergreifend tätigen Kolleg*innen zusammenarbeiten und Kundenfeedback berücksichtigen.

Bei der Einführung neuer Workflows ermutigen wir die Teams immer, so früh wie möglich eine Reihe von Perspektiven einzubeziehen. So kann sich ein Konzeptdokument mit den Beiträgen des restlichen Produktentwicklungsteams entfalten. Von den Entwickler*innen erwarten wir, dass sie ihre ersten Überlegungen schriftlich festhalten. Ziel ist es, dass sie schon während ihrer Arbeit Feedback von Kolleg*innen erhalten, nicht erst, wenn alles bereits fertig zu sein scheint. Es gibt für praktisch jedes Projekt eine Art Dokument, um diese frühen Überlegungen festzuhalten. Die Herausforderung besteht darin, schnelles Feedback von den Teams zu erhalten, während sie an ihrem Teil arbeiten.

Deshalb halten wir in unseren Design- und Entwicklungsabteilungen regelmäßig „Engineering Crits“ ab. So erhalten wir immer zu einer bestimmten Zeit und an einem bestimmten Ort Feedback von anderen Teams. Der „Engineering Crit“ kommt dabei eine ganz besondere Rolle zu. Sie gibt uns die Möglichkeit, frühzeitig und häufig um Feedback zu bitten. Sie ist ein Forum, in dem dich Experten bei technischen Entwürfen unterstützen. Sie ist kein Genehmigungsprozess. In „Engineering Crits“ wird nichts entschieden oder beschlossen, und das ist auch so gewollt. Ziel ist es, ein Design so weit zu verbessern, dass es eigentlich nicht mehr genehmigt werden muss. Wir nutzen FigJam, um diese Meetings durchzuführen, sodass jede*r in Echtzeit daran teilnehmen kann​ – es macht sehr viel Spaß!

Die „Engineering Crit“ ist kein Genehmigungsverfahren, sondern eine Gelegenheit, frühzeitig und regelmäßig Feedback von anderen Teams zu erhalten. Wir ermutigen die Teilnehmer*innen, sich auf WIP-Arbeiten einzulassen und produktiv auf Probleme hinzuweisen, ohne gleich eine Entscheidung zu treffen. Das ist die Vorlage, die wir bei Figma verwenden.

Aber was passiert, wenn es zu viel Input oder widersprüchliches Feedback gibt? Ich habe schon erlebt, dass Projekte aus dem Ruder gelaufen sind, wenn das Verhältnis von generativen und explorativen Verfahren unausgewogen war. Gleichzeitig sollte es aber voran gehen. Besonders schwierig ist es, wenn harte Kompromisse notwendig werden und es viele Unklarheiten gibt, z. B. bei der Festlegung eines ersten Preismodells. Zu viele konkurrierende Perspektiven und neue Ideen können leicht zu einem Stillstand führen.

Deshalb teilen wir Projekte in Meilensteine auf. Das mag einfach klingen, aber die klare Definition und Kommunikation von Meilensteinen hilft uns, die Erwartungen anderer Beteiligter zu managen. Außerdem erinnert sie uns daran, wann es an der Zeit ist, im Interesse von Fortschritt und Dynamik zusammenzuarbeiten. Dynamik ist dabei besonders wichtig. Sie gibt uns das Gefühl, immer nur ein paar Schritte von unseren Zielen entfernt zu sein. Wenn wir sie verlieren, geraten wir ins Trudeln und stellen in Frage, was wir tun.

Meilensteine helfen uns bei Figma nicht nur, uns innerhalb der Teams anzunähern, sie ermöglichen es uns auch zu erkennen, wenn die Dinge teamübergreifend nicht nach Plan laufen. Indem wir Gefahren frühzeitig kommunizieren, können wir uns gegenseitig Fachwissen oder Ressourcen zur Verfügung stellen und die Dynamik wiederherstellen. Genau in einem solchen Fall ist mehr Input sinnvoll. Manchmal greife ich ein, wenn ich sehe, dass ein Projekt ins Stocken gerät. Wegen meiner Position reagieren die Mitarbeiter*innen immer noch überrascht, wenn ich mich intensiv mit bestimmten Bereichen befasse, aber es ist wichtig, dass wir uns gegenseitig helfen, Blockaden zu lösen, und dass sich keiner von uns zu weit von den Details entfernt, die uns auf dem Boden halten.

Im Grunde stelle ich mir unsere Arbeit bei Figma gerne als einen Baum von Abhängigkeiten vor. Die Blätter können sich schnell und mit geringem Risiko für den Rest des Baums ändern, aber die Wurzeln müssen solide sein. Bei Planung eines Projekts auf Wurzelebene sind die Überlegungen ganz anders als auf Blattebene. Wenn du eine Datenbank aufbaust, kannst du nicht einfach alleine loslegen und „schnell etwas kaputt machen“. Bei der Arbeit an Systemen auf niedriger Ebene musst du viel mehr darauf achten, den richtigen Input zu bekommen, als bei Projekten weiter oben im Technologie-Stack. Wenn du an einer Funktion arbeitest, die die Benutzeroberfläche ändert, aber das zugrunde liegende Datenmodell unangetastet lässt, ist es oft risikoärmer, unabhängiger zu experimentieren – aber du solltest trotzdem für die Benutzer*innen nicht alles „kaputt machen“. Ein großer Teil meiner Aufgabe besteht darin, die Blattknoten von den Wurzelknoten zu trennen und für das Team zu klären, was schnell umgesetzt werden kann und wofür ein grundlegenderer Ansatz mit Feedback von den wichtigsten Stakeholder*innen nötig ist.

Auch Produktänderungen sind häufig Wurzelknoten. Wenn wir zum Beispiel über ein neues Design-Primitiv wie automatisches Layout nachdenken, müssen wir sicher sein, dass wir von den neuen Eigenschaften, die es mit sich bringt, wirklich überzeugt sind, denn eine nachträgliche Änderung könnte bestehende Workflows und Designs beeinträchtigen. Bei vielen unserer wichtigen Markteinführungen und technischen Neuerungen mussten wir über einzelne Umgebungen, Sprachen oder Abstraktionsgrenzen hinaus in ganzen Zweigen, vom Blatt bis zur Wurzel, denken.

Für Entwickler*innen kann das eine Umstellung sein, weil sie es gewohnt sind, sich zu spezialisieren, z. B. für Entwickler*innen mit Erfahrung im Front-End-Bereich, die neu in der Systemprogrammierung oder Infrastrukturarbeit sind. Die Sache ist die: Wir alle unterschätzen unsere Fähigkeit, schnell zu lernen. Deshalb stellen wir absichtlich Teams zusammen, in denen Entwickler*innen sowohl an den Blättern als auch an den Wurzeln arbeiten. So schaffen wir eine Struktur, in der wir im Technologie-Stack nach oben und unten arbeiten können. Damit sind wir in der Lage, gegenseitig unser Fachwissen zu nutzen und Herausforderungen direkt anzugehen, statt sie zu vermeiden. Die effektivsten Entwickler*innen sind diejenigen, die nicht auf einen Bereich spezialisiert sind, sondern Herausforderungen annehmen und das Selbstvertrauen haben, sich schnell in neue Systeme einzuarbeiten. Sie gehen Problemen nach, egal, wohin sie führen, und lassen sich nicht durch ihre Rolle einschränken. Mit dieser Arbeitsweise haben wir den Mut gefunden, das Produktdesign überhaupt ins Internet zu bringen.

Ich habe genug verschiedene Prinzipien, Umgebungen und Prozesse in verschiedenen wachstumsstarken Unternehmen gesehen, um zu wissen, dass es nicht den einen „richtigen“ Weg gibt, etwas zu tun. Tatsächlich sind die erfolgreichsten Unternehmen oft trotz einiger dieser Entscheidungen erfolgreich. Während wir uns gemeinsam durch die sich ständig verändernde Landschaft der Technik und Zusammenarbeit bewegen, dürfen wir nicht zulassen, dass frühere Erfahrungen die Fähigkeit unseres Teams einschränken, die Feinheiten neuer Probleme zu lösen. Ebenso sollten wir dem Drang widerstehen, uns auf unsere Rollen und Titel zu beschränken. Es ist leicht, sich zu sehr auf eine kanonische Definition einer Rolle oder eines Prozesses zu versteifen, anstatt das zu tun, was in der Praxis nötig ist – ausgehend von grundlegenden Prinzipien zu denken, mit einem niedrigen Ego zu beginnen und über die Beschränkungen früherer Versuche hinauszugehen.