From a Basement PC to Automation Troubleshooting: Kevin Greßlehner (DS Automotion GmbH) on Networks, Control Systems, and Learning by Building

Why this DevStory matters

In the session “Kevin Greßlehner, IT Techniker bei DS Automotion,” speaker Kevin Greßlehner from DS Automotion GmbH offers a clear, grounded look into a role many engineers know by name but rarely see explained this vividly: customer-facing IT in highly automated environments. What we heard is the journey of a hands-on tinkerer who turned curiosity into a career that blends network design, control systems, and meticulous troubleshooting—seasoned with humor and strong team spirit.

What stood out to us at DevJobs.at: this career is less a straight plan and more a mindset. Kevin’s story follows a consistent loop—build it yourself, try it, understand it—from the first “broken” PC in the basement to high availability in production.

The first spark: A “broken” PC that wasn’t broken

At seven years old, Kevin’s family had an old PC that was deemed broken and relegated to the basement—“a huge black bucket,” as he remembers. He quietly carried it upstairs, hooked it up, and discovered it worked fine. He played the games of that era. The year was around 2003, and that moment started everything.

It’s more than a childhood anecdote. It sets the tone for everything that follows: don’t accept that something is impossible or defective—check, set it up, test it, and trust yourself in the process.

From tinkering to programming: Linux, Basic, and the question “What else can this do?”

What began as gaming quickly became a passion for building. Kevin got space in the basement to “build and experiment.” He dug into hardware, installed Linux, and asked the crucial question: “What else can this thing do besides gaming?”

His answer: programming. He taught himself Basic—still a kid at that point, somewhere between eight and ten years old. “Poorly learned,” he jokes, but the direction was clear: learn independently, understand how things work, turn ideas into working systems.

This early mix of hardware, operating systems, and programming forms a foundation we often see in careers that move toward complex systems: if you’ve opened hardware, installed OSes, and then written code, you naturally build a mental model for how components fit together.

HTL IKT: Systems, networks, Java, and projects

After middle school, Kevin attended a technical high school (HTL) with a focus on Information and Communication Technology. He solidified a broad technical profile:

• Network engineering
• Systems engineering
• Programming (Java at the time)
• Project work including project management

It’s an important combination: theory meets practice, code meets operations, and everything is tied together in projects. That blend becomes essential later in customer service IT—where software, networks, hardware, and real-world processes don’t just coexist, they co-operate.

The DS Automotion moment: Autonomous vehicles in the production hall

After graduating and completing military service, Kevin started looking for jobs and discovered DS Automotion GmbH. During the interview, he was brought into the production hall, where vehicles and forklifts were “driving completely on their own.”

The decision came quickly: he accepted the next day. Since 2016, Kevin has worked in customer service IT for DS Automotion’s systems. This is where the work becomes both deeply technical and grounded in real operations.

Customer service IT since 2016: Where technology meets operations

Kevin’s scope is broad, with clear technical cores and continuous contact with production reality:

• Network engineering on the customer side: assigning IP addresses to vehicles, structuring the network, aligning on firewall rules
• Integrating third-party devices into the system
• Setting up control systems: Engineering delivers the system; Kevin’s team installs it on the customer’s machines and ensures ongoing operations
• Verifying communication between all components
• Handling failures across the stack—from vehicles and control layers to peripheral components like a fire protection door

It’s technically demanding and operationally critical. His role sits at the nexus of engineering, infrastructure, and the customer’s day-to-day processes.

Customer networks: Structure, addressing, firewalls, third-party devices

One of the most tangible parts of Kevin’s work is network design at the customer site. New systems mean entire fleets and control systems must be addressed, segmented, and secured properly.

• Assigning IP addresses to vehicles and components
• Structuring network segments in alignment with the customer’s IT
• Defining and agreeing on firewall rules
• Onboarding and integrating third-party devices

This is where stability and security are set in motion—or where later “3 a.m.” incidents are prevented. It’s not glamorous, but it’s fundamental: clean design, clear responsibilities, and auditable rules.

Control systems: From engineering to production

Control systems arrive from the engineering team. Kevin’s team installs them on customer servers, verifies communication, and prepares for ongoing operations. This handover from development to production is a critical phase: versions, configs, interfaces, and dependencies must align.

After go-live, support also lands with his team. If something goes wrong, the trail often leads back to customer service IT for investigation and resolution.

Support and troubleshooting: Detective work with logfiles

When a customer reports a malfunction, detective work begins. Kevin calls it exactly that—and the label fits.

The process is structured yet demanding:

1. Intake—via email, phone, “sometimes at three in the morning.”
2. Reality check—“What does the system look like right now? How is it behaving?” Does the customer’s description match the current state?
3. Logfiles and hypotheses—open, parse, and ask: where did a part of the software “take a wrong turn,” or is it a user error?
4. Differentiate, document, explain—deliver a clear, evidence-based description to the customer.

It’s technical and communicative at once. Sometimes a customer insists “we caused it,” and it’s a particular kind of satisfaction when logs and logic prove otherwise.

Behind the humor lies professionalism: error culture, evidence, and clarity. That combination keeps crises manageable.

Team culture: Friendship, humor, and Nerf darts

Despite the seriousness of operations, Kevin’s team culture is warm and tight-knit: “It’s more like friends than colleagues. We have fun at work.” When a customer is „not quite satisfied,“ Nerf darts may fly across the office. There’s no rigid “by-the-book” attitude here—just a team that shares proximity and humor. That makes a difference when a 3 a.m. call comes in or a high-availability setup needs thorough testing.

High availability in practice: Designing, setting up, and testing failover

New systems often require high availability. That means hardware, configuration, and testing to ensure a second server takes over when the first fails.

Multiple disciplines meet here: infrastructure design, operational procedures, and test methodology. Kevin emphasizes how much he enjoys this—and extends an invitation to anyone interested: get in touch with DS Automotion’s HR.

Mindset: Curiosity and the will to build

The most defining piece of this DevStory is Kevin’s approach to learning and work. It’s simply stated and consistently applied: be curious, build it yourself, do the work.

Instead of buying a ready-made solution at the first sign of a problem, start by asking: can I build this myself? That’s how you learn. Practical, hands-on experience pays off later in professional contexts—from running your first home cloud to parsing complex logfiles under pressure.

Concrete starting points: Microcontroller irrigation and a home cloud

Kevin offers two crisp examples:

• Build an irrigation system using a microcontroller instead of buying a commercial solution.
• Host your own cloud at home rather than entrusting data to a “big behemoth” like Microsoft or Google.

Both ideas deliver the same lesson: if you set up and run systems yourself, you learn core principles—networking, security, operations, troubleshooting—firsthand. That experience becomes the foundation for understanding and shaping industrial IT landscapes later on.

What engineers and IT talent can take away

Kevin’s path and day-to-day responsibilities translate into clear guidelines:

• Build broad fundamentals: hardware, OS, networks, programming. Breadth helps you act decisively in heterogeneous systems.
• Learn through projects: theory becomes robust when exercised in real scenarios—like HTL project work or setting up a personal cloud.
• Think end-to-end: control systems, vehicles, third-party devices, firewalls—everything is connected. Your solution only counts in the full chain.
• Document and prove: logs, hypotheses, clear communication. Good troubleshooting is detective work—structured, evidence-based, respectful.
• Nurture team spirit: humor and trust make a difference when it’s “three in the morning.”
• Enjoy operations: high availability is a discipline, not a buzzword. Designing, setting up, and testing failover is real engineering.
• Build it yourself: nothing beats the experience of configuring, running, and understanding a system end to end.

A “DevOps mindset” without the buzzword

Kevin doesn’t use slogans. But what he describes naturally reflects a DevOps-like mindset:

• Accountability from install to operations
• Collaboration with engineering and customer IT
• Focus on automated systems that work in real production
• Continuous learning through hands-on practice

No hype, just results: vehicles that “drive on their own” because networks, control systems, and servers run reliably in the background.

Who this path fits

This DevStory speaks to people who love making systems run—where it matters: at the customer site, in production halls, under time pressure, with a mix of structure and pragmatism. If you enjoy testing hypotheses against logfiles, designing networks that prevent 3 a.m. calls, and thinking of high availability as testing rather than diagrams, you’ll recognize yourself in Kevin’s description.

For anyone at the beginning, Kevin’s advice is a practical starting point: be curious, build it yourself, repeat. A “broken” basement PC can become much more.

Quotes and ideas that stay with us

These lines capture the core: curious, accountable, hands-on.

Conclusion: A career that starts with building—and matures in operations

“Kevin Greßlehner, IT Techniker bei DS Automotion” shows how early tinkering can grow into a resilient, versatile IT career. At DS Automotion GmbH, Kevin blends network engineering, control system setup, troubleshooting, and high availability—supported by a team that pairs professionalism with humor.

If this world resonates with you, the message is clear: understand systems, take responsibility, provide evidence—and keep building things yourself. That is the kind of technical maturity you need when vehicles drive on their own and systems run around the clock.

Kevin closes with an invitation: bring your curiosity, get hands-on—and reach out if that’s your idea of meaningful IT work.

• 

  

  Klemens Pleiner, Basis Software Developer bei DS Automotion

  Klemens Pleiner von DS Automotion gibt im Interview Einblicke in seinen Weg als Developer, das Besondere an seiner aktuellen Arbeit im Unternehmen und was seiner Meinung nach wichtig für Neueinsteiger ist.

  Watch now
• 

  

  Gerald Hahn, Requirements Engineer bei DS Automotion

  Gerald Hahn von DS Automotion berichtet im Interview über das Requirements Engineering: wie er in die Branche eingestiegen ist und was er Anfängern raten würde.

  Watch now
• 

  

  Lukas Fiel, Test Automation Engineer bei DS Automotion

  Lukas Fiel von DS Automotion erzählt im Interview von seinem Werdegang von den eigenen Projekten bis hin zum Test Automation Engineering und welche Tipps er für Neueinsteiger bereithält.

  Watch now