enjoy IT GmbH

Etablierte Firma

Alle Videos anzeigen

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.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

Im Talk "Oktay Akgül, Lead Developer bei enjoy IT" schildert Speaker Oktay Akgül seinen Weg von der HTL Leonding über Bachelor und Master an der JKU Linz zum Backend-Schwerpunkt und zur Rolle als Lead Developer, die er anfangs mit Projektmanagement verwechselt hatte. Er beschreibt, wie seine Arbeit die gesamte Software-Evolution abdeckt – von Technologie- und Architekturentscheidungen über Teamzuschnitt, Reviews, Prozesse und Pipelines bis zu Wartung und Security – und wie zentral dabei Kommunikation ist. Sein Rat: mit einer Sprache starten (bei ihm Java/C#), viel in eigenen Projekten üben, Konzepte statt Syntax verinnerlichen und Apps/Websites auch selbst hosten und absichern.

Vom HTL-Start zum Lead Developer: Was wir aus „Oktay Akgül, Lead Developer bei enjoy IT“ für die Backend-Karriere lernen

Ein persönlicher Weg in die Softwareentwicklung – beobachtet aus der DevJobs.at-Redaktion

In der Session „Oktay Akgül, Lead Developer bei enjoy IT“ (Speaker: Oktay Akgül, Company: enjoy IT GmbH) erleben wir eine Entwicklung, die viele angehende Entwicklerinnen und Entwickler anspricht: Der Start mit Neugier für Technik, das schrittweise Hineinwachsen in Programmiersprachen, ein wissenschaftlicher Unterbau an der Universität – und schließlich die bewusste Entscheidung, Software zu bauen und Verantwortung als Lead Developer zu übernehmen.

Was uns an diesem Gespräch besonders hängen bleibt, ist die Bodenständigkeit der Botschaften. Keine Überhöhung von Tools, kein Mythos „geborenes Talent“ – stattdessen pragmatische Einsichten: „Programmieren ist etwas für mich“, sagt er, nachdem er in der HTL mit Java und C# begonnen hatte. Und später betont er: Man müsse „einfach machen“, Apps oder Websites bauen, Dinge verwerfen, reduzieren, sich auf wenige Sprachen fokussieren und die Grundkonzepte verstehen, um sie in andere Sprachen übertragen zu können.

Diese Story ist nicht nur ein Karriereporträt. Sie ist eine Anleitung dafür, wie man das eigene Handwerk aufbaut, wie man als Lead Engineer nicht nur Code, sondern auch Menschen, Prozesse und Qualität im Blick behält – und warum Softwareentwicklung ein endloser Lernpfad bleibt, der nie langweilig wird.

Frühes Interesse: Technik, Zahlen, Mathematik – und die erste Begegnung mit Code

Oktay Akgül beschreibt seinen Einstieg ohne Pathos: Er wählte die Fachrichtung Informatik an der HTL in Leonding, obwohl ihm „nicht wirklich klar [war], was Programmieren ist oder was wirklich auf [ihn] zukommt“. Entscheidend war das Interesse an Technik, das Basteln an Laptops und PCs, die Faszination für kleine Technik-Gadgets und eine Vorliebe für Zahlen und Mathematik.

Schon dieser Anfang zeigt etwas Grundsätzliches, das wir oft beobachten: Der Motor ist Neugier, nicht Perfektion. Wer gern tüftelt und Muster in Problemen erkennt, findet einen natürlichen Zugang zur Softwareentwicklung. Als in der HTL Java und C# als „Einstiegssprachen“ auf dem Lehrplan standen, war das für ihn ein Aha-Moment: Er merkte, dass er mit Programmieren Probleme lösen kann – strukturiert, reproduzierbar, nachvollziehbar.

„Programmieren ist etwas für mich… Da kannst du Probleme lösen und die musst du mithilfe der Programmierung lösen.“

Für viele beginnt es genau hier: Ein Sprach- und Konzept-„Vokabular“ wächst zusammen mit dem Gefühl, mit Code greifbare Ergebnisse zu schaffen. Diese frühe Bestätigung wurde für Akgül zum Kompass.

Universität und Vertiefung: Vom Interesse zur bewussten Berufswahl

Nach der HTL folgte für ihn der formale nächste Schritt: Bachelorstudium Informatik, anschließend der Master in Computer Science an der JKU Linz. Die Universität war mehr als nur ein Titel; sie ermöglichte es, zu üben, zu vertiefen und eine bewusste Entscheidung zu treffen:

Zielschärfung: „Ich will Software bauen.“
Architektur-Blick: „Ich will wissen, von Start auf, wie entsteht Software, mit welchen Sprachen und Frameworks kann man das ideal aufsetzen.“
Fokuswahl: Seitdem blieb er „in der Welt der Backend-Systeme“.

Wir lesen in dieser Passage drei Dinge heraus: Erstens, Lernen ist ein Tun – gerade an der Uni, wo Praxisanteile und Abschlussarbeiten (in seinem Fall: viel Übung im Rahmen des Abschlusses) den Unterschied machen. Zweitens, Spezialisierung entsteht aus dem, was einen fesselt; für ihn sind es Backend-Systeme. Drittens, ein Masterprogramm kann die innere Entscheidung „Ich will Software bauen“ schärfen und technisch fundieren.

Berufsbild geklärt: Vom anfänglichen Missverständnis zum klaren Rollenbild

„Früher habe ich mir gedacht, ich will eigentlich Projektmanager werden. Ich habe aber nicht gewusst, dass es eigentlich Lead Developer ist.“ Dieser Satz bringt ein häufiges Missverständnis auf den Punkt. Projektmanager und Lead Developer sind nicht austauschbar. Für Akgül war entscheidend: Wer sich technisch „schon gut auskennt“, bewegt sich „mehr in die Richtung“ Lead.

Das spiegelt sich in seinem Alltag: „Ich bin jetzt nicht an einen Computer gefesselt den ganzen Tag, ganz im Gegenteil. Ich muss sehr viel kommunizieren.“ Lead Engineer bedeutet für ihn, an „der Evolution einer Software in jedem Schritt“ beteiligt zu sein – von der Konzeption über Entwicklung bis hin zur Wartung.

Für uns wird hier klar: Führung in der Technik ist eine Doppelbewegung – tief genug im Code, um Qualität und Architektur zu beurteilen, und gleichzeitig nahe genug am Team und den Stakeholdern, um Entscheidungen, Prioritäten und Rahmenbedingungen zu orchestrieren.

Phase 1: Konzeption – Technologien, Widersprüche, Drittsysteme, Teamaufstellung

Wenn Akgül die Konzeption beschreibt, wird der Rahmen des Lead-Workflows deutlich. Es geht um Fragen wie:

„Welche Technologien verwenden wir für die Anforderungen?“
„Gibt es Widersprüche in der Spezifikation, die man nur mal klären muss?“
„Welche Leute zieht man heran?“
„Welche Drittsysteme muss man anbinden?“
„Wie nutzt man die Stärken und Schwächen der Teammitglieder?“

Diese Fragen markieren ein Set an Verantwortlichkeiten, das wir in der Praxis als unterschätzt erleben. Wer Technologieentscheidungen trifft, trifft auch Entscheidungen über Komplexität, Wartungsdruck und Teamdynamik. Wer Spezifikationswidersprüche früh identifiziert, spart Entwicklungsteams schmerzhafte Rewrites. Wer Teamstärken kennt, setzt Menschen so ein, dass sie wirken können.

Konzeptionelle Checkliste für Lead Developer (angelehnt an Akgüls Aussagen)

Anforderungen in Technologieentscheidungen übersetzen: Passt die Sprache/das Framework zur Problemklasse?
Spezifikationskonflikte früh klären: Wo sind Annahmen unvollständig oder widersprüchlich?
Drittsysteme einplanen: Welche Schnittstellen, welche Abhängigkeiten, welche Risiken?
Teamzuschnitt prüfen: Wer übernimmt welche Aufgabe – wo liegen Stärken, wo Lernfelder?
Pfad zur Wartbarkeit denken: Wie halten wir das System später aktuell und sicher?

Phase 2: Entwicklung – Qualität, Code Reviews, Prozesse und Pipelines

In der Entwicklungsphase benennt Akgül Handgriffe, die in jeder professionellen Codebasis unverzichtbar sind:

„Feedback geben“ und „Code Reviews durchführen“
„Schauen, dass die Qualität passt“
„Prozesse“ und „Pipelines“ so gestalten, dass Entwickeln nicht schwer fällt
„Alle Probleme beseitigen“ – fehlende Zugriffe, fehlende Dokumentationen beschaffen

Was uns beeindruckt: Die Betonung der Beseitigung von Reibung. „Es darf jetzt für einen Entwickler nicht schwierig sein, dass man entwickelt.“ Diese Haltung ist nicht nur menschlich, sie ist auch wirtschaftlich: Jede Entsperrung von Zugängen, jede geklärte Doku, jede funktionierende Pipeline beschleunigt Wertschöpfung.

Entwicklungs-Backlog für Leads (aus Akgüls Punktesammlung abgeleitet)

Code-Review-Routinen etablieren und leben.
Metriken und Qualitätsansprüche klar kommunizieren (ohne überzuadministrieren).
Continuous-Integration-Pipelines so aufsetzen, dass Feedback schnell ist und Deployments verlässlich sind.
Reibung erkennen und sofort adressieren: Zugänge, Doku, Testdaten, Umgebungen.
Kommunikationskanäle pflegen: Feedback-Loops zwischen Devs, Lead, ggf. Fachbereichen.

Phase 3: Betrieb und Wartung – am aktuellen Stand bleiben, Sicherheitslücken schließen

„Wie wird das Ganze gewartet?“ Diese Frage begleitet jede technische Entscheidung. Akgül formuliert es knapp und vollständig: „Man muss bei jeder Software, bei jeder Programmiersprache, bei jedem Framework am aktuellen Stand sein. Gibt es Sicherheitslücken, die man beheben muss? Wer behebt die?“

Darin steckt ein klarer Wartungsauftrag:

Aktualität: Versionsstände und Framework-Updates beobachten und einplanen.
Sicherheit: Vulnerabilities identifizieren, priorisieren, fixen – inklusive Verantwortlichkeiten.
Verantwortungsübergänge: Wer macht was, wenn ein Security-Update reinkommt?

Wir nehmen hier eine DevOps-nahe Haltung wahr: Verantwortung endet nicht beim Merge. Betrieb, Pflege und Sicherheit sind Teil der Lieferverantwortung eines Teams – und ein Lead Developer hält diese Fäden zusammen.

Kein Einheitsweg: Interesse, Praxis und fokussiertes Lernen als roter Faden

Akgül sagt deutlich, dass es „nicht den idealtypischen Verlauf“ gibt: Niemand muss zwingend HTL und Uni machen. Entscheidend ist, „interessiert [zu] sein, Probleme lösen zu wollen mit den Skills, die man erarbeitet“.

Diese Skills beschreibt er erstaunlich konkret:

„Sich eine Programmiersprache auszuwählen“, mit der man vertraut wird
„Im Rahmen des Abschlusses“ oder privat „sehr viel üben“
„Eine App bauen, eine Website bauen“ – und auch Dinge verwerfen
„Nicht zu viel auf einmal“ probieren, sondern „auf ein paar Programmiersprachen spezialisieren“
„Grundkonzepte kennengelernt“ haben: Diese lassen sich in jede Sprache übertragen; die Syntax ändert sich, die Prinzipien bleiben
Mit „sehr vielen Frameworks in Kontakt“ kommen und „sehr viel selber aufsetzen“
Nicht nur programmieren, sondern auch „hosten“, „Server absichern“, „Webserver absichern“
„Schritt für Schritt“ arbeiten und „in jedem Level von der Entwicklung“ etwas gemacht haben

„Man muss einfach machen… und das Wichtigste ist, nicht zu viel auf einmal probieren.“

Aus Sicht von DevJobs.at ist das die Essenz eines nachhaltigen Lernpfads: fokussiert, praxisnah, mit Blick auf Ende-zu-Ende-Verantwortung. Wer Anwendungen nicht nur baut, sondern auch laufen lässt und absichert, schließt die Feedbackschleife, die ein Lead später steuern muss.

Die Backend-Entscheidung: Warum dieser Fokus Wirkung entfaltet

Akgül ist „seitdem in der Welt der Backend-Systeme geblieben“. Das erklärt er nicht mit großen Worten; es ist eine Konsequenz aus dem Wunsch, „Software zu bauen“ und die Entstehung vom Start bis zum Ziel zu verstehen. Backend bedeutet Datenflüsse, Integrationen, Drittsysteme – genau jene Aspekte, die er in der Konzeption anspricht.

Für viele Karrierepfade ist diese Fokussierung ein Beschleuniger: Wer Schnittstellen, Persistenz, Skalierung und Wartung denkt, erkennt Abhängigkeiten früh und kann Qualitätsvorgaben sinnvoll priorisieren. Das wirkt in allen Phasen, die Akgül nennt: von Technologie-Choices über Code Reviews bis hin zur Security-Pflege.

Kommunikation als Kernkompetenz: Führen ohne „an den Computer gefesselt“ zu sein

Ein Satz sticht heraus: „Ich bin jetzt nicht an einen Computer gefesselt den ganzen Tag… Ich muss sehr viel kommunizieren.“ Das trifft den Kern des Rollenwechsels vom Individual Contributor zum Lead Developer. Kommunikation ist hier kein Beiwerk, sondern Werkzeug.

In der Konzeption klärt Kommunikation Widersprüche und Prioritäten.
In der Entwicklung kanalisiert sie Feedback, Reviews, Prozesse.
In der Wartung sorgt sie für klare Zuständigkeiten.

So wird Führung sichtbar: als koordiniertes Herstellen von Klarheit. Codekompetenz bleibt Fundament; Wirksamkeit entsteht durch Verständigung – mit Entwicklern, Stakeholdern, Schnittstellenpartnern.

Praktische Leitlinien für angehende Lead Developer (aus Akgüls Story abgeleitet)

Ohne neue Fakten zu erfinden, lässt sich aus den Aussagen des Speakers ein pragmatisches Set an Leitlinien destillieren:

Wähle bewusst 1–2 Sprachen als Kern und lerne die Konzepte tief genug, um sie in andere Sprachen zu übertragen.
Baue Dinge. Apps, Websites – und verwerfe auch wieder. Tun statt nur konsumieren.
Denke Ende-zu-Ende: Nicht nur programmieren, sondern hosten und absichern.
Suche Reibungspunkte und entferne sie: Zugänge, Doku, Pipelines – der Flow der Entwickler zählt.
Nimm Wartung ernst: Bleib aktuell, schließe Sicherheitslücken, kläre Zuständigkeiten.
Nutze Teamstärken: Richte Aufgaben nach Stärken und Lernfeldern aus.
Erkenne Spezifikationswidersprüche früh – sie sind die Quelle vieler späterer Probleme.
Kommuniziere viel und gezielt – in jeder Phase der Software-Evolution.

Diese Punkte sind nicht spektakulär – und genau darin liegt ihre Kraft. Sie sind das tägliche Handwerk, das die Rolle tragfähig macht.

„Einfach machen“ – wie man das in den Alltag übersetzt

Akgül betont die Praxis. „Privat damit beschäftigen“, „selbst aufsetzen“, „hosten“, „absichern“ – dahinter steckt ein Lernmodus, der sich in allen Karrierestufen anwenden lässt:

Anfängerinnen und Anfänger: Eine Sprache wählen, ein Mini-Projekt starten (z. B. eine kleine Website), die Anwendung deployen und bewusst absichern.
Fortgeschrittene: Einen zweiten Tech-Stack parallel über die Konzepte erschließen; die Unterschiede in Syntax und Idiomen beobachten, ohne sich zu verzetteln.
Leads in spe: Pipeline- und Prozesswissen aufbauen; Code Reviews moderieren; Drittsysteme einbinden; Zuständigkeiten klären.

Das Entscheidende ist, nicht „zu viel auf einmal“ zu probieren. Fokus erzeugt Tiefe – und Tiefe erzeugt Übertragbarkeit.

Qualität ist Teamleistung: Code Reviews, Prozesse, Pipelines

Wenn Akgül über Qualität spricht, verortet er sie im Teamprozess: Reviews, Feedback, funktionierende Pipelines. Diese Einsicht lohnt sich: Qualität entsteht nicht nur im Editor, sondern im Zusammenspiel – durch Standards, die verstanden und gelebt werden.

In der Praxis heißt das:

Review-Kultur: Reviews sind Dialoge, keine Gatekeeping-Rituale.
Dokumentation: Fehlende Doku ist ein Bug im Prozess – zu schließen wie jeder andere.
Pipeline-Stabilität: Ohne zuverlässige Pipelines werden Qualitätssignale verpuffen.

Diese drei Bausteine fügen sich in Akgüls Bild eines Lead Engineers, der Hindernisse aus dem Weg räumt, statt sie zu verwalten.

Sicherheit und Aktualität: Der unsichtbare Teil der Lieferqualität

„Gibt es Sicherheitslücken, die man beheben muss? Wer behebt die?“ Dieser Doppelsatz zeigt, wie Akgül Sicherheit versteht: als verbindliche Aufgabe mit klarer Verantwortlichkeit. Gerade hier entscheidet sich, ob ein Team zuverlässig liefert. Sicherheits- und Versionspflege sind keine Randaufgaben; sie sind integraler Teil der Evolution einer Software.

Für Leads bedeutet das, zwei Perspektiven gleichzeitig zu halten:

Technisch: Welche Lücken betreffen uns, wie priorisieren wir Fixes, wie testen wir?
Organisatorisch: Wer kümmert sich konkret, wie laufen Updates durch die Pipelines?

Ohne dieses Doppel hat Wartung keine Schlagkraft.

HTL, Uni – oder ganz anders? Warum Wege vielfältig sein dürfen

Akgül will seinen Weg nicht als Schablone verstanden wissen. Die Kernbotschaft lautet: „Das Wichtigste ist, man muss einfach interessiert sein, Probleme lösen zu wollen.“ Wer das mitbringt, kann über unterschiedliche Pfade in die Softwareentwicklung finden.

Dass er selbst HTL und Uni gegangen ist, wird in seinen Aussagen vor allem zu einem Plädoyer für Übung und Praxis. Für uns als Redaktion ist gerade diese Demut vor dem eigenen Weg wertvoll: Sie ermutigt, die eigenen Startbedingungen anzunehmen und den Fokus auf Handwerk und Lernschleifen zu richten.

Vom Missverständnis zum Selbstbild: Lead Developer statt Projektmanager

Dass Akgül zunächst „Projektmanager“ im Blick hatte und später erkannte, dass es „eigentlich Lead Developer“ war, zeigt: Rollenbilder sind unscharf, vor allem zu Beginn. Seine Klärung verläuft über die Tätigkeit: Wer die Technik tief versteht und in jeder Phase Verantwortung übernimmt, findet sich in einer Lead-Rolle wieder, in der Kommunikation, Qualität und Wartung zusammenlaufen.

Es ist ein gutes Gegenbild zu der Vorstellung, Führung am Codeende würde nur aus Planung und Reporting bestehen. In seiner Beschreibung steht der Lead mitten im technischen Prozess – aber mit Fokus auf Menschen, Entscheidungen und Flow.

Ein Satz, der bleibt: „Es wird eigentlich nie wirklich langweilig“

Die Summe seiner Rolle fasst Akgül so: „Es wird eigentlich nie wirklich langweilig.“ Das ist keine Floskel, sondern die logische Folge seiner Aufgaben: Konzeption, Entwicklung, Wartung; Technologieentscheidungen, Teamaufstellung, Reviews; Aktualität, Sicherheit, Zuständigkeiten. Wer so arbeitet, bewegt sich ständig zwischen Detailtiefe und Gesamtbild – eine Dynamik, die die Rolle lebendig hält.

Fazit: Eine klare, praxisnahe Blaupause für den Weg zum Lead

Aus der Session „Oktay Akgül, Lead Developer bei enjoy IT“ (Speaker: Oktay Akgül, Company: enjoy IT GmbH) nehmen wir ein Leitbild mit, das ohne Buzzwords auskommt:

Neugier und Zahlenaffinität können ein sehr guter Start sein – aber entscheidend ist das Tun.
Wähle Sprachen bewusst, lerne Konzepte tief, übertrage sie breit.
Baue, hoste, sichere – Ende-zu-Ende-Verantwortung schult das Denken eines Leads.
Räume Hindernisse aus dem Weg: Zugänge, Doku, Pipelines – damit Entwicklung nicht „schwierig“ ist.
Halte Wartung und Sicherheit präsent: Aktualität ist Teil der Qualität.
Führe über Kommunikation: in Konzeption, Entwicklung und Betrieb.

Genau diese Mischung – Fokus, Praxis, Verantwortung – zeichnet den Weg aus, den Akgül beschreibt. Wer sich daran orientiert, baut nicht nur Software. Er oder sie baut die Fähigkeit, Teams zu befähigen, Qualität zu sichern und Systeme langfristig tragfähig zu halten. Und das ist, in seinen Worten, ein Job, der „nie wirklich langweilig“ wird.

Weitere Dev Stories