Automation by Design: Inside ByteSource Technology Consulting GmbH’s Cloud Team with AWS, Kubernetes, and DevOps – Insights from “Manuel Lindner, Senior Consultant bei ByteSource”

What this session revealed

In the session “Manuel Lindner, Senior Consultant bei ByteSource” (Speaker: Manuel Lindner, Company: ByteSource Technology Consulting GmbH), we got a grounded, real-world look at a Cloud and DevOps team that doesn’t just talk about automation—it practices it end to end. The guiding idea is simple: customer focus, pragmatism, and continuous learning, with technology choices backed by firsthand use rather than slideware.

Right from the start, Lindner frames the organization clearly: ByteSource is customer-oriented and does not sell its own product. Work happens within client projects, sometimes as a small embedded team and sometimes as a single consultant, depending on client size and topic. The cloud team centers on AWS, Kubernetes, containerization, and everything under DevOps and automation. Lindner captures the engineering mindset with a candid line:

That “laziness” is classic engineering virtue: standardize the right work once so that quality goes up, errors go down, and delivery speeds up—sustainably.

Team structure: Three streams, one cloud-centric engine

ByteSource is organized into three teams company-wide. Lindner works in the cloud team focused on AWS, Kubernetes, containerization, and DevOps/automation. A second team covers another topic area, and a third team places a strong focus on software development (while not doing pure software development alone). For the culture and leadership lens we care about here, the cloud team stands out:

• Scale and growth: Nearly 20 people today, up from about ten some three to five years ago—a steady climb.
• Composition: Roughly 60–70% internal staff, complemented by external colleagues, assembled per project.
• Leadership in practice: Two people—Lindner among them—handle the team’s leading activities: organizing, coordinating, and taking care of onboarding when new hires join.

It’s a pragmatic setup befitting a consulting company: minimal overhead, leadership close to the work, and structure aligned to delivery.

Client-first, product-agnostic delivery

There is no internal product to sell. Everyone works in client settings—sometimes solo, sometimes in a small group—tuned to the client’s size and topic. This has tangible implications for day-to-day engineering:

• Success is measured by client outcomes, not by feature velocity of an in-house platform.
• Tooling follows the problem, not the hype. Even in CI/CD and Infrastructure as Code, flexibility beats dogma.
• Team shape remains fluid. If you enjoy stakeholder-facing roles, you can take that on; if you prefer to operate behind the scenes, there’s room for that as well.

Engineering ethos: “Do it once, do it right—then automate it”

Automation, for this team, is a mindset rather than a checklist. The goal is not to automate for its own sake, but to do the right thing once—properly—and then let the system run with confidence. This translates into concrete practice:

• Infrastructure as Code by default: Infrastructure is expressed in code—repeatable, reviewable, and version-controlled.
• CI/CD as the accelerator: Changes are tested and deployed automatically, increasing both velocity and safety.
• Dogfooding: The team uses technologies internally before recommending them, building credibility through real experience.

Technology focus: AWS, Kubernetes, IaC, and CI/CD

AWS as the cloud backbone

The cloud focus is clearly on AWS. Lindner notes they work together with AWS and that the cloud team treats this domain as its core strength. For candidates, that means deep exposure to AWS workloads, architectures, and services—applied both in client projects and in internal use.

Kubernetes for container orchestration—with portability as a key argument

Kubernetes has steadily grown in importance for the team in recent years. Lindner underlines two points clients appreciate:

• Flexibility: Kubernetes isn’t locked to a specific cloud provider. Workloads can run on-premises or move between providers as needed.
• A powerful feature set: Kubernetes brings robust capabilities that modern platforms and production environments rely on.

Together, portability and capability make a potent case in consulting: solutions can be shaped without long-term provider lock-in.

Infrastructure as Code: Terraform, Ansible, CDK, and more

To automate for reliability and repeatability, the team leans on Infrastructure as Code—tech-agnostic and client-aligned:

• Terraform
• Ansible
• AWS CDK (Cloud Development Kit)
• Additional tools as appropriate to the client’s context

Lindner stresses flexibility: they won’t force clients into new toolchains if suitable tools are already in place. That minimizes change fatigue and improves adoption.

CI/CD in practice: GitHub, Bamboo, Jenkins

On CI/CD, the team uses different tools depending on the environment and what the client has in place:

• GitHub
• Bamboo by Atlassian
• Jenkins—considered “a bit older” by some, but still very widely used

The throughline is pragmatic: what exists, what works, and what moves the project forward.

Self-organization in action: Hiring and onboarding from within the team

One of the most telling cultural markers: there isn’t a separate HR department yet. The team organizes hiring and onboarding themselves—with clear, human-centered rituals.

The hiring flow

• Initial contact via the website.
• A job interview—“thankfully in person again.” The focus: get to know each other, sense the shared wavelength.
• A deeper dive into topics aligned to the candidate’s strengths.
• Mapping interests and preferences: Which technologies spark interest? More client-facing or more behind-the-scenes?
• An internal decision in one to three days.
• Ideally, a quick offer and a prompt start.

This is geared toward fit—technically and in working style—so that projects can be staffed and planned with intent.

Onboarding: Start close, then open up

Onboarding intentionally begins on-site:

• First day at the office: meet people, learn processes, get to know “how we work day to day.” Equipment is handed over.
• Fast support: in-person, five-minute problem-solving beats remote friction.
• Once things “click,” home office is “no issue at all”—self-organized and always coordinated with the client.

It’s a two-step model: proximity accelerates ramp-up; trust underpins flexible work.

Working with clients: Variable, pragmatic, outcome-oriented

Lindner describes engagement patterns that vary with client size and topic—sometimes a single consultant, sometimes a small team. What determines the shape:

• The client’s scale and maturity
• The actual domain need (cloud infrastructure, Kubernetes platform, CI/CD setup, automation, etc.)
• The right role mix (more stakeholder work vs. deeper engineering behind the scenes)

Because the team is broad, roles can be combined—precisely where those interest/preference discussions in the interview pay off.

Dogfooding as a culture marker: Credibility through owned experience

A recurring theme is credibility. By recommending what they themselves use, the team:

• Gains experiential knowledge—talking from lessons learned, not hypotheticals
• Builds a trust foundation with clients—“this is how we do it, and it has worked for us”

In consulting, this de-risks decisions and accelerates adoption.

Leadership and responsibility: Little formalism, lots of ownership

Team leadership—shared by two people including Lindner—acts as an enabler: organizing, onboarding, and keeping communication clear. What’s striking is what Lindner doesn’t emphasize: heavy hierarchy. Instead, the examples suggest a culture where ownership drives work:

• Team members take responsibility in client settings.
• Decisions follow context and technical rationale.
• Self-organization fills the gap where a classic HR department (for now) doesn’t exist.

For seasoned engineers, that’s compelling: real autonomy close to the work.

Why this environment appeals to tech talent

From the session, a set of concrete reasons emerges for engineers focused on cloud, DevOps, and automation.

• AWS focus plus container expertise: If you want to weave modern cloud architecture with Kubernetes, you’ll do exactly that—and in production-grade client projects.
• Automation as principle: Infrastructure as Code and CI/CD aren’t side quests; they’re how delivery happens.
• Tool flexibility: Terraform, Ansible, CDK; GitHub, Bamboo, Jenkins—what matters is fit. That sharpens judgment and broadens skill.
• Direct client impact: Rather than polishing a single product, you’ll solve varied, real problems—solo or in a tight-knit team—where your work is immediately used.
• Learning via dogfooding: Try internally, then apply in the field—building resilient best practices.
• Self-organized working: From hiring to onboarding, the culture distributes responsibility rather than centralizing it.
• A growing team: From about ten to nearly twenty—growth opens doors to shape and build.
• Hybrid flexibility after ramp-up: Start together to gain speed, then work flexibly—always aligned with the client.

Who will thrive here

• Cloud/DevOps engineers who like thinking end-to-end: IaC modules, CI/CD pipelines, and Kubernetes deployment strategies.
• Consultants who enjoy client-facing work—or engineers who prefer to craft reliable systems behind the scenes. Lindner indicates both profiles have a place.
• Pragmatists at heart: “What do we have? What works? What should we automate next?”
• Team players who welcome responsibility and value quick, direct collaboration.

Hiring and onboarding: What candidates can expect

Lindner’s description amounts to a predictable, respectful candidate journey:

1. Reach out via the homepage—simple first contact.
2. In-person interview—get to know each other, test cultural fit, and dive into your technical focus.
3. A fast internal decision (one to three days)—timely, transparent feedback.
4. First day on-site—meet people, processes, and get equipment; unblock issues in “five minutes” instead of long remote loops.
5. Once you’ve settled—home office is open, self-organized, and client-aligned.

It’s a flow that respects time and focus—vital in project-based organizations.

Quality through automation: The practical blueprint

“Do it right once” implies discipline in implementation: clean IaC structures, reusable modules, robust pipelines, and sensible test and rollout mechanics. Lindner’s team pairs those principles with tool openness. The result: a delivery practice that’s realistic and effective.

• Infrastructure is modeled and versioned as code.
• Deployments run via established CI/CD pipelines.
• Kubernetes is used where portability and features add up.
• Tools are selected to fit the client’s needs—rather than prescribed in the abstract.

That forms a DevOps culture built not on buzzwords but on repeatable quality—the currency of credible consulting.

The importance of early proximity: Speed as a social effect

Many organizations let new joiners wander through scattered docs. Lindner’s team deliberately counters that with early proximity. Knowing people and processes—and solving questions in minutes—saves energy for the core mission: building systems, improving automation, and moving client outcomes.

Once that base is in place, the second pillar kicks in: trust. Home office becomes “no issue at all” so long as it fits the client’s arrangement. It’s a best-of-both-worlds model: accelerate ramp-up, then empower flexible work.

A realistic view of tooling: Jenkins still matters

A telling detail: not every environment is greenfield. Lindner explicitly mentions Jenkins—as “a bit older” in some minds but “still very, very often” used. That honesty matters. It hones judgment: modern engineering must solve for brownfield and greenfield alike—both demand care, communication, and automation skill.

Conclusion: A home for cloud automation builders

“Manuel Lindner, Senior Consultant bei ByteSource” paints a picture many engineers will recognize as aspirational and grounded: a growing cloud team that treats automation as craft, validates tooling internally, and applies it with clients—using AWS, Kubernetes, Infrastructure as Code, and hands-on CI/CD. The organization is lean, self-organized, and client-centered. Hiring and onboarding are personal, fast, and fit-focused. And “laziness” is a commitment to quality: do it right once—then let it run.

If you’re seeking ownership in projects, flexibility in tools, and proximity to real problems and solutions, the ByteSource Technology Consulting GmbH cloud team offers an environment where engineering isn’t administrated—it’s shaped.

• 

  

  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.

  Watch now