DIG GmbH

Etablierte Firma

Alle Videos anzeigen

Gerald Sigmund, Chief Software Architect von DIG

Der Chief Software Architect von DIG Gerald Sigmund erzählt im Interview über den Aufbau des Devteams im Unternehmen, mit welchen Technologien gearbeitet wird und wie das Recruiting abläuft.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In "Gerald Sigmund, Chief Software Architect von DIG" beschreibt Gerald Sigmund das rund 11-köpfige Team, das eine webbasierte Plattform für Prozessautomatisierung und digitalen Einkauf entwickelt und mit einem Hybrid aus Scrum und Scrumban arbeitet: zweiwöchentliche Sprints, Dailies und ein dynamischer Sprintanteil für wechselnde Kundenwünsche. Recruiting beginnt mit einem Ersttermin mit Entwicklungsleiter und HR, gefolgt von einem 3–4‑stündigen Schnuppertag im Büro und einem Onboarding mit Setup und kleinen Issues; gefragt sind Frontend-, Backend- oder Full‑Stack‑Interessen, wobei neben Fähigkeiten die persönliche Team-Passung besonders zählt. Technologisch reicht die Entwicklung von Perl/PHP über ein Angular-Frontend mit Microservices auf Grails bis zu geplanten Modernisierungen (z. B. Micronaut) und verstärkter Nutzung von AWS-Diensten wie Queues und Storage.

Gerald Sigmund, Chief Software Architect von DIG: Hybrid-Scrum, Microservices und ein People-first Hiring, das Wirkung zeigt

Einblicke aus der DevJobs.at-Redaktion

In unserer Session „Gerald Sigmund, Chief Software Architect von DIG“ mit Gerald Sigmund von der DIG GmbH bekamen wir einen kompakten, ungefilterten Blick darauf, wie ein überschaubares, fokussiertes Engineering-Team eine komplexe, webbasierte Plattform kontinuierlich weiterentwickelt – und wie die Organisation rund um Prozesse, Hiring und Onboarding darauf ausgerichtet ist, Tempo und Qualität in Balance zu halten.

Was uns besonders hängen geblieben ist: DIG baut eine Plattform, auf der Kunden ihre Geschäftsprozesse automatisieren und ihren Einkauf digital abwickeln. Hinter dieser knappen Beschreibung steckt ein langer technischer Weg – von Perl und PHP über eine eigens gebaute Workflow-Engine bis hin zu einer modernen Architektur mit Angular-Frontend, Microservices im Backend und der bewussten Nutzung von Cloud-Diensten wie AWS. Dazu kommt ein Delivery-Prozess, der bewusst nicht dogmatisch ist: Statt reines Scrum in Stein zu meißeln, kombiniert DIG praxistaugliche Elemente aus Scrum und Scrumban und lässt Raum für dynamische Kundenanforderungen.

„Unser Entwicklungsprozess ist Scrum angelehnt … wir haben jetzt einen Prozess, der eine Mischung aus Scrum und Scumban ist.“

Diese Haltung – pragmatisch, produktorientiert, menschenzentriert – zieht sich wie ein roter Faden durch Teamstruktur, Collaboration und Hiring.

Was DIG baut: Eine Plattform zur Automatisierung und für digitalen Einkauf

Gerald Sigmund fasst es schlicht, aber eindeutig:

„Wir bauen eine Plattform, die webbasiert ist, wo Kunden ihre Geschäftsprozesse automatisieren können und auch ihren Einkauf digital abwickeln.“

Aus Engineering-Perspektive bedeutet das: B2B-Workflows, Prozessabbildung, Integrationen und Datenflüsse, die robust und nachvollziehbar sein müssen. Die Plattform ist kein nice-to-have Feature-Set, sondern integraler Teil des Tagesgeschäfts der Kunden. Wer hier entwickelt, arbeitet an:

Automatisierten Geschäftsprozessen, die jeweils konkrete Abläufe abbilden und zuverlässig orchestriert werden müssen.
Digitalem Procurement, das Anforderungen, Freigaben, Bestellungen und Dokumente sicher und sauber durch das System führt.
Einem Web-Frontend, das komplexe Aufgaben zugänglich macht, sowie einem Microservices-Backend, das Änderungen und Erweiterungen strukturiert ermöglicht.

Die Mission ist damit greifbar: Komplexität beherrschbar machen – für Kunden, die Effizienz, Transparenz und Tempo in ihre Prozesse bringen wollen. Für Engineers ist das eine klare Ansage: Hier geht es um echten Produktnutzen, nicht um Spielereien.

Teamgröße und Rollen: Klein, klar, handlungsfähig

„In unserem Entwicklungsteam sind wir in Summe an die 11 Leute … aufgeteilt zwischen Entwicklern, wir haben ein Produktmanagement, System Operating und so ein Entwicklungsleiter, der die Issues alles schreibt für das Team und ich mache die Architektur bei uns für das Produkt.“

Elf Leute sind genug, um Tempo zu machen – und klein genug, um Reibungsverluste gering zu halten. Die Rollen sind klar abgesteckt:

Entwicklung fokussiert auf Delivery über Frontend, Backend und Fullstack.
Produktmanagement sorgt für die inhaltliche Ausrichtung und Priorisierung.
System Operating kümmert sich um Stabilität, Deployments und Betriebsaspekte.
Ein Entwicklungsleiter (Dev Lead) schreibt die Issues, hält also die taktische Brücke zwischen Produkt und Umsetzung.
Gerald Sigmund verantwortet als Chief Software Architect die Architektur.

Diese Aufstellung signalisiert: Verantwortung ist sichtbar. Wer hier arbeitet, spürt den eigenen Beitrag. Gleichzeitig schafft die klare Rollenverteilung Verbindlichkeit – besonders bei fachübergreifender Zusammenarbeit.

Prozess: Zweiwöchige Sprints, Dailies und bewusstes „Dynamik-Fenster“

DIG hat – auch das ist typisch für reife Engineering-Organisationen – mehrere Prozessvarianten ausprobiert, um die beste Passung zum eigenen Geschäft zu finden:

„Wir haben einmal mit Scumban gestartet gehabt, wir haben reines Scrum probiert, aber das hat nicht unbedingt perfekt für uns funktioniert, auch aufgrund von manchen Kundenanforderungen und daher haben wir jetzt einen Prozess, der eine Mischung aus Scrum und Scumban ist.“

Konkret heißt das:

Zweiwöchige Sprints
Sheds-Meetings und Dailies
Ein Anteil im Sprint, der „ein bisschen dynamischer“ ist

„Wir haben zwei wöchentliche Sprints, wir haben Sheds-Meetings, wir haben Dailies, aber wir haben einen gewissen Prozenteil im Sprint, der halt ein bisschen dynamischer ist.“

Dieser dynamische Anteil ist eine pragmatische Antwort auf Kundenrealität. Nicht jeder Bedarf lässt sich in lange Zyklen zwängen; Prioritäten verschieben sich, es tauchen Integrationsfragen auf, Fixes müssen zeitnah passieren. DIG räumt dieser Realität explizit Platz im Sprint ein – ohne das Team in permanenten Kontextwechsel zu zwingen.

Für Engineers ist das ein Gewinn: klare Taktung, aber keine Prozess-Dogmatik. Wer gerne strukturiert arbeitet und gleichzeitig nah an Kundenbedürfnissen bleibt, findet hier den passenden Rhythmus.

Hiring, jetzt mit HR: Klarer Ablauf, echte Einblicke

DIG hat die Bewerbungsprozesse zuletzt professionalisiert:

„Wir haben seit kurzem eine HR-Abteilung, seitdem läuft das ein bisschen professioneller ab.“

Das Setup ist bewusst schlank und menschenzentriert – und es gibt einen klaren Ablauf:

Bewerbung über verschiedene Plattformen (unter anderem über DevJobs).
Erstgespräch mit Entwicklungsleiter und HR-Managerin. Dabei werden Firma, Produkt und Entwicklungsprozess vorgestellt – und der Bewerber oder die Bewerberin erzählt, was bisher gemacht wurde und wo die Interessen liegen (Frontend, Backend oder Fullstack).
Schnuppertag: Meist 3–4 Stunden vor Ort im Büro. Austausch mit verschiedenen Leuten im Team, Blick ins Produkt, in die Codebasis und in den Entwicklungsprozess.
Wenn beide Seiten ein gutes Gefühl haben, wird ein Starttermin vereinbart.

„Da kommt dann der Bewerber meistens drei, vier Stunden zu uns ins Büro, da sitzt er sich dann zu den verschiedenen Leuten im Team, schaut sich das Produkt an, schaut sich die Codebasis ein bisschen durch, erzählt, wie es bei uns abläuft … und wenn es dann für beide passt, dann wird halt irgendein Starttermin festgelegt.“

Aus Kandidatensicht ist das ideal: kein Rätselraten, keine künstlichen Prüfungen, stattdessen ein realistischer Eindruck vom Alltag – und ein ehrliches Bild davon, wie zusammengearbeitet wird.

Onboarding: Setup, kleine Issues, dann Vollgas im Sprint

Der Einstieg ist bewusst niedrigschwellig gestaltet:

Technisches Setup und Orientierung.
„Spezielle kleine Issues“, um die Plattform kennenzulernen.
Schrittweise Integration in den regulären Sprintfluss.

„Am Anfang ist es halt so, dass man im Onboarding-Prozess halt alles ein bisschen erklärt kriegt, man macht einmal das Setup, man startet mit speziellen kleinen Issues, damit man die Plattform kennenlernt und je länger man im Team drinnen ist, umso mehr arbeitet man halt ganz normal im Sprint damit.“

Das ist gutes Handwerk: Kleine, abgeschlossene Aufgaben helfen, Codekonventionen, Architekturmuster und Domänenlogik zu verinnerlichen. Gleichzeitig geht es schnell in die produktive Arbeit über – genau die Balance, die ein effizientes Onboarding braucht.

Woran DIG Talent misst: Tech-Kompetenz und Teamfit – beides zählt

Bei der Auswahl betont DIG zwei Achsen:

Fachlicher Hintergrund und Technologieerfahrung, inklusive Präferenz für Frontend, Backend oder Fullstack.
Persönliche Passung zum Team.

„Was uns wichtig ist … der Hintergrund ist natürlich interessant … aber was halt auch wichtig ist, wie passt er persönlich zum Team … da ist es dann oft so, dass die Fähigkeiten nicht unbedingt das Wichtigste sind, sondern halt auch auf die Sympathie auch ein bisschen mitzuhalten.“

Das ist keine Oberflächlichkeit, sondern Organisationshygiene: Ein Team dieser Größe funktioniert nur, wenn Zusammenarbeit reibungsarm ist, Kommunikation stimmt und man sich gegenseitig etwas zutraut. Für Bewerbende heißt das: Offenheit und Neugier sind ebenso wichtig wie die eigene Tool-Kiste.

Technologie-Evolution: Von Perl und PHP zu Angular, Microservices und Cloud

Die Historie der DIG-Plattform zeigt, wie konsequent das Team Technologie als Mittel zum Zweck nutzt – und dabei Evolution vor Revolution stellt.

„Angefangen hat es in der DIG vor über 20 Jahren mit Perl und PHP … eine minimalistische Workflow-Engine, die halt Dokumente herummappt.“

Später kam das Procurement-System in PHP dazu. Irgendwann reichten die damaligen Ansätze nicht mehr, um Kundenwünsche abzubilden – ein Klassiker in wachsenden Plattformen. Die Antwort: eine neue Plattformgeneration.

„… wir haben dann vor einigen Jahren eine neue Plattform aufgebaut, die ist frontend-mäßig jetzt in Angular und im Backend verwenden wir Microservices. Da haben wir ja dieses Grails-Framework damals gefunden …“

Heute denkt DIG den nächsten Schritt:

„… inzwischen gibt es schon andere Frameworks, die schon ein bisschen moderner sind, also das ist das, was wir in Zukunft anstreben werden, zum Beispiel Micronaut oder andere Systeme.“

Parallel werden Cloud-basierte Dienste stärker forciert:

„Und was wir halt auch im Moment stark forcieren, sind halt Cloud-basierte Dienste … wie können wir AWS-Sachen verwenden, zum Beispiel Q-Systeme, Data-Storage …“

Für Engineers ist das ein spannendes Set:

Frontend mit Angular: Komplexe UI-Flüsse, State-Management und saubere Schnittstellen zum Backend.
Microservices im Backend (Grails, perspektivisch modernisiert, etwa Richtung Micronaut): Servicegrenzen, Schnittstellenverträge, Observability, Versionsmanagement.
Cloud-basierte Bausteine, speziell AWS: Queueing für entkoppelte Workloads, Storage für persistente Daten.

Wichtig: DIG betreibt keinen Selbstzweck. Die Technologie folgt dem Produkt, nicht umgekehrt. Das macht die Arbeit berechenbar und wirkungsvoll.

Zusammenarbeit im Alltag: Klarheit durch Issues, Nähe durch direkte Einblicke

Ein Detail mit großer Wirkung: Der Entwicklungsleiter schreibt die Issues fürs Team. Das schafft einheitliche Qualität in der Aufbereitung von Aufgaben und hält Product und Delivery eng zusammen. Für das Team bedeutet das:

Konsistente Beschreibung von Anforderungen und Akzeptanzkriterien.
Klarheit über Prioritäten im Sprint und im dynamischen Anteil.
Weniger Reibungsverluste zwischen Rollen.

Zudem bietet der Schnuppertag bereits vor dem Einstieg genau die Einblicke, die gute Zusammenarbeit braucht: Man sieht Code, Produkt und Prozess – real, nicht abstrakt. Wer danach startet, ist in der Regel bereits mental „drin“.

Warum DIG für Tech-Talente attraktiv ist

Aus dem Gesagten kristallisieren sich klare Gründe heraus, warum sich ein Wechsel zur DIG GmbH lohnt:

Wirkung statt anonymer Massenstruktur: Mit rund elf Leuten ist jeder Beitrag sichtbar und entscheidend.
Produkt, das echte Prozesse trägt: Geschäftsprozess-Automatisierung und digitaler Einkauf sind relevante, anspruchsvolle Domänen.
Pragmatische Prozesse: Zweiwöchige Sprints, Dailies und ein bewusst eingeplanter dynamischer Anteil statt Prozess-Dogmatik.
Klarer Hiring-Prozess mit echtem Einblick: Erstgespräch mit Dev Lead und HR, Schnuppertag im Büro, keine künstliche Hürde.
Sorgfältiges Onboarding: Setup, kleine Issues, zügiger Übergang in den Sprintfluss.
Moderne, evolvierende Architektur: Angular-Frontend, Microservices-Backend (Grails, Ausblick auf Micronaut), gezielter Einsatz von AWS.
Teamfit zählt: Zusammenarbeit auf Augenhöhe, Sympathie und Miteinander als echter Selektionsfaktor.

Diese Mischung aus technischer Substanz, organisationaler Klarheit und menschlicher Passung ist besonders selten – und genau deshalb für viele Entwicklerinnen und Entwickler so attraktiv.

Was Bewerbende konkret erwarten dürfen

Gerald Sigmund zeichnet ein realistisches Bild davon, wie ein Bewerbungsprozess bei DIG abläuft und worauf es ankommt:

Ein Erstgespräch, in dem beide Seiten offen über Erfahrungen, Technologien und Präferenzen (Frontend, Backend, Fullstack) sprechen.
Einen Schnuppertag, an dem man mit verschiedenen Teammitgliedern spricht, die Plattform erlebt und die Codebasis sichtet – ungeschminkt und praxisnah.
Ein Onboarding, das ohne Druck, aber mit klaren Schritten ins Sprintgeschehen führt.

Wer sich vorbereitet, profitiert: Eigene Projekte kurz und prägnant beschreiben, die persönlichen Interessen transparent machen, Fragen zu Entwicklungsprozess, Code-Qualität und Deployments mitbringen. Vor allem aber: offen auftreten. Denn DIG bewertet ausdrücklich nicht nur die Skills, sondern die Passung ins Team.

Führung und Architektur: Entscheidungsfreude ohne Dogma

Der Mix aus klarer Architekturverantwortung (Chief Software Architect) und operativer Taktung (Dev Lead schreibt Issues) sorgt für Entscheidungsfreude – ohne dogmatisch zu werden. Ob Prozess (Scrum/Scrumban), Stack (Grails heute, Micronaut als Perspektive) oder Cloud-Einsatz (Queues, Storage): Entscheidungen werden getroffen, evaluiert und iteriert. Das gibt Orientierung, ohne Beweglichkeit zu verlieren.

Für Engineers ist das Gold wert: Architekturreife und Lernkurve greifen ineinander. Wer sich an Service-Schnittstellen, API-Verträgen, asynchronen Mustern und UI-State-Management abarbeiten will, bekommt bei DIG das passende Umfeld – mit einem Team, das nahbar ist und die eigenen Entscheidungen erklären kann.

Kundenorientierung als Taktgeber

Der dynamische Sprint-Anteil ist ein Bekenntnis zur Kundenorientierung. Anforderungen ändern sich. Unerwartete Integrationsfragen tauchen auf. DIG baut das nicht als Ausnahme, sondern als Regelmechanik ein. Für die Praxis heißt das:

Fokus-Phasen im Sprint werden durch klar adressierte Ad-hoc-Themen ergänzt.
Das Team darf und soll Prioritäten pragmatisch zugunsten des Kunden verschieben, wenn nötig.
Die Prozessdisziplin bleibt erhalten – sie wird intelligent erweitert, nicht aufgegeben.

Diese Balance funktioniert nur, wenn Kommunikation stimmt. Genau deshalb ist Teamfit bei DIG kein Soft-Faktor, sondern kritischer Erfolgsfaktor.

Lernen im Fluss: Kleine Issues, großer Kontext

Die Onboarding-Strategie – von kleinen Issues ins Sprintgeschehen – ist mehr als eine Nettigkeit. Sie verankert Lernfortschritt in echter Arbeit. In Microservices-Umgebungen ist das besonders wertvoll: Kontexte sind klarer, Grenzen definierter, Tests und Deployments greifbarer. Wer die ersten Issues sauber bearbeitet, versteht bald auch die übergreifenden Architekturentscheidungen – und kann Verantwortung zügig ausbauen.

Technische Schlaglichter, die sich aus der Session ableiten

Ohne über die Session hinauszugehen, lassen sich einige technische Leitplanken festhalten:

Angular-Frontend: Komponentenarchitektur, Routing, Formulare, State und Performance als wiederkehrende Themen.
Microservices-Backend: Servicekomposition, Schnittstellenverträge, Versionierung, Observability.
Grails-Stack heute, Perspektive auf modernere Frameworks wie Micronaut: Migrationen, Schnittstellenstabilität und schrittweise Modernisierung.
AWS-gestützte Bausteine: Queues für asynchrone Entkopplung, Data-Storage als verlässliche Grundlage für Dokumente und Prozessdaten.

Für Engineers ist dieses Setup weder exotisch noch trivial – es ist genau richtig, um Handwerk zu vertiefen, Architektur zu lernen und Wirksamkeit zu erleben.

Fazit: Ein kleineres Team, das groß denkt – und konsequent liefert

„Gerald Sigmund, Chief Software Architect von DIG“ hat uns gezeigt, wie die DIG GmbH Technologie und Organisation pragmatisch verzahnt: mit einer Plattform, die reale Prozesse trägt, mit einer Architektur, die Schritt für Schritt modernisiert wird, und mit einem Hiring, das Menschen in den Mittelpunkt stellt. Wer eine Umgebung sucht, in der Klarheit, Verantwortungsfreude und Kundenorientierung zusammenkommen, findet hier genau den richtigen Ort – mit einem Team, das seine Energie in Wirkung übersetzt.

„Je länger man im Team drinnen ist, umso mehr arbeitet man halt ganz normal im Sprint damit.“

Genau darum geht es: schnell ankommen, im Fluss lernen – und gemeinsam liefern.

Weitere Dev Stories