Welche Skills brauche ich, um gute Produkte zu bauen?

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von digital kompakt und heute geht es mal wieder um das Thema Produkt. Denn immer wenn ich über Produkte nachdenke, dann kommt bei mir der liebe Björn Wagner in den Kopf. Den kennt ihr vielleicht, der ist ja regelmäßig bei uns zusammen mit Till Reiter. Björn ist nämlich VP Engineering bei SAP Signavio, bewegt da halt eine echt große Organisation, hat aber auch schon beide Welten gesehen. Also früher mehr Startup, jetzt mehr Konzern darf man ja schon sagen. und wir haben uns überlegt, dass es mal spannend ist zu diskutieren, welche Skills brauche ich eigentlich, um gute Produkte zu bauen? Ja, wir haben ja schon mal über Rollen geredet, über Karrierepfade, wir haben vielleicht auch über Teamzusammenarbeit geredet, aber eigentlich noch nie so richtig. Was muss ich denn können, wenn ich in dem Bereich sein möchte? Und da werden wir euch mal die fünf Skills vorstellen, die jeder da eigentlich braucht. Und warum es vielleicht doch gar nicht so schlecht ist, in der Schule ein bisschen Mathe und Physik gehabt zu haben. Also freut euch, eure Bildung ist offensichtlich gut investiert gewesen. So, von daher lieber Björn, moin moin.

Björn Wagner: Moin.

Joel Kaczmarek: Hast du denn gut in Mathe in der Schule?

Björn Wagner: Es hing sehr stark von der Klasse ab, sage ich mal. Es wurde besser. Von der Klasse, nicht vom Lehrer. Es wurde besser über die Zeit auf jeden Fall, ja.

Joel Kaczmarek: Ja, du hast ja das Thema heute so ein Stück weit mitgebracht. Wie war denn so dein Entree dazu? Also was war so der Auftaktgedanke, der dir kam?

Björn Wagner: Ich komme hauptsächlich aus der Richtung, dass wir schon viel über Rollen, über cross-funktionale Teams geredet haben, welche, wie mache ich Entscheidungen und so weiter. Und was mich natürlich im Kern immer interessiert ist, hauptsächlich unabhängig von den Rollen, welche Skills, welche Fertigkeiten muss ich denn eigentlich mitbringen, um erfolgreich Produkte zu entwickeln. Was heißt erfolgreich? Produkte, die am Ende die Kunden lieben, wie man so schön sagt und die dann je nach Kontext auch noch Revenue, Marge für die Firma abwerben am Ende des Tages.

Joel Kaczmarek: Mich begleitet dieser Satz gerade einmal die ganze Zeit. Verlieb dich nicht in Produkte oder Lösungen, verlieb dich in die Probleme. Von daher, das wird ja genauso das Ex sein, in dem wir aktiv sind. Und dann lass uns doch mal reinschauchen. Also wie gesagt, fünf Skills, die wir definiert haben, die sich so in drei Bereiche unterteilen lassen. Und die drei Bereiche sind Problemlösungen. Und dann das Zweite, das hast du Shape Solution auf Englisch genannt. Also Shape eher, glaube ich, gedacht als Verb, nicht als Substantiv, sondern wie man die Lösung sozusagen formt. Und als Letztes, wie man die Execution skaliert. So, die drei Bereiche. So, und wenn wir jetzt mal anfangen mit dem Ersten. dem Problem lösen, dann ist ja irgendwie relativ klar, also da hat man schon so eine Ahnung, warum Matheunterricht vielleicht ganz gut gewesen sein könnte. Also du sagtest so im Vorgespräch zu mir, Kreativität beim Problem lösen und so eine gewisse Kundenempathie, das ist so dasjenige, welche, wenn du sowas feststellst bei jemandem, ist das sehr wertvoll für dein Team.

Björn Wagner: Genau, genau, absolut. Also wie gesagt, in so einem Team hat man ja verschiedene Rollen, in der Regel man hat Designer, Product Manager, Product Owner und dann Entwickler, meistens mehrere Entwickler pro Team natürlich, mit denen man gemeinsam die Kundenprobleme löst, die Lösung baut, validiert und dann am Ende auch schaut, ob quasi der erhoffte Value, das heißt man das geplante Kundenproblem auch lösen konnte, so ganz vereinfacht gesagt. Und im Kern des Ganzen, ich sage eigentlich ganz gerne, wir sind keine Entwicklungsorganisation, wir sind eine Problemlösungsorganisation. Also das ist für mich der aller, aller wichtigste Skill. Wie kann ich kreativ Probleme lösen? Und ich bin mir noch nicht ganz sicher mit dem Wort Empathie, aber für mich ist das immer wichtig. so nah wie möglich an den Problemen des Kunden dran zu sein. Und dann quasi muss man die Verbindung schaffen. Man sagt, okay, man hat jetzt das Kundenproblem wirklich im Detail verstanden und schafft dann die Verbindung mit dem Technologiewissen, was man hat, wie man das Kundenproblem mit einer bestimmten Technologie konkret umsetzen kann. Dann testet man ganz viel, man validiert das, man baut das vielleicht in verschiedenen Versionen. Und man schaut dann natürlich dabei, dass man dann das Problem auch wirklich gelöst hat. Man lernt ganz viel dabei. Vielleicht lernt man auch, dass gewisse Sachen nicht so funktionieren, wie man es gemacht hat. Dann stellt man die wieder ein. Aber im Kern des Ganzen, egal ob ich ein Designer bin, ob ich ein Product Manager bin, ob ich ein Engineer bin, im Kern des Ganzen steht für mich wirklich die kreative Problemlösung. Und jetzt kann man natürlich sagen, nochmal vielleicht auf diesen Empathieaspekt einzugehen. Also die einfachste Art oder direkteste Art der Empathie ist, wenn man selber der Kunde des Produktseins kann. Ich glaube, das ist einer der wesentlichen Punkte, warum auch, sage ich mal, im B2C-Bereich Produkte, wenn es um Usability oder ähnliche Aspekte geht, sehr weit vorne sind, weil sich in der Regel die Teams, die die entwickeln, sehr stark mit dem Nutzer identifizieren können, ja. Wenn ich jetzt eine Software für ein Flugzeug entwickle, dann ist das in der Regel ein bisschen schwieriger oder in anderen B2B-Applikationen. Aber je näher man am Kunden ist und je näher man auch sich selber in die Rolle des Kunden oder des Nutzers, um genauer zu sein, versetzen kann, desto besser versteht man halt auch die Probleme und desto besser kann man dann halt mit Lösungen um die Ecke kommen. Und nochmal, du hast es angesprochen, was hat das mit Mathe und Physik zu tun? Man diskutiert ja viel vielleicht. Macht das überhaupt Sinn, was man da lernt? Das brauche ich ja nie wieder im Leben. Aber es geht nicht um das, was man lernt, sondern wie. Und dort lernt man auch strukturiert das Problem lösen. Und das ist so der Kern des Ganzen für mich.

Joel Kaczmarek: Ja, und vor allem, ich meine, es sind ja mehrere Faktoren. Also wenn wir es jetzt mal mit Kundennähe als erstes vielleicht übersetzen, weil du dich ja mit Empathie so ein bisschen daran gestoßen hast, da kommt ja noch mehr hinzu. Es hilft ja nicht, dass du nah dran bist am Kunden, sondern du musst ihn ja auch auf eine gewisse Art verstehen. Ich weiß, ich hatte einmal so einen Moment mit Christopher Böhnke. Der hat damals dieses noch Fjord, das heißt Accenture Song. ist quasi der Berlin-Leiter von deren Innovationsagentur und der ist halt eigentlich so Designer. Und ich habe mit dem Research-Gespräche mit Hörern von unserem Podcast geführt und wie die das Produkt nutzen. Und die haben immer was gesagt am Telefon und der hat aber was völlig anderes aufgeschrieben, weil er hat nicht das aufgeschrieben, was sie gesagt haben, sondern er hat das Bedürfnis dahinter aufgeschrieben oder das Problem, was er dabei erkannt hat. Von daher kann man es auch total gut vorstellen, wenn jemand in deinem Team sitzt und versteht halt genau, also der kennt vielleicht den Kunden, oh ja, der Bernd hier, den habe ich ja neulich da mal in Siegen besucht und so, und dann sagte der mir ja das, so, und wenn er dann auch sozusagen auch versteht, worum es geht, dann können die ja ganz anders Entscheidungen treffen auf dem Prozess, weil es wird ja immer mal wieder eine Situation geben, wo ein Techie von dir irgendwie sagt, okay, linksrum oder rechtsrum, und wenn du dann an einem Punkt bist, dass das selbst entscheiden kann, dann hast du, glaube ich, alles richtig gemacht,

Björn Wagner: ne? Ja, absolut. Und in vielen Gesprächen, gerade natürlich, wenn man, sage ich mal, erfahrene Nutzer seines Produkts hat, dann kommen die in der Regel ganz, ganz viel mit tollen Feature-Ideen um die Ecke. Dann sagen die, ja, ich brauche hier das noch, das noch und den Button hätte ich gerne noch und hier können wir das nicht irgendwie vereinfachen. Und was halt super wichtig ist, sich halt nicht nur in den Gesprächen mit den Kunden wirklich auf die Features zu fokussieren, nach dem Motto, wünsch dir was, Was können wir denn noch bauen, sondern wirklich verstehen, was sind denn die darunter liegenden Probleme? und vielleicht sieht die Lösung dann ganz anders aus. Das ist so ein bisschen, wie man immer so schön sagt bei Henry Ford, die Leute hätten sich schnellere Pferde gewünscht, aber halt kein Auto. Da muss man halt so ein bisschen schauen, wie kann man, da gibt es verschiedenste Techniken, wie man wirklich dann das Kundenproblem genau versteht und dann halt auch umsetzt. Und natürlich, man macht das nicht alleine, das ist im Team. Und was mir halt immer sehr wichtig ist, ich habe ganz viele Teams gesehen, die haben mal Scrum eingeführt und dann gibt es da die Rolle des Product Owners. und dann macht der Product Owner, spricht halt, wenn man Glück hat, mit ein paar Kunden, dann schreibt er halt so User Stories auf, wie man es kennt, beim Lehrbuch, die werden dann runtergebrochen, dann machen die Designer, entwickeln dazu vielleicht ein paar Screens, zum Beispiel für eine mobile iPhone, Android App und dann kriegen die Entwickler die Aufgabe, jetzt diesen Screen zu bauen. Aber die Entwickler haben halt nie verstanden, was ist eigentlich das Problem, das wir lösen. Und dadurch können sie A, keine Ideen zu beitragen und verstehen den Kontext gar nicht. Dann geht ganz viel verloren. Dann wird nur die Hälfte entwickelt, wird vielleicht in die falsche Richtung entwickelt. Man weiß nicht, wie man es testen muss. Man versteht dann gar nicht, wie wird das eigentlich eingesetzt und wie entwickle ich denn jetzt dafür konkrete Tests. Das ist aber auch wichtig, dass dieses Problemverständnis halt nicht nur bei einer Person im Team ist, die dann allen anderen erklärt, übrigens, das müsst ihr jetzt so bauen, sondern das gesamte Team sollte halt mitarbeiten, das Problem des Kunden verstehen. Und dort halt auch an der Lösung mitarbeiten. Das ist natürlich immer besser. Nicht, dass irgendwie zwei Leute was bauen, die schmeißen das über den Zaun und jetzt, lieber Entwickler, baut das mal möglichst schnell. Wie lange braucht ihr? Eine Woche oder zwei? Nee, nee, das ist nicht die Idee. Wirklich verstehen, worum es geht, was ist das Problem, selber dazu beitragen und das halt nicht nur individuell, sondern halt auch im Team entsprechend so aufzusetzen.

Joel Kaczmarek: Und was ist dein Vorgehen, nachdem du abfragst oder überprüfst, ob jemand, den du in deine Organisation holen möchtest, über diese Problemfähigkeit, also Problemlösungsfähigkeit und auch diese gewisse Empathie verfügt?

Björn Wagner: Also ich habe noch nicht die ultimative Antwort gefunden dafür. Das ist dann wieder ein bisschen rollenspezifisch. Also was wir zum Beispiel machen ist, für Entwickler gibt es in der Regel so eine Coding-Challenge, das heißt irgendwann in der Mitte des Bewerbungsprozesses in der Regel, es ist auch von Land zu Land ein bisschen unterschiedlich, aber gibt es eigentlich eine Aufgabe, eine relativ kundenbezogene Aufgabe. Also da wird jetzt nicht konkret genannt, hey, baue jetzt bitte genau dieses Feature, sondern hey, hier ist ein Kundenproblem, löse das mal und skizziere mal so eine Lösung, die irgendwie dann also Code produziert und den man auch ausführen kann und testen kann irgendwie, so ganz grob gesagt. Aber man geht halt nicht hin und sagt hier, bitte baue ABC, sondern man fängt halt abstrakt an mit einem Kundenproblem und schaut dann halt, okay, verstehen die Bewerber das Kundenproblem und wie verstehen sie es und wie gehen sie in die Lösung rum, welche Gedanken haben sie bei der Lösung und wie setzen sie das dann konkret um. Also das ist zum Beispiel eine Möglichkeit. Man kann natürlich im Bereich Design oder Product Management, kann man halt auch ähnliche Aufgaben, Challenges geben, um die Leute wirklich am Ende an einem konkreten Problem arbeiten zu lassen und zu sehen, wie gesagt, wie gehen sie das Problem an. Kommt gar nicht so gut darauf an oder so stark darauf an am Anfang, wie gut ist die Lösung, sondern wie sind so die Gedankengänge, wie denken die Leute, wie gehen sie voran, um bestimmte Probleme effizient zu lösen.

Joel Kaczmarek: Gut, also wir waren jetzt im ersten Bereich Problemlösen. Das war auch quasi so der Punkt, dass wir gesagt haben, Problemlösungsfähigkeiten gepaart mit Kundenempathie. Jetzt kommen wir zum zweiten Bereich, nämlich die Lösung in Form zu bringen. Also Shape Solution hast du es auf Englisch genannt. Da hast du notiert, dass die erste wichtige Fähigkeit ist, so funktionale Skills zu haben. Was meinst du damit?

Björn Wagner: Genau, also das ist vielleicht auf Deutsch, das ist so das Handwerk. Also als Entwickler programmiere ich halt. Als Designer skizziere ich Lösungen auf verschiedenen Granularitätsebenen. Es kann irgendwie ein einfacher Mockup sein, ein Papier skizziert oder halt so Pixel-Perfect-Figma-Klick-Prototype, der schon aussieht wie das echte Produkt, wenn man irgendwie sehr, sehr spät im Discovery-Prozess, wenn man das so schön nennt, quasi Sachen testen möchte. Und natürlich Handwerkskills, das ist einer der fünf, aber was wichtig ist, ist einer der Skills. Also man muss halt sehr gute Fähigkeiten haben im Bereich Entwicklung. Zum Beispiel, wie schreibe ich Code, wie schreibe ich Clean Code, wie teste ich meinen Code, wie kann ich auch Code für komplexe Service, komplexe Umgebung schreiben, was sind dort Best Practices, Trends, Patterns, die ich umsetzen muss. Das ist halt super wichtig. Aber was halt hier, also das hängt alles sehr stark zusammen. Das heißt, wenn ich halt ein Entwickler bin, der das Kundenproblem verstanden hat, dann kann ich halt auch viel besser verstehen, wenn ich jetzt an Testkonzepte denke, wie teste ich denn eigentlich die Lösung? Weil ich verstehe, in welchem Kontext der Nutzer das einsetzt. Das heißt, gerade so die einfachen Test Cases, die sind immer relativ einfach quasi definiert, aber was sind so die Edge Cases? Was passiert, wenn was schief geht? Und je mehr ich quasi ein Problem und den Nutzer verstehe, desto besser kann ich dann dort halt auch wieder meine funktionalen Skills, was ich jetzt halt als reiner Entwickler zum Beispiel lerne, auch wirklich anwenden. Und am Ende mit dem Kontext ist man, glaube ich, sowohl effektiver, das heißt, man baut mehr an den richtigen Sachen und man ist auch effizienter. Das heißt, man ist viel, viel schneller, weil es gibt weniger Missverständnisse, weniger Zyklen, dass man zurückgehen muss und sagen muss, jetzt haben wir uns alle falsch verstanden, wir wollten eigentlich ganz was anderes. Aber das sind dann so die Kern-Skills und da kommt natürlich kein Weg dran vorbei. Es ist aber so, wenn wir uns so typische Senioritätskurven anschauen, dass in der Regel ab einer Seniorität von so einem Senior, was so eine mittlere Karrierestufe ist, quasi man sich eher auf die Entwicklung der anderen Skills fokussiert. Das heißt, man wird jetzt nicht besser am Programmieren in vielen Fällen, sondern man wird dann eher besser an den anderen Skills, die wir besprechen an der Stelle.

Joel Kaczmarek: Also das ist quasi eine wichtige Hausaufgabe, die nicht fehlen darf. Klar, ist ja plain vanilla, aber hat sozusagen abnehmenden Grenznutzen. Also irgendwann hast du da so eine Art Decke erreicht und dann geht es eher darum, die anderen Fähigkeiten zu verbessern, um quasi das, was du kannst, besser einbringen zu können.

Björn Wagner: Genau. Und noch eine spannende Sache natürlich, das Thema AI ist in aller Munde. Und hier, also Ich glaube, am schwierigsten wird es sein, Problemverständnis und Lösungen durch AI ersetzen zu lassen. Aber wir sehen schon viel in Fortschritt. Hey, wie können wir denn die Entwicklung schneller, einfacher machen? Natürlich brauchen wir immer noch Entwickler und die Lösungen sind, es gibt, sage ich mal, Mixed Feedback, wie gut auch AI wirklich in der Entwicklung funktioniert. Aber so funktionale Skills, das heißt, wie schreibe ich wirklich Code oder wie designe ich auch, also wie bringe ich quasi bestimmte Ideen zu Papier, sage ich mal, dort wird, glaube ich, AI einen viel, viel schnelleren Weg reinfinden und viel, viel schneller Wert schaffen können als in dem Kern der Problemlösung.

Joel Kaczmarek: Gut, also Handwerk lässt sich zumindest in Teilen durch KI wegdisruptieren oder erweitern, augmentieren, aber Handwerk ist immer nur so gut wie die Richtung, in die man sie schickt. Ich habe die Tage, habe ich was Schönes gehört, das ist ein bisschen wie bei dem Thema Schule, vielleicht erinnerst du dich noch, im Physikunterricht hat man ja von Vektoren immer gehört, also eine Kraft und eine Richtung. Von daher, das Handwerk ist quasi die Kraft, aber die Richtung muss klar sein und die ist halt besser, wenn du die Fähigkeit hast, Probleme zu lösen, ne. Gut, die dritte Fähigkeit, auch in diesem zweiten Bereich der Lösungsentwicklung, ist Kommunikation. Das ist ja gefühlt alles. Also man kann nicht nicht kommunizieren, haben wir gelernt. Was ist denn für dich da besonders wichtig in deinem Bereich oder im Bereich Product, wenn es um Kommunikation geht?

Björn Wagner: Ich denke Kommunikation. Was ganz wichtig ist, es geht in beide Richtungen. Es geht nicht darum, ich habe eine Idee und jetzt erzähle ich allen, wie toll die Idee ist, sondern es geht ganz viel auch um Kollaboration und auch Zuhören. Also wirklich beidseitige Kommunikation, sage ich mal. Der wichtigste Punkt ist, ich muss halt Ideen greifbar machen. Es hilft nichts, wenn ich das Problem super verstanden habe und dann als Designer einen super Prototypen entwickle, dann quasi aber das nicht kommunizieren kann. Dann jetzt nicht verschiedene Stakeholder, wie man immer so schön sagt, also entweder Kunden oder andere Stakeholder, Manager im Unternehmen davon überzeugen kann,dass das jetzt die Lösung ist,die den meisten Wert schafftund in die auch investiert werden muss am Ende. Das heißt, Kommunikation ist sehr, sehr wichtig,sowohl, wie kann ich meine Idee kommunizieren,wie kann ich meine Idee auch diskutieren,aber dann halt auch ein extrem wichtiger Skill ist,aktives Zuhören oder Active Listening, wie man so schön sagt im Englischen. Und hier auch wirklich zuhören. Man hat immer sehr viel,Leute sind immer, gerade wenn man Leute hat,die sehr leidenschaftlich über ein Thema sind, Und man möchte jetzt mit dem Kunden eine Idee validieren. Man hat vielleicht ein Erstgespräch mit dem Kunden oder mit ein paar Kunden natürlich, versteht, was ist das Problem. Und jetzt kommt man mit so einer ersten Skizze um die Ecke und will mal validieren, hey, gehen wir in die richtige Richtung, macht die Lösung Sinn, adressiert das das Problem. Dass die Leute dann sehr stark in so einen, ich nenne es mal Verkaufsmodus reingehen und den Kunden wirklich, als ob sie ihm das Produkt verkaufen wollen, jetzt die Lösung verkaufen wollen. Und dann, je nachdem natürlich, bekommt man ein ganz anderes Feedback, als wenn man, sage ich mal, dort viel offener rangeht und jetzt weniger verkauft, sondern mehr zuhört, mehr beobachtet, wie würden die Kunden das nutzen. Und das ist halt sehr wichtig, den richtigen Mix dort zu finden. Natürlich, in gewissen Szenarien muss man das verkaufen, aber in gewissen Szenarien muss man auch zuhören und erst mal verstehen und nachfragen und wirklich im Detail verstehen, was der Kunde, der Nutzer denn eigentlich sagt und Und halt wirklich nicht meine Lösung verkaufen, weil wenn ich dem die verkaufe, dann sagt der vielleicht irgendwann einfach, ja, ja, dann mache ich das nochmal zwei anderen Kunden und wenn es dann wirklich benutzt wird, dann kommt das Feedback halt erst viel, viel später und vielleicht dann zu spät, den man schon viel mehr rein investiert hat.

Joel Kaczmarek: Gut, also wenn wir jetzt nochmal an unseren Vektor denken, wir sind sozusagen in der Lage, eine Kraft zu entwickeln, die wir richten und dann ist es natürlich wichtig, da aber in Kommunikation zu gehen. An welcher Stelle ich die wohin richte. So, jetzt überlege ich gerade noch, das ist ja so ein bisschen das Klischee, dass man technischen Menschen vorwirft, dass sie gerade in Kommunikation nicht so gut sind, dass das immer so eine Nerd sind, die darfst du immer nicht stören. Also ich habe so ganz viele Türaufkleber in Erinnerung, so nach dem Motto, nicht gegen die Scheibe klopfen und so, wenn du irgendwie an Tech-Bereiche denkst. Wie siehst du denn da, sage ich mal, also was ist denn da wirklich dran, beziehungsweise wie geht ihr auch dieses Thema an, dass ihr den Leuten helft, kommunikativ gut zu sein?

Björn Wagner: Auch hier, Übung macht den Meister. Es gibt ein breites Skillset, wir reden heute über die fünf. Und natürlich auch Kommunikation ist für alle, egal auf welcher Ebene, egal in welcher Rolle, ein sehr, sehr wichtiger Skill. Man arbeitet im Team, man muss immer gut mit Leuten kommunizieren können. Das heißt, hier sind dann die Manager in der Regel gefragt der Leute, Halt zu schauen, okay, wo stehen die Leute, wie gut sind sie kommunikativ und wie kann man sie weiterentwickeln? und dann zum Beispiel kann man sich überlegen, okay, bevor man die Leute zum wichtigsten Kunden schickt, dort was zu präsentieren, fängt man vielleicht an, erstmal intern gewisse Sachen zu präsentieren oder intern Feedback abzuholen und man kann sich dann Schritt für Schritt weiterentwickeln und dann halt auch größere Projekte, komplexe Projekte machen, wo man dann wirklich sehr stark hands-on das trainieren kann. Plus es gibt natürlich jede Menge Kurse, die man so im Bereich wirklich klassisches Teaching, die man den Leuten mitgeben kann, wo sie halt ihre Kommunikationsskills verbessern können. Und ich würde auch sagen, dieses Klischee, was du angesprochen hast von den Leuten im Keller, ich glaube, das hat sich schon in vielen Bereichen stark überholt. Es spricht heute nicht mehr der Realität, gerade halt in stark, sag ich mal, Produkt- und Engineering-Organisationen in Starken.

Joel Kaczmarek: Würdest du denn sagen, wenn Menschen heutzutage aus einer Uni rausfallen mit einem technischen Background, den sie dort studiert haben, dass sie also diesen kommunikativen Faktor gut vorbereitet werden?

Björn Wagner: Kann man, glaube ich, pauschal nicht beantworten. Das hängt sehr, sehr stark von den Universitäten ab. Ich kann es von mir selber sagen. Ich habe ja hier in Potsdam Software Engineering studiert und explizit nicht nur Informatik studiert. Und dort gab es gerade im Master einen sehr, sehr starken Fokus auf Kommunikation und Leadership und weniger auf, ich sag mal, die theoretischen Aspekte. Natürlich hat man auch theoretische Aspekte gehabt, aber das wurde viel mehr abgemixt mit Softskills, mit Kommunikation, auch mit Leadership-Themen. Und das hängt, glaube ich, sehr stark davon ab, wo man studiert und welche Fachrichtung. Aber ich würde immer darauf achten, also kann ich Leuten nur empfehlen zu schauen, hey, was ist der Anteil, der im Studium vorgesehen ist. Und man hat ja in der Regel auch eine gewisse Flexibilität, wo man noch zusätzlich Sachen wählen kann. Und das ist, glaube ich, was, wo man immer aufpassen sollte, dass man das auch macht. Und viel Teamarbeit, weil das trainiert halt Kommunikation automatisch. Wenn man im Team ist, muss man viel zusammenarbeiten. Und das ist super wichtig. Was ich immer wieder aufs Neue lerne für mich selber ist, Sachen aufzuschreiben. Das ist unglaublich wichtig. Man kann irgendwie mit fünf Leuten zwei Stunden diskutieren, aber dann einfach mal, wir haben über Probleme geredet, ein Problemstatement aufzuschreiben und dann alle wirklich zu sagen, hey, das ist jetzt das, was wir unter dem Problem verstehen, dass wir eine gemeinsame Sprache sprechen. Das ist halt super wichtig. und da würde ich auch schauen, dass man da ein paar Berührungspunkte in der Ausbildung mit hat.

Joel Kaczmarek: Ergibt Sinn. So, dann haben wir jetzt also zwei von drei Bereichen und drei von fünf Skills. Nochmal zur Erinnerung, Problem Solving als erster Bereich, mit der Fähigkeit, Probleme lösen zu können und Kundenempathie zu haben. Dann das Solution Shaping, also die Lösung zu entwickeln mit den funktionalen Skills auf der einen Seite und den kommunikativen auf der anderen. Und jetzt kommt ja so der dritte und letzte Bereich, nämlich die Execution zu skalieren. Was ist da so? der, es fehlen ja offensichtlich noch zwei Fähigkeiten, was ist die erste, die du da als zentral siehst?

Björn Wagner: vereinfacht gesagt Projektmanagement, sage ich mal, oder einfach getting things done, wie man so schön sagt auf Englisch. Also wie gesagt, ich habe das Problem verstanden, ich habe irgendwie ein gutes Design, um bei dem Designbeispiel zu bleiben, entwickelt. Ich habe super kommuniziert, aber nun muss ich je nach Größe das Produkt, sage ich mal, die Sachen auch noch umgesetzt bekommen. Also wie schaffe ich es denn jetzt quasi, wirklich dediziert von allen Leuten Feedback zu holen, mir das Investment zu sichern, denn die Sachen, wenn ich dann Investment bekomme für zum Beispiel ein neues Produkt, Dann wird in der Regel auch jemand fragen, hey, sehr gut, wir investieren da jetzt irgendwie, keine Ahnung, 20 Leute für ein Jahr rein. Aber was können wir denn in einem Jahr liefern? Und dass man dann halt in einem Jahr oder hoffentlich vor einem Jahr, vielleicht nach ein paar Wochen, Monaten am Anfang, dass man halt gewisse Sachen schon liefern kann und die Versprechen dann halt auch einhalten kann und die Sachen wirklich liefert, sage ich mal. Also da gehört sehr viel Projektmanagement dazu, quasi strukturiert Fortschritt zu machen. Da gehört dann auch sehr viel Stakeholdermanagement dazu. Und gerade in großen Organisationen ist das unglaublich wichtig, Dass ich halt die richtigen Leute quasi informiere und proaktiv mitnehme und überzeuge, dass wir halt in die richtige Richtung laufen. Ohne das, wie gesagt, hilft mir die beste Lösung nicht. Und dann am Ende schauen, hey, wie kann ich meine Versprechen halten, wie kann ich Sachen, die ich verspreche, auch zur richtigen Zeit und in der vereinbarten Qualität und im vereinbarten Umfang halt auch lösen am Ende des Tages. Und das wird halt in kleinen Firmen, Startups ist das in der Regel relativ einfach, je komplexer die Firmen werden, je größer die Organisationen werden, desto mehr Aufwand geht dann halt auch hier rein, hey, wie kann man das wirklich dann mit mehr Leuten koordinieren und halt sicherstellen, dass man halt in die gleiche Richtung arbeitet und auch am gleichen Ziel zur gleichen Zeit ankommt.

Joel Kaczmarek: Okay, also würde ich sagen, ist ja ziemlich plain vanilla, dass man quasi den Fortschritt managt. und genauso gibt es aber auf der anderen Ebene noch, wenn ich so drüber nachdenke, der fünftes Gewehr dann eigentlich auch so eine gewisse, also Enablertum oder Empowerment, also dass man sagt, es muss ja eigentlich irgendwie so eine Führung darin geben, also das, was du gerade beschrieben hast in den Managen, das ist ja ein Prozess, da braucht es ja dann auch eine Hierarchiestruktur oder eine klare Zuteilung so in der Richtung, ne?

Björn Wagner: Genau, also man braucht natürlich Leadership. Wollen wir gleich im zweiten Detail auch nochmal ein bisschen weiter im Detail drauf eingehen. Am Ende, was wir halt oder ich halt auch sehr stark immer versuchen, den Organisationen voranzutreiben, ist dieses Thema Empowerment. Was heißt das? Also Empowerment heißt nicht, steckt natürlich viel Autonomie drin. Aber auch viel Alignment. Das heißt, als Manager soll man den Leuten möglichst viel Freiraum geben und dann ist es halt die Kunst, rauszufinden, wie viel Freiraum der richtige Freiraum ist. Natürlich, wenn man Leute mit weniger Erfahrung hat, dann ist es schon natürlich auch nur fair und richtig, den Leuten halt auch vielleicht mehr Guidance, mehr Guardrails, Entschuldige fürs Denglische, einfacher mitzugeben.

Joel Kaczmarek: So Banden, ne?

Björn Wagner: Und weil Freiheit ist was, was Leute grundsätzlich antreibt und halt auch motiviert, so einer der Faktoren. Und natürlich ist es aber nicht nur, jeder entscheidet das, was er will und baut das, was er möchte. Man muss dann auch schauen, okay, sind wir denn aligned, das heißt, sind wir abgestimmt mit der Gesamtrichtung des Produkts, der Firma, des Unternehmens, mit der Gesamtrichtung der Technologie, dass nicht jeder quasi, jedes Team jetzt in einer größeren Organisation sagen kann, wir verwenden jetzt einen komplett anderen Technologie-Stack, um unsere Services oder Features zu bauen. sondern es muss halt auch ein gewisses Alignment muss halt stattfinden und dort ist es halt immer wichtig, aus Leadership halt die richtige Balance zu finden, wie viel Freiheit gibt man, wie viel alleint man die Leute mit der Gesamtrichtung, das sind so die Kernkompetenzen an der Stelle.

Joel Kaczmarek: Ja und vielleicht nochmal dieses Beispiel zu stretchen aus der Physik, wenn wir wieder an den Vektor denken, dann ist es ja ein bisschen wie so ein Körper, also das quasi alles gehört zu einem gemeinsamen Körper, aber du hast so eine gewisse Autonomie darin, welcher Körperteil, welche Kraft gerade in welche Richtung lenkt, also der Fuß vielleicht nach links und der Arm nach rechts oder so. Ja. Also das Bild ist gar nicht mal so schlecht, freue ich mich ja gerade. Und wenn wir dann nochmal zusammenfassen, dann haben wir also Problemlösung inklusive Kundenempathie, wir haben die funktionalen Fähigkeiten oder das Handwerk, was du meintest, wir müssen das kommunizieren können, genauso aber auch im Fortschritt untereinander managen und brauchen dafür halt diesen Leadership Approach inklusive, wo sind wir eigentlich mit welchem Autonomiegrad und wo hängen wir aber zusammen, was du eben mit Alignment genannt hast. Und ich glaube, da bietet sich ja wirklich an, dass, wie du eben gesagt hast, wirklich nochmal diesen Leadership Approach ein bisschen vertiefen. Also was da eigentlich genau dazu gehört.

Björn Wagner: Vielleicht noch, weil du gerade nach der Zusammenfassung gefragt hast, vielleicht noch eine Sache. Ich glaube, wenn man es sich mal im Detail anschaut, dann ist es schon sehr generalistisch. Also man hat schon, es ist ein sehr, sehr breites Skillset, was man eigentlich hat und braucht, egal in welcher Rolle man ist und weniger spezialisiert. Natürlich sind irgendwie Leute immer verschieden gut. Also man würde niemanden finden, der irgendwie alles gut kann oder alles perfekt kann. Aber es ist halt schon wichtig, so ein klassisches System ist halt, wenn man sehr kreative Leute hat, dass man auch schaut, okay, da gehört trotzdem immer noch ein bisschen Projektmanagement dazu, weil sobald man das halt anfängt, jetzt auf andere Rollen auszulagern oder noch mehr Leute hinzunimmt, dann gibt es ja wieder eine, sage ich mal, Kommunikationsgrenze dazwischen und das macht es halt wieder komplexer, langsamer und mehr Aufwand. Also es ist schon, glaube ich, zu einem gewissen Grad, man muss halt so ein Generalist sein und zum einen kreative Lösungen haben, aber die dann immer noch einigermaßen strukturiert halt auch umsetzen können. Ich glaube, das ist halt so der Kernpunkt an der Stelle.

Joel Kaczmarek: So, und jetzt nochmal zu dem Leadership-Approach. Was beinhaltet der für dich?

Björn Wagner: Genau, also vom Leadership, also man hat jetzt Leute, wie gesagt, großfunktional Leute, Designer zum Beispiel, Product Manager, Product Owner, Entwickler. Wie führt man die? Und meine Bewerbungsfrage ist immer, definiert auch mal Leadership und das ist sehr, sehr spannend, weil es gibt halt so viele verschiedene Perspektiven darauf. Also hier gibt es wieder nicht richtig falsch. Für mich sind so fünf Aspekte eigentlich wichtig. Einmal das Thema, man muss irgendwie eine Richtung oder eine Vision vorgeben, also um irgendwie Leute zu motivieren, um irgendwie sogar Leute einzustellen, dass man irgendwie so eine gemeinsame Richtung hat. Purpose, wie man halt auch so schön sagt im Englischen, das ist irgendwie der eine Teil. Dann ist ganz wichtig, dass man den Leuten Kontext gibt. Wir haben gerade so schön über die Boundaries, also die Banden gesprochen. In welchem Kontext können sie sich frei bewegen? Was dürfen sie entscheiden? Was muss irgendwie abgestimmt werden? Das ist halt super wichtig. Und das sowohl ist hier wichtig, dass es dann quasi die Strategie abgestimmt ist. Also wie wollen wir langfristig unsere Vision erreichen? Zum anderen Teil aber halt auch, was gern vergessen wird, wie operieren wir halt? Weil wir sind natürlich nicht in einem Vakuum. Es gibt auch sehr viel Vakuum. sage ich mal, so typisches Thema Stand-Operating-Procedure, Security-Themen und so weiter, die man halt sehr ernst nehmen muss und auch in die tägliche Arbeit übernehmen muss und das muss halt irgendwie sichergestellt werden, dass das halt auch irgendwie als Kontext richtig quasi positioniert wird. Dann gibt es noch das Thema Umgebung, ja, ist für mich eine der wichtigsten Verantwortlichkeiten eigentlich für Manager, das heißt, wie schafft man eine Umgebung, man hat ja cross-funktionale Teams, die haben dann aber auch in der Regel, ja, sage ich mal, Natürlich verschiedene Hintergründe, verschiedene Dynamiken, verschiedene Mindsets, auch wie kann man daraus wirklich ein Team formen, wo sich jeder irgendwie sicher fühlt, wo jeder auch offen seine Meinung quasi sagen kann und wo jeder am Ende seine beste Arbeit gerne abliefert. Also wie kann man diese Umgebung schaffen, was benötigen die Leute dafür? Dann ganz wichtig, die Leute weiterentwickeln. Englisch sagt man so schön Mastery. Also wie kann ich sicherstellen, dass die Leute quasi in den fünf Skills, die wir gerade besprochen haben, sich dort kontinuierlich weiterentwickeln. Und wie setzt man dann richtigen Fokus, individuell, aber auch fürs Team, um halt sicherzustellen, dass man die Ergebnisse erreicht. Und dann der letzte Teil, das ist so der Manager-Teil oder der MHR-Teil. So das Disziplinarische, Higher Fire Promote sind so, wie die Amerikaner mal sagen, die typischen Aufgaben, die man natürlich auch noch mitmachen muss. Mit allen HR-Responsibilities, die halt dazukommen, aber wie gesagt auch eher der kleinere Teil natürlich, was ich da im Verantwortungsbereich der Leader sehe.

Joel Kaczmarek: Also eigentlich sehr plain vanilla, wenn man es zusammenfasst, also klar eine Richtung vorgeben, den Leuten irgendwie diese, ich glaube eigentlich müsste man eher Geländer sagen, Guardrails wäre eigentlich eher so Geländer, wenn ich drüber nachdenke, also so ein Laufgeländer geben, in welchem Bereich sie operieren können, weil da geht es ja wieder um diesen Faktor vom Alignment. Die Umgebung, die Leute weiterzuentwickeln und Disziplin würde ich mal mit Konsequenz vielleicht auch übersetzen, also dass man sagt, ich halte die Organisation hygienisch sauber, dass da irgendwie quasi interagiert wird, wenn was nicht stimmt und so weiter. Jetzt ist so, was mir noch als abschließender Gedanke dazu kam, die Frage, würdest du sagen, dass man auch diese Leadership-Skills gut vorfindet am Markt, sage ich mal, wenn die Leute ausgebildet wurden oder ist das was, was man eigentlich eher nochmal in der Praxis schult und eigentlich sich da aneignet?

Björn Wagner: Auch hier würde ich sagen, gemixt. Also ich glaube, man kann das nicht lernen. Da ist sehr viel Learning by Doing. Das kann ich jetzt nicht im Textbook lernen. Ich erinnere mich immer noch mit die spannendste Vorlesung, die ich an der, oder das Seminar war es, glaube ich, an der Universität hatte, wo wir wirklich mit, ich glaube, es war sogar ein Bachelor mit, mit 80 Leuten über ein Semester lang eine Softwarelösung entwickelt haben. Und dann kommt man natürlich, 80 Leute, die zusammenzubringen, zu koordinieren. dass dann irgendwas am Ende dabei rauskommt und ich glaube, in solchen Szenarien lernt man dort am meisten, also man muss es nicht direkt hands-on machen, ich glaube, man kann das halt auch im, sage ich mal, universitären Kontext lernen, aber das ist dann viel, wo man halt auch reinwachsen muss und was so wichtig ist, nur weil man vielleicht ein guter, wie man immer so schön sagt, Individual Contributor ist, also weil ich ein guter Entwickler oder Designer bin, heißt es noch nicht, dass ich dann auch ein guter Leader oder Manager bin. Deshalb hatten wir auch schon mal drüber gesprochen, so diese Manager-Pfade oder Experten-Pfade, die man eher in der Karriere gehen kann. Ich glaube, um halt wirklich ein guter Leader zu sein, braucht man halt viel Erfahrung, muss seine eigenen Fehler machen und kann dann nach und nach quasi die verschiedenen Skills verändern. quasi weiterentwickeln. Aber das heißt nicht, dass man Manager sein muss. Man kann auch als, sage ich mal, Seniorentwickler mit einem Werkstudenten zusammenarbeiten und dort vielleicht erste Erfahrungen sammeln. Hey, wie kann ich denn die Person onboarden und die Person weiterentwickeln und erfolgreich machen? Also es gibt, glaube ich, jede Menge kleine Möglichkeiten, wo man das lernen kann, bevor man es dann vielleicht zum ersten Mal in einer größeren Leadership-Rolle anwendet.

Joel Kaczmarek: Das ist immer so ein zweischneidiges Schwert. Ich denke gerade so an unseren Leadership-Coach, der immer sagt, das ist so ein bisschen eine Unart, dass die Leute bei Führung immer der Meinung sind, ja, ich lerne on the job. Weil du gehst ja auch nicht zum Fußballtrainer und sagst so, ja, wieso trainiert ihr für Fußball? Ich lerne on the job. Von daher, das ist so ein bisschen so ein Mix. Auf der einen Seite brauchst du so diese Praxiserfahrung, auf der anderen Seite musst du dir halt auch dezidiert einen Fokus dafür setzen, dass du dich darum kümmerst, schätze ich mal. Oder es würde ja wahrscheinlich im Tech-Bereich nicht wesentlich anders sein als in anderen Sphären.

Björn Wagner: Ja klar, also man kann sich mit Coaches, man kann sich mit Rollenspielen und so weiter natürlich auf gewisse Situationen vorbereiten, aber wenn man dann zum ersten Mal in der Situation ist, jemanden entlassen zu müssen, aus welchen Gründen auch immer, dann ist das glaube ich immer noch sehr schwer vorher in einem Rollenspiel oder in einer gewissen Art und Weise quasi zu üben, zu trainieren an der Stelle. Schwierige Gespräche führen auch schwierige Feedbackgespräche. Man kann sich da sehr gut drauf vorbereiten und es gibt auch super viel Theorie, aber am Ende kommt es immer darauf an, okay, wie setze ich das jetzt konkret um? und in der eigentlichen Situation ist das dann, wo glaube ich viel Praxiserfahrung und dann auch viel Reflexion am Ende des Tages hilft. Also Grundlagen auf jeden Fall, aber ich glaube ohne die Praxis kommt man nicht so wirklich weit.

Joel Kaczmarek: Ja, das braucht schon auch die Spiele, ne? Nur das Training, nur das Torschießen reicht nicht, musst du dann halt auch in der Champions League dich kümmern.

Björn Wagner: Das sieht man immer beim Elfmeter, glaube ich.

Joel Kaczmarek: Ja, cool, Björn. Du, knackige halbe Stunde, wichtigsten Skills, glaube ich, verstanden, also nochmal zusammengefasst. Probleme lösen und mit Empathie die Kunden verstehen, funktionale Fähigkeiten haben, kommunizieren, Empowerment auf der Leader-Ebene und den Fortschritt managen. und dann im ganz speziellen Bereich, wenn wir nochmal auf den Leader gucken, Richtung vorgeben, Kontext klar machen, eine Umgebung schaffen, die Leute weiterentwickeln und mit Disziplin arbeiten. Sehr gut. Haben wir noch was Wichtiges vergessen?

Björn Wagner: Ja, das klingt gut. Ich glaube, ausprobieren, üben und man muss immer für sich die Organisation, die Kultur, glaube ich, immer die richtige Setup finden. Das sagt einem auch kein Lehrbuch. Sich viel mit Leuten austauschen, was funktioniert bei denen, was funktioniert nicht bei denen, aber das dann halt nicht blind anwenden oder einfach blind irgendein Framework, den neuesten Blogartikel oder die beste Best Practice quasi versuchen zu übernehmen.

Joel Kaczmarek: Ja, ich glaube, das ist immer ein ganz wichtiger Hinweis, weil es ist ja wie bei der Ernährung. Nicht jeder ist Veganer oder nicht jeder Flexitarier, nicht jeder mag Paleo. Also da braucht, glaube ich, jede Organisation auch so ein bisschen ihren eigenen individuellen Zugang. Ja, cool, du. Dann vielen, vielen Dank. Bis zum nächsten Mal. Vielleicht haben wir dann wieder den Till im Gepäck. Schauen wir mal hier. Vielen Dank, Björn.

Björn Wagner: Ciao.