Automatisieren aus Prinzip: Ein Blick in das Cloud-Team der ByteSource Technology Consulting GmbH mit AWS, Kubernetes und DevOps – Insights aus „Manuel Lindner, Senior Consultant bei ByteSource“

Worum es in dieser Session ging

In der Session „Manuel Lindner, Senior Consultant bei ByteSource“ (Speaker: Manuel Lindner, Company: ByteSource Technology Consulting GmbH) bekamen wir einen präzisen, praxisnahen Einblick in die Arbeitsweise eines Cloud- und DevOps-Teams, das Automatisierung nicht nur predigt, sondern lebt. Die Leitidee ist klar: Kundennähe, Pragmatismus und kontinuierliches Lernen – und zwar so, dass Technologieentscheidungen durch echte Erfahrung („wir setzen es selbst ein“) und nicht nur durch Folien entstehen.

Gleich zu Beginn ordnet Lindner die Organisation ein: ByteSource ist kundenorientiert, ohne eigenes Produkt. Projekte werden in enger Zusammenarbeit mit Auftraggebern umgesetzt, mal im kleinen Team, mal als einzelne Expert:innen – abhängig von Größe und Themenlage beim Kunden. Das Cloud-Team konzentriert sich auf AWS, Kubernetes und alles, was unter DevOps und Automatisierung fällt. Die Haltung dazu bringt Lindner sympathisch auf den Punkt:

Diese „Faulheit“ ist in Wahrheit eine Ingenieurs-Tugend: Arbeitsschritte so durchdacht zu standardisieren, dass Qualität steigt, Fehler sinken und die Geschwindigkeit zunimmt – dauerhaft.

Teamstruktur: Drei Schwerpunkte, ein starkes Cloud-Team

ByteSource ist prinzipiell in drei Teams organisiert. Lindner selbst arbeitet im Cloud-Team mit Fokus auf AWS, Kubernetes, Containerisierung und DevOps/Automatisierung. Ein zweites Team betreut ein weiteres Themenfeld, und ein drittes Team legt einen Schwerpunkt auf Softwareentwicklung (ohne ausschließlich reine Softwareentwicklung zu machen). Für unseren Blick auf Engineering-Kultur und Führung ist insbesondere die Funktionsweise des Cloud-Teams relevant:

• Größe und Wachstum: Das Team umfasst nahezu 20 Personen und ist in den letzten Jahren von rund zehn Mitarbeitenden deutlich gewachsen. Ein gesunder Zuwachs, der laut Lindner „stetig nach oben“ zeigt.
• Team-Mix: Etwa 60–70% sind interne Kolleg:innen, ergänzt durch externe Mitarbeitende. Die Zusammenarbeit erfolgt in projektbezogenen Formationen.
• Führung im Team: Aktuell übernehmen zwei Personen – inklusive Lindner – mehr oder weniger die führenden Tätigkeiten, also organisatorische Abstimmungen, Onboarding und das Zusammenhalten der Fäden im Projektalltag.

Die Aufstellung spiegelt eine pragmatische, kundenzentrierte Beratungsfirma wider: kein starres Organigramm, sondern eine operative Führung nahe an den Projekten.

Kundenorientierung ohne eigenes Produkt

ByteSource verkauft kein eigenes Produkt. Jede und jeder im Team arbeitet in Kundenprojekten – je nach Kontext einzeln oder im kleinen Team. Das hat mehrere Implikationen für den Engineering-Alltag:

• Der Erfolg wird am Kundennutzen gemessen – nicht am Funktionsumfang einer internen Plattform.
• Technologieauswahl folgt dem Problem, nicht dem Trend. Auch bei CI/CD-Tools oder Infrastructure-as-Code-Werkzeugen bleibt man bewusst flexibel.
• Projektkonstellation und -größe variieren. Wer gern mit Stakeholdern arbeitet, kann Kundenschnittstellen übernehmen; wer lieber „im Hintergrund“ baut, findet dafür ebenso Platz.

Engineering-Grundhaltung: „Einmal gescheit – dann automatisch“

Die wiederkehrende Leitlinie in Lindners Ausführungen ist Automatisierung als Mindset. Dabei geht es nicht um „Automatisierung um der Automatisierung willen“, sondern darum, das Richtige einmal sauber zu bauen – und danach verlässlich laufen zu lassen. Dieses Denken prägt die technische Praxis:

• Infrastructure as Code als Default: Infrastruktur wird konsequent in Code gegossen – wiederholbar, überprüfbar, versionierbar.
• CI/CD als Beschleuniger: Änderungen werden automatisiert geprüft und ausgerollt. Dadurch wird nicht nur Tempo, sondern auch Sicherheit gewonnen.
• „Dogfooding“: Bevor man etwas empfiehlt, setzt man es intern ein. So entstehen echte Erfahrungswerte, die beim Kunden Vertrauen schaffen.

Technologie-Schwerpunkte: AWS, Kubernetes, IaC und CI/CD

AWS als Cloud-Schwerpunkt

Im Cloud-Bereich liegt der Schwerpunkt klar auf AWS. Lindner beschreibt, dass man mit AWS zusammenarbeitet und das Team dort sein „Steckenpferd“ hat. Für Kandidat:innen bedeutet das: Wer in AWS-Workloads, -Architekturen und -Services tief eintauchen will, findet hier gelebte Praxis – in Kundenprojekten und im internen Einsatz.

Kubernetes als Container-Orchestrierung – mit Portabilität als Argument

Kubernetes ist in den letzten Jahren bei ByteSource „mehr und mehr geworden“. Lindner betont zwei Gründe, die Kund:innen überzeugen:

• Flexibilität: Kubernetes ist nicht auf einen Cloud-Provider festgezurrt. Workloads lassen sich – je nach Bedarf – on-premises betreiben oder zwischen Cloud-Anbietern migrieren.
• Mächtiges Feature-Set: Kubernetes bringt umfangreiche Funktionalitäten mit, die in modernen Plattformen und Produktivumgebungen zählen.

Diese Kombination aus Portabilität und Leistungsfähigkeit ist in Beratungssituationen schlagkräftig: Sie erlaubt, technische Lösungen ohne langfristige Provider-Fessel auszulegen.

Infrastructure as Code: Terraform, Ansible, CDK und Co.

Für Automatisierung und Reproduzierbarkeit setzt das Team auf Infrastructure as Code – technologieagnostisch und kundenangepasst:

• Terraform
• Ansible
• AWS CDK (Cloud Development Kit)
• Weitere Tools je nach Bedarf und Kundenkontext

Wichtig ist Lindner dabei die Flexibilität: Man zwingt Kund:innen nicht in neue Toolchains, wenn bereits passende Werkzeuge im Einsatz sind. So senkt man Umstellungsaufwand und fördert Akzeptanz.

CI/CD-Praxis: GitHub, Bamboo, Jenkins

Beim Thema CI/CD greift das Team auf unterschiedliche Tools zurück – ebenfalls fallweise und abhängig vom Setup beim Kunden:

• GitHub
• Bamboo von Atlassian
• Jenkins – von manchen als „älter“ gesehen, aber weiterhin in vielen Umgebungen verbreitet

Diese Nüchternheit („Was ist vorhanden? Was funktioniert?“) passt zur Beratungsrolle: Statt Dogmen zählt, was dem Projekt dient.

Selbstorganisation: Recruiting und Onboarding aus dem Team heraus

Eine bemerkenswerte Facette der Kultur: Es gibt noch keine eigene HR-Abteilung. Recruiting und Onboarding organisiert das Team selbst – mit klaren, menschennahen Ritualen.

So läuft die Bewerbung

• Kontaktaufnahme über die Homepage.
• Ein Bewerbungsgespräch – „Gott sei Dank wieder persönlich“. Im Fokus: Kennenlernen, gemeinsamer Austausch, ein Gefühl für die „Wellenlänge“.
• Fachliche Vertiefung je nach Schwerpunkt der Bewerberin/des Bewerbers.
• Abfrage von Präferenzen: Welche Technologien interessieren? Mehr Kundenkontakt oder lieber Hintergrundarbeit?
• Interne Entscheidungsphase von ein bis drei Tagen.
• Im besten Fall: Zusage und zeitnaher Start.

Diese Schritte folgen einem klaren Ziel: Passung. Nicht nur in der Technik, sondern im Arbeitsmodus – damit Projekte von Beginn an sinnvoll geplant und besetzt werden können.

Onboarding: Erst Nähe, dann Flexibilität

Beim Onboarding setzt ByteSource bewusst auf räumliche Nähe:

• Erster Tag im Büro: Menschen, Prozesse und Werkzeuge kennenlernen. Equipment (Laptop, Geräte) wird übergeben.
• Schnelle Hilfe: „Setzen wir uns fünf Minuten zusammen“ – Probleme lassen sich vor Ort leichter lösen als remote.
• Sobald „es sich eingeklebt hat“, ist Homeoffice kein Thema – sprich: offen und selbstorganisiert, in Absprache mit dem Kunden.

Dieser Ablauf verbindet soziale Eingewöhnung mit späterer Autonomie. Wer neu ist, hat unmittelbare Unterstützung; wer angekommen ist, gestaltet den Arbeitsalltag flexibel.

Zusammenarbeit mit Kund:innen: Variabel, pragmatisch, wirkungsorientiert

Lindner beschreibt die Zusammenarbeit als variabel – vom Einzel-Consultant bis zum kleinen Projektteam. Entscheidend sind:

• Größe und Reifegrad der Kundenorganisation
• Das konkrete Themengebiet (Cloud-Migration, Container-Plattform, CI/CD-Aufbau, Automatisierung etc.)
• Die passende Teamzusammensetzung (etwa mehr Kundenkontakt oder stärkere Technikfokussierung im Hintergrund)

Weil das Team intern breit aufgestellt ist, lassen sich Rollen kombinieren. Genau hier zahlt sich die Abfrage der individuellen Präferenzen im Bewerbungsgespräch aus: Wer gerne mit Stakeholdern moderiert, wird entsprechend eingesetzt; wer lieber Systemteile baut, arbeitet fokussiert im Maschinenraum.

Kulturmerkmal Dogfooding: Glaubwürdigkeit durch Eigenbetrieb

Ein roter Faden durch die Session ist Glaubwürdigkeit: Das Team empfiehlt Technologien, die es selbst im Einsatz hat. Dadurch entsteht eine doppelte Wirkung:

• Erfahrungswissen: Man spricht nicht über hypothetische Vor- und Nachteile, sondern über reale Lessons Learned.
• Vertrauensbasis: Kund:innen hören nicht nur „Das ist cool“, sondern „So machen wir es – und so hat es sich bewährt“.

In einer Beratungsrolle ist das Gold wert. Es reduziert Risikoängste und ermöglicht schnellere, fundiertere Entscheidungen.

Führung und Verantwortung: Wenig Formalismus, viel Ownership

Die Führungsarbeit im Cloud-Team – zu zweit getragen – ist vor allem organisatorisches Enablen: Onboarding gestalten, Projekte koordinieren, Ansprechbarkeit sichern. Auffällig ist, was Lindner nicht sagt: Es fallen keine großen Worte über Hierarchien. Stattdessen sprechen die Beispiele für eine Kultur, in der Ownership zählt:

• Teammitglieder übernehmen Verantwortung im Kundensetting.
• Entscheidungen folgen dem Projektkontext und der Fachlichkeit.
• Selbstorganisation füllt die Lücke, wo eine klassische HR-Abteilung (noch) fehlt.

Gerade für erfahrene Engineers ist das attraktiv: Gestaltungsspielraum ist kein Lippenbekenntnis, sondern gelebter Alltag.

Warum ByteSource für Tech-Talente spannend ist

Aus der Session heraus lassen sich konkrete Gründe ableiten, warum Engineers mit Cloud-, DevOps- und Automatisierungsfokus hier auf ihre Kosten kommen.

• AWS-Fokus plus Container-Know-how: Wer moderne Cloudarchitektur mit Kubernetes verbindet, trifft auf einen Alltag, in dem genau das gefragt ist – und in echten Projekten Wirkung entfaltet.
• Automatisierung als Prinzip: Infrastructure as Code und CI/CD sind nicht „Zusatzthemen“, sondern die Art, wie gearbeitet wird.
• Technologie-Flexibilität: Terraform, Ansible, CDK; GitHub, Bamboo, Jenkins – was zählt, ist der passende Fit. Das schärft Urteilskraft und Toolkompetenz.
• Direkte Kundennähe: Statt an einem Produkt zu feilen, gestaltet man in wechselnden Kontexten – allein oder im Team – Lösungen, die unmittelbar genutzt werden.
• Lernkurve durch Dogfooding: Intern ausprobieren, dann beim Kunden einsetzen – so entstehen robuste Best Practices.
• Selbstorganisiertes Arbeiten: Von Recruiting bis Onboarding zeigt sich eine Kultur, die Verantwortung verteilt und Ernst macht mit Autonomie.
• Wachsendes Team: Von zehn auf fast zwanzig – Wachstum eröffnet Chancen, mitzugestalten und aufzubauen.
• Hybrid-Work nach Onboarding: Erst gemeinsam Tempo aufnehmen, dann flexibel arbeiten – in Absprache mit dem Kunden.

Für wen diese Umgebung besonders gut passt

• Cloud/DevOps-Engineers, die gern End-to-End denken: vom IaC-Template über das CI/CD-Pipeline-Design bis zur Kubernetes-Deploy-Strategie.
• Consultants, die Kundennähe schätzen – oder Engineers, die lieber im Hintergrund zuverlässige Systeme bauen. Beide Profile können laut Lindner ihren Platz finden.
• Menschen mit Freude an Pragmatismus: „Was ist vorhanden? Was funktioniert? Was automatisieren wir als Nächstes?“
• Teamplayer, die Verantwortung mögen – auch jenseits formeller Titel – und denen kurze Wege und direkte Hilfe wichtig sind.

Recruiting und Onboarding: Was Bewerber:innen konkret erwartet

Aus Lindners Beschreibung entsteht ein klarer Ablauf, auf den man sich als Kandidat:in einstellen kann:

1. Erstkontakt über die Homepage – schnell und unkompliziert.
2. Persönliches Bewerbungsgespräch – Kennenlernen, kulturelle Passung, fachliche Vertiefung entlang deines Schwerpunkts.
3. Transparente Entscheidungszeit (ein bis drei Tage) – zügiges Feedback.
4. Start im Büro – Menschen, Prozesse, Geräte; schnelle Klärungen „in fünf Minuten“ statt langer Remote-Schleifen.
5. Sobald „es sich eingeklebt hat“ – Homeoffice ist offen, selbstorganisiert und kundenkompatibel.

Diese Schritte signalisieren Respekt vor Zeit und Fokus – und sie schaffen einen Rahmen, der gerade in projektgetriebenen Organisationen wichtig ist.

Qualität durch Automatisierung: Das praktische Leitbild

Wer „einmal gescheit“ baut, muss Exzellenz in der Umsetzung anstreben: saubere IaC-Strukturen, wiederverwendbare Module, robuste Pipelines, sinnvolle Test- und Rollout-Mechanismen. Lindners Team verbindet diese Prinzipien mit einer gesunden Tooloffenheit. Das Ergebnis ist eine realistische, wirksame Delivery-Praxis:

• Infrastruktur wird als Code modelliert und versioniert.
• Deployments laufen über etablierte CI/CD-Mechanismen.
• Kubernetes wird dort eingesetzt, wo Portabilität und Features den Ausschlag geben.
• Tools werden kundenorientiert ausgewählt – statt pauschal vorgeschrieben.

So entsteht eine DevOps-Kultur, die nicht auf Buzzwords baut, sondern auf wiederholbare Qualität. Genau das macht Beratung glaubwürdig und Outcome-orientiert.

Die Besonderheit der ersten Wochen: Nähe als Beschleuniger

In vielen Organisationen stolpern Neuzugänge über verstreute Informationen. Lindners Team setzt bewusst einen Kontrapunkt: Nähe in den ersten Tagen. Das erleichtert nicht nur den Wissenstransfer („Wer macht was? Wo liegt was?“), sondern auch das soziale Ankommen. Wenn Fragen „in fünf Minuten“ geklärt werden, bleibt Energie für das Eigentliche: Systeme aufbauen, Automatisierungen verbessern, Kundenprojekte voranbringen.

Sobald die Grundorientierung sitzt, greift die zweite Säule: Vertrauen. Homeoffice ist „überhaupt kein Thema“, solange es mit dem Kunden abgestimmt ist. Diese Kombination bietet das Beste aus beiden Welten: schneller Start – und danach selbstbestimmte Arbeitsorganisation.

Eine realistische Sicht auf Tools: Jenkins lebt weiter

Ein Detail, das in der Praxis oft untergeht: Nicht jedes Setup ist grün auf der Wiese. Lindner erwähnt explizit Jenkins – in manchem Kopf „schon ein bisschen älter“, aber in der Realität „sehr, sehr häufig“ im Einsatz. Diese Ehrlichkeit zählt. Sie schult die Urteilskraft: Moderne Engineering-Teams lösen Probleme im Bestand und auf der grünen Wiese. Beides verlangt Sorgfalt, Kommunikation und Automationskönnen.

Fazit: Ein Team für Macher:innen der Cloud-Automatisierung

Die Session „Manuel Lindner, Senior Consultant bei ByteSource“ zeigt ein Bild, das vielen Engineer-Herzen entgegenkommt: Ein wachsendes Cloud-Team, das Automatisierung als Handwerk begreift, Technologien intern erprobt und beim Kunden anwendet – mit AWS, Kubernetes, Infrastructure as Code und praxisnaher CI/CD. Die Organisation ist schlank, selbstorganisiert und kundennah. Recruiting und Onboarding sind persönlich, schnell und auf Passung bedacht. Und „Faulheit“ ist hier ein Qualitätsversprechen: einmal richtig bauen und dann laufen lassen.

Wer genau das sucht – Verantwortung im Projekt, Flexibilität bei Tools, Nähe zu echten Problemen und Lösungen – findet bei der ByteSource Technology Consulting GmbH ein Umfeld, in dem Engineering nicht verwaltet, sondern gestaltet wird.

• 

  

  Jörg Herzinger, Cloud Consultant bei ByteSource

  Jörg Herzinger von ByteSource spricht im Interview über seine Anfänge im Studium, auf was der Fokus im Cloud Consulting liegt und wie man am besten in dieses Gebiet einsteigen kann.

  Jetzt ansehen