Wie Paradox Interactive effektive Teams aufbaut: Einblicke von Andrew Gomes [Interview]

‍Mateusz Radominski:

Hallo zusammen, ich bin hier mit Andrew Gomes, Projektmanager bei Paradox Interactive, und heute werden wir über den Aufbau und die Leitung von Entwicklungsteams sprechen. Andrew, könntest du mir mehr über deine Rolle bei Paradox Interactive erzählen?

‍

Andrew Gomes:

Nun, ich bin Projektmanager bei Paradox, und ich weiß, dass das ein sehr weit gefasster Titel ist. Das bedeutet viele verschiedene Dinge an vielen verschiedenen Orten. In meinem Kontext bedeutet das jedoch, dass ich mit unseren Entwicklungsteams zusammenarbeite, um sicherzustellen, dass die Prozesse und Liefererwartungen alle aufeinander abgestimmt, realistisch und gesund sind. Und insofern ist das von Team zu Team unterschiedlich. Manchmal agiere ich als Scrum Master, manchmal ist es viel mehr als das, was die Leute als traditionelle Projektmanager-Kapazitäten betrachten würden. Ein Blick auf Zeitpläne und Roadmaps.

‍

Mateusz Radominski:

Ich hab's. Und wie wäre es mit der Strukturierung der Teams, die an den Projekten arbeiten? Was ist Ihr Ansatz dazu?

‍

Andrew Gomes:

Normalerweise verwenden wir das Scrum-Format. Ich würde sagen, im Allgemeinen neigen wir dazu, eine Seite agiler Entwicklungspraktiken hinzuzufügen. Das finden wir bei unseren Teams, die an Live-Diensten und -Produkten arbeiten. Scrum kann ganz gut funktionieren. Natürlich gibt es andere Teams, die vielleicht mehr an Kanban oder Scrumban interessiert sind, aber es ist wirklich etwas, das wir versuchen, mit den Teams selbst zu coachen und zu entwickeln, anstatt eine von oben nach unten gerichtete Arbeitsweise zu entwickeln.

‍

Mateusz Radominski:

Okay, und kannst du ein „typisches Team“ definieren oder passt du die Teamstruktur an das Projekt an, an dem sie gerade arbeiten?

‍

Andrew Gomes:

Es ist ein bisschen von beidem. In jedem Team gibt es ein paar Kernpunkte. In der Regel haben wir jemanden in einer Position der technischen Führung, jemanden in einer Position der Prozessleitung und dann jemanden in einer Position der Produktleitung. Aber darüber hinaus kann die Art und Weise, wie wir das Team um diese drei Säulen herum strukturieren, ziemlich unterschiedlich sein, je nachdem, was das Team zu erreichen versucht.

‍

Mateusz Radominski:

Und wenn Sie auf eine Sache hinweisen müssten, die Ihrer Meinung nach entscheidend ist, wenn es um die Strukturierung eines effektiven Teams geht, was wäre das?

‍

Andrew Gomes: 

Ich denke, eines der wichtigsten Dinge, um ein effektives Team zu haben, ist es, sicherzustellen, dass Sie alle, die an dieser Struktur teilnehmen, über die Zustimmung informiert haben. Prozesse funktionieren nicht besonders gut, wenn sie Menschen aufgezwungen werden, wenn dadurch nur ein Umfeld entsteht, in dem die Menschen einen Prozess als etwas betrachten, das ihrer eigenen Kreativität und ihrer eigenen Freiheit und Autonomie, ihre Arbeit abzuschließen, im Wege steht. Wirklich hilfreich ist es, wenn die Mitarbeiter darüber aufgeklärt werden, warum der Prozess da ist, was er erleichtern soll, und wenn sie die Möglichkeit erhalten, zu sehen, dass er diese Bedürfnisse im Rahmen des Onboardings in das Team oder des Onboardens in die Prozesse tatsächlich erfüllt.

‍

Mateusz Radominski:

Ich hab's. Und kannst du mir etwas mehr über die Zusammenarbeit mit externen Partnern erzählen? Zum Beispiel, wie findest du dich in der Arbeit mit Leuten, die außerhalb von Paradox sind, wieder und wie unterscheidet es sich?

‍

Andrew Gomes:

Ich würde sagen, zum Glück, ich meine, in der heutigen Zeit haben wir so viele externe Kapazitäten, dass und vor allem nach der Pandemie, es einfach zu einer üblichen Arbeitsweise geworden ist, dass es sich nicht sonderlich seltsam anfühlt, in dieser Position zu sein. Wir arbeiten mit Teams zusammen, die in einer ganz anderen Stadt ansässig sind. Ich denke, eine der Herausforderungen, die sich bei jeder Art von reiner Remote-Setup ergeben, ist jedoch, dass es viel schwieriger ist, ein tieferes emotionales Vertrauen aufzubauen, das man normalerweise in einem Team finden möchte. Ich denke, viele Leute halten es für selbstverständlich, wie wichtig es ist, einen glücklichen und produktiven Arbeitsplatz zu haben, aber Sie müssen wirklich das Gefühl haben, dass Sie sich auf die Leute verlassen können, die mit Ihnen zusammenarbeiten, dass sie nicht nur ein Gesicht auf der anderen Seite des Internets sind, das keine Konsequenzen für Sie hat. Ich denke, das ist wahrscheinlich die größte Herausforderung. Aber gleichzeitig ist dies keine besondere Herausforderung für Teams, Remote-Setups, zumindest nicht mehr.

‍

Mateusz Radominski:

Daher sind der Aufbau von Beziehungen, Vertrauen und Eigenverantwortung hier von entscheidender Bedeutung.

‍

Andrew Gomes:

Auf jeden Fall. Ich glaube, die Leute haben Angst davor, wie leicht sie, wie leicht sie vermuten, dass sich andere Leute vom Team lösen können und dass das den Verdacht erweckt, dass sich alles auf sie häufen wird. Bei dieser einen Person. Daher ist es wirklich wichtig, dass Remote-Teams und insbesondere Teams, die in dieser Art von Agentur- und Kundenbeziehung arbeiten, das Gefühl entwickeln, auf derselben Wellenlänge zu sein, gemeinsam an einem Strang zu ziehen und ein gemeinsames Gefühl von Eigenverantwortung und Beiträgen zu haben, sodass die Angst vor der Angst, dass jemand einfach abspringt und das Projekt hängen lässt, minimiert wird.

‍

Mateusz Radominski:

Ja, das verstehe ich. Und lassen Sie uns für eine Weile zum Prozess der Teamzusammenstellung zurückkehren. Was sind die wichtigsten Dinge, auf die du achtest, wenn du das Team zusammenstellst, zum Beispiel, gibt es bestimmte Charaktereigenschaften, nach denen du bei Leuten suchst?

‍

Andrew Gomes:

Ich würde sagen, dass ein Interesse am Prozess für mich persönlich sehr hilfreich ist. Das heißt also nicht unbedingt, dass die Person ein Experte für einen bestimmten Prozess sein muss oder dass sie in der Vergangenheit sogar unbedingt gute Erfahrungen gemacht haben muss. Aber die Bereitschaft zu versuchen zu verstehen, warum eine andere Gruppe die Dinge anders macht, ist meiner Meinung nach entscheidend, um in der Lage zu sein, einem Team beizutreten und sich in die Best Practices zu integrieren, die sich in der Regel aus gutem Grund weiterentwickelt haben. Das heißt aber nicht, dass alle bewährten Verfahren und alle Prozesse regelmäßig überprüft und bei Bedarf geändert werden sollten. Es kommt jedoch selten vor, dass ein Prozess eingeführt wird, nur weil er normalerweise im Laufe der Zeit entwickelt wurde, um ein Problem zu lösen. Und es ist wirklich wichtig, dass Sie, wenn Sie in einen Raum kommen, versuchen zu verstehen, was diese Probleme waren und wurden sie gelöst oder sind sie immer noch vorhanden? Ist der Prozess etwas, das aktiv hilft? Oder ist es etwas, das das Team vielleicht hinter sich gelassen hat und es Zeit für eine Veränderung ist? Aber das sind alles Fragen, von denen ich denke, dass es wirklich hilfreich ist, sie zu beantworten.

‍

Mateusz Radominski:

In Ordnung, also eine Art Neugier auf den Prozess und zu verstehen, warum manche Dinge auf eine bestimmte Art und Weise passieren und zu fragen, ob das immer noch die beste Art ist, zu funktionieren. Und da das Brainhub-Team am Paradox-Projekt arbeitet, kannst du mir sagen, wie sie diese Kriterien erfüllen können?

‍

Andrew Gomes:

Ja, das Team ist also schon länger bei uns, sie arbeiten schon länger mit uns zusammen, als ich speziell mit diesem Team gearbeitet habe. Sie waren tatsächlich bei vielen dieser Änderungen dabei. Sie haben also gesehen, wie sich Prozesse im Laufe der Zeit weiterentwickelt haben, und dann vor relativ kurzer Zeit einige neue Mitarbeiter hinzugezogen. Und eines der Dinge, die diesen Übergang wirklich erleichterten, war, dass sie verstanden, was das Produkt war, dass sie hinzukamen, weil ihre Kollegen natürlich bereits zuvor daran gearbeitet hatten, aber sie hatten auch ein ziemlich gutes Gespür dafür, dass Prozesse aus unserer Sicht, aus der Sicht unserer Kunden, ablaufen. Unsere Prozesse waren nicht unbedingt in Stein gemeißelt. Was uns am meisten interessierte, war, dass das Team bereit war, seinen Beitrag zu leisten und im Wesentlichen so zu funktionieren, wie es interne Entwickler tun würden, und das gleiche Maß an Eigenverantwortung und Input bei der Art und Weise, wie sie arbeiten, zu übernehmen. Und ich denke, es war uns sehr klar, dass die Leute, die dem Team beitraten, bereit waren, solche Gespräche zu führen und bereit waren, diese Art von Teilnahme und Input zu bieten und außerdem einfach großartige Entwickler waren.

‍

Mateusz Radominski:

Toll, es ist schön, das zu hören. Und jetzt komme ich zurück zu der Neugier, die Sie zuvor erwähnt haben. Das ist eine der Soft Skills, nach denen man bei Menschen sucht. Gibt es noch andere, die Sie für entscheidend halten, und wie bringen Sie sie mit den Hard Skills in Einklang?

‍

Andrew Gomes:

Ich meine, ich denke, Hard Skills sind immer eine ziemlich einfache Sache. Es gibt bestimmte Sprachen, in denen man bestimmte Arbeitsweisen kennen müsste, die einfach grundlegend sind, um das Produkt zu entwickeln, aber bei den Soft Skills, die wirklich auftauchen, geht es wirklich darum. Dinge wie Erwartungsmanagement und das Selbstvertrauen, sich auf unklare Fragen einzulassen. Ich weiß, dass es definitiv eine Herausforderung sein kann, wenn die Entwickler eine Reihe von Anforderungen erhalten, aber die Person, der die Anforderungen gestellt wurden, die Probleme, die im Weg stehen, möglicherweise nicht vollständig versteht. Daher ist es wichtig, dass die Entwickler das Gefühl haben, in einer Position zu sein, in der sie sagen können: Nun, warte eine Minute, wir müssen ein tieferes Gespräch darüber führen. Denn die Alternative ist, dass sie entweder riskieren, etwas falsch zu machen und die tatsächlichen Anforderungen nicht zu erfüllen, oder sie stressen sich selbst und die Dinge kommen irgendwie zum Stillstand, weil es einfach zu viele Unbekannte gibt. Ich denke also, dass die Soft Skills des Engagements wirklich, wirklich wichtig sind. Vor allem, wenn man das Entwicklungsteam so behandelt, als wäre es ein internes Team. Es ist wirklich wichtig, dass die Entwickler diese Perspektive einnehmen und ihre Gedanken als Entwickler einbringen, nicht nur als Finger auf einer Tastatur.

‍

Mateusz Radominski: Wir sprechen also von einer Art offener Kommunikation, also wenn ich etwas nicht verstehe, gehe ich tiefer und überkommuniziere das sogar, damit ich keine Fehler mache. Und wie achten Sie während des Rekrutierungsprozesses auf diese Dinge? Wenn Sie zum Beispiel sehen, dass jemand ziemlich gut ist, wenn es um technische Fähigkeiten geht, aber Probleme mit den Soft Skills hat, wie sprechen Sie einen solchen Kandidaten an?

‍

Andrew Gomes:

Wenn es also eine solche Situation ist, ist das Wichtigste, dass wir sehen, dass die Person daran interessiert ist zu lernen, dass sie erkennt, dass das eine Schwäche sein kann, aber dass sie auch daran interessiert ist, in diesem Bereich zu wachsen. Und ich weiß, das klingt irgendwie nach einer flauschigen Antwort. Natürlich wollen die Leute das tun, aber es passiert ziemlich oft. Du triffst auf Leute, die einfach nicht daran interessiert sind, diesen Aspekt des Entwicklerdaseins weiterzuentwickeln. Es ist also etwas, das es wert ist, gezeigt und demonstriert zu werden.

‍

Mateusz Radominski:

Ich hab's. Könnten Sie mir jetzt mehr über Ihre Entwicklungsteams erzählen? Sind sie funktionsübergreifend oder vollständig spezialisiert? Wie sieht es bei Paradox aus?

‍

Andrew Gomes:

Nun, ich würde nicht sagen, dass es unbedingt Spezialisten gibt, aber sie sind konzentriert. Sie sind sicherlich im technischsten Sinne funktionsübergreifend und lösen mehrere Probleme auf oft unterschiedlichen Tech-Stacks. Wir versuchen aber auch, Teams so weit zu unterteilen, dass sie sich wirklich auf ein oder zwei Tech-Stacks konzentrieren können. Sie werden nicht gebeten, das gesamte Spektrum der Dinge abzudecken, die wir tun. In dieser Funktion versuchen wir sicherzustellen, dass es einfache Kommunikationspunkte zwischen den Teams gibt, aber die Teams selbst sind in der Lage, sich wirklich auf die Teams selbst zu konzentrieren und sich zu spezialisieren. Wir versuchen, jegliche Art von Silobildung zu vermeiden. Wir möchten, dass unsere Entwicklungsteams im Allgemeinen intern eher funktionsübergreifend sind. Es kann vorkommen, dass sowohl Frontend-Entwickler als auch Back-End-Entwickler in einem Team arbeiten. Und dann wird in diesen Fällen die Arbeit, die sie leisten, im Allgemeinen natürlich ziemlich spezifisch sein. Aber sie arbeiten immer parallel zur regulären Kommunikation und sind Teil derselben Prozesse, sodass alle auf derselben Wellenlänge sind und wissen, was die anderen sind, auch wenn sie technisch gesehen nicht dieselbe Arbeit erledigen können.

‍

Mateusz Radominski:

Ok, und was die Größe angeht, wie groß sind Paradox-Teams? Befolgst du irgendwelche Best Practices?

‍

Andrew Gomes:

Deshalb halten wir uns im Allgemeinen an die Best Practices, die Scrum im Allgemeinen vorschreibt, was wirklich besagt, dass man, sobald man etwa acht bis zehn Personen erreicht hat, ziemlich groß und klobig wird. Unsere Teams neigen also fast immer dazu, kleiner zu bleiben. Irgendwo zwischen drei und sechs Personen. Es ist ganz normal, wenn Teams gelegentlich ziemlich groß werden. Dann fangen wir an, sie entweder aufzuteilen oder zwei spezialisierte Unterteams innerhalb der Gruppe zu bilden. Und das ist immer eine eher spontane Konversation, es gibt keinen bestimmten Prozess, wie das abläuft, denn wenn diese Dinge zur Sprache kommen, ist es in der Regel jedes Mal eine einzigartige Situation.

‍

Mateusz Radominski:

Und wie verteilt ihr die Arbeitslast zwischen den Teams, habt ihr etablierte Prozesse?

‍

Andrew Gomes:

Die Aufteilung der Arbeit zwischen Teams ist also nicht wirklich ein Top-Down-System. Teams haben in der Regel einen Product Owner, sodass Anfragen über diesen Product Owner eingehen und nicht von einer zentralen Stelle aus verteilt werden. Innerhalb der Teams wird die Arbeitsverteilung eher als Konversation behandelt, sodass sich Entwickler als Gruppe zu einer bestimmten Menge an Arbeit verpflichten oder diese akzeptieren, die sie für den Zeitraum, in dem sie arbeiten, erledigen werden, oder ob es sich um einen Sprint handelt oder wenn sie ein eher fließendes System wie Combine haben, haben sie ihre Work-in-Progress-Grenzen. Die Verhandlung darüber, wer was macht, wird also eher als offene Diskussion behandelt: Oh, nun ja, ich habe die letzten zwei Tage der Woche Urlaub, also sollte ich keinen Job annehmen, der fünf Tage dauern wird, oder vielleicht hat diese Person mehr Fachwissen in diesem Thema, also vielleicht ist sie die Richtige dafür, weil wir es tun müssen. Wir müssen das so schnell wie möglich erledigen. Alternativ möchte diese Person vielleicht etwas über ein neues Thema lernen. Sie werden also eine Aufgabe übernehmen, mit der sie vielleicht nicht so vertraut sind, aber wir können es uns leisten, etwas länger zu dauern.

‍

Mateusz Radominski:

Nett, also eine Art Konversation darüber, was die Leute können und was sie lernen möchten.

‍

Andrew Gomes: 

Es ist also quasi ein Pull-System, wenn es darum geht, dass Entwickler ihre Arbeit übernehmen. Und natürlich versuchen wir, alle Blockaden zu entfernen, die sie daran hindern würden, Dinge auf ihren Teller zu ziehen. Aber ich denke, das wäre die beste Arbeit, die von Leuten gemacht wird, die engagiert sind und die Arbeit tatsächlich machen wollen. So weit wie möglich wird ein Pull-System einem Push-System vorgezogen.

‍

Mateusz Radominski:

Fantastisch. Andrew, gibt es irgendwelche Tipps, die unsere Zuhörer aus diesem Interview mitnehmen sollen?

‍

Andrew Gomes:

Ja, ich würde sagen, der größte Tipp ist, sich daran zu erinnern, dass die Leute die beste Arbeit leisten, wenn sie glücklich sind. Sie zeigen dir nicht immer, wenn sie gestresst sind, also ist es wirklich wichtig, sicherzustellen, dass du einen offenen Dialog mit den Leuten führst, mit denen du zusammenarbeitest, um sicherzustellen, dass sie Spaß an ihrer Arbeit haben und dass sie das Gefühl haben, dass sie in der Lage sind, zu sprechen, wenn etwas für sie einfach nicht passt, ohne Angst vor Repressalien zu haben, denn du wirst viel bessere Arbeit von Leuten bekommen, die glauben, dass sie sich engagieren und investieren können Arbeit, die sie machen, anstatt dass sie einfach da sitzen und es rausdrehen müssen, nur für die um es als erledigt zu bezeichnen.

‍

Mateusz Radominski: 

Nett. Also, in erster Linie offene Kommunikation, um sicherzugehen, dass die Leute Spaß an der Arbeit haben. Und die perfekte Zusammenfassung, um diesen Vortrag zu beenden. Andrew, danke für deine Zeit und all die Tipps, die du gegeben hast. Ich hoffe, dass es einige Leute gibt, die das nützlich finden, und hoffentlich werden wir eines Tages ein weiteres Gespräch führen.

‍

Andrew Gomes:

Danke Mateusz.

‍

Mateusz Radominski:

Danke Andrew.

‍