Vom neugierigen Tüftler zum Senior Agile Architect: Markus Schwabeneder (SEQIS Group GmbH) über Breite, Teamarbeit und lebenslanges Lernen

Eine Entwicklerlaufbahn, die mit Neugier beginnt

Bei DevJobs.at hören wir viele Werdegänge – doch manche bleiben besonders hängen, weil sie ein zeitloses Muster sichtbar machen: Neugier, Pragmatismus und der Wille, Dinge wirklich zum Laufen zu bringen. Genau so beschreibt Markus Schwabeneder, Senior Agile Architect bei SEQIS Group GmbH, seinen Weg. Er beginnt mit einem simplen, aber kraftvollen Satz:

Aufgewachsen in einer Zeit, in der ein eigener Computer noch alles andere als selbstverständlich war, kam der erste PC mit elf Jahren ins Haus – gebraucht, nicht ganz aktuell und: voller Hürden. Die „normalen Spiele“ wollten einfach nicht starten. Anstatt die Lust zu verlieren, tat Markus etwas, das seinen weiteren Weg prägen sollte: Er schrieb Patch-Files und Skripte, feilte so lange, bis es funktionierte. Dieses frühe Hands-on-Mindset, verbunden mit Experimentierfreude in Basic und Logo (inklusive der legendären Turtle-Grafiken), legte den Grundstein für alles, was folgte.

Von Pascal und Delphi zur Technischen Mathematik

Im Gymnasium lernte Markus Pascal und Delphi. Die Sprachen blieben für ihn eher blass – sie begeisterten ihn nicht in dem Maß, dass daraus ein Informatikstudium geworden wäre. Stattdessen entschied er sich für Technische Mathematik an der Johannes Kepler Universität Linz. Eine Weichenstellung, die im Rückblick bemerkenswert stimmig wirkt: Mathematik als Fundament, Programmieren als Werkzeugkasten.

An der Universität vertiefte er sich in C++ und bekam Kontakt mit Java – und genau da sprang der Funke über. Java machte ihm „extrem Spaß“. Über die Mitarbeit an Optimierungsproblemen – „ich habe Unterstützung gebraucht für Optimierungsprobleme“ – ergaben sich Gelegenheiten, praktisch mitzutun. Schließlich kam ein Jobangebot, und Markus landete in der Softwareentwicklung.

Es ist eine Laufbahn, die nicht geradlinig im Sinne eines Curriculum-Plans wirkt, aber gerade deshalb zu einem schlüssigen Profil führt: Ein generalistischer, problemlösungsorientierter Zugang mit mathematischem Rüstzeug und echter Freude am Programmieren.

„Agile“ als gelebtes Prinzip, nicht als Etikett

Heute trägt Markus den Titel Senior Agile Architect. Das „Agile“ darin ist kein Buzzword, sondern Ausdruck einer Haltung. Er formuliert es unmissverständlich:

Und weiter betont er den praxisnahen Teil: Es geht ihm nicht darum, Prozesse per Dekret aufzustellen, sondern sie durch konsequentes Arbeiten im Team erlebbar zu machen:

Diese Haltung ist Augenhöhe statt Dogma: Regeln werden nicht von oben verordnet, sondern über erlebbare Ergebnisse legitimiert. Agilität zeigt ihren Wert, wenn Teams spüren, dass iterative Zusammenarbeit, kurze Feedback-Loops und Klarheit über Ziele tatsächlich bessere Ergebnisse liefern.

Architektur ist End-to-End-Verantwortung – im Team

Das zweite Wort in Markus’ Titel ist „Architect“. Was heißt das in seinem Alltag? Zunächst: Architektur ist für ihn breit gedacht. Sie umfasst nicht nur die Gestaltung der Software, sondern reicht bis zur Serverlandschaft, zum Deployment und zum Testsetup. Markus beschreibt das ohne Pathos, dafür mit einem nüchternen Realismus:

Der Schlüsselbegriff, den er dafür nennt, ist T-shaped: breite Kenntnisse in vielen Bereichen, mit einer Vertiefung in einigen – und vor allem genug Überblick, um mitreden, mitdenken und mitgestalten zu können. Dieses Verständnis zahlt auf zwei Dinge ein:

• Entscheidungsqualität: Wer die Implikationen über den ganzen Lebenszyklus kennt, trifft nachhaltigere Architekturentscheidungen.
• Zusammenarbeit: Wer weiß, wie Deployment und Testsetup ticken, spricht anders mit Ops- und QA-Kolleg:innen – lösungsorientiert und respektvoll.

Markus bringt es auf den Punkt: In der agilen Welt ist T-Shaped keine Kür, sondern ein Arbeitsmodus. Architektur ist Teamsport.

Generalist mit Fokus: Wie Breite und Tiefe zusammenspielen

Was heißt das konkret für den Arbeitsalltag? Markus macht klar: Er will „Ahnung haben von allen diesen Bereichen“. Genau das unterscheidet ihn von reinen Spezialist:innenrollen – ohne die Spezialisierung geringzuschätzen. Es geht um das Sowohl-als-auch:

• Ein Architekt muss sich an den Schnittstellen auskennen: von der Codebasis über Build- und Release-Prozesse bis zur Produktionsumgebung.
• Er oder sie muss mit unterschiedlichen Perspektiven umgehen können: Entwickler:innen, Tester:innen, Betriebsverantwortliche, Product Owner – alle tragen Informationen bei, die den Architekturkontext prägen.

Nicht alles selbst machen zu müssen heißt nicht, die Verantwortung zu delegieren. Es bedeutet, Verantwortung gemeinsam mit dem Team zu tragen – und so Entscheidungen zu treffen, die sich in der Praxis bewähren.

Soft Skills als Kernkompetenz der Architektur

Ein bemerkenswerter Akzent in Markus’ Erzählung: Sein Mathematikstudium brachte nicht nur Programmiergrundlagen, sondern vor allem Soft Skills, die ihn in seinem Job voranbringen. Für eine Rolle in der Softwarearchitektur ist das mehr als eine Fußnote. Er sagt es klar:

Und er räumt mit einem Klischee auf:

Kommunikation ist kein Nebenschauplatz, sondern das Medium, in dem Architektur erst möglich wird: Anforderungen verstehen, Konsens aufbauen, Risiken transparent machen, Entscheidungen erläutern, Feedback integrieren – all das ist Kommunikation. Wer in Architektur reingehen möchte, tut gut daran, diese Fähigkeiten bewusst zu trainieren.

Lernen als Freude – nicht als Bürde

Der vielleicht persönlichste und gleichzeitig universellste Punkt in Markus’ Geschichte betrifft das Lernen. In seiner Formulierung schwingt eine klare Erwartungshaltung mit – an sich selbst und an jene, die in die Rolle hineinwollen:

Diese Freude am Lernen ist für ihn nicht abstrakt, sondern gelebte Praxis: nach dem Studium „eine Menge Ausbildungen“, viel Lernen im Job. Und er beschreibt sein Arbeitsumfeld als einen Ort, an dem Weiterentwicklung aktiv gefördert wird – „die Firma ist einem stetig bestrebt, am Puls der Zeit zu sein und auf die neuen Technologien zu setzen.“

Das ist kein Nebenbei-Programm, sondern Teil der beruflichen Identität: Technologien kommen und gehen, Methoden entwickeln sich, Tools verändern das Zusammenspiel zwischen Entwicklung, Test und Betrieb. Wer das als lebendige Herausforderung sieht, wird in einer Architekturrolle glücklich.

Vom ersten Patch-File zur beruflichen Haltung

Auffällig an Markus’ Weg ist die Kontinuität der Motive. Was als Kind mit Patch-Files und Skripten begann – Probleme praktisch lösen – findet später seine Entsprechung in der Art, wie er Agilität versteht: nicht predigen, sondern machen. Und ebenso in der Architektur: nicht im stillen Kämmerchen entwerfen, sondern im Team Lösungen erarbeiten, die tatsächlich laufen – von der Software über das Deployment bis zum Testsetup.

Die frühen Berührungen mit Basic und Logo waren kein Selbstzweck. Sie haben ein Gefühl dafür geschärft, wie aus kleinen Bausteinen etwas Sichtbares entsteht. Und sie haben die Hemmschwelle gesenkt, sich in neue Technologien einzuarbeiten. Wer als Elfjähriger eigene Skripte schreibt, lernt: Ich darf anfassen. Ich darf Dinge kaputtmachen und wieder reparieren. Genau dieser Mut ist später Gold wert – in Code Reviews, in Architekturentscheidungen, in der Moderation von Risiken.

Konkrete Hinweise für Entwickler:innen, die in die Architektur wollen

Aus Markus’ Erzählung lassen sich eine Reihe handfester Empfehlungen destillieren – ohne Checklisten-Charakter, aber mit klarem Praxisbezug:

• Werde T‑shaped: Baue dir breite Grundkenntnisse auf – Code, Infrastruktur, Deployment, Test. Du musst nicht überall Expert:in sein, aber die Sprache und die Zwänge der angrenzenden Disziplinen verstehen.
• Lerne, durch Tun zu überzeugen: „…man arbeitet damit und dann sehen halt die Leute, dass es so zu arbeiten wirklich Erfolg bringt.“ Setze auf kleine, erlebbare Verbesserungen statt auf Appelle.
• Pflege deine Soft Skills: Architektur lebt von Kommunikation. Übe aktives Zuhören, klares Argumentieren und den Umgang mit Dissens. Das ist kein „Nice to have“, sondern Jobkern.
• Nimm Lernfreude ernst: Wenn kontinuierliches Lernen sich wie Last anfühlt, ist die Rolle schwer tragbar. Wenn es sich wie Energiequelle anfühlt, bist du auf dem richtigen Weg.
• Erhalte dir die Neugier: Die Energie, die dich mit elf zu Patch-Files und Skripten gebracht hat, trägt dich auch später durch neue Tools, Paradigmen und Teams.
• Breite Bildung zählt: Ein Studium der Informatik ist nicht zwingend. Wichtig ist, dass du Grundlagen mitnimmst – analytisches Denken, Struktur, Problemlösungsfähigkeit – und sie im Teamkontext anwenden kannst.

Warum „Architekt“ nicht „Alleinzeichner“ bedeutet

Markus’ Aussage „so läuft das nicht“ in Bezug auf das Arbeiten im stillen Kämmerchen ist ein deutlicher Fingerzeig: Architektur ist keine Soloperformance. Sie ist ein Vermittlungsberuf zwischen Perspektiven, ein gemeinsamer Aushandlungsprozess, der sich an der Realität messen lassen muss. Das schließt auch ein, Verantwortung so zu verteilen, dass sie tragfähig wird: nicht alles selbst entscheiden, aber die Qualität der Entscheidung ermöglichen – mit Kontext, mit Abwägung, mit Transparenz.

Genau deshalb ist die Zusammenarbeit mit Test und Betrieb in seiner Beschreibung kein Appendix, sondern Bestandteil der Architektur. Wenn Continuous Integration ins Leere läuft, wenn Deployments wackeln, wenn Tests nicht aussagekräftig sind – dann ist das kein „Problem der anderen“, sondern ein Hinweis darauf, dass architektonische Leitplanken fehlen oder nicht geerdet sind.

Breite Ausbildung, breites Wirken: eine Einladung an Quereinsteiger:innen

Interessant ist der Impuls, den Markus an Ausbildungswege knüpft. Er sagt, sein Mathematikstudium habe ihm Soft Skills mitgegeben, die in seinem Job entscheidend seien – und zugleich betont er, dass es dafür nicht zwingend eben dieses Studium sein muss. Was zählt, ist eine Ausbildung, die über das rein Zielgerichtete hinausgeht: „…ein bisschen Allgemeinwissen und das breit aufgestellt und weiterentwickelt.“

Dieser Fokus auf Breite ist ermutigend – insbesondere für Menschen, die aus anderen Disziplinen in die Softwareentwicklung kommen oder zwischen Rollen wechseln möchten. Entscheidend ist nicht, was auf dem Papier steht, sondern ob man das Zusammenspiel der Disziplinen versteht und in Teams tragfähige Lösungen erarbeitet.

Agilität als Erfahrungswert – warum Vorleben stärker ist als Vorschreiben

Ein weiterer roter Faden in Markus’ Schilderung ist die Idee, dass Agilität erlebt werden muss. Das klingt simpel, ist aber in der Praxis oft der Knackpunkt. Prozesse, Boards, Rituale – sie bleiben hohl, wenn sie nicht mit echter Zusammenarbeit und echter Problemlösung gefüllt werden. Markus’ Ansatz „man arbeitet damit…“ ist in dieser Hinsicht nahezu programmatisch: Wenn das Team sieht, dass ein iteratives Vorgehen Blockaden löst, dass eine klare Definition of Done Qualität erzeugt, dass frühes Testen Risiken minimiert, dann verankern sich Praktiken von selbst.

Für Architekt:innen heißt das: die Brücke zu schlagen zwischen Prinzipien und Alltag, zwischen Leitplanken und konkretem Code, zwischen Vision und dem nächsten Commit. Nicht, indem man das letzte Wort hat, sondern indem man das Gespräch ermöglicht und den Weg weist.

Ein Beruf, der nie fad wird

Markus beschreibt seinen Job als einen, der „nie fad wird“. Das ist keine Floskel, sondern die logische Folge seiner Haltung: Wer Neues als Einladung versteht, findet in der Softwareentwicklung und -architektur einen unerschöpflichen Lernraum. Neue Technologien, neue Domänen, neue Teamkonstellationen – sie fordern heraus, aber sie belohnen auch. Gerade weil er die Lust am Lernen betont, wirkt seine Berufsfreude authentisch.

Und: Dieser Blick relativiert die Jagd nach dem Nächsten großen Ding. Es geht weniger darum, jeden Trend mitzumachen, als vielmehr darum, sich in der Breite wertschöpfend zu bewegen – und in der Tiefe dort anzusetzen, wo es für das Team und das Produkt zählt.

Was wir von Markus Schwabeneder (SEQIS Group GmbH) mitnehmen

• Karrierewege dürfen ungerade sein. Wichtig ist, dass sie von einer Haltung getragen sind: Neugier, Hands-on, Teamorientierung.
• Agilität ist eine Praxis. Sie überzeugt, wenn sie Erfolge sichtbar macht – nicht, wenn sie Regeln diktiert.
• Architektur ist ganzheitlich. Sie endet nicht am Code, sondern umfasst Serverlandschaft, Deployment und Testsetup – und lebt von Zusammenarbeit.
• Soft Skills entscheiden. Kommunikation, Austausch und gemeinsame Lösungsfindung sind Kernaufgaben, keine Nebengeräusche.
• Lernfreude ist der Motor. Wer sie hat, bleibt am Puls der Zeit – ob über formale Ausbildungen, Lernen im Job oder Eigeninitiative.

Schlussgedanke: Die Kunst, Breite und Tiefe auszubalancieren

Die Geschichte von Markus Schwabeneder zeigt eine archetypische, aber selten so klar formulierte Wahrheit: Gute Architektur entsteht dort, wo Menschen mit breiter Perspektive, echter Kommunikationsstärke und gelebter Lernfreude zusammenarbeiten. Der Weg dorthin kann mit Patch-Files beginnen, über Basic und Logo führen, durch Pascal und Delphi geduldig getragen werden, in der Technischen Mathematik Struktur gewinnen, in C++ und Java Fahrt aufnehmen – und in einer Architekturrolle landen, in der all das zusammenkommt.

Für uns ist dieses Gespräch ein Reminder, worauf es ankommt: auf die Freude, Dinge wirklich zum Laufen zu bringen. Auf das Miteinander im Team. Und auf die Bereitschaft, immer wieder dazuzulernen – nicht, weil man muss, sondern weil man will.

Wer diesen Kompass teilt, wird in einer Rolle wie der von Markus – Senior Agile Architect bei SEQIS Group GmbH – nicht nur bestehen, sondern gestalten.

• 

  

  JavaScript and (Non) Blocking UI

  Klemens Loschy von SEQIS fokusiert sich in seinem devjobs.at TechTalk "JavaScript and (Non) Blocking UI" auf eine Problemstellung aus dem Gebiet der eventloops in JavaScript und demonstriert einen Lösungsweg.

  Jetzt ansehen
• 

  

  Improving Merge Reviews

  Timo Keber von SEQIS zeigt in seinem devjobs.at TechTalk die maßgeschneiderten Lösungen, die das Team für die Merge Reviews mit GitLab in VS Code verwendet.

  Jetzt ansehen
• 

  

  Atlassian Forge Custom UI Testing und Asynchronität

  Daniel Kleißl von SEQIS spricht in seinem devjobs.at TechTalk über eine Eigenheit von Forge beim UI Testing und zeigt in einer Live Demo, wie das Team dieses Problem gelöst hat.

  Jetzt ansehen

• 

  

  Alexander Weichselberger, Managing Partner von SEQIS

  Der Managing Partner von SEQIS Alexander Weichselberger spricht im Interview über die Kerngedanken des Unternehmens, aktuelle Projekte, den Bewerbungsprozess und warum der Blick über den Tellerrand auch wichtig ist.

  Jetzt ansehen