enjoy IT GmbH

Established Company

Show all Videos

Oktay Akgül, Lead Developer bei enjoy IT

Oktay Akgül von enjoy IT erzählt im Interview wie er zum Programmieren gekommen ist, wie sich dann der Weg bis zu aktuellen Arbeit als Lead Developer gestaltet hat und gibt Tipps für Neueinsteiger.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "Oktay Akgül, Lead Developer bei enjoy IT," Speaker Oktay Akgül traces his path from HTL Leonding through a CS bachelor’s and master’s at JKU Linz to a backend focus and a Lead Developer role he initially confused with project management. He explains that the job spans the full lifecycle—choosing technologies, resolving spec contradictions, shaping teams, driving reviews and pipelines, and ensuring maintenance and security—with communication at its core. His advice: start with one language (he used Java/C#), practice through personal projects, master transferable concepts, and host and secure your own apps and websites.

From HTL to Lead Developer: Lessons from “Oktay Akgül, Lead Developer bei enjoy IT” for Backend-Focused Careers

What we heard and learned as the DevJobs.at editorial team

In the session “Oktay Akgül, Lead Developer bei enjoy IT” (Speaker: Oktay Akgül, Company: enjoy IT GmbH), we followed a journey that will resonate with many developers: curiosity about tech leads to first steps in programming, university practice deepens the craft, and a deliberate choice emerges—to build software and take responsibility as a Lead Developer.

What stands out is how grounded the message is. No tool fetish, no myth of “born talent.” Instead, pragmatic insights: he recalls realizing “programming is for me” once he started with Java and C# at HTL. Later, he emphasizes the importance of just doing the work—building apps or websites, discarding some, deliberately focusing on a few languages, and internalizing core concepts that transfer across syntaxes.

This is more than a career vignette. It’s a practical outline of how to grow your craft, how a Lead Engineer looks beyond code to people, processes, and quality—and why software work remains an ongoing learning path that doesn’t get boring.

Early spark: tinkering, numbers, math—and first contact with code

Oktay Akgül describes his start without embellishment: he chose the Informatics track at HTL in Leonding even though he “didn’t really know what programming is or what would be coming.” The drivers were there—interest in technology, tinkering with laptops and PCs, fascination with tech gadgets, and a preference for numbers and mathematics.

Then came Java and C# as “entry languages” at HTL, and something clicked: he discovered that programming is a way to solve problems—structured, repeatable, comprehensible.

“Programming is for me … you can solve problems and you have to solve them with programming.”

For many, this is the turning point: a growing vocabulary of languages and concepts, coupled with the satisfaction of producing tangible results through code. That early confirmation became a compass.

University and depth: from interest to a conscious professional choice

After HTL, he went on to complete a Bachelor’s in Informatics followed by a Master’s in Computer Science at JKU Linz. University was more than a credential; it enabled practice, deepening, and a conscious decision:

Clarity of goal: “I want to build software.”
Architectural mindset: “I want to know from the start how software is created, with which languages and frameworks you can ideally set it up.”
Focus: since then, he has remained “in the world of backend systems.”

We take three themes from this part of his story: first, learning happens through doing—especially at university, where practice around final work helps build muscle memory. Second, specialization tends to follow what captivates you; for him, it’s backend systems. Third, an advanced degree can sharpen and ground the internal choice to “build software.”

Clarifying the role: from initial confusion to a clear self-concept

“I used to think I wanted to be a project manager. I didn’t know that it’s actually Lead Developer.” This captures a common early-career confusion. Project Manager and Lead Developer are not interchangeable. For Akgül, the pivot was simple: if you have deep technical familiarity, you naturally move towards the lead path.

His day-to-day mirrors this: “I’m not chained to a computer all day—quite the opposite. I have to communicate a lot.” As a Lead Engineer, he’s involved “in every step of the evolution of a software”—from concept to development to maintenance.

For us, this frames technical leadership as a two-fold motion: deep enough in code to judge architecture and quality, and close enough to people and stakeholders to orchestrate decisions, priorities, and conditions.

Phase 1: Concept—technology choices, contradictions, third-party systems, team composition

When Akgül talks about concept work, the lead workflow comes into focus. The questions include:

“Which technologies do we use for the requirements?”
“Are there contradictions in the specification that we need to clarify?”
“Which people do we bring in?”
“Which third-party systems do we need to integrate?”
“How do we use the strengths and weaknesses of team members?”

These questions point to responsibilities we often see underestimated. Technology choices influence complexity, maintenance pressure, and team dynamics. Early identification of specification contradictions saves teams from hard rewrites. Knowing team strengths enables people to contribute at their best.

A concept-phase checklist for leads (drawn from Akgül’s remarks)

Translate requirements into technology choices: Do the language and framework fit the problem class?
Clarify spec conflicts early: Where are assumptions incomplete or contradictory?
Plan third-party integrations: Which interfaces, dependencies, and risks are involved?
Align tasks with team strengths: Who takes what, and where are the best learning opportunities?
Plan for maintainability: How will we keep the system current and secure later on?

Phase 2: Development—quality, code reviews, processes, pipelines

In development, Akgül highlights moves that underpin any professional codebase:

Give feedback and perform code reviews
“Make sure the quality fits”
Ensure processes and pipelines are set up so that developing isn’t hard
“Eliminate all problems”—such as missing access rights or missing documentation

What sticks with us: his focus on removing friction. “It must not be difficult for a developer to develop.” This is both humane and economical: each access unlocked, each doc clarified, each pipeline working is a direct accelerator of delivery.

A development checklist for leads (based on Akgül’s points)

Establish and live a review routine.
Communicate quality expectations without over-bureaucratizing.
Set up pipelines for fast feedback and reliable deployments.
Hunt down friction: access, documentation, test data, environments.
Maintain communication loops across devs, lead, and stakeholders.

Phase 3: Operations and maintenance—stay current, fix vulnerabilities, assign responsibility

“How will this be maintained?” That question accompanies every decision. Akgül puts it plainly: you must stay up to date “with every software, every programming language, every framework.” If there are vulnerabilities, they need to be fixed—and it must be clear who fixes them.

The maintenance mandate, as we read it:

Currency: observe versions and framework updates, plan accordingly.
Security: identify, prioritize, and fix vulnerabilities—including explicit responsibility.
Ownership: when a security update lands, who does what, and when?

We sense a DevOps-adjacent posture here: responsibility doesn’t end at merge. Operations, upkeep, and security are part of a team’s delivery remit—and a lead developer ties these threads together.

No single ideal path: interest, practice, and focus as the throughline

Akgül is explicit that there’s no “ideal type” path: no one must follow HTL plus university. The key is being “interested in solving problems with the skills you’ve built.”

He then gets surprisingly concrete about those skills:

Choose one programming language to grow familiar with
Practice a lot—through university work or privately
Build an app or a website—and discard some projects, too
Don’t try too much at once; specialize in a few programming languages
Internalize core concepts—they translate across languages; syntax differs, principles hold
Get exposure to many frameworks and set up lots of things yourself
Don’t just program, but also host, harden the server, and secure the web server
Work “step by step” and ensure you’ve done something tangible at each level of development

“You just have to do it … and the most important thing is not to try too much at once.”

From our editorial vantage point, this is the blueprint for sustainable learning: focused, hands-on, with end-to-end responsibility. Running what you build—and securing it—closes the feedback loop that a lead later shepherds for the team.

Choosing backend: why this focus compounds

Akgül has “stayed in the world of backend systems.” He doesn’t dress this up; it follows from wanting to build software end-to-end and understand how it’s set up with languages and frameworks. Backend work naturally intersects with data flows, integrations, and third-party systems—the very topics he emphasizes during the concept phase.

For many careers, this focus accelerates growth: thinking in terms of interfaces, persistence, and maintainability helps you spot dependencies early and prioritize quality constraints sensibly. That orientation echoes through his whole workflow: technology choices, reviews, pipelines, and security.

Communication as a core skill: leading without being “chained to a computer”

One line stands out: “I’m not chained to a computer all day—quite the opposite. I have to communicate a lot.” This captures the shift from individual contributor to lead. Communication isn’t an add-on; it’s the instrument.

In the concept phase, communication clarifies contradictions and priorities.
In development, it channels feedback, code reviews, and process agreements.
In maintenance, it establishes clear responsibilities.

Leadership shows up as coordinated clarity. Code expertise remains foundational; effectiveness comes from mutual understanding between developers, stakeholders, and integration partners.

Practical guidelines for aspiring lead developers (derived from Akgül’s story)

Without inventing new facts, we can distill pragmatic guidelines from his remarks:

Choose one or two core languages and learn the concepts deeply enough to translate them to other languages.
Build things—apps, websites—and don’t be afraid to throw some away.
Think end-to-end: not only coding, but also hosting and securing.
Remove friction relentlessly: access, documentation, pipelines—developer flow matters.
Treat maintenance as part of quality: stay current, patch vulnerabilities, assign ownership.
Play to team strengths: align tasks with people’s capabilities and learning edges.
Surface spec contradictions as early as possible—they are the root of many later problems.
Communicate a lot, and purposefully—across all stages of software evolution.

These aren’t flashy—but that’s precisely why they work. They’re the craft moves of sustainable leadership.

Translating “just do it” into daily practice

Akgül repeatedly stresses practice: “occupy yourself privately,” “set things up yourself,” “host,” “secure.” That learning mode can be applied across career stages:

Beginners: pick a language, start a small project (e.g., a simple website), deploy it, and secure it intentionally.
Intermediates: explore a second stack via concepts; notice how syntax and idioms differ without spreading yourself thin.
Leads-in-training: grow process and pipeline literacy; facilitate code reviews; integrate third-party systems; clarify responsibilities.

The key is to avoid “too much at once.” Focus produces depth; depth enables transfer.

Quality as a team sport: reviews, processes, pipelines

When Akgül talks about quality, he locates it in team processes: reviews, feedback, functioning pipelines. Quality is not just in the editor; it emerges from collaboration—through standards that are understood and lived.

In practice, that implies:

Review culture: reviews are dialogues, not gatekeeping rituals.
Documentation: missing documentation is a process bug—fix it like any other.
Pipeline stability: without reliable pipelines, quality signals will dissipate.

These pieces fit together in his portrait of a lead who clears obstacles instead of administrating them.

Security and currency: the invisible part of delivery quality

“Are there security vulnerabilities we have to fix? Who fixes them?” This neatly expresses his view of security: as a binding task with explicit responsibility. This is where reliable delivery is made or broken. Security and version upkeep are not side quests; they’re part of the software’s evolution.

For leads, that entails two simultaneous lenses:

Technical: which vulnerabilities affect us, how do we prioritize fixes, how do we test them?
Organizational: who does what when an update lands, and how do updates flow through pipelines?

Without both, maintenance lacks punch.

HTL, university—or something else entirely? Why paths can be varied

Akgül doesn’t pose his trajectory as a template. The core message: “The most important thing is being interested in solving problems.” Whoever brings that intent can find multiple on-ramps into software development.

In his telling, HTL and university become a plea for practice and repetition. From our perspective, that humility about one’s own path is valuable: it encourages people to accept their starting point and aim their energy at craft and feedback loops.

From misunderstanding to role clarity: Lead Developer instead of Project Manager

That Akgül first had “project manager” in mind and later recognized it was “actually lead developer” is instructive: role boundaries are fuzzy early on. His resolution runs through the nature of the work: with deep technical understanding and responsibility in every phase, you end up in a lead role where communication, quality, and maintenance converge.

It’s a good antidote to the notion that leadership in code-heavy fields is mostly planning and reporting. In his picture, the lead stands in the midst of the technical process—with a focus on people, decisions, and flow.

A line that sticks: “It doesn’t really ever get boring”

He summarizes the role succinctly: “It doesn’t really ever get boring.” That’s not a platitude—it’s the natural outcome of his responsibilities: concept, development, maintenance; technology choices, team composition, reviews; currency, security, accountability. This constant movement between detail and big picture keeps the role alive.

Conclusion: A clear, practical blueprint for growing into a lead

From “Oktay Akgül, Lead Developer bei enjoy IT” (Speaker: Oktay Akgül, Company: enjoy IT GmbH), we take away a blueprint that avoids buzzwords:

Curiosity and numerical intuition can be a great start—but action is what counts.
Choose languages deliberately, learn concepts deeply, transfer them broadly.
Build, host, secure—end-to-end responsibility trains a lead’s mindset.
Remove obstacles: access, docs, pipelines—so that development is not “difficult.”
Keep maintenance and security front and center: currency is part of quality.
Lead through communication—across concept, development, and operations.

This blend—focus, practice, responsibility—captures the path Akgül describes. Follow it, and you won’t only build software. You’ll build the ability to enable teams, safeguard quality, and keep systems healthy for the long run. And, in his words, it “doesn’t really ever get boring.”

More Dev Stories