Als Solo Entwickler in einem Unternehmen arbeiten

Ich bin Projektinitiator, Architekt, Programmierer, Kommunikator, Product Owner und Administrator. Ich bin Leiter und Manager eines Teams. Dieses Team bin ich selbst.

Holy shit, das tut manchmal weh.

Dieser Moment, wenn du in Meetings hibbelig wirst, weil sie länger als 15 Minuten dauern. Wenn du hibbelig wirst, weil du in dem Meeting über ein Projekt redest, während du jede kostbare Minute in die Entwicklung stecken willst, um das, worüber ihr in dem Meeting redet, auch real werden zu lassen.

Dieser Moment, wenn du ein sehr technisches Projekt vorantreibst, das für nicht-Entwickler schwerer nachvollziehbar ist. Du beginnst, das Projekt in Analogien zu erklären. Diese Analogien verselbstständigen sich in den Köpfen deiner Vorgesetzten. Du fängst an, dir zu wünschen, die Analogien nie erwähnt zu haben.

Dieser Moment, wenn du in deiner Rolle als Kommunikator die nächsten Schritte des Projekts deinem Vorgesetzten erklärst und gleichzeitig aufpasst, dass du nicht zu viel versprichst, da du als dein eigener Manager die Teamkapazität genau kennst.

Du versuchst, so wahrhaftig wie möglich zu kommunizieren: dass es unknown unknowns im Projekt gibt. Dass du deshalb gewisse Zusagen nur extrem ungern machst. Dein Gegenüber gibt dir das Gefühl, dass du das schon schaffen wirst. Du hoffst es und hast nur noch mehr Angst vor jenem Tag. Dem Tag, an dem dir klar wird, dass das, was du da losgetreten hast, doch ein Rohrkreppierer ist. Dass es zu schwer ist. Dass es unmöglich ist.

Du machst weiter.

Du löst Teilprobleme. Mit den Lösungen kommen neue Probleme auf. Du löst sie auch.

Du vermeidest verbindliche Zusagen in Meetings immer mehr - weil jede Zusagen direkt auf deinem Stapel landet, als ein Haufen Tickets in deinem Kanban Board.

Du ziehst deine Bahnen stoisch weiter, wie ein stählerner Pflug durch einen kalten, verschneiten Acker. In der Hoffnung, dass dieser Boden fruchtbar sein wird.

Dann passiert es.

Die Teile fügen sich zu einem großen Ganzen zusammen. Deine Architekturkonzepte gehen auf. Deine Abstraktionen erweisen sich als wirklich sinnvoll. Du baust Geschwindigkeit auf. Aus fundamentalen Entscheidungen werden Entscheidungen über neue Features. Aus abstrakten Tickets wie Brainstorme Lösungen, um Problem X generisch zu lösen werden konkrete Aufgaben wie Füge boundary checks ein.

Die Gewässer werden ruhiger. Deine Zuversicht steigt. Die Zuversicht, dass diese getane Arbeit ihren Zweck erfüllen wird. Dass andere Entwickler hier weitermachen können.

Oh, wenn es soweit wäre.

"Erst kommt die Ebbe, dann kommt die Flut" -Kristoffer Jonas Klauß