Virtuelle Inbetriebnahme, globales Engineering und fokussiertes Hiring: Was wir aus „Klausmair Philipp, Head of Global Controls Tool Development bei TGW Logistics Group“ mitnehmen

Ein junger Teambereich mit großem Hebel im Realisierungsprozess

In der Session „Klausmair Philipp, Head of Global Controls Tool Development bei TGW Logistics Group“ gab Philipp Klausmair einen präzisen und praxisnahen Einblick in einen noch jungen, aber wirkungsstarken Bereich: sein Global-Controls-Tool-Team. Seit rund fünf Jahren als eigenständige Einheit aktiv, verantwortet das Team drei Tools, die im Realisierungsprozess sämtlicher Kundenprojekte zum Einsatz kommen. Zwei dieser Tools sind direkt „im Büro“ von Klausmair angesiedelt; ein drittes wird hauptsächlich in den USA entwickelt, während „alle Agenden, Budgetplanung, Kostenplanung usw. über das Büro in Wales“ laufen.

Wir haben besonders mitgenommen: Dieses Team ist klein, global verteilt und technisch fokussiert – und die Tools dahinter sind nicht Add-ons, sondern tägliche Arbeitsgrundlage in jedem Projekt. Für Entwicklerinnen und Entwickler, die Wirkung im Alltag spüren wollen, ist das ein klares Signal.

Teamgröße, Setup und Rollen – transparent und hands-on

Aktuell besteht das Team aus neun Mitgliedern inklusive Leitung. Drei Kolleg:innen arbeiten in Amerika, der Rest verteilt sich auf die beiden Tools im „Klausmair-Büro“. Die Bandbreite an Profilen ist groß, ebenso die Altersspanne im Team: „Der Älteste ist 55, der Jüngste 21.“ Die Kultur: pragmatisch, respektvoll und mit einem klaren Fokus darauf, dass Technik und Persönlichkeit zusammenpassen.

• Global verteiltes Setup mit klarer Verantwortung je Tool
• Neun Teammitglieder (inkl. Head), davon drei in den USA
• Altersdiversität als Normalfall – 21 bis 55 Jahre
• Spezialisierungen entlang Back-end/Front-end erwünscht und möglich

Klausmair betont, dass sich jede und jeder nach Energie und Interesse entfalten kann: „Da gibt es immer Möglichkeiten, wo sich gerade jeder mit seiner Energie austoben will … Back-end, Front-end … es gibt eigentlich alle Möglichkeiten bei uns im Team.“

Tool 1 im Fokus: Field Emulation – virtuelle Inbetriebnahme als Standard

Seit etwa sieben Jahren arbeitet das Team an der Field Emulation – einem Schlüsseltool, das Steuerungen vorab in Betrieb nimmt. Kurzum: Virtuelle Inbetriebnahme verschiebt Testaufwände von der Baustelle ins Büro. Das spart Zeit, reduziert Risiken und schafft Komfort für die Controls- und Engineering-Teams.

Warum das relevant ist:

• Testdurchläufe werden schneller und wiederholbar. Statt hunderter Kisten und mehrköpfiger Teams auf der Baustelle reicht in der Field-Emulation ein Mausklick.
• Szenarien lassen sich zigfach wiederholen, Ergebnisse liegen rasch vor – Optimierung wird systematisch möglich.
• Komfort und Qualität steigen: definierte Umgebung, weniger Störfaktoren, bessere Dokumentation.

Technologisch basiert die Field Emulation auf C#/.NET und einer Visualisierungs-Software als Zukauf-Framework. Zusätzlich kommt für die Simulation die NVIDIA Physics Engine zum Einsatz. Das Setup zeigt: Hier wird durchdachte Produktentwicklung mit praxistauglicher Physiksimulation kombiniert – mit dem Ziel, Inbetriebnahme zu beschleunigen und mit Daten zu untermauern.

Tool 2: Basic Engineering Tool – globale Konsolidierung statt lokaler Varianten

Auch das Basic Engineering Tool ist „in jedem Projekt“ im Einsatz. Es unterstützt Controls Engineers in der planenden und elektrotechnischen Arbeit: automatisierte Berechnungen, „Reboards“ und konsolidierte Prozesse, die vormals in einzelnen Units unterschiedlich gehandhabt wurden.

Dieser Schritt ist aus Engineering- und Qualitäts-Perspektive entscheidend: Wenn Planungslogik, Berechnungen und Dokumentation übergreifend konsistent sind, sinken Reibungsverluste. Der Lerneffekt skaliert global, und die Ergebnisqualität wird vergleichbar.

Technisch steckt auch hier C#/.NET darunter, inklusive Visualisierung via Zukauf-Framework sowie moderner Windows-Oberflächenentwicklung mit WPF. Das Team arbeitet strukturiert, aber pragmatisch – es setzt auf bewährte Frameworks und ergänzt gezielt um Simulation und Visualisierung.

Tool 3: Entwicklung in den USA, Steuerung über Wales

Das dritte Tool wird „hauptsächlich in Amerika“ entwickelt, während die administrativen Agenden über „das Büro in Wales“ laufen. Eine zusätzliche technische Nuance: „Bei dem Tool in Amerika arbeiten wir zum Beispiel auch noch mit einer SQL-Datenbank.“

Für Bewerber:innen bedeutet das: internationale Zusammenarbeit in kleinen, fokussierten Teams – mit klarer Tool-Verantwortung und realer Chance, global Einfluss auf Entwicklungspraktiken und Tooling zu nehmen.

Stack und Prozesse: .NET, WPF, NVIDIA Physics, GitHub – und der Wechsel auf Jira

In Summe arbeitet das Team mit C#/.NET, einer Visualisierungs-Software als Framework, WPF für Windows-Oberflächen und der NVIDIA Physics Engine für die Field Emulation. Als Repository ist GitHub im Einsatz. Bei der Sprintplanung befindet sich das Team im Wechsel auf Jira; ein Ticket-System ist „auch dabei“. Auffällig ist die bewusste Modernisierung über die Jahre:

Diese Historie spricht für Anpassungsfähigkeit und ein Auge für sinnvolle Modernisierung. Wer gerne Tools und Prozesse gemeinsam verbessert, findet hier eine Bühne – ohne sich in Legacy-Debatten zu verlieren. Die Linie ist klar: pragmatisch umstellen, wo es Mehrwert bringt und wo die Organisation es vorgibt.

Hiring, das konsolidiert: zwei Rollen, klare Prozesse

In den vergangenen Wochen hat das Team gemeinsam mit der zentralen HR die Ausschreibungen vereinheitlicht. Früher gab es „unendliche Listen an verschiedensten Softwareentwicklern“ – jetzt lauten die Titel schlicht „Junior Software Developer“ und „Senior Software Developer“. Diese Rollen sind abteilungsübergreifend abgestimmt; Bewerbungen laufen zentral in der Haupt-HR-Abteilung ein.

Der Prozess im Überblick:

1. Bewerbung über die zentrale HR auf die Rollen „Junior“ oder „Senior Software Developer“.
2. Erste Runde via MS Teams. Vorteil laut Klausmair: weniger Nervosität, authentischerer Eindruck. Bewerber:innen stellen sich und Projekte vor – teils auch mit eigener Präsentation.
3. Nachgespräch und Matching: Welche Abteilung bzw. welches Tool spricht die Person am meisten an? Daraus ergibt sich die Richtung für Runde zwei.
4. Zweite Runde in Präsenz (2–3 Stunden): Team kennenlernen, Arbeitsweise und Tools sehen, vertiefende Einzelgespräche. Ziel: fachlich und menschlich prüfen, wie „die Person ins Team reinpasst“.

Der betonte Punkt: Es geht nicht nur um fachliche Passung. Klausmair: „Es muss auch persönlich in das ganze Gemenge reinpassen.“ Genau diese Balance – technische Exzellenz plus Teamgefüge – prägt die Kultur.

Warum dieses Team für Entwickler:innen spannend ist

Aus unserer Perspektive bei DevJobs.at ergeben sich aus der Session mehrere klare Gründe, warum Tech-Talente hier genau hinsehen sollten:

• Wirkung in jedem Projekt: Die Tools sind im Realisierungsprozess „in jedem Projekt“ im Einsatz – Impact ist garantiert.
• Virtuelle Inbetriebnahme mit echter Physiksimulation: Die Field Emulation verschiebt Testaufwand ins Büro, beschleunigt Zyklen und erhöht die Qualität – mit NVIDIA Physics als technischem Fundament.
• Globale Standardisierung: Das Basic Engineering Tool konsolidiert Planungs- und Berechnungslogik weltweit. Wer Struktur liebt, wird die Wirkung spüren.
• Technologischer Pragmatismus: C#/.NET, WPF, Visualisierungs-Framework, GitHub – dazu ein geordneter Wechsel auf Jira. Keine Tool-Religion, sondern praktikable Entscheidungen.
• Kleine, fokussierte Teams: Neun Personen insgesamt, Verantwortung je Tool, direkter Austausch – und damit viel Gestaltungsspielraum.
• Spezialisierung möglich: Back-end, Front-end oder beides – „alle Möglichkeiten“ sind offen, je nachdem, wo man Energie hineinlegt.
• Lernkurve über Projekte hinweg: Weil die Tools projektübergreifend genutzt werden, sammeln Teams schnell Feedback und optimieren kontinuierlich.
• Strukturiertes, menschliches Hiring: Erstes Gespräch remote, zweites on-site, klare Rollen (Junior/Senior), viel Einblick ins Team – und echte Aufmerksamkeit auf die persönliche Passung.

Engineering-Kultur: Geschwindigkeit, Wiederholbarkeit, Qualität

Wenn man den roten Faden dieser Session zusammenfasst, drehen sich die Entscheidungen des Teams um drei Dinge:

• Geschwindigkeit: Von der virtuellen Inbetriebnahme bis zum Tool-basierten Basic Engineering – alles zielt darauf ab, Projekte schneller und flüssiger zu machen.
• Wiederholbarkeit: Tests, die per Mausklick laufen, lassen sich zigfach wiederholen. Genau das schafft robuste Erkenntnisse.
• Qualität: Konsolidierte Prozesse und automatisierte Berechnungen reduzieren Streuung. Qualität wird damit planbarer.

Diese Kultur zeigt sich auch im Pragmatismus beim Tooling: SVN → Team-Contest-Server → GitHub; Sprintplanung → Jira. Modernisierung, wo sie Nutzen stiftet – ohne Selbstzweck.

Transparenz in der Zusammenarbeit mit HR und anderen Units

Bemerkenswert ist die Offenheit, mit der Klausmair die Zusammenarbeit mit HR und anderen Softwareabteilungen beschreibt. Von der Konsolidierung der Stellenprofile bis zur gemeinsamen Entscheidung nach dem Erstgespräch, in „welche Richtung der Bewerber gehen will“, zeigt sich eine Haltung: Prozesse dienen den Menschen – nicht umgekehrt. So wird der Fit zwischen Person, Tool und Team zur gemeinsamen Entscheidung.

Für Bewerbende ist das eine gute Nachricht: Man wird nicht in ein starr definiertes Kästchen einsortiert, sondern kann entlang der Tools und Stärken mitentscheiden.

International arbeiten, lokal anpacken

Das Team ist global – mit Entwickler:innen in Amerika und administrativer Steuerung über Wales – und gleichzeitig sehr konkret: Die Tools laufen in den Projekten, die Emulation läuft am Bildschirm, die Planungslogik läuft im Basic Engineering Tool. Diese Gleichzeitigkeit von internationalem Setup und lokalem „Hands-on“ prägt die Arbeitsweise.

Wer diese Mischung mag, findet hier genau das Richtige: Austausch über Zeitzonen hinweg, aber Aufgaben, die jeden Tag direkt spürbar werden.

Senior oder Junior? Hauptsache motiviert und passend

„Wir suchen neue Entwickler, egal ob Junior oder Senior.“ Dieser Satz fällt früh – und er ist ernst gemeint. Das Team ist offen für Breite in Erfahrung und Background, solange Motivation, Lernwille und Teamfit stimmen. Das deckt sich mit der Altersdiversität im Team und der Betonung, dass es „alle Möglichkeiten“ für Spezialisierung gibt.

Wir interpretieren das so: Wer als Junior strukturiert einsteigen will, bekommt mit klaren Tools, Prozessen und einem aufgeräumten Stack gute Rahmenbedingungen. Wer als Senior Verantwortung übernehmen möchte, kann im kleinen, fokussierten Setup viel bewegen – fachlich wie organisatorisch.

Ein genauerer Blick auf die Arbeitsrealität

Die Field Emulation illustriert gut, wie Alltag hier funktioniert. Statt auf der Baustelle Material und Personal zu koordinieren, werden Testszenarien digital aufgesetzt und wiederholbar gefahren – „Mausklick“. Ergebnisse kommen schneller, Optimierungen folgen zügig. Die Arbeitsumgebung ist kontrolliert: Büro, Bildschirm, Kaffee. Diese Ruhe und Reproduzierbarkeit schafft Fokus und verhindert, dass Probleme unter Baustellenbedingungen „verrauschen“.

Gleichzeitig bleibt die reale Welt präsent: Am Ende wird jedes System draußen gebraucht. Genau deshalb ist die enge Schleife aus Emulation, Auswertung und Optimierung so wertvoll. Die Tools sind kein Selbstzweck – sie sind Mittel, um reale Inbetriebnahmen besser vorzubereiten.

Technologiepfade mit Sinn – und ohne Dogma

Das Team betont keinen Hype, sondern Stimmigkeit: C#/.NET als Basis; WPF für Windows-Frontends; Visualisierung mit zugekauftem Framework; NVIDIA Physics, wo Simulation sinnvoll ist; GitHub als heutiger Standard im Repository; Jira als gelebte Sprintplattform. Dazu die Einsicht, dass Technologiesprünge manchmal vorgegeben sind – und dass man sie dann zügig mitgeht.

Diese Haltung ist für viele Entwickler:innen attraktiv: klare Grundlagen, pragmatische Erweiterungen und kontinuierliche Modernisierung – ohne die Unruhe, jeden Monat das Nächstbeste einzuführen.

Zusammenarbeit, die Authentizität erlaubt

Ein Aspekt, der uns besonders gefallen hat: die bewusste Entscheidung, erste Gespräche über MS Teams zu führen. „Die Bewerber sind meistens ein bisschen ruhiger und ein bisschen authentischer und sind nicht so nervös.“ Dieser Menschlichkeitsfaktor zeigt sich auch in Runde zwei: zwei bis drei Stunden, Team kennenlernen, Arbeitsweise sehen, echte Gespräche statt Checklisten.

Diese Form der Zusammenarbeit beginnt beim Recruiting – und setzt sich im Alltag fort: kleine Teams, direkte Kommunikationswege, hoher Praxisbezug.

Fazit: Ein Team für Entwickler:innen, die Wirkung und Klarheit suchen

Unser Eindruck aus „Klausmair Philipp, Head of Global Controls Tool Development bei TGW Logistics Group“: Hier entsteht in einem jungen, globalen und fokussierten Team eine Tool-Landschaft, die die Realisierung von Kundenprojekten messbar beschleunigt und stabilisiert. Virtuelle Inbetriebnahme, globale Konsolidierung im Basic Engineering, pragmatischer Stack und ein Hiring-Prozess, der Menschen ernst nimmt – all das fügt sich schlüssig zusammen.

Wer Technik mit klarem Nutzen, internationale Zusammenarbeit in kleinen Teams und transparente Prozesse sucht, sollte sich diese Chance ansehen. Oder, um es mit Klausmair zu sagen: „Wir sind offen für neue Teammitglieder.“

—

Wenn Sie sich angesprochen fühlen: Bewerbungen laufen auf die vereinheitlichten Rollen „Junior Software Developer“ und „Senior Software Developer“ über die Haupt-HR. Danach geht es – je nach Tool-Fit – in den beschriebenen Prozess mit MS-Teams-Erstgespräch und Onsite-Runde. Viel Erfolg!

• 

  

  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

• 

  

  Mario Leitner, Head of Software Development bei TGW Logistics Group

  Head of Software Development Intelligent Automation bei der TGW Logistics Group Mario Leitner spricht im Interview über den Aufbau der Devteams im Unternehmen, was Neuankömmlinge erwartet und welche Technologien verwendet werden.

  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