Interview with Gina, Revolve NTNU

English

Deutsch

How do you avoid/prevent a high fluctuation in your team?

Like all Formula Student teams, we are a volunteer project made up entirely of students, and the team composition is unpredictable. You never know how many candidates will apply, how important they might become and what kind of experience they have. By having generic positions in the group, we avoid “locking in” resources to a system that does not need them. For example, let's say we admit a member to the perception team, and get a suitable applicant for the control position. But then, we see, that our control systems are the limiting factors to performance, not the perception, we would be stuck with non-optimal resource allocation.

In contrast, if we just admit good engineers who are passionate about the group in generic roles, we can sit down together and say: ‘Hey, what is limiting our performance?’ And focus our resources there.

So, you mean you already clearly communicate your expectations and your approach during the application process? Nonetheless, have you ever experienced issues in creating a successful team?

Yeah. I mean, you cannot say that nobody has ever quit or had issues. But I think one of the nice things in Revolve NTNU that I'm very, very grateful for, is the strong community that we have. We expect everyone to put in the same amount of work, no matter what group they are in or what position they have. We expect people to be at the office and the workshop and hang out together. To support this approach, we not only work together but also promote the team dynamic by having social events and shared meals during the summer.

How long are the team members part of the team in average?

We have everything from one year to five years. Five years is quite rare, but it happens. Most of our members are only there for one year, though. So, I think we have about a 10 to 15% retention rate.

By saying your core team is almost changing every year, how are you handling the knowledge management? How can you guarantee that the team of the next season do not need to repeat everything you already did, but they really can proceed on the topics you are on?

First, we're lucky to have very active and reachable alumni. Because many people only stay for one or two years, we have a solid alumni base from recent years still at the university who we often invite to come around and help out. For example, we have a concept review at the beginning of the year where members present their ideas for the coming year to alumni. This event is important and popular, both for the presenting members and the alumni that attend to help out!

In addition to our alumni base, our transfer of experience in autonomous software is aided by our working standards which encompass practices regarding how to name branches, how to record issues, what kind of libraries we use, and more. All of that has been decided by the group and consolidated in our documentation. We have invested time into refactoring the code this year to fit these very standards and consolidate a good, understandable pipeline. Additionally, we hold code reviews among the group members and gain a lot from suggestions like: ‘this would work, but have you tried doing it this way?’

Last but not least, our autonomous pipeline has a modular design: each system in the pipeline has a standardized set of inputs and outputs. This gives us the freedom to experiment with new versions of a system – for example, a new type of controller – while maintaining backward compatibility with previous, proven concepts, reducing the consequences for members trying something new.

So as always, communication is the key for successful knowledge management?

Yeah. Working together, communicating.

Wie vermeidet ihr eine hohe Fluktuationsrate in eurem Team?

Wie alle Formula Student Teams sind wir ein ehrenamtliches Projekt, das sich ausschließlich aus Studenten zusammensetzt, und die Zusammensetzung des Teams ist nicht vorhersehbar. Man weiß nie, wie viele Kandidaten sich bewerben, wie wichtig sie werden könnten und welche Erfahrungen sie mitbringen. Indem wir allgemeine Positionen in der Gruppe haben, vermeiden wir es, Ressourcen an ein Software System zu binden, das evtuell gar kein Entwicklungsbedarf aufweist. Nehmen wir zum Beispiel an, wir schreiben eine Stelle für den Bereich Objekterkennung aus, und bekommen einen geeigneten Bewerber für diese Position. Wenn wir dann allerdings feststellen, dass unsere Kontrollsysteme die leistungsbegrenzenden Faktoren sind und nicht die Objekterkennung, müssen wir mit einer nicht optimalen Ressourcenzuweisung leben. Wenn wir dagegen gute Ingenieure akquirieren, die sich für allgemeine Aufgaben begeistern, können wir uns zusammensetzen und sagen: "Hey, was schränkt unsere Leistung ein?” Und unsere Ressourcen dann darauf konzentrieren.

Du meinst also, dass ihr eure Erwartungen und euren Ansatz bereits während des Bewerbungsverfahrens klar kommuniziert? Haben ihr dennoch jemals Probleme bei der Bildung eines erfolgreichen Teams gehabt?

Ja. Ich meine, man kann nicht sagen, dass niemand jemals gekündigt hat oder Probleme hatte. Aber ich denke, eines der schönen Dinge bei Revolve NTNU, für die ich sehr, sehr dankbar bin, ist die starke Gemeinschaft, die wir haben. Wir erwarten, dass jeder das gleiche Maß an Arbeit leistet, unabhängig davon, in welcher Gruppe er ist oder welche Position er hat. Wir erwarten, dass die Leute im Büro und in der Werkstatt sind und zusammen abhängen. Um diesen Ansatz zu unterstützen, arbeiten wir nicht nur zusammen, sondern fördern auch die Teamdynamik durch gesellschaftliche Veranstaltungen und gemeinsame Mahlzeiten während des Sommers.

Wie lange sind die Teammitglieder im Durchschnitt im Team?

Wir haben alles von einem Jahr bis zu fünf Jahren. Fünf Jahre sind eher selten, aber es kommt vor. Die meisten unserer Mitglieder sind allerdings nur ein Jahr dabei. Ich denke, wir haben eine Verbleibquote von 10 bis 15 %.

Wenn du sagst, dass euer Kernteam fast jedes Jahr wechselt, wie handhabt ihr dann das Wissensmanagement? Wie stellt ihr sicher, dass das Team der nächsten Saison nicht alles wiederholen muss, was ihr bereits getan habt, sondern dass es wirklich mit den Themen weitermachen kann, die ihr gerade behandelt?

Erstens haben wir das Glück, dass wir sehr aktive und erreichbare Alumni haben. Da viele Leute nur ein oder zwei Jahre bleiben, haben wir eine solide Basis von Alumni aus den letzten Jahren, die noch an der Universität sind und die wir oft einladen, zu uns kommen und zu helfen. So veranstalten wir zum Beispiel zu Beginn des Jahres eine Konzeptbesprechung, bei der die Mitglieder den Alumni ihre Ideen für das kommende Jahr vorstellen. Diese Veranstaltung ist wichtig und beliebt, sowohl für die vorstellenden Mitglieder als auch für die Alumni, die teilnehmen.

Zusätzlich zu unserer Alumni-Basis wird unser Erfahrungstransfer in Bezug auf autonome Software durch unsere Arbeitsstandards unterstützt, die Standards in Bezug auf die Benennung von Zweigstellen, die Erfassung von Problemen, die Art der von uns verwendeten Bibliotheken und vieles mehr umfassen. All dies wurde von der Gruppe beschlossen und in unserer Dokumentation konsolidiert. Wir haben in diesem Jahr viel Zeit in die Überarbeitung des Codes investiert, um ihn an diese Standards anzupassen und eine gute, verständliche Pipeline zu erstellen. Außerdem führen wir Code-Reviews unter den Gruppenmitgliedern durch und profitieren dabei sehr von Vorschlägen wie: Das würde funktionieren, aber habt ihr das auch schon mal so gemacht?

Nicht zuletzt ist unsere autonome Pipeline modular aufgebaut: Jedes System in der Pipeline hat einen standardisierten Satz von Eingängen und Ausgängen. Das gibt uns die Freiheit, mit neuen Versionen eines Systems zu experimentieren - zum Beispiel mit einem neuen Controller-Typ - und gleichzeitig die Abwärtskompatibilität mit früheren, bewährten Konzepten aufrechtzuerhalten, was die Folgen für die Mitglieder verringert, die etwas Neues entwickeln.

Kommunikation ist also wie immer der Schlüssel zum erfolgreichen Wissensmanagement?

Ja, genau. Zusammenarbeiten, kommunizieren.