Mike ist 33, gebürtiger Berliner, wohnt noch in Lübeck, bald wieder Berlin. Anfangs in der berliner Startup-Szene unterwegs gewesen, dann drei Jahre bei Xing in Hamburg gearbeitet. Seit zwei Jahren bei Github.
Mike ist eigentlich Sysop, also Administrator. Bei Xing für mehrere hundert Server zuständig. Später dann immer mehr in Richtung DevOps gewandert, was er jetzt macht.
Erst 5 Jahre als Barkeeper gearbeitet, dann Ausbildung zum Fachinformatiker.
Nach den drei Jahren bei Xing war er wieder auf der Suche nach was Neuem und hat einen Tweet von Github bzgl. Enterprise Support Europe gesehen und angeklickt und hat sich darauf beworben.
Das Ganze hat mit einer einfachen E-Mail angefangen, in der Mike schrieb was er gerade tut, wieso er sich bewerbe. Dann kam eine positive Antwort von Github, die 10 "Screening Fragen" beigefügt haben, also Aufgaben zum knacken. Und damit war er dann an einem Wochenende 10 - 15 Stunden beschäftigt. Das wird auch heute noch so bei Github praktiziert. Daraufhin kam es zu einem Telefonat mit "Joel", einem seiner jetzigen Kollegen. Der wollte Mike nach rund 15 Minuten des Fragens gerne mal persönlich treffen, aber dann hat Mike das Zepter übernommen und neugierig viele Gegenfragen zu Github gestellt.
Dann ging es für zweieinhalb Tage nach San Fransisco. Mit Limusinenservice, Hotel etc. Mike hat sich etwas klein gefühlt und nicht gut geschlafen (auch wegen Jetlags). Sich am nächsten Tag im Github Office mit 45/50 Leuten unterhalten, und XBOX gespielt, Billard, Mittagsessen - in Zweier- und Dreiergruppen - und im Grunde ging es nur darum, ihn kennenzulernen. Mike war sich danach aber sicher: Das wird nichts. Zwinschen all den Superstars hat er sich nicht gesehen. Außerdem hatte er einen nativ englischsprachigen Konkurrenten. Am letzten Tag hat er sich dann SF angeschaut (und sich einen dicken Sonnenbrand eingefangen), und ist nach Hause geflogen.
Mike ist noch heute selbstständig und stellt Github ständig Rechnungen, weil es andernfalls sehr schwer ist, sich in Übersee anstellen zu lassen.
Mike arbeitet remote und kümmert sich um Support. Mike arbeitet bei bei "Github Enterprise", einer Appliance. Er ist Teil dieses Teils von Github und leistet Support für dessen Kunden. Mike war nicht immer beim Support, sondern hat auch Features (mit)gebaut, hat anfangs als Github Enterprise noch klein war sogar mal Hiring gemacht. Hat Jobinterviews in SF gemacht. Und im letzten halben Jahr viel Release Management und Testing gemacht. Github lässt einem also viele Freiheiten.
Github ist jetzt 6 Jahre alt, kein Konzern, aber 240 Leute (als Mike anfing 110). Ende 2012/2013 gab es noch keine einzige Managementposition, sondern jeder hat gemacht, was er meinte am besten zu können. Es ging nur darum, das gesamte Konstrukt nach vorne zu bringen. Vorausgesetzt, die anderen stimmten einem zu, dass das Sinn macht.
Auch wurde viel an einem internen Toolset gearbeitet, u.a. auch einem Tool, in das man seine Ideen und Gedanken einfließen lassen konnte. Und wenn das Feedback der anderen gut genug war, konnte man sich dem auch widmen. Aus solch einer Idee ist dann der Editor "Atom" entstanden.
Im letzten laufenden Jahr hat sich das aber dann doch verändert. Es gibt nun festere Strukturen. Dennoch muss Mike niemandem Rechenschaft darüber ablegen, was er an jedem einzelnen Tag tut oder nicht tut.
Dieses Teamverhalten wird sichergestellt durch
- sehr sorgfältige Screenings
- und dadurch, dass immer jemand für den anderen die Hand ins Feuer legen muss
Es gab dennoch auch schon einmal Leute, die das Unternehmen wieder verlassen mussten, weil sie mit der "Strukturlosigkeit" klarkamen. Wichtig ist auch, dass man ständig seine eigene Art zu Arbeiten kontrolliert, einschätzt und managed. "War die eigene Arbeit für Github von Vorteil/Mehrwert?"
Von 240 Leuten sitzen 180 außerhalb von SF: Viele aus den USA. 50 - 60 in Europa. 30 - 40 im asiatischen Raum. Es gibt keine wirklichen Meetings, keine Standups, kein Projektmanagement. Wenn man sich mit wem im Videochat unterhalten will, dann pingt man denjenigen im Instant Messenger an. Die Programmierarbeit erfolgt dann natürlich über Github.
Das bedeutet zwar viel Freiheit, aber auf der anderen Seite verpflichtet es einen immer auch, die Arbeit nicht zu vergessen. Auch wenn man gerade an das Ende der Welt gereist ist.
Dafür gibt es intern auch das Motto: "Optimizing for Happiness". Deshalb gibt es u.a. gutes Geld und auch Firmenanteile. Auch remote Arbeitende bekommen in den Genuss der gleichen Vorzüge wie die Festangestellten. Das erstreckt sich bis dahin, dass man sich in ein Flugzeug setzen und in SF in einem Hotel absteigen dürfte, wenn man das Gefühl verspürt, in der Zentrale sitzen und mal Leute dort sehen zu wollen. Zum Beispiel nach einigen Monaten der einsamen Remotearbeit.
Die Octocat wurde von demselben britischen Designer gemacht, der auch das Twitter-Logo gemacht hat. Das hat man damals mal auf die Schnelle gekauft, weil man ein Logo brauchte. Dass das so einen Kultstatus erreichen würde, war niemandem klar.
Github Enterprise kommt als Virtuelle Maschine daher, die man lokal ins Netzwerk hängen kann. Die Userstruktur kann man dann derjenigen in der Firma nachempfinden. Konkurrenten wären z.B. Stash oder Gitlab. Nur dass bei Github alles in einer Appliance steckt, also der Issuetracker wäre zum Beispiel direkt mit dabei, im Gegensatz zum Atlassian Produkt, wo man noch JIRA dazu braucht.
Atlassian hat viermal so viele Mitarbeiter wie Github.
In Sachen Supportarbeit ist es so dass Mike und andere "Operations" Mitarbeiter kleinere Fehler selber lösen. Größere Fehler werden dann an Programmierer weitergeleitet. Bei "Github Enterprise" spricht man nie mit unerfahrenen Endusern, sondern i.d.R. mit den Administratoren auf Firmenseite. Es werden viele Supportanfragen per E-Mail beantwortet, weil viele Kommandos darin hin und hergeschickt werden, die man so leichter kommunizieren kann. Es gibt notfalls auch "Callback" Support. Und es gab auch rund zwei Dutzend Fälle, in denen sein Team in den Flieger gestiegen ist und vor Ort vorbeigeschaut hat. Die meisten Probleme entstehen meist durch die gemeinsame Codebase, die Github Enterprise mit Github.com teilt - aufgrund von Änderungen der Github.com Leute, die dabei die Enterprise Appliance vergessen.
Beim Umgang mit den Benutzern gibt folgende Kernprinzipien:
- Nicht in einen Kampf reinziehen lassen
- Niemals den Benutzer beschimpfen, ansonsten warten und abkühlen
- Github entschuldigt sich ganz selten, weil die Features meist so sind wie sie die haben wollten (die reifen mindestens 6 Monate vorher auf Github.com)
- Keiner hat Superkräfte, deshalb darf man auch mal sagen, dass man keine Ahnung hat. Das Problem wird dann eben weitergegeben.
- Keine Werbung für eigene Produkte in den Tickets
Mike reizt am Support, wenn im Instant Feedback eine überpositive Rückmeldung kommt. Am Ende des Tages weiß man einfach, was man getan hat. Man hat ein Problem, und das kann man lösen, und dann fühlt man sich gut. Das einzige Problem an der Sache: Es hört nie auf. Und so braucht man auch mal eine Auszeit vom Beantworten von Tickets. Und man muss auch ständig dazulernen, vor allem wenn man öfters mit einem Problem konfrontiert wird, oder sich keiner im Team findet, der sich mit einem Thema oder einer Konstellation auskennt. Zum Beispiel LDAP.