Wer macht was in der IT?

Joel Kaczmarek: Hallo und ein warmes Willkommen zu einer neuen Folge Blackbox Tech, wie immer mit dem fabelhaften Johannes Schaback. Hallo, Johannes.

Johannes Schaback: Moin, moin.

Joel Kaczmarek: Wie wir es uns zur Aufgabe gemacht haben, wollen wir auch dieses Mal wieder ein bisschen Licht in das Thema IT bringen. Also wer das nicht so lebt, nicht so atmet, wer vielleicht ein bisschen fremd ist, kennt das ja manchmal nicht. Nachdem wir schon viele Bereiche angesprochen haben, nehmen wir heute mal was ganz Grundsätzliches, nämlich Rollen in der IT. Wen gibt es da eigentlich? Was machen Leute, wenn sie mit Technologie und IT zu tun haben? Weil da gibt es ja teilweise wirklich ganz verrückte Bezeichnungen, sowas wie Software-Quality-Manager, ein Software-Architekt, manche sagen CTO, manche sagen CIO. Und unsere Aufgabe ist heute so ein bisschen den Übersetzer zu spielen, was macht eine Person, wenn sie die Rolle X hat, wofür ist sie gut, was ist ihr wichtig, worauf kommt es bei ihr an, weil wenn ich jetzt irgendwie ein Bewerbungsgespräch führe und da sitzt jemand vor mir, der Entwickler ist und ich suche aber eigentlich irgendjemand, der Softwarearchitekt ist oder umgekehrt, das kann ja schon mal zu Konflikten führen und das wollen wir heute so ein bisschen aufklären. Ist das ein Problem, was dir auch oft beginnt in deiner Praxis?

Johannes Schaback: Absolut, total. Und es ist einfach leider auch zu wenig standardisiert. Es hat sich so ein bisschen entwickelt. Und heute können wir vielleicht auch dazu beitragen, dass es etwas standardisierter wird, auch wenn es vielleicht dann ein bisschen meine Darlegung der Dinge ist. Aber grundsätzlich absolutes Problem, auch wenn du ein CV liest, du liest da Software Architect, dann denkst du dir ja was dabei, dann hast du dir ein Bild vor Augen. Und Hoffentlich stimmt dieses Bild, aber erstmal musst du ein Bild vor Augen haben und dann gilt es auch nochmal zu überprüfen, ist das denn wirklich auch ein Architekt gewesen?

Joel Kaczmarek: Gut, dann fangen wir mal ganz oben in der Hierarchie-Kette an mit dem CTO. Manche Unternehmen sagen auch CIO, also steht kurz für Chief Technology Officer oder im Falle von CIO, was ich oft bei so Corporates und DAX-Unternehmen sehe, Chief Information Officer. Was ist das für eine Rolle, was macht so eine Person?

Johannes Schaback: Also der CTO und CIO sind erstmal nicht unbedingt dasselbe. Der CTO kümmert sich sehr stark um die Entwicklung. Sagen wir mal, es gibt kein CIO. Also im Berliner Startup-Umfeld ist es eher, wie du schon sagst, ungewöhnlich, dass es ein CIO gibt. Dann ist sozusagen der höchste Techie, in der Firma oder die höchste Techie in der Firma, der oder die CTO und verantwortet die Produktivität, also das Entwickeln in einem digitalen Umfeld des Software und dass diese Software und das Produkt reibungslos läuft, also operativ funktioniert, dass es keine Downtimes gibt, dass es keine Fehler gibt, dass es keine Bugs gibt, dass das Payment funktioniert etc. Das sind so Aus meiner Sicht die zwei wichtigsten Verantwortungsbereiche eines CTOs, also Produktivität und operative Exzellenz, sage ich dazu immer. Jetzt zu der Differenzierung zum CIO. In großen Firmen ist es so, dass du häufig Produktentwicklung und Betrieb trennst und du hast in großen Firmen, insbesondere in eher herkömmlichen Unternehmen, noch sehr viele administrative Tätigkeiten. Das heißt also, der CIO unterscheidet sich zum CTO, dass der CIO eher im Betrieb veranlagt ist und eher als der oberste Systemadministrator zu verstehen ist. Also der kümmert sich um das Einkaufen von den Laptops, die die Mitarbeiter benutzen sollen, kümmert sich um das Netzwerk, was zwischen den Rechnern liegt, kümmert sich um die Security der Daten aus dem Finance-Bereich, kümmert sich um die Um die Infrastruktur, um die Systemadministration, während der CTO an der Stelle eher für die Produktentwicklung zuständig wäre.

Joel Kaczmarek: Das ist spannend. Ich habe früher für ein Unternehmen gearbeitet, was sich dem ganzen Thema Transparenz in IT bringt, sozusagen verschreibt. Also die müssen wir auch mal hier einladen, sehe ich schon, weil das ist ja auch unser Thema. Der ist, glaube ich, sehr artverwandt. Da hatte ich immer so den Eindruck, dass CIO schon auch irgendwie viel mit der Software zu tun hat. Also wenn du ein großes Unternehmen hast, hast du ja zum Beispiel die Aufgabe, ein technisch Verantwortlicher muss mit den nicht technischen Budgetgebern kommunizieren, sprich beispielsweise ein Vorstand. Und ich hatte gedacht, dass da ein CIO oft auch im ganzen Thema technischer Betrieb auf der Programmierseite.

Johannes Schaback: Absolut, exakt, genau. In einem Startup hast du halt einfach nicht diese Rollentrennung. Da macht der CTO die CIO-Rolle mit. Aber absolut, genau.

Joel Kaczmarek: So. Das ist dann sozusagen so ein bisschen derjenige, der ganz oben den technischen Hut auf hat. Lass uns doch mal sozusagen auf das ganz unterste Niveau springen. Das ist jetzt nicht bewertend gemeint, sondern eher derjenige, der am tiefsten im Detail drin steckt, der sozusagen die kleinste Baustelle macht. Ich denke mir manchmal so eine Technologieabteilung wie so eine Karawane, die durch den Dschungel zieht. Also es gibt jemanden, der haut vorne die Palme um, der ist super geil da drin, irgendwas zu bauen oder sozusagen irgendwas zu verändern. Und dann gibt es den, den wir gerade hatten, der auf der Palme oben drauf sitzt und guckt, wo läuft die Karawane hin. Das ist der CTO. Und zwar, ich spreche gerade von Entwicklern. Ja, oder Developer, wie manche ja auch Neudeutsch auf Englisch sagen. Das ist ja so ein bisschen das andere, was glaube ich vielen sofort ein Begriff ist. Und dann können wir dazwischen mal so die Ebenen aufmachen, was es eigentlich noch für Sonderrollen gibt. Klar, das ist ja eigentlich relativ simpel, aber vielleicht kann man doch nochmal die eine oder andere Ebene mit reinbringen. Was genau macht ein Entwickler im technischen Prozess?

Johannes Schaback: Vielleicht könnte man sogar noch einen Schritt generischer werden und erstmal vom Ingenieur sprechen,

Joel Kaczmarek: um

Johannes Schaback: auch die Eingrenzung eines Entwicklers auf die Entwicklung rauszunehmen, weil ein Entwickler, er oder sie sitzt ja nicht den ganzen Tag vor dem Rechner und entwickelt, schreibt Source-Code, sondern kümmert sich eben auch um Um den Betrieb der Software. in der Regel, also häufig ist das eben nicht getrennt. Deswegen sprechen wir oder sehe ich vermehrt, dass man eher vom Engineer spricht als vom Entwickler. Und dann im Fall eines Entwicklers vom Software-Engineer, also der baut, der ist ein Ingenieur der Software und baut und entwickelt Software weiter, benutzt aber auch bestehende Komponenten, um ein bestimmtes Produkt, um das Produkt zu bauen. Das ist, also der Software-Ingenieur oder der Software-Entwickler ist verantwortlich für in der Regel einen Bereich in einem Team, einen Source-Code zu schreiben, zu programmieren und je nachdem, wie die Firma ausgestaltet ist, das ist sehr individuell, da gibt es durchaus Unterschiede, kümmert sich auch um den Betrieb dieser Software. Also gerade in agilen Umfällen, agil haben wir jetzt auch noch nicht drüber gesprochen, aber da gibt es eben ein Paradigma, das nennt sich You build it, you own it. Das heißt also, wenn du es programmiert hast, dann musst du es auch betreiben, dann gehört es dir auch, dann bist du auch verantwortlich und musst im Worst Case auch nachts um zwei raus und den Bug fixen oder dein abgestürztes Programm wieder starten.

Joel Kaczmarek: Dann lass uns doch mal, weil wir es ja eingangs auch so ein bisschen hatten, diese Rolle, was ist denn, wenn jetzt jemand vor mir sitzt, der eigentlich sagt, er ist Systemadministrator und ich suche aber einen Entwickler. Jetzt lass uns mal den Leuten klar machen, was ist der Unterschied zwischen diesen beiden Rollen, weil man denkt ja immer so, der macht die IT. So denkst du ja als nicht technischer Entscheider, ohne dass das jetzt despektierlich den Personen gegenüber gemeint ist. Was genau macht ein Systemadministrator in Abgrenzung zu einem CTO, CIO oder in dem Fall einem Entwickler, Softwareentwickler oder Engineer?

Johannes Schaback: Es ist auch wirklich nicht ganz einfach. Es ist auch wirklich nicht ganz einfach. Aber wenn ich jetzt über den Kamm geshared sprechen müsste, würde man sagen, ein Software-Engineer oder ein Entwickler schreibt als Hauptaufgabe Source-Code, programmiert, baut am Produkt, trägt zur Produktentwicklung bei. während ein Systemadministrator verwaltet. Kein Sourcecode schreibt, so jetzt Klammer auf, wenn er Skripte schreibt, um beispielsweise Server zu administrieren, dann stimmt das ja so nicht ganz, Klammer wieder zu, aber primär verwaltet er und arbeitet mit bestehenden Programmen, also integriert Programme, installiert Programme, migriert Programme, betreibt diese Programme, überprüft, liest Logfiles und kümmert sich darum, dass die Leute arbeiten können oder dass auch vielleicht einfach die Programme arbeiten können. Das ist so der grobe, grobe Unterschied. Also ganz, wirklich ganz, ganz pauschalisiert. Ein Entwickler trägt zur Produktentwicklung bei, programmiert, und der Systemadministrator nimmt bestehende Programme. Also das kann entweder ein Programm sein, was der Entwickler programmiert hat, oder was eben, weiß nicht, Third-Party-Software ist, Microsoft oder, ja. SAP und lässt eben diese Programme laufen, stellt sicher, dass die ordnungsgemäß funktionieren. Innerhalb der Systemadministration muss man eigentlich nochmal unterscheiden. Also innerhalb der Systemadministration gibt es unterschiedliche Bereiche. Da gibt es zum Beispiel den Bereich, der sich ausschließlich darum kümmert, dass die Mitarbeiter arbeiten können, also in den Offices. Das nennt sich häufig Helpdesking oder Helpdesk. Die laufen rum, installieren Updates, kümmern sich darum, dass die Antivirus-Software bei den Mitarbeitern up-to-date ist, dass die Leute von außen in das Firmennetzwerk rein können, tauschen defekte Hardware aus, Mäuse, installiert aber auch Arbeitsplätze. Das ist Helpdesk. Dann gibt es einen Bereich Networking. In großen Firmen auch als solcher eigenständiger Bereich getrachtet wird. Der kümmert sich ausschließlich darum, dass das Netzwerk zwischen den Mitarbeitern aber auch im Serverbereich funktioniert. Netzwerk ist eben so eine kritische Infrastruktur, dass du jemanden Dediziertes darauf brauchst, der sich sicherstellt, dass eben dieses Netzwerk funktioniert, dass es sicher ist, dass es schnell ist, dass es gut funktioniert. Und dann gibt es noch diesen klassischen Serverbetrieb. Also Operations häufig genannt oder Server Ops, die kümmern sich darum, dass die Server laufen, dass die Server sicher sind, dass sie up to date sind, dass bestimmte Programme, bestimmte Services auf diesen Servern laufen, bestimmte Service Layer Agreements eingehalten werden, dass eine Datenbank schnell genug ist. Die verändern die Datenbank nicht, vielleicht modifizieren sie die Konfiguration, aber sie stellen primär sicher, dass eben der Betrieb funktioniert.

Joel Kaczmarek: Ich habe mich so ein bisschen an Gründerszene-Zeiten erinnert gefühlt. Da hatten wir einen sehr, sehr tollen Entwickler, Schrägstrich IT-Verantwortlichen, wie das mal so ist, in so einem Start-up hat er eigentlich alles gemacht. Der hat sich schon genommen entwickelt, aber auch irgendwie verantwortet und gemanagt. Und das war auch immer erste Ansprechperson zu, hey, mein Rechner geht nicht, kannst du mir damit helfen? Und er hat immer ein bisschen abgekotzt, was ich auch total verstehen kann, aber immer ganz treu geholfen. Also das ist ja mal wirklich so ein Beispiel, wo man merkt, ganz, ganz andere Rolle als Laie, Gerade wenn du jetzt, sagen wir mal, du bist im Accounting oder im Sales oder so, dann siehst du ja jemanden sitzen, der macht Computer und dann gehe ich auch zu dem hin, wenn mein Computer kaputt ist. Dass der aber eigentlich Source-Code schreibt oder irgendwie in einer völlig anderen Domäne ist, ist einem gar nicht so klar. Von daher an dieser Stelle einen warmen, herzlichen Dank an Pascal, der damals viel bei uns ausgehalten hat und an alle anderen, die das auch müssen.

Johannes Schaback: Absolut. Das ist ja auch gerade in Stylers immer so, dass sozusagen unter einem Hut sehr viele Rollen sich vereinen. Man spielt ganz viele Rollen und dann ist man eben Systemadministrator für den Serverbereich, aber eben halt auch für die Mitarbeiterrechner. Und das ist auch ein hammer, hammer schwieriger Job. Als CTO verantwortet man das ja mit und muss sich eben entsprechend auch darum kümmern, dass die Administration funktioniert. Und es ist wirklich ein echt schwieriger Job. Man denkt da immer Ja, das ist irgendwie nicht so schwierig wie entwickeln. Das stimmt aber gar nicht. Also eine gute Systemadministration ist echt schwierig. Und damit das gut funktioniert, es erfordert sehr viel gutes Projektmanagement, sehr viel gutes Nachhalten. Man muss sehr tief in Details reingehen. Man muss sehr viele Fehler nachhalten. Es ist ja eine Dienstleistungsart und Weise. Man muss ja Leuten helfen, dass sie arbeiten können. Aber wie in häufigen Startups, es entfallen viele Rollen auf eine Person.

Joel Kaczmarek: Also jeder, der das heute anhört, der kann mal irgendwie zu seinem, wie immer er genannt wird, Technikverantwortlichen gehen, ihm einen Kaffee mitbringen und einem warmen Danke auf die Schulter klopfen. Die sorgen dafür, dass ihr arbeiten könnt und manchmal ist es vielleicht gar nicht ihre Aufgabe und sie machen es trotzdem. Also seid mal lieb zu denen. So, zwischen den beiden Rollen Systemadministration und Entwickler gibt es ja meines Wissens auch noch irgendwie eine Art Layer dazwischen. Also ich glaube, so könnte man das so ein bisschen verorten, was immer so gemeint wird als DevOps benannt wird. Vielleicht kannst du da ein, zwei Sätze mal zu sagen, so ein bisschen erklären, was das eigentlich genau ist, was da genau gemacht wird.

Johannes Schaback: Genau, DevOps ist in der Tat genau auf der Schnittstelle zwischen Entwickler und Operations, daher auch der Name, und kümmert sich darum, dass der Code, der geschrieben wird, auch operativ funktioniert. Also der DevOpsler ist dafür verantwortlich, dass der Code in Production auch wirklich läuft, also in der Umgebung, in der Serverumgebung, in der er letztendlich laufen soll, auch wirklich funktioniert. Er kümmert sich aber auch häufig um Integrationstests oder auch um das Ausführen von Tests und im Grunde um infrastrukturelle Fragen sehr nah um die Entwickler herum. Also manche DevOpsler kümmern sich beispielsweise um die Entwicklungsumgebung, die auf den Rechnern läuft, der Entwickler. Das ist ganz interessant, weil das ja häufig auch als Systemadministrator-Job verstanden wird. kümmert sich dann aber eben auch darum, dass OpenVPN-Keys ausgetauscht werden. Wenn du jetzt in einem klassischen Cloud-Hosting-Umgebung bist, wie jetzt in Amazon oder in Google Cloud-Plattformen, würde der DevOpsler sich darum kümmern, dass dein Code hochgeladen wird, dass der kompiliert wird, dass die richtige Version läuft und kümmert sich im Grunde um Betrieb. Aber nochmal ist es häufig so, dass ein Entwickler dann Ein Teil plötzlich in eine DevOps-Rolle springt und dann als DevOpsler eben seinen eigenen Code ausrollt. Das gibt es auch. Also es ist grundsätzlich, es gibt diesen Blumenstrauß an Rollen in der Regel immer erst, wenn ein Unternehmen eine gewisse Größe erreicht, sodass diese Spezialisierung noch Sinn macht.

Joel Kaczmarek: Hervorragend. Also jetzt haben wir irgendwie die Level konkreter Macher, Entwickler besprochen. Wir haben denjenigen sozusagen thematisiert, der das Ganze am Leben hält, technischer Art. Und wir haben denjenigen besprochen, der es managt, ganz oben. Also von Macher bis Manager. Jetzt gibt es ja dazwischen, immer wie gesagt, nicht gedacht als Hierarchie, als Bewertung, sondern einfach als Funktionsrolle, unterschiedliche Ebenen, die wir jetzt vielleicht auch mal so ein bisschen schärfen können. Eine, mit der ich mal anfangen würde, man sehe mir nach, wenn es nicht immer der logische Aufbau ist, vielleicht gibt es bessere, aber das ist ja auch ein bisschen schwierig. Jeder hat das ja anders, das hast du ja auch gerade gesagt. Aber ich finde so dieses ganze Thema Software-Architekt ganz interessant. Also dass man sagt, es gibt da wirklich jemanden, der wie ein Architekt eine Software verantwortet. Was genau macht so eine Rolle und welche Bedeutung hat sie?

Johannes Schaback: Software kann man sich im Grunde vorstellen wie ein großes Haus oder ein großes, großes Bau unterfangen, in dem ganz viele Komponenten ineinander greifen müssen, ineinander funktionieren müssen und zusammenarbeiten müssen. Und ein Architekt, um in diesem Bild zu bleiben, kümmert sich darum, dass diese Komponenten, dass dieses große, dass du deinen Überblick behältst über den gesamtheitlichen Status dieser Software, aber auch des Vorhabens des Bauens dieser Software. Und mein Architekt weiß eben um die unterschiedlichen Verantwortungsbereiche unterschiedlicher Module oder Teile von der Software, die du baust und weiß auch, wie die miteinander sprechen und kümmert sich als ein konkretes Beispiel um die Protokolle, die die Module oder die Services miteinander sprechen. und sorgt dafür, dass im Grunde ein einheitliches System, ein einheitliches funktionierendes Ganzes, großes Ganzes entsteht. Ähnlich wie eben auch im Bau. Der Software-Architekt hat in der Regel sehr viel Erfahrung, kennt sich in allen Bereichen sehr gut aus, ist also auch in der Regel schon länger im Unternehmen, hat aber eben auch die Autorität, bestimmte Qualitätsanforderungen durchzusetzen, also bestimmte Test-Coverages, also wie Gut, ist mein Code getestet oder dokumentiert oder er kümmert sich auch darum, dass bestimmte Konventionen eingehalten werden. Also wie soll der Source Code aussehen in der Formatierung? Es ist ja Text letztendlich. Um solche Themen kümmert sich ein Software-Architekt und es ist eben eine Senior-Rolle, es ist eine vollselfte Erfahrung, das ist wichtig. Ja, das ist es, denke ich.

Joel Kaczmarek: Also zusammengefasst kann man so ein bisschen sagen, ein Architekt ist so ein Stück weit ein Alleskönner, zumindest ein Vielkenner vielleicht und ein Strukturgeber in so einem Konstrukt. Heißt das dann konsequenterweise, dass ein Software-Architekt irgendwie eine Rolle ist, die eher später im Lebenszyklus von einem digital getriebenen Unternehmen auftaucht? oder sollte man so etwas schon sehr, sehr früh mit berücksichtigen?

Johannes Schaback: Wenn du auf einer grünen Wiese was aufbaust, bist du natürlich auch automatisch ein Architekt, weil du ja bestimmte Designentscheidungen treffen musst, wie deine Plattform läuft. Dann bist du relativ schnell in einer Architektenrolle. Ein Architekt erfordert aber, wie du schon richtig sagst, viel Erfahrung. Es muss viel gesehen haben. Ein Architekt muss auch immer wissen, das, was wir gerade machen, Unter den Umständen ist wirklich optimal. Oder verlieren wir zu viel Zeit mit Bug Hunting oder sind wir eigentlich okay im Ratio? oder ist unsere Architektur wirklich so, so, so dermaßen stark veraltet, dass wir wirklich switchen müssen auf eine andere Technologie oder einen Teil des Systems umbauen müssen. Das sind ganz, ganz schwierige Entscheidungen, die auch schwer quantifizierbar sind, weil sie sehr viel Vorhersage erfordern, wie schneller oder produktiver man wird in der Zukunft. Das sind solche Entscheidungen, die ein Architekt treffen muss und das kann er auch erst, wenn er wirklich etliche Zahlencode gelesen hat in seinem Leben und in dem bestehenden Unternehmen oder in dem bestimmten Umfeld, in dem er sich bewegt, das System in- und auswendig kennt.

Joel Kaczmarek: Also man merkt, das ist schon ein bisschen auch eine etwas seniorigere Rolle. Absolut. Vom Erfahrungsgrad und wahrscheinlich auch ein bisschen teurer, deswegen vielleicht leistet sich der andere den deswegen etwas später.

Johannes Schaback: Und man muss auch sagen, es gibt Unternehmen, die sagen, wir brauchen keine Architekten, weil wir uns dermaßen stark an Konventionen halten und sozusagen unsere Organisation so gebaut haben, unsere Teams so geschnitten haben. dass du keinen Architekten brauchst, weil jedes Entwicklerteam so eigenständig agieren kann und so eigenständig sein eigenes Produkt, sein eigenes Problem lösen kann, dass du eigentlich keinen übergeordneten Architekten brauchst, als dedizierte Rolle zumindest, also als ein Software-Architekt. Die Architektur ist per se inherent schon so gut, dass du eigentlich keinen Architekten mehr brauchst.

Joel Kaczmarek: Eine andere Rolle, die wahrscheinlich so ein bisschen artverwandt ist, ist ja die des Software-Quality-Managers. Also man hört ja schon so ein bisschen raus, wenn es um Qualitätsmanagement geht, würde ich mal tippen, ist das eine Person, die dort ins Spiel kommt. Vielleicht kannst du ja mal mit eigenen Worten wiedergeben, was so eine Person macht, wann sie sinnvoll ist.

Johannes Schaback: Der Software-Qualitätsmanager kümmert sich darum, dass die Software das macht, was von ihr erwartet wird. Ohne dass wir jetzt über den Produktmanager gesprochen haben oder den Product Owner, besteht ja immer für jede Software eine Spezifikation, also eine Vorstellung, was diese Software machen soll. Die wird in unterschiedlichen Artefakten niedergeschrieben, also entweder in Screenshots oder in Tickets mit Abläufen, was passieren soll oder vielleicht auch einfach nur in einem informellen Gespräch. Und dieses Verständnis, was die Software machen soll, diese Erwartung an die Software muss überprüft werden. Das macht natürlich der Entwickler schon mal zu einem gewissen Teil, weil er muss sie ja bauen. Der kriegt deklarativ gesagt, das ist das, was die Software am Ende machen soll. Make it so. Und er fängt an zu coden. oder sie fängt an zu coden und dann wird am Ende muss aber überprüft werden, ist das auch wirklich das, was wir erwarten? Und da gibt es dann unterschiedliche Anforderungen. Beispielsweise in Agenturen gibt es dann die Anforderung, dass du kein Pixel breit abweichst. Ich denke mir das ein Stück weit aus, aber unterschiedliche Anforderungen für unterschiedliche Businesses, dass du von deinen Screenshots nicht abweichen darfst. Oder ein Tester kann eben auch prüfen, dass die Response Time deiner Website eine gewisse Zeit nicht oder Länge nicht überschreitet. Der kann auch überprüfen, dass eben, das ist ja auch ein häufiges Problem, dass du an einer Stelle das Code etwas veränderst und an einer ganz anderen Stelle stößt du außerdem mit dem Hintern etwas um, ohne dass du es willst. Und plötzlich sieht auf einer anderen Seite der Website etwas ganz kaputt aus. Das ist etwas, was der Tester testen muss und kümmert sich letztendlich um die Qualität des Produktes und die Qualität der Entwicklung.

Joel Kaczmarek: Jetzt hast du ja schon richtig angedeutet, wir haben uns ein bisschen von den Management-Ebenen zu den Macher-Ebenen, zu den Qualitätsebenen durchgehangelt. Jetzt gibt es natürlich noch irgendwie Manage-Ebenen dazwischen. Das heißt, ein Entwickler wird in der Regel wahrscheinlich an jemanden reporten oder von jemandem koordiniert werden, der den Hut auf hat für ein bestimmtes Projekt. Und dann gibt es wieder sozusagen Überbereiche. Das ist ein bisschen so pyramidenhaft. Das heißt, man clustert das immer kleiner. Begriffe, die mir da unterkamen, waren irgendwie sowas wie Software-Project-Manager oder Software-Development-Manager. Ist das richtig so? Also muss man sich das so vorstellen, dass man irgendwie viele Entwickler hat, die auf einem Projekt sitzen, die werden von einem Manager gemanagt, darüber gibt es wieder einen, darüber wieder einen, bis irgendwann der CTO kommt. oder ist das irgendwie falsch oder vereinfacht gedacht?

Johannes Schaback: Die Unternehmen legen das sehr unterschiedlich aus. Es gibt sehr traditionelle Unternehmen, die sozusagen Projektmanagement und auch technische Verantwortung sehr eng zusammenführen. Es gibt viele Firmen, die Produktentwicklung von der technischen Umsetzung trennen. Dann gibt es auch wieder viele Unternehmen, die sagen, wir wollen eigentlich unser Line-Management, also sozusagen das direkte Vorgesetzte, beispielsweise wer kümmert sich um Urlaubsanträge, Gehaltserhöhungen, trennen von der technischen Umsetzbarkeit. Das wird sehr, sehr unterschiedlich ausgelegt und sehr unterschiedlich strukturiert. Letztendlich ist es so, es muss Geld verdient werden, ganz klar. Und das Unternehmen, auch abhängig in welcher Branche es ist, guckt sich an, was ist uns wichtiger, dass wir einfach jetzt nur einfach den Betrieb sicherstellen oder dass wir möglicherweise auch sehr schnell produktiv sind. Und dann versuchen wir unsere Incentive-Modelle oder unsere Company-Struktur dahingehend auszulegen, dass eben diese Anforderungen entsprechend gewichtet werden. Häufig beobachtet man die Struktur so, dass es sehr flach ist im Sinne der Hierarchien. Es gibt sehr wenig Hierarchie-Ebenen. Das heißt also, Entwickler haben einen Vorgesetzten und dieser Vorgesetzte ist dann schon wiederum der CTO. Das führt dazu, weil die ja sehr breit ist, die Organisation, dass auf einen Line-Manager sehr, sehr, sehr, sehr viele Entwicklerinnen und Entwickler entfallen,

Joel Kaczmarek: was

Johannes Schaback: wiederum dazu führt, dass ja dieser Line-Manager sich gar nicht um die einzelne Person kümmern kann, sondern dass sehr viel in dem Team bestimmt wird oder eben durch 360-Grad-Reviews sehr stark quantifiziert wird, wie die Performance, die Bewertung eines Mitarbeiters wird. Das hat den Vorteil, dass du eben nicht in hierarchischen Hühnerleiter-Strukturen denkst, sondern dass du eben sehr frei bist, dass das Team wichtiger ist als dein persönlicher Karrierepfad nach oben, weil es nach oben gibt. Es gibt de facto kein nach oben. Natürlich gibt es ein Line-Management nach oben, aber in der Regel bei so breiten Strukturen wird neben diesem klassischen People-Management auch eben ein technischer Expertise-Pfad aufgemacht. Das heißt, ich kann Karriere machen, indem ich mich einer bestimmten Technologie weiterentwickele und da dann eben ein Experte werde oder weil ich ein Influencer werde für einen bestimmten Bereich oder ein Produkt, weil ich mich eben super gut mit Ad-Tech auskenne oder weil ich mich super gut mit Datenbanken auskenne. In dem Bereich kann ich mich dann weiterentwickeln. Das hat aber erstmal nichts damit zu tun, dass ich dann jemandem sagen kann, okay, du hast das und das zu tun oder zu lassen, sondern das ist dann eher eine technische Expertise. Und dadurch, dass du aber eben der, wenn du jetzt in so einem Bereich bist, der absolute Experte für Datenbank bist, hören auch alle auf dich. Das ist so ein bisschen die Konvention. Grundsätzlich ist das eine Form der Organisation, die man sehr häufig beobachtet.

Joel Kaczmarek: Hervorragend. Ich würde sagen, wir halten uns heute mal echt knapp und konstant, weil wir wollen den Leuten ja nur kurz so ein bisschen mit auf den Weg geben, welche Rollen es gibt.

Johannes Schaback: Wollen wir vielleicht den Product Owner oder den Product Manager und den Project Manager nochmal differenzieren? Ich habe das Gefühl, das ist auch häufig sinnvoll. Es gibt hin und wieder, sieht man, das ist Unterschiede in der Wahrnehmung, was ist jetzt dieser Product Owner, was ist der Project Manager oder Product? Wie differenziert sich das? Man muss dazu sagen, es gibt eben im klassischen Projektmanagement eben einen Projektmanager. Das ist einfach so. Das brauchst du, weil du jemanden brauchst, der sich überlegt, was sind die Voraussetzungen, um ein bestimmtes Produkt zu bauen? Wie viele Entwickler brauchen wir? Können wir das überhaupt? Was schätzen wir, auch wenn man das nicht machen soll? Wie lange wir dafür brauchen? Was sind die Kosten damit? Und durch den Einzug vieler dieser agilen Methoden, des Lean-Managements, wird ja immer sehr stark versucht, eigentlich diesen Waterfall, also ich mache heute einen Planungsstand, dann mache ich den nächsten Planungsstand, dann mache ich den nächsten Planungsstand und wenn dann aber in der Mitte irgendwo was in die Hose geht, dann ist meine komplette Planung im Arsch. zu vermeiden, sodass man eben sagt, wir versuchen eigentlich eher kurzfristig agil zu entscheiden und immer nur Planungsschritte von zwei bis vier Wochen zu machen, weil wir einen größeren Zeitalter eigentlich gar nicht so richtig überblicken können. Und damit wird das Projektmanagement eben ein ganz anderes. Und dieses Projektmanagement wird sehr stark dann vereinnahmt von einer Rolle, die das Produkt in einem betriebswirtschaftlichen Sinn verantwortet. Und das ist der sogenannte Product Owner. Das ist aber eine Rolle, die sehr stark geschaffen wurde oder auch definiert wurde durch dieses Lean Management, das ist das Agile Management. Und der Product Owner verantwortet den Erfolg des Produktes am Markt. Das ist so meine Definition und kümmert sich eben insbesondere betriebswirtschaftlich darum, dass ein möglicherweise sehr technisches Produkt aber eben auch am Markt erfolgreich ist. Und der achtet eben darauf, dass die Nutzer happy sind, der achtet darauf, dass die Usability stimmt, der bei dem Laufen, User Experience, User Interface, aber auch eben Funktionalität, also Tag zusammen und ist häufig auch im Line Management, also im Sinne des Vorgesetzten, auch wirklich ein Vorgesetzter. In vielen Agile Setups aber eben auch einfach nur eine Rolle in einem Team, genauso wie der Entwickler auf gleicher Ebene im Organisationssinn. Und da muss man jetzt einfach unterscheiden, der Product Owner verantwortet das Produkt im betriebswirtschaftlichen Sinne, also im Sinne des Erfolgs am Markt, während der Projektmanager sich in großen Anführungsstrichen nur verantwortet. um den reibungslosen Ablauf, der der Produktentwicklung beispielsweise jetzt in dem Kontext oder um eines Projektes kümmert. Hat aber eigentlich damit nichts zu tun, ob jetzt das Produkt, was da entwickelt wird, nachher erfolgreich ist oder nicht.

Joel Kaczmarek: Ja, ich meine, es ist ja ganz wichtig, dass du das mal ansprichst, weil genau solche Sachen missversteht man ja. Hä, ich dachte, Projektmanager ist der? Warum bist du jetzt Produkt-Owner? Was ist denn da der Unterschied? Also gebe ich dir komplett recht, das sind ja auch so die Sachen, die dann irgendwie schnell zur Verfügung führen.

Johannes Schaback: Total und das wird auch in jeder Firma nochmal, ich wiederhole mich da ein bisschen, aber in jeder Firma leicht anders ausgelegt und es ist auch wirklich nie so ganz trennscharf.

Joel Kaczmarek: Also ich hoffe in diesem Sinne, dass wir euch da draußen auch ein bisschen helfen konnten, solche Rollen besser zu verstehen, dass wenn ihr mal irgendwie im Vorstellungsgespräch sitzt oder auf der anderen Seite vielleicht euch mal irgendwie ein Angebot oder eine Ausschreibung durchlest und fragt, passe ich da eigentlich

Johannes Schaback: auch zu?

Joel Kaczmarek: Könnte ich das nicht auch machen, dass man so ein bisschen Gefühl kriegt, was da eigentlich von wem gemacht wird? und wie gesagt, geht mal irgendwie zu eurer Technikverantwortlichen, egal ob sie jetzt CTO oder Scorer-Geschichten oder was auch immer machen. Architekten sind Quality-Manager und klopft denen ein bisschen auf die Schulter und bringt ihnen irgendwie die Mate an den Tisch. Die freuen sich. In diesem Sinne, ich danke dir, Johannes, und ich danke euch fürs Zuhören.

Johannes Schaback: Sehr gern. Vielen Dank.