Engineering bei TGW Logistics Group: Autonome Scrum-Teams, .NET‑Modernisierung und Teamfit im Fokus – Einblicke aus „Mario Leitner, Head of Software Development bei TGW Logistics Group“

Warum uns diese Session beeindruckt hat

Wir bei DevJobs.at haben die Session „Mario Leitner, Head of Software Development bei TGW Logistics Group“ besonders aufmerksam verfolgt. Speaker Mario Leitner gab einen selten klaren, praxisnahen Blick in eine IT-Organisation, die TGW-weit „bis zu 700 IT-Mitarbeiter“ umfasst – und die zugleich großen Wert auf schlanke Kommunikation, eigenständige Teams und eine robuste Modernisierungsagenda legt. Was wir mitgenommen haben: TGW verbindet bewährte Strukturen (Scrum, Product Ownership, Teamleitung) mit einem Technologiepfad, der konkret und nachvollziehbar Richtung Container, Linux, Azure Pipelines und ein gruppenweites Frontend-Portal führt. Gleichzeitig bleibt der Mensch – und passender Teamfit – im Recruiting das entscheidende Kriterium.

Diese Haltung zieht sich als roter Faden durch Organisation, Hiring und Tech-Entscheidungen – und macht TGW für Entwicklerinnen und Entwickler greifbar: klare Rollen, Zusammenarbeit über Standorte hinweg, und ein Stack zwischen C#/.NET, Oracle und einem Vue.js‑basierten Portal, der mit jedem Sprint moderner wird.

Teamlandschaft: Drei Programmierteams, klare Schwerpunkte, gemeinsame Architektur

In Leitners Bereich arbeiten rund „20 bis 25 Mitarbeiter“, organisiert in „drei Programmierteams“. Zwei Teams kümmern sich primär um die Logistiksoftware, ein drittes Team verantwortet UI/UX – konkret die „Implementierung eines Frameworks, auf dem man dann basieren kann“. Damit schafft TGW eine Basis, auf der Frontend-Teams einheitlich arbeiten können: wiederverwendbare Komponenten, konsistente User Experience, schnelleres Onboarding.

TGW-weit liegt der Fokus auf agilen Entwicklungsmodellen – mit „Scrum-Teams, die entweder nach Scrum [oder] Scrumban arbeiten“. Jede Einheit hat die Kernrollen an Bord: Entwickler, „Scrum-Master, [und] Product Owner“. In der Praxis werden diese Rollen „oft über Teams geshared“. Besonders bemerkenswert: „Wir haben einen Scrum-Master … für drei Teams, der sich um alle drei Teams kümmert, was sehr gut ankommt.“ Das schafft Synergien, vereinheitlicht Moderation und erleichtert teamübergreifende Abstimmung.

Übergreifend sichern „Tech-Leads und Software-Architekten“ die Architektur des Gesamtsystems – verteilt über mehrere TGW-Standorte: „Mach-Trink“, „Wölz“ und „in Deutschland draußen“. Diese Struktur ermöglicht es, Entscheidungen über Grenzen einzelner Teams hinweg konsistent zu halten, ohne die lokale Handlungsfähigkeit zu beschneiden.

Warum diese Aufstellung wirkt

• Klare Fokusteams: Logistik-Kernsoftware und UI/UX-Framework sind sauber getrennt, zugleich verzahnt.
• Rollen mit On-the-ground-Wirkung: Entwickler, PO, Scrum Master – und das pragmatisch geteilt, wo es Sinn macht.
• Architektur als gemeinsamer Nenner: Tech-Leads und Architekten sorgen standortübergreifend für Kohärenz.

Für uns steht fest: Diese Kombination fördert Geschwindigkeit, Qualität und Wiederverwendbarkeit – und gibt Talenten die Wahl, ob sie lieber am logistischen Kern, auf der UI/UX-Schiene oder in der Architektur/Enablement-Schicht arbeiten möchten.

Führung und Kommunikation: Teamleitung als tägliches Sprachrohr, Management als Abkürzung – nicht als Hürde

Ein markantes Organisationsprinzip bei TGW: Jedes Team hat „einen eigenen Teamleiter“, der „wirklich ein Sprachrohr für das gesamte Team darstellt“. Gleichzeitig bleibt die „Kommunikation zum Team auch von Management-Seiten her sehr flach … und auch sehr direkt“. Beides zusammen – täglicher, greifbarer Teamlead und kurze Wege ins Management – senkt Reibung, beschleunigt Entscheidungen und gibt Richtung, ohne Mikromanagement zu betreiben.

Leitner formuliert das pragmatisch: „Es ist einfach wichtig, dass man einen hat, an den man sich ständig und täglich wenden kann – und das versucht man durchgehend durchzuziehen.“ Für Entwicklerinnen und Entwickler bedeutet das: Es gibt eine Ansprechperson, die den Kontext kennt, Hindernisse beseitigen hilft und den Draht nach „oben“ herstellt, wenn nötig.

Was das im Alltag ausmacht

• Verlässlicher Ansprechpartner: Der Teamleiter kennt Ziele, Backlog, Hindernisse – und nimmt Feedback ernst.
• Flache Eskalationswege: Wo Entscheidungen gebraucht werden, sind sie erreichbar – ohne Overhead.
• Schutz der Autonomie: Führung organisiert den Rahmen, die Teams liefern eigenständig.

Dieses Zusammenspiel trägt die Kultur der „sehr eigenständigen Teams“, von der Leitner spricht – und schafft zugleich Sicherheit in der täglichen Arbeit.

Recruiting: Erster Fit mit Fachbereichen, dann Teaminterview – und eine ehrliche Wahlmöglichkeit

TGW ist groß genug, um Recruiting professionell zu zentralisieren – und nah genug am Engineering, damit der Prozess an der fachlichen Realität ausgerichtet bleibt. Der Ablauf nach Leitner:

1) Eingang und Pre-Screening durch die Recruiting-Abteilung: „Dann wird der erste Check gemacht: Wo passt er? Zu welcher Stellenbeschreibung passt er?“ Anschließend gehen die Profile „direkt an das Team … an den Leiter dort“.

2) Erstes Bewerbungsgespräch mit bis zu drei Teamleitern: „Das hat einen super Grund – nämlich, dass der Bewerber oder die Bewerberin einfach mal kennenlernt: Es gibt ja mehr Bereiche in der TGW, die sich mit Software beschäftigen … und dadurch auch verschiedenste Einsatzmöglichkeiten.“ Jeder Bereich „stellt sich vor“, damit am Ende beider Seiten „ein guter Eindruck“ vom gemeinsamen Arbeiten entsteht.

3) Präferenz klären und zweites Gespräch: Nach dem Erstgespräch wird gefragt, „für was für einen Bereich er sich interessiert“. In Abstimmung mit den Teamleitern folgt das zweite Gespräch. Dort geht es um „Details … wie schaut das denn wirklich im täglichen Arbeiten aus, wie schaut die Umgebung aus“ – und um das Herzstück des Prozesses:

4) Teaminterview: „Der Bewerber oder die Bewerberin lernt das Team kennen … Und das Team lernt den neuen Kollegen, die neue Kollegin kennen.“ Hier werden sowohl technische Erfahrung als auch Persönliches beleuchtet: „Gehen wir miteinander laufen?“ – also: Passen Arbeitsstil und Miteinander. Leitners Anspruch ist klar: Skills sind wichtig, aber „er muss ins Teamgefüge passen“.

5) Entscheidung und Angebot: Nach dem Teaminterview folgt die Entscheidung – „hoffentlich mit einem Angebot“ – und im Idealfall der Start mit dem Leitsatz: „TGW is my company.“

Was uns daran gefällt

• Echte Wahlmöglichkeit: Bewerberinnen und Bewerber sehen mehrere Bereiche – und wählen mit.
• Team entscheidet mit: Das spätere Umfeld prüft Fit und macht die finalen Annahmen tragfähiger.
• Praxisorientierte Transparenz: Im zweiten Gespräch geht es um „Details“ und den realen Alltag – nicht nur um Folien.

Für Talente heißt das: Ihr werdet als künftige Kolleginnen und Kollegen ernst genommen – und ihr wisst vor der Zusage, mit wem ihr zusammenarbeitet und welche Aufgaben auf euch warten.

Technologiepfad: Von .NET Framework zu .NET Core, vom Eigenbau zu Azure Pipelines – und ein neues Vue.js‑Portal

TGW spart in der Session nicht mit Details zur Technik. Ausgangslage und Zielbild sind transparent:

• Legacy gibt es – aber fokussiert: „PL/SQL auf Oracle“ ist „nicht unsere Haupttechnologie“.
• Schwerpunkt heute: „.NET Framework, C# … fast die gesamte Software ist auf dem 4.8 Framework.“
• Ziel morgen: „Umstieg auf .NET Core“, um „auf Container-Deployment [und] Linux-Systeme“ zu gehen. Das ist die „Basis“ für die Plattform-Modernisierung.
• Frontend: ein neues „TGW-Portal“, dessen Technologie „Vue.js“ ist – mit einem Framework-Ansatz, „auf Basis von einem Framework an Apps und Widgets“ zu entwickeln.
• Java gehört dazu: „Nichtsdestotrotz gibt es … Java-Entwicklung … auch ihr seid herzlich willkommen.“
• Datenbanken: „vorrangig Oracle“, punktuell „MySQL“.
• Tooling: Weg „von selbst gestrickten Tools … wirklich zu Azure Pipelines“ – mit dem Ziel „automatischen Container-Deployment“.
• Betriebsmodelle: „Cloud-basierte Lösungen oder Komponenten-basierte Lösungen … wo es möglich ist“, daneben „On-Premise-Lösungen, die sich einfach nicht ablösen lassen“, aber „in Komponenten aufzuteilen“, um „skalierbarer zu werden“.

Warum das für Entwicklerinnen und Entwickler spannend ist

• Modernisierung mit Substanz: Migration auf .NET Core und Linux-Container ist kein Buzzword, sondern klarer Plan.
• Frontend mit Wirkung: Vue.js als konzernweites Portal-Framework – Apps und Widgets als Produktionsfokus.
• DevOps-Pragmatismus: Azure Pipelines statt Eigenbau, automatisches Container-Deployment als Zielbild.
• Vielfalt statt Einspur: C#, Java, Oracle, MySQL – je nach Team und Projekt.
• Realismus im Betrieb: Cloud, wo sinnvoll; On-Premise, wo nötig; komponentenbasiert, um beides zu verbinden.

Diese Roadmap ist weder dogmatisch noch beliebig – sie nimmt bestehende Systeme ernst und formt daraus eine moderne, skalierbare Softwarelandschaft.

Zusammenarbeit über Standorte: Variantenreichtum als Lernfeld, Architektur als Klammer

Leitner beschreibt die TGW-Realität als „sehr, sehr viele Varianten“ – organisatorisch wie technologisch. Für die Zusammenarbeit bedeutet das: gemeinsam lernen, vergleichen, vereinheitlichen – ohne platt zu standardisieren. Geteilte Scrum Master, produktnahe Teamleiter und standortübergreifende Architekturen sind die Mittel der Wahl.

Wo Vielfalt sonst isoliert, sorgt diese Rolle für Verbindungen: Lessons Learned wandern schneller, Impediments werden sichtbar, Prioritäten bleiben synchronisiert. Tech-Leads und Architekten halten das große Bild zusammen – über „Mach-Trink“, „Wölz“ und Deutschland hinweg – und unterstützen die Teams beim Austarieren von Autonomie und Einheitlichkeit.

Was TGW vom Teamfit erwartet – und was Talente dafür bekommen

Leitner formuliert es ohne Umwege: Ein „perfekter Entwickler“ reicht nicht – die Person muss „ins Teamgefüge passen“. Das ist kein Nice-to-have, sondern Notwendigkeit. Denn „wir setzen auf sehr eigenständige Teams“, und die funktionieren nur, wenn „Respekt gegenseitig da ist“.

Was Talente dafür bekommen, ist eine Arbeitsumgebung, in der Teams ernst genommen werden: Sie stellen sich im Erstgespräch vor, sie lernen Kandidatinnen und Kandidaten kennen, sie entscheiden mit. Diese Mitverantwortung fördert Zusammenhalt – und reduziert das Risiko teurer Fehlentscheidungen für alle.

Konkrete Gründe, warum Entwicklerinnen und Entwickler TGW prüfen sollten

• Eigenverantwortung mit Rückhalt: Autonome Teams, klare Ansprechpartner, flache Managementwege.
• Spürbare Engineering-Kultur: Scrum/Scrumban, POs und Scrum Master mit teamübergreifendem Blick.
• Architektur als Karrierefeld: Tech-Leads/Architekten arbeiten am Gesamtsystem – standortübergreifend.
• Stack mit Zukunft: .NET Core, Linux-Container, Azure Pipelines; vorne ein gruppenweites Vue.js‑Portal.
• Realistische Vielfalt: C#, Java, Oracle – kombiniert mit Komponentenansätzen und On-Prem/Cloud-Denken.
• Transparenter Bewerbungsprozess: Erstgespräch mit mehreren Teamleitern, zweites Gespräch mit Alltagsfokus, Teaminterview als Herzstück.

Alltag und Entwicklungsmöglichkeiten – abgeleitet aus der Session

Ohne ins Spekulative zu gehen, lässt die Session erkennen, wie sich Alltag und Entwicklung anfühlen dürften:

• Wer tief ins Backend möchte, arbeitet mit C#/.NET Framework (heute) und begleitet den Wechsel zu .NET Core (morgen) – inklusive Container- und Linux‑Zielen.
• Wer Frontend gestalten will, baut auf dem Vue.js‑Framework Apps und Widgets für das „TGW-Portal“.
• Wer Plattform und Auslieferung verbessern möchte, unterstützt den Wechsel von Eigenbau auf „Azure Pipelines“ und treibt „automatisches Container-Deployment“ voran.
• Wer Systemperspektive sucht, findet in der Architektur-Rolle Anknüpfungspunkte – gemeinsam mit Tech-Leads über Standorte hinweg.

Jede dieser Bahnen profitiert von der beschriebenen Teamautonomie, klaren Ansprechpartnern und einem Recruiting, das bereits im Prozess die reale spätere Zusammenarbeit abbildet.

Fazit: Technische Modernisierung mit Bodenhaftung – und Teams, die tragen

Die Session „Mario Leitner, Head of Software Development bei TGW Logistics Group“ zeigt eine Organisation, die beides ernst nimmt: Technologie und Zusammenarbeit. Der Weg von .NET Framework 4.8 zu .NET Core, von Eigenbau-Deployments zu Azure Pipelines, von Einzelanwendungen zum Vue.js‑basierten Portal – all das geschieht nicht im luftleeren Raum. Es wird getragen von Teams, die eigenständig arbeiten, von Scrum Mastern, die Verbindungen schaffen, und von Teamleitern, die als tägliches Sprachrohr den Rahmen halten.

Das Recruiting spiegelt diese Haltung konsequent: mehrere Teamleiter im Erstgespräch, ein zweites Gespräch mit Alltagsdetails – und ein Teaminterview, das technische Stärken und menschliche Passung gleichermaßen prüft. Am Ende steht im besten Fall eine Entscheidung mit Haltung – „TGW is my company“. Für uns ist klar: Wer eine Mischung aus praktischer Modernisierung, klaren Strukturen und respektvoller Teamkultur sucht, sollte sich TGW Logistics Group genauer ansehen.

• 

  

  Speed Up Your Pipeline

  Thomas Svoboda von TGW Logistics Group teilt in seinem devjobs.at TechTalk einige Ansätze, wie man Azure DevOps Pipelines optimieren könnte.

  Jetzt ansehen

• 

  

  Klausmair Philipp, Head of Global Controls Tool Development bei TGW Logistics Group

  Head of Global Controls Tool Development bei der TGW Logistics Group Philipp Klausmair erzählt im Interview über das vergleichsweise neue Team im Unternehmen, wie dort das Recruiting abläuft und gibt Einblick in die verwendeten Technologien.

  Jetzt ansehen

• 

  

  Philipp Aumayr, Senior Software Developer Simulation bei TGW Logistics Group

  Philipp Aumayr von der TGW Logistics Group erzählt im Interview über seine Anfänge beim Programmieren, welche Themen bei seiner heutigen Arbeit nach wie vor relevant sind und gibt Tipps für Neulinge.

  Jetzt ansehen
• 

  

  Sascha Beyer, Full Stack Developer bei TGW Logistics Group

  Sascha Beyer von der TGW Logistics Group berichtet im Interview über seinen Werdegang, was er im Unternehmen als Full Stack Developer macht und gibt Tipps für Anfänger.

  Jetzt ansehen