Welche Kompetenzen für Software Engineers in Zukunft wichtig sind – Interview mit Ruedi Stirnimann

Ruedi Stirnimann hat seine Diplomarbeit im MAS Human Resources Management der FHNW über die künftig notwendigen Kompetenzen von Software Engineers verfasst. Der begeisterte Sportler und Iron-Man-Finisher bekleidete bereits verschiedene verantwortungsvolle HR-Positionen in Luzern und Zürich.

Kompetenzen von Software Engineers – wie bist du zu diesem Thema gekommen?

Mein Gedanke war, dass sich die Art der Zusammenarbeit von Softwareentwickler*innen verändern wird. Oft wird beispielsweise in verteilten Teams gearbeitet. Da müssen sich zwangsläufig auch die notwendigen Skills und Kompetenzen verändern.

Ein anderer Grund ist der Fachkräftemangel. Es heisst immer, man benötige Software Engineers. Man betrachtet also lediglich die Funktion und die Fachkompetenz und weniger, was weitere die notwendigen Skills sind, um den Job gut ausführen zu können.

Was denkst du, was sind die wichtigsten Kompetenzen von Software Engineers in der Zukunft?

Einerseits die Kundenorientierung. Diese hat stark damit zu tun, ob jemand die Perspektive des Gegenübers übernehmen kann, also über Empathie verfügt. Man muss sich ins Gegenüber hineinversetzen können. Oft sind Software Engineers «fachtechnisch» sehr versiert und das Gegenüber versteht unter Umständen sehr wenig von Technik bzw. von IT.

Ausserdem muss man wissen, welche Fragen man stellen muss, wie man Sachverhalte einfach darlegen kann, wie man gut moderiert. Wenn mehrere Personen oder Anspruchsgruppen involviert sind, muss jemand das Gespräch leiten und führen. Man muss auch aufzeigen können, wie man etwas verstanden hat, indem man den Sachverhalt oder das Problem zum Beispiel einfach und verständlich visualisiert.

Wenn wir annehmen, dass wir immer verteilter arbeiten, ist für mich auch interkulturelle Kompetenz wichtig. Man muss verstehen, wie der andere tickt, was ihm wichtig ist. Ich muss verstehen, dass an einem gewissen Ort nicht vor neun Uhr gearbeitet wird, dass in anderen Regionen/Ländern ganz ein anderes Führungsverständnis vorhanden ist, etc.

Lernen, sich weiterbilden. Ist das auch wichtig?

Natürlich. Ich würde das nicht auf Software Engineers beschränken. Anpassungsfähigkeit ist DIE Überlebenskompetenz. Nicht der Grösste, der Stärkste überlebt, sondern der Anpassungsfähigste. Damit verbunden sind Lernfähigkeit, schnelle Adaptionsfähigkeit und Ideen schnell loslassen können und neue verfolgen, also Veränderungsbereitschaft. Das tönt einfacher als es ist.

Interkulturelle Kompetenz, Empathie, Kundenverständnis, Lernfähigkeit: Wird man damit geboren oder kann man sich diese aneignen?

Beides. Gewisse Dinge sind angeboren und nur schwer trainierbar, z.B. Empathie. Man redet auch von Selbstkompetenz. Da weiss man, das geht etwas in die Persönlichkeitseigenschaften und diese sind recht stabil und nur schwer veränderbar. Da braucht es sehr gute Unterstützung bis hin zu persönlichem Coaching. Dann gibt es Sachen, die sind gut trainierbar. Ich kann jemanden auf ein gutes Niveau bringen, wenn es nur darum geht, wie er oder sie auftritt, oder wie präsentiert wird, Oder dass nicht zu viel Fliesstext auf Folien verwendent wird oder Visualisieren mit Bikablo. Solche Dinge sindDas ist lernbar.

Wie wichtig ist Feedback?

Immer, wenn es um Entwicklung geht, ist Feedback sehr wichtig! Bin ich dies oder jenes denn auch wirklich? Es gibt meine Wahrnehmung, aber was ist die Rückmeldung von anderen? Wahrnehmung nicht gleich wahr. Für mich ist das ein zentraler Lernbeschleuniger: Feedback bekommen.

Feedback ist immer der Ausgangspunkt. Aktion, dann Rückmeldung. Das war gut oder das was hätte man besser machen können? Die kontinuierliche Verbesserung passiert nur, wenn man beständig zurückschaut. Wie bei Scrum in einer Retrospektive. Verarbeiten und versuchen, das nächste Mal besser zu sein.

Ich merke es bei mir. Ich arbeite allein, daher mache ich alle sechs Wochen ein Coaching. Jemand spiegelt mir Dinge und sagt auch unangenehme Dinge. Das ist enormer Lerntreiber.

Ja, und das Feedback soll idealerweise kontinuierlich sein. Analog zu Wasserfall und agilem Vorgehen. Bei Wasserfall sehen wir uns einmal im Jahr. Ein Jahr später sehen wir uns wieder und sind überrascht, enttäuscht etc. Es ist gar nicht mehr möglich, ein MAG zu führen und Ziele zu vereinbaren, welche nach einem Jahr noch Bestand haben. Wir müssten in ein regelmässiges, kontinuierliches Feedback in kürzeren Abständen kommen.

Konkret?

Ganz einfach. Wir haben einerseits ein MAG. Wir vereinbaren vielleicht ein Ziel. Du hältst einen Vortrag. Zu diesem Vortrag werde ich dir eine Rückmeldung geben. Die Ziele regelmässig überprüfen. Das kann ganz kurz sein. Wichtig ist, dass es zeitnah stattfindet und nicht erst am nächsten MAG.

Ein Ziel, das zu weit in der Zukunft liegt, verliert seine Dringlichkeit.

Ja, und vielleicht auch seine Relevanz. Heute vereinbart man ein Ziel, morgen wird die Firma verkauft … Ein wichtiger Punkt ist, wie man Feedback gibt. Es ist ganz einfach: Es beginnt mit einem positiven Einstieg, dann Ich-Formulierungen, («Es ist meine Wahrnehmung, dass …»). Beschreiben, nicht bewerten. Nicht «du bist unpünktlich», sondern «Ich habe festgestellt, dass du letzte Woche zweimal zu spät warst.»

Du hast die Offenheit angesprochen. Es scheint mir bei vielen Themen so, dass es zuerst notwendig ist, zu verstehen, dass andere Personen eine andere Wahrnehmung der Wirklichkeit haben. Das ist bei interkultureller Kompetenz so, bei Kundengesprächen, bei Empathie generell.

Es ist vieles auf Offenheit zurückzuführen. Dass nicht ich die Wahrheit gepachtet habe. Dass es auch noch andere Wahrnehmungen gibt.

Beispiel Kundenorientierung: Es gibt Kunden, die teilweise in einer völlig anderen, etwas veralteten Welt arbeiten. Da treffen Universen aufeinander! Der Kunde kann ein älterer Patron sein, der kaum weiss, wie man einen Computer anstellt. Und dann kommt der Software Engineer und sagt, mir ist dies und jenes wichtig, Angular oder was auch immer. Der Patron versteht das nicht.

Als Software Engineer bekommt man täglich Jobangebote. Weshalb soll man sich nun in diesen Bereichen weiterbilden? Es geht gut auch ohne.

Jein. Noch geht es. Als ich die Arbeit verfasste, ging es darum, dass wir v.a. in der Schweiz einen Fachkräftemangel haben. Wir sind nach wie vor eine Hochpreisinsel. Wenn aber jemand in Vietnam auch gut entwickelt, dann ist meine technische Expertise irgendwann zu teuer. Früher lagerte man die Produktion aus. Auch Code generieren kann man irgendwann mit der Codeproduktion vergleichen. Ich denke, das wird früher oder später ausgelagert.

Wie kann ich mich dann weiterhin in der Schweiz profilieren? Die Nähe zum Kunden, das kann man auch in Zukunft nicht auslagern. Das Verständnis für den Kunden, die Nähe zum Kunden und in dieser Schnittstelle agieren.

Du siehst in der Schweiz also primär Vermittlerrollen. Product Owners, Requirements Engineers, Projektleiter …

Das war mein Fazit der Arbeit. Aber ich glaube, ich liege etwas falsch. Vielleicht ist es noch Zukunft und wird erst in 10-15 Jahren sein. Ich dachte, es ginge schneller.

Konkret, wie würdest du vorschlagen, die Kundenorientierung eines Bewerbers in einem Einstellungsinterview herauszufinden?

Ich würde ihn fragen, was für ihn Kundenorientierung bedeutet. Dann würde ich in die Dreiecksfragen hineingehen und fragen, ob er oder sie mir eine konkrete Situation schildern kann, wie er oder sie mit Kunden umgegangen ist. Wie findest du heraus, welche Bedürfnisse dein Kunde hat? Mir geht es darum, dass jemand mit Fragen arbeitet. Hier würde ich wieder nachhaken, welche Fragen denn? Offene Fragen, geschlossene Fragen? Da merkt man schnell, ob jemand weiss, wie man mit Kunden umgehen muss. Bis dahin, dass aktiv zuhören genannt wird, dass man versucht, die wichtigen Punkte des Kunden zu wiederholen, zu paraphrasieren. Da merkt man sehr schnell, ob es jemandem wichtig ist, sein Gegenüber zu verstehen. Oder ich bringe einen Case. Ich spiele den Kunden. «Ich habe von diesem Trend gehört. Ich möchte dies auch bei uns in der Firma umsetzen». Was machen Sie jetzt?

Was wäre eine gute oder eine schlechte Antwort.

Gut ist, wenn Fragen gestellt werden, idealerweise klassische W-Fragen, offene Fragen. Explorieren. Aktiv zuhören. Den Kunden verstehen, nachfragen. Wiederholen des Gesagten. Die Gestik soll nickend, bejahend sein. So, dass man merkt, dem geht es darum, das Gegenüber zu verstehen. Die schlechte Lösung wäre wohl: Ich nehme es mit und erfülle alle Wünsche. Das reicht nicht. Eine kritischere Auseinandersetzung ist notwendig.

Was würdest du einem SWE aufgrund deiner Arbeit raten?

Sich den «weichen» Themen gegenüber öffnen. Nicht nur Code und Technologie. Da ist schon die Offenheit gegenüber Neuem …

Dann aus Erfahrung: Der Kunde ist König. Das Technische interessiert ihn nicht. Man muss ihm eine Lösung bringen, welche einen Mehrwert bringt.

Betriebswirtschaftliches Denken. Es geht nicht nur um attraktive Technologien. Schlussendlich muss für den Kunden eine Lösung da sein, die ihm einen Mehrwert bringt.

Also in etwa Kundenorientierung, betriebswirtschaftliches Wissen und Denken, Offenheit gegenüber Neuem.

Was Software Engineers unbedingt weiterhin machen sollen: Austausch untereinander. Communities bilden, gemeinsam Lösungen finden. Da passiert so vieles! So viel Wissensaufbau und -Transfer. Viele Firmen versuchen, dies intern aufzusetzen – oft mit wenig Erfolg. Das passiert im Software Engineering automatisch, auch über Firmengrenzen hinweg. Da kann ich nur raten, weiter an Hackathons zu gehen, in User-Groups aktiv zu sein etc.

Herzlichen Dank, Ruedi, für das aufschlussreiche Gespräch!