Patrick Debois

Hi, my name is Patrick Debois, and today we're going to talk about DevSecOps culture and how I believe we're heading towards a team-centric view.

Some of you might know that I've been advocating DevOps for many years now, and I've never had a real definition of what DevOps should be or could be, for that matter. After so many years, I kind of started settling on the following: DevOps, or DevSecOps, is everything you do to overcome the friction created by silos, and all the rest is plain engineering. There is definitely some technology involved, but there are a lot of things that you're actually doing to overcome that friction. For me, that's the core purpose of DevOps and DevSecOps: looking at what friction we can overcome.

Friction points have been in many places. We've discussed technical bottlenecks quite often, such as different environments: the dev environment, the test environment. We've discussed management style, discussions about budget, which group gets which budget, and personal and educational issues like who gets what training. Our answer in the past has often been to put command and control somewhere in the middle, regulating like a police function what goes in from dev, what goes into security, what comes from customers and operations. But these pressure points have been building up, and luckily we're trying to overcome them somehow.

We've seen the following pressure shifts. Agile moved pressure from the customer and cut out the middleman, getting feedback to the team that was implementing. Ops got a pressure point through virtualization and cloud, and started focusing less on infrastructure and more on the service. DevOps moved the application towards production and started caring a lot more about production. Now we're in DevSecOps, where we have another friction or pressure point, security, and we're trying to address security earlier in the value stream.

Those forces are moving things towards the team and trying to cut out the management of command and control in the middle. Management becomes a supportive function around the team, supporting what they need to do. That's where management style is heading.

What we actually hope for, the Valhalla of what we're trying to do, is that the team somehow knows magically what to do. It has the autonomy to do what it thinks is right. We're putting the power with the people doing the work. That's the movement we're going through: from people who aren't doing the work trying to control who does the work, to the team doing it autonomously. There is a transfer of authority that we're trying to build, where we empower people in the team to do the right thing.

What's interesting is that company culture has evolved over many years. In his book "Reinventing Organizations," Frederic Laloux shows the transition that thinking has been making around collaboration culture. The first collaboration culture is command and control. It stems a little bit from castles, making sure nobody gets in, and the sovereign dictating what the law is: this power-centric, command-and-control thinking. You can still see this in metaphors like the firewall or the castle, coming in and coming out.

We have evolved since that and started approaching things with a more modern way of automation. Think of it as the evolution from castles to building factories. Factories and automation brought stability and repeatable processes, so it becomes a different way of controlling things: controlling the process.

Moving from this automation or factory setting, we started looking at how we get better at this process. Measuring became important. The scientific method prevailed. It wasn't just about a repeatable thing; it was about getting better at this repeatable thing.

Then we moved on to the next thing. We started asking who we are doing this for. It wasn't just about the process. We started looking at a customer-centric view, and really wanted to be focused on what the customer wants, in a good way, and not just what we could build. Eventually, Laloux argues that we're entering the phase of evolutionary. We're not just doing it for somebody; we want what we do to be meaningful.

It seems each of the steps is still somewhere prevalent in our culture of collaboration. Some will have hints and glimmers of the power-centric step, and some have hints and glimmers of the evolutionary step. To be clear, probably one is not per se better than the rest, but you need to apply them differently and understand when to apply them. It looks to me that each of them is actually creating space for the next phase to happen. It's very rare that you can just enter evolutionary if you don't first get clear safety on power and control. Each of them builds on top of each other, and that space is where I think we can start thinking about changing things. Changing things are things we can do to reduce friction.

We see this command-and-control versus evolutionary movement also happening in the DevSecOps or DevOps team patterns described in DevOps Topologies or Team Topologies. Some keep the center of authority somewhere in the middle; some are trying to overlap completely. That's a mixture of different styles. Again, one could have more impact than the other, but depending on what evolutionary step your company is in, you're probably going to adopt one or another. Saying one is better than the other, you could see it as another evolutionary step in each item.

You might adopt one model, and then you might have to move to another model because you adopted a different collaboration pattern over the years and the old model doesn't fit anymore. I think there is evolution in the topologies happening all the time in companies, not at the instant scale, but on the micro scale. The team-centric versus the decentered, the meaningful versus the control: they're all patterns still influencing how we think about the team-centric view. But the prevalent thing is that we've come from command and control and we're heading to this meaningful team. Autonomous teams are doing the things, they are empowered to do the work, and all the rest is trying to optimize to help them do their best job.

How have you seen the interactions? We can give collaboration of working together. We can be facilitators, less driving it, or we can set out to do something as a service, the automation. There are different ways we try to overcome friction that existed in the different models. The nice thing is we now have options, and we are thinking about the options people have tried over the years.

But the real problem is not how you organize and group your team, or where your company is in the collaboration ladder. It always boils down to trust. Trust is bidirectional, and often people adopt different collaboration models because they have a different understanding of trust in the company.

We often put emphasis on trust by looking at people's competence. If they're knowledgeable about what they do, then they often have a big plus. That's very natural because when we are technology-centric, we look at how well people are doing, and that's usually our first indicator of what they are doing or how well they are doing it. But in this kind of book, they describe four other things.

The other thing is being sincere. You can have all the skill set you want, but you might not be sincere. I wouldn't go so far as to say people are lying, but they might have different agendas, and that shows in certain interactions between groups.

They might have the best intentions and the best competencies, but they might not be reliable. Maybe they're not yet good at it, or they have other priorities, or there are other things that block people from trusting them. Usually that would be as simple as showing up in a meeting, being there all the time, being reliable. Somebody can call you and you will answer. All those three are already important parts of building that trust.

But the ultimate thing is that we want people to care, and I see this quite often. We can train the team in their competence. We can see that they're sincere and really eager. We see that they're fixing bugs, and reliability is that they're fixing bugs all the time, but they might not actually care. That care factor is very elusive in trying to build it in a team, and that's why some transformations fail.

It's also important to note that if one group, one silo, tries to trust the other silo, there is also the process that they have to become trustworthy themselves. It's easy to say the other group should do A, but you have to do things yourself, and you're trying to convince other people that you are competent, sincere, reliable, and actually care about their problems.

For example, if the development group mainly cares about features and not about security, it will show. If security mainly cares about security and not about features, it will show. That clash of trust is hard to come by, but it is an instrumental thing to look at for how you can get better.

Over time, I distilled the things people have started doing around DevSecOps into four areas. One is a lot of activity around the secure stack: what are we building? The next is how we are building. They can be technical, they can be process, but most of the narrative has been about this being a technical part or an automating part. Then there is the flip side: why we're building this. Governance, in the broadest sense, gives us an idea of what that should be, that why. It could have various whys, but it gives direction to the things we do in securing the stack and securing the delivery.

Ultimately, building on the process, building on the automation, and building on the stack, we're hoping that we are empowering teams to do the right thing. That's the fourth area. It is not enough to talk about governance and why we're doing things. It's very important to talk about who is doing the work and how we're helping them do the work.

If I were to picture the secure stack, a lot of the DevSecOps narrative has been about building the right things: code, container, cloud infrastructure, API management, authentication, authorisation, monitoring, metrics, logging, privacy, licences, operational frameworks, and the business. It's not one single silo that does one of these areas. Balancing DevSecOps and overcoming friction means you're not just caring about your code; you're caring about how it will end up in production and how it is secured. Those are things you do to overcome friction between the silos. That's what I think the narrative of DevSecOps probably is about.

The same thing happens in the delivery process. If you're thinking about the pipeline, there are things we can do in development that we can get better at. But as we move through the environments from development, to test, to production and operational environments, there are different things we can do. That broader view is what I want to instill in the team so they can take ownership of what they can do.

This is usually hindered by friction of silos. If the development group can't look at the build environment and can't look at the production environment, or the other way around, these are friction points in each of those areas that you overcome. Another way of looking at it is sometimes referred to as the sonar model: we're trying to ping from one area to the other to overcome friction points. But it gets blurry as long as we have longer feedback cycles.

Ultimately, we also want the process to be taken care of. In DevSecOps, I usually see this come up first at the friction point of incident management, which is probably the first area where these people start having to collaborate together somehow to overcome the incident. Later, they expand this to longer cycles of vulnerability management, all the way to compliance management and security continuity. This is a longer cycle, and a lot of developers don't have the power to look at the other areas.

On the flip side, developer groups or developer teams don't have to do everything. Again, this becomes collaboration somewhere in the middle in these areas. Saying it's 100% overlap is probably not the perfect concept, but somewhere between different groups doing different things with an overlap of about 70 to 30 percent in the middle. Where the balance is will probably be up to your company's culture.

Ultimately, we want to move from just collaboration to authority. The actual collaboration start could be as simple as, "Hey, we're seeing this vulnerability. Hey, have you seen this?" That gets the conversation going. What you actually want to go for is the next phase. If people are saying, "Here's something, here's something," you would hope they want to act on it. Sometimes they lack the competence, and sometimes they lack the focus to work on it. But ultimately you want them to get better at what you're surfacing as a security issue.

Once you see they are getting better, a lot of the educational part is that you want to make them accountable. It puts another pressure point on moving the team from knowing what to do to being responsible for what they do. The latest area is that we start trusting them as the authority. They have the authority to do certain stuff, and that's what we hope to transfer to that team. It doesn't happen overnight. It's a long process that takes a lot of the pain away.

Ultimately, just looking at the stack, the delivery process, or governance will not be enough. This fourth pillar of collaboration transfer, much like the circles of organizational culture, is what you're trying to achieve and what will fuel a successful transformation.

As I mentioned before, I showed you a lot of places where friction points happen. When we improve something in the stack, it might improve something in delivery, governance, and empowerment. They're all influencing each other. I'm not saying governance is more important than delivery, or the stack of tools versus the culture. One goes hand in hand. Again, it's creating space. If we improve something, there is time and budget to improve something else. That's almost like the spiraling thing that we want, from a central-owned, security-owned DevSecOps mentality to a team-embedded mentality. Where you end up and where your balance is, that's up to you to see how it fits into your corporate culture.

A third thing I usually think people forget is the alignment or motivation. I've given you inspiration on where friction points can happen, where you can start tackling them, and how the transfer of authority from collaboration could happen. But there is still this motivation. If there is no alignment on why we're doing all this, then again, this is going to be really hard.

In my opinion, saying that it's good for the business is rarely the personal motivation people seek out. This really starts when you're trying to get from collaboration to the learning phase. In DevSecOps, it's been common practice to look for security champions, and security champions are often on the scale where they want to work around security. They're security-curious. But as we move down the line from "I want to understand security" to "I have to understand security," there is a whole spectrum, and the motivation of just saying it's good for the business won't be enough. You can appeal to being professional, to the quality of code, and it can go all the way up to getting a reward if you do it. I can't tell you the answer, but it's an important thing that is often lost in the whole transformation narrative: how do you not put the whole model on the team or group, but get the people doing the job to accept that they're doing the job? That motivation is crucial in the whole transformation.

So are we done yet? For sure, it's never done. That's where transformation after transformation will happen. There is no definite transformation. We'll keep going and improving over and over again. Our collaboration mentality might change over the years. We might see yet another wave of how we're thinking, because this culture is reflected by society in general: how people behave and how they think about these collaboration models.

I also find there is a paradox. The paradox of command and control is that the harder you squeeze to get the grip of control, the more elusive the control actually becomes. It's like sand: when you push it too far, it just flows out of your hand.

A similar paradox with automation is that the more you automate, you think it will be all about repeatable process, but after a while the people who did the automation leave, and nobody really understands anymore why we did all this automation. It becomes like a legacy system, and it becomes less reliable because we aren't sure anymore why we're building it.

On the level of measuring, there is a similar problem. If you start measuring to get feedback and improve yourself, that's great. But if you start measuring and look at the measurement as the end goal, what we've seen quite often is that people start to game the metrics and play on the metrics instead of the result. The paradox of measuring to get better is that when you look at the metric as the goal, it will probably start eluding your ultimate goal.

On the level of collaborative approaches, when we want to empower people, we often have the narrative around customer-centricity. What's interesting about that paradox is that when we are very customer-focused and ask what customers want, quite often in the starting phase of a SaaS company they will listen and look at all the things customers want, and they don't really judge what is important. After a while, when you get bigger, you start listening to the customers who pay the most, or the customers who are loudest, or the customers you value most in whatever your valuation is. You're actually becoming less customer-centric for the other group. Again, it's a pendulum swing from being very customer-focused to some-customer-focused.

That's a paradox that we keep getting over and over again. Ultimately, we are now going in the direction of autonomy and getting the team to decide, but we already know that once we get there, there is going to be a big call when some people don't make the right decisions or decisions we agree with. There is going to be a flip side where people really want to get back to controlling things and giving up on autonomy. Autonomy is good when it suits our purpose and when teams are going in the direction we want, or giving the meaning we want. But if we don't agree, we want to resort back to different approaches. Those paradoxes will keep coming in and keep coming back.

Even in general, there is a paradox around security. If you are safe, you probably think the least about security. If you're not safe, you think the most about security. But if you start doing more and more to build secure systems, after a while you get less interested because it's less visible why you were doing all these things. These paradoxes will keep us busy over and over again. It's something we need to be aware of, and the balance is, as I usually say, just enough. Where just enough is will probably be a thin line in your company, where you're going from one pendulum to another.

I hope I made it clear that DevSecOps works somewhere around the friction created by silos of the three groups working together; that there are different approaches, from the central approach to the more collaborative approach; and that you can do a lot of engineering work, but if you're not trying to do it to overcome the friction of the silos, then it's very good engineering, but it's plain engineering. If you're doing the engineering to overcome the silos, in my opinion, that is kind of DevSecOps or DevOps, as they both influence each other from a tools and a culture perspective.

Thank you very much for listening to me. As always, this has been a broad view on things. I'm happy to have a conversation with you anytime. I'd like to think together with you on how we can improve this, what your worldview is on what direction we are going, or what improvements we can make. Thank you very much, and feel free to reach out to me on my Twitter, @patrickdebois, or via email. I would love to hear your feedback. Hope to see you again somewhere soon, somewhere in real life, at another conference. Thank you very much.