Late Start, Lasting Impact: How Manuela Jobstmann at SSI Schäfer IT Solutions Turned a Programming Pivot into Requirements Engineering Mastery

A clear arc: from a programming reboot at 38 to product impact

At DevJobs.at, we listened closely to the session “Manuela Jobstmann, Requirements Engineer bei SSI Schäfer IT Solutions.” The Speaker is Manuela Jobstmann; the Company is SSI Schäfer IT Solutions GmbH. What stood out was a career path that quietly undermines clichés about late entry into tech, lifelong learning, and the real-world practice of Requirements Engineering.

Manuela’s story is anything but linear. At 38, she starts a programming education—programming logic, C++, object-oriented programming, Java, and C#. She then takes on junior responsibilities—“like everyone else, just at 38”—builds momentum with one to two trainings per year, pursues a Master’s in Innovation Management at 48, and finally moves to SSI Schäfer IT Solutions GmbH. There, she chooses a role that amplifies her strengths in a new domain: Requirements Engineering in logistics.

We were struck by her composure around pace, collaboration, and quality—and by the clarity and structure in how she describes the workflow with stakeholders, product management, and engineering: from first problem statements and flowcharts to a shared acceptance test.

Milestone 1: A programming education at 38—choosing a deliberate restart

The first turning point is the decision to begin a programming education at 38. Her curriculum included:

• Programming logic
• C++
• Object-oriented programming
• Java
• C#

What matters is less the list than the posture behind it. Getting started as a junior—explicitly “like everyone else, just at 38”—highlights that seniority in years doesn’t automatically mean seniority in a discipline. The difference maker is taking ownership of one’s learning.

The message is straightforward: there’s no wrong time to enter tech. There’s only the wrong pace—rushing without depth or lingering without momentum.

Milestone 2: Continuous upskilling—the quiet constant

For years, Manuela keeps a steady rhythm: “one or two trainings every year” to remain professionally fit. That sounds unremarkable—until you realize how compounding skills turn into leverage. Requirements Engineering benefits when you understand technology, constraints, and unstated assumptions. Upskilling here isn’t window dressing; it’s tool selection.

This mindset culminates in a bigger move: a Master’s degree in Innovation Management at 48. Shifting from a purely technical to a process-and-decision perspective readies her for the role she now holds. Steering innovation requires observation, abstraction, and moderation—exactly the core of Requirements Engineering.

Milestone 3: Moving to SSI Schäfer IT Solutions—choosing the role over the stack

After additional training and early professional experience, Manuela seeks “a new challenge” and joins SSI Schäfer IT Solutions GmbH. The tech landscape is different—she had leaned more toward the Microsoft stack, and there the environment is Java-oriented—so she starts as a Requirements Engineer.

• Previous focus: more on the Microsoft stack
• New environment: Java
• Consequence: entry through Requirements Engineering rather than immediately coding in the new stack

This isn’t retreat; it’s smart leverage. She chooses the point in the system where she can have immediate impact rather than getting stuck on stack familiarity. A new domain—logistics—comes with it. She digs in and discovers that she enjoys writing software requirements, meeting customers, and orchestrating internal collaboration across departments.

The subtext is powerful: domain knowledge is learnable if your posture is right. What counts is a structured approach and real curiosity about the problem.

What Requirements Engineering means in her practice

Manuela does not frame Requirements Engineering as clerical documentation; she presents it as analytic, facilitative, and iterative teamwork. Her core responsibilities:

• Receive problem statements from product management or stakeholders
• Analyze problems or desired representations in the software
• Draft a rough flow (flowchart) outlining how the problem could be solved
• Discuss the draft with developers, who “have a different view of the software”
• Co-create a solution the group believes will work, then present it to stakeholders for review
• Keep fine-tuning during development (“small things”) to ensure the best outcome for stakeholders
• Implement, test, document, and release
• Conduct a joint acceptance test meeting with UI/UX, documentation, developers, and support

From an engineering lens this is a crisp cycle: diagnosis—design—peer review—validation—implementation—verification. The flowchart stage isn’t cosmetic; it’s the shared artifact that aligns perspectives.

She also clarifies that she no longer focuses on heavy documentation, except internal materials. The emphasis is on alignment, iteration, and getting to a solution everyone stands behind.

The power and tension of teamwork

Manuela emphasizes how collegial and collaborative the environment is—and how much she values teamwork. The trade-off is real: diverse points of view boost outcomes and also complicate coordination.

• Upside: broader perspectives, better solutions, shared ownership
• Challenge: different ways of working and seeing the same topic

The way through this is not mysterious—just demanding: conversations, steady collaboration, and a willingness to approach colleagues individually. Teamwork acts as a quality filter—not friction-free, but productive.

From desktop client to web solution: modernization as strategic decluttering

A particularly concrete theme is the product transition underway: alongside the existing client–server desktop client, SSI Schäfer IT Solutions is planning and implementing a web solution.

• Trigger: adding a web solution
• Opportunity: question each requirement’s timeliness
• Effect: shed legacy, become more user-friendly, more modern, “sleeker”

For product and engineering teams, this matters: migrations aren’t mere ports. They are strategic moments to prune requirements. A web solution also forces crisp flows and interaction clarity—perfect for flowcharts and explicit acceptance criteria.

Acceptance testing as a team ritual: quality belongs to everyone

The acceptance test happens “together in a meeting,” with UI/UX, documentation, developers, and support represented. That composition is intentional: UI/UX tests experience, documentation safeguards understanding, development verifies implementation, and support brings frontline reality into the room.

• UI/UX: is it clear and usable?
• Documentation: is it understandable and traceable?
• Development: is it solid and working as intended?
• Support: will it hold up under real-world usage?

The goal is explicit: arrive at a solution that “really gets the best out for everyone.” This standard is challenging—and it only works if the various perspectives shape the solution from the start.

Pace, patience, quality: an operating philosophy informed by architecture

A throughline in Manuela’s story is pace. Drawing on lessons from architecture, she puts it bluntly:

In complex software, speed without alignment creates future costs: bug-fixing, usability friction, technical debt. Her approach:

• Let colleagues work at their own pace
• Leave room for alternative views
• “Step back” at times—be ready to be convinced by other approaches
• Stay open to new things

This is the social complement to the technical process. It defends teams from premature solutions and increases buy-in.

A compact, practice-first guide distilled from her workflow

From Manuela’s account, we can extract a lean, durable pattern:

1. Capture the problem: get clear statements from product management or stakeholders.
2. Analyze: identify what issue must be solved or what needs to be represented in the software.
3. Draft a rough flow: sketch a flow/flowchart—the smallest common visualization.
4. Developer dialogue: actively seek the technical counter-perspective; align assumptions.
5. Co-create a solution: arrive at an option everyone believes in.
6. Stakeholder review: reflect the solution back for validation and legitimacy.
7. Fine-tune during development: keep quick loops for “small things.”
8. Implement, test, document, release: build steadily, verify, document where it matters, ship.
9. Run a joint acceptance test: include UI/UX, documentation, development, and support—quality is shared.

It’s neither heavyweight nor ad hoc. It’s a pragmatic middle path that many product teams can sustain.

The learning curves that compound: stack and domain

Two learning curves stand out in Manuela’s journey:

• Stack shift: from more Microsoft alignment to a Java environment—and the deliberate choice to create impact via Requirements Engineering rather than getting stuck on tooling.
• Domain shift: entering logistics—working her way in, building understanding, and discovering joy in requirements work inside that context.

For developers, this is permission to flex: switching domains and roles isn’t a dead-end; it’s an amplifier if you keep the process tight and stay curious.

Team culture: collegial but clear about expectations

Manuela calls the internal culture “very collegial,” while recognizing the reality of different work styles. Good team culture isn’t the absence of friction; it’s making friction productive—through dialogue, active listening, and a readiness to temper one’s own stance.

That sentence sounds simple and is anything but. Balancing individual tempo with a product roadmap requires facilitation—the very place where Requirements Engineering adds social value.

Concrete takeaways for engineers, PMs, and requirements practitioners

From the session “Manuela Jobstmann, Requirements Engineer bei SSI Schäfer IT Solutions,” we drew several field-tested practices:

• Start with the problem, not the solution: ask stakeholders to articulate pains first.
• Visualize early: a rough flowchart prevents months of misunderstanding.
• Invite counter-perspectives: developers see the system differently—use that.
• Make reviews routine: stakeholder feedback is a learning step, not a gate.
• Keep loops short: small alignments during development save large corrections later.
• Treat quality as a team sport: have UI/UX, docs, and support at the acceptance table.
• Use modernization to declutter: a move to web is the time to drop stale requirements.
• Choose pace with care: “fast solutions are often not the best”—plan for maturation.
• Stay open: temper personal preferences, recognize other views, keep learning.

Why this path points forward

The backbone of Manuela’s story is ownership—of learning, of clarity in collaboration, and of robust decisions.

• Lifelong learning shows up as routine (yearly trainings, Master’s at 48)
• Role flexibility beats stack fixation (entering a Java environment via Requirements Engineering)
• Team processes aren’t self-running (collegial, but demanding alignment)

For tech teams, this offers a stable blueprint—especially in transition phases like moving from a desktop client to a web solution.

Closing image: the late start as an unfair advantage

Late starters often bring two strengths: humility before the craft and persistence in the process. In Manuela’s case, those strengths converge into a Requirements Engineering approach that convenes people, tests assumptions, and makes quality visible.

“Be open to new things”—her closing sentiment—reads like a quiet verdict. It explains how a career can grow from a late start to steady, shared impact. And it reminds us that product outcomes depend less on when you begin and more on how you shape the journey.

• 

  

  Markus Duft, Senior Software Developer bei SSI Schäfer IT Solutions

  Markus Duft von SSI Schäfer IT Solutions gibt im Interview Einblicke in seinen Berufsweg, wie er schlussendlich zum Software Development gekommen ist und was seiner Meinung nach wichtig für Beginner ist.

  Watch now