Showing Posts From

Strategy

Seeing opportunities with AI

Artificial Intelligence (AI) is changing the way businesses operate, offering new opportunities and challenges. As a C-level executive, it's important to understand how AI can benefit your company while managing the risks involved. Setting Your AI Goals First, you need to decide what you want to achieve with AI. Do you want to use it to improve internal processes or to create new products and services? Your ambition will guide your strategy and set realistic goals. For example, AI can help streamline back-office tasks, making them faster and more efficient. Or, you might use AI to offer personalized customer experiences, which can lead to higher customer satisfaction and loyalty. Choosing the Right Approach Next, consider how you will implement AI. There are different ways to do this. You can use pre-built AI tools that are already available. This is quick and doesn’t require much technical knowledge, but it may not fit your specific needs perfectly. Alternatively, you can adapt existing models with your own data to make them more tailored to your business. This approach is more flexible but requires more expertise. Lastly, you can develop your own AI system from scratch. This gives you full control but is more expensive and time-consuming. Choosing the right path is crucial. It affects how quickly you can start using AI and how much it will cost. For instance, if your goal is to quickly improve customer service, a pre-built solution might be the best choice. If you need a highly customized solution for a specific problem, developing your own AI system might be necessary. Navigating the Risks Using AI also comes with risks. These include unreliable outputs, data privacy issues, cyber threats, and regulatory concerns. For example, AI systems can sometimes produce incorrect or unexpected results. This can happen if the data used to train the AI is flawed or if the system encounters new situations it hasn’t seen before. Ensuring data privacy is crucial, especially when handling sensitive information. You need to comply with regulations like GDPR in Europe or HIPAA in the U.S. Cyber threats are also a concern. AI systems can be targeted by hackers, putting your data at risk. This means you need to have robust cybersecurity measures in place. Additionally, different countries have different rules about AI, and you need to follow them. This can be complex, as regulations can change quickly and vary widely. For instance, regular audits and compliance checks can help ensure you stay within legal boundaries. Leading with Vision and Prudence Leading with AI requires a balanced approach. You need to support innovation while also ensuring safety and ethical considerations. This involves engaging stakeholders, balancing speed and caution, and fostering a culture of learning. Engaging stakeholders means talking to everyone involved, from developers to end-users, to get their input and support. This helps build a sense of ownership and alignment. Balancing speed and caution is also important. You need to move fast to stay ahead of competitors but take time to ensure your AI is reliable and secure. Fostering a culture of learning means encouraging your team to learn about AI and keep up with new developments. This helps keep your organization ahead of the curve. Wrapping Up AI offers a unique chance for C-level executives to drive growth and innovation. However, it also presents significant challenges. By carefully planning and managing risks, you can use AI to improve your business and stay ahead of the competition. In summary, leading with AI means setting clear goals, choosing the right deployment strategy, and being prepared for risks. With the right approach, you can unlock the full potential of AI for your organization. True leadership means guiding your company through the complexities of AI with vision and resilience.

Co-managed IT explained: who is really responsible?

Choosing how to run your IT infrastructure is one of the most important strategic decisions a business can make. However, many business leaders struggle with confusing terminology in the IT service provider landscape. Terms like co-managed IT, co-sourcing, fully managed services, and co-creation are often used incorrectly, leading to failed partnerships and unclear expectations. Understanding what these models actually mean, how responsibilities are divided, and how financial billing works is essential before signing any contract. The landscape of IT management models To make informed choices, business leaders must clearly distinguish between the different ways IT services can be delivered and organized. Under an insourcing model, a business handles all technology needs internally by hiring and managing its own personnel. Outsourcing, by contrast, transfers an entire process or department to an external provider who guarantees specific performance targets. Co-sourcing takes a staff augmentation approach by bringing in external personnel to work under your internal team's direction, adding temporary capacity without shifting operational control. Service delivery models also differ in scope and management approach. A standard managed service focuses on buying a specific functional outcome under a strict agreement, while remote managed services rely on software tools to monitor systems from a distance. Fully managed services go a step further by handing over complete operational responsibility for the entire IT environment to an external partner. Finally, co-managed IT involves an internal team and a provider managing a domain together, whereas co-creation focuses on jointly developing new digital products rather than managing existing systems. Deep dive into co-managed IT: what it is and what it is not Co-managed IT is often misunderstood in the service provider market, where it is frequently confused with buying extra staff or single software tools. In reality, a true co-managed setup is a joint operational partnership. Both the internal IT team and the external provider actively manage a specific domain together by sharing access to management platforms, support queues, and daily workflows. Both parties share equal accountability for system health, overall uptime, and cybersecurity. This approach is fundamentally different from other sourcing arrangements. It is not co-sourcing because co-sourcing merely supplies extra hands without transferring operational accountability to the vendor. It is also distinct from co-creation, which develops new intellectual property, and traditional outsourcing, which removes the internal team from daily operations entirely. Companies select co-managed models when they have a capable internal team that understands the business, but needs enterprise-grade tools, 24/7 coverage, and specialized knowledge. Financially, co-managed services usually rely on a predictable monthly fee per user or device, combined with set rates for project support. Deep dive into co-creation: what it is and what it is not Co-creation is another term that is often misused when organizations confuse custom software development with operational IT management. At its core, co-creation is a collaborative development strategy where a client and a technology vendor build a software tool together. The client provides domain expertise, practical feedback, and operational requirements, while the vendor contributes technical architecture, software engineering, and scalable infrastructure. This model should not be confused with standard custom software development, where a client pays the full cost to keep exclusive rights. Nor should it be mistaken for co-managed IT or co-sourcing, as co-creation focuses on building new digital tools rather than supporting daily IT operations. Businesses choose co-creation when standard commercial software falls short, but building custom tools alone is financially unfeasible. Financially, the client typically receives lower development rates or early software access. In return, the vendor retains the core intellectual property and creative freedom, allowing them to market and sell the solution to other commercial customers. The shared responsibility model: operational versus legal reality When working with an external IT partner, dividing responsibilities correctly is critical to avoiding operational gaps and legal surprises.IT Sourcing Model Operational Execution Operational Responsibility Legal Accountability Common Billing StructureInsourcing Internal staff Internal IT management Internal business board Internal salaries and capital spendOutsourcing External provider External service provider Internal business board Fixed monthly contract or service feeCo-sourcing Internal staff & external personnel Internal IT management Internal business board Time and materials or daily ratesCo-managed Shared internal and external team Joint shared responsibility Internal business board Fixed fee per user/device + project rateCo-creation Joint development team Joint development leadership Internal business board Discounted dev fees + IP retentionFully Managed External provider External service provider Internal business board Fixed monthly fee per user or deviceOperationally, you can delegate tasks and share daily responsibilities with a partner. In a co-managed environment, the vendor might handle backup management and software patches while your internal team supports end users. If a backup fails due to vendor negligence, the vendor is operationally accountable based on agreed service levels. However, legal responsibility works very differently. Regulators and courts hold your board of directors legally accountable if a cyberattack occurs or privacy laws are violated. While you can seek financial damages from a partner for breach of contract, ultimate legal accountability remains with your business. Closing thoughts Modern IT management requires a clear understanding of where effort ends and true responsibility begins. Misidentifying your sourcing model leads to operational confusion, unfulfilled promises, and unmanaged business risk. By defining roles, financial structures, and legal boundaries early, organizations can build effective partnerships that protect their operations. True IT partnerships are built on shared operational accountability, but business leaders must remember that legal responsibility can never be outsourced.

Large vs. Small Language Models: Understanding the differences and choosing the right tool

In the early days of generative artificial intelligence, tech companies believed one main rule: bigger is always better. Massive AI models like OpenAI's GPT-4, Google's Gemini Ultra, and Meta's Llama-3 proved that adding hundreds of billions of parameters unlocked incredible skills. These models could solve complex logic problems, write software, and translate languages easily. However, a new trend is taking over the tech world: Small Language Models (SLMs). Models such as Microsoft's Phi-3, Google's Gemma, and Meta's Llama-3-8B show that smaller models can also be smart, fast, and much cheaper to use. To understand the AI landscape today, models are generally divided into three main categories:Large Language Models (LLMs) [70B+ Parameters]: Massive models trained on huge amounts of internet data. They require powerful cloud servers to run and act as general-purpose experts. Medium Language Models [13B to 70B Parameters]: Balanced models that offer strong reasoning skills while still being easier for companies to host privately. Small Language Models (SLMs) [1B to 10B Parameters]: Compact models designed to run efficiently on small hardware, such as regular laptops, smartphones, or small internal company servers.Hardware constraints: Why model size matters To understand why SLMs are becoming so popular, we need to look at computer hardware, specifically graphics memory (VRAM) and speed. Memory requirements (VRAM) To run an AI model, its weights (parameters) must be loaded directly into a computer's high-speed graphics memory.A large 70-billion parameter model needs around 140 GB of VRAM to run at standard quality. This requires high-end enterprise hardware costing tens of thousands of dollars. In contrast, a small 8-billion parameter model can be compressed (quantized) to run using less than 5 GB of VRAM. This means it can easily run on a standard work laptop or a modern smartphone.Speed and latency Big models need to move massive amounts of data back and forth through hardware every time they generate a word. Smaller models carry much less data, which allows them to generate text much faster. This makes SLMs ideal for real-time tasks like live customer chat or typing assistance. How small models get so smart How can a small model perform almost as well as a giant model from a few years ago? The secret lies in high-quality data and smart training techniques. Traditional LLMs learn from raw internet text (billions of webpages, social media posts, and slang). Modern SLMs, on the other hand, learn from curated, high-quality "textbook" data and simplified lessons from larger models.Filtered Synthetic Data: Instead of learning from random internet chatter, modern SLMs are trained on clean, high-quality data created by larger AI models. This includes clear coding examples, textbooks, and step-by-step logic exercises. Knowledge Distillation: This is a process where a large "Teacher" model helps train a smaller "Student" model. The student learns to copy the reasoning patterns of the teacher without needing the giant memory size.Key differences at a glanceFeature Large Language Model (LLM) Small Language Model (SLM)Model Size 70B to 1 Trillion+ parameters 1B to 10B parametersHardware Needed Massive enterprise GPU servers Standard laptops, phones, single GPUsMemory Footprint Very High (100GB+ VRAM) Low (2GB to 10GB VRAM)Response Speed Slower for large answers Extremely fast generationOperating Cost High cloud API or server fees Very cheap to host locallyData Privacy Data usually sent to the cloud Data can stay fully on your local deviceCombining SLMs with company data (RAG) Many organizations assume they need a giant AI model to understand their company's internal files. However, using an AI model as a giant memory bank is inefficient and often leads to false answers (hallucinations). Instead, smart companies combine Small Language Models with a system called Retrieval-Augmented Generation (RAG):Step 1: User asks a question. Step 2: The system searches internal company documents for the facts. Step 3: The exact document text is given to the SLM. Step 4: The SLM reads the text and writes a clear answer.Because the SLM does not need to memorize all company facts inside its parameters, a small 8B model paired with RAG often outperforms a large, expensive LLM at a fraction of the cost. When to choose an LLM vs. an SLM Choosing the right model depends on your specific goals, budget, and privacy requirements. Choose a Large Language Model (LLM) when:You need complex reasoning: Writing complicated software code, analyzing vague legal documents, or solving advanced scientific problems. You build autonomous agents: AI systems that need to plan multiple steps and interact with external tools independently. Your queries are unpredictable: Your application covers many completely different subjects without a fixed focus.Choose a Small Language Model (SLM) when:Speed is critical: Applications like real-time translation, autocomplete, or instant customer support. Privacy is mandatory: Healthcare, finance, or legal tasks where data cannot leave the local building or device. You operate on a budget: Running high volumes of daily requests without paying expensive cloud API subscription fees.Closing thoughts Artificial intelligence is no longer just about building the largest possible model. While giant LLMs remain important for cutting-edge research and complex logic, Small Language Models are proving to be the most practical choice for daily business operations. By using clean training data, clever optimization, and targeted document systems, SLMs deliver fast, private, and cost-effective performance. The best AI architecture is not about using the biggest model available, but finding the smallest model that can solve your problem effectively.

The AI productivity paradox: Why more tools aren't saving us time

Artificial intelligence has spread faster than almost any other technology in human history. Today, workers across every industry use generative AI daily. They use it for writing reports, designing presentations, writing software, and summarizing long meeting notes. Major software companies have embedded AI directly into our email clients, office suites, and project dashboards. On paper, this should save us hours of work every week. Yet, if you look at modern business statistics, overall productivity has barely moved. Many business leaders are left asking the same frustrating question: If everyone is using AI, why is work not getting done any faster? This situation is not actually new. It is a modern version of the famous "productivity paradox" observed by economist Robert Solow in the 1980s. Back then, he noted that computers were visible everywhere except in the economic productivity numbers. Today, AI faces the exact same challenge. Why AI saves minutes, not whole processes The main reason for this productivity gap is simple: most people use AI to speed up small, isolated tasks rather than fixing full workflows. For example, a customer service agent might use AI to draft a quick reply to an email. The drafting takes five seconds instead of five minutes. However, that message still needs manual review, manager approvals, and input into old database systems. The bottleneck simply moves to another part of the process. In addition, several hidden time-wasters prevent AI from delivering its full potential:The Double-Checking Burden: AI outputs are rarely perfect on the first try. Employees end up spending significant time checking facts, correcting hallucinations, and editing formatting. Tool Overload: Organizations often use multiple specialized AI tools at the same time, such as ChatGPT, Claude, Midjourney, and GitHub Copilot. Deciding which tool to use and switching between them creates mental fatigue. The "More Content" Trap: Because creating documents and emails has become easier, companies generate much more of them. This creates a massive ocean of reports and emails that other employees must spend time reading. Constant Context Switching: Workers constantly jump between Slack messages, email, AI chats, and project boards, which drains mental energy throughout the day.What history teaches us about real efficiency MIT economist Erik Brynjolfsson points out that groundbreaking technologies rarely boost productivity immediately. He compares the current adoption of AI to the arrival of electricity in factories during the late 19th century. When factory owners first replaced steam engines with electric motors, productivity did not go up right away. It was only when they completely redesigned factory layouts and assembly lines around electricity that output exploded. Old Approach: [Standard Process] + [Add AI Tool] = Minimal Time Saved New Approach: [Redesigned Process Built for AI] = Massive EfficiencySimilarly, Wharton professor Ethan Mollick emphasizes that AI works best as a collaborative partner rather than a basic tool. Companies that see massive productivity gains do not just give their workers an AI login; they fundamentally rethink how work gets done. Real-world example: Support & software developmentCustomer Support: Instead of using AI just to suggest email templates, leading companies let AI agents sort tickets, handle routine queries autonomously, and route complex edge cases directly to human experts. Software Engineering: Rather than using AI merely to write single lines of code, teams integrate AI across the whole cycle—from initial architecture planning and automated unit testing to security checks and documentation.Looking ahead: The shift to autonomous agents We are currently moving from simple AI assistants toward autonomous AI agents. New multimodal agentic systems—like Alibaba’s Qwen 3.7 Plus—can look at user interfaces, click buttons, navigate websites, and complete multi-step tasks across different software without constant human prompting. As these tools mature and become affordable to deploy, the central question for businesses will change. It will no longer be "Should we use AI?" but rather "How must we redesign our work to let AI perform whole tasks effectively?" Closing Thoughts Having access to the most powerful AI tools in the world will not automatically make your team faster or smarter. Technology only provides the raw capability; real success depends on how thoughtfully you restructure your daily habits, workflows, and organizational structures to support it. True productivity in the AI era is not about doing old tasks faster. It is about designing completely new ways of working.

Stop using engineers as shock absorbers

Look at almost any modern tech job advertisement today, and you’ll see the exact same list of benefits: “Flexible hybrid work, autonomous culture, latest hardware, and regular team events.” Yet, despite these perks, tech companies worldwide face a persistent crisis: their highest-performing senior engineers and tech leads are silently walking out the door. Industry data confirms this gap. According to global developer experience benchmarks, over 65% of senior engineering turnover is driven by organizational friction and administrative noise, rather than technical difficulty or compensation. Developers do not quit because of a lack of team socials or fruit baskets. They leave when their day-to-day job becomes buffering their team against executive indecision, sitting in low-value alignment meetings, and blunting structural chaos. The "Human shock absorber" In many growing software organizations, a subtle leadership failure occurs as teams scale. When executive boards struggle to establish clear strategic boundaries or resolve cross-departmental friction, they quietly delegate that responsibility downward. They create what can only be called a Frankenstein Role: a Tech Lead or Staff Engineer who is asked to be 100% hands-on architect, 100% people coach, and 100% process firefighter. Instead of solving complex technical problems or building scalable cloud architectures, your highest-paid technical experts become human shock absorbers. They spend up to half their working week absorbing leadership noise, translating vague goals, and mediating conflicts that should have been settled at the C-level. Research on developer cognitive load shows that modern software engineers spend less than 30% of their actual workday writing code or designing software. The remaining time is consumed by context-switching, status updates, and navigating organizational friction. The real math behind senior engineering turnover When a burned-out senior engineer or lead resigns from a bloated role, the financial damage on the P&L statement is far larger than most executives realize. The true total cost of losing a key technical figure can be broken down using standard engineering talent benchmarks:Cost Category Impact Level DescriptionDirect Replacement Costs Significant Agency fees, interviewing hours, sign-on packages, and competitive market salaries for senior talent.Onboarding & Ramp-Up Substantial Lost productivity during the 6 to 9 months it takes a new senior engineer to master a complex codebase.Contagion Effect (Domino Turnover) High Risk McKinsey research shows that when a respected lead quits, team members are up to 35% more likely to leave within 6 months due to increased workload and chaos.Roadmap & Market Delay Severe Slid delivery dates, delayed feature releases, and missed market opportunities.Plaguing your organization with high turnover isn't a recruitment issue—it is a direct leadership leak. You can't code out of broken governance With the rapid adoption of AI coding assistants, agentic dev-tools, and automated testing suites across engineering teams, leadership teams often assume tech investments will solve their productivity bottlenecks. However, recent studies on AI engineering adoption highlight a clear contradiction: While AI assistant tools improve individual line-of-code generation by 15% to 20%, total organizational delivery velocity in chaotic companies improves by less than 3%.Why? Because generating code was never the primary bottleneck. If your decision-making process is slow, your boundaries are blurry, and your teams are misaligned, AI tools simply help your developers build the wrong things faster. Buying AI licenses to compensate for poor organizational design is one of the most expensive escape routes on an IT balance sheet. You cannot solve a structural leadership deficit with a software subscription. How to sanitize your engineering leadership Restoring execution speed and retaining top-tier engineering talent requires structural clarity at the top. You don't need another soft skills workshop, agile transformation, or internal culture initiative. You need clean leadership architecture: 1. Keep C-suite accountabilities at C-level Executives must set firm strategic priorities, establish binary boundaries, and clean up inter-departmental politics. Never ask a Tech Lead or Engineering Manager to resolve organizational friction without giving them explicit executive authority. 2. Ruthlessly separate technical roles from line management Stop expecting senior engineers to be elite software architects and full-time people managers simultaneously. Create clear, parallel career tracks:Individual Contributor (IC) Track: Focused 100% on architecture, technical execution, and code quality. Engineering Management Track: Focused on people development, resource allocation, and team enablement.3. Measure friction, not just output Instead of tracking raw output or ticket velocity, measure organizational friction:How many hours a week do senior leads spend in alignment meetings? How often do decisions made at the top get reopened three weeks later? How long does it take to get a clear 'yes' or 'no' on technical decisions?Closing thought Senior A-players in software engineering do not leave companies because the work is hard. They leave when the work is made unnecessarily chaotic by a lack of leadership structure. The next significant improvement to your bottom line and product delivery won't come from a new framework, a recruitment drive, or another AI tool. It will come from eliminating the hidden operational friction that is draining your lead engineers today. Ask yourself: Is your executive team providing clear boundaries for your engineers to build great products, or are you using them as human shock absorbers for organizational noise?

The ungoverned cloud: Why cloud strategies fail at execution.

In boardrooms across Europe, cloud strategy is undergoing a harsh reality check. For years, the narrative was centered on speed and migration. Today, executive teams face a very different set of challenges: unpredictable cloud expenditure, strict regulatory mandates (NIS2, BIO2, EU AI Act), and diffuse operational accountability. When external audits reveal that two-thirds of cloud environments lack proper control, the executive reflex is predictable: install a heavy Governance Board, write 80-page policy manuals, and require manual sign-offs for every change. This approach fails every time. It creates shadow IT, paralyzes delivery teams, and fails to eliminate actual risk. Personally, I view cloud governance not as a bureaucratic brake, but as an operational operating system. True governance provides clear guardrails, automated compliance, and organizational clarity—allowing engineering teams to move fast safely. To achieve this, organizations must move away from theoretical policies and implement a functional Cloud Center of Excellence (CCoE).The 5 pillars of cloud governance Before structuring your team, you must define what cloud governance actually encompasses. Mature cloud governance covers five distinct operational domain pillars:Pillar 1: Financial Management (FinOps)Shifting from static annual IT budgets to dynamic unit economics, continuous cost allocation, and real-time optimization.Pillar 2: Security & Regulatory Compliance (NIS2 / BIO2)Enforcing baseline controls aligned with NIS2, BIO2, ISO 27001, and GDPR across all cloud landing zones.Pillar 3: Automation & Platform EngineeringEliminating manual infrastructure configuration through Infrastructure as Code (IaC) and automated developer platforms.Pillar 4: Identity & Data Control (Zero Trust)Implementing Zero Trust architecture, strict least-privilege principles, and explicit data boundaries.Pillar 5: AI & Emerging Tech Governance (ISO/IEC 42001)Setting parameters for responsible AI use under the EU AI Act and ISO/IEC 42001, preventing unmanaged shadow-AI implementations.What is expected of C-level leadership? Cloud governance cannot be delegated away to IT or a compliance team. Real governance requires active C-level involvement, clear sponsorship, and strategic alignment. Here is what is explicitly expected of executive leadership across each core domain:C-Level Role Core Executive Expectation & Operational ResponsibilityChief Executive Officer (CEO) & Board Treat Cloud Governance as Risk Management: Recognize that cloud failure, data breaches, and non-compliance carry direct board liability under NIS2. Establish risk appetite boundaries and mandate cross-functional governance across the company.Chief Operating Officer (COO) Align the Operating Model & CCoE Mandate: Provide the CCoE with formal authority to set organizational standards. Break down functional silos between IT, Security, and Business units, ensuring that delivery speed never bypasses compliance.Chief Financial Officer (CFO) Enforce Financial Accountability (FinOps): Shift financial oversight from traditional CapEx IT depreciation to dynamic OpEx management. Demand unit-cost transparency and require Business/Product Owners to account for cloud consumption within their P&L.Chief Information / Technology Officer (CIO/CTO) Drive Modern Architecture & Enablement: Transition engineering teams away from manual ticketing towards self-service platforms (IDPs). Enforce "Policy as Code" and ensure cloud infrastructure aligns with architecture goals.Chief Information Security Officer (CISO) Automate Guardrails Over Gatekeeping: Move from reactive security reviews to proactive, automated policy enforcement. Integrate NIS2, ISO 27001, and AI compliance directly into deployment pipelines.Key Leadership Takeaway: Executive leadership is not expected to manage cloud settings or review code. Leadership is expected to set parameters, grant mandate, enforce accountability, and model the culture required for operational discipline.Enablement, not control The central execution engine of cloud governance is the Cloud Center of Excellence (CCoE). Too many companies misinterpret the CCoE as an architectural approval committee that meets every Thursday to review tickets. That is the quickest way to kill organizational momentum. Gatekeeper vs. EnablementAnti-Pattern: The Gatekeeper CCoE Modern Pattern: The Enablement CCoEManually reviews and approves architectural change requests. Builds automated guardrails and self-service templates.Writes static policy PDFs that engineers rarely read. Embeds policy directly into deployment pipelines (Policy as Code).Acts as a centralized bottleneck for cloud adoption. Functions as an internal product team serving delivery teams.Measures success by policy compliance and audit logs. Measures success by engineering velocity, security, and cost efficiency.Structure & core roles A successful CCoE is a lean, cross-functional team that brings together key domains. It does not replace engineering teams; it empowers them.Executive Sponsor (COO / VP Operations): Secures budget, aligns governance with corporate P&L goals, and resolves organizational friction between business units. Cloud Lead / Architect: Defines overall multi-cloud strategy, Landing Zone standards, and reference architectures. Cloud Security & Risk Specialist: Translates regulatory requirements (NIS2, ISO 27001, EU AI Act) into actionable security policies and automated checks. Platform Lead / Software Architect: Drives Platform Engineering, building Internal Developer Platforms (IDPs) and self-service "Golden Paths". FinOps Practitioner: Analyzes cloud consumption data, establishes unit-cost metrics, and works directly with product owners on cost accountability.Practical implementation: A 4-phase roadmap Implementing cloud governance across an organization requires a phased, practical approach. Phase 1: Establish the charter & landing zone architectureDefine the CCoE Charter: Formally declare the team's purpose, scope, and mandate across the business. Build Landing Zones: Create standard multi-account cloud structures (e.g., AWS Organizations or Azure Management Groups). Isolate workloads by environment (Dev, Test, Prod) and business unit. Implement Centralized Logging: Ensure audit trails, identity logs, and network traffic are automatically ingested into a central SIEM system from day one.Phase 2: Automate guardrails (Policy-as-Code)Define Preventive & Detective Controls: Use native cloud policies (e.g., Azure Policy, AWS Service Control Policies) to enforce mandatory constraints: Preventative: Block public S3 buckets or unencrypted storage volumes from ever being created. Detective: Automatically flag and alert security teams when a resource drifts from baseline configuration.Tagging Strategy Enforcement: Mandate metadata tags (Owner, CostCenter, Environment, DataClassification) at deployment time. If a resource lacks tags, auto-remediate or reject the build.Phase 3: Platform engineering & self-service (Golden Paths)Build the Internal Developer Platform (IDP): Provide engineering teams with a self-service portal (e.g., Backstage) to provision compliant infrastructure in minutes. Publish Golden Paths: Pre-package approved architectures (e.g., secure microservice deployment, compliant SQL cluster) that include security, monitoring, and backups by default. Community of Practice: Establish cloud guilds to train product teams, share best practices, and accelerate internal skills development.Phase 4: FinOps maturity & Responsible AI governanceShift-Left Cost Management: Integrate cost-estimation tools into CI/CD pipelines so developers see the estimated monthly bill before merging code. Establish AI Guardrails: Deploy private API endpoints for Generative AI. Ensure corporate data is isolated and protected under strict tenant boundaries. Continuous Executive Dashboards: Provide board-level visibility into compliance posture, operational risks, and cloud cost efficiency.What the board needs to see To ensure your CCoE is delivering real value, track concrete operational metrics rather than subjective milestones:Metric Target / Good Practice Executive FocusLanding Zone Coverage > 95% of workloads in governed Landing Zones Risk & ComplianceUntagged Cloud Resources < 2% of total cloud assets Financial AccountabilityPolicy Drift MTTR < 4 hours to remediate non-compliant resources NIS2 / Security PostureGolden Path Adoption > 80% of new microservices deployed via IDP Velocity & StandardizationCloud Unit Cost Decreasing cost per business transaction P&L & ScalabilityClosing thoughts Solving cloud governance is not a technical problem; it is an organizational design challenge. Relying on manual audits, reactive firefighting, and bureaucratic approvals inevitably leads to higher costs and increased business risk. True operational leadership means building a system where compliance, security, and cost control are automated and frictionless. By establishing a modern Cloud Center of Excellence, embedding Policy as Code, and adopting Platform Engineering, executive teams can bridge the gap between high-level strategy and ground-level execution. When governance is built directly into your operating model, compliance stops being a burden—it becomes a competitive advantage that enables rapid, resilient, and profitable growth.

Rolf Schutten
13 Aug, 2026

From waiting too long to moving ahead: Why Cbw and AI governance need one clear plan.

In the Netherlands, waiting until the very last moment to deal with new rules is very common. For a long time, the standard approach to IT security was simple: "They won't check us yet," or "Let's wait and see what others do." With the European NIS2 directive and the new Dutch cybersecurity law — the Cyberbeveiligingswet (Cbw) — that time is over. The laws are active, supervision is starting, and the final responsibility now sits directly with company directors and executive management. Viewing the Cbw as just a burden or a boring checklist is a mistake. At the same time, the EU AI Act and frameworks like ISO 42001 are coming at us fast. Treating these as completely separate projects will waste budget and burn out your team. The smartest move is to stop waiting and combine IT security and AI governance into one clear strategy. The Cyberbeveiligingswet (Cbw): Why waiting is no longer an option The goal of NIS2 and the Cbw is simple: raise the basic level of digital security across Europe. The old rules mostly applied to traditional vital sectors like energy and water. The new Cbw applies to many more organizations. Medium and large companies in logistics, food, chemistry, digital services, and IT providers (MSPs and MSSPs) now fall under the law. Because of this, supply chain security becomes a shared legal responsibility. Two core parts of the Cbw change how companies must operate:Duty of Care & Fast Reporting: Companies must prove they take the right technical and organizational security steps. If a major incident happens, strict rules apply: a first warning must be sent to regulators within 24 hours. Personal Board Responsibility & Mandatory Training: Directors can now be held personally responsible if they ignore basic security rules. On top of that, executives are legally required to take regular training to understand cyber risks. Leaving IT security completely to the IT department without director oversight is no longer allowed by law.BIO2 becomes law: Your foundation is already there For Dutch government bodies and their IT suppliers, an important change is happening. The Baseline Informatiebeveiliging Overheid (BIO2) is moving from a voluntary framework to a binding law under the Cyberbeveiligingsbesluit. While many organizations worry about this, the truth is that BIO2 gives you a solid foundation you might already own. It builds on well-known global standards:ISO/IEC 27001: The process foundation for security management (ISMS). It sets up risk checks, policies, and continuous improvement. CIS Controls: The practical, technical checklist. Where ISO tells you what goals to reach, CIS Controls give you a concrete list of actions (device management, multi-factor authentication, logging, and endpoint protection).If your organization already works with ISO 27001 or BIO2, you already cover most of the technical requirements of the Cbw. The AI side: Don't build another separate project At the same time, company boards are hearing about the EU AI Act and ISO 42001 (the standard for Artificial Intelligence management). The usual reaction is to push AI away: "Let's finish the Cbw project first. We will worry about AI in a few years." This is a missed opportunity. If you compare BIO2 and ISO 27001 with ISO 42001, you see something interesting: a company running a good ISO 27001 or BIO2 setup already covers 70% to 80% of what ISO 42001 requires. That is because AI management uses the exact same basics as normal IT security: risk checks, data rules, access management, supplier controls, and incident handling. You do not need to build a whole new management system. The specific "AI gap" The remaining 20% to 30% gap is very specific:AI Ethics & Fairness: Making sure algorithms work fairly without discrimination. Explanation & Human Control: Understanding how an AI tool reaches a decision and keeping a human in control (human-in-the-loop). Impact on People: Checking how the AI tool affects employees, customers, and privacy. AI Lifecycle Management: Checking data quality and monitoring if the AI model changes over time (data drift). AI Incident Handling: Preparing for new threats like prompt injection or accidental data leaks through AI tools.These extra steps are not a new system; they are just a direct addition to your current IT security setup. One integrated plan: Build it once The AI Act timeline moves forward regardless of your Cbw deadlines. Companies that treat these things as three separate projects — one for Cbw, one for ISO 27001, and one for AI — will pay three times as much for the same result. The practical order to follow is: BIO2 / ISO 27001 Foundation ➡️ CIS Controls (Technical Setup) ➡️ ISO 42001 (AI Extension) Practical steps to takeCombine Risk Checks: Add AI tools and algorithms directly to your existing risk lists in your security management system. Use Clear Technical Rules: Use CIS Controls to secure your cloud environments (like Microsoft Azure) to meet the requirements for both Cbw and ISO standards. Extend Your Security Policies: Add the specific ISO 42001 points for AI ethics and control directly into your daily processes. Train the Board: Combine the required Cbw training for directors with a practical update on AI risks and opportunities.Closing thoughts Putting off rules and regulations until the last minute no longer works. The Cyberbeveiligingswet, mandatory BIO2 rules, and the EU AI Act mean that IT security and AI are now direct topics for company leadership. Instead of running separate compliance projects, combining these standards into one clear plan turns a legal obligation into a practical advantage. You protect directors from liability, remain a trustworthy partner in your supply chain, and build a safe foundation to use AI effectively in your business.

The executive prompt playbook: Mastering context, techniques, and multi-agent AI

Many business leaders still view prompt engineering as a technical trick reserved for IT departments or junior analysts. They open a chat interface, type a vague question like "Draft a strategy for market expansion," and end up disappointed by a generic, middle-of-the-road answer. They assume the technology is overhyped, close the tab, and go back to traditional ways of working. This misses the fundamental nature of modern artificial intelligence. Prompting an AI model is not like typing a query into a search engine; it is an exercise in strategic delegation. If you give a brilliant human executive assistant a vague instruction without background information, you will receive a superficial result. But if you give that same assistant a clear strategic context, defined boundaries, and explicit expectations, you receive executive-grade work. The same principle applies to AI. For a modern board member or director, learning how to frame prompts, apply proven cognitive techniques, and structure multi-agent workflows is becoming a core leadership capability. The architecture of an executive prompt: Context and framing The single biggest mistake executives make with AI is omitting context. Large language models are designed to predict plausible text based on probabilities. Without specific framing, the model defaults to the average corporate jargon found across the open internet. To get sharp, actionable insights, you must anchor the AI inside your specific business reality. A high-performing executive prompt consists of five essential structural blocks: Role, Context, Task, Constraints, and Output Format. First, you establish the Role by telling the AI who it is supposed to be. Second, you provide the Context, explaining the background, market situation, or internal pressures surrounding the issue. Third, you define the Task with absolute clarity. Fourth, you set strict Constraints, specifying what the AI must avoid, what assumptions it must challenge, or what regulatory rules it must respect. Finally, you specify the Output Format, such as a structured memo or a risk matrix. [ROLE] Act as a conservative M&A advisor specializing in European industrial manufacturing.[CONTEXT] Our company is a mid-sized Dutch manufacturer ($150M revenue) considering acquiring a German competitor with strong software capabilities ($30M revenue). Our board is risk-averse, highly protective of existing cash flow, and concerned about cultural integration and hidden software maintenance debt.[TASK] Review the attached summary financial report and technical audit. Identify the top three strategic and operational risks associated with this acquisition.[CONSTRAINTS] Do not summarize the general benefits of M&A. Focus strictly on potential failure points. Assume interest rates will remain elevated over the next 36 months.[OUTPUT FORMAT] Provide a 1-page executive memo organized into three sections: Key Risk, Operational Impact, and Recommended Mitigation.Essential prompt techniques for executive decision-making Beyond basic prompt structure, executives can draw on specific prompt techniques to unlock far deeper strategic reasoning from AI systems. 1. Role-Based Prompting (Persona Framing) Instead of asking for general advice, you force the AI to look at a problem through a specific expert lens. By asking the system to evaluate a proposal as a skeptical activist investor, a strict compliance officer, or a disruptive tech founder, you quickly surface blind spots that a single perspective would miss. Act as a skeptical activist investor who has just taken a 5% stake in our company. Read our proposed three-year digital transformation roadmap attached below. Identify three initiatives in this roadmap that appear over-budgeted, unnecessary, or unlikely to deliver clear ROI within 18 months. Challenge our leadership assumptions aggressively, using concise, direct executive language.2. Chain-of-Thought (CoT) Prompting AI models perform significantly better when forced to explain their reasoning step-by-step before delivering a final answer. If you ask a complex strategic question directly, the model might rush to an oversimplified conclusion. By instructing the model to work through the logic systematically, you force higher decision quality. We are considering shifting our enterprise software pricing from a traditional fixed seat-based model to a usage-based consumption model. Before giving me your final recommendation, work through this decision step-by-step: 1. Analyze the immediate cash flow risks during the transition phase. 2. Evaluate how our sales compensation structure needs to adapt. 3. Assess customer retention risks among our largest conservative enterprise accounts. 4. Weigh the long-term upside against these operational hurdles.Show your reasoning for each step clearly before providing a final executive summary recommendation.3. Few-Shot Prompting (Learning by Example) If you want the AI to draft a strategic document, do not just describe the format—provide one or two examples of actual memos that reflect your preferred executive style. By showing the model what excellent work looks like in your company, the AI immediately matches the desired tone, structure, and depth. I need you to write a brief strategic update for our advisory board regarding our AI adoption policy. Below are two examples of previous memos I wrote that the board praised for their clarity, direct tone, and bulleted risk focus.---EXAMPLE 1--- [Insert past memo text here] ---END EXAMPLE 1------EXAMPLE 2--- [Insert past memo text here] ---END EXAMPLE 2---Draft a new memo regarding our proposed internal policy on employee use of generative AI tools. Mirror the exact tone, paragraph length, and bullet-point structure of the examples above.4. Meta-Prompting (Socratic Alignment) When facing a complex scenario where you are not even sure what questions to ask, you can instruct the AI to interview you first. This turns the AI into a thought partner that helps you clarify your own thinking before generating a single line of strategy. I need to draft a comprehensive AI governance framework for our healthcare organization, but the parameters are complex and I want to ensure we do not miss key operational details. Do not generate the framework yet. Instead, act as an expert risk management consultant and ask me 5 targeted questions, one at a time, about our current infrastructure, data privacy controls, and risk tolerance. Wait for my answer after each question before asking the next one. Once we finish all 5 questions, synthesize my answers into the final governance draft.Advanced techniques for complex strategic scenarios As executives deal with higher levels of business complexity, more advanced prompt techniques become necessary. 5. Generated Knowledge Prompting Before asking the AI to make a strategic judgment, you instruct the system to articulate and list key domain facts, regulatory constraints, and market truths first. This ensures the AI grounds its final recommendation on accurate underlying knowledge rather than high-level speculation. First, list the top five regulatory requirements under the European Union AI Act that specifically apply to automated risk-assessment software in financial services. Second, based strictly on those regulatory facts you just generated, evaluate our proposed AI credit-scoring workflow attached below and highlight where we are non-compliant.6. Tree of Thoughts (Scenario Branching) When evaluating major strategic crossroads, you can instruct the AI to explore multiple decision paths simultaneously, evaluate the failure points of each branch, and compare the outcomes before selecting the strongest path forward. Our logistics company is facing a 25% rise in fuel and operational costs. I want you to evaluate three distinct strategic responses: - Option A: Pass 100% of the cost increases directly to customers through a fuel surcharge. - Option B: Absorb the costs short-term while aggressively automating route planning to reduce total mileage by 15%. - Option C: Restructure customer contracts around longer delivery windows in exchange for fixed pricing.For each option, generate two potential downstream consequences (one positive, one negative). Then, evaluate which path offers the best balance of customer retention and margin protection over a 24-month horizon.7. Directional Stimulus Prompting This technique involves giving the AI explicit strategic anchors, keywords, or core themes to guide its analytical focus. It prevents the model from wandering into irrelevant topics and keeps the analysis tied directly to leadership priorities. Analyze our quarterly operational performance report. In your analysis, focus strictly through the following strategic anchors: [Cost Efficiency], [Supply Chain Volatility], and [Key Person Dependency]. Ignore general marketing or sales metrics. Provide a brief assessment explaining how our current performance impacts each of these three strategic anchors.Beyond single prompts: Orchestrating a multi-agent council While individual prompt techniques are powerful, the ultimate revolution in executive decision-making lies in multi-agent architecture. Instead of relying on one AI model to perform every task, you design a digital council of specialized AI agents, where each agent has a distinct role, personality, and set of responsibilities. In a multi-agent setup, the human executive moves from being the writer or analyst to becoming the chairman of the digital board. You set the agenda, monitor the debate between specialized agents, intervene when the discussion strays off course, and make the ultimate human decision based on synthesized insights. Act as the Chairman of an AI Advisory Board evaluating our entry into the US healthcare market. You will simulate a debate between three specialized board members before providing a final synthesis.Step 1: Have [Agent A: Chief Strategy Officer] present a 2-paragraph expansion argument focused on market size and revenue growth. Step 2: Have [Agent B: Chief Risk Officer] challenge Agent A's plan, pointing out three critical regulatory and legal hurdles in the US healthcare landscape. Step 3: Have [Agent C: CFO] analyze the financial trade-offs between both perspectives, focusing on cash burn and payback timelines. Step 4: As Chairman, summarize the core points of debate, resolve the conflicts between the agents, and present a final executive decision brief for the CEO.The executive mindset shift Mastering these techniques requires a fundamental mindset shift. You must stop viewing AI as an automated search box and start treating it as a team of highly capable, hyper-fast advisers who know nothing about your company until you brief them properly. The quality of the output you receive from AI is a direct reflection of the clarity of your own leadership. If your instructions are confused, your context is weak, and your boundaries are vague, the AI will return confusing, weak, and vague results. But when you master the art of framing, provide rich context, and orchestrate specialized agents, AI becomes an incredible lever for executive productivity and decision speed. Closing thought Technology will not replace strategic leadership, but leaders who know how to direct AI will rapidly replace those who do not. The goal of prompt engineering for executives is not to turn managers into programmers. It is about learning how to communicate intent, set clear boundaries, and demand rigorous thinking from digital systems. Stop asking AI for quick answers. Start giving it the strategic context it needs to deliver real executive value.

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.