Jannet zeigt uns anhand zweier konkreter Migrations-Projekte bei Scout24, wie wichtig Kommunikation bei der Umsetzung ist. Außerdem gewährt sie uns einen Einblick in das internationale Projektmanagement mit verteilten Teams bei PLUMgrid und wie sie von diesen Erfahrungen bei Scout24 profitiert.
Vita
Schon während ihres Studiums der Elektrotechnik an der National University of Sciences and Technology in Islamabad interessiert sich Jannet mehr für die Software-Seite und arbeitet nach ihrem Abschluss als Test- und DevOps-Engineer. Nach einer intensiven Phase bei PLUMgrid und die Übernahme durch VMware ziehen sie und ihr Mann nach Berlin, wo sie sich bei der Scout24-Gruppe bewirbt. Heute arbeitet sie als Engineering Manager mit verteilten Teams in Berlin und München.
Hi Jannet, welche Rolle hast du bei Scout24?
Ich bin Engineering Manager bei Scout24. Als ich zu Scout24 gekommen bin, ist gerade ein neues Team zusammengestellt worden, das Delivery Engineering Team. Das habe ich dann übernommen. Außerdem leite ich mittlerweile auch as Team, das unsere Migration in die Cloud vorantreibt. Das ist die Konsequenz aus meiner Arbeit in meinem ersten Team. Sie sagten: „Du hast hier so gute Arbeit geleistet, hier hast du noch ein Team.“
Welche Projekte werden in deinen Teams umgesetzt?
Im Delivery Engineering Team haben wir zum Beispiel die Migration aller Source Code Management Tools hin zu GitHub Business in der Cloud vollzogen. In der Platform Engineering Abteilung sind wir ein Langzeitprojekt angegangen, bei dem es um die Migration aller Teams in die AWS Cloud geht.
Wie lange bist du schon bei Scout24?
Zum 1. Januar 2018 habe ich meine Stelle angetreten. Ende des Monats sind es dann acht Monate.
Was hast du davor gemacht?
Im Oktober 2017 bin ich mit meinem Mann aus Pakistan nach Deutschland gezogen. Scout24 ist die erste Firma in Deutschland, bei der ich arbeite. Der Plan war es, erst einmal herzuziehen und dann einen Job zu suchen.
Tech Jobs
Warum habt ihr euch für Deutschland entschieden und nicht zum Beispiel für die USA?
Das ist eine gute Frage, zumal ich vorher für eine US-Firma gearbeitet habe. Sagen wir es mal so: Die Visa-Situation zwischen Pakistan und den USA ist angespannt. Der Prozess, als Techie ein europäisches Arbeitsvisum zu bekommen, ist da verhältnismäßig einfach.
Welche Ausbildung hast du in Pakistan absolviert?
Ich habe meinen Bachelor der Elektrotechnik an der National University of Sciences and Technology in Islamabad gemacht und schon während des letzten Jahres gemerkt, dass mich eher die Software-Seite interessiert. In meinem Abschlussprojekt ging es dann auch um Programmierung.
Meinen ersten Job hatte ich nach dem Studium als Test- und DevOps-Engineer beim pakistanischen Office des US-Startups PLUMgrid, das recht bald von VMware übernommen wurde. Häufig war ich in Teams dran, wenn es etwas zu managen oder die Führung zu übernehmen galt. So bin ich letztendlich in der Management-Rolle gelandet.
Wie muss man sich deinen Alltag bei Scout24 vorstellen?
Aktuell komme ich so gegen 8.30 Uhr nach einer knappen Stunde Fahrt im Büro an. Bis dahin habe ich mich dann schon durch ein paar Blogs gelesen.
Welche sind das?
Ich lese zum Beispiel Hacker News, einige Blogs, und Medium ist auch ein guter Ort, um Dinge zu lesen. Außerdem folge ich einigen auf Twitter.
Wie geht es dann weiter im Büro?
Um 9.45 Uhr starten die Dailys, die bei uns 15 Minuten lang dauern, und danach haben wir unseren Tech Huddle.
Was ist ein Tech Huddle?
Im Tech Huddle diskutieren wir technische Probleme, irgendetwas, was uns blockiert, oder wenn wir etwas den anderen sagen wollen. Wenn man zum Beispiel einen Rat benötigt, dann kann man das im Tech Huddle fragen. Er ist freiwillig, aber wir nutzen die Zeit dafür ziemlich häufig.
Was steht dann noch an?
Wir haben regelmäßige OKR Checkpoints, um zu sehen, ob sich alles in die richtige Richtung entwickelt. Wir machen regelmäßige Groomings und Retrospektiven ‒ wir nutzen Scrum oder Kanban, je nachdem, was für das Projekt am Besten geeignet ist. Manchmal verbringe ich viel Zeit in One-on-Ones und Meetings mit Kollegen, mit denen ich direkt zu tun habe. Das sind zwei Teams mit acht Kollegen, die ich wöchentlich spreche. Gespräche mit den Peers und das Stakeholder Management sind wichtig, um alle auf dem aktuellen Stand zu haben.
Lass uns mal konkret auf ein Projekt eingehen. Wie hast du zum Beispiel die Migration der Source Code Management Tools gemanagt?
Dazu musste ich erst einmal die Geschichte des Unternehmens kennen lernen. ImmobilienScout24 und AutoScout24 waren in der Vergangenheit zwei komplett eigenständige Firmen. Der Zusammenschluss vor einigen Jahren passierte zunächst auf dem Papier. Die eigentliche Arbeit hat dann aber erst begonnen. Das bedeutet zum einen die Zusammenführung der Unternehmenskulturen, aber auch die der Technologien.
Ein Teil unseres Jobs ist es, die unterschiedlichen Level der Teams anzugleichen. Dabei geht es um die Standardisierung der Technologien, der Tools und der Prozesse. Und zwar an beiden Standorten, Berlin und München. Ich bin darum auch viel unterwegs, weil mein Team auf zwei Standorte aufgeteilt ist.
Der Zusammenschluss vor einigen Jahren passierte zunächst auf dem Papier. Die eigentliche Arbeit hat dann aber erst begonnen.
Einer meiner ersten Schritte, als ich das Team übernommen habe, war die Identifizierung der Stakeholder. Wer ist wofür zuständig, wer sind die wichtigen Ansprechpartner? Wir sind eine ziemlich große Firma, da war das gar nicht so einfach.
Wie viele Teams gibt es bei Scout24?
Wir sind in Berlin mehr als 660 Scouts. Insgesamt hat Scout24 1.200 Mitarbeiter, davon etwa 400 Entwickler, die wir als unsere User ansehen. Wir sagen immer, dass wir wie Raketentreibstoff für die Teams sind. Das ist das Spannende an meiner Arbeit. Wir versuchen die Teams schneller und besser zu machen.
Als wir das Delivery Engineering Team gelauncht haben, haben wir erst mal ein Delivery-Engineering-Frühstück unten in der Kantine veranstaltet, zu dem jeder eingeladen war. Denn nur im direkten Kontakt kann man die Art von Beziehung zu seinen Kollegen aufbauen, die es einem ermöglicht, dass man Feedback bekommt, selbst welches geben kann und dafür sorgen kann, dass sich Dinge in die richtige Richtung entwickeln.
Mit welchem Ansatz habt ihr dann die Migration umgesetzt?
Diese Initiative war aus Kosten-, Sichtbarkeits- und Technologie-Gesichtspunkten so wichtig, dass wir sie auf allen Leveln gespielt haben. Das bedeutet, wir haben uns sowohl mit den Managern als auch den Engineers besprochen. Wir waren uns am Ende alle einig, dass wir es Team für Team machen müssen, und haben den Zeitrahmen für ein Team auf eine Woche festgelegt.
Wir haben dann die gesamte Vorarbeit geleistet. Wir haben die Slots abgestimmt und den Prozess transparent dargelegt. Jeden Schritt haben wir in Confluence dokumentiert. Bei der Umsetzung haben wir dann die Teams involviert und einen GitHub Migration Support Channel auf Slack eingerichtet. Der größte Teil der Arbeit war eigentlich Kommunikationsarbeit: E-Mails, FAQs erstellen und die Organisation des Tech Community Meetups, auf dem wir für Fragen ansprechbar waren.
Der größte Teil der Arbeit war eigentlich Kommunikationsarbeit.
Eines unserer Ziele war es, die Teams so wenig wie möglich in Beschlag zu nehmen. Darum haben wir uns zum Beispiel auch mit einem Team von GitHub ausgetauscht und seine Erfahrungen in den Prozess einfließen lassen. Deswegen haben wir zum Beispiel zwei Slots eingerichtet, einen vor dem Mittagessen und einen danach. In jedem Slot haben wir uns auf ein Segment konzentriert.
So wusste jeder, wann er Code für welches Segment committen kann. Es gab für jedes Segment auch eigene Slack-Channel, in denen dann der Status kommuniziert wurde. So sind wir Tag für Tag vorgegangen und am Ende der Woche war dann alles migriert. Vorher hatten wir vier verschiedene Tools und Systeme, jetzt nutzen wir GitHub Business.
Tech Jobs
Welche Probleme traten auf?
Die Migration der Repos ist eine Sache. Die User müssen sich aber auch einen neuen Account anlegen. Zwei Monate vor der eigentlichen Migration hatte ich bereits angefangen, Mails an alle zu schicken, dass man einen eigenen Account auf GitHub braucht. Wir haben dann eine Map gebaut, welcher User auf GitLab welchem User auf GitHub entspricht.
Trotzdem gab es kurz vorher noch immer circa 30 Entwickler, die noch keinen Account hatten. Daraufhin habe ich dann auch die Manager mit in die Mails reingenommen und es stellte sich heraus, dass ein paar der Entwickler bis dahin noch nicht einmal etwas von der Migration gehört hatten. Die Lektion, nicht nur für uns, sondern auch für die Manager der Teams war, dass man in so einem Fall nicht zu viel kommunizieren kann.
Man kann nicht zu viel kommunizieren.
Die Erfahrungen aus diesem Projekt kannst du vermutlich direkt auch bei der Migration in die Cloud anwenden.
Ja, denn auch hier ist die Kommunikation der Schlüssel, da es viele Leute betrifft: Teams, Manager, alle sind diesmal im gleichen Channel, und wir treffen uns wöchentlich, damit wir auf dem gleichen Stand sind.
Was war die Herausforderung bei diesem Projekt?
Technisch ging es darum, alle ImmobilienScout24 Datacenter in die Cloud zu AWS zu migrieren. Die Datacenter waren bisher so gebaut, dass sie für 10 bis 20 Jahre halten. Es gibt viele Abhängigkeiten und wenn man in die Cloud umzieht, muss man Schritt für Schritt vorgehen. Es gibt drei Vorgehensweisen in so einem Fall: Beim „Lift and Shift“ nimmt man einfach alles und schiebt es in die Cloud und und ändert nichts an den Applikationen und der Umgebung wie Deployment oder Monitoring.
Dieselben Virtuellen Maschinen laufen einfach nur woanders. Beim Projekt „Re-Platform“ sucht man sich ein paar Komponenten heraus und passt sie an. Bei „Re-Architect“ schreibt man so viel um wie möglich, um es während der Migration Cloud native zu haben. Wir haben uns für die zweite Variante entschieden, weil man sich hier auf den Umzug an sich konzentriert. Das war nicht einfach, weil die Grenze zwischen Re-Architect und Re-Platform fließend ist. Dafür haben wir ein Tiger-Team aus Experten zusammengestellt. Seine Aufgabe war es, den Teams zu zeigen, was sie vor der Migration ändern müssen und was sie erst später optimieren müssen.
Zum Ende des Interviews würde ich gerne noch etwas mehr auf die Soft Skills eines Engineering Managers eingehen. Was, denkst du, ist hier wichtig?
Ich glaube, es geht um die Fähigkeit, ein Projekt voranzutreiben. Du brauchst dazu ein Team, in dem alle mit offenen Karten spielen. Mein absolutes Lieblingsbuch diesbezüglich ist von Kim Scott: „Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity“. Wenn du ein Team managst, sagt sie, dann musst du dich persönlich dafür einsetzen. Andererseits musst du das Team aber auch challengen. Und um das tun zu können, ist gute Kommunikation wichtig. Außerdem geht es um Dependency Management, das Beseitigen von Blockaden und darum, die strategischen Ziele nicht aus den Augen zu verlieren.
Wie war der Sprung aus Pakistan nach Deutschland rückblickend für dich?
Als ich damals direkt mit den US-Kollegen gearbeitet habe, war die Kultur sehr offen, freundlich und Feedback-orientiert. Der Umstieg zu Scout24 war daher einfach, da die Unternehmenssprache Englisch ist und die Kollegen recht international sind. Ich vermisse natürlich die Berge um Islamabad und das Essen. Dafür ist hier die Work-Life-Balance eine andere. Hier wird der Urlaub, der einem zusteht, auch genommen.
Trotzdem bin ich hier schon auch auf unterschiedliche Reaktionen auf meine Person gestoßen.
Inwiefern?
Ich hatte dazu ein interessantes Gespräch mit einem Kollegen, kurz nachdem ich hier angefangen habe. Er meinte, wenn man sich eine Person für eine Engineering-Manager-Rolle vorstellt, dann ist das eher ein Mann um die 40. Das bekam ich anfangs durchaus zu spüren. In der Zwischenzeit spielt das keine Rolle mehr. Ein anderer Kollege gab mir später das Feedback, dass, wenn er mit mir arbeitet, er das Gefühl hat, dass ich in meiner Vergangenheit etwas ausgesetzt gewesen sein muss, das schlimmer war als die Arbeit bei Scout24.
Warst du das denn?
Ich kann mich noch gut an ein Projekt bei PLUMgrid erinnern, als ich noch in Pakistan war. Ich hatte verteilte Teams in Pakistan, in den USA, Westküste und Ostküste, und ein UI-Team in Rumänien. Ich war mehrere Wochen ununterbrochen im Flugzeug ‒ der Flug von Pakistan in die USA dauert 20 Stunden ‒, und das Projekt fand in fünf unterschiedlichen Zeitzonen statt. Wir mussten die Meetings teilweise aufspalten. Eine Teil fand am Morgen statt, ein Teil am Nachmittag und aufgrund der Zeitverschiebung einer nachts um zwei. Irgendwie haben wir das hinbekommen. Das war wirklich unglaublich, aber auch ziemlich anstrengend.
Liebe Jannet, vielen Dank für das Interview!
Dieses Interview wurde am 23. August 2018 in den Räumlichkeiten von Scout24 in Berlin gehalten.