Schutten.Cloud | Where Technology Meets Leadership

Strategy is for decision-making. Marketing is for storytelling.

Organizations spend an extraordinary amount of time defining their vision, mission, purpose and values. Workshops are organized. Consultants are hired. Leadership teams debate every word. Marketing departments create beautiful presentations. Posters appear on office walls. And then, on Monday morning, nothing changes. Not because the strategy was poorly communicated. But because it was never designed to help people make decisions in the first place. Too often, organizations treat strategy as a communication tool. I believe it should be treated as a governance tool. The day I realized we were solving the wrong problem Not long ago, I was part of a leadership team redefining the identity of a growing IT services company. The ambition was clear. We wanted to define who we were, what we stood for, and where we wanted to go. Something people could genuinely recognize themselves in. Something that would unite the organization as it continued to grow. At least, that was my expectation. Instead, the conversation quickly became familiar. Customer intimacy. Innovation. Competitive pricing. Quality. The kinds of phrases every organization seems to use because nobody can reasonably disagree with them. None of them were wrong. But I kept asking myself a simple question. What will we do differently on Monday because of this? Nobody seemed able to answer. And that was the moment I realized we weren't creating a strategy. We were creating marketing. A strategy should answer questions before they're asked As organizations grow, decisions become increasingly decentralized.Recruiters hire people they've never worked with. Sales teams negotiate deals without involving the board. Architects design solutions independently. Product managers decide what gets built next. Marketing teams position the company every single day.The larger the organization becomes, the less practical it is for leadership to approve every decision. That is precisely why strategy exists. Not to inspire people. Not to impress customers. Not to look good on a website. But to ensure that hundreds of people make decisions that move in the same direction. A good strategy reduces uncertainty. It doesn't create it. Every strategic principle should have consequences Words like innovation, quality and customer intimacy sound impressive. But they only become meaningful when they influence behavior. Imagine a customer asks for a highly customized solution. Do we build it? The answer shouldn't depend on who happens to be leading the meeting. It should already be implied by the strategic framework. A recruiter finds an exceptional engineer. Technically brilliant. But unlikely to thrive within the organization's culture. Do we hire them? Again, the answer shouldn't require executive intervention. Marketing wants to launch a new campaign. Should we position ourselves as the cheapest provider? The premium specialist? The safest choice? The most innovative? If your strategy doesn't make that decision easier, what exactly is it for? Every strategic principle should eliminate options. If it doesn't help people decide what not to do, it isn't providing direction. Growth demands autonomy When organizations have fifty or a hundred employees, many decisions still happen organically. People know each other. Leadership is accessible. Context spreads through conversation. But as organizations scale, that changes. Information becomes fragmented. Teams specialize. Decision-making becomes distributed. You cannot build a thousand-person organization where every important decision depends on a handful of executives. Nor should you want to. Growth requires autonomy. But autonomy without direction creates inconsistency. That's where strategy becomes essential. Not because larger organizations need more slogans. But because they need better decision-making frameworks. Strategy should reduce debate, not create it One of the simplest ways to test whether a strategic framework works is to observe what happens during disagreement. Imagine a discussion about building custom software for an important customer. If the room immediately splits into opposing opinions, and the only way to resolve the discussion is by asking senior leadership... ...your strategy has already failed. A strong strategic framework should settle many of those discussions before they even begin. Not because it provides answers to every situation. But because it establishes principles that people trust when making difficult trade-offs. The best strategies don't eliminate judgment. They improve it. Storytelling still matters None of this means communication is unimportant. Quite the opposite. Organizations absolutely need stories. Stories create identity. They build culture. They attract customers. They help people feel connected to something larger than themselves. But stories should explain strategy. They should never replace it. Marketing tells people what the organization believes. Strategy determines what the organization actually does. Confusing those two is where many organizations lose their way. The real test The effectiveness of a strategy isn't measured during an annual kick-off. It isn't measured by how many employees can recite the mission statement. And it certainly isn't measured by how attractive it looks on a slide. It's measured in ordinary moments.A salesperson deciding whether to accept a customer. An architect deciding whether to build custom functionality. A recruiter choosing between two candidates. A product team deciding what not to build.Those are the moments where strategy either exists... ...or it doesn't. Closing thought I've seen organizations spend months debating the difference between a vision, a mission, a purpose and a set of values. Ironically, none of those discussions improved a single decision. Because the names don't matter. Whether you call it a strategy, a vision, a purpose or a strategic framework is largely irrelevant. The only question that matters is this: Does it help people make better decisions without asking for permission? If the answer is yes, you've built something that can genuinely guide an organization. If the answer is no... ...you've probably written excellent marketing copy.

When intelligence becomes something we outsource

We are slowly doing something unusual with intelligence. Not replacing it. Not augmenting it. But outsourcing it. One prompt at a time. Artificial Intelligence tools like ChatGPT, Gemini, and Claude are often framed as productivity multipliers. And they are. They compress time, reduce friction, and make complex outputs accessible at almost no cost. But there is a quieter shift underneath that narrative. We are starting to separate thinking from understanding. And that is where things become fragile. The illusion of competence A well-written prompt can produce a remarkably convincing answer. Structured, fluent, confident, even nuanced. But confidence is not the same as correctness. And fluency is not the same as comprehension. The problem is not that AI produces wrong answers. It is that it produces answers that feel right often enough that we stop checking. And once that habit sets in, something subtle changes: We stop being the system that verifies. We become the system that accepts. Intelligence without ownership There is a difference between using a tool and depending on it for cognition. A calculator never made anyone worse at math. But it also never asked them to understand what it was doing. Modern AI tools sit in a different category. They don’t just compute. They interpret, summarize, explain, reason. Which means they don’t just extend intelligence. They can replace the experience of thinking. And once that replacement becomes comfortable, it becomes structural. The cloud problem, repeated at a cognitive level We have seen this pattern before. Cloud computing abstracted infrastructure:servers became services systems became APIs operations became dashboards complexity became someone else’s responsibilityIt worked brilliantly—until it didn’t. Because abstraction has a hidden cost: distance from reality. And with each layer of abstraction, fewer people understand what is actually happening underneath. Now we are doing the same thing with intelligence itself. From understanding systems to trusting outputs In earlier generations of engineering, you were forced to understand what you built. If a system slowed down, you needed to understand IOPS, memory pressure, CPU scheduling, network latency. Today, many engineers start at the top layer: Deployments, pipelines, managed services, black-box scaling. Even education has adapted. We teach how to use systems, not how they fundamentally behave. And that works—until something breaks outside the abstraction layer. Then the question becomes uncomfortable: Who still understands what is actually happening underneath? The real risk is not AI becoming too smart The real risk is humans becoming too comfortable. Because when AI works well, it removes friction. And friction is often where understanding is formed. If everything just works, there is no need to dig deeper. If nothing requires repair, there is no need to understand cause and effect. If answers are always available, the discipline of reasoning slowly erodes. Not dramatically. Not visibly. But cumulatively. “Just ask AI” is not a strategy There is a growing cultural reflex:Don’t know it? Ask AI. Need it explained? Ask AI. Need a decision? Ask AI.And most of the time, that is fine. Until it becomes the only mechanism. Because AI does not create accountability for truth. It produces plausible synthesis based on patterns. Which means it inherits one critical dependency: There must still be human intelligence capable of questioning it. Not superficially. But structurally. What happens when the underlying knowledge disappears? This is the uncomfortable edge of the argument. What if we gradually lose the ability to independently validate what AI produces? Not because we are incapable. But because we stopped practicing. Then we reach a point where:the system produces an answer nobody truly understands how it was derived and nobody can confidently say whether it is correctAnd at that point, intelligence is no longer something we use. It is something we receive. The paradox of progress We are building systems that make us more capable than ever before. And at the same time, potentially less resilient than ever before. Because resilience is not measured by output. It is measured by what remains when the system is not available. Or when the abstraction fails. Or when the data is missing. Or when the model is wrong. Closing thought AI is not the end of thinking. But it might become the end of careless thinking, if we are intentional. The real question is not whether AI can do the work. It is whether we are still willing to understand the work that is being done on our behalf. Because at some point, the dependency becomes invisible. And when that happens, the most important system we have is no longer artificial intelligence. It is human understanding. And if we outsource that too far, we may eventually discover that we still have answers— but no longer know how to question them.

AI didn't replace engineering. We just stopped talking about it.

Artificial Intelligence has become impossible to ignore. Open Gartner. AI. Read CIO.com. AI. Attend Microsoft Build, Google I/O or AWS Summit. AI. Scroll through LinkedIn for five minutes and you'll quickly get the impression that every meaningful conversation in technology now begins and ends with large language models, autonomous agents and AI-assisted development. I understand the excitement. AI is a remarkable technological breakthrough, and its impact will be difficult to overstate. But I've started wondering about something else. Not what we're talking about. What we've stopped talking about. The conversations that quietly disappeared A few years ago, our industry spent enormous amounts of time discussing operating models, governance, architecture, automation, platform engineering and cloud operating practices. Those conversations weren't glamorous. They rarely filled conference halls. They certainly didn't dominate social media. But they mattered. Because they determined whether technology actually worked once the keynote was over. Today those disciplines seem strangely absent from the conversation, as though AI somehow made them less relevant. It didn't. If anything, it made them significantly more important. Engineering never disappeared One of the more curious assumptions behind today's AI enthusiasm is that intelligence somehow compensates for engineering. That if an AI model can generate code, architecture becomes less important. That governance becomes something you can add later. That operational excellence is simply another problem AI will eventually solve. I'm not convinced. Software has never failed because people lacked ideas. It usually fails because complexity quietly grows beyond anyone's ability to understand or control it. AI doesn't remove that complexity. It introduces an entirely new category of it. Unlike traditional software, these systems are probabilistic. They don't always behave the same way twice. They require validation instead of assumption, observation instead of certainty. That doesn't reduce the need for engineering discipline. It raises the standard. Demonstrations have an unfair advantage One reason the current conversation feels so optimistic is that most of what we see are demonstrations. Someone builds an agent in twenty minutes. Another team generates an application from a prompt. A startup orchestrates half a dozen AI services into something that looks almost magical. And genuinely—it often is impressive. But demonstrations have an unfair advantage. They don't have to survive production. They don't have to operate for three years. They don't have to pass security reviews. They don't have to explain themselves during an audit. They don't wake someone up at three o'clock in the morning because an automated decision suddenly affected thousands of customers. Production has always been where technology stops being exciting and starts becoming accountable. That hasn't changed. Abstraction is a wonderful servant The cloud taught us an important lesson: Abstraction is incredibly powerful. We no longer think about physical servers before deploying an application. Kubernetes allows developers to focus on workloads instead of individual machines. Managed services remove enormous amounts of operational burden. Those are extraordinary achievements. But abstraction has always come with an implicit agreement. Someone still needs to understand what happens underneath. Every abstraction layer increases productivity for thousands of people while simultaneously reducing the number of people who understand the foundation beneath it. That trade-off is acceptable. Until the abstraction breaks. Then expertise suddenly becomes scarce. I wonder what we're teaching the next generation When I speak to younger engineers, I'm often impressed by how quickly they adopt new technologies. Many can build sophisticated cloud-native applications long before they have ever managed a physical server. Increasingly, many can also build AI-powered applications before they've fully understood distributed systems, identity, networking or storage. None of that is their fault. We teach what the industry rewards. And right now, the industry rewards speed of adoption far more visibly than depth of understanding. I sometimes wonder what happens twenty years from now. Not when AI becomes more capable. But when the people responsible for critical systems have never needed to understand the layers beneath the abstractions they inherited. The question that interests me most Perhaps this isn't really an article about Artificial Intelligence. Perhaps it's about attention. Technology has always moved in waves. Every few years we collectively decide what deserves our attention, and everything else quietly disappears into the background. Today, AI occupies almost all of that space. Meanwhile, architecture, governance, operational excellence and systems thinking continue doing what they have always done. Quietly determining whether ambitious ideas become reliable systems. Or expensive experiments. Final reflection I have no doubt that Artificial Intelligence will transform our industry. I also have no doubt that most organizations are underestimating what it takes to operationalize it responsibly. Because intelligence alone has never been enough. Not in software. Not in leadership. Not in engineering. Perhaps that is what concerns me most. We celebrate every new abstraction as progress, while paying remarkably little attention to the knowledge it slowly replaces. Every generation of technology asks us to understand a little less of what happens underneath. AI simply accelerates that trend. Maybe that is inevitable. But history has rarely been kind to civilizations that confuse convenience with understanding. The industry is celebrating intelligence while quietly abandoning wisdom. And history has never been particularly kind to civilizations that confused the two.

Employees don't want another survey. They want to be heard.

Every year, thousands of organizations ask their employees exactly the same question. "How are we doing?" The survey has many names. The name hardly matters. The process is almost always the same. Employees are encouraged to be honest. Leadership promises to listen. The results arrive a few weeks later. A dashboard appears. Scores turn green, orange or red. Trends are compared to previous years and benchmarked against other organizations. And then something interesting happens. The organization starts explaining the results before it has really listened to them. The first reaction is almost never curiosity I've seen the same pattern more than once. Leadership gathers around a table to review the results. Some comments are dismissed as unrealistic. Others are explained away. "It's only a snapshot." "People don't see the full picture." "The reorganization clearly influenced the scores." "One department pulled the average down." Sometimes those explanations are entirely reasonable. But they all have one thing in common. They explain the outcome before they explore it. That subtle difference matters. Because the purpose of listening isn't to defend your decisions. It's to understand why people experienced them differently than you expected. Measuring trust doesn't create trust Organizations often invest significant time and money in measuring employee satisfaction. Ironically, they spend far less time creating the conversations that actually improve it. A survey can tell you that trust is low. It cannot explain why. It certainly cannot rebuild it. Trust isn't restored by presenting another PowerPoint with action points. It is restored when people believe someone genuinely wants to understand their experience. Not to agree with everything they say. But to understand it. We keep scaling the wrong thing One of the biggest mistakes organizations make is assuming that more data automatically leads to better leadership. It doesn't. If anything, leadership becomes more difficult when hundreds of comments are compressed into percentages, averages and trend lines. The individual disappears. The story disappears. The nuance disappears. By the time the executive team receives the report, employees have become statistics. That may be useful for reporting. It is rarely useful for understanding people. Leadership happens at dinner tables Imagine something different. Not another annual survey. Not another company-wide town hall where only the confident voices ask questions. Imagine inviting eight employees to dinner every month. No presentation. No agenda. No managers. No HR representative taking notes. Just a conversation. People from different teams. Different ages. Different backgrounds. Different perspectives. Some who have been with the company for fifteen years. Some who joined three months ago. No expectation that everyone will agree. No expectation that every suggestion will be implemented. Just a conversation where people are free to say what they genuinely think. Not because leadership needs more data. Because leadership needs more understanding. People don't expect perfection One of the biggest misconceptions in leadership is that employees expect every problem to be solved. Most don't. People understand that organizations have budgets. Priorities. Customers. Shareholders. Trade-offs. What they struggle with isn't disagreement. It's silence. If an idea isn't feasible, explain why. If priorities changed, explain why. If you disagree, explain why. Adults can handle disagreement remarkably well. What slowly destroys trust is the feeling that feedback disappears into a system that quietly moves on. The purpose of leadership isn't agreement A good leader doesn't exist to validate every opinion. Nor should they. Leadership requires making decisions that not everyone will support. That's part of the responsibility. But responsibility comes with another obligation. People deserve to understand why decisions were made. Not because it guarantees agreement. Because it demonstrates respect. Being heard and getting your way are two very different things. Confusing the two helps nobody. The survey isn't the problem Employee surveys have value. They reveal patterns. They identify trends. They help leaders recognize blind spots. The problem begins when the survey becomes the conversation. Or worse, when it replaces it. Culture isn't built through anonymous questionnaires. It is built through thousands of interactions in which people discover whether their voice genuinely matters. The best organizations don't treat feedback as an annual event. They make listening part of how they lead. Closing Words Organizations often ask employees one important question every year: "How are we doing?" Perhaps leaders should ask themselves another: "When was the last time I had a conversation where someone felt completely free to disagree with me?" Because culture is not measured by a survey. Trust is not created by a dashboard. And leadership is not demonstrated by publishing an action plan. It is demonstrated by listening before explaining. By responding before defending. And by creating an environment where people continue speaking—not because they expect to win every discussion, but because they know someone is genuinely willing to hear it.

Digital sovereignty is not where your cloud runs

Organizations often talk about digital sovereignty as if it is a geographical problem. As if moving workloads from one region to another, or choosing a “European cloud”, somehow resolves it by default. That framing is comfortable. It is also misleading. Because digital sovereignty is not defined by where your cloud runs. It is defined by what you depend on, who controls those dependencies, and how quickly that control can shift without you noticing. And in most modern architectures, those answers are far less reassuring than organizations assume. The illusion of location-based control One of the most persistent misunderstandings in cloud strategy is the idea that data residency equals sovereignty. If data is stored in a specific country or region, the thinking goes, it must be under that jurisdiction’s control. Therefore, the organization is sovereign. But sovereignty is not a storage property. It is an operational condition. Modern cloud environments separate storage, compute, identity, observability, orchestration, and security into distributed services. Even if data is physically stored within a defined region, the control plane often is not. Identity providers, logging systems, container orchestration, key management services, and telemetry pipelines may all cross borders by design. And each of those layers introduces external dependency. So what looks like sovereignty at the infrastructure layer can still be deep dependency at the control layer. The real dependency map is not obvious Most organizations can tell you where their workloads run. Far fewer can explain:Who controls their identity system Where authentication and authorization decisions are evaluated Which external APIs are critical to deployment pipelines How secrets are managed and rotated What happens if a major cloud control plane becomes unavailableThese are not edge cases. They are core architectural facts. Yet they are often treated as implementation details rather than strategic dependencies. The result is a mismatch between perceived autonomy and actual control. A system may look sovereign on a slide deck while being tightly coupled to a small number of global providers in practice. Sovereignty is not binary Another common mistake is treating digital sovereignty as a yes-or-no state. Either you are sovereign, or you are not. Reality is more nuanced. Sovereignty exists on a spectrum of control across multiple dimensions:Data sovereignty: Where data is stored and under which legal regimes it falls Operational sovereignty: Who can change, deploy, or interrupt systems Technical sovereignty: How replaceable core components are Economic sovereignty: How easily costs can be influenced externally Vendor sovereignty: How dependent you are on specific providers or ecosystemsAn organization can be strong in one dimension and weak in another. For example, you might host data locally while remaining fully dependent on a single global identity provider. Or you might have multi-cloud infrastructure but still rely on one provider’s proprietary orchestration layer. Calling this “sovereign” or “not sovereign” misses the point entirely. The real question is: where are you constrained without realizing it? Cloud convenience is a design trade-off Cloud platforms are powerful because they reduce complexity. Managed services remove the need to operate infrastructure at scale. APIs abstract away operational burden. Integrated tooling accelerates delivery. But every abstraction is also a dependency. When you adopt a managed database, you gain operational simplicity. You also accept a specific backup model, a specific failover mechanism, and a specific pricing structure. When you adopt a managed identity provider, you gain security and standardization. You also accept that authentication is no longer fully under your control. These are not flaws. They are trade-offs. The problem arises when organizations treat these trade-offs as reversible defaults rather than strategic commitments. The hidden concentration of control Over time, cloud adoption tends to concentrate control rather than distribute it. Even in multi-cloud environments, the same patterns emerge: One provider becomes the primary identity source One ecosystem dominates observability One pipeline tool becomes the standard deployment mechanism One set of APIs defines infrastructure behavior This is not accidental. It is the natural outcome of efficiency seeking. But concentration introduces fragility. Not necessarily technical fragility in the form of outages, but strategic fragility: reduced negotiating power, limited exit options, and increasing difficulty to redesign systems without significant disruption. The more optimized a system becomes around a single ecosystem, the less sovereign it tends to be. The uncomfortable question: what can you actually replace? A practical way to evaluate sovereignty is not to ask where systems run, but what would happen if key components disappeared. Not hypothetically in a disaster scenario, but structurally:If your identity provider changes terms or access, how fast can you switch? If your primary cloud provider increases costs significantly, what breaks first? If a critical managed service is discontinued, do you have an exit path or just a migration project? If external connectivity is restricted, which parts of your architecture stop functioning immediately?These questions are uncomfortable because they expose design assumptions that are usually left unchallenged. Most organizations discover that their “sovereign” architecture contains far fewer independent components than expected. Sovereignty requires intentional friction True digital sovereignty is not achieved by avoiding cloud platforms. It is achieved by designing for optionality, even when it introduces friction. That can include:Avoiding unnecessary proprietary abstractions in core systems Designing data portability as a requirement, not a future task Separating identity from infrastructure providers Maintaining documented, tested exit strategies for critical services Ensuring that no single provider becomes a structural bottleneckNone of these decisions are purely technical. They are architectural governance choices. And they often conflict with short-term efficiency goals. Which is why they are frequently postponed. Leadership, not infrastructure, defines sovereignty At its core, digital sovereignty is not a cloud architecture problem. It is a leadership problem. Because the hardest part is not building systems that are portable or independent. The hardest part is deciding when dependency is acceptable and when it is not. Every organization will rely on external platforms. The question is not whether dependency exists, but whether it is understood, measured, and intentionally managed. Without that clarity, sovereignty becomes a narrative rather than a capability. Closing thought Digital sovereignty is not where your cloud runs. It is whether you could still operate if your assumptions about that cloud stopped being true. And in most modern architectures, that question is less theoretical than it seems.