DEV Community: Javier Castro

The Meeting You Skipped Was the One That Actually Mattered

Javier Castro — Mon, 10 Aug 2026 14:19:49 +0000

The Meeting Problem Is Real. The Fix Is Incomplete.
Let’s be honest about what we were running away from. Post-2020, people found themselves trapped in a endless loop of video calls, with Microsoft recording over a 2.5x jump in total weekly meeting hours. The default response to every minor query became a 30-minute calendar block. That isn't collaboration; it's operational paralysis.

When Atlassian surveyed 5,000 global workers, meetings comfortably crowned the list as the primary barrier to getting actual work done — beating out unclear priorities and low morale. Over three-quarters of people admitted to feeling completely wiped out on heavy meeting days, often pushing their actual tasks into overtime just to catch up.

Moving toward asynchronous communication wasn't a fad; it was self-defense. Research published in MIT Sloan Management Review showed that cutting out just one day of meetings a week led to noticeable boosts in autonomy, clearer communication, and higher job satisfaction, all while lowering daily stress. When companies pushed that further to a 40% reduction — essentially two meeting-free days — productivity surged by over 70%.

The async movement isn't wrong about the disease. They’re just applying a partial cure and calling it a full recovery.

What the Summary Leaves Out

A crisp, well-structured summary is great at recording what got decided. What it completely misses is how the decision actually happened.

It won't tell you how close the consensus really was. It misses the slight hesitation in a principal engineer’s voice when she muttered, "I guess I can live with it." It hides the fact that the product manager stayed silent for forty minutes — which, if you know how they operate, is usually a red flag.

Human interaction relies heavily on non-verbal cues — micro-expressions, posture, uncomfortable pauses. They add essential texture to our words and reveal how people actually feel about a plan. Strip all that away, and you're left with a static document. Documents are useful references, but they don't carry the authority or emotional weight of a shared room.

Trust in remote setups doesn't usually form in formal channels; it built gradually through informal banter and subtle visual signals. Async workflows strip those away. When you read a three-sentence recap of a long, nuanced debate, you aren't getting the full picture — you're reading an edited narrative shaped by whoever wrote the notes.

Atlassian’s findings highlight how meeting culture often fails because a few loud voices dominate while everyone else checks out. That’s a valid critique. But shifting to async doesn't magically fix power dynamics; it often just ensures that the loudest voice becomes the only one written into the record.

The Buy-In Problem Nobody Talks About

Some meetings aren't about sharing information. They’re about forming a social contract.

When a company executes a major shift — a reorg, a new tech stack, a change in strategy — the live discussion is where team members decide whether they are truly onboard. Not in a dramatic "I resign" way, but in the quiet choice between actively championing the direction or subtly ignoring it while sticking to their old habits.

When people feel safe expressing themselves, they take risks: they challenge assumptions, point out flaws, and voice doubts. That tension is what creates true ownership. But ownership can't be attached as a PDF or summarized in a bullet point. It has to be forged in real-time through the friction of live conversation.

Studies on high-performing tech teams confirm that psychological safety — built on active dialogue, open exchange, and genuine give-and-take — directly drives innovation. Notice the emphasis: it’s the process of communicating live, not just receiving the final takeaway, that builds alignment.

This is where pure efficiency math collapses. Teams easily measure the hours saved by wiping meetings off the calendar. What they fail to track is the invisible friction that builds up when employees execute plans they privately doubt, simply because they never got a chance to air their concerns to someone who could respond on the spot.

The Counterargument Deserves a Fair Hearing
To be fair, async advocates raise a point that frequently gets ignored: live meetings are not automatically inclusive.

Synchronous setups inherently favor fast talkers, extroverts, and whoever happens to be online in the right timezone. People who prefer time to process ideas before speaking are routinely sidelined. For a team split between São Paulo and Singapore, a live "alignment" call often aligns only the people awake enough to participate without drinking their fourth coffee.

Even Atlassian — a company whose tools heavily promote async work — acknowledges that working purely asynchronously makes it harder to build real relationships. They openly note that gathering synchronously to build personal rapport and trust pays dividends that static updates never will.

The sensible view isn't that async and sync are mortal enemies; they’re just tools engineered for different jobs. Async is ideal for status updates, simple check-ins, and passing along clear info. Live interaction is required when you need people to wrestle with complex problems, debate risks, and align on tough trade-offs. The issue today is that organizations have stopped making this choice intentionally. They default to async out of calendar fatigue, replacing difficult conversations with written notes regardless of whether the decision actually calls for it.

The Coordination Tax Nobody's Accounting For

Projects frequently launch with excitement and end near a deadline, but very little real alignment happens in the middle. Molly Sands, who leads Atlassian’s Teamwork Labs, put it bluntly: teams assume everyone is aligned, but in reality, few people know what their peers are actually doing day-to-day.

Active coordination isn't flashy, but it remains one of the strongest indicators of whether a project succeeds. Today's teams have access to more data than ever, yet many feel completely in the dark. Atlassian’s research across thousands of workers revealed that employees waste roughly a quarter of their workweek just trying to hunt down basic answers.

That is what poor coordination looks like in practice: not a lack of information, but constant operational drag. Everyone can read the announcement, but nobody is entirely sure what it means for their specific workload.

Important nuances get buried under endless Slack threads, Google Docs, and comment chains. Async was supposed to declutter our work, yet it often creates a different headache: a mounting trail of text that nobody has time to read, compounding faster than the meeting invites ever did.

Academic research on knowledge workers shows that while overload destroys focus, dropping below a baseline of live interaction causes its own problems. People lose the shared context needed to organize their work efficiently. There is a healthy floor for real-time contact, not just a ceiling. Unfortunately, the tech industry has spent five years focusing exclusively on the ceiling.

Where This Leaves You

The quiet reality hiding behind the radical async movement is straightforward: the meeting you canceled might have been doing work you can't easily quantify.

Not the monotonous status update — kill those without second thoughts. But the tense architecture review where an engineer finally spoke up about a fundamental flaw after ten minutes of uncomfortable silence. Or the quick sync where two teams realized they were building conflicting features and fixed it on the spot. Or the delicate feedback conversation that is now being sent as a dry, three-paragraph message that everyone will misinterpret differently.

Time saved is easy to measure on a spreadsheet. Organizational cohesion is not. And the companies that have ruthlessly optimized for the former are quietly starting to pay for what they lost.

The real question isn't whether we should have fewer meetings. Of course we should. The real question is whether the live interactions we do keep are the ones capable of building the trust, alignment, and shared purpose that no written summary can ever replace.

Sources
Microsoft Work Trend Index

Five Hybrid Work Trends to Watch | MIT Sloan Management Review

The Surprising Impact of Meeting-Free Days | MIT Sloan Management Review

Meeting Overload and Asynchronous Collaboration | Atlassian Research

Workplace Woes: Meetings Report | Atlassian

Psychological Safety and Team Performance | Stack Overflow Engineering

Real-Time Non-Verbal Interaction Overlays in Virtual Collaboration | arXiv

The Data Was Always There. It Was Just Wrong.

Javier Castro — Mon, 10 Aug 2026 12:29:20 +0000

Industrial AI isn't failing because the models aren't good enough — it's failing because companies spent decades building the digital equivalent of a house of cards, and now they're surprised the AI can't play on top of it.

A senior engineer at a midsize European petrochemical refinery once described to a colleague the experience of preparing their operational data for an AI predictive maintenance pilot. Six months of work. Teams pulling sensor readings from equipment installed across three different decades, stored in five incompatible formats, some still transcribed from paper logs by hand. At the end of it, they had a dataset. What they didn't have was a model that could do much with it, because the underlying records were riddled with duplicate entries, mislabeled columns, and timestamps that didn't align across systems. The vendor's demo, naturally, had looked flawless.

This is the story of AI in traditional industry that no one puts on the conference keynote slide. Not a story of technological failure — the models themselves are increasingly capable — but a story of an organizational reckoning that was thirty years in the making. The uncomfortable claim: the real barrier to AI in retail, energy, and manufacturing is not artificial intelligence. It's the data infrastructure that these industries quietly agreed to neglect for decades, and the organizational habits that grew around that neglect.

The Infrastructure That Was Never Built

Many manufacturing enterprises grapple with outdated legacy systems, widespread data silos, and a lack of integrated data governance — limitations that often result in datasets that are noisy, incomplete, or poorly contextualized, requiring laborious and costly pre-processing. This is not new information. It has been the conclusion of every serious industry report for the better part of a decade. What's new is that AI is making the problem visible in a way that ERP consultants and middleware vendors never quite managed to.

Decades of reliance on monolithic systems — mainframes, fragmented ERPs — are now among the greatest barriers to resilience, growth, and compliance. In the energy sector, the situation compounds in a specific way. A single oil, gas, refining, or petrochemical facility can have thousands of sensors measuring everything from temperature and pressure to velocity and viscosity, yet facilities make operating decisions using less than 8% of the data available to them. It's not that the data doesn't exist. Operators already collect most of it — they just can't combine the sensor readings, engineering documentation, and process physics fast enough to actually do anything with it.

The ERP problem specifically deserves more attention than it gets. A recent deployment study on enterprise ERP systems found something that vendors would prefer stayed quiet: initial LLM deployment attempts failed despite sophisticated prompting and retrieval mechanisms, and system performance became acceptable only after implementing automated cleaning — confirming that generative AI cannot compensate for fundamentally corrupted data. This finding directly contradicts vendor claims that LLMs can "clean data on the fly" through contextual understanding.

That last sentence should be printed on a banner and hung in every vendor booth at Hannover Messe.

The J-Curve Nobody Mentions in the Strategy Deck

To be fair to the industries struggling here, the early productivity hit from AI adoption is a documented phenomenon, not a sign of uniquely bad execution. Recent research on AI adoption at U.S. manufacturing firms reveals a more nuanced reality: AI introduction frequently leads to a measurable but temporary decline in performance followed by stronger growth in output, revenue, and employment — a "J-curve" trajectory that helps explain why the economic impact of AI has been underwhelming at times.

The harder finding is who takes the deepest hit at the bottom of that J. The negative impact of AI adoption was most pronounced among established firms — organizations with long-standing routines, layered hierarchies, and legacy systems that resist unwinding. In other words, the companies with the most operational history, the longest track records, and the most accumulated process knowledge are exactly the ones that suffer most when they try to bring AI into the workflow. Not because they're being managed badly, but because their past success literally got in the way.

Organizational memories are often clouded by many failed or painfully stretched technology rollouts — ERP systems, safety tools, telematics systems, and so on. People wonder whether the AI-tools wave is another fad worth waiting out. When you look more closely, the real blocker is change fatigue, not an aversion to technology.

That matters. The floor-level operator at a manufacturing plant who rolls his eyes at the new "AI dashboard" isn't a Luddite. He's someone who watched three previous digital transformation initiatives arrive, produce PowerPoint decks, and disappear. His skepticism is rational. And improved accuracy or productivity boosts mean little to front-line operators, who care more about customer escalations, rework, and operating costs.

Pilots Everywhere, Production Nowhere

Here is the number that should be tattooed on every CDO's forearm before their next board presentation: despite billions in enterprise AI spending, a 2025 study from MIT's NANDA initiative concluded that 95% of generative AI pilot programs fail to produce measurable financial impact — with failures stemming not from model quality but from poor workflow integration and misaligned organizational incentives.

Most companies are stuck in pilot mode. While 88% of organizations use AI in at least one function, only one-third have begun to scale their AI programs at the enterprise level. Bayer, to their credit, gave this syndrome a name that has since spread across the industry: "pilotitis" — the habit of continuous piloting that leaves management increasingly impatient, wondering how to get out of the rut.

Only 26% of organizations have moved beyond proof of concept, and 42% abandoned the majority of their AI initiatives before production. For energy and manufacturing companies, those numbers are likely worse — because they face the additional friction of safety approval chains, functional safety standards, and process engineers who rightly point out that a probabilistic recommendation engine shouldn't be trusted to schedule a pressure vessel inspection without human sign-off.

That last concern, incidentally, is legitimate. Large organizations prefer human-in-the-loop solutions even when full automation is technically feasible — because the perceived risk of autonomous AI outweighs the efficiency gains. In a refinery, this isn't overcaution. This is correct risk management. The AI vendors who don't understand this are the ones pitching to procurement rather than to safety engineers.

When the Shop Floor Meets the Slide Deck

The gap between what AI can demonstrably do and what actually ships to production has a specific texture in industrial settings. Consider what happened when a research team embedded with an energy firm to assess generative AI readiness across organizational functions in early 2025. They identified 41 use cases consolidated into six categories — reporting, RAG-based solutions, predictive maintenance, anomaly detection, budgeting, and forecasting — with three priorities emerging across functions: automation of reporting, predictive maintenance to minimize downtime, and enhanced forecasting for planning.

All sensible. All things that AI can genuinely help with. And yet the same team found that the smart energy sector encounters numerous obstacles in adopting AI, including insufficient or poor-quality data, technical infrastructure issues, a lack of skilled professionals, integration difficulties, and legal compliance concerns.

The missing expertise problem is particularly acute. Missing expertise is the dominant reason that firms do not adopt AI today. A data scientist who can build a transformer model is not the same person who can navigate a plant historian, understand HAZOP documentation, or explain to a process engineer why the model flagged a false positive on a temperature sensor three months after the bearing had already been replaced. Industrial AI needs people who are bilingual in a way that's genuinely rare — who speak both the language of gradient descent and the language of a distillation column.

Retail faces a slightly different version of the same problem. Global retailers lose more than $1.8 trillion per year due to inefficient demand forecasting and inventory disconnect, and 62% continue to rely on manual or spreadsheet-based reorder processes. The technology to fix this exists. The organizational will and the clean data to feed that technology are substantially harder to find. Companies must manage more SKUs and fragmented orders across multiple fulfillment channels, maintain real-time inventory visibility, handle return rates rising to 40% in sectors like fashion, and allocate inventory dynamically across online and offline channels. These are real operational problems that AI can address — but only with the kind of end-to-end data integration that most retailers haven't actually built.

The Counterargument, Taken Seriously

There's a version of this critique that goes too far, and it's worth naming. Some deployments work, and work well. Shell's collaboration with C3.ai produced a platform that continuously monitored over 10,000 critical refinery assets, analyzed approximately 20 billion data points weekly, successfully identified two imminent and critical equipment failures well in advance, and resulted in estimated savings of approximately $2 million. Michelin has reportedly identified more than 200 AI use cases generating meaningful annual ROI. Barnes Group, an aerospace and industrial components manufacturer, identified, de-duplicated, and indexed all of its product specification documents using generative AI — allowing service technicians to access immediate, accurate information and yielding a five-times return on the AI investment in its first year.

The J-curve exists, but early AI adopters showed stronger growth over time. And the research on what separates successful deployments from failed ones is fairly clear. McKinsey reports that top performers are nearly three times more likely to fundamentally redesign workflows as part of their AI efforts — 55% of high performers redesigned workflows around AI versus only 20% of other companies. The companies that treat AI as a tool to bolt onto existing processes lose. The ones that treat it as a reason to question the process itself have a fighting chance.

The counterargument also holds that the data infrastructure problem is solvable. Modernizing legacy systems isn't a one-time project — it's a continuous journey that can begin with relatively simple integrations between siloed systems. True. It's also, sometimes, a decade-long journey that starts with a three-year SAP migration that goes sideways in year two.

The Real Problem Is What Got Celebrated

Here's the sharpest version of the claim: traditional industries aren't failing at AI. They're being penalized for decades of decisions that were, at the time, entirely rational. Running a thirty-year-old process historian because it works is sensible. Accepting a patchwork ERP because the upgrade cost was too high is a reasonable CFO call. Keeping paper logs as a backup because the SCADA system has crashed before is just good field engineering.

None of those decisions were wrong when they were made. All of them collectively created an organization that is genuinely, structurally difficult to apply modern machine learning to. A growing body of reports and academic studies has highlighted that many firms have struggled to generate meaningful returns from their AI initiatives — the "AI productivity paradox." But paradox implies mystery. There's no mystery here. As one industrial company CEO put it: "The technology is not the hard part. It's the changing-the-company part that's hard."

The AI vendors landing in Houston or Dortmund with their demonstration environments and clean synthetic datasets are not wrong about what the technology can do. They're just performing a demo on a surface that doesn't look much like the actual factory floor. The floor has forty years of grime on it, metaphorically speaking, and also sometimes literally. No amount of model sophistication bridges that gap without someone first deciding to clean the floor.

The companies that figure this out stop asking "how do we implement AI?" and start asking "what would need to be true about our data before AI could help us?" Those are very different questions. Most AI strategy documents, for the record, answer neither of them.

Sources

Your Software Team Isn't the Problem. Your Org Chart Is.

Javier Castro — Sun, 09 Aug 2026 12:48:51 +0000

Non-tech companies keep hiring engineers and then systematically preventing them from doing engineering — and the cost of that confusion is finally becoming impossible to ignore.

Picture this: an oil services company with 30,000 employees and $4 billion in annual revenue installs a Jira board. Leadership hires a Scrum Master. Sprint planning runs on schedule every two weeks. The backlog is groomed. The velocity chart goes up. And the lone software team — eight developers buried three layers beneath the VP of Operations — continues to wait six weeks for a Change Advisory Board to approve a three-line patch to a field-management application running on a server nobody can physically locate.

The Jira board is not the problem. The org chart is.

This is the defining tension in enterprise software delivery right now: the gap between companies that exist to build software and companies that build software in order to do something else. Retailers, oil and gas operators, manufacturers, heavy-equipment firms — these organizations have been told, with increasing urgency, to "become tech companies." Most have responded by adopting tech company rituals without changing anything about how they actually make decisions, reward employees, or manage risk. The result is a kind of organizational cosplay: the ceremonies of Agile without the authority structures that make Agile functional.

The Cost Center Trap

In accounting, every department is classified as either a cost center or a profit center. At a software company, developers build the product that generates revenue — they're a profit center. But what if you don't work in software?

That question has a very concrete answer in most industrial organizations. When a drilling company's IT team ships a better scheduling tool, they have not drilled more oil. When a retailer's in-house engineering team automates a supply-chain workflow, they have not sold more goods. The software is real and the value is real, but it is indirect — and indirect value, in organizations measured by barrels, SKUs, or tonnage, is perpetually at risk of being classified as overhead.

This is the root of why so many older companies struggle to transform, and why the struggle doesn't seem to be easing. The Pragmatic Engineer has documented the pattern thoroughly: engineering teams at non-tech firms tend to be understaffed, undercompensated relative to their skills, and perpetually underinvested compared to peers at software-native companies. They are expected to deliver modern software while being resourced like a maintenance department.

The practical downstream effect is talent bleed. Industries that have been slow to adopt technology — manufacturing, agriculture, transportation and logistics — now face pressure to integrate AI. They have decades of technical debt and greenfield AI opportunities sitting side by side. They need developers who are AI-literate but also understand domain-specific requirements, regulatory constraints, and existing systems. Finding people who satisfy all three criteria and will accept a non-tech salary is not straightforward. So these organizations cycle through contractors, system integrators, and offshore teams — and then wonder why institutional knowledge disappears every 18 months.

Legacy Systems: The Real Constraint That Agile Ignores

Throughout the life of a software system, its architecture decays, its underlying technologies become obsolete, and user requirements shift — until the software becomes what the industry politely calls a legacy system. Most software currently running in production fits that description: long-lived systems representing years of accumulated business logic, kept alive through extensive maintenance, at increasing cost and increasing exposure to security risk.

This is the technical reality that Agile transformation decks tend to skip over. The Scrum framework was designed for greenfield product development. It assumes a team can iterate freely, deploy frequently, and learn from user feedback. In a company running a 25-year-old ERP written in COBOL, interfacing with a proprietary MES that the original vendor no longer supports, none of those assumptions hold. The backlog refinement session becomes an exercise in estimating how long it will take to find a workaround for infrastructure that shouldn't exist in 2025.

In many traditional IT organizations, a Change Advisory Board is tasked with assessing risks and approving changes. The CAB holds regularly scheduled meetings to review all proposed upcoming changes, pulling in experts to explain, defend, or assess them. And while change management exists for real reasons — risk, compliance, auditability, cross-team coordination — the process has a well-documented tendency to become complex, bureaucratic, slow, and painful. Atlassian calls this "bureaucratic." In heavy-industry contexts, it's often non-negotiable. A software change to an oil platform's sensor management system touches IEC 61511 functional safety requirements. A retail pharmacy's order management update carries FDA audit obligations. These aren't excuses for slow delivery — they're load-bearing constraints. Agile doesn't remove them. It just makes the sprint retrospective more awkward.

Transformation Theater

From 2022 to 2024, digital transformation spending in Western markets was projected to reach $6.3 trillion. Failure rates hover around 84%, with no signs of improvement. Organizations are pouring money in and not getting the value out.

Some of that failure comes from technical complexity. Most of it, if you talk to practitioners who have actually sat inside these transformations, comes from a simpler problem: organizations adopt the vocabulary of modern software delivery without restructuring the authority that software delivery requires.

The failure patterns are consistent. Middle managers stay in waterfall mode, keeping old bureaucracy intact while internal silos are preserved. Other functions refuse to change their pace. Product launch activities resist incremental delivery. Reward models stay focused on individual output rather than team outcomes.

This is what "Agile transformation" actually looks like inside a manufacturing firm: two-week sprints scheduled inside a six-month project plan, approved by a steering committee that meets quarterly. Developers write user stories. The acceptance criteria are written by a business analyst who reports to a VP who has never merged a pull request. The Definition of Done is whatever makes the next milestone gate turn green. Velocity is tracked religiously. Deployment frequency is never measured at all.

In practice, assigning responsibility to a Product Owner creates friction with existing processes when transitioning from a waterfall or ITIL way of working. And in non-tech companies, "existing processes" includes procurement rules, union agreements, safety certification cycles, and board-level risk frameworks. These don't flex for a two-week sprint.

The Counterargument Deserves a Fair Hearing

It would be easy — and wrong — to conclude that Agile and DevOps are simply incompatible with industrial settings. That's not the claim here.

The CrowdStrike outage of July 2024 is a useful counter-case. When a problematic CrowdStrike update clashed with Microsoft's widely-used software, the resulting global IT outage cost Fortune 500 companies north of $5 billion. The disruption hit companies with outdated legacy systems hardest — airlines in particular took longest to recover. Delta canceled around 5,000 flights in the first three days, then another 1,000 on day four.

Delta's prolonged recovery compared to peers was not bad luck. Their crew scheduling system was so deeply dependent on Windows machines that manual recovery — physically touching each one — was the only remediation path. A company in that position has not invested adequately in its software operations layer. That is a cost-center mentality applied to infrastructure that cannot afford it.

There are genuine wins on the other side. One automotive manufacturer trying to shift its complex architecture to the cloud struggled to translate legacy code into requirements that could be moved or rebuilt. Using AI-assisted tooling, teams removed eight person-weeks of effort previously spent documenting each portion of legacy code, producing reports then available for forward engineering. That's a meaningful compression of the most brutal phase of modernization work — not because Agile ceremonies unlocked it, but because actual engineering investment did.

The Organizational Capability That Actually Matters

The honest thesis isn't that non-tech companies are bad at software, or that the engineers inside them are underqualified. Most are doing something genuinely hard — delivering software inside organizations whose decision-making architecture was built around a completely different model of production. The sprint board doesn't threaten anyone who runs a blast furnace. The retro doesn't rearrange a procurement committee.

What actually differentiates the non-tech companies that deliver good software from those that don't is not the methodology on the wall. It's whether technical leaders have organizational authority to match their accountability. Whether a CTO or VP of Engineering can say "this system is a liability" and be heard, rather than just noted. Whether the change control process exists because the risk is real or because nobody ever had the clout to simplify it.

Software management is playing a larger and more strategic role across large traditional organizations — and those organizations are finding themselves increasingly limited in their ability to respond to market and customer needs. "Limited in their ability to respond" is polite phrasing for what actually happens: a three-line fix that should ship Tuesday takes six weeks, costs a developer their enthusiasm, and eventually costs the company a person who leaves for somewhere that ships.

The oil rig doesn't care about your sprint velocity. Fair enough. But the rig's operator should care that the software running its sensor telemetry was written before smartphones existed, is maintained by one contractor who knows the codebase, and would take four weeks to update even in an emergency. That's not a technology problem. That's a governance problem wearing a technology problem's clothes.

And no amount of Scrum certification fixes an org chart.

Sources

Agility and Peter Pan Syndrome

Javier Castro — Sat, 08 Aug 2026 21:50:42 +0000

Agility often presents a sense of discomfort within organizations; it is a concept that lingers in conversations but is not fully understood in practice. In IT companies, discussions about agility, various frameworks, and spreading the philosophical spirit of agility are commonplace. However, the reality is that agility often behaves like a child who refuses to grow up, trapped in what can be described as a Peter Pan syndrome — remaining at the lower levels of the organization.
Scaling agility requires transparency and a more horizontal organizational structure, and as we know, no one wants to lose control as it might be perceived as a sign of weakness. If agility were to spread across all levels, yet only a few were responsible for decision-making, it would be as if nothing had changed.

To be truly agile, we must be willing to relinquish our privileges and accept that we will also share responsibilities. Achieving 100% agility may seem utopian, which is why it is crucial to ground our approach and define a matrix of roles and responsibilities. Everyone must understand that decisions and responsibilities are aligned with their job positions. Certain responsibilities will not be shared, and this is where organizations often confuse roles with being agile.

For agility to take root and thrive, there must be a collective commitment to transparency, shared responsibility, and a willingness to adapt to a more horizontal structure. By doing so, organizations can move beyond superficial agility and embrace a transformative approach that fosters true growth and innovation.

The “Mind-Reader” in the Age of Algorithms: Why Being a PM is Still a Human Sport

Javier Castro — Sat, 08 Aug 2026 21:47:51 +0000

The Infrastructure Moving Target
Then there’s the technical side. We’re in an era where the ground moves beneath our feet every six months. Today’s “best practice” in UI/UX or cloud infrastructure is tomorrow’s legacy tech.

As a Technical Project Manager, you aren’t just tracking a timeline; you’re managing a living organism. A simple change in an API or a shift in how a CSS framework handles responsiveness can have a butterfly effect across the entire product. An AI can help you write a script to fix a bug, but it struggles to understand the strategic impact of shifting your entire team’s focus to address a sudden infrastructure vulnerability.

We are the ones who balance the “Technical Debt” vs. “Feature Velocity” scale. We understand that while the AI says we could deploy on Friday, the human reality of the team’s burnout and the complexity of the production environment says we shouldn’t.

The Augmented Agile: Tools, Not Replacements
Don’t get me wrong — I’m not a Luddite. I’ve championed CI/CD and automation throughout my career. I love that AI can now help me draft initial user stories or summarize a chaotic 20-person brainstorming session.

But these are just tools. A carpenter didn’t lose their job because the power drill was invented; they just started building better houses faster.

In this new “AI-adjacent” industry, our role is evolving from “Information Gatherers” to “Context Providers.” We provide the context that the machines lack. We take the 10% improvement in code quality that automation gives us and we reinvest that time into what actually matters: Product Discovery and Team Culture.

The Bottom Line: Empathy as a KPI
At the end of the day, software is built by people, for people. Whether I’m leading 3 Agile teams or coaching 20+ members on self-organization, the goal is always the same: creating an environment where humans can be creative.

AI can’t foster “team satisfaction”. It can’t facilitate a retrospective where people feel safe enough to admit they made a mistake. It can’t sense the “heart” of a product [as Darwoft likes to say].

So, if you’re a PM or an Agile Coach feeling the “AI anxiety,” remember this: as long as humans are the ones paying for the software and humans are the ones writing the code, they will always need a human in the middle to make sense of the chaos.

Keep your empathy sharp, your curiosity high, and maybe keep an eye on those “Mardel” coffee shop queues — there’s always a process to be optimized, and a bot isn’t going to do it for you.

The Tech Leadership Skills You've Been Neglecting Are Exactly the Ones AI Can't Cover

Javier Castro — Fri, 07 Aug 2026 14:56:48 +0000

As AI eats the execution layer of technical management, the leaders who spent a decade avoiding the hard conversations are about to be found out.

Picture a mid-level engineering manager at a mid-size SaaS company. Smart. Shipped features on time. Knew the architecture cold. Ran a tight Jira board. Then GitHub Copilot arrived, then Claude Code, then the agentic coding pipelines — and suddenly the team's output tripled, the delivery metrics turned green, and senior leadership wanted to know why they still needed a manager at all.

The question wasn't cruel. It was just logical. If an AI can handle sprint planning, code review triage, status reports, and dependency mapping, what exactly is the manager for?

The answer isn't technical. It never really was.

The Execution Layer Is Gone. What's Left?

The dirty secret of a large share of tech management is that it was always disguised execution. Breaking down tickets, chasing blockers, writing the PRD that should have been a five-minute conversation — these were coordination tasks dressed up as leadership. AI has now dressed them back down. And in doing so, it has exposed a vacuum that no amount of prompt engineering fills.

Most stalled AI initiatives fail not because of algorithms, but because leadership systems, governance structures, and culture are not prepared for AI-enabled work. That observation comes from MIT Sloan Management Review research drawing on real advisory work across enterprises — and it keeps showing up in every serious post-mortem. In a 2025 global survey from BCG, 60% of respondents said their investments in AI have delivered little material value, either in increased revenue or lowered costs.

Only 26% of organizations have moved beyond proof of concept, and 42% abandoned the majority of their AI initiatives before production.

The bottleneck is almost never the model. In one recent survey, 91% of large-company data leaders said "cultural challenges/change management" are impeding organizational efforts to become data-driven. Only 9% pointed to technology challenges. That number is almost comic in its lopsidedness, and yet the industry keeps funding GPU clusters while under-investing in the leaders who know how to bring a skeptical VP of Finance and an anxious engineering team to the same table.

The Argument That "Soft Skills Will Save You" Is Also Wrong

Here's where the counterargument earns its hearing — because the standard response to AI-eats-execution has become its own kind of lazy consolation prize.

The conference circuit is currently full of speakers assuring every nervous middle manager that "emotional intelligence" and "empathy" will be their competitive moat. The advice isn't wrong, exactly. It's just dangerously incomplete. Warmth is not a strategy. Empathy without judgment is just being nice at the wrong moments. AI raises the stakes for leadership precisely because it can accelerate decision-making while creating a false sense of certainty. Leaders need to know what AI can and cannot do — and, critically, when to override it.

That word — judgment — is doing a lot of heavy lifting right now, and it should. As AI dramatically reduces the cost of replicating expertise, what was once the source of competitive advantage — proprietary methods, scale, ten years of training — collapses. What doesn't collapse is the capacity to read the room at a vendor renegotiation, to tell a talented engineer their approach is wrong without destroying the relationship, or to sense that a team's confidence in an AI-generated output is outpacing the quality of the output itself.

Research shows 42% of knowledge workers admit to trusting AI outputs without verifying them due to time pressures. That's not a model problem. That's a leadership problem. Someone has to build the culture where questioning the output is expected, not penalized.

What MIT's Research Actually Shows (It's More Specific Than "Be Human")

Researchers at MIT Sloan have been trying to put harder edges around the "be more human" platitude. Their EPOCH framework — the result of studying statistical limitations of AI tools — identifies specific human capabilities that remain genuinely complementary to AI rather than redundant with it. AI performs badly when data are biased or sparse, when extrapolation far from the training data is needed, and when moral dilemmas emerge. The researchers concentrated on how humans have dealt with these problems, which creates the foundation for skills that AI can't absorb.

Notice what's on that list: moral dilemmas, extrapolation into novel territory, thin data. These are exactly the conditions that define real leadership moments — the ambiguous, high-stakes, low-precedent situations that no training corpus has properly seen before. MIT Sloan researchers deliberately don't call these "soft" skills. "A 'hard' skill, like solving a math problem, is comparatively easy to teach. It is much harder to teach a person these critical human skills and capabilities — such as hope, empathy, and creativity."

Stanford echoes this at the organizational level. Stanford GSB economics professor Susan Athey has cautioned against "blind faith" in AI use. "Machine learning solves simple problems, but it is not sentient," Athey explains. "It struggles when applied to many business problems." As a result, many organizations find that early experimentation does not translate into organizational value. Which, given the experimentation budgets being thrown around, is a fairly expensive lesson.

The Skills Nobody Practiced Because They Thought the Code Would Hide It

The thorniest version of this problem shows up in engineering specifically. Throughout 2025, AI systems have become capable of generating relatively complex code in seconds. That points toward a world where software engineering is less about writing code from scratch and more about defining, reviewing, testing, and orchestrating systems.

That shift sounds clean. In practice it's disorienting for teams whose entire professional identity was built around the craftsperson model — you write it, you own it, you fix it. Collaboration patterns are changing: teams are shrinking, roles are blurring, and the question is no longer how to structure teams but how to make collaboration effective in whatever form it takes.

Into that space steps the leader who knows how to hold a team together through identity disruption. That's not a skill listed in any job description. But it's the skill that determines whether an AI rollout lands or festers. Emotional intelligence, strategic leadership, and real communication remain crucial in stakeholder management, negotiations, and conflict resolution — and research from emerging agentic software engineering frameworks keeps arriving at the same conclusion: the tasks AI can't absorb are the ones that involve contested human interests.

Contested interests are everywhere right now. C-level demands measurable proof of ROI. Staff functions worry about process risks and blame. End users distrust system inconsistency. Frontline workers fear replacement. A leader who can't hold those four simultaneously in a room — without collapsing into either false cheerleading or defensive hedging — is going to watch AI implementation fail on a purely social level.

The Negotiation Problem Nobody Wants to Admit

There's a specific sub-skill here worth naming directly: negotiation. Tech culture has historically treated negotiation as something salespeople do, or lawyers. Engineering leaders particularly tend to regard it with suspicion, as if the desire to influence an outcome is somehow less rigorous than optimizing a function.

That attitude is now expensive. Every AI deployment is a negotiation — with the team absorbing the change, with the executives demanding ROI on a timeline the technology can't honor, with the vendors whose contracts don't match the actual capability of the product. AI can coach you through preparation, surface tactical blind spots, run rehearsal scenarios. But the actual moment of creative problem-solving across a contested table — reading what the other party actually needs versus what they said they need — that remains stubbornly, specifically human.

MIT Center for Information Systems Research scientist Nick van der Meulen observes a recurring pattern: "Organizations are applying yesterday's best practices to an inherently different technology. They govern AI like legacy IT, mistake productivity shaves for enterprise value, and treat AI as another skill to acquire when it's actually redefining what skilled work looks like."

The same could be said for how organizations are treating leadership itself.

The Uncomfortable Reframe

Here is the claim worth sitting with: for many tech leaders, the skills AI cannot replicate are precisely the ones they've spent their careers avoiding. The hard conversation with a high performer who's burning out the team. The moment where you disagree with your skip-level in a room full of people and don't flinch. The political navigation required to get two feuding product and engineering organizations to ship something together.

Consider the doctor who treats screens instead of patients, or the teacher constrained by standardized testing. Everywhere, situation-sensitive judgment is being replaced by what one researcher calls "execution logic": prestructured parameters that turn decision makers into mere executors. As spheres of discretion disappear, the creativity of human agency drains away.

Tech leadership is not immune to that dynamic. Most organizations continue to treat the implementation of AI as a primarily technical challenge — and current technology leadership roles reflect this mindset. Reflexively reaching for a dashboard, a framework, or a tool is a form of execution logic too — and AI is now better at all three than most managers.

What it cannot do is carry the weight of a difficult decision made under genuine uncertainty, explained honestly to people who are scared, and defended when the data is inconclusive. That's still yours. Whether you've built the capacity to do it — that's the more uncomfortable question.

The leaders who thrive in the next few years won't be the ones who out-prompted the AI. They'll be the ones who finally did the interpersonal work they'd been deferring since their first promotion. Which means the AI didn't create the leadership gap. It just made it visible.