Showing Posts From

Engineering

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.

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.

The tech literacy crisis: Why we are raising a generation unprepared for the real world

A worrying trend has been growing in secondary education over the past twenty years. In many middle schools, practical technology classes have quietly disappeared or seen their hours cut by more than half. This might look like a simple change in school schedules. But in reality, it shows a huge gap between what we teach our children and what our modern world actually needs. We are raising a generation that uses touchscreens every day, but has no basic understanding of how those devices are powered, built, or programmed. The big contradiction of our time We live in a world that relies heavily on fast technological growth. Almost every major challenge we face today requires real technical skills. We need:Energy transition experts to build solar grids, manage battery storage, and run modern power plants. Electronics and hardware engineers to design microchips, PCBs, and robotics. Software developers and cybersecurity specialists to keep our digital networks safe. Industrial construction engineers to build sustainable houses and modern factories.The demand for these technical specialists is higher than ever. Yet, our education system treats basic technology lessons like an optional hobby instead of an essential core subject. We expect young people to choose technical careers later in life, even though they barely get to touch practical engineering during their school years. From creators to passive consumers By removing technology education from schools, we create a passive mindset. When students never get the chance to open a circuit board, build a simple frame, or write basic code, they start viewing technology purely as consumers. They treat complex machines as black boxes—magic objects that just work until they break. A strong economy cannot rely only on consumers. It needs builders, fixers, and creators. Understanding basic technology—like electric circuits, mechanical parts, and software logic—is no longer just for future mechanics. It is a basic skill everyone needs in a high-tech world. The danger for future leadership This lack of basic technical knowledge also creates a problem in the workplace. When general technical knowledge drops, the gap between management and technical execution grows wider. Companies end up led by managers who understand spreadsheets, but have no idea how their company's physical or digital products actually work. As a result, organizations struggle to innovate. They make wrong estimations about timelines, underestimate technical challenges, and fail to understand their own engineers. If we want smart, tech-savvy leaders in boardrooms tomorrow, we must introduce children to practical technology today. Bringing practical technology back to school Fixing this problem does not mean every student needs to become a software developer or a nuclear engineer. It simply means treating technology education with the same respect as math, history, or language. We need to teach young people how the world around them works. That means bringing practical technology back to the classroom:Combine theory with practice: Teach math and physics using real-world technical problems. Remove the mystery: Give students the confidence to take things apart, fix problems, and build new things. Show real career paths: Help students see early on what modern jobs in software, energy, and building actually look like.Closing thought We cannot build a high-tech future on a foundation of low-tech education. If we want to maintain our infrastructure, succeed in the energy transition, and stay competitive, we must take technology education seriously again. It is time to give the next generation the practical skills, curiosity, and knowledge they need to build the future.

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.