I have always liked reading, but I did not find the time for it. About 10 years ago, I started to listen to books in the car. I have a lot of travel time and listening to books just works for me. I tend to switch between (science-)fiction and non-fiction.
When I encounter a problem or a new situation, read or hear something about a new model or framework, I’ll find a book and “read” it. Over the years I gathered quite a long list of books that helped me a lot in my daily work. In one on one talks with people, in explaining situations to customers, dealing with problems or just let me grow as an individual. When I talk to people I often hear myself saying. I read a book, where… But no clue in which book this was. That’s why I started this list of books. To have a library for myself, the lessons from each book as a quick summary, but also to be able to share it with others. I hope you enjoy it and find it useful. If you want to learn about more books, visit the Books section of this site.
At one of my earlier jobs, a manager pulled me aside. He had just completed a course in Neuro-Linguistic Programming, and he had a note to share with me: asking “why” was aggressive. It put people on the defensive. I should rephrase my questions, approach things differently.
I sat with that feedback for a while. And honestly, I never fully bought it. I was not trying to interrogate anyone. I just genuinely wanted to understand the big picture before diving into the details. Why are we doing this? What problem are we actually solving? Who cares about this outcome, and why?
Some time later I came across Simon Sinek’s Start with Why, and I finally had language for what I had been doing instinctively.
Sinek’s core idea is deceptively simple. Most organisations communicate from the outside in: here is what we do, here is how we do it, and if you are still listening, here is why. Leaders who inspire — and Sinek’s examples include Apple, Southwest Airlines and Martin Luther King — do the opposite. They lead with why, and let the what follow from that.
He calls this the Golden Circle: Why at the center, How in the next ring, What on the outside.
The classic example from the book compares two ways to talk about a computer company. The conventional version: “We make great computers. They are beautifully designed and simple to use. Want to buy one?” The Apple version: “Everything we do, we believe in challenging the status quo. We believe in thinking differently. The way we challenge the status quo is by making products that are beautifully designed and easy to use. We just happen to make computers. Want to buy one?”
The product is the same. The sequence is different. The effect on the listener is completely different.
Here is where I diverge slightly from how the book is sometimes read. Many people take the Golden Circle as a framework for vision statements and brand strategy. Apple, Southwest, Martin Luther King: it feels like a tool for big things.
But I apply it to every single decision. Every project kickoff. Every presentation I give. Every consultancy assignment where a customer is asking me to build or change something.
Before I talk about solutions, I want to understand the why. Why are we doing this? Why do you need this now? What changes if we get this right? And equally: what does it mean for your organisation if this stalls or fails?
In the technical industry especially, I notice how quickly we skip past those questions. We work with very smart people who can reason about architecture, tooling, and trade-offs at a sophisticated level. The conversation accelerates fast. Before long, we are deep in the how and the what, and no one has paused to ask whether we all agree on the why.
That is often where things quietly go wrong. Not because of bad technical decisions, but because the problem being solved turned out not to be the problem anyone actually had.
What the Golden Circle gave me is a kind of discipline: lead with purpose, not with solution. When a team or a leadership table comes to me with a request, I treat the first fifteen minutes as sacred for that one question: why does this matter?
And most of the time, the why they bring in the door is not the same as the why we land on together. The first answer is usually functional, “we need a new platform,” “we want to modernise the stack,” “we are falling behind.” Push a little and a clearer purpose emerges: we are losing good engineers, we cannot respond to the market fast enough, the board is asking us to demonstrate value from technology investment.
Those are very different conversations. And they lead to very different choices.
Sinek’s TED talk on this is one of the most-watched ever for a reason. If you have not seen it, it is worth the eighteen minutes: https://youtu.be/u4ZoJKF_VuA. And if you want the full argument in book form, the summary is in the Books section.
The manager who told me to stop asking why was not wrong that the word can land awkwardly. But the instinct behind it is exactly right. Every conversation has a level of abstraction at which it becomes genuinely productive. Getting there requires someone willing to keep asking until the actual purpose becomes visible.
That is not aggressive. That is just good leadership.
]]>Some colleagues tease me about it. “You probably have a model for that,” they say and honestly, they are not wrong.
Over the years I have developed what you might call a fondness for models and frameworks. Not because I think reality fits neatly into boxes, but because a good model gives me an umbrella. A place to start reasoning, a shared language to explain what I am seeing. Handlebars for situations that would otherwise feel slippery and hard to grip.
And sometimes a model does something even more useful: it gives words to something I already sensed but could not articulate. That moment of recognition. That YES!, that is exactly what is happening here, is worth a lot when you are trying to get a team or a leadership table aligned.
This is one of those models. I use it regularly, share it often, and it has served me well. I hope it does the same for you. If you want to learn about more models, visit the Models section of this site.
A few years ago, a good friend of mine and I took a day to walk through a city. We do that sometimes: no agenda, no client to prep for, just walking and talking. The kind of conversation where you end up somewhere completely different from where you started.
At some point we asked ourselves: what do we actually do? What is the thing that connects all the work?
Our first answers were all technology. Cloud migrations, DevOps, platform engineering, software quality. Which is true. But it felt like the list of things we carry, not the reason we carry them.
After a few hours of walking and pushing back on each other, we arrived somewhere different. Every person on our team, whether a developer, an architect, an agile coach, or a transformation consultant, is working toward the same thing. We help organisations become IT companies. And if you want to be an IT company, you need to behave like one.
That conversation was the seed of the Engineering Culture Model.
The Engineering Culture Model maps eight dimensions that separate an engineering organisation that merely functions from one that consistently excels. Not as a checklist, not as a maturity ladder, but as a diagnostic.
The eight dimensions are: Clear Digital Vision, Empowering Operating Model, State of the Art Software, Smooth Delivery, Appropriate Continuity, Power Through Platforms, Knowledge Driven, and Epic Workplace.
What makes the model useful is not the list itself. Most CIOs would nod at every item. What makes it useful is the pattern it reveals when you plot an honest assessment across all eight. In almost every organisation I work with, two or three dimensions absorb all the attention, usually Smooth Delivery and State of the Art Software, while the rest drift quietly sideways.
That drift is almost always behind the stalling, the attrition, and the missed delivery promises. The visible problem is rarely the real problem. The real problem is in the adjacent dimensions nobody is watching.
With the rise of AI, organisations are moving fast. AI is being injected into products, processes, and pipelines at a rate that would have seemed implausible five years ago. And I understand the urgency. The opportunity is real.
But here is what I keep seeing: organisations trying to embed AI into a foundation that was already cracked.
If your digital vision is unclear, your teams cannot decide what to use AI for, or where to draw the line. If your operating model is structured around approval chains and handover rituals, AI-generated code still gets stuck in the same queues. If knowledge is hoarded rather than shared, the people who understand the AI tools and the people who understand the business domain rarely talk.
Injecting AI into that environment does not fix it. It amplifies it. The speed goes up, and so does the rate at which the existing problems compound.
Clear Digital Vision and Empowering Operating Model need to come first. Investing in AI capabilities before those two dimensions are sound is building fast on a foundation that was never stable.
The model works as a starting point for a conversation, not as a conclusion. I use it before any transformation engagement to plot where an organisation is strong and where it is quietly breaking down.
Walk through all eight dimensions with the leadership team. Not to score them, but to surface the gaps that do not show up on project dashboards. The dimension that gets no attention is usually the one generating the most drag.
Then ask: what sequence makes sense? Not all eight at once, not in a rigid order, but with awareness of which dimension creates the conditions for the next one to succeed.
That is the move. Not more technology. Not a faster sprint cadence. A clear picture of all eight dimensions, an honest read on where you are, and a deliberate choice about where to start.
You probably have a model for that, they say. And in this case, I do. I hope it is useful.
I wrote quite a lot about this for my company Xebia. You can find more about the Engineering Culture Model in these posts:
]]>And then he tried GitHub Copilot on a Saturday afternoon, almost as a joke. By Sunday evening he had rebuilt a small internal reporting tool from scratch, alone, in a language he hadn’t touched in years. His feedback: “I felt like a developer again. And I understood my team’s problems in a completely different way by Monday morning.”
There is an important distinction that gets lost in most AI coverage: there is a difference between an AI coding assistant and an AI coding agent.
An assistant waits for your prompt and suggests the next line. An agent executes. You describe a task in plain language, and it reads your codebase, figures out what to change, writes the code, runs the tests, and reports back. You review the result. You don’t need to know the exact syntax. You don’t need to remember how to configure a build pipeline. You describe what you want and you steer.
Tools like GitHub Copilot’s agent mode, Cursor, and Claude Code work exactly this way. The barrier to participation has dropped so dramatically that the question is no longer “can I do this?” It is “do I want to engage?”
There are two reasons this matters for anyone in a CTO, CIO, or senior technology leadership role.
The first is credibility. When you ask your engineering teams why something is slow, complex, or expensive, you are usually dependent on their translation. They simplify. They omit. Not because they are dishonest, but because explaining technical trade-offs to someone who hasn’t touched a codebase in years requires a lot of abstraction. If you have recently struggled through a small feature request with an AI agent by your side, you have a much sharper antenna for when the explanation doesn’t quite add up.
The second reason is speed of thought. Strategy today is not just a sequence of slides; it is increasingly a sequence of working prototypes, internal tools, and integrated systems. Leaders who can assemble a small working demo, or at least meaningfully interrogate one, think faster and decide better. Not because they become developers again, but because they remain technically fluent.
The most common objection I hear is some version of: “That’s not my job anymore.” And that is fair. Nobody is suggesting the CIO should be reviewing pull requests. But there is a difference between doing the work of a developer and staying close enough to the craft to lead it well.
Carol Dweck’s research on growth mindset is useful here. The fixed-mindset version of leadership says: “I have moved beyond this.” The growth-mindset version asks: “What can I still learn from engaging with this?” AI coding agents lower the cost of that engagement to almost nothing. An hour on a Saturday afternoon is enough to close a credibility gap that has been quietly widening for years.
And honestly, there is something else at play. The engineers on your team notice whether their leader can engage with their reality. Not superficially, but genuinely. That noticing changes the dynamic in the room when you sit down together.
You don’t need to install anything complicated. Open GitHub Copilot in VS Code, describe a small problem you actually care about solving, and follow the agent’s output. Correct it when it goes wrong. Ask it to explain what it did. Push back when it misunderstands the requirement.
You’ll make something imperfect. That’s fine. The point is not the output. The point is the re-engagement with the texture of the work, with the kind of thinking that your teams do every day.
The competitive edge doesn’t come from the code you write. It comes from the understanding you rebuild.
So: when did you last write something that actually ran?
]]>Welcome to Culture Engineers, a space where I’ll be exploring the intersection of technology, people, and the practices that bring the two together.
I’ve spent the better part of a decade helping software teams improve their software development lifecycle. That evolved into implementing DevOps practices on both technology teams and management teams. Early in my career, I thought the problems were mostly technical: pick the right architecture, use the right tools,follow the right process.
I was wrong.
The most common blocker I encounter isn’t a technology problem. It’s a culture problem.
Teams that can’t have honest conversations about failures. Leaders who reward heroics instead of sustainable practices. Organisations that measure the wrong things and wonder why nothing improves.
Culture engineering is the practice of intentionally shaping the environment in which people do their best work. It’s applying the same rigour we give to software systems to the human systems that build them.
On this site you’ll find:
If you’re a tech lead, engineering manager, or architect wrestling with the people and process side of software delivery — I hope this site gives you something useful.
The best software comes from the best teams. The best teams are built intentionally.
Let’s get to work.
]]>Regardless of the reason, the question will arise: Should we rebuild the software? How long will it take? And how much will it cost?
These are important and seemingly straightforward questions, but the answers are not always simple or concrete. There is more to consider than just time and resources.
In this session — which I delivered at devCampNoord 2026 and Techorama Netherlands 2024 — we explore this question in more detail. We discuss some challenges and considerations involved in making the business decision to rebuild or refactor an application. Furthermore, we explore how to proceed once the decision has been made.
The moment a team suggests starting over, the conversation changes. Stakeholders hear “months of work with no new features.” Developers hear “finally, a chance to do it right.” Both perspectives are valid — and both are incomplete.
A rebuild is not a technical decision. It is a business decision with technical implications. Before you can answer “how long will it take,” you need to answer harder questions:
Many teams choose refactoring because it feels less risky. You keep the system running, you improve it gradually, you avoid the “big bang” rewrite. That logic holds — until it doesn’t.
Incremental refactoring only works when the codebase has enough structure to build on. If the architecture is fundamentally flawed, if the domain model is wrong, if the coupling between components makes every change a system-wide risk — then refactoring can become an endless treadmill. You make things better locally, but the system as a whole keeps deteriorating.
The strangler fig pattern can help here. Rather than replacing everything at once, you build new capability alongside the old system, gradually routing traffic away from legacy components. But even this requires discipline, investment, and organisational patience that many teams underestimate.
Rebuilding makes sense when:
The last point is the hardest to measure, but often the most important. When a team spends 70% of their sprint capacity on maintenance, bugs, and workarounds, and only 30% on new value — that is a signal worth taking seriously.
Rather than treating this as a binary choice, I encourage teams to think along three axes:
The answer to “rebuild or refactor” is almost never obvious from the outside. It requires an honest assessment of all three — and the courage to name what you actually find.
This post is based on my conference session of the same name. The slides are available for download — see the presentations page.
]]>Projects ran late, ran over budget, or failed entirely. People began to realise that software, unlike physical engineering, had no consistent methods, no agreed-upon process and no reliable way to scale. By the end of that meeting, the participants had a name for it: the software crisis.
It is tempting to treat that crisis as a historical event, something that belonged to the era of punch cards and mainframes. But in reality, the crisis never really disappeared. It merely changed shape. As software became more powerful and more pervasive, the problems evolved with it. We found new methodologies, new ceremonies and new tools, yet the underlying tension remained the same: software grows faster than our ability to manage it.
When the crisis was first identified, software systems were tiny by modern standards. A banking system or an early defence program had nowhere near the complexity of today’s cloud platforms, distributed applications or global-scale APIs. Yet even then, teams struggled to coordinate requirements, design predictable processes and deliver reliable outcomes. The response led to the birth of software engineering as a discipline, and later to structured lifecycles like the SDLC and the famous Waterfall model. These frameworks offered clarity, but they also introduced rigidity, and eventually they proved too inflexible for a world where requirements change weekly instead of yearly.
The industry reacted by shifting to iterative models. The Spiral model introduced risk management and continuous learning. Scrum promised short cycles and empirical planning. XP brought technical practices into the agile movement and gave teams a more human rhythm for building software. Then DevOps arrived and pushed collaboration across the entire lifecycle, merging development and operations and accelerating the delivery pipeline.
Each evolution helped, yet none eliminated the challenges. Teams still struggled with complexity, resource constraints and shifting expectations. The tools became more powerful, yet the work became more demanding.
The cloud brought scalability, but also a proliferation of choices, configurations and responsibilities. Security became a constant and moving concern. Infrastructure as code blurred the line between developer and operator. Monitoring, compliance, container orchestration, CI systems and automation pipelines turned into responsibilities that silently expanded a developer’s workload. The original crisis of unpredictability shifted into a crisis of complexity.
This is the quiet truth of modern software development: we solved the problems of the past only to discover new ones in the present. Today, even small teams build systems that would have been considered extraordinarily complex in the 1960s. A simple web application may involve distributed caches, managed services, identity platforms, automated pipelines, versioned APIs and a dozen third-party integrations. In that sense, the software crisis never went away — it simply evolved into the challenge of managing an ecosystem that grows faster than any team’s capacity to fully understand it.
What is different today is that, for the first time, we have a technology that can help us address complexity itself rather than just wrap new processes around it. Artificial intelligence, and particularly large language models, are capable of absorbing context, interpreting code, summarising decisions and automating tasks across the lifecycle. Instead of expecting developers to keep every detail in their heads, AI can become an active participant in the process. It can expose architecture, spot inconsistencies, generate documentation, design pipelines, mine requirements from conversations and bridge the gaps between roles.
This does not mean AI will replace the need for engineering discipline. It means the discipline can finally scale in a way humans alone never could. In 1968, the crisis was about unpredictability. Today, it is about overload. Teams drown not because they lack methodology, but because they face an ever-growing surface area of responsibility. AI gives us a way to rebalance the equation. It absorbs the noise so that humans can focus on the decisions that truly matter.
Seen from this perspective, the software crisis did not end. It simply moved. And perhaps that is the most honest way to understand progress in this field. Software is always growing, always expanding, always pushing against the limits of what we can coordinate. What changes over time is not the existence of the crisis, but our ability to meet it.
We are not escaping the software crisis. We are learning to outgrow it.
]]>The shift is subtle, yet significant. For decades, programming required translating human ideas into a strict, mechanical syntax that computers would accept. This translation was the gatekeeper. If you could write code, you could build. If you could not, you were dependent on someone who could. Now, AI systems are reversing that relationship. They are becoming better at understanding us than we are at speaking their language.
This does not eliminate the need for programming skills, but it does reduce the cost of getting from an idea to a working prototype. Tools like GitHub Copilot, GitHub Spark, ChatGPT and similar assistants can generate code directly from explanations, sketches or even vague descriptions. A product owner can describe a workflow and get a workable draft. A designer can take a Figma component and turn it into real code without a handoff meeting. A tester can describe a scenario and receive a fully automated test script. The translation layer is getting thinner, and that matters more than most organizations realize.
Many teams assume this trend is about coding faster. It is not. It is about lowering the barrier to participation. When natural language becomes a valid part of the development toolchain, people who were previously fenced off from technical tasks can contribute more directly. Requirements become clearer. Designs become more actionable. Context becomes easier to preserve. The conversation stops being “tell me exactly what to build” and becomes “show me what you mean.”
English is not replacing TypeScript, Python or C#. It is sitting above them, acting as a universal interface. Developers still need to understand architecture, trade-offs and the consequences of a design decision. But they no longer need to translate every detail manually. The human effort moves from transcription to interpretation, from syntactic accuracy to conceptual clarity.
This also forces a shift in skills. Developers need to communicate intent more clearly, because vague prompts produce vague code. Product owners need to articulate value, not just features, because AI can generate functionality faster than a team can validate it. Architects need to express constraints and patterns in language the tools can understand. In short, the better teams become at expressing ideas, the more powerful these systems become.
However, it is important to stay realistic. Natural language is ambiguous. It is shaped by assumptions, shortcuts and context that AI does not always understand. A well-written prompt does not guarantee a well-designed solution. The underlying engineering discipline still matters. Teams still need version control, testing strategies, governance and clear acceptance criteria. The promise of “just describe it and AI will build it” ignores the complexity of real-world systems and the messy reality of long-term maintenance.
The real value is not automation, it is alignment. When natural language becomes a first-class artifact in the lifecycle, it becomes easier to keep design, code, tests and requirements connected. The explanations live closer to the implementation. The intent stays attached to the outcome. Knowledge stops leaking between roles.
This is the practical impact many organizations overlook. The question is not “Will English replace programming languages” but “How will natural language reshape the way teams collaborate and structure work?”
If the history of software tells us anything, it is that every new abstraction expands who can contribute. English as a programming language is not a technical shift, it is an organizational one. The teams that benefit most will be the ones that treat natural language not as a shortcut, but as a shared tool for clarity, alignment and better decision-making.
English is not the new programming language because code is disappearing. It is the new programming language because the conversation finally matters as much as the syntax.
]]>But the uncomfortable truth is that coding often is not even the majority of a developer’s job. In many teams, it can be as little as 30 percent of the workweek. The rest disappears into meetings, clarifying requirements, writing documentation, fixing CI pipelines, dealing with testing, responding to security alerts, and untangling the endless administrative threads that bind modern software development together.
Despite this, when companies adopt AI tools, they usually pour all their attention into supercharging that 30 percent. They look for features that autocomplete functions, generate boilerplate, or help with refactoring. These improvements are not bad. They just miss the point. If the bottleneck in your process is not the act of writing code, then making that part faster does not speed up the overall system. In fact, it can create more work: more code means more to test, more to review, more to document, more to integrate, and more that can break. By focusing AI efforts on the enjoyable part of the job, teams inadvertently expand the pile of work that lives in the less enjoyable 70 percent.
This is where the real opportunity lies. The greatest potential of AI is not in making already-skilled developers type faster; it is in relieving them from the work they tolerate but rarely enjoy.
Requirements are a perfect example. Teams often walk out of meetings with scattered notes, half-decisions, and three slightly different interpretations of what was agreed. An AI system can turn a messy transcript into a clean set of user stories with acceptance criteria, ready for discussion.
Documentation is another area ripe for change. No developer wakes up excited about updating a sequence diagram or writing a detailed overview of how the checkout flow works. Yet an AI system can generate those diagrams directly from the code, or reconcile the documentation with what is actually implemented.
Testing becomes lighter too. An AI-guided exploratory test can open the browser, click through the interface, and capture a full narrative of what happened, complete with screenshots and observations. That narrative can then be converted into an automated test that runs in the pipeline.
The same applies to build pipelines and security alerts. Instead of manually digging through CI logs to find a missing path or misconfigured environment variable, AI can read the logs, point out the likely cause, and even prepare a patch. When a security scan flags a risky logging statement or an unsafe input pattern, the system can suggest a fix or apply one automatically in a new branch.
What this does is subtle but important. Instead of making the enjoyable part of software development go faster, AI starts to chip away at the friction surrounding the craft. It reduces the administrative burden, shortens the refinement cycle, improves communication, and eliminates repetitive tasks that drain energy. In other words, it gives developers more time to engage with the parts of the job that drew them into the field in the first place: solving problems, designing systems, and building things that matter.
There is another reason this matters. Coding is one of the few aspects of the job that directly contributes to a sense of flow, mastery, and satisfaction. It is the part where developers feel in control and see the immediate results of their decisions. The surrounding 70 percent rarely provides the same sense of reward. By optimising only the enjoyable part, organisations risk amplifying pressure: developers can produce more code in less time, but the pile of non-coding work grows just as fast and remains just as manual.
Treat AI as a reducer of friction, not just an accelerator of output. It becomes a tool for unblocking, clarifying, recommending, summarising, and stitching systems together. It dissolves the little tasks that clutter a developer’s day. When applied thoughtfully, AI creates a shift in how teams spend their time — away from administrative overhead and toward meaningful creation.
Stop optimising the 30 percent developers already enjoy. Start shrinking the 70 percent they don’t. That is where AI can meaningfully change the rhythm of a team, the quality of the work, and the satisfaction of the people doing it.
]]>I use GenAI every day. It is incredibly helpful, especially in coding tasks and architecture discussions. But replacing us? I was not so sure. So Geert and I invited April from GitHub — someone who has been in the cloud and DevOps space for over a decade and works on developer experience and productivity using tools like GitHub Copilot.
Her answer was clear: no, developers are not going away. But your work is definitely changing.
April reminded us of something important. We have heard this story before. When cloud arrived, people feared for their jobs. Same with virtualisation, and later with containers. Each time, it was not about being replaced. It was about adapting. AI is no different.
The core of our job as developers, architects and engineers has not changed. We make decisions. We design systems. We think critically about trade-offs. That is not something AI can do — at least not yet. GenAI gives suggestions, accelerates repetitive tasks, and acts like a supercharged rubber duck. But we are still the ones in the pilot seat.
The way we described Copilot in the episode really stuck with me. It is like pair programming with a junior developer who somehow has access to everything ever written. But it is still junior. It can make silly mistakes, or suggest code that does not compile. So we still need to test, validate, and bring the right context.
That is where the real challenge is. If you ask the wrong question, you get a half-right answer. If you forget to give business context or overlook the architecture, Copilot cannot fill in those blanks. It does not know your organisational structure, Conway’s Law, or your compliance constraints. It just knows code patterns.
One important takeaway: not using AI might be a bigger risk than using it wrong.
If your peers use AI to complete a task in 30 minutes that takes you five hours, it is only a matter of time before you fall behind. Just like in sports, technology shifts the baseline. It is not about replacing humans, it is about augmenting them.
So the real question becomes: how fast can you learn to work with it?
Prompting matters. Context matters. Iteration matters. The best developers I know do not just ask AI to “write a unit test.” They keep asking, refining, and learning how to get the best result — just like they would with any tool or colleague.
Another thing that stood out in our talk was the gap between management decisions and real developer adoption. Just buying Copilot licences does not magically make your team more productive. It requires cultural change. Education. Time to play and experiment. Communities where developers can share prompts, tricks, and frustrations.
Just like with DevOps, it is not about tooling. It is about process and mindset. And yes, that takes effort.
Here is my take after this episode. Developers will not be replaced. But developers who refuse to learn, experiment, and adopt new tools might be. It is not about job loss. It is about relevance.
If you want to stay in this field, invest in your own skills. Not just coding, but also in learning how to use GenAI effectively. How to give it better input. How to challenge its output. And maybe most importantly, how to stay curious and open to change.
Because at the end of the day, the thing that keeps you valuable is not just your ability to type out code. It is your ability to think, to design, to collaborate, and to learn.
And AI, at least for now, cannot do any of those without you.
]]>One of the examples that comes up often is cloud migration. A technical shift, sure, but what it often reveals is how deeply siloed organisations still are. Development teams are excited about agility, automation, and speed. But then you run into the security team, who treat the cloud like a traditional data centre. Need a firewall port open? That will take two weeks.
It is not just bureaucracy. It is mindset. “It is what it is” becomes the default. People stop challenging how things are done. Sometimes, it is about control. Sometimes it is fear. Fear of becoming irrelevant. If I am no longer the gatekeeper of the firewall, what is left of my job?
That fear is human. And it gets in the way of change.
That reminded me of a powerful framework: Carol Dweck’s concept of the growth mindset. She studied why some people thrive under challenge and others retreat. The difference was not intelligence or skill. It was how they saw effort and failure.
People with a fixed mindset believe their abilities are static. Success defines them. Failure threatens them. So they avoid risk, avoid challenge, avoid looking stupid. People with a growth mindset see ability as something to develop. They embrace challenge. They learn from feedback. They do not tie their identity to the outcome.
It clicked for me. So many symptoms we see in resistant teams come down to this. Status quo thinking. Siloed behaviour. Saying yes without action. It is all rooted in a fear of being wrong, of being exposed, or of being seen as less.
Another big inspiration is Patrick Lencioni’s Getting Naked, which talks about three common fears in professional environments:
You cannot build a DevOps mindset if these fears dominate the culture. We need to create environments where it is okay to not know. Where people feel safe to ask the “dumb” question. Where mistakes are learning opportunities, not career enders.
So how do you shift that mindset across an organisation? One model I find useful is ADKAR:
We often skip straight to knowledge. We flood people with training, tools, and Terraform examples. But if there is no desire, none of it sticks. If there is no awareness, they do not even understand what they are being asked to change. It is like teaching someone how to drive without ever telling them why they need a car.
Changing a mindset is not just individual work. It is team dynamics. Culture. Trust comes first. Only when people trust each other can they disagree, have conflict, and commit together to a new direction. Without that, people hold back. They nod in meetings and disengage afterward.
And sometimes, what sounds like “everybody disagrees” is just the vocal minority. Most people are somewhere in the middle. Not actively resisting, but not moving either. That silent majority is your lever. Focus on them. Support them. Find the quiet influencers and help them step forward. Change spreads faster when it comes from peers, not just from above.
Maybe the most important thing: praise effort, not just outcome. In school. In parenting. In organisations. If we only reward results, people will not take risks. They will not try new things. They will not grow.
But if we reward effort, curiosity, collaboration, and reflection, we build something much stronger. We create a culture where learning is valued and fear takes a back seat.
That is the DevOps mindset. And it is something we can all grow into.
]]>