Warum Entwickler auch Business Developer sein müssen

Code zu "schrubben" ist eine Sache, zusammen mit Kunden kreative Lösungen für deren Anforderungen zu finden, eine ganz andere.

Lesezeit: 7 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 48 Beiträge

(Bild: Black Jack/Shutterstock.com)

Von
Inhaltsverzeichnis

Code zu schreiben oder Softwaretests und Entwicklungswerkzeuge zu konzipieren – diese Aufgaben haben lange Zeit das Beschäftigungsfeld der Entwickler*innen maßgeblich bestimmt. Doch im Zuge der Digitalisierung hat sich dieses Spektrum deutlich erweitert – und ist dabei spannender geworden. Denn heute ist ihr kreativer Beitrag gefragt, um Geschäftsmodelle von "analog" auf "digital" umzustellen. Das gilt nicht allein für die Innovations- und Digitalberatungen, sondern auch für die "klassischen" Softwareentwickler.

Young Professionals schreiben für Young Professionals

Dieser Beitrag ist Teil einer Artikelstrecke, zu der heise Developer explizit junge Entwickler*innen eingeladen hat – mit dem Ziel, ihresgleichen, aber natürlich auch die interessierten "älteren Semester" über aktuelle Trends, Entwicklungen, Phänomene und persönliche Erfahrungen zu informieren. Die Beiträge dieser Artikelstrecke erscheinen im monatlichen Turnus. Du bist selbst ein "Young Professional" und willst Teil dieser Serie sein? Dann bewirb dich mit einem Vorschlag bei der Redaktion. Sie steht dir mit hilfreichen Tipps über den Schreib-, Redigier- und Freigabeprozess hinweg zur Seite.

Man sollte sich von dem Gedanken verabschieden, dass Entwickler*innen oft nur das umsetzen, was Kollegen*innen aus dem Beratungsteam zusammen mit Kunden vereinbart haben – etwa Web-Anwendungen zu erstellen oder Legacy-Applikationen per "Lift and Shift" in eine Cloud-Umgebung zu überführen. Gefordert sind hingegen zunehmend Fachleute, die die Rolle von kreativen Problemlösern übernehmen. Das heißt, sie müssen sich vermehrt in die speziellen Anforderungen der Kunden hineindenken. Das gilt nicht nur für technische Aspekte, sondern auch für wirtschaftliche und strategische Erwägungen.

Doch nach diesem Ausflug in strategische Höhen zunächst einmal zurück auf den Boden der Realität. Begonnen sei mit dem Berufseinstieg von Entwickler*innen oder dem in den Arbeitsalltag. Empfehlenswert ist, die neuen Kolleg*innen zu Beginn mit Aufgaben zu betrauen, die weniger "kritisch" sind. Das kann zum Beispiel das Abarbeiten von Tickets bei Produkten sein, die bereits bei Kunden im Einsatz sind. Häufig geht es dabei darum, Features hinzuzufügen oder Bugs zu beseitigen. Ein solch sanfter Einstieg ist vor allem für Mitarbeiter*innen hilfreich, die erst am Anfang ihrer Karriere stehen, sprich "frisch von der Schulbank" kommen. Selbiges mag aber auch für Quereinsteiger gelten. Durch diese Vorgehensweise hat das neue Teammitglied die Chance, sich ohne allzu großen Druck mit den Workflows und eingesetzten Tools vertraut zu machen.

Wichtig ist zudem, dass die bestehenden Beschäftigten den Neueinsteigern das Gefühl geben, dazu zu gehören, und dass die neue Meinung im Team ebenso zählt. Nicht förderlich ist dagegen, wenn den neuen Kolleg*innen gleich zu Beginn klar gemacht wird, dass ihre Python- oder JavaScript-Kenntnisse unterirdisch seien. Es hängt maßgeblich von der sozialen Kompetenz und den "Soft Skills" der Kolleg*innen und der Teamleads ab, ob sich eine produktive und vertrauensvolle Zusammenarbeit ergibt. Das bestätigt auch eine Studie des Personaldienstleisters Manpowergroup von 2018. Demnach suchten 78 Prozent der Unternehmen Mitarbeiter*innen, die gut kommunizieren können, an die 86 Prozent wollten Beschäftigte mit ausgeprägten Team-Fähigkeiten. Das galt auch für technische Sparten wie die Softwareentwicklung und das Programmieren.