Techleadstory: Building the Land Transport Product at Quehenberger Logistics – Insights from “Alexander Reichl, Product Owner bei Quehenberger Logistics”

Why this session matters for engineers

In “Alexander Reichl, Product Owner bei Quehenberger Logistics,” we heard a grounded, no-nonsense walkthrough of how logistics tech actually gets built and run inside a European forwarding company. Alexander Reichl lays out the operating model for the Land Transport product at Quehenberger Logistics: a compact team that spans first-line TMS support, light customization and development, project management, and long-term product stewardship. The story is compelling for tech talent because it combines real operational impact with end-to-end ownership.

Rather than slides about distant visions, the session focuses on practical mechanics: a ticketing system with change requests, a monthly cross-product prioritization routine, close collaboration with a group-wide TMS-IT of dedicated developers, and a commitment to monitor and improve solutions long after go-live. It also spotlights the big theme in logistics IT today: connectivity. Think customer portals, carrier portals, partner integrations—and a steady stream of requests for real-time visibility.

The team structure: small, focused, product-centric

Quehenberger runs Land Transport with a deliberately lean setup, as Reichl explains:

• Three people handle TMS support. “Support” here goes beyond classic first-line tasks and reaches into second-line customizing and simple development.
• A key support topic is “Offertspeicherung” (offer storage): customer price offers are stored so pricing can be generated automatically during order entry.
• At group level, there is a TMS-IT unit with dedicated developers—Reichl mentions “around ten” across the group—who work across products and systems. The Land Transport product taps these resources for projects.
• A ticketing system manages change requests. Assignments are coordinated by the responsible lead in TMS-IT. A monthly meeting aligns priorities across products and drives implementation.
• Within Land Transport, two people run project management. They are the “central hub,” taking in requirements, designing processes and functions, steering implementation and rollout, and then owning long-term monitoring.

This compact structure concentrates responsibility and learning. It encourages people who like to shepherd a solution from concept all the way to stable operations—with the credibility that comes from seeing how tech decisions play out on the ground.

No handoffs over the wall: cradle-to-operations ownership

A defining theme is the absence of a “throw it over the wall” mentality. Once a project ships, the product team stays responsible—functionally and operationally.

• Concept and design happen in the product team, closely aligned with operational stakeholders.
• Implementation and rollout are coordinated by the product team in collaboration with the group’s TMS-IT.
• After go-live, long-term monitoring remains with the product. Feedback loops feed improvements and new change requests.

For engineers and product people, this creates a virtuous cycle: you own the problem, the solution, and its success over time.

A concrete flagship: AI-driven order entry as a core element

Reichl names “AI order capture” as a current initiative. The emphasis, however, isn’t on hype—it’s on the function’s centrality.

For engineers, the implication is clear: this isn’t tech theater. It’s a production-critical capability. If you care about shipping AI where it actually carries an operation, you get that chance here.

Working with the group-wide TMS-IT

Beyond the Land Transport unit, there is a group TMS-IT with dedicated developers who build features across products and systems—Reichl mentions “about ten” in total. Collaboration runs on clear rhythms:

• Change requests go into the ticketing system and are assigned centrally.
• A monthly meeting lines up priorities across all products.
• The Land Transport product pulls TMS-IT resources for specific projects.

For developers, this means focused work items and clear prioritization. For product managers, it means stakeholder alignment and the ability to argue for value within a shared development pipeline.

Engineering culture: close to people, close to operations

Reichl draws a realistic picture of two complementary modes of work:

• IT project leadership is people-centric and field-facing—“viel mit Menschen,” often out in operations. It blends process design, facilitation, and translation between business and tech.
• Development is more desk-based. Still, product context matters, because logistics complexity emerges from how many actors and processes interact.

This alignment—tech serving operations, operations informing tech—permeates the session. If you thrive at that interface, you’ll find the right conditions here.

Connectivity over silos: portals, interfaces, standardization

Reichl is blunt about where the industry is headed: more portals, more APIs, more partners. But that explosion of endpoints can backfire if it isn’t standardized.

The takeaway for tech talent: integration is the job. It’s about interface design, resilient data flows, and architecture patterns that reduce friction rather than multiplying it.

Real-time visibility: high demand, real complexity

Reichl says requests for real-time tracking and visibility hit his desk weekly. The challenge isn’t desire, it’s the market’s structure:

• The forwarding landscape is “very decentralized and segmented,” with “many players.”
• Each interface adds complexity, especially for tracking across a chain with multiple handoffs.

Engineers who enjoy hard problems will recognize this: you need pragmatic interfaces, clear contracts, exception handling, and a tolerance for heterogeneity.

Digitalization as an economic and employee mandate

For Reichl, digitalization is table stakes: it’s how you maintain and improve outcomes—and how you meet the expectations of a modern workforce.

The challenge: existing systems and processes can be “a bit more rigid.” The craft is to evolve them toward mobile and user-friendly experiences without losing operational reliability.

Hiring: central HR, active networking, direct conversations

How do new colleagues join? Reichl outlines a multi-pronged approach:

• Central HR manages recruiting. The product team files requests (e.g., project leadership, backend development) that HR routes to suitable channels.
• Roles are posted on various portals, complemented by targeted headhunting and presence at fairs and conferences.
• Networking matters: you can approach Reichl directly at events if the conversation fits.
• As he quips: “Hoffentlich über Dev-Jobs oder solche Plattformen.”

For candidates, this means that formal applications and authentic technical conversations both carry weight.

Profiles that fit: open to career changers, realistic expectations

Reichl prioritizes curiosity and motivation:

• An interest in IT is essential; enthusiasm for logistics is helpful.
• Career changers are welcome—the team has “done very well” with them.
• The “dream candidate” (15 years of programming, 15 years of IT project leadership, plus a forwarding apprenticeship) is an intentional exaggeration. Realistically, nobody has that.

Logistics keeps things varied, too: today a steel client in Linz, tomorrow textiles—different approaches, different constraints. That variety is a selling point in itself.

Why engineers should consider this team

From the session, several reasons stand out for joining Quehenberger Logistics’ Land Transport product:

• End-to-end ownership: from discovery and design through rollout and long-term monitoring. No throw-over-the-wall mentality.
• Visible impact: core functions like order entry sit at the heart of the operation. Your work shows up in daily results.
• Serious integration work: customer and carrier portals, partner interfaces—real-world complexity with tangible value.
• Real-time visibility as a standing challenge: high demand, ambitious requirements, and a fertile ground for robust tracking.
• Small, compact teams: short paths, close collaboration with operations and the group TMS-IT.
• Openness to career changers: motivation and learning mindset matter as much as a perfect resume.
• Broad product learning: process design, implementation, and continuous improvement are part of the role.
• A modern employee experience as a goal: moving toward mobile, digital tools—even if legacy systems are rigid today.

How decisions and delivery flow day to day

Reichl sketches a cadence that gives structure without bureaucracy:

• Tickets and change requests are captured centrally in the ticketing system.
• A monthly prioritization meeting aligns competing demands from multiple products.
• The group TMS-IT executes, while the Land Transport product team remains responsible for concept, introduction, and ongoing monitoring.

For product leaders, that means prioritization, stakeholder engagement, and release planning. For developers, it means focused backlog items with a clear path to production—and a culture that values maintainability, evidenced by the emphasis on post-go-live monitoring.

A culture of proximity: tech meets people

You can hear it between the lines when Reichl emphasizes being “viel mit Menschen.” In forwarding, technology must mesh with drivers, dispatch, customers, and partners. If you like to work across boundaries, you’ll find an environment that asks for and rewards that strength.

At the same time, “classic” development has a strong home here—clear requirements, bounded projects, and the assurance that your code runs in a visible operation rather than being filed away in a backlog.

Standardization as a guiding principle

Perhaps the clearest strategic thread in the session is the call for standardization. Portals and APIs have multiplied. The next leap comes from connecting and standardizing them so employees can actually work faster—and customers get the digital experience they expect.

For engineers, that translates to architectures and patterns that outlive a single integration. It’s reusability, clear ownership of interfaces, and data flows that hold up across company and system boundaries.

Conclusion: A pragmatic blueprint for product-strong logistics tech

“Alexander Reichl, Product Owner bei Quehenberger Logistics” offers a realistic blueprint for tech teams in logistics: small and focused, close to operations, organized around clear prioritization, and serious about long-term product stewardship.

If you join, you sign up for:

• true product responsibility rather than one-off delivery,
• integration challenges that stretch your skills,
• a culture that thinks people and technology together,
• and an environment that values curiosity—including from career changers.

Reichl’s invitation is straightforward: apply via central HR, through portals and targeted recruiting, or approach him directly at fairs, conferences, and talks. For engineers who enjoy that “no day is like the other” reality and want to learn logistics from the inside out, Quehenberger Logistics’ Land Transport product offers the right mix of responsibility, impact, and team proximity.

• 

  

  Bernhard Kriechbaum, Team Lead IT Project Management bei Quehenberger Logistics

  Team Lead IT Project Management bei Quehenberger Logistics Bernhard Kriechbaum gibt im Interview Einblicke in den Aufbau der IT Abteilung, an welchen technologischen Challenges dort gearbeitet wird und wie das Recruiting und Onboarding abläuft.

  Watch now

• 

  

  Julia Keplinger, IT Team Lead bei Quehenberger Logistics

  Julia Keplinger von Quehenberger Logistics spricht im Interview über ihren Werdegang in der IT, wie sie schließlich zu ihrer aktuellen Arbeit als Teamleiterin gekommen ist und welche Tipps sie für Neueinsteiger hat.

  Watch now