TechLead-Story: Matthias Posch, CTO bei tubics

TechLeadStory

Matthias Posch

Team

Wie groß ist das Dev-Team? Wie setzt sich das Team, in Funktionen aufgeteilt, zusammen?

Wir sind zurzeit fünf Personen im Team. Ein Teamlead, zwei Frontend Devs und zwei Backend Devs. Einer der Backend Devs ist zugleich auch Sysadmin und kümmert sich um die Stabilität der Infrastruktur. Frontend/Backend können sich auch mal überschneiden, also Frontend Devs können mal den ein oder anderen Endpoint entwickeln und Backend kann mal die ein oder andere Seite im Produkt bauen.

Wie ist euer Dev-Team organisiert und aus welchem Grund habt ihr euch für eine bestimmte Organisation entschieden? Worin liegen die Vorteile, wo die Nachteile?

Wir haben über die Zeit eine "tubics-scrumban" Variante entwickelt. In der wir Anleihen von verschiedenen Methodologien ziehen, die optimal zu unserem Teamsetup und Umfeld passen. Konkret arbeiten wir mit zwei-Wochen Sprints, Sprint-Planning Meetings inkl. Story Points Schätzung, Sprint Restrospektiven, Pair Programming, Pull Requests und Peer Reviews. Weiters gibt es Teammeetings nach größeren Crashes/Bugs um zu identifizieren, was der Fehler war und wie diese in Zukunft vermieden werden können. Daraus werden meist sehr wertvolle Learnings gezogen und helfen, das Gesamtsystem besser zu verstehen.

Wir arbeiten in einem sehr agilen, sich ständig ändernden Umfeld. Daher ist uns wichtig zu Beginn des Sprints ein Minimalset an Tickets zu identifizieren, die wir bis Sprintende liefern wollen und einen großen Puffer zu lassen, für weitere Feature Requests oder Bugs, die während des Sprints aufkommen. So können wir auch während des Sprints auf Änderungen der Außenwelt optimal reagieren und trotzdem ein gewisses Commitment für Sprintende einhalten.

Auf höherer Ebene gibt es ein Product Team, dass sich mit zukünftigen Features und der strategischen Richtung des Produkts beschäftigt. Daraus leiten sich abstrakte User Stories ab, die dann im Dev Team - on-demand mithilfe eines UX/UI Designers - im Detail spezifiziert und für den Sprint vorbereitet werden.

Zum Know How Transfer veranstalten wir immer wieder sogenannte "tubics-Sessions", in denen ein Teammitglied ein gewisses Thema vorbereitet und präsentiert. Letztes Beispiel war E2E Testing Framework "Cypress", das wir folgend als fixen Bestandteil in unseren Entwicklungsprozess aufgenommen haben.

Wir legen auch viel Wert darauf immer wieder Remote-Tage machen zu können. Wir sind es gewohnt Meetings als Video-Call zu veranstalten und sehen das auch nicht als Hemmschwelle. Das gibt den Leuten die nötige Freiheit auch mal nicht im Büro sitzen zu müssen, wenn es einen guten Grund dafür gibt.

Was macht euer Team im Vergleich zu anderen Teams besonders ?

Wir haben in der Vergangenheit viele Entwicklungsmodelle und Teamkonstellationen ausprobiert. Unsere Stärke ist, dass wir uns sehr gut mit etablierten Entwicklungsmodellen und Theorien auskennen, aber nicht davor zurückschrecken, sie an unsere einzigartige Situation anzupassen. Dadurch lernt man sich gegenseitig besser kennen und kann auf die persönlichen Stärken und Schwächen besser eingehen. Wir gehen Fehlern bis zu deren Ursprung auf den Grund, ohne abwertend mit dem Finger auf Individuen zu zeigen. Wir behandeln unseren Code nicht als persönliches unantastbares Heiligtum, sondern versuchen voneinander zu lernen und somit das Produkt als Ganzes und als eingeschworenes Team zu ownen.

Recruiting

Wie ist eure Dev-Abteilung in den Recruiting-Prozess integriert?

Je nach Bereich kann es vorkommen, dass ein Frontend- oder Backend-Entwickler im zweiten Bewerbungsgespräch teilnimmt. Weiters werden die Code Beispiele der Bewerber im Team besprochen.

Gibt es ein konkretes Prozedere für neue Kollegen? Wie werden diese integriert?

Am ersten Arbeitstag gibt es ein längeres Einführungsmeeting mit dem Teamlead um alle Accounts, Zugänge und eine lokale Entwicklungsumgebung aufzusetzen. Weiters wird die Entwicklungsmethode und alle zugehörigen Meetings und Prozessschritte erklärt wie bspw. der JIRA Workflow. Danach geht es direkt an den Code mit einer ersten User Story. In den ersten Wochen wird vermehrt Fokus auf 1on1 Gespräche mit dem Teamlead gelegt, aber abgesehen davon integrieren wir neue Kollegen vom ersten Tag an vollwertig ins Team, mit allen dazugehörigen Aufgaben, Meetings etc.

Natürlich werden neue Kollegen auch gebührlich mit einem Feierabendbier willkommen geheißen. :)

Neben der fachlichen Qualifikation, worauf legt ihr noch Wert, wenn ihr nach Entwicklern für euer Team sucht?

Für uns als Startup ist der Teamfit und die Arbeitseinstellung mindestens genauso viel wert wie die fachlichen Kompetenzen. Ein guter Entwickler muss in der Lage sein, sich selbstständig in eine neue Umgebung einzuarbeiten. Er/Sie muss seine eigenen Prinzipien in die Code Basis einbringen, ohne dabei den bestehenden Code umzureißen. Entwickler müssen prinzipiell kritikfähig und mit konstruktivem Feedback umgehen können. Man sollte über gewisse Problemlösungskompetenzen verfügen - also in der Lage sein, komplexe Probleme zu zerlegen und mit Lösungsvorschlägen für kleinere Bruchstücke aufkommen. Zeitgleich darf man sich auch nicht zulange einbunkern und scheuen nach Hilfe zu fragen, wenn man nicht weiter kommt. Diese Gratwanderung ist ein unglaublich wertvoller Skill.

Technologien

Welchen technischen Herausforderungen seht ihr Euch gegenüber?

Unser primärer Datenlieferant ist die offizielle YouTube API. Dadurch ergibt sich eine unglaublich große Abhängigkeit zu EINER Schnittstelle, deren Auswirkung in der gesamten Applikation spürbar sind. Das stellt uns immer wieder vor Herausforderungen/Probleme/Restriktionen, für die wir sehr kreative Lösungen entwickeln müssen, um unseren Usern trotzdem eine optimale Experience bieten zu können.

Mit welchen Technologien arbeitet ihr?

Angular, Node.js, ExpressJS, TypeScript, MySQL, Docker, cypress und einigen third-party APIs.

Wie hat sich die Technologie des Unternehmens seit der Gründung verändert?

Das Grundgerüst der Applikation hat sich seit Beginn nicht verändert. Dinge wie Folderstruktur, Modulsystem etc. sind gleich geblieben. Wir arbeiten mit Microservices, da sind natürlich seit Beginn einige dazu gekommen.

Unser Backend hatten wir zu Beginn auf Heroku gehostet und sind dann aufgrund explodierender Kosten auf Google Cloud Platform mit Docker Swarm gewechselt.

Unabhängig davon hat sich natürlich unsere Art zu entwickeln stark verändert. Je reifer das Produkt wurde, desto mehr Aufwand wird in Logging und Fehlerhandling investiert.