TechLead-Story: Hannes Stiebitzhofer, CTO von S1Seven

TechLead-Story: Hannes Stiebitzhofer, CTO von S1Seven

Team

Unser Team ist sehr klein, wir sind eine junge Firma. Wir haben einen Lead Engineer, der die ganze Architektur verantwortet und wir haben jetzt einen Full Stack Developer, der auf der Front End und auf der Back End Seite tätig ist,

einen Front End Entwickler und halbzeit eine Frau die uns mit UX Design, Grafik versorgt.

Damit haben wir wirklich ein kleines Team, das wir stark vergrößern wollen, um einerseits mehr Skills reinzubringen und andererseits nämlich Redundanz reinzubringen. Also jetzt ist es so, wenn einer krank wird… schwierig, weil dann geht auf der einen Baustelle nichts mehr weiter. Da wir ein kleines Team sind, sind wir sehr formlos organisiert. Also wenn wir von so Organisationen reden für größere Teams – das haben wir alles nicht. Wir haben einmal in der Woche unser Workshop-Meeting, wo wir die Ergebnisse der letzten Woche durchgehen, wo wir planen, wo wir diskutieren, wo gibt es Probleme, was wollen wir machen, wie schaut das aus in Abhängigkeiten mit Projekten – weil wir auch Kundenprojekte haben und viele Seiten quasi ziehen und was wollen – und dann machen wir täglich noch ein kurzes Stand-up meistens remote, also wir sind nur zum Teil im Büro. Es gibt keinen Zwang ins Büro zu kommen – ab und zu muss man ins Büro kommen. Wir wollen in Wien ein Kernteam haben, das man braucht um ein Produkt zum Entwickeln.

So sind wir organisiert – sehr formlos. Was aber auch heißt, wenn wir größer werden, brauchen wir neue Strukturen also mit 5, 10 Leuten sieht das dann anders aus. Aber ich denke, das muss man einfach wachsen lassen und bei Bedarf organisieren,

und das dass Tram – oder die Teams – sich dann selbst organisieren müssen.

Ich komme aus dieser Organisationsberatung, Projektmanagement, ich bin sehr formal und strukturiert – das ist also leicht inkopatibel mit Programmierern, und deshalb will ich es einfach nicht machen. Die Teams müssen sich selber organisieren, ansonsten wird das auf Dauer nicht funktionieren.

An anderer Stelle möchte ich hinzufügen, ich bin kein großer Fan von diesen ganzen Scrum und diesem Superformalen, ich habe da eine bisschen negative Meinung dazu. Nämlich ich glaube das braucht man bei großen Teams von „mittelmäßigen“ Programmieren – sage ich jetzt mal ganz böse – und die wirklich guten Leute organisieren sich selbst. Also ich frage mich da immer, wie bei Google und bei anderen ob die auch alle radikal Scrum machen – und ich bezweifle es! Und das ist auch so eine Erfahrung aus meiner Vergangenheit, wir wollen Leute heuern, die so gut sind, dass diese sich am Ende selbst organisieren.

Das ist unser Projektteam beziehungsweise unser Development Team mit dem wir jetzt arbeiten.

Recruiting

Naja, Hiring ist nämlich ein komplizierter Prozess, weil gute Leute finden sehr schwer ist, beziehungsweise sich sehr wenig Leute am Markt bewegen. Das ist das, was wir auch die letzten Monate verstärkt beobachten – also die Menge an Bewerbern ist gesunken, wir versuchen jetzt wirklich aktiv rauszugehen auf verschiedene Kanälen, Leute zu finden und anzusprechen, mit Erfolg zum Teil manchmal auch nicht. Wir sehen das wirklich als Aufgabe hier verstärkt Energie reinzustecken, also es gibt eine Dame bei uns im Haus, die sich um diesen Aspekt kümmert um das auch wirklich zu betreuen. Wenn wir jemanden gefunden haben, mit dem wir sprechen möchten, dann gibt’s drei Interviews.

Eines ist mit mir das auf der Meta-Ebenen ist, Softwaretechnik, wie die Leute motiviert sind, was interessiert sie an Software, warum wollen sie das tun.

Das zweite mit unseren Lead-Engineer, das ist dann Hardcore-Tech, da redet man wirklich über Code, wie programmiert wird, schauen uns Beispiele an, das ist dann auch intensiv für die Teilnehmer oder Bewerber. Also wir hatten mal auch einen Fall wo einer meinte er zeigt nix vor – naja schwierig, weil wir wollen die Leute kennenlernen, wir wollen sehen wie sie programmieren wie sie denken, wie sie sich wohlfühlen beim Programmieren. Und da ist interessant, Leute die sich im Open Source Bereich bewegen, was die da gemacht haben, welche Projekte sie interessieren – vor allem weil wir auch selbst Teile von unseren Entwicklungen open sourcen, ganz bewusst versuchen diese in die Industrie zu bringen und offene Standards zu schaffen.

Und am Ende gibt es dann noch ein Gespräch mit dem CEO, da wir so eine kleine Firma sind, versuchen wir wirklich genau zu selektieren und dann kommt man an Board – oder auch nicht. Wenn man an Board kommt dann gibt es zwei Teile von Onboarding – der eine ist ganz simpel der formale, administrative Teil, dafür gibt es eine genaue Checkliste, diese arbeitet man in zwei Stunden durch, da gibt es dann die ganzen Informationen welche CE Unterlagen gibt es, wie sieht die Signatur in der E-Mail aus, das ist alle schön vor strukturiert. Einerseits dass es effizienter ist und damit es am Ende auch gleich aussieht, das ist der administrative Teil.

Und dann das Developer Onboarding. Beim Developer Onboarding haben wir wiederum auch einen Guide, den wir der Reihe nach durchführen: was ist die Architektur, was verwenden wir für Systeme, und am Ende geht’s natürlich viel um das, wie ist alles dokumentiert und spezifiziert, wie das zum Beispiel auf GitHub abläuft. Also wir verwenden GitHub für Versionsmanagement für Continuous Integration für Issue Management – und das ist alles in sich automatisiert.

Damit sieht man auch wie es geht – es ist dokumentiert. Ich denke dass es ganz, ganz wichtig ist, dass Sachen dokumentiert sind. Aus meiner eigenen Programmierer Vergangenheit und Entwicklungszeit – ich habe ganz bewusst eine ganz genaue Dokumentation geschrieben mit einem ganz simplen Hintergrund: Erstens bin ich faul, und zweitens bin ich vergesslich. Deshalb will ich eine Dokumentation haben, wo ich nachsehen kann, Copy Paste, ich mache diesen Schritt und diesen Schritt und damit effizient bleibe. Ich möchte damit nicht meine Zeit verlieren und deswegen versuchen wir alle diese repetitiven Tasks – die vielleicht auch nur einmal im Monat kommen – am besten zu dokumentieren oder zu automatisieren. Nämlich nur das macht Softwareentwicklung auch wirklich effizient.

Und dann ist man aus Programmierer ongeboardet und dann beginnt man an kleinen, verschiedenen Teilen unserer Lösung zu arbeiten.

Das ist einerseits Front End lastig und der zweite Teil ist Back End wo auch unterschiedliche Skills gefordert sind. Unser Ziel ist, dass man alle Leute bis zu einem gewissen Grad involvieren. Erstens ist es interessanter und zweitens hat man einen Wissens- und Ideenaustausch und was auch wichtig ist: das Baumproblem gibt es nicht. Dem Programmierer fällt ein Baum am Kopf und dieser ist vier Wochen im Krankenhaus und dann geht nix mehr weiter und es kann kein Fehler behoben werden, das wollen wir ganz bewusst vermeiden, auch mit dem Hintergrund, ansonsten kann man sonst nicht zwei/drei Wochen auf Urlaub gehen. Und wir wollen ja dass sich die Leute erholen und wirklich drei Wochen am Stück in Urlaub gehen können. Das ist mein eigenes Ziel – geht nicht immer – aber das soll den Leuten möglich sein!

Technologien

Viele Challenges! Also wir haben unser Unternehmen 2019 gegründet und haben dann mit einem Developer Team in Warschau gearbeitet. Getrieben durch den Hintergrund, dass mein Co-Founder früher in Polen gearbeitet hat. Haben mit denen eine erste Iteration vom Produkt gemacht, mit dem wir auf den Markt gegangen sind und es mal getestet haben. Dann haben wir eine Testphase gehabt und wir haben eingesehen, dass unser erstes Produkt zu kompliziert ist und deshalb haben wir ein einfacheres Produkt gemacht – schon so ein einfaches Produkt, dass es Programmieren fast schon peinlich ist, weil es so einfach ist – aber es ist super cool und die Leute verstehen es und finden es echt toll und wir glauben auch, dass wir damit extrem erfolgreich werden.

Das haben wir dann wiederum weggeschmissen und haben wieder from-scratch angefangen, um die ganzen Erfahrungen, die Lessons learned, in eine Architektur zu bringen, die man am Ende weiterentwickeln kann, die man technologisch neu aufstellt und skalierbar macht. Auch mit dem Ziel, sauber zu arbeiten, so dass wir wenig technical Debt haben, dass möglichst viele Prozesse automatisiert sind und da bauen wir auf TypeScript auf – also wir machen alles in TypeScript Front End und Back End. Front End ist dann in Angular, Back End ist NestJS und als Deployment Plattform haben wir dann Heroku – Platform as a Service, ist sehr umstritten immer wieder, ich bin ein großer Fan, weil es einem die ganzen Administrationsarbeiten weg nimmt. Die Developer sollen sich meiner Meinung nach mit System Administration nicht beschäftigen und dieses Full Stack wo man dann quasi auch noch System Administration und Deployment und alle diese Dinge – eigentlich ist das furchtbar fad! Eigentlich möchte man Funktionen bauen, Features, das was die Leute sehen, was den Kunden einem Nutzen bringt – und nicht mit irgendwelchen Docker Instanzen rumspielen die dann sowieso irgendwann krachen und dann muss man sich in der Nacht hinsetzten und das ist alles unlustig!

Damit entwickeln wir uns langsam, langsam weiter, jetzt haben wir auch noch den Stack erweitert von GitHub, GitHub Actions, Issue Management dort, über automatisierten Code Review über SonarQube – also wir bauen alle diese Dinge ein um wirklich einen state-of-the-art Development Stack zu haben, damit wir uns am Ende wirklich auf Features konzentrieren können! Weil das ist eigentlich das Spannende. Wir haben eine Microservices-Architektur mit einem Web Front End wir haben eine Blockchain Anbindung, und wir haben dann – das Spannende, weil wir eben in der Stahlindustrie sind – auch die ganzen fachlichen Aspekte, die wir reinbringen müssen. Das heißt wir haben einerseits die Technologie, die Web-Technologie und die Blockchain-Technologie und auf der anderen Seite müssen wir das Know-How aus der Stahlindustrie – mit der wir ja arbeiten – einbringen können.

Und das ist nämlich eine total spannende Challenge, weil es gibt nicht viele Software Developer die sich mit der Stahlindustrie arbeiten – zumindest nicht in Wien, vielleicht in Linz, also die Linzer kommen jetzt auch ganz schnell nach Wien, wenn es interessiert sind. Ich selbst komme eigentlich aus der Energiewirtschaft, und lerne das jetzt quasi wie man die Probleme dieser Industrie lösen und daher müssen wir uns wirklich auf die Probleme der Stahlindustrie fokusieren und andererseits auf die Entwicklung und die Funktionen die wirklich Wert stiften – und nicht auf System Administration.

Ja das wäre Technologie, aus meiner Sicht.

 

 

Erfahre mehr zum DevTeam von S1Seven

Hannes Stiebitzhofer

Interview im September 2021