From Curious Tinkerer to Senior Agile Architect: Markus Schwabeneder (SEQIS Group GmbH) on Breadth, Teamwork, and Lifelong Learning

A developer journey powered by curiosity

At DevJobs.at, we hear many career stories. Some stand out because they spotlight a timeless pattern: curiosity, pragmatism, and the determination to make things work. That’s how Markus Schwabeneder, Senior Agile Architect at SEQIS Group GmbH, describes his path. He opens with a simple but telling line:

He grew up at a time when a home computer wasn’t an everyday device. At age eleven, he finally got his first PC—used, not exactly up to date, and full of hurdles. The “normal games” wouldn’t run. Instead of giving up, Markus did something that would define his trajectory: he wrote patch files and scripts until things worked. That hands-on mindset, paired with early experiments in Basic and Logo (complete with turtle graphics), became the foundation of everything that followed.

From Pascal and Delphi to Technical Mathematics

In high school, Markus learned Pascal and Delphi. They didn’t ignite his passion—at least not enough to push him toward a computer science degree. Instead, he chose Technical Mathematics at Johannes Kepler University Linz. In hindsight, that choice feels remarkably coherent: mathematics for fundamentals, programming as the toolbox.

At university, he deepened his C++ skills and got in touch with Java—and that’s where the spark turned into genuine joy. Java “was extremely fun.” Through involvement in optimization problems—“I needed support for optimization problems”—he got a chance to contribute. A job offer followed, and Markus found himself in software development.

It’s a path that isn’t linear in a curriculum sense, but it adds up to a compelling profile: a generalist, problem-solving approach with mathematical grounding and a real love for coding.

“Agile” as lived practice, not a label

Today, Markus’s title is Senior Agile Architect. The “Agile” part isn’t a buzzword—it’s a stance. He puts it plainly:

Crucially, he emphasizes practice over prescription. For him, it’s not about imposing processes from above, but demonstrating their value through teamwork and results:

This is agility at eye level, not dogma. Practices aren’t legitimized by authority; they earn trust through outcomes. Teams feel the difference when iterative collaboration, short feedback loops, and clarity on goals translate into better results.

Architecture means end-to-end accountability—together

The other half of his title—“Architect”—comes with a broad scope. In Markus’s words, architecture includes the software design itself, the server landscape, deployment, and the test setup. He describes this with a matter-of-fact realism:

The key concept he uses is T-shaped: broad knowledge across many areas with deeper expertise in some—and, above all, enough understanding to contribute meaningfully. That pays off in two ways:

• Decision quality: Knowing implications across the lifecycle leads to more durable architectural choices.
• Collaboration: Understanding deployment and testing changes how you talk to Ops and QA—more solution-oriented and respectful.

In his view, T-shaped isn’t a nice-to-have in agile environments—it’s how the work gets done. Architecture is a team sport.

Generalist with focus: how breadth and depth reinforce each other

What does that look like in practice? Markus wants to “have an idea of all these areas.” That is precisely what distinguishes his role from a purely specialist track—without diminishing specialization. It’s a both-and perspective:

• Architects need to understand the seams: from the codebase through build and release processes and into production.
• They must be comfortable navigating different viewpoints: developers, testers, operations, product—each adds constraints and insights that shape architecture.

Not doing everything yourself doesn’t mean shedding responsibility. It means sharing it with the team so decisions hold up in the real world.

Soft skills as a core competence in architecture

A striking note in Markus’s account: his mathematics studies gave him programming basics—but above all, soft skills that move him forward in his job. For an architectural role, that’s not an aside. He states it plainly:

He also dispels a cliché:

Communication isn’t a side activity; it’s the medium in which architecture becomes possible: understanding requirements, building consensus, surfacing risks, explaining decisions, integrating feedback. Anyone aiming for architecture should invest in these skills deliberately.

Learning as joy—not a chore

Perhaps the most universal point Markus makes is about learning. His wording carries a clear expectation—of himself and of those considering the role:

For him, this joy is concrete: after his studies he completed many trainings and learned extensively on the job. He also portrays his company environment as one that actively fosters development—staying at the pulse of the times and embracing new technologies.

This isn’t an extracurricular hobby; it’s part of the professional identity. Technologies come and go, methods evolve, tools reshape how development, testing, and operations work together. If you see that as an invitation rather than a threat, architecture becomes a very fulfilling path.

From early patch files to a professional stance

What stands out is the continuity of themes in Markus’s story. It starts with patch files and scripts—pragmatically solving problems—and later shows up in how he understands agility: don’t preach, do. It also shows in architecture: don’t design in isolation; build team-based solutions that actually run—from software to deployment to the test setup.

Those early experiments in Basic and Logo weren’t an end in themselves. They trained the intuition that small building blocks can produce visible results, and they lowered the barrier to learn new technologies. Writing scripts at age eleven teaches you that you can touch things, break them, and fix them. That confidence is invaluable later—during code reviews, in architectural trade-offs, and when moderating risks.

Practical guidance for developers eyeing architecture

Several concrete takeaways emerge from Markus’s account—no checklists for their own sake, but actionable pointers:

• Become T‑shaped: Build broad fundamentals—code, infrastructure, deployment, testing. You don’t need to be an expert in everything, but you should understand the language and constraints of neighboring disciplines.
• Convince by doing: Work with the practices so people “see that this way of working really brings success.” Favor small, visible improvements over top-down appeals.
• Invest in soft skills: Architecture runs on communication. Practice active listening, clear reasoning, and respectful disagreement. This isn’t a bonus; it’s the core of the job.
• Treat learning as fuel: If continuous learning feels like a burden, the role will be hard to sustain. If it energizes you, you’re in the right place.
• Keep curiosity alive: The same energy that led you to patch files and scripts will carry you through new tools, paradigms, and teams.
• Value broad education: A CS degree isn’t mandatory. What matters is foundational thinking—analysis, structure, problem solving—and the ability to apply it in a team context.

Why “architect” doesn’t mean “solo designer”

Markus’s “that’s not how it works” regarding solitary work is a clear signpost: architecture isn’t a solo performance. It’s a facilitation role across perspectives—a shared decision-making process that must stand up to reality. That includes distributing responsibility so it’s sustainable: not deciding everything yourself, but enabling the quality of decisions with context, trade-offs, and transparency.

That’s why testing and operations aren’t afterthoughts in his description; they’re integral to architecture. If CI runs into a void, deployments wobble, or tests fail to be meaningful, that’s not “someone else’s problem.” It’s a signal that architectural guardrails are missing or not grounded.

Broad education, broad impact: an opening for non-linear paths

Another noteworthy cue in Markus’s story is his view on education. Mathematics gave him soft skills and fundamentals that matter in his job, but he’s explicit that you don’t need a math degree to get there. What counts is education that goes beyond a narrow target: a broad base of general knowledge and ongoing development.

This emphasis on breadth is encouraging—especially for those entering software from other disciplines or switching roles. What matters isn’t the label on your diploma, but whether you grasp how the pieces fit together and can build workable solutions in a team.

Agility must be experienced

A recurring thread in Markus’s story is that agility has to be experienced to be believed. Processes, boards, rituals—they remain hollow if they’re not filled with real collaboration and problem solving. His approach—“work with it”—is practically a blueprint: when the team sees that iterative flow unblocks work, that a clear definition of done produces quality, and that early testing reduces risk, practices take root naturally.

For architects, that means bridging principles and daily work—between guardrails and concrete code, between vision and the next commit. Not by having the last word, but by enabling the conversation and pointing the way forward.

A job that never gets boring

Markus calls his role one that “never gets boring.” That’s not a throwaway line—it’s the logical outcome of his mindset. Those who treat novelty as an invitation will find software development and architecture an inexhaustible learning space. New technologies, new domains, new team constellations—they all challenge and reward. Because he foregrounds the joy of learning, his enthusiasm feels authentic.

And this lens also tempers the chase for the next big thing. It’s less about adopting every trend and more about creating value across the breadth—while going deep where it matters for the team and the product.

What we learned from Markus Schwabeneder (SEQIS Group GmbH)

• Career paths don’t need to be linear. What matters is the underlying stance: curiosity, hands-on pragmatism, and teamwork.
• Agility is a practice. It convinces when it delivers visible results—not when it dictates rules.
• Architecture is holistic. It doesn’t stop at code; it spans server landscape, deployment, and test setup—and thrives on collaboration.
• Soft skills are decisive. Communication, exchange, and joint problem solving are core responsibilities, not side quests.
• Joy in learning is the engine. Those who embrace it stay current—through formal trainings, on-the-job learning, and initiative.

Closing thought: balancing breadth and depth

Markus Schwabeneder’s story illustrates a clear truth: good architecture emerges where people combine broad perspective, real communication skills, and a lived commitment to learning. The path can start with patch files, pass through Basic and Logo, be carried patiently through Pascal and Delphi, gain structure in Technical Mathematics, pick up speed in C++ and Java—and culminate in an architecture role where it all comes together.

For us, this session is a reminder of what matters: the joy of making things truly work, the power of teamwork, and the willingness to keep learning—not because you have to, but because you want to.

Those who share this compass will not only thrive in a role like Markus’s—Senior Agile Architect at SEQIS Group GmbH—but shape the work around them.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now

• 

  

  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.

  Watch now