Building SAP Products with Clarity and Momentum: Inside ATSP with Michael Hofstetter

What this conversation reveals

At DevJobs.at, we pay attention when a tech lead opens the hood on how structure, hiring, and onboarding really work. In this session, Michael Hofstetter, Leitung Software Development bei ATSP, outlines a crisp operating model: a focused engineering team, a wide range of SAP-based projects, a recruiting flow that prioritizes fit and speed, and onboarding anchored by a practical buddy system. He also draws clear technical lines—from ABAP to UI5 and an explicit outlook toward the cloud.

What comes through is an organization that creates room for growth without losing orientation: stable product teams where product knowledge matters, flexible staffing for custom projects, and collaboration between development and consulting that intentionally blends strengths on both sides.

Team size, locations, and work domains

ATSP’s development group is intentionally compact: twelve developers overall—eleven in Innsbruck, plus one in Vienna. This scale fosters short feedback loops and close proximity between team lead and individual engineers. You can hear that advantage in the way Hofstetter describes recruiting, role fit, and onboarding.

ATSP’s internal organization distinguishes two areas of work:

• Product development: the company’s own software products sold to customers.
• Individual development: customer-specific projects—ranging from minimal tweaks to extensive engagements.

Importantly, staffing stays flexible: “No developer is exclusively assigned to one domain,” Hofstetter notes. The team works across areas as needed. At the same time, product teams are kept relatively stable because product-domain knowledge is critical. Each product team has a lead developer and two to three supporting engineers.

By contrast, individual development is variable. The range spans “some two-hour adjustment” all the way to a “100-day project,” with staffing level scaling accordingly. That spread shows how diverse the engineering day-to-day can be at ATSP—and how fast people can learn by working across contexts.

Development–consulting collaboration

“Everything is on an SAP basis,” says Hofstetter. He also explains how responsibilities are shared between development and consulting, especially at the frontend–backend boundary:

• UI5 work is always handled by the development department.
• Backend parts are implemented partly by the development team and partly by colleagues in consulting.

This shared responsibility cultivates end-to-end understanding—and creates realistic options for people who want to dive deep into code while staying close to customer projects. That bridge reappears in hiring, where role preferences are discussed explicitly: “pure development” versus “technical consulting” with some development.

Product teams: ownership through clear responsibility

Where ATSP owns a product, teams are purposefully stable. A lead developer provides the backbone, with two or three engineers covering feature development, maintenance, and advancement. This design enables long-term knowledge building and simpler coordination.

For talent that seeks ownership across product cycles, it’s an attractive setting: focused and predictable, yet still porous enough to interact with custom projects.

Individual development: speed and variety

“It can be anything from some two-hour adjustment to a 100-day project,” Hofstetter summarizes. In practice, this means:

• fast, precise changes for minor adjustments,
• longer, team-based execution for larger projects,
• flexible staffing according to scope and complexity.

For engineers who enjoy variety, this is compelling. Every engagement brings new interfaces, new customer situations, and often new technical nuances—contained within a clear SAP technology context.

Hiring: clarity, fit, and speed

ATSP distinguishes between applications for open roles and unsolicited applications. In both cases, role clarity and fast decisions stand out.

Open roles: first conversation with engineering

When ATSP opens a role, it is assigned to a department—“who wants it.” If a developer applies, the first conversation is with Michael Hofstetter and a colleague from HR. The goal is expectation alignment:

• What does the candidate envision under a development role at ATSP?
• How does collaboration work in the department?
• What prior experience exists—industry-specific or general?

Hofstetter emphasizes that ATSP sees many graduates and career changers. All the more reason to align on what “development” means in this context. Another key question is the role preference: “pure development,” or “technical consultant” who wants to work with customers while still “doing some development.” ATSP stays flexible and decides how to proceed based on that exploration.

Unsolicited applications: management first, then round two

For unsolicited applications, HR and management conduct the first conversation to determine which specialty area is a fit. Then there is a second conversation in round two with the relevant side. A noteworthy commitment follows: “The goal is that after the second conversation we can make an offer within three working days.” That three-day mark sets a clear expectation for candidates—and demonstrates decision speed.

Onboarding: a three-month buddy system

ATSP anchors onboarding with a buddy (“Paten”) for the first three months. The buddy’s responsibilities are concrete and practical:

• ensure that the new colleague’s tech setup and tools work,
• serve as a fixed point of contact for admin and process questions,
• provide orientation on “who to call when…”

This role is especially important for people “fresh to the industry.” The buddy supports knowledge building, brings the new hire along to appointments, and explains “how to access certain systems” and “how to behave with certain customers.” Support tapers off as the person needs less help—“it gradually runs out”—until full self-reliance.

For tech talent, that means a clear entry path, lived support, and fast access to implicit knowledge—from systems to customer etiquette. It’s onboarding that integrates, not just a checklist.

Tech stack: ABAP, UI5, and the S4 context

“We traditionally work on SAP technologies—primarily ABAP,” Hofstetter says. Over recent years, SAP UI5 has “come on strong,” and it’s getting stronger as organizations switch to S4. ATSP has drawn a clear line of responsibility: UI5 is “always” handled by the development department. Backend parts, in turn, are divided between development and consulting.

That split creates a clean frontend focus in the dev team and allows backend functionality to align with customer-facing work. For engineers operating in or moving into the SAP space, the setup is valuable: UI5 skills are increasingly relevant, ABAP remains central, and the boundary between both offers room to grow.

Architecture trends: separation and a view to the cloud

Hofstetter names two directions shaping the work ahead:

• a clear separation between frontend and backend (UI5 frontend and a backend system),
• development moving toward the cloud over the next five to ten years.

He spells out the consequences of cloud explicitly: “It has effects on how we develop, what to watch for, how software is operated, how to deploy.” In other words, development practices, operating models, and release processes will evolve.

For talent eager to ride that wave, this is a chance to help shape architecture, quality, and deployment strategies—grounded in a stable base of SAP, ABAP, and UI5.

Role choice: engineering, technical consulting, or both

A striking point in Hofstetter’s outline is the explicit openness on role design. ATSP lets people align personal preference with organizational needs:

• If you want “pure development,” the development department offers a clear home.
• If you want to “work with the customer” and still “do some development,” the technical consultant path is an option.

From an employer-branding perspective, that’s more than a perk. It’s a deliberate way to attract different profiles without forcing them into rigid molds—and it fits the division of responsibilities (UI5 in dev, some backend in consulting).

Project experience: quick wins and long runs

The spectrum from “two hours” to “100 days” is not just a metric—it’s an invitation. Small tasks sharpen precision, communication, and the ability to deliver under tight time limits. Larger projects demand coordinated teamwork, forward-looking architecture decisions, and consistency over time. Together, they shape profiles that are particularly valuable in the SAP ecosystem.

How ATSP enables growth

Hofstetter’s description points to specific growth levers:

• Buddy system: structured onboarding that surfaces and transfers knowledge—especially for those new to the industry.
• Permeable team organization: contributions across product and custom projects wherever it fits.
• Role flexibility: engineering or technical consulting—with the option to blend both.
• Clear tech path: ABAP and UI5 today; frontend–backend separation and cloud on the horizon.
• Hiring speed: commitment to an offer within three working days after round two.

These points are concrete and operational—not vague promises—which makes them strong signals to candidates.

Why ATSP is compelling for tech talent

If you’re considering ATSP, this session surfaces several reasons to take a closer look:

• Everyday variety: from short tweaks to substantial projects—learning opportunities at every turn.
• Clear structures: lead developers in product teams; defined responsibilities across development and consulting.
• Mentored start: a three-month buddy providing orientation until self-sufficiency.
• Role flexibility: “pure development” or “technical consulting” with some development, depending on your profile and preference.
• Solid technical footing: SAP/ABAP as the core, with UI5 gaining traction and S4 driving modern UI adoption.
• Forward-looking posture: a visible move toward the cloud—with consequences for development, operations, and deployment.
• Swift decisions: an offer within three working days after the second conversation signals commitment and respect for candidates’ time.

Graduates and people switching into the industry will find an especially supportive setup: structured onboarding, real team responsibility, and an environment that doesn’t leave growth to chance. Experienced engineers will appreciate the room to combine technical depth with customer proximity.

How the application routes work

• Open positions: apply to a specific role assigned to a department. First conversation with Michael Hofstetter and HR. Expectation alignment and role clarification (“pure development” or “technical consultant” with development). Next steps decided based on fit.
• Unsolicited applications: first conversation with HR and management; determination of the suitable domain; second interview in round two. Target: an offer within three working days after the second conversation.

This process is clear, personal, and fast—connecting technical alignment with cultural fit without losing momentum.

Engineering culture: pragmatic, customer-aware, technology-forward

Even without buzzwords, a cultural picture emerges:

• Pragmatism: staff by need, scale for custom projects, and keep clear leads in product teams.
• Customer awareness: consulting colleagues implement some backend, and engineers can engage with customer settings depending on role.
• Technology-forward: ABAP, UI5, the S4 context, and an upcoming cloud direction—with consequences for how software is built, run, and deployed.

This mix is typical of organizations rooted in an established platform (SAP) while gearing up for modern frontends and cloud operating models.

Quotes and takeaways from Michael Hofstetter

A few statements from the session stand out:

• “No developer is exclusively assigned to one domain—everyone contributes.”
• “Product teams always have a lead developer, plus two or three supporting engineers.”
• “Anything from a two-hour adjustment to a 100-day project.”
• “We traditionally work on SAP technologies—primarily ABAP—and UI5 is getting stronger, especially as houses move to S4.”
• “UI5 is always done by the development department, while backend parts are handled partly by us, partly by consulting.”
• “The goal is to be able to make an offer within three working days after the second conversation.”
• “We have a buddy system for onboarding … from ensuring tech works to explaining how to behave at certain customers.”
• “Development is moving toward the cloud … affecting how we develop, operate, and deploy.”

Final word: a clear offer to engineers who want responsibility

The session “Michael Hofstetter, Leitung Software Development bei ATSP” presents an engineering organization with a clear frame and practical habits: transparent processes, focused responsibilities, and openness toward different role shapes. If you want to build in the SAP space—with a UI5 focus, ABAP as a backbone, and a view toward the cloud—this is an environment that not only expects impact but also supports growth.

What distinguishes ATSP is the combination: small and large projects; product and custom work; development and consulting skill sets—held together by leadership that values fit, speed, and support. For talent ready to take visible responsibility in a structured, collaborative setting, ATSP looks like a strong next step.

• 

  

  Laura Neuner, SAP Consultant bei ATSP

  Laura Neuner von ATSP erzählt im Interview über ihren Weg in die IT, was ihrer Ansicht nach für Neueinsteiger wichtig ist und gibt Einblicke in den Arbeitsalltag im SAP Consulting.

  Watch now