Get in touch with us
We at accompio will be happy to help you.
06.10.2026
Kubernetes, CI/CD pipelines, cloud-native platforms: When companies talk about DevOps, the tools are usually at the center of the discussion. But a modern technology stack alone does not make a DevOps organization. There are companies with the best pipelines who still need three months for a release – and others who deliver significantly faster with virtual machines and a monolith.
The difference lies not in the technology but in the way of working. DevOps is primarily a culture of collaboration, quick feedback, and continuous improvement. The tools are the result of this way of working – not their starting point.
In the current video, Bastien Reinhardt, Senior IT Consultant at accompio, talks about why successful DevOps strategies go beyond tools and technologies.
DevOps is often equated with Kubernetes, CI/CD, and cloud-native technologies. From Bastien Reinhardt’s perspective, that is too narrow a view. DevOps emerged because teams wanted to work differently: faster, more closely coordinated, and with shared responsibility for the outcome. It was from this idea that the familiar tools were first developed.
Today, the order is often reversed. Companies first implement the tools and expect the way they work to automatically change as a result. In the worst case, the teams are forced into a new way of working through the tools without their understanding or consent.
„These tools are ultimately just the result of a working method.“
Bastien Reinhardt, Senior IT Consultant at accompio
The „DevOps Handbook“ (The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois and John Willis) describes three key principles: workflow (flow), rapid feedback, and continuous learning and improvement. Nevertheless, in many companies, the focus is primarily on the tools themselves.
The reason is simple: tools are visible. Anyone who introduces Kubernetes has clear responsibilities; they see that the platform is being operated and used, and can even measure how many workloads are already running on it. A changed way of working, on the other hand, cannot be so easily demonstrated.
A comparison from practice shows how this actually affects things:
The release duration is a measurable metric that tells more about a company’s DevOps maturity than the list of tools used.
Many companies still operate with traditionally separate development, operations, and infrastructure teams. Especially large organizations are optimized for reliability and are highly accustomed to their existing way of working. For many employees, therefore, a change feels like a loss of control over their own department.
„The hurdles are actually almost never technical.“
Bastien Reinhardt, Senior IT Consultant at accompio
The silos are each optimized for their own goal: the development teams to deliver features as quickly as possible. The operations team to maintain high availability. Both goals are legitimate, but they often conflict. DevOps requires working across departments – and this very change is difficult at first.
This sentence directly stands in the way of successful DevOps. Because in DevOps, the goal is to break down silos. Those who work in the DevOps team are responsible not only for development, but for the entire product as well. This also includes finding and solving problems together with the operations team.
What is important here is that this phrase does not usually imply convenience; it is rather a practice that has been followed for years. In addition, in some organizations there are compliance requirements that formally restrict certain activities. Therefore, it is important to ensure that the compliance requirements are met. DevOps a holistic issue that affects everyone – teams, leaders, and the organization as a whole.
Change works most sustainably when it comes from the bottom up. Developers can therefore actively promote DevOps – even without an order from above. Bastien Reinhardt lists three concrete starting points:
Technical specialization remains important. However, skills that go beyond one's own field of expertise are becoming increasingly important.
Where do I sit in the value chain of my company? What are the other teams doing? And how can I make their work easier? Those who ask these questions are not just optimizing their own area, but the entire system.
In the past, specialists were primarily sought after. Today, so-called T-shaped profiles are in demand: broad knowledge of adjacent fields (the horizontal bar of the „T“) combined with deep expertise in one’s own field (the vertical bar).
DevOps means more coordination. This also means accepting limits: Optimizing within one’s own area of responsibility is not useful if it would have significantly greater effects in operation. Then it’s necessary to find a common point to which to move—and not go any further.
Almost every company already operates its own internal platform today. Even Google Cloud’s DORA 2025 report shows that around 90 percent of the organizations surveyed are using at least one internal platform. The crucial question is no longer whether there is a platform, but how good it is: Are the teams using it voluntarily because it helps them? Or are they being forced by organizational constraints to use it? The answer to this speaks volumes about the quality of platform engineering.
No one can get around AI. Currently, it is primarily used for code generation. However, the same applies to DevOps as to any other tool: AI is a multiplier.
„Good teams get better; bad teams are shown much more clearly where they have problems and they improve much faster.“
Bastien Reinhardt, Senior IT Consultant at accompio
Teams that know their workflow and have quick, short feedback loops will be able to use AI more quickly and effectively across all areas. The result: The gap between teams that live DevOps and those that haven’t yet adopted it will grow wider.
accompio assists companies in the implementation of Kubernetes, CI/CD, and Infrastructure as Code – topics that are fundamentally based on Site Reliability Engineering (SRE).
Bastien Reinhardt's most important advice for companies: start small and solve a measurable problem.
Successful DevOps doesn’t start with Kubernetes or a new CI/CD pipeline, but with the question of how teams work together. Tools, automation, and AI reinforce what is already there – good practices as well as weak processes. Companies that want to establish DevOps sustainably should therefore Develop technology and culture togetherBreaking down silos, tailoring teams along product lines, giving them time to operate and improve, and making feedback visible.
The initial step need not be large. A single, measurable problem – such as a too long release cycle – is enough to trigger the change.
Bastien supports companies in the implementation of Kubernetes, CI/CD, and Infrastructure as Code. His focus is on site reliability engineering and how teams can jointly develop technology and working methods.
DevOps is a working method in which development (development) and operations (operations) work closely together and jointly take responsibility for a product. Central principles are a fast workflow, short feedback loops, and continuous improvement. Tools such as Kubernetes or CI/CD support this working method, but do not replace it.
No. Tools are the result of a DevOps approach, not a prerequisite for it. Companies with modern cloud-native stacks can still have long release cycles if teams continue to work in silos.
The hurdles are mostly organizational rather than technical: silo thinking, differently optimized development and operational goals, fear of losing control, and compliance requirements. DevOps requires cross-functional collaboration, which must first be learned.
T-shaped describes a competence profile with broad knowledge of adjacent areas such as operations or security, while simultaneously having a deeper specialization in one’s own field. Such profiles facilitate collaboration within product teams.
A learning-oriented culture of error where post-mortems are about finding the causes rather than the culprits, and a non-spectacular deployment – a non-event on Tuesday morning rather than a major event with contingency plans.
In the context of DevOps, AI is a tool and acts as a multiplier. Teams with good workflow and fast feedback loops benefit greatly, while weaker teams see problems more quickly.
It is best to start with a small, measurable problem, such as the duration of a release. DevOps should not be set up as a time-limited project, as the culture should be permanently embedded in the company.
