Nathaniel Barnes

Welcome to Orbit, the Hg podcast where we talk to leaders who have built some of the most successful technology companies in the world. I'm Nathaniel Barnes, portfolio CTO at Hg. My guest today coined a term that became the way an entire industry works. In 2009, Patrick Debois was a frustrated Belgian consultant on a government data centre migration, watching developers and operations teams talk past each other. His response was to organise a small conference in Ghent called DevOpsDays. That conference became a global movement. The term Patrick coined, DevOps, reshaped how software gets built and shipped. Patrick co-authored the DevOps Handbook, and over the 17 years since, he has watched version control, code review, CI, CD pipelines and observability go from fringe practices to baseline hygiene.

Now he is watching it happen again. But this time, the thing that needs the rigour isn't code, it's context. Welcome to the show, Patrick.

Patrick Debois

Thanks for having me.

Nathaniel Barnes

Thanks for being here. So we talked a little bit in your talk earlier about the parallels you draw over time. You talked about, "what if Ops was like Dev in 2009?" And now, in 2026, we are starting to ask, what if context was like code? What made that first leap a step change? How did you know it was happening, and how do you draw that parallel out to today?

Patrick Debois

Yeah. So it was already mentioned in the industry. You got a little bit frustrated, right? Yeah. And I'm an engineer, so I like to do things a little more structurally. With DevOps, that was the whole pride. Like, hey, I want to be proud of how I run the systems, how well they're performing for the customers. And it frustrated me how we used to hand off the way we did at that time. I grew into thinking, there must be a better way. And then I found other people coming into it, doing testing, doing canary deploys, there was a whole set of practices.

But I always look at it from two sides. There's a lot of tooling that overcomes a certain problem, that gives it a new direction. And then the tooling has a set of practices that change the way you work. So I'm interested in both, making sure that the change is actually also in the organisation. That led to a transformation. Some technology, some people stay at the technology level with containers. But it's a fascinating field to be in.

And now with AI, obviously the game changer was new technology, AI. People, especially over maybe the past year in the coding field, which is near and dear to the previous field of building and delivering software, caught on. And now we're looking at what this practice could be. That's where I do that similar thinking.

Nathaniel Barnes

Do you see ways that we're grappling with the same kinds of problems as we move forward into agentic coding? Or are we grappling with them in the same ways? You talked about that proliferation of tooling, and I know we see that everywhere right now in the same way we did during the DevOps movement.

Patrick Debois

There are two times I think the proliferation happens. The first time is more in the emerging phase. Everybody wants to be the first, the killer, the one thing everybody uses. There's a race going on. You're seeing the same thing now, whether it's your Anthropic, your OpenAI, the big players, and then smaller players trying to build on top of that new technology. Then at the end of phase one, things transition more into the organisation. There's a proliferation of vendors, because that's an established thing and they all want a piece of the pie. So that's happening very similarly.

We don't have a clear winner yet. What's fascinating is the speed now. The winner of today could be obsolete within a year. It's a little bit tough for the big players, but it's definitely happening with the open source players as well.

Nathaniel Barnes

Yeah, one hundred percent. One of the things that drove the ability of DevOps to create long-term transformation was essentially codifying Conway's Law and breaking down those walls so that people could actually talk more effectively with each other. So, looking forward, are you seeing more instances of that? Are you seeing things where the agents are basically accelerating people into the existing walls they have between their structures and teams? Or are you seeing people reshape and do something different in that regard?

Patrick Debois

Yeah, I think both, actually. Starting a little bit from the solo person where, you know, I can deploy a server and now I can deploy 100 consistently, with a coding harness and people experimenting in those spaces. But scaling it out is actually the collaboration you mentioned. DevOps was very centred on collaboration.

With AI, it was interesting, because everybody said, "now I can do all these things myself." That was the first reaction. I can do this solo, the solopreneur. I need less people in my company to do certain things. And that scared a lot of people. But what we now see is, actually, we learned the agent only thrives if you give it the right context and the right information. And to do that, we have to have a consensus, not only between the human and the agent, but the agent is actually forcing us to talk to other colleagues to have the same context. So that's helping as well. While the agent is almost failing at things, let's discuss that. How can we help the agent? It's almost like the agent is everyone's developer-enablement project. It helps that collaboration.

The other thing is silos. I mentioned this in my talk. Within an organisation, you have certain knowledge, others don't. There are good reasons, permissions, scrutiny on those as well. But sometimes it is more like, well, that person doesn't want to talk to me, or I have access but no clue what it's doing. With AI, I can relentlessly follow up on my questions. And as long as I get access to the data or the context that the other person uses, I can help overcome those bridges where maybe somebody else doesn't have time.

The third piece is that Dev and Ops blended together. At the beginning that was the biggest friction. Then the testers came in, then DevSecOps, then all the rest. I personally learned that whatever the parallels were on the pipeline we were building technically, were also there in the sales pipeline, in the GTM pipeline. It's all about vetting, triaging, filtering, feedback loops. We now see that with AI as well.

Now AI is actually stimulating us to write documentation, write pieces. I mentioned that it's the first time in history that developers actually like to write documentation. Maybe they become a manager, or their role expands. They become more of the architect of their system. They become more of the PM. So that cross-boundary person, I think some have called the AI product engineer, they go broader. That kind of multi-faceted person also creates empathy for different roles.

That was a part of DevOps too. If I know the pains that Ops is having, as a Dev, I'll do my best to improve them. And AI is also helping with PM, with discovery. That's a hard thing, having the right feature. So that's helping in collaboration as well. PMs are building prototypes and helping engineering build the right thing, instead of frustrating documents that they ship around. So a lot of collaboration is happening. The saying that we're all going to end up solo coding with our brain, it's not happening. It's still going to take cross-collaboration.

Nathaniel Barnes

Yeah. It's funny you talked about that intersection, and trying to get the right information. As engineers, we have seen for so long that the biggest problem you have is getting an idea, getting the right idea, out of someone's head and onto paper so that you can actually do something with it. It's been fascinating watching that process play out at lightning speed with these agents accelerating everything.

Patrick Debois

Yeah. I have a fascinating example. We often think about getting ideas inside our companies or our team. We talk a lot about vibe coding and people building prototypes. Part of vibe coding is the learning journey. What do I actually want to build? Because they can see it in action and get way better feedback.

But what if your customers can actually build on top of you? What if you allow them to vibe code with the APIs of your tools? You're going to see features that you would never have been able to describe. All of a sudden you're like, "you built what?" Taking that outside world into your product the same way as you do internally, I think they're both equally valid as learnings.

Nathaniel Barnes

And doing it without having to build that mountain of tech debt that comes with, like, a DSL or something.

Patrick Debois

Yeah. Resources are scarce, so you have to pick, as a product manager, what's first. Hopefully you make the right bets. That's discovery. You're already improving. We can build faster, we can build multiple versions, we can get there. So there's definitely an acceleration happening in the industry.

Nathaniel Barnes

Do you think that's a function of the ideas getting closer to what the market actually wants? Or do you think it's more a function of, we're looking for the best idea in a haystack, and if we make the haystack bigger, because everybody can try their idea, we're finding the right one?

Patrick Debois

Mm-hm. I think it's more that we never had time for all the exceptions and things that we thought were useful but couldn't build due to scarce resources. It's not just about discovery of the right feature that will ultimately make money. Sure. But adaptability is also a phase that can create more money, because that one addition all of a sudden makes your feature unlock a whole new product group as well. So I think it goes both ways.

Nathaniel Barnes

For our listening audience, when I get outside of people who are dealing with these things on a day-to-day basis, there's a bit of confusion about what exactly is the difference between context engineering and prompt engineering, or what makes context, in this specific way, different. Could you start with a brief explanation?

Patrick Debois

Sure. Yeah. Most people, even if they're not engineers, use ChatGPT. Whatever they type in the chat window, you'd consider those prompts. One by one. Now, the technology underneath is the LLM, and it has a limited amount of text it can keep in memory when it replies to you. Context engineering as a field has been quite focused on, we have that limitation, so whatever we put in there has to count. That's what context engineering meant. From prompt-er to engineer. You're almost managing the window: what goes into the LLM.

Now, what I'm talking about is the context development lifecycle. Before you put it into your agent and that window, you have to prepare and find all that information. It needs to be right. It needs to be discussed. It needs to be the right pieces. So looking at and managing that context before it goes into the context window becomes context engineering, and that gets translated into prompts. That's the lifecycle I think we're at.

We're seeing that code is becoming more prompting. We also see that pieces of our code are being replaced by prompts. More complex things, like onboarding or user support, are increasingly prompts. We just need a better way of dealing with that. Right now, a lot of people just copy and paste documents, and my engineering head goes, "what? Oh no, no, no, we shouldn't be doing this. There has to be a better way." Then, in analogy with the software development lifecycle, I called this the context development lifecycle.

Nathaniel Barnes

So the context development lifecycle you were talking about earlier, you've broken it into four steps. Generate, evaluate, distribute, observe. Can you walk us through that? What do teams frequently struggle with as they get through that process, and where do you think you have to get it right?

Patrick Debois

Yeah. Everybody has a different journey, of course. But in general, a lot of people are very focused on creating context. They type prompts, maybe they write files, then they copy and paste the file as a prompt. There's a lot of creation. Maybe it's from your internal wiki, your Slack system. That's the first phase. I call that generate.

Nathaniel Barnes

Which is the part everybody's focused on when we're talking about Claude Code and tools. Yeah. It's all generation.

Patrick Debois

Yeah. Then what you saw increasingly happen, while you're doing it as a solo person, you also want to use it elsewhere. So you start the first version of distribute. "I have this awesome prompt, can I copy and paste this?" That's maybe the first version. Or, I check it into my version control, in some files, and I get that.

Now you see a whole piece of marketplaces popping up. It's similar to a shared library. It's a shared context piece in a package that I can download for my agent. Instead of having to write everything myself, I can just download it. If I use another tool, somebody else is using it, similar to libraries and open source libraries as a concept. That's usually the cycle people go through.

The third piece is, they give it to somebody else, and then that person says, well, it doesn't work. I have no clue why it works, or when it will work, or what changes. There comes a new model. They don't know whether it's better or not. There are 15 lines. Is it now remembering the things? Is it forgetting all the things? They become too long. So that's usually when people go, "I need a way to test this better than a vibe check." This "seems good to me, let's ship it." No, no, no. You can't do this in engineering like that.

Conceptually, the AI world has the idea of evals. You run a bunch of tests. I give, let's say, an agent a task, and the funny part is, I can also have an agent check whether the task was completed in a good way. A lot of people call this LLM as a judge, or evaluations. So whenever I change something in my context, I say, here's a piece of context, here's my agent, here's my problem, try to establish this. Then I have another agent judging whether it was established. You can create a set of criteria, a set of tests, a set of scenarios. It becomes very close to behaviour-driven development. I have a scenario, I want to test this. So everything comes back. Engineering rigour is now coming back into those phases.

Nathaniel Barnes

What's old is new again.

Patrick Debois

Absolutely. Then the fourth piece. We've got the testing, but usually devs do this locally in a cycle. I've got a piece of context, I wrote my lines of AGENTS.md, I see where it works, maybe I can test it on multiple agents. I have a nice framework to do this. I distribute it. But then, how do I automate the feedback?

You have observability for production machines. What if we look at the log files from everybody in the organisation using that context? Can we find missing context? Can we find conflicting context? Can we see whether something is added to the context? So you start getting that feedback mechanism that was instrumental to CI, CD. But now for context. We're feeding this back, and somebody adds that one piece of context that everybody was struggling with, or the agents were struggling with, and all of a sudden everybody becomes more productive. You get the same infinity loop as you'd get with CI, CD, to improve that lifecycle.

Nathaniel Barnes

Awesome. I was a big fan, when I was a line engineer, of test-driven development in general. One of the things that was an eye-opener for me as I was adopting DevOps was the concept of testing loops inside of testing loops inside of testing loops. TDD was making my code better, and then I had broader ones that would make sure I didn't break anything too terrible, and then I had broader ones as we got into the build.

As we move into an AI world, do you see a place for, or a structure of, loops like that? Where we have different testing that runs locally as you're doing it, and different testing that's going to run as you get broader than that, and different testing on the distribution level?

Patrick Debois

Yeah. I often refer to it almost like a sonar. I test with a ping and then I always go faster. Whatever has the context, sometimes it's like a skill, it has formatting, almost like a linter. That's a very fast thing you can run locally. Maybe I can run a series of LLM-as-a-judge locally on my machine. Sure. But I won't be able to run it across different agents. For that, maybe I need a server, or a CI/CD-style build environment.

The judges also have different levels. I can judge just by the output, "hey, it produced code, it's looking good," almost like you read it on paper, but you never executed it. When you execute it, it becomes an actual test. It's not that fast test. It's going to execute. It could still be relatively fast. But then maybe I want to test it with all the tools, like the setup that every coding person has, and all of a sudden that becomes an end-to-end test. It needs access to all the systems. So that same thing is happening. The more complex and closer to production environment you get, the more you probably shift into more complex cloud systems.

Now, coding agents are also moving to the cloud. So the jury's still out whether people will actually still want to keep running things on their laptop. It's another thing we've tried for years to standardise, the coding environment. But there's a personality to it, apparently. It's hindering us. We went through that whole process to containerise everything, and then ended up with developers just running the container sitting on their laptop so they could have it locally.

One of the pitfalls is that some people try to run local models to get faster feedback. But I think that's a step too far. On maybe feedback on your domain, if it's useful feedback, then that works. But you can't know, from one model on your laptop, whether that behaves the same way as an agent running in the cloud from a vendor. That's almost like local testing with a non-conforming test environment. A lot of people struggle. "Should I run the LLM locally?" Do you really want to waste time on that? Anyway.

Nathaniel Barnes

Do you see a world where we start getting observability from production and feeding it into those kind of local evals? I know that's an area we've tried to push in. I feel like every time we, as an industry, get close to that, we actually find ourselves further away, with the exception of a few things around search-goodness scores and things like that. But, I wonder, in this world where we have LLMs that can act as the judge and they know something about your system, if they could also rake over the observability and take that live information and feed it back into your test system as it's running?

Patrick Debois

Yeah. I think the question is similar to, "do I actually need tests?" You learn either by the tests you can come up with, or your customers come up with them. That's your observability. The things that you didn't anticipate, or you want to know, what's happening now? I think it's a maturity thing. Whenever something goes wrong in production, you take that hard, and you actually improve that in your evals. You take an agent trace, and you say, "this is now a test case. Did I improve my context, and does the agent now behave in the right way?" That's good practice.

Not everybody is doing this. It's a step-by-step thing. Maybe you don't have to observe in your agent yet. Generally, in the industry, it's not that well formed. And it is just, funnily enough, I think it's still because in organisations they're still so siloed, even though they're not saying it. Production is run by the platform team right now. Not Ops, but it's not the same thing now. The tools are working on exposing that information more and more, and it's becoming more accessible to the agents and the devs as well. But I've gone to numerous conferences and I've talked to dev vendors, "hey, shouldn't you put in more of the operations?" "Yeah, but nobody's asking for it." And the Ops people say, "nobody's asking for the Dev side." It's like, really? Because you're still thinking within your domain in the organisation.

Nathaniel Barnes

There has to be a world where, instead of us trawling those logs to write test cases to pull back in there, it can be the LLMs.

Patrick Debois

Totally. Technically there's nothing stopping us. But if everything is DIY, we don't want to do that either. So, fair enough. Vendor, if you're listening, this is an opportunity in the market.

Nathaniel Barnes

Now we're just giving ideas away for free on the podcast.

Patrick Debois

Absolutely.

Nathaniel Barnes

Okay. Fair enough. You referred to this context development lifecycle as a flywheel during your talk. That would imply there's a compounding effect, that as you get better, you continue to pay increasing dividends. Could you talk through how that works? How does it feed in and accelerate the lifecycle going forward?

Patrick Debois

Yeah. If you start with the solo developer improving parts of the documentation because they weren't right, or the wiki wasn't right, and they're overriding it into their own file. What if all of a sudden the whole team gets that update? Their agents start performing better as well.

Now, the team might only know the domain knowledge of the specific piece of the product they're working on, but might not know anything on the actual guidelines for production or security. So that team can write it. All of a sudden, instead of someone nagging, "hey, did you improve security? Are you following our runbooks?" all of those pieces get used by the agents as well. It's like real-life execution of the runbooks, the context. And with the observability we talked about, that gives you your feedback channel, whether it's still working.

If one person improves this, all of a sudden you can push out that context to all the coding agents, and they get an upgrade. Not from the model, not from the engine, but from the context. It could be useful for new product terminology, all of a sudden everybody's working around this. Even product teams could start writing those contexts, because then the agents get less confused. Was it the old product? The new product?

So those have a compounding effect. And I hate to say compounding, but it's good for AI. Everything is compounding.

Nathaniel Barnes

Give it some more. It makes the trade go up.

Patrick Debois

[laughs] Yeah. But that's the flywheel that I think is happening, hopefully, in organisations that take this seriously.

Nathaniel Barnes

Do you think that expands outside of R&D as well? You get this compounding effect where new information about what the agent did well or didn't do well gets fed into the context and distributed among the developers. So you get the same feedback loop where, say, every product person who's having an interview with a customer and gaining knowledge about what the market actually needs takes that and distributes it out to every other product person.

Patrick Debois

I think you nailed it. Yeah. It's exactly that. There's nothing specific about R&D. Similar to the DevOps principles of collaboration across silos, in the context world it's also across the whole company.

One of the things that sounds too good to be true, and there is friction, I'm not going to lie, context can get outdated. But the fact that it's actively used is probably the best defence on it being corrected. Otherwise it just gets easily stale. We do get into politics a little bit. Who gets to say what goes in? What's the rule? But hey, that's organisational hierarchy. It's a little bit hard.

How do you handle context conflicts? That's another one. The owner gets to decide, but there are specific override cases of context, so we need a mechanism for that as well. Just because the product can drift, the technical things can drift. But I think the best bet is that the agents are using it. It's the same with guidelines. The guidelines that are never used are just paperware.

Nathaniel Barnes

Can you expand a little bit on context drift? What is it you're referring to, and how does that change over time?

Patrick Debois

Context drift would be something like, let's say we use a tool for testing. The tool has very specific ways of setting things up, naming conventions, processes it needs to follow. We add a new tool, and the new tool has another way of working. But somewhere in the context we still refer to the old way of working. It's drifting away.

Another way is, today the product has the term "blah," and tomorrow it says "hello" as the product name. Good luck. It's drifting away. So context is not write-once-and-done. It could also be the way we think about the problem, the way we think about our domain has changed, the way our customers have changed. That means we have a lot of context to update, if one thing gets changed.

Now, maybe with AI, the problem and the solution is always AI [laughs], keeping this up to date and aligning this. But it doesn't solve the thing of us having to put the effort of saying yes, no, this is correct, or not correct. Luckily for that, we still have our job.

Nathaniel Barnes

I like the way you said AI was turtles all the way down. Let's just say it's I/O and AI, no matter where you look. It's absolutely crazy. Do you think that the management and curation of this context is an internal product? Do you think that's something that eventually lives with a vendor? I know the context itself has to be your organisation's understanding, because it's part of the secret sauce of what makes you effective. But the actual curation and management of it, where do you think that lands?

Patrick Debois

I think there's bound to be a set of products that make that easier. There are already registries, but the surfacing of conflicts and all those things is further down the line. I think we're running a little bit behind. There are products that already have rights management systems, collaboration forums, but it just hasn't hit yet on coding context. Eventually it will come, with a shared platform integrated somewhere in a tool where you build out yourself. Probably your best bet right now is to pay the innovation tax, as I call it. You have to pay the innovation tax in these kinds of times in the industry. The feeding is obviously your business. And hopefully you're going to keep your moat while doing this.

Nathaniel Barnes

Yeah, yeah. But you shouldn't be waiting for those products to exist. If you really want that flywheel to spin and get those compounding benefits, you've got to actually resolve those differences between your organisations, investing in your now.

Patrick Debois

Yeah. It might prove organisationally that you're not ready for this kind of argument. But similar to the DevOps transformation, you needed a certain way of thinking. The thinking changed, the hierarchy changed. And we're back to Conway's Law, right? We just made the whole circuit.

Nathaniel Barnes

Honestly, I think there's so much organisational change that is just forcing hard conversations between teams. I remember a lot of our early DevOps conversations were around that hard thing of, "well, why do we do it that way? This is really inconvenient for Dev." And, "well, because you created these problems that later I found in production." So it would not surprise me if we find later that it's product management arguing with marketing, "but you keep putting this term in here, and we A/B tested that," or something else.

Patrick Debois

Guess what, the agents are also arguing.

Nathaniel Barnes

Yeah, that's been really fun to watch. That may have been one of my favourite things when this stuff first came out, watching the agents argue with each other. There was a particular thread I saw that was really funny, where one agent had posted asking about translating. They'd been given a receipt that was in Japanese, and they were asking about how best to translate it. There were three other agents arguing about the best way to translate this receipt in Japanese.

Patrick Debois

Sounds like an organisation.

Nathaniel Barnes

It absolutely is. So with all of this compounding, that inevitably means there's a serious acceleration happening inside these companies. When I look at DevOps, you coined that term in 2009. My first time spinning up fully automated pipelines was probably 2011. It took a while for that to really cement in the industry, to the point that even now, sometimes when we go look in due diligence on companies, I still see companies that have manual runbooks and manual build plans. But it feels like this is different. This is moving a lot faster. Do you see that? Are companies having to adjust on the fly? Do you think this will move that quickly, or do you think it's going to play out over the long term?

Patrick Debois

I would differentiate between two things. We feel that the innovation is fast. I would say maybe it's not faster than other times, but what makes the innovation faster is that it's almost public and has a world audience instantly. At that time, social networks were emerging. Twitter had been very instrumental for DevOps to find like-minded people. Now everybody's watching the whole show all the time. The innovators get feedback so close and so fast that the cycle is way faster.

Now, we are in a transient phase. Early adopters always want to be on the competitive edge. But maybe they don't need to be right. A late adopter could be fine. You know, "we skip the whole thing, we're still making money," and now we go. It depends a little bit on your industry as well.

I still get questions from people saying, "we just discovered DevOps." How is that possible in an industry where all the knowledge is available? Same thing. We're discovering evals and context. Conceptually, technology-wise, it's been there for a couple of years. So that's also weird. The industry needs to massage itself. Sometimes I think it's drip-feeding.

Nathaniel Barnes

Yeah, I think that's right. For the longest time we've had this conversation around, "well, all the knowledge is out there, why don't you have it?" I think what I grapple with here is the fact that, because of the nature of it, it's compounding benefits. It usually forces you to do something differently. The last time I can remember that for sure, we saw an exponential curve like this in growth of knowledge and capability, is something like Moore's Law. There were companies that were able to sit out the semiconductor revolution, if you will. But those companies were not people that made things with technology. And many of those companies died along the way. So you have to kind of get on it as it accelerates. It's a very different thing for the knowledge to be out there and then have to grapple in a market where somebody is getting it right exponentially faster.

Patrick Debois

I think we're at the age where it doesn't need to be perfect. We just need to be there.

Nathaniel Barnes

We just need to do it.

Patrick Debois

Yeah, we just need to do it. And that's a little bit weird as an engineer. Like, yeah, not perfect. It's always been a balance. But right now we're seeing GitHub going, "no more, like, people complaining about that." We're making progress. But there's a balance to be made there.

Nathaniel Barnes

It is funny, because when we look across our portfolio, and when I look at the broader industry, a lot of times the companies that spent the biggest time trumpeting, "I have my 27-step plan for how I'm going to roll out AI in my code," those are the ones that, a year later, I look back, and they're still on step 14 of their 27-step plan. Whereas the ones that came in, attacked a problem, the bottleneck moved, something else broke somewhere else, and they just went, "okay, great, we'll attack that one." They were agile in that way. Those are the ones that actually made the big benefits.

Patrick Debois

It is a paradox. I have that personally myself. You work with teams that haven't been as long in the industry. That's not hard. But you've accumulated all these battle scars, and things like, "hey, we need to watch out for this. We need that." So you don't want to be the person who's like the grandfather who says, "you know what, we did all these things." You want them to move at the speed they want to, and stumble through. I think the thing is, much like a toddler, the way they learn is you provide a safe environment.

The downside is that there's often not enough time anymore for the longer horizon, the hypothesising of what could be your future, because you're in the weeds, you need to deliver. That's another tension that has existed in companies for a long time. Futuristic thinking versus day-to-day business.

Nathaniel Barnes

It's almost like you need somebody who's going in and crashing into things and trying new things and stumbling, like a toddler, but on the same note, you have to have that bag of tricks that we've been slowly accumulating with our battle scars for the last 100 years.

Patrick Debois

And what is still relevant, right? Because that's the same as context pruning. It's like your own knowledge pruning. I need to throw all that away. Technology has moved on. It's working differently in the industry. And that's maybe the paradox, that a lot of people think our life is just going to be easier, but maybe we're just shifting complexity. Our judges now also have problems that we need to maintain. Context drift is a new problem. So are we gaining? It depends on where we want to put the emphasis. Right now the emphasis is on speed, on agility, not on robustness. Those are the choices we make.

Nathaniel Barnes

In many ways, though, sometimes people learn techniques, but not the first principles that brought them to why that technique came to bear. We exist in an industry where there are no panaceas, there's nothing that is a universal good all of the time. So helping people learn the whys and the hows then helps them understand when they should be applying that technique or not. Because you're right, there's so much that has to be pruned as we've continued to evolve and grow.

Patrick Debois

Do you ever try to teach children the first principles? It doesn't go well in the beginning, right?

Nathaniel Barnes

They don't enjoy that work so much.

Patrick Debois

Yeah.

Nathaniel Barnes

But you go back and learn them after a few battle scars.

Patrick Debois

That's it. That's it.

Nathaniel Barnes

Yeah. As you're watching companies grow, what are the first indications to you that they're doing it wrong? Or maybe a better way to put that is, when you see some companies sprinting and that's great, and you see some that are starting to lag behind, what's the first indication, as you're looking at a company, that they're going to lag behind? Is it a cultural thing? Is it a touchstone of what they're doing wrong?

Patrick Debois

It sounds weird, but when I look at how they treat their CI/CD, how mature they are, they have a better chance at absorbing another transformation. If you're still putting things on by hand, that's a sign. Now, a startup that skips the whole CI/CD and puts things in production, there's worth to it too, because they're getting customer feedback and learning the product.

Nathaniel Barnes

That goes back to, when do you apply these individual principles? If I don't have a customer base, then I don't really care about that rigidity yet.

Patrick Debois

Evals is a little bit of a telltale sign. Are you doing some testing? Are you thinking about doing some testing? One of the challenges there is that the ownership of this piece has been confusing. Is it the devs? Is it the platform team? Or is it the AI team? The AI team can run beautiful eval systems, but they couldn't tell whether it was actually good code. So that's one of the signs, who owns that piece. When I hear it's the AI team, they're going to worry more about whether it's trainable, ML, and we've moved on. That has its merit for certain pieces, but did you make the shift to try? That reinvention is hard in companies.

Nathaniel Barnes

It reminds me of one of my telltale signs, when I'm looking at tech diligence on a company, is if I walk in there and I ask a dev, "who's in charge of how your servers run in production?" And they go, "oh, there's a DevOps team over there. They take care of that." And I'm like, "oh god, no, you didn't figure that out." Although I'm not that adamant, as people say. I love collaboration, don't get me wrong.

Patrick Debois

A mobile team is also something, right? Does everybody know it's responsible for having it work on mobile? Yes, but there's a mobile team. It is a feature. So I would not say that you can have, definitely, a DevOps team in a way. I think it's about the mindset that the team has. Are we just offering the platform, or are we actually enabling and listening? That was the whole discussion about Product as a Platform, or rather, Platform as a Product. Are we listening to users? Are we helping them with their business cases?

The silo is not about naming. "We have a team." It's, how open are they to listening when you have a problem? How much are they helping you to overcome your problems? That's more of a telltale sign for me.

Nathaniel Barnes

Yeah, that makes sense. The problem is not necessarily that they have a DevOps team. It's that the answer is, "oh well, they deal with it." Then you've just created the silo.

Patrick Debois

Yeah. But feature-driven teams are all kind of silos in hindsight, too. Right.

Nathaniel Barnes

That's all we're doing.

Patrick Debois

No, I think that's another piece. When you have autonomous teams, that's a side tangent, but it is not about them being solo. It is about, when they change something, they need to tell that to everybody in the company. You still need to communicate, but you have autonomy in making certain decisions. Then the whole system needs to be aligned. If I make a decision and you're not impacting it, you bear the cost if nobody else is doing it that way. There are choices in independence.

Nathaniel Barnes

So you have ownership of it, but you're also responsible for the outcomes of it.

Patrick Debois

Yeah. And then it's like the devs are running agents like crazy, and the VP says, "look at my budget." There's always somebody who draws the short straw.

Nathaniel Barnes

So, looking to the future. Let's just go two years from now, because I don't think I can contemplate what the world will look like in 5 to 10. What do you think a company looks like that is doing this well?

Patrick Debois

Oh, it's the crystal ball question, right? For me, the extension to context is actually knowledge. I haven't fully distilled this in my mind, but the companies that are not just centralising context, but are actually learning from what they're doing. That brings the moat back. It's the same thing. I have a DevOps platform, you just run it, it's a bunch of things, or it's actually listening to what the market is doing and reinventing.

So, if a company can absorb a new technology in, let's say, a month. I hope that we're getting better at this. Is that where I predict people will go? No, it's where I hope they will go. That's always a different thing.

Nathaniel Barnes

Yeah. So if there was predictive power in DevOps from cycle time, the time from commit to production, then the predictive power now comes from our ability to absorb that context, and then into production. Is that right?

Patrick Debois

Correct. Yeah.

Nathaniel Barnes

Yeah. Okay. That makes sense. With this rapid pace of change, there are some people that just absolutely thrive on it. I certainly know some developers that are brilliant developers, they're managing 12 agents at once, and they talk about the fact that, as soon as it's done, they're like, "oh my god, I'm mentally taxed. I've got nothing left." How do you think, what differentiates those two personality profiles? How can leaders inspire people to thrive more on that kind of change, or maybe just prepare them for that kind of change?

Patrick Debois

Yeah. I think there's a little bit of personality in general. Do you want to learn new things all the time? Is that where you thrive? It's definitely my personality, I want to learn new things. So I'm having the time of my life right now. But some people, I totally understand, want to be focused, stay very good at what they do. They don't need to have the feeling that they're left out. We're in a transient phase, but it's hard to get a synthesis of those kinds of phases.

Almost anything leadership can tell them is, "okay, this is what's happening in the industry, these are the things," and keep people up to date. But not, "you have to try this latest thing ever," because that creates pressure. It's not for everybody. So it's mostly for leadership to recognise that not everybody is interested in that chaos phase right now.

There is the choice about, is this the way that I like to continue my job? Babysitting servers was before DevOps, giving them names, if that was what I wanted to do, tuning kernels. The job has changed. Now I need to talk to customers. I need to talk to my teams. That's a challenge, whether you want to have people move in that direction. With transformation, you can't force people in a direction.

The people who have the battle scars, who've done these things before, I think they're great champions on writing context. Now, it might not be the life they want, so that's up to them. But look at the opportunity. Maybe they're a great AI product engineer, because they can think and still are important and have engineering skills. So look at where they fit in.

It's not about having to be up to date all the time. The other thing is, we love to say, "here's the new technology, can you try it?" Respect things like, don't expect people to have a new prototype in the morning and then immediately scrutinise it. "When are you shipping this?" I get the attention, but leave some room for improvement.

The other thing is more personal hygiene. Remember when the phone came out, social media came out? We were all doom-scrolling. Some people still are. When's the moment you do this? When's the moment that you close your laptop? It's not just about giving you another idea to execute. People will start living with the tension. There are going to be a little bit more guidelines in general. Okay, we're expecting you to do this, or limit the time you spend on that.

Nathaniel Barnes

In some ways, your statement around needing slack, or needing ability in the system, reminds me of the old adages around a supply chain. If you have a supply chain that's highly efficient, it can't also absorb change rapidly. So you have to have slack in the system for a supply chain to function correctly. I think we're finding, in many ways, that in our R&D organisations and in the organisation as a whole, you have to have that kind of slack built into the system as well, if you're going to be absorbing this kind of constant change.

Patrick Debois

With the agility we've talked about, you definitely need that. You can't deliver to production all the time and solve all the problems. But it's very enticing to look at just throughput. "Can we get more throughput?"

Nathaniel Barnes

Out there now.

Patrick Debois

There are ways of looking at it. "I have 2x, 3x." It still feels hard to measure at times. You made some bug rates and so on. I sometimes refer to it as the infinity-x things you would never have done. That's harder to measure. Look at those things. What would you never have done? That takes you on a new adventure, typically.

Nathaniel Barnes

I always wonder sometimes, whenever we get to the 2 or 3x conversation, if we're just digging ourselves a bigger hole. That concept around the build trap. I wonder sometimes if we're just digging deeper build traps.

Patrick Debois

Yeah. It's fascinating, because we keep learning, and now we can build the ideas out and share. So the learning is instrumental, I think. And leaving time to learn is important.

Nathaniel Barnes

Yeah. Finding that time, not only for you to learn from what's happening and changing in the industry, but from each other within the organisation, in order to build that shared context.

Patrick Debois

Right. Context, you need it. That's right.

Nathaniel Barnes

I brought it all back. Thank you very much for joining me today on the podcast, and thank you again for speaking here today at the Digital Summit. I know we've already gotten great feedback from the CTOs, CISOs, and other technology leaders inside of the portfolio.

Patrick Debois

My pleasure. I'm keen to see what comes out of it. For those interested, I'm also running my own event together with a community. Not my own, but it's called AI Native DevCon. It's in London, on the first and second of June. You can join us there. There's a "Patrick50" discount code. It's more about context, people struggling, learning from the industry as a community, similar to what DevOpsDays was. I encourage you to come, and if you have any questions, I'm easy to reach on the socials. Thanks again.

Nathaniel Barnes

I know we'll have people there. Thank you.

The views and opinions expressed in this podcast and transcript are those of the contributor and should not be taken to represent the views or positions of Hg or its affiliates.

Statements contained in this podcast and transcript are based on current expectations or estimates and are subject to a number of risks and uncertainties. Actual results, performance, prospects or opportunities could differ materially from those expressed in or implied by these statements and you should not place any undue reliance on these statements.