Vom HTL‑Mechatroniker zum Cloud‑Backend: Was wir von Matthias Thym (smaXtec) über System Engineering, Kubernetes und präzise Problemlösung lernen

Ein klarer Weg ohne geraden Strich: Die Session „Matthias Thym, Back End & System Engineer bei smaXtec“ im Rückblick

In der Session „Matthias Thym, Back End & System Engineer bei smaXtec“ erzählt Matthias Thym von einem Karriereweg, der nicht mit Informatik begann – und gerade deshalb für viele Entwicklerinnen und Entwickler relevant ist. Sein Start in der HTL mit Schwerpunkt Mechatronik war eine „bunte Mischung“: Programmieren war dort nicht der Hauptfokus, und doch öffnete genau diese Mischung die Tür. Erste Zeilen Code schrieb er auf Mikrocontrollern in C. Später merkte er, dass ihm andere Sprachen besser liegen – und fand seinen Weg zu Python und weiter in die Backend- und Systemwelt. Heute arbeitet er im System & Infrastructure Team bei der smaXtec animal care GmbH, wo die Infrastruktur in der Cloud läuft und „viel mit Kubernetes“ gearbeitet wird.

Was diesen Einblick so wertvoll macht, ist weniger eine Aufzählung von Technologien als der Blick auf Haltung und Handwerk: Probleme identifizieren, ohne die Ursache zu kennen, und sie „möglichst schnell, möglichst präzise, möglichst effizient“ zu lösen. Genau diese pragmatische Professionalität prägt seinen Beitrag – und liefert handfeste Orientierung für alle, die in Backend, Infrastruktur oder systemnaher Entwicklung Fuß fassen wollen.

HTL Mechatronik als Sprungbrett: Wie Breite zum Startvorteil wird

Matthias begann an einer HTL, fünf Jahre, Ausbildungsschwerpunkt Mechatronik. Kein Informatikzweig, kein reines Software-Curriculum. Und doch: „Ich bin aber sehr wohl dort schon zum Programmieren gekommen.“ Dieser Satz ist zentral. Er zeigt, wie wertvoll hybride Ausgangspunkte sein können. Gerade Mechatronik – an der Schnittstelle von Mechanik, Elektronik und Software – vermittelt ein systemisches Verständnis. Wer dort Programmieren lernt, lernt es meist im Kontext konkreter Hardwareanforderungen und mit einem Fokus auf Robustheit.

Seine ersten Schritte führten in die Embedded-Welt: Mikrocontroller, C, nah an der Hardware. Eine Schule des knappen Speichers, der deterministischen Abläufe, der Klarheit in Nebenläufigkeit und Timing.

• Von Anfang an zählt die Wirkung: Code steuert echte Geräte.
• Fehler äußern sich physisch: LEDs, Motoren, Sensorwerte – unmittelbares Feedback.
• Der Anspruch an Präzision ist hoch: „geht irgendwie“ reicht selten.

Diese frühe Prägung erklärt mit, warum Matthias später so konsequent die Genauigkeit betont. Wer gelernt hat, dass Unschärfe auf Hardwareebene schnell zu echten Problemen führt, bleibt auch im Backend allergisch gegen unklare Zustände.

Von C zu Python: Technologien nach Passung wählen

Später im Studium und bei privaten Projekten verschob sich sein Fokus: „…bin dann mit der Zeit im Laufe des Studiums und bei privaten Projekten eher auf Python und andere Programmiersprachen gekommen.“ Der Grund dafür klingt unscheinbar, ist aber richtungsweisend: C lag ihm „nicht so“ wie andere Sprachen. Anstatt dogmatisch bei der „ersten“ Sprache zu bleiben, hat er sich auf Werkzeuge ausgerichtet, die zu seiner Denkweise und seinen Aufgaben passen.

Das ist eine der wichtigsten Lernchancen seiner Geschichte:

• Technologieauswahl ist persönlich und aufgabengetrieben. Wenn eine Sprache nicht „liegt“, darf – und sollte – man wechseln.
• Private Projekte sind ein wirksamer Hebel. Sie erlauben Experimente fern von Curricula und liefern echte Vergleichswerte.
• Entwicklung ist ein Kontinuum: vom Embedded‑Kontext zu höheren Abstraktionen, vom hardwarenahen C zu produktiven, vielseitigen Sprachen wie Python.

Die Botschaft dahinter: Kompetenz entsteht nicht aus sturem Festhalten an einem Tool, sondern aus der Fähigkeit, das passende Werkzeug zu finden – und den Mut, es zu wechseln.

Ankommen im System & Infrastructure Team: Cloud, Kubernetes und das unsichtbare Rückgrat

„Ich bin jetzt selber seit einem halben Jahr bei smaXtec…“ Aus dieser frischen Perspektive beschreibt Matthias die Teamstruktur im Backend: ein Integration Team und ein System & Infrastructure Team. Er arbeitet Letzterem zu – mit einem klaren Auftrag:

• „…dass gewisse Infrastruktur steht, aktualisiert wird…“
• „…neue Server aufgesetzt werden, wenn notwendig.“
• „Mittlerweile ist das alles in der Cloud, da wird viel mit Kubernetes gearbeitet…“
• „…allgemeine Dinge, die eben systemrelevant sind, die wir am Laufen halten und betreuen…“
• „…und neue Dinge, die wir firmenintern so brauchen, die aufgesetzt werden müssen.“

Das zeichnet das Bild einer Rolle, die man im Alltag selten sieht – und doch ist sie für alle anderen Teams erfolgskritisch. Infrastruktur ist dann gut, wenn sie unsichtbar ist, weil sie einfach funktioniert. Updates, Server-Provisionierung, Cluster-Betrieb, interne Services: Das sind die Bausteine, auf denen Produkte, Integrationen und Datenflüsse stehen.

Auffällig ist, wie nüchtern Matthias diese Arbeit beschreibt. Kein Technikfeuerwerk, keine Buzzwords um ihrer selbst willen. Stattdessen das Handwerk der Verlässlichkeit: aufsetzen, aktualisieren, betreiben. Cloud und Kubernetes werden nicht als Selbstzweck dargestellt, sondern als Mittel zum Zweck – so wie es in professionellen Umgebungen sein sollte.

Die Schwesterdisziplin: Integration Team als Brücke nach außen

Während sein Team das Fundament liefert, sorgt das Integration Team für die Verbindungen: „…Integrationen zu anderen Unternehmen, mit denen wir kooperieren oder mit denen wir gewissen Austausch pflegen, wenn man es Daten anbetrifft.“ Diese Aufgabenteilung ist typisch für gereifte Backend‑Organisationen:

• System & Infrastructure: Betrieb, Plattform, interne Services, Zuverlässigkeit.
• Integration: Schnittstellen, Partner, Datenflüsse, Kompatibilität.

Beide Seiten bedingen einander. Stabile Integrationen brauchen eine stabile Plattform. Und Plattformarbeit entfaltet ihren Wert, wenn darauf Integrationen und Produktfunktionen sicher laufen. Dieses Zusammenspiel wird in Matthias’ Beschreibung greifbar.

Der Kern der Arbeit: Probleme erkennen, Ursachen finden, präzise lösen

Auf die Frage nach Anforderungen an Ausbildung und Mindset wird Matthias deutlich: „Ich glaube, man muss eine gewisse Leidenschaft dafür mitbringen, Probleme zu lösen, Probleme davor zu identifizieren.“ Häufig sei der Ausgangspunkt nur ein unspezifischer Hinweis: „Ganz oft geht es in meiner Arbeit darum, dass man auf welchem Weg auch immer mitbekommt, dass ein Problem besteht. Man weiß unter Umständen gar nicht, was die Ursache ist…“ Genau dann zählt professionelle Haltung: „…und man muss sich einfach darum kümmern, dass es möglichst schnell, möglichst präzise, möglichst effizient gelöst wird.“

Diese drei Adverbien sind das Destillat aus viel Praxis:

• Möglichst schnell: Reaktionsfähigkeit ohne Aktionismus. Geschwindigkeit, die den Impact minimiert.
• Möglichst präzise: Nicht nur Symptome verrücken, sondern treffgenau wirken – mit Blick auf Ursache und Wirkung.
• Möglichst effizient: Ressourcen sparsam einsetzen – Zeit, Aufmerksamkeit, Infrastruktur.

Wer so arbeitet, baut Vertrauen auf. Für Kundinnen, für Kolleginnen, für Partner. Die Qualität steht nicht in der Anzahl der eingesetzten Tools, sondern in der Konsequenz, Probleme sauber zu lösen.

Praktische Leitlinien für diese Art von Arbeit

Aus Matthias’ Beschreibung lassen sich robuste Gewohnheiten ableiten:

• Frühzeitige Problemwahrnehmung: Hinweise ernst nehmen, auch wenn die Ursache unklar ist.
• Hypothesenbasiertes Vorgehen: Systematisch einkreisen statt blind ausprobieren.
• Schrittweises Eingreifen: Kleine, überprüfbare Änderungen statt großer Sprünge.
• Dokumentation des Weges: Was wurde beobachtet? Was geändert? Was war die Wirkung?
• Abschluss mit Stabilisierung: Fix verifizieren, Nebenwirkungen prüfen, Lessons Learned festhalten.

Diese Haltung ist technologieagnostisch. Sie gilt in Embedded‑Kontexten genauso wie im Kubernetes‑Cluster.

Ausbildung, die Türen öffnet – und warum sie kein Muss ist

„Ein Studium ist nicht unbedingt erforderlich, aber mit Sicherheit hilfreich.“ Dieser Satz ist wohltuend unideologisch. Genauso differenziert fällt sein Blick auf die Wege aus: „Was die erforderliche Ausbildung anbetrifft, glaube ich, kann von HTL über FH, Uni, aber auch Quereinsteiger das im Prinzip jeder lernen, aber man muss eine gewisse eigene Initiative mitbringen.“

Die Pointe steckt im letzten Halbsatz: Eigeninitiative. In seinen Stationen taucht sie mehrfach auf – zuerst beim Einstieg ins Programmieren in der HTL, dann in Privatprojekten beim Wechsel der Sprachen, schließlich im heutigen Alltag, wenn Probleme ohne klare Ursache gelöst werden müssen. Initiative ist der rote Faden, der Ausbildungstitel überflüssig macht, sofern man die Praxis sucht.

Konkrete Implikationen für Karriereentscheidungen

• HTL, FH, Uni: Alles kann funktionieren. Entscheidend ist, dass du Räume hast, um Probleme selbstständig zu lösen.
• Quereinstieg: Möglich, wenn die Bereitschaft da ist, Lücken aktiv zu schließen – durch Projekte, Lernphasen und Praxis.
• Studium als Hebel: Hilfreich, weil es Struktur, Umfeld und Tiefe bieten kann – nicht weil es ein Gütesiegel wäre.

Von der Embedded‑Schule zum Cloud‑Betrieb: Breite als Stärke nutzen

Die Stationen, die Matthias nennt – Mikrocontroller mit C, später Python, heute Cloud und Kubernetes – bilden eine Linie vom Nahen zum Abstrakten. In Summe steht da ein Ingenieursprofil, das verschiedene Ebenen kennt: vom Bit zur Plattform. Genau diese Vielfalt ist in modernen Backend‑Landschaften ein Vorteil.

• Wer aus Embedded kommt, scheut Nebenläufigkeit und Ressourcenfragen nicht.
• Wer in Python produktiv ist, kann schnell Prototypen, Tools und Services liefern.
• Wer im Cloud‑Umfeld arbeitet, denkt in Plattformen, Deployments und Betrieb.

Breite ist hier kein Selbstzweck. Sie erlaubt, Probleme ganzheitlich zu denken und in die jeweils richtige Ebene zu überführen – ob Konfiguration, Code oder Infrastruktur.

Geschwindigkeit, Präzision, Effizienz: Ein Arbeitsprinzip in drei Worten

Die Formel, die Matthias explizit ausspricht, lässt sich als Arbeitsprinzip lesen:

• Geschwindigkeit: rechtzeitig erkennen, priorisieren und handeln.
• Präzision: Ursachen isolieren, Fehlerbilder schärfen, Wirkungen messen.
• Effizienz: mit angemessenem Aufwand die maximale Wirkung erzielen.

Praktisch heißt das: nicht alles automatisieren, was automatisierbar ist, sondern das Richtige automatisieren; nicht jedes Tool einsetzen, sondern das Passende; nicht jeden Prozess standardisieren, sondern dort, wo Wiederholbarkeit Wert schafft. So entsteht Professionalität ohne Überladung.

Die Teamdimension: Geteilte Verantwortung für Stabilität und Austausch

In der von Matthias beschriebenen Aufgabenteilung wird deutlich, wie wichtig klare Teamgrenzen sind – und wie stark sie aufeinander angewiesen sind. System & Infrastructure schafft Verlässlichkeit nach innen; Integration schafft Verbindungen nach außen. Beide sind nötig, um Unternehmens‑ und Produktziele zu tragen. Gerade in Umgebungen, in denen „mittlerweile alles in der Cloud“ läuft und „viel mit Kubernetes“ gearbeitet wird, sind gemeinsame Schnittstellen, Absprachen und Erwartungen entscheidend: Welche Services stellt die Plattform bereit? Welche Betriebsqualitäten erwarten die Integrationen? Wie werden Änderungen abgestimmt? Selbst wenn Matthias diese Fragen nicht explizit ausführt, legt seine Beschreibung nahe, dass genau an dieser Nahtstelle gutes Engineering sichtbar wird.

Ratschläge, die direkt aus der Praxis kommen

Aus Matthias’ Weg lassen sich für Entwicklerinnen und Entwickler handfeste Handlungsfelder ableiten – ohne Spekulation, direkt aus seinen Formulierungen heraus:

1. Folge der Passung, nicht der Gewohnheit: Wenn eine Sprache dir nicht liegt, wechsle. C war der Start, Python später die Wahl – aus gutem Grund.
2. Nutze Privatprojekte strategisch: Sie geben dir Freiraum, Neues zu erproben und Stärken zu entdecken.
3. Übe Problemerkennung: Achte auf Signale – Alarme, Rückmeldungen, Symptome. Oft kennst du die Ursache noch nicht.
4. Trainiere die Dreifaltigkeit aus Tempo, Präzision, Effizienz: Handle schnell, wirke exakt, verschwende keine Ressourcen.
5. Baue Breite auf: Hardware‑Nähe, Programmiersprachen, Plattformbetrieb – jede Ebene schärft dein Urteilsvermögen.
6. Wähle deinen Bildungsweg bewusst: HTL, FH, Uni, Quereinstieg – möglich ist vieles. Entscheidend ist Eigeninitiative.

Lernpfade, die zu dieser Rolle passen

Matthias’ Geschichte skizziert eine Rolle, die viele reizt: systemnah, plattformorientiert, wirkungsstark. Wer sich dorthin entwickeln will, bekommt mit seinen Stichworten einen klaren Lernpfad:

• Grundlagensicherheit: Verständnis für Betrieb, Netzwerke, Prozesse.
• Software‑Handwerk: saubere Implementierung, Skripting, Tools bauen – Sprachenwahl nach Passung.
• Plattformdenken: Services aufsetzen, aktualisieren, betreuen – Cloud‑Kompetenz schrittweise ausbauen.
• Verantwortungsübernahme: Probleme tilgen, nicht verschieben; Ursachen suchen, nicht Symptome übertönen.

All das ist kompatibel mit unterschiedlichen Ausbildungshintergründen – solange die Bereitschaft da ist, echte Probleme anzupacken.

Ein Wort zur Haltung: Nüchtern, verbindlich, lernbereit

Was uns in der Session besonders auffiel, ist die Nüchternheit in der Darstellung. Keine Überhöhung, kein Tech‑Name‑Dropping jenseits des Notwendigen. Stattdessen ein ruhiger Fokus darauf, was getan werden muss, damit Systeme laufen: aufsetzen, aktualisieren, betreuen; nach außen integrieren; Probleme erkennen und lösen. Diese Ruhe ist ein Qualitätsmerkmal. Sie zeigt, dass Professionalität in der Infrastruktur nicht aus Spektakel entsteht, sondern aus verlässlicher Routine, klarer Priorisierung und der Bereitschaft, Verantwortung zu tragen.

Fazit: Ein pragmatischer Kompass für Backend und Infrastruktur

Die Session „Matthias Thym, Back End & System Engineer bei smaXtec“ liefert keine Checkliste der neuesten Tools – sie liefert etwas Wertvolleres: einen Kompass. Wer mit einem gemischten techniknahen Hintergrund startet, wer Sprachen nach Passung auswählt, wer Cloud‑ und Kubernetes‑Kompetenz als Mittel zum Zweck begreift und wer Probleme „möglichst schnell, möglichst präzise, möglichst effizient“ löst, baut eine tragfähige Laufbahn im Backend‑ und Systemumfeld.

Ob HTL, FH, Uni oder Quereinstieg: Der Weg steht offen – solange Eigeninitiative, Lernbereitschaft und die Lust an echter Problemlösung mitgehen. Genau das zeigt die Laufbahn von Matthias Thym bei der smaXtec animal care GmbH. Sie erinnert uns daran, dass in der Infrastruktur die unsichtbare Arbeit oft die wichtigste ist – und dass verlässliche Systeme nicht von selbst entstehen, sondern von Menschen, die Verantwortung übernehmen und präzise handeln.

• 

  

  Manuel Frech, Teamlead Hard- & Firmware bei smaXtec

  Teamlead Hard- & Firmware bei smaXtec Manuel Frech spricht im Interview über den Aufbau der Entwicklungsabteilung, welche Technologien dort im Einsatz sind und wie das Recruiting und Onboarding abläuft.

  Jetzt ansehen

• 

  

  Johannes Pesenhofer, Data Scientist bei smaXtec

  Johannes Pesenhofer von smaXtec spricht im Interview darüber, wie er zu seiner aktuellen Arbeit als Data Scientist gekommen ist und was seiner Ansicht nach wichtig für Beginner ist.

  Jetzt ansehen
• 

  

  Oliver Troger, Front End Developer bei smaXtec

  Oliver Troger von smaXtec erzählt im Interview über seinen Werdegang, inklusive Umwegen bis zum Front End Development und gibt Tipps für Neueinsteiger.

  Jetzt ansehen