Software-Entwicklung beim DigitalService: Mehr als nur Code

In vielen Tech-Teams sieht die Rolle von Software Engineers recht ähnlich aus: Tickets aus dem Backlog bearbeiten, Features entwickeln, Bugs beheben. Vielleicht noch ein paar Meetings mit Kolleg:innen aus den Bereichen Product und Design, gelegentlich ein Stakeholder-Gespräch – und fertig ist der Sprint.

Doch gerade in komplexen, wenig vorhersehbaren Projekten – wie sie in der öffentlichen Verwaltung häufig vorkommen – greift dieses Bild zu kurz. Denn was, wenn noch gar nicht klar ist, welches Problem eigentlich gelöst werden soll? Wenn unklar ist, ob Software über­haupt die passende Antwort ist?

Dann geht es darum, gemeinsam in interdisziplinären Teams herauszufinden, was wirklich gebraucht wird – und was nicht. Engineers sind dabei nicht nur dafür zuständig, Lösungen zu entwickeln, sondern auch mitzugestalten, welches Problem gelöst werden soll.

Diese Art zu arbeiten stellt viele gewohnte Abläufe auf den Kopf – bringt aber auch neue Möglichkeiten, Wirkung zu entfalten, wie wir in diesem Blogbeitrag zeigen.

In der öffentlichen Verwaltung, in der wir beim DigitalService mit unseren Projekten unterwegs sind, ist die Ausgangslage oft komplex. Es geht nicht nur um technische Herausforderungen, sondern auch um gesetzliche Rahmenbedingungen, historisch gewachsene Prozesse, Zuständigkeiten auf unterschiedlichen föderalen Ebenen – und immer wieder um die Frage: Was ist eigentlich das Ziel? Für wen? Und warum?

Diese Fragen zu stellen, ist nicht die Aufgabe einzelner Rollen – es ist Teamarbeit.

Das bedeutet konkret: Bevor ein System entworfen oder ein Service gebaut wird, bevor ein Repository angelegt oder ein Architekturentwurf gemacht wird, sind wir Engineers bereits involviert. Wir bringen unsere Perspektive im Rahmen von User-Research in In­ter­views mit Nutzenden ein. Wir lesen Gesetzestexte oder Verwaltungsvorschriften, um tech­ni­sche Anforderungen im rechtlichen Kontext zu verstehen. Wir arbeiten eng mit Designer:innen zusammen, um Prozesse zu visualisieren. Wir entwickeln erste Hy­po­the­sen, bauen kleine Prototypen oder führen kurze technische Machbarkeitsanalysen durch, um zentrale Fragen im Vorfeld zu klären. Und wir evaluieren bestehende technische Lö­sun­gen und Systeme.

Es ist ein erweitertes Rollenverständnis unserer Arbeit als Engineers. Wir sind nicht nur diejenigen, die eine Lösung implementieren – wir helfen aktiv mit, das Problem überhaupt erst zu verstehen. Und wir sind dadurch auch mitverantwortlich dafür, ob eine Lö­sung wirklich einen Mehrwert für Nutzende hat.

Dabei geht es nicht darum, alles zu können oder alles zu entscheiden, sondern darum, dass auch unsere Perspektive von Anfang an einfließt. So werden insbesondere tech­ni­sche Möglichkeiten und Grenzen frühzeitig sichtbar.

Diese Art zu arbeiten ist für viele von uns neu – und sie ist nicht immer bequem. Wer bis­her stark auf Implementierung fokussiert war, erlebt diesen frühen Projektabschnitt oft als ungewohnt. Manchmal schreibt man wochen- oder sogar monatelang keine Zeile Code. Manchmal stellt sich heraus, dass ein Problem gar nicht durch Software gelöst werden sollte oder der erste Ansatz verworfen werden muss, weil sich die Ausgangslage ver­än­dert hat.

Für manche fühlt sich das an, als sei man „nicht richtig am Arbeiten“. Überspitzt gesagt, ist man ja schließlich Engineer geworden, weil man Dinge bauen will – nicht, um in In­ter­views mit Nutzenden zu sitzen oder über Paragrafen zu diskutieren.

Und dennoch erleben viele von uns rückblickend, dass genau diese Phasen entscheidend waren: für das Projekt, aber auch für die persönliche Weiterentwicklung.

Denn Engineers, die sich auf diese Discovery einlassen, erweitern ihre Wir­kungs­mög­lich­kei­ten: Sie können fachliche und technische Zusammenhänge besser einordnen, Ge­sprä­che mit Verwaltungspartner:innen gezielter führen, sich aktiver in die Stakeholder-Kom­mu­ni­ka­tion einbringen. Und sie gestalten Produkte mit, die nicht nur technisch funk­tio­nie­ren – sondern wirklich etwas bewirken.

Wenn Engineers von Anfang an Teil des Teams sind, bringt das viele Vorteile – für die spätere Umsetzung, aber auch für die Zusammenarbeit. Technische Rah­men­be­din­gun­gen, bestehende Systeme oder regulatorische Anforderungen fließen frühzeitig in die Überlegungen ein. So lassen sich Fragen klären, bevor sie zu größeren Hürden werden – und manche Schleifen im Projektverlauf werden vermieden.

Auch die Dynamik im Team verändert sich, wenn alle Disziplinen gemeinsam starten: Product, Design, Engineering, Transformation und andere Perspektiven finden schneller zueinander. Das erleichtert Abstimmungen, stärkt das Vertrauen untereinander und schafft ein gemeinsames Verständnis von Problem und Ziel.

Gerade in kleinen Teams, die unter Zeit- und Ressourcendruck arbeiten, kann diese Fle­xi­bi­li­tät entscheidend sein. Indem wir Engineers uns für Prozesse, Nutzende, politische Rah­men­be­din­gun­gen oder fachliche Logiken interessieren, können auch wir dazu beitragen, dass das Team als Ganzes beweglicher bleibt.

Wichtig ist dabei die richtige Balance: Wie schon erwähnt, muss niemand alles können. Bei vielen unserer Projekte werden Engineers benötigt, die sich auf technische Aufgaben konzentrieren wollen. Technische Spezialist:innen spielen eine zentrale Rolle bei einem Großteil unserer Arbeit – und das wird auch in Zukunft immer so bleiben. Aber wer Lust auf interdisziplinäre Arbeit und auf einen Perspektivenwechsel hat, bekommt genau das.

Engineering beim DigitalService ist mehr als nur Software-Entwicklung. Es ist Teil eines gemeinsamen Prozesses, in dem interdisziplinäre Teams mit unseren Partner:innen aus der Verwaltung daran arbeiten, digitale Lösungen sinnvoll und nachhaltig zu gestalten.

Unsere Engineers entwickeln nicht nur Features – sie lesen, moderieren, analysieren, prototypisieren. Sie denken mit – und manchmal um.

Und sie helfen mit, dass digitale Transformation nicht abstrakt bleibt, sondern in kon­kre­ten, besser nutzbaren Produkten für Bürger:innen und Verwaltung sichtbar wird.