DIG GmbH

Established Company

Show all Videos

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.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "Gerald Sigmund, Chief Software Architect von DIG", Gerald Sigmund explains how a roughly 11-person team builds a web platform for business process automation and digital procurement using a hybrid Scrum/Scrumban model with two-week sprints, Dailies, and a dynamic sprint slice to handle changing customer needs. Hiring starts with an initial meeting with the development lead and HR, followed by a 3–4-hour in-office trial day and structured onboarding with setup and small starter issues; candidates may focus on Frontend, Backend, or Full-Stack, with cultural fit valued alongside skills. The stack has evolved from Perl/PHP to an Angular front end with microservices on Grails, with plans to move toward newer frameworks (e.g., Micronaut) and increased use of AWS services like queues and storage.

Inside DIG GmbH with Gerald Sigmund, Chief Software Architect von DIG: Hybrid Scrum, Microservices, and a People-first Hiring Journey

What we learned at DevJobs.at

In the session “Gerald Sigmund, Chief Software Architect von DIG,” with Gerald Sigmund from DIG GmbH, we heard a clear, grounded account of how a compact engineering team evolves a complex, web-based platform—while aligning processes, hiring, and onboarding to keep both speed and quality in check.

The essence is straightforward: DIG builds a platform that lets customers automate business processes and run their procurement digitally. Behind that short description lies a long technical path—from Perl and PHP and a custom workflow engine to a modern architecture with an Angular front-end, microservices on the back-end, and a measured adoption of cloud capabilities like AWS. And instead of strict process dogma, DIG combines the best of Scrum and Scrumban to leave intentional room for dynamic customer needs.

“Our development process is Scrum-inspired … we now have a process that’s a mix of Scrum and Scrumban.”

That mindset—pragmatic, product-focused, and people-centered—runs through team structure, collaboration, and hiring.

What DIG builds: A platform for automation and digital procurement

Gerald put it succinctly:

“We’re building a web-based platform where customers can automate their business processes and also handle their purchasing digitally.”

From an engineering perspective, that means B2B workflows, process orchestration, integrations, and data flows that must be robust and auditable. The platform isn’t a nice-to-have—it’s embedded in customers’ daily operations. Engineers here work on:

Automated business processes that map real-world flows and need reliable orchestration.
Digital procurement flows that shepherd requests, approvals, orders, and documents safely through the system.
A web front-end that makes complex tasks accessible, and a microservices back-end that enables structured change and extension.

The mission is tangible: make complexity manageable for customers who want efficiency, transparency, and speed. For engineers, it’s a clear promise: real product impact, not gimmicks.

Team shape and roles: Small, clear, capable

“Our development team is about 11 people in total … split between developers; we have product management, system operating, and a development lead who writes the issues for the team, and I handle the architecture for the product.”

Eleven people are enough to move fast—and small enough to minimize friction. The roles are clearly defined:

Engineering focuses on delivery across front-end, back-end, and full stack.
Product management sets direction and prioritization.
System operating minds stability, deployments, and operational concerns.
A development lead writes the issues, bridging product and execution.
Gerald Sigmund, as Chief Software Architect, owns the architecture.

This setup signals visible ownership. Everyone feels their impact. At the same time, crisp role boundaries foster accountability, especially across functions.

Process: Two-week sprints, dailies, and an intentional “dynamic window”

DIG experimented with process models to match the rhythm of their business:

“We started with Scrumban, tried pure Scrum, but that didn’t work perfectly for us—partly due to customer requirements—so we now have a process that’s a mix of Scrum and Scrumban.”

Concretely:

Two-week sprints
Sheds-meetings and dailies
A portion of each sprint reserved for dynamic work

“We have two-week sprints, we have sheds-meetings, we have dailies, but we have a certain percentage in the sprint that’s a bit more dynamic.”

That dynamic portion is a pragmatic response to customer reality. Not every need fits neatly into longer cycles; priorities shift; integrations pop up; fixes are sometimes time-sensitive. DIG carves out explicit space for that reality—without subjecting the team to constant context-switching.

For engineers, it’s an advantage: clear cadence without process dogma. If you like to work with structure and stay close to customer needs, this rhythm fits.

Hiring with HR in the loop: A clear process, real exposure

DIG recently formalized hiring:

“We’ve had an HR department since recently; since then, things have been running a bit more professionally.”

The setup remains lean and human-centered, with a clear sequence:

Application via various platforms (including DevJobs).
An initial interview with the development lead and the HR manager. The company, product, and development process are presented; the candidate shares past experience and whether the interest lies in front-end, back-end, or full stack.
A trial day: typically three to four hours on-site at the office. Meet different team members, explore the product, skim the codebase, and understand the development process firsthand.
If both sides feel it fits, a start date is agreed.

“The candidate usually comes to our office for three or four hours, sits with different people on the team, looks at the product, goes through the codebase a bit, hears how things work here … and if it fits for both, then a start date is set.”

From a candidate’s perspective, that’s ideal: no guessing games, no artificial tests—just a realistic view of the day-to-day and how collaboration actually works.

Onboarding: Setup, small issues, then into the sprint flow

The starting experience is intentionally low-friction:

Technical setup and orientation
“Special small issues” to learn the platform
Gradual integration into the regular sprint flow

“At the beginning … you get explanations, do the setup, start with specific small issues so you can get to know the platform, and the longer you’re in the team, the more you work in the sprint as normal.”

It’s sound craftsmanship: small, scoped tasks help internalize code conventions, architecture patterns, and domain logic. At the same time, it transitions quickly into productive work—the balance good onboarding needs.

What DIG values in candidates: Technical competence and team fit

DIG emphasizes two axes:

Technical background and experience with technologies, including your preference for front-end, back-end, or full stack.
Personal fit with the team.

“The background is of course interesting … but what’s also important is how the person fits the team … sometimes the skills aren’t the most important thing; sympathy and fit matter, too.”

This isn’t superficial—it’s organizational hygiene. A team this size only functions if collaboration is smooth, communication works, and people trust each other. For applicants, that means openness and curiosity are as important as your toolbox.

Technology evolution: From Perl/PHP to Angular, microservices, and cloud

DIG’s platform history shows a team treating technology as a means to an end—and preferring evolution over revolution.

“It started at DIG over 20 years ago with Perl and PHP … a minimalist workflow engine that maps documents.”

Later, a procurement system in PHP was added. Eventually, that setup no longer covered customer needs—so DIG built a new platform generation.

“A few years ago we built a new platform; front-end is Angular and the back-end uses microservices. We found the Grails framework at the time …”

Today, the next step is on the horizon:

“… meanwhile there are other frameworks that are a bit more modern; that’s what we’re aiming for in the future, for example Micronaut or other systems.”

In parallel, DIG is ramping up cloud-based services:

“We are currently strongly focusing on cloud-based services … how can we use AWS, for example queue systems, data storage …”

For engineers, that’s a compelling set:

Angular on the front-end: components, routing, forms, state management, and clean back-end contracts.
Microservices on the back-end (Grails, with an eye toward modernizing, e.g., Micronaut): service boundaries, interface contracts, observability, version management.
Cloud building blocks on AWS: queues for decoupled workloads and storage for persistent data.

Crucially, DIG avoids tech for tech’s sake. Technology follows the product, not the other way around.

Day-to-day collaboration: Clarity through issues, closeness through real exposure

One detail with outsized impact: the development lead writes the issues for the team. That enforces a consistent level of quality in how work is framed and keeps product and delivery tight. It means:

Consistent descriptions and acceptance criteria
Clarity of priorities across the sprint and its dynamic portion
Less friction across roles

Additionally, the trial day gives candidates the kind of insight that feeds good collaboration: real code, real product, and real process. Those who join have already formed an authentic mental model of the work.

Why DIG appeals to engineers

From the session, several clear reasons emerge to consider DIG GmbH:

Impact without the anonymity of a huge organization: with around eleven people, every contribution is visible and consequential.
A product that carries real processes: business process automation and digital procurement are relevant, demanding domains.
Pragmatic process: two-week sprints, dailies, and an intentionally carved-out dynamic slice—no process dogma.
A transparent hiring journey: initial interview with the dev lead and HR, an in-office trial day, no artificial hurdles.
Thoughtful onboarding: setup, small issues, and a quick transition into sprint work.
A modern, evolving architecture: Angular on the front-end, a microservices back-end (Grails now, aiming at frameworks like Micronaut), and targeted use of AWS.
Team fit matters: collaboration on equal footing, with sympathy and mutual fit treated as a first-class factor.

It’s a rare mix of technical substance, organizational clarity, and human fit—exactly what many developers seek.

What candidates can expect

Gerald sketches a realistic picture of the process and expectations:

An initial conversation where both sides speak openly about experience, technologies, and front-end/back-end/full-stack preferences.
A trial day meeting multiple team members, seeing the product, and scanning the codebase—unvarnished and practical.
Onboarding that’s unrushed but structured, leading quickly into the sprint rhythm.

Bring concise narratives of your past work, be transparent about your interests, and come with questions about process, code quality, and deployments. Most importantly, show up openly—DIG explicitly values fit alongside skills.

Leadership and architecture: Decisive without being dogmatic

The combination of clear architecture ownership (Chief Software Architect) and operational cadence (dev lead writing issues) fosters decisiveness without rigidity. Process (Scrum/Scrumban), stack (Grails now, Micronaut ahead), and cloud usage (queues, storage) are decided, evaluated, and iterated. That offers direction without sacrificing agility.

For engineers, that’s invaluable: maturity in architecture and a steady learning curve. If you want to work on service interfaces, API contracts, asynchronous patterns, and UI state—this environment fits.

Customer orientation sets the tempo

The dynamic sprint portion is a commitment to customer reality. Requirements change. Integration questions appear. DIG treats that not as an exception but a mechanism:

Focus periods in the sprint are augmented by clearly addressed ad-hoc topics.
The team is expected to pragmatically adjust priorities in favor of the customer when needed.
Process discipline remains intact—expanded intelligently, not abandoned.

This balance only holds if communication is strong. That’s why team fit is not a soft factor at DIG; it’s a core success driver.

Learning in flow: Small issues, big context

The onboarding path—from small issues into the sprint flow—is more than a kindness. It roots learning in real delivery. In a microservices environment, that’s particularly valuable: contexts are clearer, boundaries well-defined, tests and deployments tangible. If you handle the first issues cleanly, you quickly grasp the broader architectural decisions—and can grow ownership fast.

Technical highlights drawn from the session

Staying strictly within session content, several guideposts stand out:

Angular front-end: component architecture, routing, forms, state, and performance as recurring concerns.
Microservices back-end: service composition, interface contracts, versioning, and observability.
Grails today, aiming toward more modern frameworks like Micronaut: migration, interface stability, and phased modernization.
AWS-based building blocks: queues for asynchronous decoupling and data storage as a reliable foundation for documents and process data.

This setup is neither exotic nor trivial—it’s precisely right for deepening craft, learning architecture, and delivering impact.

Conclusion: A small team that thinks big—and delivers consistently

“Gerald Sigmund, Chief Software Architect von DIG” showed how DIG GmbH weaves technology and organization pragmatically: a platform that carries real processes, an architecture that is steadily modernized, and a hiring approach that puts people first. If you’re looking for an environment where clarity, ownership, and customer orientation align, this is it—a team that channels its energy into meaningful outcomes.

“The longer you’re in the team, the more you work in the sprints as normal.”

That’s the point: arrive quickly, learn in flow, and deliver together.

More Dev Stories