Österreichische Lotterien
Philipp, System Engineer Linux bei Österreichische Lotterien
Description
Philipp von den Österreichischen Lotterien erzählt im Interview über seine Anfänge in der IT, den Arbeitsalltag in seinem Beruf als System Engineer und was seiner Meinung nach für den Einstieg wichtig ist.
By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.
Video Summary
In the talk Philipp, System Engineer Linux bei Österreichische Lotterien, Philipp traces his path from early IT passion and technical school through roles as an IT solution agent and a hands‑on stint at a small IT firm to Österreichische Lotterien, starting in Windows back‑office before moving internally to Linux as an Oracle DBA in the production systems team. He values owning and maintaining the redundant databases behind critical gaming systems and the flexibility to upskill during a cloud transition while keeping operations stable. His advice: cultivate genuine interest and PC stamina, build broad IT knowledge across cloud services, stay informed, seek peer exchange, leverage online training, and apply to roles that appeal to you.
From IT Solution Agent to Oracle DBA: Philipp, System Engineer Linux at Österreichische Lotterien on responsibility, cloud transition, and sustainable learning
Introduction: A grounded path into critical operations
In the session “Philipp, System Engineer Linux at Österreichische Lotterien,” Philipp lays out a path that mirrors many real IT careers: early curiosity, an entry in support, a deliberate move into a hands‑on environment, a return to a larger organization, and finally a shift into operational ownership. Today, Philipp works in the production systems operations team as an Oracle DBA, sharing ownership of databases that underpin the company’s critical game systems.
What stands out throughout his story is the combination of technical modesty and a strong learning mindset. Philipp highlights the need to upskill for a cloud transition while maintaining a stable production environment. For engineers and operators alike, this dual focus—reliability and growth—is the throughline and the source of actionable lessons.
“I have the ownership of the databases on the important game systems … We make sure they are maintained, we make sure they run, redundantly.”
Early curiosity: Technical interest that turned into a foundation
Philipp’s IT interest “was always there.” In school, he was “hooked” by computers, hardware, and software. The natural next step: a technical school education (HTL), which he “completed well.” That foundation matters. It builds systematic thinking, a practical approach to technology, and the confidence to iterate on real‑world problems.
We see this pattern in many developer stories: initial curiosity paired with a first chance to turn theory into practice. For Philipp, that combination led directly into his first full‑time role. There’s no romanticism in his telling—no miracle breakthroughs—just steady engagement, tinkering, and learning that compound over time.
First role: IT Solution Agent—close to issues, limited depth
Philipp started out as an IT Solution Agent. The way he describes the work is telling: he was “very strongly confronted with problems” but at a rather “surface‑level.” Anyone who has worked in first‑line or general support recognizes this: you triage symptoms more than you redesign root causes. That kind of work builds empathy for users, sharpens prioritization, and teaches impact—skills that become essential once you take on deeper operational responsibility.
For Philipp, that support vantage point was a stepping stone. The next move would shift him closer to the core of systems.
Small‑company turn: Hands‑on with servers, networks, and software
After the support role, Philipp deliberately chose a smaller IT company to go “hands‑on.” The focus expanded to include server technologies, networking, and software engineering tasks. He calls the switch a “nice contrast” to what he did before. This is a familiar arc for many engineers: move from ticket flow to system flow, from handling incidents to building and operating the underlying components.
That breadth is invaluable later on. When you’ve had your hands in provisioning, networking, and deployment, you understand infrastructure decisions not as abstractions but as moving parts with trade‑offs. Philipp’s next step would leverage exactly that practical exposure.
Returning to Österreichische Lotterien: Windows back office, application and database support
Philipp returned to the lotteries organization, this time on the Windows side, working with back‑office applications. He describes a split responsibility: application support and database support—not on the platform level but for special solutions. That phrasing suggests an application‑centric vantage point: understanding data flows, maintenance rhythms, and how updates or incidents are felt by real users and internal teams.
It’s also a people‑positive chapter: he highlights working again with colleagues he already enjoyed collaborating with. Such team ties often shape career choices more than we admit; supportive peers, shared context, and trust are catalysts for growth. After “one and a half to two years,” he made an internal move that would define his current focus.
The internal leap to the Linux track: Production operations as an Oracle DBA
Philipp transitioned internally “from Windows to the Linux track.” Today, he is part of the production systems operations team, employed as an Oracle DBA. His mandate: service, maintain, and ensure uptime for databases tied to the company’s “important game systems.”
“I’m in the production systems operations team … employed as an Oracle DBA and I service, maintain, and make sure our databases run with our important game systems.”
In practice, this means proactive maintenance, monitoring, and redundancy planning. When databases are critical, “runs stable” isn’t a platitude; it’s the operational heartbeat. And while keeping the lights on, the environment keeps evolving—pushing the role beyond rote operations into continuous adaptation.
Responsibility, redundancy, trust: What production means in practice
Philipp is plainspoken about redundancy: the team ensures databases are maintained and run redundantly. In production, responsibility translates into absorbing risk before it becomes user impact. Redundancy isn’t a bonus; it’s the baseline for availability. And “ownership” over databases implies decisions with consequences for throughput, consistency, and recovery.
Even without listing process acronyms, his account evokes the essentials: change management, maintenance windows, backup and recovery discipline, and continuous monitoring. The operating principle is clear: production is a promise—to users, to business stakeholders, and to the team itself.
Cloud transition as a learning engine: Timeboxed upskilling with support
A central theme in Philipp’s story is the “cloud transition.” The organization feels the shift, and the team is “challenged and asked” to upskill in that direction. Crucially, the company provides flexibility so learning can happen within working hours. Philipp calls out that they can “flexibly allocate work time” to focus on what will matter more in the future.
That setup is more than a nice‑to‑have. A cloud transition is not a simple tool swap; it’s a competence shift. It demands broad orientation (service models, operational approaches, security posture) while maintaining accountability for current systems. Philipp is frank about the tension: learning is encouraged, yet “it’s important to ensure our operations” remain reliable. That is the real challenge—and precisely where durable skills are forged.
The daily equation: Keep production safe while building the future
Perhaps the most accurate description of Philipp’s day is the “both‑and”: keep production stable while carving out time for future‑oriented learning. That is not a contradiction; it is a resource management problem. Solve it, and your operations become more professional. Structures that explicitly plan learning time reduce incidents, support better automation, and accelerate adaptation.
Philipp frames this as a “challenge” he enjoys. That sentiment reveals a lot about senior motivation: the drive to fold reliability and innovation into one coherent practice rather than treating them as competing goals.
Philipp’s advice: Interest, stamina, breadth—and community
Toward the end, Philipp gets concrete. His advice is refreshingly practical:
- Cultivate genuine interest: “A basic interest should definitely be present.” Curiosity fuels staying power.
- Accept the real work rhythm: “You need to be able to sit at a PC for several hours.” Concentration is part of the craft.
- Build a broad technical base: He observes “much more going in the direction of software” and recommends “comprehensive general knowledge” in IT.
- Embrace cloud breadth: “There are so many different services … that you can’t always go deep” because you need a broad service portfolio to build and operate systems.
- Stay informed: Track changes at the level of principles and patterns.
- Seek peers for exchange: coworkers, study peers, and “various online platforms” as accelerators.
- Use digital training: Many offerings are “partly available for free.” Low‑barrier, high‑leverage.
- Apply where it excites you: “Just try applying anywhere you might like.” Momentum beats perfection.
The list reads like a compact operating system for a learning career. No buzzwords—just habits that compound.
Breadth vs. depth in the cloud era: A practical truce
Philipp captures a core industry reality: the cloud’s service surface is so large that exhaustive depth across the board is unrealistic. This isn’t an argument against specialization; it’s a call for smart prioritization. The implied model looks like this:
- Go deep where you hold direct responsibility (e.g., database availability and maintenance).
- Stay broad where integration, selection, and operating models matter (cloud services, interfaces, security fundamentals).
That balance has always made sense. In a cloud context, it becomes non‑negotiable. Philipp’s path shows how to build it: start near users (support), learn through hands‑on system work (servers, networks, software), internalize application needs (back office), then assume platform ownership (production databases).
Learning environments that work: Why dedicated time beats slogans
A recurring thread is institutional support: flexible learning time tied to real goals (“cloud transition”). Without that structure, upskilling remains aspirational. Philipp’s team demonstrates a durable pattern: operations remain central, and learning is part of the job—not an after‑hours add‑on. That mindset produces sustainable capability, especially in teams that run critical systems.
For newcomers and career shifters: Concrete next steps
Philipp’s pointers translate into pragmatic steps:
- Nurture curiosity: Pick learning topics that genuinely interest you—intrinsic motivation sustains deep work.
- Train your focus: Work in time blocks at the PC; real progress needs concentration.
- Build the map: Understand enough across ops, networking, software, and data to ask meaningful questions.
- Practice cloud thinking: Service models, shared responsibility, operations patterns.
- Design for exchange: Schedule regular learning and discussion with colleagues, peers, or community groups.
- Leverage free resources: MOOCs, vendor training, documentation—start where friction is low.
- Test opportunities: Apply for roles that excite you—role changes accelerate growth.
These are compatible with multiple starting points—technical school, university, or a career change.
What responsibility looks like: Stability is built by teams
When Philipp talks about redundancy and maintenance, he emphasizes “with my colleagues” having ownership. That’s the real face of production work: few heroic solos, lots of team agreements. Clear processes, shared ownership, and cover for each other are what make reliability repeatable.
In game systems, where availability equals trust, the team forms the stability buffer. Philipp’s path shows how to grow into such teams: broad exposure, an application‑adjacent phase, and a willingness to carry real accountability.
Motivation that lasts: Why “challenge” is a healthy signal
Philipp calls the balance between safeguarding operations and upskilling a “challenge” he enjoys. That’s a useful filter for choosing roles: the best problems are challenging without being overwhelming; they have impact and allow for growth. Recognizing that in yourself leads to better career decisions.
Guardrails for organizations: Time, focus, and operational safety
Philipp’s story also points to organizational guardrails:
- Make learning time explicit: Not “on top,” but a defined part of working hours.
- Tie goals to transitions: Link upskilling to concrete steps in the transition path (e.g., cloud adoption).
- Protect operations: Role redundancy, clear processes, dependable handovers.
- Encourage breadth: Help people understand systems, not just tools.
These aren’t luxuries. They are prerequisites for evolving critical systems safely.
Quotes that stick
A few lines linger as anchors:
“A basic interest should definitely be present.”
“You need to be able to sit at a PC for several hours.”
“There are so many different services … you need a big portfolio of services.”
“We make sure [databases] run redundantly.”
They are understated and, precisely for that reason, credible. They describe the real work behind stable systems.
Conclusion: Learning mindset meets operational sovereignty
“Philipp, System Engineer Linux at Österreichische Lotterien” is the story of an engineer who refuses to pit breadth against depth. From IT Solution Agent to hands‑on roles in a smaller firm, back to the lotteries organization on the Windows side, and into today’s production operations role as an Oracle DBA. Along the way: team culture, ownership, and a clear enjoyment of the tension between stability and growth.
If there’s a takeaway, it’s this:
- Learn broadly; specialize where you own outcomes.
- Schedule learning like you schedule production—both are operations.
- Seek peer exchange—it is the shortest path to better answers.
- Apply boldly—role changes accelerate maturity.
At the end, Philipp wishes aspiring entrants simple “good luck.” It fits his story: luck favors a mindset—interest, stamina, and a steady willingness to shoulder responsibility.
More Tech Talks
More Tech Lead Stories
More Dev Stories
Österreichische Lotterien Sylvia, Senior Agile Developer bei Österreichische Lotterien
Sylvia von den Österreichischen Lotterien spricht im Interview über ihren Anfang mit dem Programmieren in der Schule, was das Besondere an ihrer aktuelle Arbeit ist und gibt Tipps für Neueinsteiger.
Watch nowÖsterreichische Lotterien Oscar, System Engineer Backup & Storage bei Österreichische Lotterien
Oscar von den Österreichischen Lotterien spricht im Interview über seinen Weg in der IT bis hin zu seinem aktuellen Job neben dem Studium und gibt Tipps für Beginner.
Watch nowÖsterreichische Lotterien Andreas, System Engineer Digital Workplace bei Österreichische Lotterien
Andreas von den Österreichischen Lotterien erzählt im Interview über seinen technischen Background in der Schule, was seine Arbeit als System Engineer Digital Workplace umfasst und gibt Tipps für Neueinsteiger.
Watch now