Liminal Spaces and Transitions

[Darren] (0:03 - 0:22)

If your job is at risk because of the AI you are so desperate to have, that is something you should stop and consider.

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development.

[Pinja] (0:22 - 0:32)

Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

[Darren] (0:37 - 0:43)

Welcome back to the DevOps Sauna. I'm here once again with Pinja.

[Pinja] (0:43 - 0:44)

Hey there, how are you doing, Darren?

[Darren] (0:45 - 1:23)

I'm doing pretty good. And there's a weird topic I want to discuss today, which is why we're recording this on the 27th December. So we're in that weird space between Christmas and New Year.

And I think we can describe these as liminal spaces, spaces like airports where we only have secondary frames of reference, and these kinds of transitional spaces. And this kind of started me thinking on what we should talk about, and we should talk about this kind of effect when it comes to projects, and transitions, and transformations, and how we progress through these kind of things.

[Pinja] (1:24 - 1:54)

Liminal spaces can be considered also not only in architecture. There is actually, while I was thinking about this subject, I ran into a subreddit called Liminal Spaces, which is more about the architecture. So empty spaces, empty hallways, as you say, transitional spaces.

But in organizations and in projects, you can also be; everybody knows that an organization can do a transition or a transformation. So why not there also be a liminal space where we're talking about that.

[Darren] (1:54 - 2:27)

And when we look at the actual description of a liminal space, this kind of place where we don't feel fully at ease, where we're not where we were, but we're not where we're going, unfortunately, describes quite a lot of the situations. Because in these spaces, you're kind of at the mercy of so many different things. You might be waiting for something.

You might be waiting for someone else. It might just not be the time to act yet. So I think a lot more people end up in these than we might perhaps think at first glance.

[Pinja] (2:27 - 3:10)

Yeah, that's true. I think the word liminal even comes from Latin for threshold, but that might also give us some guidance on how to approach this subject. And the uneasiness, at least for me, when I think of liminal spaces where I've been in, whether it's in between jobs or is it not, perhaps these couple of days between Christmas and New Year's, this doesn't make me too much at unease. But let's say projects, for example, I'm waiting for somebody and an organizational change, I don't know what's going to happen.

So it's the not-knowing part. I don't have the communication. I perhaps don't have the why.

I don't have the information on what's going to happen. And what can I do in this time and space that would make this more beneficial?

[Darren] (3:10 - 3:47)

Yeah, and exactly that feeling when you're sat in the airport, and you see your flight get pushed back by 45 minutes and then by another 45 minutes, and you just have no frame of reference for what you need to do with yourself in that intervening time. And I think that's something that a lot of organizational transformations struggle with where they may have built this huge transformation and then they get time gated behind certain actions and some people are kind of left to just waiting. And maybe we need to discuss how to tackle things like that.

[Pinja] (3:47 - 4:43)

Yeah, and many times what I've seen as a coach and as a consultant, and as I've been part of organizations that have gone through transformations, transitions at various scales, it is often seen as this necessary evil, that part of the process itself. It's something that we need to go through very fast, as fast as possible, so that the goal is at the very end, which is how to push through this, but often there is the value of slowing down. So we let the possibilities and opportunities grow actually during this phase because we often have an organization full of capable, smart people who can and could do a lot of things to transition us into an even better future that is often pushed through without sufficient communication.

And people are left wondering, how do I even fit into this thing? What is my role in the future?

[Darren] (4:43 - 5:51)

I think you kind of nailed it there with the necessary evil idea. The idea that, yeah, these transitions are things that people just view as something to basically speed run, but it kind of, it doesn't mesh well with ideas that we currently have about how to get the best out of basically anything where we're told to slow down, to enjoy the journey, not to like rush to the end of something, except we have this one massive corporate area where apparently rushing through is the best possible thing. And it comes back to, I was at this event at Microsoft in Espoo a couple of weeks ago, and one of the presentations started by very clearly saying how to manage these kinds of transitions.

And the first thing was talk to people, like talk to your clients. And like, there are so many times when projects just decide, we know what's best for everyone. So we're going to launch for that goal.

And instead of taking this kind of scenic route and like making the journey, the transformation, not making the goal, the requirement.

[Pinja] (5:52 - 6:25)

Yeah. And that's a big thing that when I've seen transformations and transitions in an organization, afterwards, right after, there is usually a lot of moments. Some people actually leave right after this.

And just because of the experience of going through the transformation might be even natural. Movement of people, it might be their time to go for something else. But it is always disheartening to see when the transformation process itself has angered people and left them uncertain about their own future in the new phase.

[Darren] (6:25 - 7:23)

I can see it, yeah, especially if the transformation hasn't been designed with them in mind. If they're basically being told that the way they work, the way they want to work, the way they've learned to work is wrong.

And I can see nothing less disheartening than basically being told by a company, this thing you're doing is no longer welcome here. Instead of, we see what you're doing, here's what we want, how do we make the, how would I describe, the golden path that actually combines these two by meeting the user experience with the requirements? And that seems to be a really common topic.

Loads of our events that we visit, that we put on, we're seeing this kind of force towards Developer Experience. But I think a lot of transformation projects are not really catching on to that yet.

[Pinja] (7:23 - 8:05)

No, we're thinking about it more from the, how do we implement, how do we start using a new tool from the Developer Experience? We talk a lot about platform engineering. How do you make it run so you have a centralized governance model, but then people are able to use it as they see fit, right?

But how do we make that into, let's say, organizational changes or other ways of working changes as well? And there are many different ways of tackling these things. But say, Darren, have you ever considered how do you yourself react in a situation or in a liminal space in a transformation or transaction?

What is your modus operandi in that situation?

[Darren] (8:06 - 8:56)

I'm not sure that my use case would be typical because I've been in a lot of airports, so I'm used to this kind of weird liminal space feeling. So to me, it's just like, okay, I can't work on that. I have 73 other things I can be doing and I'll get back to this when someone has caught up.

So, I don't think I've really been involved in a project in such a way that it's so consuming. If I'm consulting, I hop between a handful of different things. So it's rare that all of them would be paused.

And if it is, there are always servers I can check. So I think it's about that kind of always having something you can do, even if it's pushing towards that goal or at least augmenting that goal without feeling held back by other people.

[Pinja] (8:56 - 9:41)

What I've seen in organizations going through transformations is that people tend to react in many different ways. And there might be a bunch of reasons why they're doing what they're doing. And this is not always...

If I now categorize people into, let's say, three categories, it doesn't mean that 33.33% of people do this way in every single place and going forward the same thing. But there are often those people who keep on doing what they've been doing before, just because they don't know any better, even if they would know this is not what is actually moving us forward, but nobody told me otherwise. Let's say the Titanic is sinking, and the band is still playing, or somebody is still adjusting the deck chairs, right?

[Darren] (9:41 - 9:41)

Yeah.

[Pinja] (9:42 - 10:51)

So that's usually the first category of people. Then I've seen the quiet quitters as well. They're not perhaps leaving the organization, but as they do not know what they're doing and what's going to happen, they start basically doing nothing.

Nobody told me what I'm supposed to be doing. And this is in no way criticism towards these people, but it might be because of how the transformation has been led. It might be because of the organization itself.

There are many various ways for this. Then there are these people who lean in and try to make it better. What do I have to do to make this better?

How can I actually provide input for this? How can I influence this change to make it a little bit better? Trying to find better ways and they often actually, when they are given the opportunity, they are improving the process itself.

So there are a couple of these various things and it's not, I'm making this very simplified, but of course people have very different ways and it might be a mixture of many things, right? But these are often the, let's say the behavior patterns that I've seen. For the ones who are not at the center of, for example, a project management office for these kinds of changes.

[Darren] (10:51 - 11:03)

That's actually a question. Do you think that these mindsets are kind of more prevalent the further a person gets away from the actual change process?

[Pinja] (11:03 - 11:04)

Yeah, pretty much.

[Darren] (11:04 - 11:47)

I'm thinking that these first two are obviously not ideal mindsets, and we want to bring into, maybe not even lead and make it better, but at least acknowledging and going along with the process, which I don't think the first two are really kind of open towards. And I'm just, I'm wondering if it again comes back to the talk to your developers and if you don't include them, if they feel further and further away from the process, are they more likely to ignore it? Are they more likely to be part of this churn you've recognized?

And are they more likely just to be carrying on doing things that they have always done because they're just not close enough to the process?

[Pinja] (11:48 - 13:58)

Yeah, and it's also about securing the buy-in from people, like talk to your people, talk to your developers. They are the experts. If we're talking about the tool migration, for example, you're migrating to a new tool chain, which is one tool, for example, they are the experts in what they're doing.

Go in and talk to them and communicate what's going to happen. And we had a project a year ago, I think we even called it a program with one customer because we did a large migration, toolchain migration for this customer. And they had made a decision to hold their feature development and software development for the duration of this migration.

And there was a phased transformation. So there is some room for the different silos to start finding for their own space, and what can we do now? And then there's a question: What will the space be filled with?

So this company did a lot of communication around this transformation. And it was a big thing. They had maybe 200 developers.

So there's a big crowd to be impacted on this. So they knew all the time what was the next official step. They had people who actually stepped in, but more importantly, they had people who were these central communicators who were providing information on what's going to happen next.

And there was some waiting time. There was liminal space. And what we aimed to do for that liminal space is that we provided them instructions.

So we're now targeting Teams 1, 2, and 3. So Teams 4 through 27, I'm sorry, you will have to wait for now, but you can do preparations.

So, we gave them very detailed instructions on what they were able to do while they waited to get the most out of the first initial interactions. When we started the migration, for example, their repositories. So, that was one of the most helpful things in this transformation case.

But the people actually stepped in because they knew what was the North Star, what was the big goal, and then they were able to provide the input.

[Darren] (13:58 - 14:07)

There's two things I want to cover here. The first is that it often comes around to the fact that we're not reinventing the wheel. It seems the key there was communication.

[Pinja] (14:07 - 14:07)

Correct.

[Darren] (14:08 - 14:20)

And actually keeping people involved in the discussion process. It's like it's breaking down the silos. It all comes back to these things we've been saying for two decades that we're still not doing.

[Pinja] (14:21 - 14:53)

Yeah, that was the thing. Providing forums for people to ask questions, providing them communication, frequent communication. And we also had very quick, very fast feedback loops between us and this organization to solve any of the bottlenecks.

And they were very dedicated to this. And there was room for people from the customer organization's part to bring in proposals. Hey, actually, I see how you're now doing all the configurations for this and that tool.

What about if we, and then they step in and fill the space?

[Darren] (14:54 - 15:20)

Okay, that makes a lot of sense. The other thing I want to ask is, we hear this about Developer Experience a lot. And I'm just starting to wonder, is there a space for opinionated platform engineering?

Do you think there is a space where platform engineering experts should be saying, here is how it works, here's the toolchain you need to use?

[Pinja] (15:21 - 16:04)

If we think of Developer Experience and if we think of the DevOps safety net and platform engineering as well, I've seen more success when the toolchain itself is centralized and the governance has been centralized. But then there is decentralization around how perhaps the teams have more wiggle room in how they use it. So, not everybody has to become their own shadow IT, for example.

So especially in larger organizations, it might be smarter to have somebody who says, yes, these are the tools that we're using to have the security aspects, for example, in line and on par with the standards that the company is following.

[Darren] (16:04 - 16:18)

That makes sense. But it can't be so opinionated that it's saying, here is the tools that we use, and we're using this regardless of the fact that our code scanning tool doesn't actually cover half of the languages that you're using.

[Pinja] (16:18 - 16:19)

Absolutely not.

[Darren] (16:19 - 16:21)

And most of our security tooling doesn't make sense.

[Pinja] (16:22 - 16:59)

No, absolutely not. I really hope that there are no decisions based on that. I might be very naive in saying this, but in an ideal world of, no, absolutely not.

And this, again, goes to the communication and listening to your people. What do we actually need? Hey, we're using C++, but our code scanning does not cover C++.

What do we do then? Hey, let's add another tool to the chain. So again, would we have been able to solve this problem with a toolchain if we had stopped at the very beginning to think about what are our needs and talk to our people?

Hey, what are the languages that we cover, for example?

[Darren] (16:59 - 17:02)

So opinionated is good, over-opinionated is bad?

[Pinja] (17:03 - 18:34)

Yes, and dictating is bad. Let's put it that way. Not listening to your people is bad.

There are, of course, every transformation that goes through these speed bumps and on blocks and bottlenecks. But what I've seen as the main things is, and I feel like I'm repeating myself, but I don't think I can over-repeat myself in this with the communication lines. How do you structure it so that people know what's going to happen?

Clarify and communicate the big why we're doing this. So why are we changing to a new tool chain? Is it because of security reasons?

Do we need to do it for compliance reasons? How about the, yes, let's improve the Developer Experience. Yay, also very good.

So people need to know why we're going through this. Whether that's an organizational structure change, is that tool change? People are better able to lean into the change when they hear why we're doing this.

And what I've also seen that works really well is when we break down the big goal down to smaller pieces and focus on the small wins. And the organization and the transformation I was just talking about, they emphasized on always celebrating the small wins. So they provided these goalposts along the way that when do we celebrate our first green sprint, for example?

Where do we celebrate the first release with a new toolchain? It was way down the road, but it was always broken down. So let's celebrate the first green sprint and so forth.

[Darren] (18:34 - 20:28)

That's actually, I kind of want to pivot on the topic a little bit or maybe transition on the topic given what we're talking about. But that's so in line with a blog I wrote not that long ago about celebrating the small victories in security. That security has this tendency to be kind of doomsayery where some guy with a big beard will come and say, everything's going wrong, and things have exploded, and all the servers are down, and it's the end of the world.

But what we don't see is the tens of thousands of attacks a day that get thwarted by basic security measures and we just ignore those. So not going into that subject too deeply, but I do want to use it to kind of pivot into the idea of security because obviously security is on everyone's mind and it's kind of constantly transitional. You end up with these, you get a security tool.

You can actually see this by getting a security tool and downloading the list of CVEs, the common vulnerabilities and exploits over time. And they basically double in size since 2011 every year. They actually reached a peak around 2021, but in the 10 years, they were basically each time doubling in size.

So security was just in this or is constantly in this transition and that means that when you're looking at things from that standpoint, it becomes easy to dismiss the liminal space because you exist in it. It's just, it is the way you have to work. It becomes your primary reference and that's perhaps something that could be advantageous to project transition as well.

I assume that's why we do these kinds of transitional projects because it gets people in with the expertise to navigate these liminal spaces because they're always existing in them.

[Pinja] (20:29 - 20:47)

When you say that it is a constant liminal space, does it help in breaking that down, or is it just one liminal space after another, or is it just, is there any differentiators or are there any differentiators between that constant liminal space?

[Darren] (20:47 - 21:40)

It feels pretty constant. As an example, at Eficode, we maintain an ISO certification and that's recently transitioned from the 2013 version to the 2022 version, which required a handful of new additions to security posture. So imagine that one certification stacked upon itself to cover the entire workload of a Security Specialist.

Then you basically have these things that are kind of constant but always evolving. So you don't really have much differentiation. Depending on the part of the year you're in, you'll have different things because our audits are always at the end of August.

So we spend the summer ramping up for them and this kind of thing. But there's not a lot of delineation, I would say. It's kind of just a constant state of movement which you do eventually get used to.

[Pinja] (21:41 - 21:49)

Is there a risk in the liminal space within security industry and security topics? That we would let our guard down?

[Darren] (21:50 - 22:49)

I mean, I think we've just had an excellent example of that with the cutting of two Baltic Sea cables that happened on Boxing Day, I believe. So the 26th  December, the two cables were cut, and I think actually the expectation was that guard would be let down. But to the Finns, I think quite readily proved otherwise in that they seized the suspected tanker immediately.

So I think there's an expectation that guard will be let down. Certainly yesterday, though, I believe there were some like Azure outages that were unrelated that were just like some, I think they happen from time to time. But like the fact that there aren't people to resolve them, it does mean that bad actors might take that opportunity.

And obviously if everyone's on holiday, that becomes problematic. But usually people are just a phone call away. So efforts can be scrambled to resolve situations.

[Pinja] (22:51 - 23:04)

Do you think that now we're talking about, of course, a physical cable between Finland and Estonia, but when we consider how AI is impacting the speed of attacks, you see that there will be a change in here.

[Darren] (23:04 - 24:11)

AI is difficult. Yeah. With regard to attacks, AI is difficult because I'm not sure AI attack tooling has been identified yet.

And we know this through log analysis, basically, we look at a log of an attack, we block that log, and then we look for when the same IPs or the same signatures are coming in. And then we see that those reaction speeds are still very human. There's someone trying to pivot.

However, when we start seeing those pivots happen much, much faster, we will know that attacks are now coming at the speed of AI, that they are AI-based attack tooling. And I don't want to say that they're not here yet. I haven't done enough research to warrant that.

But a lot of attacks, to me, still seem like they're coming at human speeds or the ones that aren't automated tooling like you just throw whatever you have at the entire internet and see where you get. But the more dedicated attacks still seem to be coming at the speed of humans. But I don't think that's going to last very much longer.

[Pinja] (24:11 - 24:33)

Yeah, that's the thing. AI is here. Is it here to stay?

Yes, it is going to transition our ways of working, but also the transformations with AI and how does AI move us forward as well. So I'm pretty sure that this will change the transformations and the liminal space in the near future quite a lot.

[Darren] (24:34 - 25:05)

Yeah, I think that's the biggest transformation our industry's, I would think every industry's undergoing right now, is the rapid adoption of AI because nothing has arrived as quickly as AI has. Nothing has gone, like ChatGPT went from kind of a meme tool that generated extremely funny attempts at Harry Potter books to basically everyone's go-to for generating written content within the space of a couple of years. Nothing has had that impact before.

[Pinja] (25:05 - 26:03)

No, that is true. And it was only last year, Eficode organized a couple of breakfast events with AI and how AI is going to impact software development. And at those events, we asked participants, do you yet have a policy for AI?

And this was a little bit over a year, I'd say 14 months or something. And half of the people said that they have a policy, and out of those people, I think half said that our policies do not use for their own people. And I'm very, very certain that during this time, we have now more policies, we have more governance because companies have noticed that if we do not let our people use AI tools, whether that's ChatGPT or, for example, GitHub Copilot or GitLab’s Duo or any equivalent tool that we have, they're going to be trembled with the ones who made the effort.

So this also goes for transformations and transitions.

[Darren] (26:04 - 26:38)

Yeah, I think you're exactly right. AI is having such a massive impact on productivity or even my productivity. I use ChatGPT daily to draft documentation so that I can fill in all the details and not have to spend several hours writing something I can now do in 20 minutes, which frees me up for a load of other stuff.

And this is great from a perspective of being able to do more in a day and very bad from a perspective of employers who see this and think, oh, great, now we don't need to employ as many people.

[Pinja] (26:39 - 27:48)

Yes, so you're using ChatGPT, for example, to create documentation and to spark ideas, but that also means that it still requires you as a human being to be the critical thinker and analyzing what comes out of it. And if we think of transformations and transitions, there is, as I said before, many organizations feel the need to rush through all that liminal space, whereas it could actually provide critical input for the organization and let the possibilities and opportunities foster and actually grow in this environment. So, speeding transitions and liminal space with AI, I have some doubts if it's just to be done just to speed it up, but to foster documentation and, let's say, dialogue within the organization on the possibilities, that's a different thing.

And it does not take away the need to think about why we're doing this, how we're doing this, and how do we communicate with our people, even if AI, for example, ChatGPT in this case, is being used for that transition.

[Darren] (27:49 - 29:31)

I do think you're right. I think that's important to keep in mind on a company level, but this is also actually happening on a higher level where I don't think a day goes by on LinkedIn where I see someone complaining that the EU, like, we're not getting the latest LLaMa model. We don't have access to OpenAI's video generation yet.

The EU AI Act is causing all kinds of problems. And then it's like, I feel like these, we're already seeing impacts on people like artists who are now seeing reduced workload because ChatGPT can now just throw out illustrations. So we're seeing, we're not slowing down.

We're trying to get through the liminal space in such a way that people don't understand the damage that will be caused. And I don't want to come down like anti-AI. I think AI is a great tool and it will allow people to be far more productive.

I don't want to see it used for companies to make excuses to be reductive and to reduce workloads. And I think that's exactly what the EU's AI Act and their legislation on AI is going to prevent. And all the people who are saying, well, this is terrible.

We're not getting access to these early models. First off, if you're not smart enough to use a VPN to get these models anyway, you probably don't deserve them. And two, if your job is at risk because of the AI you are so desperate to have, that is something you should stop and consider.

We have to take this transition seriously. We have to understand that we are in a transition and not just try to get to the end of it and understand the price to be paid by AI.

[Pinja] (29:32 - 30:17)

You just raised an excellent point there, Darren. And just thinking about the one thing that I'm going to just still reiterate from what you just said is that it's a tool. It is not the meaning itself.

And how can we use that to foster innovation, for example? If we can now focus with the support of legislation and regulations, we can now focus on not the repetitive things, the simplest tasks, but if our free time from that is being freed to, let's say, the innovation and thinking about more complex issues, again, we can use tools to support that. But again, remember, that is only a tool.

We will get much further than we have before.

[Darren] (30:17 - 30:42)

Yeah, it has to be a tool, and it has to be assisted and driven by people and it should always be productive and not reductive. But I think a lot of these things, as we're coming to the end now, are things that have been discussed in every year, if you could put out a DevOps trends guide. And I think in 2025 or for 2025, in 2024, it's much the same where we have another trends guide that covers a lot of these topics.

[Pinja] (30:42 - 31:46)

If we consider this, let's take a liminal space now in between Christmas and New Year's before we come back from vacation, this might be something everybody would like to, might want to put on their reading lists. So the guide that we do annually can now be downloaded for free from the Eficode website. And the guide now details the trends for next year, what we have identified, and we have five of them this year for next year.

So, the real-time insights, how do we bridge the strategy with the daily operations? Consolidated tool chains, how do we align the central governance and the local adaptation? DevOps safety net, how to enable secure, traceable, and high-quality services.

And this is something we, of course, cannot not talk about here, is the AI-driven tooling that we just mentioned here, the speeding up the development and the business innovation. And just remember, it's a tool, not nothing that is valued in itself. 

And service management, and with service management, how to go beyond just answering the phone or the email or the Slack, linking the products and the customer success together.

[Darren] (31:46 - 32:09)

Yeah, and this guide can be downloaded from our website. It's been put together over the past few months by some of the brightest we have at Eficode based on their experiences over the last year and what we expect coming up in 2025. But for now, I will thank you for joining us.

I hope you'll join us in the new year for more Sauna. Thank you for this recording today, Pinja.

[Pinja] (32:09 - 32:13)

Thank you, Darren. It was a pleasure. And I hope to see everybody back in the new year.

[Darren] (32:13 - 32:14)

Okay, we'll see you next time.

[Pinja] (32:14 - 32:15)

Thank you.

[Darren] (32:15 - 32:21)

Bye. We'll now tell you a little bit about who we are.

[Pinja] (32:21 - 32:26)

I'm Pinja Kujala. I specialize in Agile and portfolio management topics at Eficode.

[Darren] (32:26 - 32:29)

I'm Darren Richardson, Security Consultant at Eficode.

[Pinja] (32:29 - 32:31)

Thanks for tuning in. We'll catch you next time.

[Darren] (32:31 - 32:37)

And remember, if you like what you hear, please like, rate, and subscribe on your favorite podcast platform. It means the world to us.