Transcript

[0:00] Tag 1, der Klassiker, du klingelst unten, jemand drückt dir auf, du läufst die Treppe hoch, hallo, ich bin hier für den ersten Tag.
Ja, zu wem musst du denn? Ja, zu Vanessa.
Mit dem positiven Feedback, das ist natürlich großartig, weil wenn man so gar kein Feedback bekommt, aber auch alle zufrieden sind, das ist, glaube ich, auch sehr komisch.
Hast du schon mal erlebt, dass du jemanden am ersten Tag am Start hattest, den du interviewt hast und auf einmal war die Person ganz, ganz anders, als du dachtest?
Nicht am ersten Tag.

[0:34] Music.

[1:02] Diese Revision von Working Draft wird euch präsentiert von Midwald.
Next Level Hosting für deine Projekte.
Jetzt fragt ihr euch bestimmt, wie kann sowas langweiliges wie Hosting Next Level sein? Ganz einfach.

[1:13] Midwalds hochperformantes Cloud Hosting ist perfekt abgestimmt auf die Anforderungen von Freelancern und Agenturen. Es gibt zum Beispiel ein smartes Rollensystem für die Zusammenarbeit mit euren Projektpartnern und Midwild hat mit M-Studio auch eine sehr schöne moderne Verwaltungsoberfläche gebaut, mit der das Arbeiten Spaß macht.
Aber jetzt mal ehrlich unter uns Nerds. Sachen anklicken? In einem User-Interface?
Muss das sein? Nein, muss es nicht.
Denn bei Midwild gibt's die M-Studio CLI. Mit der könnt ihr euer Hosting komplett über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.
Von Nerds für Nerds bringt euch Midwild die optimale Developer-Experience, wenn's ums Hosting geht. Und deshalb jetzt auf zu mitwald.de slash workingdraft.
Denn da wartet auf euch exklusiv als Hörer von Working Draft, das Angebot, den Tarif pro Space für 30 Tage kostenlos zu nutzen.
Das war nochmal mittwald.de slash workingdraft.
Wir danken mitwald für die Unterstützung von dieser Revision von Working Draft.

[2:07] Liebe Hörer und Hörerinnen, feiert am 7.1. von 15 bis 18 Uhr mit uns die 600.
Podcast-Episode oder bei einem einzigartigen Online-Event, denn wir veranstalten eine Fishbowl-Diskussion.
Bei einer Fishbowl-Diskussion können einige Teilnehmer und Teilnehmerinnen im Kreis diskutieren, während andere im sogenannten äußeren Kreis zuhören und dann einsteigen können.
Wir freuen uns sehr auf diese interaktive und dynamische Form für einen Austausch zwischen uns WebDevs.
Meldet euch über den Meetup-Link in den Shownotes an und seid Teil dieses spannenden Formats.
Wir freuen uns schon sehr auf euch und jetzt erstmal mal viel Spaß bei der folgenden Revision.

Revision 598: Erfolgreiches Onboarding – Einblicke mit Hans & Vanessa

https://workingdraft.de/598/

[2:52] Hallo und herzlich willkommen beim Working Draft Podcast.
Wir sind heute zu zweit. Mit mir dabei habe ich den Hans. Ja, hallo.
Und ich bin die Vanessa. Hallo, ich habe noch vergessen, die Revisionsnummer zu sagen. Wir sind bei der 598.
Es geht mit großen, großen, größten Schritten zu auf die Revision 600.
Aber heute, Hans, sprechen wir erst einmal noch über die Thematik, Webentwickler und Webentwicklerinnen onzuboarden.
Das machen wir als so eine kleine Weiterführung der Revision 593, die wir vor ein paar Wochen herausgebracht haben.
Da haben wir schon mal darüber gesprochen, wie wir eigentlich dabei vorgehen können, wenn man heutzutage Webentwickler, Webentwicklerinnen einstellen möchte.
So, nachdem wir darüber gesprochen hatten und stellen wir uns jetzt vor, dass wir ganz glücklich neue Personen eingestellt haben, die vielleicht jetzt in ein paar Monaten zu uns kommen.

[3:58] Spannend. Genau. Und jetzt ist die Frage, was wäre denn dein Lieblingsschritt, der passieren sollte, bevor eine neue Person überhaupt zu der Firma kommt?
Bevor die neue Person den ersten Tag hat.
Genau, also eigentlich ist es ja so, genau wie du gesagt hast, wir führen gerade weiter.
Wir haben so das letzte Interview mit denen gehabt. Die haben unterschrieben, mega gut.
Vertrag ist unterschrieben und per Post verschickt.
Wir sollten wahrscheinlich irgendwann nochmal eine Revision machen zur Vertragsverhandlungen.
Wie führe ich eigentlich gute Vertragsverhandlungen?
Oh, das klingt ja auch mega spannend.
Aber um da mal drauf einzugehen, sagen wir mal, der Vertrag wäre unterschrieben, was passiert als nächstes.
Und das ist halt so eine Phase.
Manchmal dauert es ja dann drei Monate oder vielleicht auch noch länger, bis die Leute dann kommen.
Was macht man in der Zeit? Und was ich zum Beispiel persönlich ganz cool finde, ist, wenn es zum Beispiel jetzt Manager gibt oder so, oder die Leute, die einen einstellen, wenn man mit denen schon mal irgendwie in Kontakt tritt, wenn man da die Möglichkeit hat, als Kandidat halt vielleicht noch mal ein paar Zusatzfragen loszuwerden oder so, je näher das Datum des eigentlichen Einstiegs rückt, desto wichtiger ist es, glaube ich, da in Kontakt zu halten. Ich als Manager.

[5:17] Ich versuche die Leute auf jeden Fall immer frühzeitig auf LinkedIn zu adden und da einmal zu schreiben, hey, cool, dass du am Start bist und wir freuen uns, dass du da bist.
Das ist mir immer wichtig, dass die Leute halt wissen, okay, da ist halt eine gewisse Attention auf dem Thema.
Also die Leute beschäftigen sich in der Firma wohl damit, dass da jemand Neues kommt, um dann halt nicht komplett unvorbereitet reinzugehen.
Ja, das ist so der Kommunikationsaspekt und wie ich schon gesagt habe, je näher man dann wirklich an das Zieldatum rankommt, ich glaube, desto wichtiger wird es halt da auch die Kommunikation halt immer frequenter zu halten, also öfter mal Bescheid zu geben.
Eben, hey, bei uns läuft alles, jetzt bestellen wir übrigens deine Hardware.
Das ist dann vielleicht so die Aufgabe auf der anderen Seite, die man mal langsam übernehmen sollte.

[6:07] Nämlich, ja, einfach mal so die Checkliste abarbeiten, würde ich sagen, damit jemand, der neu startet, zum Datum hin, dann auch wirklich gut starten kann mit allen Zugängen und so weiter. Wie läuft das bei euch?
Na, ein bisschen ähnlich, wie du gesagt hast. Also vielleicht gibt es nicht unbedingt eine LinkedIn-Nachricht, Wobei ich jetzt auch immer und immer aktiver wieder auf LinkedIn werde mit dem ganzen X-Drama.

[6:35] Ich wollte es tatsächlich auch bei so Konferenzfolien, habe ich jetzt mir jetzt aufgefallen, ich war erst gerade wieder bei einer und habe gesagt, das ist meine Social Network.
Da ist mir aufgefallen, da steht LinkedIn gar nicht dabei, aber ich muss jetzt LinkedIn da hinzufügen.
Das ist jetzt wieder eine neue, coole Tool da draußen.
Aber wahrscheinlich, ich schreibe auch immer noch mal so eine E-Mail hinterher, Weil ich natürlich jetzt im Endeffekt dann nicht den Vertrag unterschreibe und rausschicke, aber die Person kann ja dann vermutlich davon ausgehen, dass ich auch ein Ja gegeben habe und dann schreibe ich auch gerne nochmal persönlich, weil es ja sonst auch immer schon sehr aufregend ist in diesem Interviewprozess und dann finde ich das auch mal ganz natürlich sehr persönliche Note zu geben, die du geschrieben hast.
Und ganz genau, wie du sagtest, auch bei uns gibt es eine Checkliste.
Bei dieser Checkliste, die haben wir, also ich muss jetzt noch dazu sagen, das gilt jetzt wirklich nicht als Werbung für das eigene Produkt, bitte nicht dafür jetzt so wahrnehmen, aber wir haben natürlich eine Plattform, die eins der, beziehungsweise das erste richtig große Feature war ja bei uns Onboarding.
Mittlerweile haben wir zwar diesen ganzen Zyklus, aber dementsprechend haben wir schon sehr oft über Onboardings mal gesprochen.
Das heißt, wir verwalten tatsächlich auch Onboardings auf unserer eigenen Plattform.

[7:51] Wahrscheinlich kann man das genauso gut in Notion oder Excel oder Word oder keine Ahnung was machen oder euren, wie heißt das, die Notizen auf dem MacBook.
Im Endeffekt haben wir dabei auch dann eine Checkliste und bei uns mit unserem Tool, da geht es ein bisschen.

[8:09] Noch advancerer, dass wir diese Journeys erstellen können, die Schritte an verschiedene Leute rausschickt per Slack oder E-Mail.
Das heißt, dass wir automatisiert dann Nachrichten bekommen, wie so, hey, Laptop bestellen oder schauen, ob ein Laptop zur Verfügung steht. steht.

[8:24] Und dann ist für uns noch wichtig, wir haben ja ein Büro in München drin und.

[8:32] Das ist ein Shared Office Space und den gibt es mehrere Male in München und deswegen musst du immer, weil wir, stellen wir immer klar, so zu welchen von diesen Open Offices soll man denn jetzt eigentlich, weil es ist natürlich doof, wenn man dann diesen Office Namen eingibt bei Google und zum Falschen läuft und dann morgens da ankommt.
Das wäre ja wahrscheinlich ein sehr schlechtes Erlebnis für den ersten Tag.
Und Und witzigerweise ist auch das was, was wir schon oft gehört haben, was auch bei richtig großen Firmen passiert, dass zwar vielleicht die Personen eine Adresse haben.
Jetzt ist es aber so bei einer Adresse, das ist ja jetzt nicht unbedingt so eine kleine Wohnung mit so einer Haustür und so einem Schildchen, Namensschildchen oder von mir aus ein Hotel mit einer großen Rezeption.
Aber gerade so ein bisschen größere Firmengebäude, die können da schon gerade in so deutschen Städten so komische Eingänge manchmal haben.
Und da habe ich schon wirklich lustigste Geschichten darüber gehört, dass Leute verzweifelt versucht haben, irgendwo reinzukommen.
Und dann hat man zwar zumindest in Deutschland sehr wenig, ein bisschen mobile Daten zur Verfügung, um dann nochmal bei den E-Mails rumzukramen, ob man irgendwie noch einen Kontakt findet.
Aber vielleicht hat man auch gar nicht jetzt unbedingt die Handynummer oder Telefonnummer von den Leuten parat, sondern halt auch nur die E-Mail-Adresse, die jetzt vielleicht...

[9:47] Die Personen von damals nicht unbedingt sofort checken werden.
Dass da dann die Leute tatsächlich einfach versuchen, die Telefonnummern zu erkunden.
Ich versuche hier anzufangen, wo ist denn die Haustür?
Genau, das heißt, das ist tatsächlich ein wichtiger Punkt bei uns. Wo ist die Haustür?

[10:03] Sind die Geräte bestellt und verfügbar?
Und dann ist es natürlich sehr speziell, was die Leute brauchen könnten.
Ob das Zugänge sind zu Kommunikationstools oder ob es schon klar sein muss, auf welche Projekte die Personen kommen müssen, ob es sogar eine Art Onboarding-Tickets gibt, das kommt jetzt natürlich dann auf die Firma drauf an.
Ich möchte mal ganz kurz darauf eingehen, weil du sagst, man muss ja wissen, wo die Haustür ist.
Heißt das, wenn ich das richtig verstehe, ihr habt eigentlich eure Onboardings, also wenn jemand neu anfängt, dann immer so gestaltet, dass die am ersten Tag dann auch im Office vor Ort sind und sich da jemand persönlich trifft?
Nein, das ist bei uns gar nicht unbedingt der Fall. Wir können die Onboardings auch remote machen.
Also wir haben ja gerade die größten Hiringphasen hatten wir wegen Corona und wegen so Ausgangssperren.
Und da haben wir das natürlich auch sehr ernst genommen, dass auch, ich meine, ich glaube ja tatsächlich, dass es für Büros gab es ja nie wirklich den Lockdown in Deutschland.

[11:03] Aber wieso sollten wir von Leuten verlangen, irgendwie in öffentliche Verkehrsmittel zu steigen, nur um sich dann zu treffen? Da haben natürlich ganz andere Leute ganz andere Meinungen, aber bei uns war das nicht der Fall, dass man vor Ort sein muss.
Aber wie gesagt, wir sind ein Onboarding-Tool und haben natürlich da unsere User-Research gemacht und haben da sehr viele Sachen gehört und das war immer so eins der witzigsten Sachen, dass die Leute die Haustür dann nicht gefunden hatten. Mhm.
Neben diesem Problem mit der Haustür, was, äh, gab's noch irgendwelche Probleme, die ihr festgestellt habt, während, ähm, ja, ihr die Leute oder wenn ihr die Leute halt remote onboardet, gibt's da irgendwelche Probleme, die euch aufgefallen sind oder läuft das eigentlich genauso gut ab, wie wenn man sich direkt trifft?

[11:51] Und wir sind ja jetzt, wir sind bei uns ja wirklich wenige Leute und ich hatte jetzt nicht das Gefühl, dass es, also es ist wirklich wenige Leute, für uns war es recht einfach noch, dass man halt trotzdem, dass man diese Kaffee-Runde macht, weißt du, was ich meine? Dass man mal reinkommt und jeden mal trifft.

[12:08] Das habe ich bei den Frontendlern, habe ich das quasi dann übernommen, das macht quasi so jedes Gewerk dann für sich selber aus, wie man das handhabt und wir können, ja wie gesagt, wir haben halt unser Onboarding-Tool selber, wir können solche Sachen automatisieren, die erstellen dann automatisch irgendwelche Kalendereinträge mit Videokonferenz-Tools für One-on-Ones mit bestimmten Personen und was ich super gerne mache bei uns im Team selber dann, das Team kann jetzt sein, das ganze Frontend-Team oder vielleicht das Projekt-Team, ist Stunde, zwei Stunden am Abend so eine Icebreaker-Session.
Und wie gesagt, das funktioniert vielleicht eher schlechter, wenn man ununterbrochen Leute onboardet, weil sonst muss das andere Team die ganze Zeit mit sich selber Icebreaker-Questions spielen.
Aber wenn man das von Zeit zu Zeit macht, dann finde ich das ganz super.
Das ist natürlich dann schon quasi im Onboarding-Prozess und dann nicht mehr im Pre-Boarding-Prozess, solche Sessions zu haben und ich habe da so eine Liste an ganz harmlosen Icebreaker-Questions, so im Sinne von lieber Buch und lieber Film und dann kommt das Gespräch oft ins Laufen.
Ich finde es total witzig, wie unterschiedlich dann doch Developer sein können, weil ich selber immer denke, dass, es doch dann immer so, ich hatte so Fragen drin, wie Teamsport oder Einzelsport und ich hatte jetzt damit gerechnet, dass jetzt neun von zehn Developer sagen werden, ja, na klar, Einzelsport.
Ich wurde sehr überrascht Alle wollten Teamsport, nur ich wollte Einzelsport.

[13:38] Aber meiner Meinung nach sollte man sich da schon auf jeden Fall Zeit nehmen dafür.
Und Eisbrecher sind natürlich auch wirklich nur fürs Eisbrechen gedacht.
Ein Meeting, was ich für sehr wertvoll halte, ist es, darüber über Werte zu reden. Es gibt da so ein paar Online-Aufstellungen und Listen von verschiedenen Werten, die es geben könnte.

[14:05] Korrektheit, Pünktlichkeit etc. Da hat man wirklich eine große Liste und da kann man die Leute mal ganze fünf oder vielleicht sogar zehn Minuten einfach draufschauen lassen, damit sie sich entscheiden können, wie wichtig sind welche Werte für euch.
Weil auch dann versteht man vielleicht auch spätere Arbeitsweisen schon ziemlich gut.
Ich bin zum Beispiel immer so die ganz korrekte Typin und so weiter.
Und deswegen brauche ich auch Sachen normalerweise eher vollständiger, liefere dann Sachen auch vollständig ab.
Wie wenn ich einen Code-Review aufmache, dann steht da immer alles schön erklärt drin.

[14:38] Ja, also genau. Also wir müssen wahrscheinlich jetzt gleich auch mal durchgehen.
Was sind eigentlich so diese Onboarding-Szenarien, die man halt so durcharbeiten muss? Du hast jetzt schon ein bisschen ausgeführt zu Icebreaker und solchen Themen.
Ich glaube, davor gibt es halt noch dieses Ganze, was du ja eben auch gesagt hast, so Zugänge und hier was links und rechts.
Eine Sache, die ich zum Beispiel noch erwähnen wollte, jetzt auch zu diesem, ist man vor Ort oder nicht vor Ort, sind so einfache Sachen wie Hardware oder wenn VPN nicht geht.
Also bei uns zum Beispiel ist so, wir haben auch eine Zeit lang Hardware verschickt, aber im Idealfall gehst du einfach an die, bei uns heißt es Tech Bar und hast da einen Termin am ersten Tag und kannst dich dann da auch einloggen und kannst gucken, dass alles funktioniert, weil das sind halt irgendwie alles gemanagte Devices. es.
Du hast halt nicht, du kannst halt nicht einfach so auf alles zugreifen und dir installieren, was du willst und dann geht dann doch nicht dein Admin-Zeug und du musst aber dahin, damit jemand das dann irgendwie bestätigen kann, dass du halt Admin bist.
Mittlerweile ist es zum Glück nicht mehr so, jetzt haben sie das so ein bisschen anders geregelt und können das auch remote aufspielen, aber das war halt eine Zeit lang auch nicht der Fall.

[15:52] Und so sind es dann so Kleinigkeiten, oder du musst dann, keine Ahnung, dein Smartphone ist nicht registriert in der Datenbank von denen oder so.
Das sind halt so diese kleinen Sachen, was ich total cool finde, wenn man dann vor Ort ist und sich halt auch wirklich trifft.
Aber auf der anderen Seite ist das halt auch total umständlich.
Also für mich zum Beispiel, wenn ich jetzt nach München fahren wollen würde, von Köln aus, um jemanden onzuboarden, ich mache das natürlich gerne.
Jetzt sind es bei mir auch nicht so viele Leute, die ich immer direkt haiere, wo ich das dann machen würde.
Meistens ist es ja in den Teams, aber da habe ich auch festgestellt, die machen das auch super gerne, auch weil so Icebreaker Challenges, glaube ich, oder Icebreaker Sessions vielmehr.

[16:37] Glaube ich, im Persönlichen, wenn du wirklich zusammensitzt an einem Tisch und du saßt am Abend, vielleicht nochmal, orderst du noch eine Pizza dazu, dann macht sich das noch ein bisschen mehr bezahlt oder keine Ahnung, man sitzt einfach nur beim Kaffee irgendwann tagsüber zusammen.
Ich glaube, das hilft halt so unglaublich viel, selbst wenn es nur dieser eine Tag ist, so in der Zusammenarbeit. Ja, wie gesagt, wir hatten das meiste Hiring während der Corona-Zeit und da war es halt für uns ganz klar.
Ich glaube, da gab es noch nicht mal Impfungen, da haben wir gesagt, das ist jetzt egal.
Und deswegen meinte ich auch, bei uns war es eben noch super nett mit den Icebreaker-Sessions, weil wir so wenig Personen waren. Aber wir alle kennen bestimmt immer noch das Problem, du kannst halt, du kannst ja nicht mal kurz flüstern in so einem Hangout.
Das passiert ja manchmal, das sind ja die Dinge, die dann echt passieren, dass eine Person kann jetzt was sagen und spricht laut und jeder hört zu, aber vielleicht willst du einmal kurz was flüstern zu einer anderen Person oder was zwischenzeitlich sagen und das funktioniert einfach mit den Videokamera-Tools nicht.
Klar, es gibt Lösungen, die versuchen, das zu machen und ich persönlich bin auch so ein bisschen Fan von diesen Tools, wo du vielleicht näher hingehen, also deinen Avatar näher hinschieben kannst und dann wird es lauter und es leiser oder du kannst da so Kreise bilden oder du kannst so eine Karte und kannst in Meetingräume gehen.
Das finde ich immer ganz nett, aber vielleicht kommt da bei mir auch so ein bisschen die Gamerin durch, weil nicht jeder ist der größte Fan von diesen Tools.

[18:05] Das mit der Pizza-Essen, klar, wir haben es dann auch mal eine Zeit versucht, hier Essen zu bestellen.
Für die Leute zu Hause, aber uns ist dann auch allen aufgefallen, so Essen vor der Kamera ist halt auch doof, so mit so einem Mikrofon, das haben wir dann auch ganz schnell wieder sein gelassen, weil da haben sich die meisten Leute dann doch ein bisschen awkward, also ich habe mich ein bisschen awkward gefühlt, wenn die von mir sprechen.
Kommen wir doch dann mal zu dem inhaltlichen Tag 1, ne?
Der Klassiker, du klingelst unten, jemand drückt dir auf, du läufst die Treppe hoch. Hallo, ich bin hier für den ersten Tag.
Ja, zu wem musst du denn? Ja, zu Vanessa. Cool, der sage ich direkt Bescheid.
Du kommst hin, holst die Person ab, nimmst sie mit. Hey, na, gute Anreise gehabt, wie ist das?
Setzen wir uns mal hin. Super, hier ist dein Laptop. Mal angenommen, das wäre schon alles eingerichtet. Wie geht es dann los?
Festplatte schon verschlüsseln und alles Mögliche.

[19:03] Los geht es mit so einer Art Kick-Off.
Das ist, finde ich, also das Kick-Off ist noch sehr offen gehalten.
Da gibt es noch nicht das Programm, sondern das ist genau dieses, ich glaube, was du gerade erst noch gesagt hast, ach, wie war denn die Anreise?
Und dass du erst mal einen Kaffee zusammen trinkt und hast du jetzt schon mal irgendwelche Gedanken, Fragen, Sorgen.
Und danach geht es meistens in da rein, das Produkt auch erstmal genauer anzuschauen, also ich arbeite ja immer mit Webseiten, das heißt, es ist dann immer recht einfach auf dem Laptop zu zeigen, da braucht man keine große Rundreise durch eine Fabrik zu machen, denn im Interviewprozess, Also geht zumindest bei uns natürlich auch immer so ein bisschen um das Produkt.
Wir fragen natürlich auch nach, wie interessiert jetzt sind die Personen an solchen Produkten, die wir da eigentlich bauen und haben sie da noch irgendwelche Ideen.
Aber was ich auch außer Zeigen gerne mache, ist auch zu fragen, willst du es einfach selber mal benutzen? Stell dir vor, du wärst User.

[20:05] Klick dich doch einfach mal durch und stell einfach alle Fragen, die dir so einfallen.
Was natürlich auch auf der anderen Seite eine unfassbar gute User Research an der Stelle ist.
Und dann ist es natürlich auch schön, wenn dann so ein bisschen die Augen das Funkeln anfangen und so sagen, ach, ich hätte die Idee, ich hätte die Idee.
Weil wir sind ja hoffentlich, versuchen wir zu sein, schon so eine nette Firma, bei der jede Person Einfluss haben kann.
Das heißt, wenn da eine Person sieht, ach, da bin ich jetzt drüber gestolpert, könnten wir da nicht was machen, dann funktioniert das normalerweise auch.

[20:36] Und davon abgesehen, bis auf dieses ganze große Produktdurchgehen, das passiert dann nicht mehr im ersten Meeting, sondern dann passiert wirklich nur noch die weitere Woche zu erklären.
Das heißt, dass ich dann drauf eingehe, also du pass auf, heute am Nachmittag wird dann dann Codebase und sowas aufgesetzt.
Dann hast du ein bisschen Freizeit, klick dich einfach durch die Dateien durch und hier sind die ganzen Readmes.
Und sobald man dann so ein bisschen die Readmes durchgelesen hat, dann trifft man sich meistens noch direkt am nächsten Tag in der Früh für eine gewisse Zeit um, jetzt ist zwar schon der Localhost zum Beispiel aufgesetzt, aber nochmal zusammen, um Codebases durchzugehen.
Die war am Anfang noch sehr klein, da konnte man quasi am Anfang noch durch alles durchgehen. Jetzt funktioniert es nicht mehr.
Das heißt, jetzt gibt es quasi so einen Grobüberblick über die Architektur.
Es gibt ein weiteres Meeting über die technischen Prozesse.
Mit technischen Prozessen meine ich, wie benutzen wir eigentlich Git?
Also erstmal, was haben wir?
Haben wir GitHub? Haben wir GitLab? Haben wir sonst was?
Machen wir Feature-Branches? Machen wir Epic-Branches? Machen wir Conventional-Commits?
Wie läuft es ab, wenn man deployen will? Wer kann deployen? Wie funktionieren die Pipelines?

[21:51] Etcetera.
Und an letzter Stelle, das macht dann aber nicht mehr ich, gibt es dann die Meetings noch, welches Projekt gibt es überhaupt?
Was kann man da dann als erstes Mal machen?
Und ich glaube, das letzte Wichtige, vielleicht sogar das Deswichtigste für die ersten paar Tage, ist dann auch noch, was sind jetzt eigentlich unsere gegensätzlichen Erwartungen?
Was braucht die Person von uns gerade in der ersten Zeit? Was brauchen wir von der Person in der ersten Zeit?

[22:24] Wie viel wird da quasi Händchen gehalten oder wie viel wird dann gesagt, hier ist dein Projekt, schau mal, wie du zurechtkommst.
Also wie die Person halt dem dann auch besser arbeiten kann.
Und was man dann glaube ich, in der ersten Woche, sage ich auch immer so, mache ich auch schon mal die Termine für One-on-Ones, die dann in der ersten Zeit wöchentlich sind oder vielleicht später, naja gut, in der ersten Zeit wirklich wöchentlich.
Und das ist natürlich das das große Mid-Off-Probation-Meeting geben wird, also die Halbzeit der Probezeit.
Weil ich finde es ja immer furchtbar, was ich teilweise... Da kommen wir ja noch hin.
Ja, aber ich finde es trotzdem ganz kurz, ich finde es immer furchtbar, wenn ich schon von Leuten höre, Geschichten, dass irgendjemand so kurz vor knapp bei der Probezeit dann doch noch entlassen wurde mit dieser zwei Wochen Entlassungszeit, wo ich mir dachte, ja, aber das waren sechs Monate Zeit.
Da muss man doch der Person mal die Chance geben, zu sagen, du, wir haben hier folgendes Feedback an dich und meinst du, das geht auch so?
Dafür hat man doch, naja, egal.
Aber ich fand es erschreckend, dass ich solche Geschichten wirklich häufiger gehört habe, dass man anscheinend so überraschenderweise nicht übernommen wurde.

[23:35] Ja, keine Ahnung. Meistens sind das ja dann irgendwie andere Gründe.
Also es hört sich jetzt so an, als hätte die Person auch nicht unbedingt mal nach Feedback gefragt, wenn man so zwei Wochen vorher da ankommt.
Also ich habe das selber noch nicht erlebt, Aber das ist ja schon ein sehr ungewöhnlicher Fall. Ich finde es auch gut.
Also entweder, also da muss ja irgendwie was gehörig schieflaufen bei der Firma und naja, egal.
Gut, erster Tag bei euch, was geht ab?
Erster Tag bei uns, ja. Kaffee, Lunch. Das ist von Team zu Team unterschiedlich, muss man ehrlich sagen.
Also was ich halt festgestellt habe, ist also, was ich versuche, und das wird immer schwieriger, Also gerade jetzt auch mit diesen komplexen Strukturen, dass man halt irgendwie alle Zugänge und alles Mögliche hat, weil es dann doch immer einige Stakeholder gibt, die da irgendwie Freigaben erteilen müssen, bis man alles zusammen hat.

[24:29] Früher hatte ich immer so diesen Wunsch die Person kann am ersten Tag irgendwas shippen, irgendwas in Production bringen und einen wichtigen Punkt, den du gesagt hast, ist dieses du hast irgendwann gesagt in dem Ablauf und das macht dann nicht mehr ich und das ist mir immer persönlich gerade auch wenn es um Team Onboarding ging, sehr wichtig gewesen wenn es ums Produkt geht.

[24:53] Dann kann das ja am besten die Person erklären, die fürs Produkt verantwortlich ist, sagen wir PO oder so. Ja, ja, klar.
Genau. Und das finde ich einfach so wichtig, weil so Arbeit besteht ja im Endeffekt auch daraus, ganz viel Kommunikation mit anderen Personen und Connections mit anderen Personen aufzubauen.
Weshalb ich das auch immer wichtig finde, dass Personen, die halt neu anfangen, viele neue Leute kennenlernen am ersten Tag, in den ersten Wochen.
Du hast eben schon gesagt, ihr habt da so One-on-Ones, die automatisiert aufgesetzt werden, Coffee-Talks zwischen den Mitarbeitern und Mitarbeitern und den Neuankömmlingen, das finde ich halt super cool, weil ich glaube, das ist halt ganz wichtig, diese Relationships aufzubauen, gerade wenn du in ein neues Team, in eine neue Organisation kommst, dass du halt als Mitarbeiterinnen und Mitarbeiter halt möglichst viele Leute kennenlernst, mit denen du Kontakte knüpfen kannst, die später dir auch bei irgendwas helfen.
Und gerade wenn, sagen wir mal, bei uns gibt es ja eine gewisse Größe.

[25:53] Wir hatten mal eine Zeit lang, da haben wir halt so eine Virtual Coffee Round gehabt, wo halt so ein System halt alle zwei Wochen dir jemand neuen zugelost hat, den du dann halt einfach mal kennengelernt hast, auch wenn du schon im Unternehmen warst.
Und das fand ich halt super hilfreich, um ein bisschen zu verstehen, auch was passiert links und rechts in der Firma. Und das sind halt auch so inhaltlich Themen, die ich halt super wichtig finde.
Also bei uns jetzt ProSiebenSatz1 ist ja eine etwas größere Company, wo man auf jeden Fall halt auch andere Bereiche hat, die halt komplett fachfremd von dem digitalen Bereich sind, den wir halt haben.
Da einfach mal einen grundsätzlichen Überblick zu bekommen, wie die Firma so tickt.
Solche Themen waren halt auch auf jeden Fall immer Bestandteil der ersten Woche.

[26:42] Jetzt ist es kürzlich so gewesen, ich habe ein paar neue Teamleads sozusagen, die halt jetzt mit denen ich dann direkt zusammenarbeite bekommen und gerade da war halt für mich wichtig, diese Erwartungshaltung, die du auch angesprochen hast, Vanessa, die halt sehr, sehr früh zu klären, halt zu sagen, okay, zum einen, was ist denn eure Erwartungshaltung jetzt an mich als Leader und auf der anderen Seite, Was ist aber auch meine Erwartungshaltung an den Mitarbeiter, die Mitarbeiterin, die ja auch jetzt einen neuen sozusagen Counterpart irgendwie haben, mit dem sie kommunizieren hauptsächlich.
Und das ist mir halt sehr, sehr wichtig, da sehr klare Erwartungen zu haben.
Was ich mittlerweile habe, ist da klar so eine Art, also Framework, wie ich das halt mache, Präsentationen, die ready sind und so, die man dann halt runterspulen kann, den Leuten geben kann und dann können die sich da auch im Nachgang nochmal einlesen in die Theorie oder so.
Und das finde ich halt persönlich ganz, ganz wichtig.
Du hast vorhin dieses angesprochen mit dem Thema, welche Values sind denn eigentlich das, woran wir uns orientieren wollen, wahrscheinlich noch darüber hinaus, welche Arbeitsweisen, also Ways of Working haben wir denn eigentlich, wenn du sagst sowas wie, ja, Pünktlichkeit ist mir wichtig oder sowas.

[28:04] Wie bekommt ihr das hin, dass halt die Leute verstehen, wie ihr als Team sozusagen untereinander tickt?
Also genau dieses Ways of Working.
Wie kriegt man das an die Leute schnellstmöglichst herangetragen?
Was habt ihr da für Methoden?
Ich finde, das sind jetzt eigentlich zwei super spannende Sachen.
Du hast auch gerade gesagt, dass man alle Leute kennenlernt.
Weil ich glaube auch, es ist erstmal extrem wichtig.

[28:33] Es gibt ja die zwei Kategorien von Menschen dann in einer Firma.
Die einen, mit denen man die ganze Zeit quasi was zu tun hat und die anderen, die man so gut eigentlich kaum sieht, gerade vor allem, wenn man remote arbeitet, so vielleicht mal im All-Hands-Meeting.
Und ich finde beide Gruppen auch am Anfang kennenzulernen.

[28:52] Beides wichtig, denn die, die ich sonst nicht sehe, sehe ich vielleicht, da komme ich vielleicht nie mit denen in Gespräch, während die, mit denen ich täglich arbeite, vielleicht schon mal bei so einem Daily erstmal so ein bisschen Smalltalk mache, aber ich habe immer wieder beobachtet, dass wenn es am Anfang dieses Kennenlernen zwischen den Leuten nicht gab, dass es später den Leuten so ein bisschen schwerer viel so wie, wir sollen jetzt hier so ein Kennenlerntreffen machen, wir arbeiten doch seit drei, zwei Monaten zusammen, ich kenne die Person doch.
Und dann stellt man fest, dass man sich überhaupt nicht kennt und es geht jetzt nicht um irgendwie private Sachen, Geburtstage oder keine Ahnung, Familienstand oder sonst was, sondern wirklich genau diese Werte.
Und um zu deiner Frage zurückzukommen, ich, wie gesagt, ich habe da so einen Zettel, man kann das jetzt in mir rummachen, Man kann das jetzt in der Präsentation machen, man kann das mit Pen & Paper machen, das spielt jetzt für mich gar nicht so die größte Rolle, aber dass die Personen sich da jetzt diese drei Werte raussuchen und dann auch danach darüber reden, warum das jetzt vielleicht für eine Person wichtig ist.
Also warum könnte es für mich sein, dass Pünktlichkeit wichtig ist, weil es für mich halt so eine Art Respekt zum Beispiel ist und wenn jetzt bei mir jemand so spät kommt, dann finde ich das ein bisschen halt einfach respektlos zum Beispiel meiner Zeit gegenüber.

[30:14] Und dann gibt es ja noch, ich finde es jetzt selber ein bisschen schwierig, wie...

[30:24] Ja, wie cringe, ich glaube, das ist das beste Wort, wie cringe diese Fragen sein dürfen, da ich natürlich auch weiß, dass das nicht jede Person mag und ich bin da auch immer so ein bisschen zwiegespalten drüber und ich möchte auch nicht, dass die Fragen jetzt super tief gehen oder sowas, weil da gibt es ja auch, es gibt ja auch so Fragen im Sinne von, hey, was ist dein größter Tick?
Und es gibt da Leute, die haben dann was Witziges darüber zu sagen.

[30:52] Ich habe nichts Wichtiges darüber zu sagen. Doch, ich habe jetzt eine Antwort, die kann ich dann immer sagen, aber das gibt mir fast schon, das könnte ein bisschen zu viel spontan sein.
Aber du, ansonsten einfach das Meeting und die Runde und man geht da im Kreis rum und bespricht es dann und dann, wenn du die richtigen Leute in deinem Team hast, dann kommt ja immer ein nettes Gespräch zusammen.
Mit richtigen Leuten zusammen mit dem Thema eigentlich übrigens nicht, dass alle gleich sind und sich deswegen verstehen, sondern viel spannender ist es immer, wenn sowieso immer alle, wenn das Team ein bisschen breiter gestreut ist und vielleicht andere Ansichten vertritt und dann finde ich es immer total nett, wenn dann so diese Situation entsteht, dass zwei komplett unterschiedliche Ansichten sich dann gegenseitig erklären können, warum man jetzt andere Ansichten über ein Thema hat.
Zum Beispiel, ja, aber ich bin zu spät gekommen, weil ich musste hier noch was total Wichtiges klären und da konnten wir dann total schnell bei einem anderen Projekt weiterkommen.
Zu der Gegenseite der guten deutschen Pünktlichkeit.
Hast du schon mal erlebt, dass du jemanden am ersten Tag am Start hattest, den du interviewt hast und auf einmal war die Person ganz, ganz anders, als du dachtest?
Puh, interessant. Nicht am ersten Tag.

[32:05] Aber es war eher so, nicht ganz anders, sondern es war eher so, dass da Kleinigkeiten waren, die mir vielleicht so ein bisschen unterbewusst aufgefallen ist, die ich aber nicht ernst genommen habe, mir dann aber später so ganz stark aufgefallen sind, dass es diese Personen zum Beispiel total wichtig sind.
Und da hatte ich auch mit einer Person mal von uns ein längeres Gespräch drüber, inwiefern kann man sich halt jetzt für eine Firma anpassen, wenn man merkt, okay, das läuft jetzt so ein bisschen anders, als ich das machen würde, aber hat jetzt nicht so viel Einfluss auf mich und deswegen gehe ich da jetzt einfach mit.
Oder gibt es eine Sache, die wirklich so gegen den Glauben dieser Person quasi verstößt und dann hat man da immer so ein bisschen Reibungsfläche.
Ich habe jetzt leider kein gutes Beispiel.

[33:03] Ja, müssen ja auch kein Beispiel explizit nennen.
Ich glaube, die Frage ist halt wirklich, wie geht man mit sowas um und wie gut kann man das in einem Team auch auffangen, wenn halt die Voraussetzungen unterschiedlich sind.
Also wenn man andere Erwartungshaltungen zum Beispiel hat.
Aber genau dafür ist ja auch dann im Endeffekt die Probezeit da.
Da hast du ja eben schon was zu gesagt.
Wie macht ihr das denn mit so Check-ins?
Also am Anfang werden Erwartungshaltungen gezeigt, aber wie oft gibt es dann quasi jetzt nicht einen Check-in?
Moment, ich komme gleich auf das Wort. Es gibt ja so One-on-Ones, da sagt man, okay, und heute sprechen wir über Performance.
Und es gibt ja so One-on-Ones wie, ach, hier ist heute einfach nur ist dein Space zum Miteinander sprechen.
Also wie oft habt ihr jetzt eher die für heute sprechen wir nach drei Monaten und dann machen wir mal so ein Performance Review oder sowas ähnliches?
Ja, also genau, es ist auch ähnlich, wie du sagtest, so Halbzeit zur Probezeit ist das eigentlich der Fall, dass man mal darüber spricht.
Natürlich gibt es grundsätzlich die One-on-Ones, aber das ist halt jedem selbst überlassen, jedem Leader sozusagen, wie man das dann auch handhabt.

[34:18] Und genau, es gibt bei uns halt so einen halbjährlichen Performance-Review-Prozess.
Und für Neuankömmlinge ist es halt wirklich das erste Mal nach den drei Monaten der In-der-Probe-Zeit zu sagen, okay, wo stehen wir denn?
Also da gibt es dann auch einen offiziellen Prozess zu, mit einem kleinen Dokument, was man dazu anfertigt und so.
Und da halt auch klar drüber spricht.
Ich bin aber persönlich jemand, ich spreche eigentlich Dinge direkt an, also gerade bei Leuten, die halt neu sind, bin ich immer sehr schnell vorne dabei zu sagen, hey, guck mal, das ist ja mega cool, dass du das so machst.
Oder auch, wenn ich mal das Gefühl habe, hey, da läuft was vielleicht nicht ideal.
Keine Ahnung, das ist, meistens habe ich festgestellt, ist das das Thema Kommunikation, wenn Dinge halt auf der Strecke bleiben oder so, dass man da dann einfach sagt, hey, pass auf, guck mal, das hier wäre meine Erwartungshaltung oder das habe ich gesehen, meine Erwartungshaltung wäre so, also uns doch bitte versuchen, so zu organisieren.

[35:23] Und in den allermeisten Fällen, also ich habe das selten erlebt, dass Leute sagen, nö, finde ich total unangebracht, was du sagst, sondern eher, jo, stimmt.
Ja, ich versuche mal dran zu denken oder im Idealfall halt auch und weise mich drauf hin, wenn ich es nochmal mache, dann kann ich schneller agieren oder so. Ja.
Ja, aber kommt natürlich immer auf die Leute drauf an. Was du gerade gesagt hast mit dem positiven Feedback, das ist natürlich großartig, Weil wenn man so gar kein Feedback bekommt, aber auch alle zufrieden sind, ist es, glaube ich, auch sehr komisch. Und...

[35:57] Es kann ja auch sein, dass man davor bei einer Firma war und die hatten halt zum Beispiel andere Werte in der ganzen Firma und da war, keine Ahnung, da war sehr schnell shippen sehr wichtig und wenn was kaputt geht, dann kann man es vielleicht wieder fixen.
Und bei einer anderen Firma ist das vielleicht ganz, ganz furchtbar und das muss alles sehr korrekt an die User rausgehen.
Und sowas kann man ja nicht lernen, sowas kann man ja vorher nicht wissen.
Da hilft es nichts, wenn man die besten Algorithmen der Welt schreiben kann.
Ich muss erst lernen, was möchte die Firma von mir.
Das heißt, es ist natürlich auch die Aufgabe von den Leadern dann, das auch weiterzugeben und nicht zu erwarten, dass Leute sowas einfach out of the box wissen könnten, was jetzt hier eben die wichtigen Werte sind. sind.
Und ich fand das auch klar, also bei Seniors geht es jetzt vielleicht noch, aber gerade so eher bei Berufseinsteigern fand ich das schon immer ganz merkwürdig, wenn man dann sofort ins Daily geht und dann, ja, und ihr spricht mal.
Und ich so, ja, aber wie ist denn euer Daily-Prozess? Also ich weiß, wir sagen in alles, wir machen ja alle in Anführungsstrichen Scrum, aber entschuldige, wir machen alle andere Dailies.
Worüber reden wir heute hier? Schauen wir aus Bord? Schauen wir nicht aus Bord?
Haben wir Daily in Daily?
Genau, also ich finde es super schön und für mich ist auch immer wichtig, dass man die Leute darauf vorbereitet, auch wie diese Prozesse dann ablaufen und eben auch, wie kommuniziert wird.

[37:19] Glücklicherweise glaube ich, dass viele, viele Firmen immer auch sehr offen sind und sich fast immer mehr Fragen erhoffen von den Leuten als weniger.
Das heißt auch dieses typische, es gibt keine dummen Fragen, es gibt keine dummen Fragen, es gibt keine dummen Fragen, bitte frag, bitte frag, bitte frag, bitte frag.
Bei uns kann es vielleicht tatsächlich manchmal die Problematik aufkommen, wie gesagt, wir sind nicht so viele Leute.

[37:43] Und das heißt, wir haben zu allen Hierarchien, also zu allen sogenannten flachen Hierarchien, haben wir zu allen Kontakt.
Aber natürlich war es für mich auch manchmal komisch, wenn ich jetzt zu den Gründern gehe und das und das und das anbringe, weil man irgendwie ja doch so eine Art Hierarchie dabei hat.
Und deswegen ermuntern wir da eben erst recht so, ja, ist CEO, aber ist alles auf einer Augenhöhe und bitte besprich alle deine Sorgen mit den Personen.
Ich glaube, das kommt ja dann ganz stark darauf an, auch wie das gelebt wird.
Also auch wenn man halt sieht, so Role Models, die das dann halt praktizieren, wenn man halt sieht, diese Leute sprechen halt auch mal und das sieht man leider dann im Digitalen oder in der Remote-Arbeit halt nicht ganz so aktiv.
Da muss man das ein bisschen anders fördern.
Die sprechen mal ein Thema an oder man spricht direkt halt oder es gibt keine Probleme, wenn man auch mal eine Kritik äußert über Hierarchiestufen hinweg sozusagen.
Wenn man das halt sieht, ich glaube, dann fällt es einem als Newcomer halt auch einfacher zu sagen, okay, ich mache das vielleicht zu einer gewissen Zeit dann auch mal.
Ich meine, das ist ja auch immer so aus der Rolle der Leute, die neu kommen.
Da gibt es ja auch so eine Art Zeitraum, den man sich vielleicht auch gönnen sollte, bis man eine Beurteilung der Themen vornimmt, weil man ja doch sonst auch Leuten auf die Füße treten kann.
Aber ich möchte noch auf ein anderes Thema hinaus, nämlich das Thema Dokumentation.

[39:11] Manche Menschen sind ja, jetzt hast du viel drüber gesprochen, man spricht viel miteinander und so.
Manche Menschen sind ja auch vielleicht eher individuelle Lerner und sagen, okay, ich möchte das alles eher lesen, anstatt halt erzählt zu bekommen.
Hast du das schon mal erlebt? Macht ihr viel Dokumentation so zu den ganzen Prozessen?
Habt ihr das alles in eurem Miki stehen? Wie geht ihr damit um?
Gut, dass du das jetzt fragst, weil wir tatsächlich jetzt nur über Kommunikation gesprochen haben.
Das bedeutet nicht, dass wir jetzt hier sechs, acht Stunden Meetings pro Tag haben.
Es ist mir nur sehr wichtig, dass man sehr wichtige Meetings hat, um über die Kommunikation zu sprechen.

[39:51] Dennoch, nicht, dass jetzt jemand hier Sorgen hat. Es gibt sehr viel, ich nenne es jetzt mal Freizeit, um wirklich die Codebase zu lernen und auch wirklich damit rumzuspielen.
Und wir waren immer ganz stolz drauf, dass wenn jemand zu uns gekommen sind, wenn wir positives Feedback für die Readmes und etc. bekommen haben.
Das war dann auch immer so, du hast es gerade vorher noch gesagt, mit vielleicht am ersten Tag gleich was shippen zu können.
Es gibt immer so ein, zwei Sachen, die vielleicht in der Readme dann so ein bisschen outdated waren oder noch nicht mit drin waren und dann gibt es immer den Task, voll gut, dass dir das jetzt aufgefallen ist, komm, wir müssen noch, keine Ahnung, den Docker-Container zusätzlich aufsetzen oder sowas.
Wir machen das zusammen.
Hast du danach nicht gleich Lust, dass du einen neuen Branch erzeugst, fügst diese Zeile in die Readme rein, dann schau, dann machen wir schon mal einen Deployment-Prozess durch. Dann erstellst du da einen Commit.
Hier steht drin, wenn man hier die Commits erzeugt.
Schau einfach mal, ob du zurechtkommst. Wenn du Fragen hast, dann komm gerne wieder auf einen zu.
Aber na klar, Developer sind, wenn man jetzt mal Mob-Programming außen vor lässt, sitzen sitzen wir bei der tatsächlichen Arbeit alleine vorm Laptop und coden vor uns hin.
Ich finde es jetzt persönlich super nett, eigentlich, wenn mir sowas jemand vorkaut.
Aber natürlich ist es bei einer Codebase ab schon einer kleinen Größe irgendwann nicht mehr möglich.

[41:11] Möglich, sondern da brauche ich die Möglichkeit, dass ich jetzt alleine durch die Dokumentation durchgehe und schaue, ob ich mich auch wirklich im Code zurechtfinde.
Denn was es ja bei jeder Codebase geben wird, ist sehr viel implizites Wissen.
Ich kann jetzt vielleicht nach einigen Jahren perfekten View-Code schreiben, aber wenn ich jetzt in eine Firma komme, dann weiß ich nicht, ob die View 2 oder View 3, oder vielleicht weiß ich es schon, aber diese Firma könnte View 2 oder View 3 haben, die könnte auf Microfronted setzen oder auch nicht.
Die könnte Feature-Branches haben oder die könnte andere Deployment-Prozesse haben.
Und vor allem gibt es dort meistens doch sowas wie, ah, ist ja klar, immer wenn so ein Fehler, immer wenn so ein Special Case auftritt, beim Loading-State machen wir immer das.
Beim Error-State, da machen wir immer was und dann Toast.
Das steht, das habe ich ja nicht durch Coding gelernt, sondern das ist implizites Knowledge bei der Codebase oder es gibt doch immer so ein paar Sachen, das weiß bestimmt jeder, wovon ich jetzt sprechen werde, da gibt es so eine Art Bug.

[42:13] Und wenn man schon lange in der Firma dabei ist, dann, du, ich habe da eine Idee.
Da gibt es da hinten, da gibt es so eine Datei und ich habe da so eine Idee, da gibt es eine Connection. Das kann man nicht wissen, wenn man den ersten Tag hat.
Das heißt, man kann einen Bug bekommen. Jemand, der ganz neu ist, sagt, was ist denn hier los? und jemand, der zehn Jahre dabei ist, die Person sagt, ah ja, hab eine Idee, ich mach das in fünf Sekunden.
Auf der anderen Seite ganz kurz, also vielleicht zu manchen Sachen so wie Error-States, wie stellen wir den dar?
Das ist ja auch, sag mal, ein Produktwissen im Endeffekt.
Wie macht man das? Und gerade sowas, denke ich, ist halt schon super wichtig zu dokumentieren.
Also man hat ja einen Backlog, aber es gibt Entscheidungen wie zum Beispiel Error-States zum Beispiel oder keine Ahnung, Designsystem, wenn man sowas hat oder ein implizites Designsystem.
Wichtige Produktentscheidungen. Warum ist das Produkt so, wie es ist?
Ich finde, sowas zu dokumentieren ist halt schon auch sehr, sehr cool, wenn man das halt als.

[43:15] Benutzer oder Neuentwickler bekommt, weil man dann halt, Darauf aufbauend halt sich selber auch dieses Wissen, von dem du gerade gesprochen hast, irgendwie aufbauen kann mit der Zeit. Ich wollte dir noch kurz ein paar konkrete Beispiele nennen, nachdem ich jetzt so einen Redefluss hatte.
Wir haben zwei große Readmes. Die eine Readme ist wirklich, wie setze ich die ganze Codebase auf, wie mache ich das mit den Datenbanken etc.
Und dann gibt es die Frontend-spezifische Readme, wo auch tatsächlich drinsteht, welche IDI verwenden wir normalerweise, also welche können wir supporten, bei welcher können wir nicht helfen, welche Extensions benutzen wir, jetzt wenn es ans ES-Linting geht oder ans Prettier, wie sind die Sachen auf aufgesetzt.
Weil wir zum Beispiel davon ausgehen, dass die Devs selber Prettier installiert haben, damit sich halt beim Speichern das richtig formatiert.
Welche Chrome- oder welche Browser-Extensions wir üblicherweise nutzen zum Debuggen.

[44:13] Und das sind jetzt quasi doch eher rein die technischen Sachen, die jetzt nicht so viel mit der Architektur dann zu tun haben.
Und dann haben wir in der Readme auch erklärt, generell aber, wie testen wir hier? Und was testen wir?
Und wie sind unsere Folder aufgebaut?
Und dann gibt es spezielle Folder, wo einfach wichtigere Code-Stücke drin sind als woanders.
Und die kommen oft noch mit einer eigenen Readme. So, das ist jetzt unser Modul, um Formulare aufzustellen.
Und wir haben zum Beispiel, keine Ahnung, ich glaube, wir haben so zwölf verschiedene Combo-Boxen, solche Selectors mit Icon und ohne Icon und mit Avatar und ohne Avatar und Multi-Select und nämlich nicht Multi-Select und die haben wir da auch, weil wir da jetzt kein Storybook oder sowas dazu haben, mal aufgedröselt.

[45:01] Und was ich dann ganz hilfreich fand, sind noch Video-Recordings, die können natürlich auch outdated werden, ist ja klar, wie jeder andere gibt mir auch und Videorecordings sind dann vielleicht schwerer abzudaten, als mal kurz zwei Paragraphen zu ändern.
Aber über die wirklich langfristigen Sachen, wo ich auch weiß, die ändern sich ja nicht mehr so schnell, gibt es dann auch einfach da so ein paar Loom-Videos verlinkt, damit, ach, Entschuldigung, Werbung, ähm, paar Videos verlinkt, weil ich ja sonst auch vergesse, was es eigentlich alles zu erklären gibt nach geringer Zeit.
Und worauf ich mega stolz war jetzt letztens, ist tatsächlich unser CTO hat mal gesagt, komm, ihr schaut sie jetzt auch mal so frontend an.
Er war aus verschiedenen Gründen, aber er macht da mal was.
Und dann, was uns halt immer wichtig war, weil wir werden ja ältere Developer, hat den Code generell wirklich also der Code muss lesbar sein und der Code muss einfacher sein.
Wir versichten vielleicht sogar manchmal auf komplexere Features, die wir vielleicht einfach nicht gut umsetzen könnten, sondern wird dann Spaghetti-Code wert.
Dann sagen wir, können wir nicht deliveren, wir brauchen halt eine maintainbare Codebase.
Da war ich ganz stolz drauf, dass er dann gemeint hat, ach, ich hab das schon verstanden, wie ihr das so macht.
Ich habe das mal so nachgebaut und anscheinend ist es verständlich.
Und hat der CEO dann auch Code-Back-Contributed zur Codebase? Der CTO in dem Fall.
Oder wollte er es einfach nur mal verstehen? Nee, nee, hat ein Frontend-Feature gebaut.

[46:27] Wie kam das an? Bei Usern oder bei mir?
Ja, bei den Mitarbeitern und Mitarbeitern. Ja gut, wieso siehst du jetzt da jetzt große Probleme?

[46:40] Ich bin einfach gespannt, so wie das ankommt.
Also, keine Ahnung, wenn ich jetzt irgendwie anfangen würde.
Ach, meinst du, weil da jemand in unserem Code rumwurschtelt oder so?
Also, ich gehe mal von mir aus. Wenn ich jetzt anfangen würde, im Web, sagen wir mal, im Webteam, mal einen Pull-Request aufzumachen und da irgendwelche Sachen drin reingeschrieben hätte, die ich gut fände und wo ich glaube, das könnte gut funktionieren.

[47:09] Dann könnte das ein bisschen problematisch werden, weil auf einmal kommt da irgend so ein Manager, der jetzt meint, er wüsste, wie die Sachen zu laufen haben, hat aber keine Ahnung und jetzt soll ich als Mitarbeiterin und Mitarbeiter dem auch noch einen fairen Pull-Review geben, wo die Person ja gar nicht weiß, wie wir Code schreiben, weil die das ja nicht tagtäglich macht, anders als die Mitarbeiterinnen und Mitarbeiter.
Und das kann natürlich einen negativen Impact haben und die Leute haben Angst, okay, vielleicht, also was heißt Angst, aber kann halt dazu führen, dass sie halt irgendwie denken so, ja, ich gebe den lieber mal frei, bevor das irgendwie negativ auf mich zurückfällt oder so.
Oder kann ich den jetzt... Ich weiß komplett, was du meinst und natürlich muss das in dem Team so funktionieren und genau das war der Punkt, den ich vorher angesprochen hatte mit, dann sprichst du halt plötzlich mal mit einem C-Level und musst da vielleicht Contra geben, aber wir kennen uns natürlich auch schon einen Ticken länger und wir fanden das alle gut und wir fanden das alle total nett und wir haben uns dann über das Feedback gefreut, dass man anscheinend schnell in diese Fraud von den Codebase reinkam und da Reviews zu machen.

[48:21] War jetzt auch kein Problem.
Wir fanden es auch, also ich fand es jetzt eher vielleicht ist es auch logisch, ich weiß es nicht, mir ist aufgefallen, dass so JavaScript und auch TypeScript hat soweit alles gepasst.
Da musste ich eher anmerken, so nach dem Motto, wir machen das normalerweise ein bisschen anders.
So wäre jetzt technisch schon korrekt, aber so ein bisschen nitpicking, wir machen das anders.
HTML und CSS, da war dann eher so du, ich ich ändere mal.

[48:49] Okay, aber nochmal zurück zum Thema Onboarding. Jetzt ist der erste Tag rum, die haben die Dokumentation gesehen.
Ich wollte noch kurz sagen, ein Learning, was ich hatte in den vergangenen Jahren, wir haben jetzt zwar beide viel erzählt, was man ja alles so beibringen könnte, ist aber, dass man nicht zu viel macht.
Vielleicht ist es auch logisch für die allermeisten, aber für mich war es so, nicht zu viel erklären an den ersten Tagen, weil die Leute können das nicht aufnehmen und die vergessen das.
Und das hatte ich so häufig irgendwie als Feedback. Wir haben dann irgendwie sieben Sessions geplant über die ersten drei Tage. Und dann haben die Leute alles irgendwie aufnehmen müssen und so und kamen dann wieder so, wenn man gefragt hat, ja und wie war es jetzt so, erste Woche Onboarding?
Ja, war schon sau viel Infos, so ich weiß auch gar nicht mehr, ob ich noch alles weiß.
Also lieber Piano, lieber ein paar Sessions vielleicht hinten raus, ist so mein Learning gewesen auf jeden Fall.
Ich wollte aber eigentlich sagen, nämlich wenn diese ersten Tage vorbei sind, kommt ja immer wieder viel auf und manchmal verfolgt man ja so ein Konzept, dass man eine Person hat, die so der Ansprechpartner, die Ansprechpartnerin ist, so Art Buddy, Slash, Mentor, wie auch immer.
Hast du mit sowas schon mal Erfahrungen gesammelt? Wie lief das?

[50:03] Ja, ich habe Erfahrungen gesammelt, persönlich und auch, wie gesagt, viele Erzählungen, weil ja, wir haben halt auch das Buddy-Programm bei uns mit drin.
Ich habe glücklicherweise sehr viele positive Sachen gehört, aber ich habe auch negative Sachen gehört und ich würde jetzt mal sagen, wir gehen jetzt einfach mal taff rein und reden mal über die negativen Sachen. Ich habe von...
Das war bei mir selber, glaube ich, mal so, dass die Firma ein Buddy-Programm hatte, aber man hat halt irgendwie vergessen, dir das zuzuweisen.
Und dann steht man so da und will ja nicht jetzt jammern so, ich dachte, hier gibt es Buddys und ich habe keinen Buddy.
Und dann traut man sich da eben, dann habe ich mich halt nicht getraut, was zu sagen.
Und dann kam irgendwann das Feedback, ja, warum hast du nichts gesagt?
Ich so, da weiß ich nicht, ich habe noch nie was von Buddys gehört.

[50:49] Und dann so, ah, dann ist die Person jetzt dein Buddy.
Wo ich mir gedacht habe, okay, das wird jetzt nicht so ernst genommen.
Das klang so, weißt du, wie es für mich klang? Das klang so nach, wir haben online bei HR-Blogs oder People-and-Culture-Blogs gelesen, dass man so Buddies haben sollte, klingt gut, aber wir glauben nicht dran, deswegen, du bist jetzt mal Buddy.
Und dann finde ich schon auch, dass man mal kurz erklären könnte, könnte, was bedeutet denn jetzt Buddy da sein in dieser Firma?
Weil ein Buddy wird ja auch oft gern genommen aus einem ganz anderen Gewerk, eben um diese Zwischenbeziehungen herzustellen und so eher so, ja, wenn du wissen willst, wie es die Kaffeemaschine zu benutzen gibt.
Jetzt versteht man aber sehr schnell, wie man so eine Kaffeemaschine benutzt und so.
Und jetzt? Hat Buddy noch mehr zu tun oder nicht? Das heißt, es waren die Erwartungen oft nicht wirklich klar für den Buddy und für den Buddyisten, also für den den Gebudditen. Genau.

[51:47] Und dann finde ich das nämlich teilweise eher vielleicht hätten wir es dann doch gleich sein lassen können.
Andere negative Beispiele sind natürlich, wenn die Buddy-Person sogar keine Lust darauf hat.
Und das ist natürlich ein bisschen schwierig, weil ich meine, es kann auch Leute geben, die haben keine Lust Code-Revies zu machen, aber dann sind sie vielleicht keine guten Mitarbeiter.
Aber kannst du das genauso bewerten?
Deine Person hat jetzt keine Lust darauf, auf Buddy zu sein. Nein.
Kann man dafür jetzt dann schlechtes Feedback geben oder sagt man, ja gut, auch egal?
Muss man sich halt in der Firma, ich will jetzt gar nicht meine Meinung da kundtun, aber das sollte man halt sich vielleicht dann drüber überlegen und nicht einfach nur Personen zum Buddy ernennen, die dann vielleicht mit ihrer Rolle nicht funktionieren.

[52:29] Die gar keine Lust drauf haben, weil dann hat nämlich die Person, die Buddy der Person auch gar nichts davon.
Mentor generell sollten ja meistens sowieso dann die Seniors des Teams sein, sowieso die Lead-Person des Teams.
Aber genau das Positive am Buddy-Programm, ja, wie ich gerade schon gesagt habe, es hilft dir dann halt wirklich auch in.

[52:56] Gerade auch in den Remote-Zeiten, dass du jetzt nicht nur im Dev-Design vielleicht Produktteam so ein bisschen versinkst, sondern vielleicht auch wirklich ein Buddy im Sales, Customer Support, Marketing und sowas hast und da auch mit reinschnuppern darfst.
Ich finde es immer super nett, auch wenn man so mal einen halben Tag jemand, klar, halben Tag, ich weiß, wer hat dafür schon Zeit.
Ich finde es aber super spannend, immer mal einen halben Tag jemand anders zu beobachten, was die da eigentlich so machen.
Also kann ich auch total empfehlen. Also bei uns gibt es das auch, kann man auch so mit in die Studios gehen oder sich den Live-Betrieb angucken.
Und Rewe zum Beispiel, das weiß ich noch, da war das damals so, die haben, also da hatte ich mal für den Lieferdienst gearbeitet und für die Festangestellten haben die das so gemacht, dass du beim Lieferdienst einfach einen Tag mal mitfahren konntest und einfach so praktisch einen Praktikumstag gemacht hast und mit ausgeliefert hast.
Damit du mal siehst, was machen die Leute da eigentlich.

[53:51] Oder Markttag gibt es da halt auch für die Leute, die halt eher im Markt mit marktspezifischen Sachen zusammenarbeiten. Dann bist du einen Tag im Markt und betreibst diesen Markt mit.
Ich kann mir vorstellen, dass es Leute gibt, die das trotzdem gar nicht mögen.
Also falls jetzt jemand von den Hörerinnen und Hörern bereit ist, auch dazu uns Bescheid zu sagen, mich würde es interessieren.
Weil ich glaube, ich habe schon manche gehört, die gesagt haben, boah, jetzt muss ich damit in die Produktion von der Firma gehen, das ist doch jetzt doof, ich will doch einfach nur coden.

[54:17] Ja, ist auch fair. Also ich glaube, zwingen sollte man niemanden dazu, sondern, also manche Leute haben auch keinen Bock auf Security-Workshop, obwohl es ganz klar deine Jobbeschreibung ist, aber so ist es halt.
Kannst auch nichts machen.
Ja, ich denke, was du gesagt hast, ist, die Seniors helfen dir, weiter voranzukommen.
Und in dem Kontext kamen mich noch, also, und können dir halt Sachen beibringen, sind ein bisschen mehr so wie so ein Mentor und so.
Und ich habe für mich mal überlegt oder auch im Vorfeld schon drüber nachgedacht und eine Sache, die mir halt immer wieder bewusst ist, so über das je weiter man kommt so in der Rolle, ja also, ob man jetzt Teamlead ist oder halt irgendwie im Management oder halt Senior Staff Engineer, was weiß ich, Principal Engineer oder so, desto weniger Onboarding bekommst du für den Teilbereich, in dem du unterwegs bist, also irgendwie so als Junior bist du halt halt noch so total engineer, wirst du noch total an die Hand genommen. Wie geht ein Stand-up?
Genau, du kriegst alles erklärt. Und dann als Senior erwartet man halt von dir, dass das, das, das, das, das alles läuft.
Und die Dokumentation, da schicke ich dir einen Link und den Rest, den kriegst du dann schon selber hin. Wenn was nicht geht, dann schreibe mal bei Troubleshooting dazu.

[55:34] Ja, genau, genau. So, und je höher man halt kommt, desto weniger Onboarding bekommt man und ich habe das damals mal bei mir festgestellt, als ich irgendwie eine neue Rolle bekommen habe und dann hieß das so, ja, du, wir machen jetzt mal eine Stunde, also mein damaliger Chef, wir machen jetzt mal eine Stunde, gebe ich dir mal ein paar Infos, schreibe dir die mal mit und der Rest ist dann on you, ja, ich werfe dir nochmal fünf Namen hin und dann kriegst du den Rest halt schon hin. Und genau das ist es halt.
Du musst halt selber durchs Leben kommen und du musst halt selbst intrinsisch motiviert dich jetzt diesen Themen annehmen.
Wobei, genau, das mit den Leuten bringt. Das heißt ja nicht, dass du jetzt, hier ist die Codebase und jetzt entwickel das Feature, sondern vielleicht bist du ja dann klug genug, um zu sehen, ach, diese Person hat hier die meisten Commits gemacht.
Dann ist das vielleicht die Ansprechperson dieses Features.
Dann gehst du proaktiv auf diese Person zu, sagst, hey, was geht da ab?
Dann sagt diese Person, sie ist zurück. zurück, na na na, damit habe ich gar nichts zu tun, ich habe dich in den normalen Pretty Egg geändert und bin deswegen bei dem Commit überall dabei, aber die richtige Person, mit der du sprechen willst, ist diese Person, dann gehst du zu der nächsten Person und sagst hallo, die Person 1 hat mich zu dir geschickt und so weiter und so fort, bis man halt dann ankommt und, dementsprechend ist es halt dann doch, ich weiß, wir sind Coder und es gibt Leute, die wollen auch einfach nur Coden, aber es gehört vor allem ab einem bestimmten Level dazu, dass man sich da durchhängelt.

[56:57] Durchwurschtelt, bis man die richtigen Personen gefunden hat.
Das soll jetzt wirklich nicht heißen, dass man den Personen gar nicht mehr hilft, aber es ist jetzt nicht mehr in diesem Sinne, oder nicht mehr mit den Personen spricht, aber es ist nicht mehr in diesem Sinne dieses Händchen halten von, ich setze ein Meeting auf, damit wir über den Code Review sprechen können oder sowas, sondern sagst, hey, ich habe ein Code Review, ich brauche ein Pair Programming, oder hey, Leute, ich brauche Pair Programming, wer hat Zeit?
Und statt, dass ein Manager jetzt ein Pair Programming aufsetzt.

[57:25] Ja, also genau, die Themen, die ich jetzt angesprochen habe, die gingen jetzt nicht unbedingt dann über Programmierung.
Ich glaube, gerade im Engineering hat man es noch teilweise ein bisschen leichter, als wenn es halt um so kommunikativere Themen geht, sagen wir mal. Mal.
Gerade wenn man halt in einem Team etwas lösen kann, das ist halt, glaube ich, auf jeden Fall sehr gut und ich habe das Gefühl, so die Teams, mit denen ich zusammengearbeitet habe, da ist man ja auch grundsätzlich sehr bereit, immer, dass man, gemeinschaftlich halt an diesen Punkten arbeitet und halt sich unter Seniors so ein bisschen hilft, aber wenn man halt irgendwie, keine Ahnung, Teamlead jetzt ist oder so, dann sind das halt häufig Themen, die halt damit zusammenhängen, dass du halt mit anderen Teamleads dich abstimmen musst.
Die wissen aber gar nichts über dein Team und deine Probleme sozusagen oder nur ganz, ganz wenig.
Und darüber hinaus halt sowieso. Ja, aber das sind vielleicht auch nochmal, ja, über das Engineering hinaus Probleme.
Vanessa, wenn du jetzt mal neue Welt, ne, ganz kurz, so neues Jahr kommt bald auf uns zu.
Du hast jetzt den Entschluss gefasst, ich bewerbe mich jetzt hier bei XY Firma und die sagen, jo, wir nehmen dich.
Und jetzt hast du am 1. Ersten, Ersten, deinen ersten Tag? Zweiten, Ersten. Was wäre dein?

[58:46] Zweiten, Ersten. Deinen ersten Tag? Schon Feiertage hier.
Was ich tun würde? Dann haben die Leute erstmal alle Urlaub.
Klar, also sagen wir, du fängst eine Woche später an. Also mach den Ersten, fang ich an.
Was würdest du tun? Was wäre deine Erwartungshaltung an den idealen ersten Tag für dich?
Okay, was ich ich.

[59:10] Mit Respekt verbunden finde, tatsächlich auch, außer ich sollte halt jetzt wirklich von heute auf morgen anfangen, ist das sowas wie die Laptop-Situation, geklärt ist und dass ich zum Beispiel nicht betteln muss, weil mir das sonst unangenehm wäre nach vielleicht einem Monitor oder was weiß ich was.
Das heißt jetzt nicht, dass ich ein großes Setup brauche, aber ich finde es immer so ein bisschen unangenehm, als würde ich mich dann den Leuten aufdrücken, wenn ich halt jetzt einen Laptop und einen Monitor brauche.
Das heißt, das finde ich immer ganz nett, wenn das einfach geregelt wäre.
Und dann, genau was du vorher gesagt hast, ich will nicht, dass der erste Tag quasi schon voll zugepackt ist, sondern dass es da schon eine Art Pausen gibt, dass ich mich vielleicht auch wirklich mal mit der Stunde mit dem Laptop mich dann zurückziehen kann, richte mir den erstmal noch zu Ende ein, weil ich schon Passwörter aufsetze und dieses Pipapo, das kann ja am Anfang immer ein bisschen dauern.

[1:00:07] Und eigentlich früher hätte ich gesagt, ich bin drauf und dran und will jetzt hier sofort die Codebase kennenlernen und etc., Aber heutzutage würde ich vielleicht doch eher dann sagen, dass das Team und das Kennenlernen des Teams wichtiger sei.
Und ich glaube, jetzt würde ich mich fast nur wiederholen über die Sachen, die wir schon vorab besprochen haben.
Haben, dementsprechend wiederhole ich noch einmal den Punkt, der mir halt wirklich wichtig ist, dass man sich jetzt an dem Tag nicht viel am Platz fühlt oder dass man nervt, weil oft werden ja Leute geheiert, weil man zu wenig Leute da hat, um Sachen zu tun, aber wenn dann niemand gerade am ersten Tag so wirklich Zeit für einen hat und klar, es gibt jetzt dieses, du bist Senior oder du bist Lead oder du bist Head of, du kommst schon klar, hier sind so ein paar Sachen, ist jetzt ein bisschen was anderes, ist.
Aber trotzdem, wenn du zum Beispiel, wenn es hieß, man trifft sich um 9 Uhr und keiner kommt um 9 Uhr und dann heißt, ach, der kommt schon oder die kommt schon um 9.30 Uhr und dann kommt die Person, die dich kickoffen sollte, erst um 9.40 Uhr.
Das fände ich jetzt einfach sehr merkwürdig, sage ich es mal so.

[1:01:18] Und ich möchte, und dann auf der anderen Seite, doch, das wäre jetzt auch noch wichtig, ich möchte natürlich aktiv werden.
Also ich denke, wir haben auch alle schon mal Geschichten von Freunden, Freundinnen gehört, die gesagt haben, du, es ist jetzt drei Wochen vergangen, ich habe immer noch keinen Zugang.
Ja, ich auch keine Ahnung, ich mache jetzt Videokurse, ich schaue mir was an.
Ich glaube, wenn mir sowas mal passieren würde, dann würde ich aber auch wirklich einsteigen, dann würde ich sagen, oh Gott, jetzt alles egal, jetzt kauft mich ja mal einen monatlangen drei Videokurse und dann mache ich halt die durch, würde da jetzt nicht Räumchen drehen und warten.
Aber ja, Ja, das ist wahrscheinlich auch nicht so angenehm, wenn man nur einen Monat dann so rumhängt, weil man will ja eigentlich den Job machen.
Und wenn man den Laptop nicht hat, auf welchem Laptop soll man denn dann seinen Videokurs machen?
Ja, einen Laptop sollte man schon wirklich haben. Also wenn ich jetzt nicht mehr einen Laptop bekommen würde, ja, was dann?
Passiert. Passiert. Wirklich? Ah je.
Naja, für wahrscheinlich. Natürlich.
Ja, eine Woche ohne Laptop ist normal. normal.

[1:02:24] Kann ich dir genügend Geschichten erzählen.
Es ist den Leuten egal, eine Woche. Aber genau, das ist der wichtige Punkt.
Es wäre halt egal, egal mit welchen konkreten Beispielen, aber es sollte jetzt nicht egal sein, dass die neue Person da ist.
Es ist alles sehr aufregend und dafür sollte man schon da sein und schon Zeit haben.
Jede neue Person wird schon verstehen, dass die anderen in ihrem Laufenden trotz sind und Und die Lieder ihre, keine Ahnung, wie viele Meetings pro Woche haben.
Aber als Störfaktor sollte man sich wirklich nicht fühlen als neue Person.

[1:03:02] Ja, das ist sehr verständlich. Ich glaube, das ist auch ganz, ganz wichtig, dass man sich halt irgendwie willkommen fühlt.
Und das gerade, wenn man halt vor Ort ist. Habt ihr Willkommenspakete? Ja.
Ich glaube nicht. Ich glaube nicht mehr.
Früher, also es gab bei Join, gab es immer mal Willkommenspakete.
Mittlerweile bei uns nicht. Das hat den Hintergrund, das ist halt ein Problem, wenn du dieses Geld für die Mitarbeiterinnen und den Mitarbeiter ausgibst und das einen bestimmten Betrag überschreitet, dann ist das ein geldwerter Vorteil und du musst das steuerlich Geld machen.
Die müssen das versteuern, die Mitarbeiterinnen und Mitarbeiter.
Deswegen fällt es so schwer, da immer die richtigen, also du kannst im Monat nur so und so viel ausgeben und wenn du ein Event planst, dann ist das Geld locker weg.

[1:03:57] Ja, das sind leider manchmal so doofe Gegebenheiten und irgendwie gibt es bestimmte auch Workarounds.
Ja, aber wenn man halt publicly tradet, naja, okay, ihr wisst alle, was ich meine.
Eine Firma ist, die auch am Stock Market aktiv ist, dann gibt es halt so viele Prüfungen und alles mögliche, wo man sich natürlich auch sehr konform verhalten muss.
Ja. Ich glaube, mir persönlich wäre das jetzt auch am unwichtigsten, ob da jetzt ein Wacom-Package auf dem Schreibtisch steht oder nicht.
Viel wichtiger ist, dass irgendjemand Zeit hat.
Oder viel nerviger wäre es wahrscheinlich, wenn man unbedingt die eine bestimmte Hardware haben wollte, aber das ging aus irgendwelchen Gründen nicht.
Aber hier ist eine Tafel Schokolade. So, aber hättet ihr mir nicht den, was weiß ich, M3 Space Black MacBook kaufen können?
Auch da gibt es gute Ausreden, warum das leider nicht geht, glaube ich. Also, ja.
Es gibt bestimmte Leasing-Verträge mit Firmen. Für meinen VS Code brauche ich auf jeden Fall M3.
Nein, Scherz. Ja, also ich.

[1:05:07] Man lebt es halt auch manchmal bei anderen Firmen oder so, die eine gewisse Größe haben.
Manche sind da flexibler, manche sind nicht so flexibel. Es kommt dann immer darauf an, was hat man da gerade für Verträge abgeschlossen, wenn man sich halt so einen Log-In-Vertrag mit irgendeinem Vendor macht, der dir deine Hardware zur Verfügung stellt und der bietet dir halt nur deutsches Keyboard an, dann gibt es halt auch nur deutsches Keyboard, Punkt.
Ja, das mit diesem ganzen Keyboard-Gebommel, also dann muss man halt mal ein amerikanisches oder deutsches lernen. Ja, natürlich.

[1:06:04] Bekommst, ja, könnte es wahrscheinlich knapp werden, da müsste man dann nochmal nacharbeiten, aber das sind halt so Sachen, die passieren.
Jetzt möchte ich das nochmal relativieren, die Aussage, gerade mit der Tastatur, vor allem Tastatur-Layout, aber dennoch, manchmal finde ich es auch bis heute teilweise, kann ich es doch nicht verstehen, wenn, ich meine, was kostet, ein MacBook Intel, was kostet ein MacBook M1 und wenn das die Leute so viel effizienter macht, dann muss das ja günstiger sein, die bessere Hardware zu kaufen, als dass die Person dann nicht effizient wäre.
Naja. Das ist halt logisch gedacht, jetzt was du gerade argumentierst, aber nicht immer wird logisch gedacht, weil wenn es dann heißt, ja, aber für dreieinhalbtausend andere Leute haben wir jetzt gerade nur diese zur Verfügung, warum musst du jetzt das bekommen?
Ich weiß, warum brauchst du jetzt einen Curved Monitor? Ich habe Pech gehabt.
Ja, aber ja, egal. Also es ist ja auch, Es ist ja cool, dass man MacBook Pros überhaupt bestellen kann. Von daher.
Ja, stimmt. Früher war das all der Schlimmer. Ich wollte es dir noch eine Frage gerade stellen. Gerne.

[1:07:12] Wieder zurückzukommen aufs Onboarding und auch Performance Reviews.
Geht es dann mehr in Richtung so richtige Coding-Performance-Review, so das hat uns gut gefallen, das hätte ein bisschen schneller gehen können oder hier hätten wir dieses UI-UX-Feedback vielleicht noch erwartet.

[1:07:28] Oder fällt es bei euch auf, kann es in der Probezeit auch anfallen, dass es wirklich auch mal so ein menschliches, zwischenmenschliches Feedback gibt, wie da war jetzt die Kommunikation in dem Team dann, irgendwas hat nicht gepasst?

[1:07:40] Also da kann ich kein aktuelles Beispiel so zu dem Thema Coding geben, weil ich jetzt tatsächlich so Reviews für Coding schon sehr, also schon eine gewisse Zeit einfach auch nicht mehr, oder was heißt Performance Reviews sozusagen für Leute, die halt wirklich Engineers sind, so nicht mehr so wirklich gemacht habe.
Aber bei mir sind es halt meistens so diese Metathemen, also irgendwie, keine Ahnung, ein Teamlead, der halt irgendwie sich gewisse Goals setzt und die vielleicht nicht erreicht.
Und da geht es ganz viel um Kommunikation, halt sozusagen, keine Ahnung, irgendwie ein Feature soll delivered werden und irgendwie gibt es keine Kommunikation dazu oder das ist irgendwo stuck.
Stuck oder ich habe gehört, deine Senior Engineers sind zu mir gekommen und haben gesagt, hier irgendwie gibt es ja keine Infos, dann würde ich sowas halt eher feedbacken.
Wobei das gehört jetzt schon für mich dann auch diese Art Kommunikation für, das ist ja dann der Job, das wäre dann das Technische.
Also das ist erwartet, dass du in dieser Position dich darum kümmerst, dass das Projekt transparent läuft oder dass die Stakeholder Bescheid wissen, wenn was länger dauert oder früher fertig wird oder was getestet werden muss.
Aber hattest du schon auch mal die Situation, dass es wirklich ein menschliches Problem dann zwischen Teammitgliedern gab und eine von diesen Personen war vielleicht sogar in der Probezeit?

[1:09:03] Dass es da so Disharmonien gab, kam. In der Probezeit hatte ich das noch nicht.
Ich überlege gerade, ob das in einem der Teams mal der Fall gewesen ist.
Nee, aber wir haben, ich muss auch sagen, ich habe jetzt in den letzten drei Jahren niemanden, den wir eingestellt haben, in der Probezeit nicht verlängert.
Hatten wir nicht den Fall. Mega gut eigentlich, fällt mir gerade auf. Ja, mega gut.
Ja, und wir haben auch eine Zeit lang viele Leute eingestellt.
Jetzt sind wir gerade wieder dabei. bei, hoffentlich bleibt das so, toi, toi, toi.
Nee, aber muss ich sagen, das war jetzt noch nie so das Problem.
Ich hatte das vor vielen, vielen Jahren, hatten wir das mal bei einem Team, da haben wir jemanden eingestellt als Freelancer, der halt.

[1:09:47] Sagen wir mal, wo wir dachten, ja, der kann schon bestimmt seine Performance als Individual Contributor abrufen, jetzt im Team wird das so okay funktionieren, aber halt so als jemand, der halt irgendwie ein Output liefert, da geht das schon, jetzt, der hat nicht so einen riesen Impact, aber das passt schon.
Und ich habe, aber da haben wir uns vertan.
Also das ging auch viel auf meine Kappe, weil ich damals die Interviews auch gemacht habe und die Person ist halt überhaupt nicht dazu irgendwas gekommen.
Die hat nie richtig Code contributen können, hatte viel zu altes Wissen, solche Sachen.
Das waren dann Themen, wo man einfach sagen muss, okay, du verstehst gerade eigentlich den Code auch gar nicht, den wir hier schreiben.
Das war ein Problem. Und da haben wir dann halt auch sehr, sehr zügig gesagt, so pass auf, das machen wir jetzt noch folgende Milestones.
Uns, hier erwarten wir folgende Sachen von dir, das finde ich halt extrem wichtig, ne, auch musst ja sowieso rechtlich dich dann absichern in so einer Probezeit, soweit ich das verstehe.

[1:10:52] Aber genau, auch da mit dem Freelancer haben wir halt gesagt, so pass auf, das sind die Dinge, die erwarten wir uns jetzt und dann gucken wir, wie das läuft und das lief dann halt nicht und dann haben wir halt gesagt, so wir trennen uns jetzt, ist bei Freelancern natürlich ein bisschen einfacher, aber in der Probezeit ja im Endeffekt auch, im Endeffekt, ich glaube, man muss ja nicht mal richtige Gründe angeben, warum du dich trennst von jemandem in der Probezeit.
In der Probezeit eigentlich nicht wirklich.
Also ich meine, du wirst ja wahrscheinlich einen richtigen Grund haben. Sonst.

[1:11:19] Ja, ich glaube aber, das Wichtige ist, dass du halt nicht den falschen Grund kommunizierst.
Weil wenn du irgendwas sagst und das ist rechtlich verwertbar.
Das ist ja auch so der Grund, warum häufig die, Absagen bei so.

[1:11:35] Irgendwie Interviews oder so immer so ein bisschen kryptisch daherkommen.
Aber das ist nochmal ein anderes Thema.
Es gibt sogar eine Sache, die ich frage und das hat ein bisschen aber was mit diesem, auch ein bisschen mit diesem Remote-Kontext zu tun oder was ist Remote-Kontext, dass Leute vielleicht doch hin und wieder ein Homeoffice machen, dass ich gerne frage, wann sind so die Lieblingsessenszeiten von den Leuten?
Weil man das ja sonst nicht sieht. Und sonst gibt es immer Grüppchen, die sich eher bilden. Es gibt so ein bisschen die Frühesser und die Spätesser.
Und teilweise finde ich es auch selber deswegen so spannend, weil ich glaube, wenn es irgendwie sozial möglich wäre, was es leider nicht ist, würde ich einmal um 10 Uhr essen und einmal um 16 Uhr.
Das sind so ungefähr die Zeiten, wo sonst niemand ist. Das ist ein bisschen doof und sozial sehr, sehr schwierig. Ja, ich weiß.
Aber ich fände es ganz cool. Naja, tatsächlich, aber ein Kollege, ich sag's dir, ja, wir sind hier, wir wären gut zusammen.
Wir essen zu den gleichen Zeiten, also wenn wir könnten.
Nee, aber ernsthaft, wenn es gerade um so Meetings geht, also ich meine, klar, dieses typische von 12 bis 14 Uhr sollten wir jetzt sowieso keine Meetings einstellen, aber dennoch frage ich da gerne nach, so hast du Bock auf ein 11.30 Uhr Meeting oder ist es bei dir eher so ein Vormittagsding oder eher ein Nachmittagsding?
Du, Hans, das geht so, in diesen kleinen Firmen geht das, weil es halt geht.
In großen Firmen ist das dann irgendwann nicht mehr relevant.

[1:13:00] Aber auch wenn es an 101 geht, so hey, hättest du das lieber da an dem Tag oder an dem Tag?
Ja, also genau, 101s mache ich auch immer genauso, wie du gerade gesagt hast.
Ich frage immer die Leute, ey, wann habt ihr Bock?
Wann passt dir's? Ich richte mich gern nach dir.
Nicht, dass man jetzt das irgendwie vor einer Review oder was weiß ich was einstellt.
Oder es war gerade eine Retro und die Leute sind eh schon dann in diesem Ding ein bisschen durch und wollen vielleicht wieder durchschnaufen, dann braucht man vielleicht jetzt nicht nach einer Retro direkt noch einen 101 mit Manager. Ja, genau.

[1:13:32] Und ansonsten muss ich sagen, wir haben Teams bei uns, die zum Beispiel so Montag und Freitag Meeting-free versuchen zu machen.
Das klappt vor allem gut für die Engineers, also die kriegen das gut hin.
Aber halt so die, also zum Beispiel als Teammanager ist es dann halt schon ein bisschen schwieriger.
Sagen dann, ja komm, nee, machen wir jetzt. Und die kriegen das dann halt nicht ganz so hin.
Aber für die ist ja auch sozusagen nicht die Arbeitszeit 100% Coding angedacht.
Das ist ja das Meeting, die Arbeitszeit.
Genau, also das ist ja bei allen anderen logischerweise auch so.
Aber da ist es halt sozusagen Kommunikation ist eh 50% deiner Arbeit mindestens.
Für manche ist es mittlerweile 90.
So, aber genau. Und ansonsten, also ich muss sagen, für mich, mir ist das relativ egal, wann die Meetings sind.
Also 12 bis 1 ist bei uns eigentlich so bei den aller, aller, allermeisten die Mittagspause.
Deswegen passiert da seltenst was. Aber jetzt zum Beispiel heute gab es halt trotzdem Meeting, weil dann ist halt Eskalation und dann muss halt.
Und dann ist das halt so. Aber das macht mir jetzt auch nicht so viel.

[1:14:52] Freitagabend 18 Uhr hatten wir auch noch ein Meeting eingestellt.
Das fand ich dann nicht so cool.
Also Freitagabend 18 bis 18.30 Uhr war jetzt nicht so meine Zeit.
Ja, ich habe auch gehört, es gibt jetzt Firmen, die irgendwie Freitag so Workshop-Tage haben.
Und manche finden das ganz super, so ein Workshop-Tag. Und manche sagen, boah, nee.

[1:15:11] Ja, das sind die Leute auch ein bisschen verschieden. Man kann es da auch bestimmt nicht jeder besser und recht machen. Ich glaube, bei Freitag 18 Uhr hören jetzt gerade viele Leute zu und sagen sich, what, vielleicht solltest du dazu sagen, dass die Engineers da hoffentlich nicht hin mussten.
Nein, das waren, da waren, also da waren sechs, sieben Leute dabei, die jetzt irgendwie halt, keine Ahnung, da in einem Thema, wo es halt eskaliert ist letzte Woche, wo man halt nochmal drüber sprechen musste und da gibt es halt keine andere Zeit, weil die Leute alle zu sind.
Aber ich bin, also der wurde dann auch noch verschoben, zum Glück.
Aber gerade für Leute mit Kindern ist halt oder kleinen Kindern ist es halt 18 Uhr gibt es halt Essen und 19 Uhr geht es ins Bett und das sind halt irgendwie die einzige Stunde, die man am Nachmittag nochmal hat, so ungefähr.
Von daher, das ist jetzt nicht so ideal. Nee, aber das sind ja die Ausnahmen.
Ich bin mir nicht sicher, ob jeder das Wort Eskalieren kennt, weil Eskalieren, wenn man das nicht in unserem Umfeld kennt, dann klingt das vielleicht nach einem etwas Größeren.
Aber mit Eskalationsmeeting meinst du dieses Eskalationsmeeting, wo man im ruhigen Ton miteinander über ein Thema spricht, das sonst eskalieren könnte?

[1:16:27] Ja, also im Endeffekt bedeutet das ja eigentlich nur, das nächsthöhere Level wird im Management, wird mit involviert, um ein Thema zu lösen beispielsweise. Beispielsweise.
Oder es kann natürlich auch umgedreht sein, du hast halt jemanden aus einem Management-Level, der halt ein Thema als Problem erkannt hat, wo man sich gemeinschaftlich hinsetzt und sagt, hey, wir müssen hier mal irgendwie eine Sache lösen gemeinsam oder mal drüber sprechen, was denn eigentlich der Status ist. aus Gründen.
Ich gebe jetzt mal ein klassisches Beispiel, dass du hast irgendeine Downtime deiner Website und du hast aber dein eigenes Goal, 99,99% Uptime und auf einmal jetzt in unserem Kontext kommt irgendeine Show.
Sagen wir einfach mal, Germany's Next Topmodel, Donnerstag 20.15 Uhr und du kannst irgendwie den Benutzern die Website nicht anbieten.
Das wäre halt fatal für uns. Das heißt, da da hängen halt auch ein bisschen Kohle dran im Endeffekt und da spricht man dann doch schon mal genauer drüber.
Das ist in dem Fall nicht der Fall, aber es kann halt in eine ähnliche Richtung gehen.
Und das ist, glaube ich, schon auch wichtig, das zeitnah zu behandeln.
Und dafür sind wir als Manager dann natürlich auch in der Verantwortung, dass wir dann auch mal Freitagabend um 18 Uhr theoretisch da auf der Matte stehen.

[1:17:54] Ja, also nur für alle, die den Begriff noch nicht gehört hatten.
Zum Beispiel, wenn ich mich jetzt ganz doll mit einem Backend-Developer streite, weil ich sage, das ist doch eindeutig eine Business-Logic, die ins Backend gehört und Backend sagt, das ist ja alles völliger Blödsinn, was du laberst, das gehört doch eindeutig ins Frontend.
Und man kommt halt einfach nicht auf den grünen Zweig, dann kann man sowas eskalieren.
Was bedeutet, ich schalte die höheren Stufen ein, um zu sagen, du, wir kommen nicht mehr weiter, wir brauchen Hilfe und weitere Personen zum Mitreden.

[1:18:24] Genau. Und das macht man im Bestfall sehr häufig. Ich bin ein großer Freund davon.
Escalate early ist das Stichwort.
Aber es ist ein anderes Thema für wann anders. Ja, genau, das kommt dir dann normalerweise nach dem Onboarding, also in der Probezeit.
Ich meine, Onboarding ist, weiß ich auch gar nicht so, ob das die ganze Probezeit des Onboarding ist oder wo das Onboarding aufhört.
Wo hört denn für dich so das Onboarding auf?
Wann ist man denn ongebordet? Nach einer Woche, nach einem Tag, nach sechs Monaten? Nie?
Ja, keine Ahnung. Manager nach einem Tag müssen wir ongebordet sein.
Minus eins Tage. Das ist echt doof zu sagen. Nein, Quatsch, das ist ja Quatsch.

[1:19:06] Nee, ach, ich denke, das ist halt so ein fließender Prozess.
Ich glaube, du hast ja eben schon so ein paar coole Punkte genannt.
Manchmal bist du halt noch auch nach Jahren nicht so wirklich ungebordet in einem bestimmten Teilbereich.
Und dann gibt es halt Teilbereiche, wo du besser ungebordet bist.
Ist so und ich glaube im Idealfall brauchst du wahrscheinlich so drei Wochen, bis du irgendwie einigermaßen gut um die Codebase drumherum, arbeiten kannst an den Stellen, wo du es halt wo es halt relevant für die aktuellen Themen ist.
Dann kommt halt ein neues Epic rein und dann kennst du es halt wieder noch nicht, wie jetzt da hinten links irgendwas funktioniert in Anführungsstrichen.
Ja und dann geht das halt so weiter, aber ich würde nicht sagen, dass die komplette Probezeiten Onboarding-Phase ist.
Nee, du hast schon recht, es sind eher so zwei Wochen normalerweise.
Ich glaube, es wäre schlecht, wenn eine Person nicht in ein richtig aktives Contributing kommen würde innerhalb der ersten sechs Monate.

[1:20:05] Nee, stimmt. Also ich würde auch wirklich nicht die ganze Probezeit dafür ansehen, nur ich fände es halt im Rahmen des Onboardings zum Beispiel sehr wichtig, da schon zu erwähnen, du, wir werden so ein Halbzeitgespräch haben in der Probezeit und Und zu diesem ungefähr Zeitpunkt wird dann auch unser Endgespräch für der Probezeit stattfinden, damit die Leute halt einfach dann nicht so überrumpelt werden und eben auch wissen, hey, das sind die Erwartungen, die wir bis dahin haben.
Und jetzt gibt es schon mal drei Monate Zeit.

[1:20:33] Und dann kann man schon mal zwischenzeitlich überprüfen, wie es läuft.
Und dann möchte ich wieder, also ich sage das öfter mal, glaube ich, hier auch im Podcast, also ich möchte noch einmal dafür werben, nehmt eure Punkte selbst in die Hand, nehmt euer Onboarding selbst in die Hand.
Wenn ihr irgendwo ongeboardet werdet, dann seid selbst dafür verantwortlich, dass ihr Feedback bekommt.
Kommt, holt euch Feedback, sprecht mit euren Vorgesetzten und fragt, was die Erwartungshaltung ist, wenn die euch das nicht sagen und kommuniziert transparent, was eure Erwartungshaltung ist.
Wenn ihr das nicht selbst in die Hand nehmt, habt ihr Pech am Ende, wenn ihr dann rausfliegt. Das ist meine persönliche Meinung.
Wenn du zwei Wochen vorher gesagt bekommst, du fliegst übrigens raus und vorher hast du dich nicht erkundigt, dass du in der Probezeit, also wie deine Probezeit eigentlich läuft, dann bist du selber leider mit dran schuld.
Ich bin bin der Meinung, jede Person ist dafür selbstständig verantwortlich, die eigene Karriere in die Hand zu nehmen und sich selbst daran voranzutreiben sozusagen.

[1:21:33] Seht es mir nach, wenn ich das jetzt ein bisschen harsch formuliere, aber ich bin kein großer Fan davon, bei allem das Händchen zu halten, weil wir sind alle erwachsen und alle professionell und das ist das Wichtige.
Wir sind professionell und wenn man professionell ist, gehört das mit dazu.
Wenn man gebabysittet werden möchte, dann hat das nichts damit zu tun, aus meiner persönlichen Perspektive.
Und das hätte ich jetzt gerne von euch, ob ihr das auch so teilt oder nicht.
Schreibt mir doch gerne bei X, da lese ich dann auch mal mit.

[1:22:08] Aber du hast gesagt, ihr würdet auch gerade ein bisschen heiern, für alle, die nicht unbedingt Gebi-Bizett werden müssen.
Ich würde jetzt hier nicht den einen Werbeplatz besetzen.
Nee, nee, nee. Aber gut, ach Mann, ich wollte nur eine nette Transition machen.
Ich mache die Transition anders.
Wir waren zwar gerade beim Onboarding, aber du, wir könnten auch mal so eine Offboarding-Session noch irgendwann machen, nachdem wir auch über Vertragsverhandlungen und etc. gesprochen haben.
Denn man muss natürlich auch nirgends bleiben, wo es ganz furchtbar ist.
Im Rahmen von solchen Onboardings habe ich dann halt auch immer mal ein bisschen tiefer mit Personen gesprochen.

[1:22:41] Und ja, natürlich kommt, das ist immer ganz im Erden, Es kommt natürlich immer ein bisschen doof an, weil man jetzt ein Interview hat und auch fragt, warum gehst du denn, oder falls die Frage aufkommt, ich stelle diese Frage nicht unbedingt, aber falls irgendwie die Thematik aufkommt, warum man auf der Suche ist, und dann kommt nur dieses ganze Gelästere über die alte Firma, ist natürlich auch mal ein bisschen schwierig.
Aber es ist dann doch mal interessant, wenn man dann schon während dieses Onboardings vielleicht eben tiefer in die Gespräche mit den Leuten kommt.
Und dann kommen solche Punkte wie so, ja, keine Ahnung, ich war da sechs Jahre und ich durfte nie auf eine Konferenz. Und das war oder jenes, weil ich sage jetzt nur ein paar Stichpunkte.
Ich weiß, der Markt ist, glaube ich, ein bisschen schwieriger geworden für Developer aktuell.
Aber man sollte natürlich nicht in toxischen Beziehungen bleiben, falls das jemand gerade hören muss.
Man kann aus toxischen Beziehungen und toxischen Arbeitsbeziehungen gehen.
Es gibt Firmen, viele Firmen wahrscheinlich gerade, die auch Hiring betreiben.
Also wenn man jetzt zum Beispiel nur die eigenen Manager managen muss, weil man doch sowieso schon so proaktiv ist, kann auch gehen.

[1:23:47] Wir heiern übrigens leider gerade nicht. Aber vielleicht nächstes Jahr.
Vielleicht ja bald wieder. Ja.

[1:23:55] Alright. Gut. Dann lass uns doch dieses Onboarding-Prozess beenden.
Nee, keine Ahnung. Ich wollte jetzt irgendwie das so...
Ja, es wird spät. Ja. Wir machen das hier zu.
Und ich dachte, es geht irgendwie mit dem Onboarding einher. Aber nein. Nein.
Und Wodding geht ja immer weiter. Ja, war spannend, auch mal aus deiner Perspektive zu hören.
Vielen Dank. Danke dir.
Und wir, wie du gerade schon gesagt hast, ihr findet uns ja wie immer, wir sagen das immer, dass ihr wisst ja, wie ihr uns finden könnt.
Aber geht es doch, weil es nicht so ganz klar sein sollte, geht es doch einfach mal auf die Working Draft Webseite und da befinden sich solche ganz kleinen Icons.
Die sind ganz süß und unaufdringlich, Aber diese Icons sind auch Links zur Sarie-E-Mail-Adresse und auch zu dem Working Draft Community Slack und wie ihr uns dort erreichen könnt, weil ich nämlich letztens selber auf der Suche nach eigentlich unserem Slack-Wing war und da gefunden habe, dass das so ein kleines süßes Icon.
Falls ihr das noch nicht gefunden habt, da ist es und dann könnt ihr da mit uns quatschen und uns Feedback geben, worüber wir sehr freuen und wir uns sehr freuen würden.
Wie immer natürlich auch über Sternchen bei zum Beispiel iTunes und nicht nur über Sternchen, sondern auch gerne über Kommentare, damit wir weiterhin von den Leuten gefunden werden, weil auch nächstes Jahr steht ja bestimmt wieder ein State of JS an und vielleicht.

[1:25:25] Naja gut, bis dahin ist es noch lang hin, aber wir freuen uns natürlich riesig und wahnsinnig, wenn wir dort auch empfohlen werden.
So. Genau. Das war's.
Dann hören wir uns nächste Woche wieder und nochmal zur Erinnerung, wir gehen mit großen Schritten auf Revision 600 zu und freuen uns schon wahnsinnig drauf.
Ich habe gehört, da kommt bald was. Da kommt was. Bis dahin, macht's gut.
Bis bald. Tschüss. Ciao, ciao.

[1:25:52] Music.

[1:25:59] Bis zum nächsten Mal.

Revision 598: Erfolgreiches Onboarding – Einblicke mit Hans & Vanessa

Medium

Chapters

Long Summary

Brief Summary

Tags

Transcript

Revision 598: Erfolgreiches Onboarding – Einblicke mit Hans & Vanessa

https://workingdraft.de/598/