DevOps as Organizational Culture: Beyond Infrastructure Engineering

Listen to the full episode above or read the article below:

This article is available in English. You can always listen to the original Polish podcast episode.

In this episode of "Porozmawiajmy o IT" (Let's Talk About IT), host Krzysztof Kempiński speaks with Jacek Marmuszewski, DevSecOps engineer and co-founder of Let's Go DevOps, about what DevOps really means beyond the technology—focusing on organizational culture, team dynamics, and the human aspects that drive business success.

What DevOps actually is (and isn't)

You can argue about this, and there are probably holy wars on this topic. Every person, every company has a slightly different approach, a slightly different definition of DevOps.

I agree completely. I've listened to parts of your podcasts with engineers who deal with infrastructure. Companies hire people and give them the DevOps Engineer label.

But the truth is, DevOps emerged as a certain organizational culture. A culture based on high transparency, extensive communication between people, and teams with strongly mixed competencies.

The old corporate divide

I remember times when I worked in large corporations. What seems completely unrealistic to me now: there were development teams that had absolutely no idea what was happening in production.

Their job was to reach the point where code could be handed to the testing team, then to the operations team. The operations team didn't know what package they were getting—they just had to run it somewhere in production.

What's more, I had one company where there was an additional development team that dealt with fixing production bugs. So the first team building features didn't even get feedback about what wasn't working, what was inefficient, what simply didn't work for the client.

This is where DevOps culture came in. Of course, they started hiring engineers—mainly cloud engineers, because that's strongly connected in my opinion. It's nice to create dynamic DevOps culture in a world where we can dynamically provision infrastructure.

DevOps as culture, not just a job title

I treat DevOps as organizational culture. In this culture, those of us who deal mainly with infrastructure also have knowledge about building applications. We can read application code. We can troubleshoot it. We participate in discussions about architecture for certain solutions. We advise which infrastructure blocks, which cloud components to use to make building applications easier.

In the other direction, developers know more or less how the infrastructure works, what its limitations are, what's good to do so applications are easier to build for them.

Yes, we often write in contracts and on LinkedIn that we're DevOps Engineers. That somewhat came out because everyone simply calls this one big bag of people with different cloud-infrastructure competencies DevOps Engineers.

But I treat DevOps as organizational culture.

The DevOps Engineer role: Three jobs in one person

The best answer is: it depends.

I'll refer to an anecdote. I have an acquaintance who dealt with recruitment at one time. When she first got the task of recruiting a DevOps to the company, she came back to me with a question. She said: "I got an offer, but it seems like they're looking for three different people in one."

Unfortunately, that's somewhat how it looks in companies. We have a very wide range of responsibilities and we try to find preferably a single person who can fulfill them.

That's also somewhat how our portfolio looks. We're a company, so we have a bit more flexibility. But what each client actually wants is a different expectation of what we'll do.

The wide spectrum of DevOps work

In some companies, we focus heavily on the database layer—database troubleshooting, optimization of things related to databases.

In others, we deal with a perhaps somewhat similar topic, but Elasticsearch—companies want us to help them with troubleshooting, optimization, performance.

In other companies, we manage strictly cloud infrastructure.

Somewhere else, it's more a form of consulting—which blocks to assemble certain elements from, or how to build certain systems so they distribute well between one or two clouds, or so they use those blocks we can use from the cloud as services.

It's hard to say what the spectrum is. What we focus on primarily: we mainly have cloud engineers. We probably relate a bit to the podcast about platform engineering—that's what most of these "DevOps" people do now. We went toward building platforms for companies and building nice tools so it's easier for developers to use complex infrastructure systems.

The technical and soft skill requirements

That's one part—cloud knowledge. We require everyone who works with us to be able to write in at least one language, preferably in Golang. That's also where our name comes from—Go with a capital letter in Let's Go DevOps.

We require that they can write in one language, can read code that developers deliver. Here the language isn't as important because we understand more or less what's happening there.

We also put strong emphasis on soft skills. Our responsibility is somewhat to go beyond the bubble of only infrastructure management, build relationships with teams, with developers, help them actually go through the path of creating infrastructure and applications that are cloud native.

Why companies hire DevOps teams

In our case, companies mainly want to completely outsource infrastructure management. We try to approach this comprehensively—it's not a ticket system where you get a clearly defined task. We try to participate in the entire application building procedure, go through the entire application lifecycle.

That's where we look for clients and where we try not to treat them as clients, but rather as partners, because these are long-term relationships. We often know everyone in the company and know the application, know the business often inside out, and can support it somewhere in terms of infrastructure.

The silo problem

What we often see: companies that build very strong teams called DevOps teams, but these are strictly infrastructure teams.

A pathological situation often arises where the infrastructure team blocks a lot of work. We also see this—often the amount of issues we have is such that we can somewhat block the delivery pipeline. Unfortunately, this happens.

There are two ways to deal with this:

Option 1: Being open, handing over increasingly high-level tools to developers so they can do as many things as possible themselves. That's what we're going toward—building some kind of platform for developers.

Option 2: A strong, charismatic DevOps team manager arrives, entrenches around it, builds a big silo and says: "From this moment, this is our responsibility." We become a team that's difficult to talk to. That's also a place where we appear to break down those walls a bit.

When companies think about recruiting DevOps, they're counting on starting to spread that communication and culture—training, conversations, those types of things must also be part of DevOps work.

Often, however, it turns out these are simply Infrastructure Engineers who often sit closed in their silo and aren't always willing to go beyond it.

Theory versus practice: When DevOps becomes "Administrator 2.0"

In theory, this philosophy, this approach we're talking about is to bring together different people, different roles responsible for producing applications, software and deployment, then maintenance, security, quality. There are quite a few of these building blocks.

But in practice, sometimes it's as you just said—it de facto creates a separate silo. What I call "administrator 2.0"—a person responsible for infrastructure who is a kind of bottleneck, perhaps some slowdown, but doesn't necessarily implement what DevOps philosophy says.

The daily reality

There's always a question of how it was supposed to look in theory, because everything looks nice on paper. Spending a lot of time with development teams looks nice on paper. But in practice, it turns out there's no time for infrastructure work, platform work.

There's even a nice article showing how these DevOps teams scatter across the company. Sometimes there's a DevOps assigned to a team, sometimes DevOps to the organization, sometimes it's a platform team. It's hard to find such an ideal creation here because it was described at such a high level that you don't know what to do with it further.

What we actually do

In our work, we see primarily that we have a lot of ad hoc things that come in. Developers who need help, explanation of something, consultation.

Maybe this sounds a bit ugly, because it's more about sitting down with them and talking and finding a nice solution to the whole problem. It's not exactly consultation as we think strictly academically. We're talking about conversation, about understanding what the other side expects from infrastructure and advising or building strictly infrastructure elements for them or with them.

I think that's the core of this work—the relationships we build with people at different moments.

Building abstraction layers

There's also the issue of thinking about them and giving them certain blocks of abstraction layer. For example, to reconcile the requirements of the security team, which is always treated in every company as the one that says no and blocks everything.

But it doesn't have to be that way. That's why we have tools like Terraform—to build ready infrastructure modules that contain all security team recommendations.

If I make this module well, if I make a nice abstraction, give it to the developer who understands why this module exists and how to use it, they'll use it in a way that means it's immediately in line with what the security team says.

So we try to do that—build them such a platform, such blocks that are developer-friendly but contain all those unfriendly things that usually appear in the company in terms of operations and security. Help build such larger elements from which the developer can then set up their infrastructure themselves.

That's our endgame in most companies.

The soft skills gap in DevOps hiring

I remember some time ago such big hype or big need for hiring DevOps Engineers when it was extremely difficult to find someone competent in this topic. Back then, I have the impression, something happened like de facto searching for cloud specialists, specialists who would have some cloud competencies.

But behind this was something like: we were looking for engineers, people with hard skills, people who know perhaps one cloud, perhaps many, but we somewhat neglected soft skills in this scope in the recruitment process.

I have a theory that companies very often wanting to hire cloud specialists de facto, with such hard engineering skills, put somewhere in announcements perhaps this magic phrase "DevOps Engineer" wanting to attract more people. But at the end of the day, they received candidates who perhaps didn't deliver, to put it colloquially, in terms of soft skills.

The technical introvert stereotype

There's an old joke: I didn't go to computer science studies to talk to people now. And paradoxically, unfortunately this is the domain of people who have a very strong technical backbone—not everyone is open to developing these soft skills. That's a certain challenge.

What you say about hiring cloud infrastructure specialists, I very strongly connect this DevOps movement with cloud infrastructure. It's hard to do real DevOps in a corporation, because if we need to wait 6 months for a server—because it needs to be ordered, it has to arrive, someone has to put it in our server room, we have to connect it at a low level, and only then can we talk about giving some abstraction layer over it—clearly we can do certain elements of DevOps culture, but it's much easier to do it in the cloud.

The startup pressure

All small companies that were just starting looked primarily for cloud engineers, counting on them promoting DevOps culture.

But we also often observe in companies that just started: the amount of work on infrastructure alone at the start is so large that we stop paying attention to soft skills at all. We simply know that from zero to product release we have 6 months, 12 months, sometimes even less. We literally have a few months, there's really a lot of this work, and everyone is working hard building infrastructure.

Then it's very easy to overlook that the person we're hiring doesn't have soft skills, focuses only on this hardcore technical approach, which isn't bad at all. But when we're talking about being DevOps, this is something we pay a lot of attention to—all people in the team must participate. It shouldn't be a discussion between the team manager and the rest of the world, but a DevOps team that talks about certain expectations, asks about certain things, participates in discussions, produces some materials like documentation, tutorials, training. This culture must be open from the infrastructure side upward.

This often drives developers in the other direction too—they're increasingly curious, they do some cloud training, they want to talk with us about certain aspects. You can really pull out nice things from this.

Common mistakes when implementing DevOps

I think it's often better or easier to learn by giving certain counter-examples or certain mistakes.

Rigid organizational boundaries

What we think about things that interfere with us somewhere or that we consider not optimal from a DevOps perspective: often we encounter situations where teams have so rigidly defined boundaries—and these boundaries defined from above—that it's very difficult to break through between them. These are often separate organizational units, often separate silos, which manage some fragments or vice presidents. These names in those larger organizations vary.

But it means these cells are separate and they often don't talk to each other face to face, but through the manager, director, or even higher.

This is a big communication problem. Such barriers are probably the hardest to break down, because in these companies we often get feedback like: "Listen, you're in this silo and you shouldn't go to the second silo." We generally don't fully listen to that statement.

But building relationships—that's what's missing in these companies in terms of soft skills.

The "we'll just do it all" mistake

When we talk about DevOpsing and cloud infrastructure, another frequent pain point we see: we take just one group, specializing in development, who have done a few courses or read a bit about the cloud, and we blindly believe this is a DevOps team and they'll do both application and infrastructure.

Yes, they'll do this infrastructure because there are these abstraction layers. But we have such clients we come to and it turns out there are basically no backups, because no one turned them on. Somehow this infrastructure was created, it fulfills its business function, but in terms of maintaining business continuity, it's missing a lot.

I think we need such a mix in these teams to have both developers and infrastructure people and simply connect them together.

The two types of DevOps engineers

I often joke that I know two groups of people when it comes to DevOps:

"Little Dev, big Ops"—people who have a very large infrastructure background and a bit of development.

"Big Dev, little Ops"—primarily those who focused on development and know infrastructure quite well.

This is a nice group that clicks together well. If we have all of them within one team, we can really build nice things together then.

What's missing in DevOps?

I think primarily what's missing here is an instruction manual, because everyone would want to have this. The question is just how to get there.

That's also why I didn't want to say certain approaches are wrong, because they work. These are companies that bring profits, often very large profits. So I can't say "hey listen, you're doing everything wrong" because they've really done a pile of good work.

But we often see this DevOps approach is maybe a bit not our way, or not how we'd see it, or we pay attention from a different perspective to certain aspects that might work.

So within this DevOps culture, in my opinion, primarily what's missing is such a clear instruction manual on how to implement this and how it should work. And these assumptions aren't always optimal.

Career paths into DevOps

I don't yet know of such studies in Poland that would train DevOps engineers. Maybe I'm wrong, maybe I don't have a full picture. But often these are people with previous experience either in development or related to infrastructure, to the cloud.

The administrative background dominance

Looking at job offers and requirements for what comes in, these are rather people who come from admin work, or administrators who additionally expanded to be able to code something, are very eager for automation. So this background is rather administrative-Linux.

I'll somewhat cross out Azure here, but mainly administrative. Most offers seem to come from these competencies.

Does the path matter?

I think it doesn't matter. If someone is really into this and wants to develop it, even in our teams we have several people whose background is primarily development, and at some point they started getting interested in infrastructure. These are real commandos, so I don't see any disadvantage whether it's one side or the other.

Both require going somewhat out of the drawer they may put us in from the beginning. You just have to go out of this bubble.

The unicorn problem

But it's also important when talking about DevOps: companies often look for such specialists who tried to do something from every area. This is a very difficult piece, because on one hand we're looking for people who can do something with networks, can do databases, can code, can do infrastructure. It's hard to catch all these competencies within one person.

I think here too, talking about DevOps, the strength actually lies in the group, not in a single person. It's good to build a nice team with nice competencies.

We also have cases where we connect people who have very good cloud background with people who were on bare metal for a very long time but are really excellent when it comes to any troubleshooting, Linux troubleshooting, etc.

This connection actually means we don't get productivity times two, but productivity times three. The fact that these people talk to each other, that they can accumulate such a wide range of knowledge, means we're able to really move big things and push big projects forward.

How AI is changing DevOps

There are specializations within DevOps, arising from the fact that it's quite a broad field of knowledge and practice. It also changes very quickly. Just look at the cloud—it's racing forward incredibly. And that's just one element, one component of the entire DevOps approach.

Lowering the entry barrier

Primarily the movement I see is that we're lowering the entry threshold primarily for people from the development side. Developers are increasingly asking AI how to do certain things, and this works well because AI can even generate fragments of Terraform code that they can simply add to our repository.

AI lowers this entry threshold quite a bit for people who aren't strictly connected with infrastructure.

But specialists are still needed

What's interesting: lowering the entry threshold means there's also much greater hunger for such specialists, but real specialist specialists.

I see from my strictly infrastructure group that here we're pushing very hard into such specializations to know how it works inside out. Because what AI will suggest, what it will do, usually works well. Sometimes we may even have some vision of why it works this way and how it works. But when it breaks, it turns out AI isn't always able to help us solve this problem.

Here we often see such inquiries that recently come to us particularly for help with really hardcore problems—those where it's already hard to Google information. You just have to know the technology inside out, and then it's also easier to find something.

AI is super, I really like that we're automating certain things. But from my perspective, from the point of view of an engineer in the job market, it will lower the entry threshold. But we're still looking for people who are willing to learn everything from zero, from the inside out to the very top, in order to support AI when it can't figure out what to do next.

FAQ

What is DevOps really?
DevOps is primarily an organizational culture based on high transparency, extensive communication between people, and teams with strongly mixed competencies. It's not just about hiring "DevOps Engineers"—it's about breaking down silos between development and operations so both sides understand each other's work and constraints.

Why do DevOps teams often become silos?
Strong, charismatic DevOps team managers sometimes entrench their teams, building walls and saying "this is our responsibility only." These teams become difficult to talk to and block delivery pipelines instead of enabling them. This happens especially when infrastructure work volume is so high that soft skills and cross-team communication get neglected.

What's the difference between DevOps culture and hiring a DevOps Engineer?
Companies often hire "DevOps Engineers" expecting cultural transformation but receive Infrastructure Engineers who work in isolation. Real DevOps culture requires engineers who can read application code, participate in architecture discussions, advise on cloud components, and build relationships with development teams—not just manage infrastructure.

What skills does a DevOps Engineer need?
Cloud infrastructure knowledge, ability to code in at least one language (to read and troubleshoot applications), understanding of databases, networks, and infrastructure, plus strong soft skills for cross-team communication and collaboration. The strength lies in building diverse teams rather than finding unicorns with every skill.

Should DevOps Engineers come from development or operations backgrounds?
Both paths work equally well. "Little Dev, big Ops" (strong infrastructure background with some development) and "big Dev, little Ops" (development focus with good infrastructure knowledge) complement each other perfectly on teams. What matters is willingness to step outside your original domain and develop across both areas.

What's the biggest mistake companies make implementing DevOps?
Creating rigid organizational boundaries where teams can't communicate directly—only through managers or directors. Also common: believing a development team with some cloud training can handle both application and infrastructure, often resulting in missing critical elements like backups or business continuity planning.

How is AI changing DevOps work?
AI lowers the entry barrier for developers by generating infrastructure code (like Terraform) and explaining cloud concepts. But this increases demand for deep specialists who know technologies inside out—because when AI-generated solutions break, you need experts who can troubleshoot problems that can't be Googled.

What does platform engineering mean in DevOps context?
Building high-level tools and abstraction layers (like Terraform modules) that contain security requirements and best practices, allowing developers to provision their own infrastructure safely. Instead of making developers create tickets for every infrastructure change, you give them self-service platforms with guardrails built in.

Podcast: Porozmawiajmy o IT (Let's Talk About IT), Episode 259
Host: Krzysztof Kempiński
Guest: Jacek Marmuszewski, Co-founder of Let's Go DevOps
Topics: DevOps culture, organizational silos, platform engineering, soft skills in technical roles, team composition, AI impact