As a leader, you’ve probably spent years nudging your managers to create psychological safety. After all, organizations benefit greatly when it feels safe to challenge the boss, surface bad news early, and say the uncomfortable thing before it becomes the expensive thing.

The Space Shuttle Challenger disaster of 1986 has become the canonical warning. Engineers raised concerns about the O-rings used in the solid rocket booster before launch. Their warnings were overruled by managers under schedule pressure. Seventy-three seconds after liftoff, seven astronauts were dead. The lesson still holds: When people are afraid to speak or are pressured to comply, organizations miss what they already know.

AI, however, is introducing a complication most leaders haven’t accounted for. Your employees now have another place to speak, and emerging research suggests they may be more willing to challenge a machine than a human leader, while another body of research challenges our assumptions about psychological safety itself.

Put those together, and you’re no longer managing psychological safety only between people. You’re managing it across people and machines, and the two may tell you very different things about your organization’s health.

Safety needs accountability

Psychological safety became popular for good reason: Teams perform better when people can admit mistakes, question assumptions, and challenge authority without fear of it following them into a performance review. But here’s the misconception: Psychological safety and accountability sit at opposite ends of the same dial. Turn safety up, the thinking goes, and standards come down. They don’t. The strongest teams have both; people feel safe enough to challenge one another and accountable enough to deliver.

Researchers studying five workplace settings, from hospital nurses to knowledge workers to four years of sales data across 229 retail stores, found that the relationship between psychological safety and performance wasn’t simply linear. At high levels of psychological safety without matching accountability, performance on routine work could decline; collective accountability substantially buffered that decline. The problem wasn’t that people felt too safe; it was safety operating without another ingredient the team needed.

A newer conceptual paper helps explain why. Psychological safety lowers the interpersonal risk of speaking up, which is what you want, but safety alone doesn’t create the discipline that keeps a team sharp: preparing for meetings, thinking carefully before weighing in, and taking shared norms seriously. That discipline comes from accountability.

Aviation offers a useful analogy. Sterile cockpit rules eliminate nonessential conversation during critical phases of flight, not safety-critical challenge. If something is wrong, you still speak. What changes isn’t how much psychological safety is allowed. It’s how tightly decision rights, operating discipline, and accountability are enforced.

Your AI pilots and early experiments need maximum candor. A junior engineer questioning a model or vendor claim should have every opportunity to be heard. Once a decision moves into production, incident response, or customer-facing execution, accountability tightens. Psychological safety doesn’t go down; accountability goes up.

Culture won’t automatically make people trust AI

Here is another set of assumptions in this area for IT leaders to challenge: that inclusive leadership, meaning leaders who stay approachable and treat employees’ input as worth acting on, builds psychological safety, that psychological safety makes people comfortable with AI, and that comfort with AI drives adoption. The evidence is messier.

One recent study found that inclusive leadership did improve psychological safety, but psychological safety itself did not significantly predict trust in AI. What mattered more was an individual’s ability to tolerate uncertainty. That matters because AI adoption is an uncertainty event: Capabilities shift every few months, outputs can be confidently right and impressively wrong, and the impact on jobs, workflows, and careers remains unclear. Employees are being asked to exercise judgment around systems whose behavior is probabilistic, not deterministic.

Another study of employees in South Korea found that AI adoption was associated with lower psychological safety, which in turn was associated with greater employee depression. Ethical leadership, meaning leaders who are transparent and fair about what’s changing, softened that relationship but didn’t eliminate it. Neither study is universal proof — different countries, samples, and methodologies matter — but together they raise an important question for CIOs.

A healthy culture may help people absorb the disruption AI creates without necessarily making them trust the technology itself. Those are two different problems. One is organizational: Do employees believe they can question what is happening around them? The other is psychological and technical: Can they work productively when the tool is probabilistic, and do they know when to trust it, challenge it, verify it, or ignore it? That requires more than another culture initiative. It requires AI literacy, judgment, and comfort operating under uncertainty.

Your people may be honest. Just not with you.

A 2026 series of scenario-based experiments with participants in China found that employees were more willing to voice concerns to an algorithmic leader than a human leader during cognitive tasks. Perceived fairness and psychological safety helped explain the difference. That doesn’t mean employees want robots for bosses — the effect didn’t hold in the same way for emotionally charged situations — but for analytical work the finding is worth paying attention to. One possible explanation feels remarkably human: An algorithm can’t embarrass you at the next staff meeting, downgrade your reputation with the executive team, or remember that you challenged its favorite project six months ago.

Now think about what happens as generative and agentic AI become embedded in everyday work. Somewhere in your company, an engineer may tell an AI assistant that the proposed architecture is flawed, explain why, work through three alternatives with the model, then walk into a meeting an hour later and nod along while a senior leader advocates for the original design.

The concern existed. The organization just never received it. AI didn’t suppress the dissent; your management system did.

You’ve created a psychologically safe chatbot sitting inside a psychologically unsafe org chart, and your AI adoption dashboard will never show you the difference. Both employees look like successful AI users, one using AI to accelerate work, the other using it as the only place they feel comfortable saying what they really think. Usage looks identical. Organizational health doesn’t.

We spend a lot of time asking whether employees trust AI. We may need to spend just as much time asking whether they trust people enough to repeat what they already told it.

What only you can fix

First, keep psychological safety constant and let accountability flex by phase. Push for aggressive challenge during strategy sessions, architecture discussions, AI pilots, and early experiments, and make disagreement cheap before decisions get expensive. Once execution starts, tighten decision rights and expectations without closing the channel for legitimate safety, ethical, or operational concerns.

Second, stop measuring psychological safety only through sentiment. Ask whether dissent changes decisions: what major initiative was redesigned because someone challenged an assumption; what AI pilot was narrowed, delayed, or killed because someone surfaced a risk early; what executive decision changed because somebody several layers down challenged the prevailing view. If nobody can remember one, another engagement survey isn’t going to tell you much.

Third, build a path for concerns raised to AI to reach the human decision system. That doesn’t mean reading employees’ private AI conversations; doing that would create exactly the surveillance problem that destroys candor. Instead, design mechanisms that let employees elevate a concern without reconstructing it from scratch: an anonymized escalation channel, a prompt-to-retrospective workflow, a mechanism to flag questionable AI outputs, or a structured path from an AI conversation into an architecture or investment review.

The design question is simple: Can an employee move a concern discovered in an AI conversation into the organization’s decision process with one deliberate action? Increasingly, that’s where the concern may show up first.

None of this argues against psychological safety. It argues against assuming psychological safety works in isolation, or that human trust and AI trust are the same problem. AI is creating a second conversation inside your organization, one that happens in meetings, reviews, and Teams calls, and one that happens quietly between an employee and a machine.

The real question isn’t whether your employees trust the AI. It’s whether AI has quietly become the place where they say the things your organization most needs to hear.

Second Opinion offers technology leaders an evidence-based perspective on their most consequential decisions. Khalid Kark brings 25 years as a trusted advisor, researcher, and operator. In an enterprise technology market crowded with noise, this column separates signal from spectacle.

A LinkedIn post about my old company, insightsoftware, popped up the other day. It was lamenting the challenge of turning 29 acquisitions and close to 80 products into one comprehensive platform. I spent years in the middle of that work, and what I know now is how much harder that consolidation is than you might think, and how much of it you only learn by getting it wrong first. 

So, when I arrived at Veson in November and found a similar landscape, I felt a bit of déjà vu. A bit of “I’ve done this before, so I know what I’m doing” and a bit of “I’ve done this before and I know it’s no cakewalk.” Veson had spent the past several years acquiring a range of products like Shipfix and VesselsValue and now needed to consolidate them onto a platform alongside its flagship IMOS solution. A new variable is also now at play that changes the whole equation: the advancement of AI.

While AI may sound like a cheat code for this work, it’s very much a double-edged sword… with a grenade taped to it. 

Yes, we can do some things faster and differently than we ever could a few years ago. But we’re also learning as we go and upskilling our team as we go, on a technology that’s changing under our feet.

The newness of these tools multiplies the complexity in a way I didn’t fully appreciate at insightsoftware. Back then, the tools simply didn’t exist or were just emerging. Now your platform must transform so that it thrives in the age of AI. It has to be built in the age of AI, which — depending on whose study you believe — means anywhere from 2X to 10X faster.

And then your team needs to adapt to the age of AI, which again means faster, at higher quality and producing more output. That’s a lot of spinning plates, on top of each other, none of which you’re allowed to drop. 

Oh, and one other plate: this is a centuries-old industry that moves billions of dollars in freight a year and does not stop for anyone. You don’t get to tie the ship up at the dock while you rebuild the engine. Business continuity, zero migration, no breaking the thing people are already running their business on. And do it as fast as you possibly can. 

Building a connected, modern platform

At Veson we had a fleet, not a unified experience. A set of strong, separate hulls, each with its own data, its own experience, its own idea of the world. A collection of great products is not the same as a cohesive foundation, and pretending otherwise is a mistake.  I’ve been guilty of this myself: combining products superficially, so they sit side by side under one roof but still behave as separate entities, rather than as one integrated experience.

In fairness to my past self, before AI even that superficial stitching was slow, labor-intensive and risky, and it often used up the time and budget we’d meant for real integration. AI has worn much of that cost away. The plumbing that used to take months now takes weeks, which frees us to focus on what customers value most: products that work as one.

A platform, in 2026, is three things stacked in order. A singular data layer underneath. One experience on top. And then AI that can reason across all of it. You cannot bolt credible AI onto a flotilla; it has nothing coherent to reason over. The unglamorous work of unifying data is what makes the glamorous AI work possible. 

The part I’m most wary of talking about — because I would rather not tempt fate — is doing all of this safely. Moving fast on all fronts at once is a lovely thing to say in a strategy meeting and a dangerous thing to do in production. The mistake I’ve watched happen (and, if I’m honest, helped cause) is measuring efficacy too narrowly.

If you pick only a few metrics (that you know you can nail) and tell people that’s how they’ll be judged, teams will act accordingly. The side effects get ignored or missed until it’s too late. Often that side effect is quality, discovered downstream when it’s far costlier to fix, or market fit, because value was quietly descoped to hit a date. With AI coding agents accelerating everything, I wasn’t willing to repeat that. We needed 360-degree checks and balances.

The one thing I insisted on and set up from the first week with Veson was working with the engineering intelligence platform Plandek. We measure speed, quality, predictability and focus in real time, so we can see the progress we’re making and spot the side effects before they compound.

AI let us pick up the pace; comprehensive measurement is what lets us keep it without losing sight of the risk. As a result, we get to have our cake and eat it, we upskill the team while the ship is sailing.

Ten months in, here’s what we’ve learned so far.

Product lessons we’ve learned

• Don’t rebuild what already works. “Modernizing” something people rely on is the fastest way to destroy the value you paid for. 
• AI only counts when it functions inside a workflow people already trust. An assistant in a corner nobody visits is a demo, not a product. 
• Aim for a minimum lovable product, not a minimum viable one.
• Continuity is a feature. The moment a customer must “migrate” to your platform, you’ve lost them. 
• One source of truth beats five clever ones. Data you unify late is a tax you pay forever. 

Experiences from our engineering teams 

• Adoption will be uneven. Don’t force the sceptics; convert them with proof. 
• The job itself is changing from writing code to directing it — reviewing, steering and trusting AI as it writes, then verifying. 
• Spread what works peer to peer. A network of AI champions beats a mandate from someone who clearly hasn’t done the work. 
• Measure everything. 
• The fastest teams are the ones who trust the platform beneath them. 
• Faster is only a win if quality holds — protect the gates hardest exactly when the pressure to cut them is highest. 

I don’t think we’ve cracked the code on this. We’re in the middle of it, plates still spinning. But this time I’m making new mistakes rather than old ones, and I’m more convinced than ever that we’re doing this the right way.

This summer, our big concern as IT leaders was figuring out how to drive adoption and ROI for our AI purchases while keeping shadow AI at bay. My advice then:  Give people transparent, sanctioned tools and put in place operational discipline to ensure the right tools are being deployed at the right times and in the right places. That advice still holds up.

But once again, the market shifted. Now, even the sanctioned tools are part of the problem, as we speed towards the autonomous, agentic enterprise.

Fortune reported recently that CIOs are “racing to put guardrails” around agents that one security chief called “a new kind of insider.” Gartner forecasts that 40% of enterprise applications will carry task-specific agents by the end of this year, up from under 5% last year. In the very same report, Gartner also predicts that 40% of enterprises will have to demote or shut down agents by 2027.

We’re building agents faster than we’re learning how to govern them.

Most leaders point to this as a visibility problem. We need to be able to see all the agents running and assign ownership to them. Fair points, but they only reveal the tip of the iceberg. The agents I’m concerned with are the ones nobody knows they’re creating.

Classic shadow AI is a tool someone chose: an employee connects a hyped consumer product straight into a corporate system, and now you have an unsanctioned agent running on unsanctioned software. That’s the fix I have written about before:  give people a sanctioned version good enough that they don’t need the workaround.

The harder case is when an employee schedules a recurring job with their sanctioned AI desktop harness. Perhaps they schedule an agent to scan their email at set times, draft replies that they can send later, maybe even grant approvals on some minor things like direct report PTO requests. 

There’s nothing shadowy about the process. It’s working within a fully sanctioned tool that is being used exactly as licensed. But that employee just built an agent. And most people aren’t calling it that.

For the use cases described above, that’s a productivity tool for a specific employee. If their computer is off or the employee leaves the company and this de facto agent doesn’t run, nothing happens. But what happens if the employee builds a process that reads emails from a shared inbox and updates the ERP based on these emails? Now you have an agent that is part of the back-office automation of the company, and if this employee is off, a potentially critical process is not working. There is also an attack surface that nobody with a security mindset is aware of, a malicious email read by the agent might cause data corruption in the ERP, for example.

The problem is, there’s no owner to name and no approval to audit, because we’re not looking for that as an agent to name and label. You can’t put something on an inventory you don’t know exists. That’s a different failure mode than shadow IT, and it needs a different fix than a better registry.

This is where we begin to see the full depth and breadth of the iceberg we’re dealing with. It opens up entirely new considerations for our governance practices as well. We used to be most concerned with the browser and what employees could be inviting into our networks that way. The bigger concern now with agents is the security of the desktop itself, because that’s where they’re actually built and run. The way to mitigate it centers on two things:  placing hard limits on what any of it can actually touch, and educating employees on what they’re actually doing, at the moment they’re most likely to do it.

Finding the balance point between control and innovation

Here’s where we also come up against the push and pull dynamic that rules our world as IT leaders, especially in the age of AI. Sometimes it seems like we have just two options:  We can lock down the enterprise and hinder productivity and creativity for our employees, or we can make things easy for our employees and put our enterprise security at risk.

The first rule I go by here is embracing the chaos and discomfort. We don’t have this all figured out yet and that’s okay. Where I see my peers fail is when they try to force a process into place in these situations. You end up pushing the behavior you’re trying to manage outside of your area of control, making your employees even more likely to turn to unsafe workarounds.

The better approach is to put in place guardrails that allow your employees some space to experiment but limit the risk. This allows you to have some control while also being able to observe the actions your employees take, and reach out to move local processes to the corporate level.

For example, you can put in place controls directly into systems like CRM or ITSM or the MCPs used to interact with them. For example, make them read-only by default, and put in place rate limits at a more “human level”:  a few hundred records a day, not the few hundred thousand that AI can process. Limit the fields and tables that can be edited, and rate limit them as well.

Then, if an agent misbehaves, whether due to malicious instructions or just a human guidance mistake, you catch the issue after a few dozen records get overwritten, rather than a thousand and retrace your steps to rebuild the files. You’re protected whether an agent is part of a central agent registry or not.

Governance is a literacy problem now, not a policy one

The other half of this has to educate the employees and designated power users, which we call AI Champions that are proxies of the CIO office in the various departments. You need to provide guidance the moment someone starts using it, not filed away in a policy no one reads. Every employee who gets a license for a sanctioned agentic tool at WalkMe takes a short course in basic agent concepts before their license activates.

Most organizations try to launch a full corporate AI training program, where research shows that only about a third of what employees learn is still being used a year later. The training fails because it teaches AI in the abstract, disconnected from the moment someone actually sits down to use it. Gate your training to the access itself, and it lands in the moment it’s most relevant.

The goal in the training isn’t to turn every employee into a developer. That’s not realistic, and I don’t think it’s the right goal either. What you’re aiming for is an understanding of what AI tool to use when: do you need a full-blown agent or just an agentic workflow, or maybe just good old deterministic integration, and the advantages, risks and limitations for each. They walk away knowing what an agent looks and acts like in the moment it’s most relevant, not months later when it’s done something they didn’t intend or expect.

Put those two fixes together and you’re solving a different problem than the one most governance conversations are stuck on. You don’t need a complete agent inventory to navigate this. You need defaults that are forgiving, and employees who recognize the moment they’ve crossed from using a tool to operating one.

AI didn’t just hand every employee a better tool this year. It handed a lot of them some of the responsibilities that used to belong to IT alone. Our job isn’t pretending that didn’t happen, or trying to claw it back. It’s making sure nobody has to become an IT admin to carry that responsibility safely.

On a major S/4HANA transformation, the first signs of trouble did not look like resistance. They looked like missed stand-ups. Then deliverables started slipping, readiness checkpoints came back with gaps and the same functional leads kept surfacing on the list of competing priorities.

The people behind those signals were not disengaged. They were functional resources supporting the implementation while still doing their day jobs. At the same time, the organization was adopting Agile ways of working, so they were also learning new project roles, Agile ceremonies, Jira, new testing expectations and new processes. Many of them held real authority in their day jobs that did not carry over into their transformation roles, which meant they were learning to operate without the standing they normally relied on.

When teams fell behind, the response from leadership was reasonable on its face: more meetings, more follow-ups, more frequent status updates. The intent was to get the program back on track. What I watched happen instead was that the same people responsible for completing the work spent more of their week explaining why the work was behind.

That is the pattern most organizations miss. Change saturation gets diagnosed as a communication gap, and the treatment consumes the capacity the team needs to recover.

What misdiagnosed saturation looks like on the ground

Saturation rarely announces itself in an engagement survey. It shows up first in delivery mechanics, and those signals are easy to read as a discipline or messaging problem.

The first signal is erosion in attendance, not pushback. Stand-ups get missed, ceremonies get shorter and the same names drop off invitations. Nobody is objecting to the transformation. They are triaging their calendars.

The second signal is status work crowding out delivery. When a growing share of a team’s week goes to preparing updates, attending check-ins and answering follow-ups, the program has started paying for visibility with the capacity it needs for execution.

The third is readiness gaps that get labeled as training issues. People who attended the sessions still are not ready, because the sessions competed with everything else on their plate and landed at the wrong moment.

The fourth is easy to overlook on global programs: capacity assumptions that do not match the actual calendar. On more than one program, the roadmap accounted for U.S. holidays and overlooked holidays affecting large portions of the teams in India, South America and other locations. The plan was built on capacity that was never there, and the gap surfaced weeks later as slipped dates.

Taken together, these signals point to the same root cause. The work did not get harder. The load did. Yet each signal is usually treated as a separate performance issue and handled with more oversight.

None of this is unusual. In Prosci’s research on change saturation, 78 percent of respondents said their organizations were nearing, at or past the point of saturation, and people managers and front-line employees carry the heaviest load. Those are the same people a transformation depends on to adopt and operate what it delivers.

Why more communication makes it worse

When a program falls behind, the executive instinct is to increase pressure around the existing dates. Add a working session. Increase the cadence of status reporting. Ask for more frequent communication so leadership can see what is happening.

Every one of those moves is made with good intent, and every one of them draws from the same limited pool of time. The people being asked for more updates are the people who were already stretched. On a program adopting Agile at the same time, the added forums sat on top of stand-ups, planning sessions and retrospectives the teams were still learning to run. Visibility goes up, capacity goes down and the program slips further. It also changes how the team experiences the program. Instead of support, they experience scrutiny, and people already carrying two jobs start to feel that the program mostly adds questions.

There is a line I use with leadership teams when this starts to happen:

When a team is behind, the instinct is often to add oversight. But every additional status meeting takes time away from the work you’re trying to accelerate.

Communication and visibility matter. They do not solve an underlying capacity problem, and sometimes they deepen it. Gartner found that only 32 percent of business leaders said the last change they led achieved healthy adoption by employees, and Gartner has argued that leaders get further by making change routine than by trying to inspire people through it. Saturation is a load problem. Louder or more frequent messages to an overloaded team do not reduce the load.

What actually relieves saturation

The moves that worked on my programs were less about new frameworks and more about giving capacity back.

Adjust the operating model as teams mature. Early go-lives needed frequent stand-ups, heavy training and hands-on support. After teams had been through multiple S/4HANA go-lives and understood the process, we deliberately reduced the cadence. Daily meetings became four days a week and eventually two. Holding on to the early-phase cadence after teams had outgrown it would have been another quiet drain. Reducing meetings on a program that has just slipped feels counterintuitive. It requires leadership to trust the dashboards and the team more than the meeting count.

Protect time when the team is on track. On one program, we kept Mondays and Fridays free of meetings when the work was on schedule. It signaled that the time belonged to the work, and teams used it.

Make upcoming work visible instead of asking for more reporting. Readiness dashboards showed what was coming, and we gave advance notice when phases were changing so people could plan around the shift rather than react to it. The dashboards did the job the extra status meetings were trying to do, without taking anyone out of the work.

Make support available without requiring attendance. Recorded training, multiple sessions and office hours let people get targeted help when they needed it without adding another meeting to everyone’s week.

Understand the change landscape before launching the next initiative. That means surveying employees and listening beyond the executive level to the functional teams who will do the work. Executives tend to see initiatives one at a time. Employees experience their cumulative impact alongside their day jobs. Research highlighted in MIT Sloan Management Review found that employees can realistically absorb one or two major changes a year, while leaders are planning for three or four. A short survey of the functional teams will usually surface collisions a portfolio view misses, because those teams feel every initiative that lands in the same week.

The principle behind all of this is one I come back to on every program: “You can’t ask people to absorb more change without giving them something back.”

For CIOs, change saturation is a portfolio decision, not a communications task. CIOs sit where multiple initiatives converge on the same functional teams, and they are often positioned to see the cumulative load before anyone else does. The decisions that relieve saturation are theirs to shape: what gets sequenced first, what waits, what cadence a mature team actually needs and whether the capacity assumptions behind a roadmap match the real calendar.

One practical test helps. Before approving the next initiative or the next status forum, ask which work the affected teams will stop doing to make room for it. If nobody can answer, the capacity is being borrowed.

The organizations that sustain transformation across multiple waves are not the ones with the best change campaigns. They are the ones that treat capacity as a constraint to be managed with the same discipline they apply to budget and scope.

You can’t communicate people into having more capacity. You can only decide, deliberately, how much change you ask them to carry at once.

In a recent finance training session, an FP&A analyst took the prompting method we had covered twenty minutes earlier and applied it to a monthly variance report spanning four business units. The report normally took one and a half to two hours. It was finished in about two minutes, live, in front of the room. Every leader watching did the same math: if experienced people can work like that, why hire the junior analyst in next year’s budget?

That question sits under most of the early AI jobs story, which has been dominated by fear: fewer junior openings, thinner entry-level ladders and senior employees using AI to absorb work that used to train the next generation.

There is evidence behind that concern. Researchers at the Stanford Digital Economy Lab found that employment among workers aged 22 to 25 had fallen in occupations with high exposure to generative AI. The effect was concentrated in jobs where AI could automate tasks. Employment held up better where companies used AI to support employees.

The companies furthest ahead on AI appear to be doing the opposite, according to recent research from Revelio Labs and Ramp reported by the Financial Times. Among nearly 22,000 U.S. companies, the heaviest AI adopters grew white-collar headcount by 10.2% over two years, with entry-level roles up 12%.

The study does not prove that AI caused the hiring. AI adopters were already larger, more engineering-focused and more likely to be growing, but the findings still matter. Companies making serious investments in AI were expanding their workforces, including their junior ranks. Companies making serious investments in AI were expanding their workforces, including their junior ranks. The difference is team design. AI productivity gains have a shelf life: within a year or two the new pace becomes the baseline, and companies that cut their junior layer to capture those gains will have no one ready to step up.

In my previous CIO article, I argued that successful AI adoption requires companies to change how they operate. Giving employees new tools while leaving existing workflows and decision-making structures in place produces scattered experiments and limited gains. Companies need to give the people closest to the work more authority to test AI, improve processes and teach others what works.

Team design is the next part of that transformation. Once AI changes how work gets done, companies also need to change how teams are built and how employees develop. That includes the junior roles where people gain the experience required to become future managers and specialists.

Cutting junior roles creates a capacity problem

The mistake is easy to make. A company trains its existing staff on AI. Suddenly, experienced employees are 30% to 60% more productive. Junior hires start to look like overhead. For a while, that logic feels rational.

The problem is that this kind of approach has an expiry date. A year or two from now, those productivity gains will be absorbed into the business. The new pace will become normal. Clients will expect more. Internal teams will take on more. Senior employees will be stretched again; except this time there won’t be a trained junior layer underneath them.

The company then has limited choices. It can overwork its experienced staff, compete for expensive external hires or promote people before they are ready. Each option carries a cost.

This is a pipeline problem as much as a hiring problem. Companies cannot produce experienced employees on demand. Judgment develops through repeated exposure to real decisions, feedback and consequences.

Research on AI and customer service offers a clue about how companies can approach this. A study of more than 5,000 support agents found that access to a generative AI assistant increased productivity by 15% on average. Less experienced workers benefited the most. The system helped them apply some of the practices used by higher-performing colleagues.

That finding should interest any leader thinking about early-career development. AI can help junior employees reach competence faster when the tool contains useful organizational knowledge and employees receive guidance on how to use it.

Building teams like multi-agent systems

When we build multi-agent AI systems, we usually build them in a hub-and-spoke model. There’s an orchestrator agent in the middle, then smaller agents handling specific tasks around it. In a marketing function, for example, one agent might handle social media, another might handle SEO, another might handle analytics and another might handle reporting. The user works through the orchestrator, which coordinates the system.

I think this model offers a useful template for team design.

The senior employee acts as the hub, with junior employees and AI agents working as the spokes around them. Instead of simply delegating tasks, that senior person shapes how the work gets done: teaching the AI systems and juniors what good looks like, and helping junior employees build judgment by working inside the same system. The junior employee learns from the AI by seeing how it approaches research, drafting, analysis and problem-solving; the AI improves because the junior is constantly correcting, refining, rejecting and escalating its outputs.

That’s where the training model changes. Historically, juniors learned through repetition, writing the first draft, building the spreadsheet, checking the details, sending the recap and slowly absorbing the standards of the job. AI will take over parts of that repetitive work, but it won’t remove the need for training. It changes where the learning happens: juniors are no longer just learning by doing the task from scratch, they’re learning by directing the task, judging the output and feeding better decisions back into the system.

A junior employee now needs to learn how to question an AI output, spot weak reasoning, understand what a client or stakeholder actually needs, and know when to escalate. This kind of judgment is built like a pilot’s instincts: not by watching someone fly, but by spending time in the cockpit as experienced pilots navigate real decisions.

What companies should hire for now

This changes what hiring managers should look for in junior talent.

Curiosity has always been a crucial quality to look for, but it matters even more now. Juniors need to be willing to learn the tools and understand how AI changes the work. But the stronger signals are emotional intelligence, good interpersonal instincts, discernment, judgment and the ability to explain why they made a decision.

The World Economic Forum’s Future of Jobs Report 2025 supports this broader view of skills. Employers expect AI literacy and technological capability to grow in importance. They also continue to value analytical thinking, curiosity, leadership and social skills. The report found that 77% of surveyed employers planned to upskill workers in response to AI disruption.

That’s also why senior employees need to work differently. Engineers need to spend more time with business teams, so they understand how the company actually operates. Business teams need to spend more time with technical teams so they understand what the tools can and can’t do.

If companies want to keep moving faster, they still need to hire junior talent. But the apprenticeship has changed. Instead of learning by taking repetitive work off someone else’s plate, juniors now join AI-enabled teams where they can see how experienced colleagues think, learn from the systems those colleagues build, and develop judgment through decisions they’re gradually trusted to make. We’re all managers now, some will manage humans, some will manage machines and a select few will build the skills to manage both.

The AI industry says enterprises can’t absorb AI. Its answer is to absorb it for them.

That’s not the same thing.

The engineer across the table knew the model cold. Not vendor-deck cold. He could tell me where it would break, what it would cost, and which benchmark numbers to ignore. One of the better technical minds who has ever sat in that chair.

Forty minutes in, I asked which of our problems he would point to first. He named a minor workflow one of my directors had mentioned that morning.

The easy read is that he didn’t know my business. True, and not very interesting. Here is the real issue: the people who sent him are making the exact mistake they are being paid to fix.

They’re not wrong about the problem

The frontier labs aren’t confused, and I want to be fair before I disagree.

MIT found that about 95% of enterprise AI pilots produced no measurable profit impact, despite tens of billions spent. Winning the benchmark wasn’t winning the deal. And a customer who never gets to production never renews.

So, they did the logical thing. They sent engineers:

• OpenAI: Launched the OpenAI Deployment Company in May with $4 billion of initial investment from 19 partners, starting with 150 forward-deployed engineers (FDEs) and deployment specialists.
• Anthropic: Partnered its engineering capability into an enterprise AI services venture with Blackstone, Hellman & Friedman, and Goldman Sachs, reportedly valued above $1.5 billion.
• Microsoft: Launched Frontier Company in July with $2.5 billion and approximately 6,000 embedded engineers and industry experts.
• AWS: Committed $1 billion to a forward-deployed engineering unit embedding engineers with customers.
• Market surge: FDE job postings grew roughly 800% in nine months, with principal-level compensation past $1.2 million.

That is a serious response. But it answers the wrong question.

All that capital is aimed at getting customers into production and keeping them there. We have been reading it as the playbook for getting AI into the wider economy. Those are two entirely different problems, and only one of them currently has anyone working on it.

The same mistake, twice

One structural fact tells you what this really is: the forward-deployed function sits on the commercial side of these companies, not in research. OpenAI capitalized its deployment arm as a separate business with outside investors.

That’s not an accusation; the org chart is simply more honest than the positioning. What that structure measures is pilots converted to production within the quarter. Against that scoreboard, the model isn’t shallow at all. It’s optimal.

Now look at the same failure from my side of the table.

A team builds an intelligent demand-forecasting agent. Accuracy improves by double digits. The engineering readout is genuinely good. And absolutely nothing happens to cash.

Accuracy was never the point. It only matters if it changes an operational decision: how much safety stock you hold, what commitments you make to suppliers, or what you schedule to build. If none of that changes, you haven’t freed a single dollar. Worse, if the model was tuned for fill rate, because that’s what the commercial team asked for — inventory climbs, working capital gets suffocated, and you are worse off than before. The project wins. The company loses.

Anyone who runs S&OP knows this reality: inventory is cash sitting on a shelf. Every forecast is a claim on that cash. Every service-level promise decides how much liquidity you lock away. The value is never in optimizing a single, isolated number; it is in managing the trade-offs between them.

Outside engineers cannot own those trade-offs. Look at what their engagements are sold on: a deflected ticket, an automated records request, a closed underwriting case. Local, siloed inside one function, and measurable in weeks. Those are the only outcomes an outsider can deliver before rolling off to the next logo.

The results a CFO cares about cross three functions and only show up in cash two quarters later.

Delivery vs. Diffusion

This gets celebrated as AI reaching the real economy. In practice, it does close to the opposite:

• The learning runs one way. Anthropic’s job listings are the most explicit about this, asking engineers to codify repeatable deployment patterns and contribute those insights back to product and engineering. That is honest, and it is the point. Analysts have flagged the same concern from the buyer’s side: that deep reliance on frontier labs hands those labs insight into the very industries they may later enter.
• Capability is replaced instead of built. The engagement leaves behind a functioning workflow, but zero internal muscle to solve the next bottleneck. Constellation Research warned this year that FDEs are often used as a crutch for product immaturity, and as part of a broader vendor dependency play. Without Palantir’s feedback loop — where every deployment continuously enriches an integrated customer ontology — this is simply an expensive systems consultancy with a frontier brand name.
• The mid-market waits. Dice reported in August that the shortage of engineers is now directly holding back enterprise AI returns. The scarcest engineering talent sits inside Fortune 50 anchor accounts, while the companies that make up most of the economy queue behind them.

In engagements structured this way, the lab learns your business. You learn their product.

So here is the test I now apply to any engagement, including the ones I sign: when it ends, are we better at finding the next problem ourselves?

If the capability leaves the building when the outside engineer packs up their laptop, that was delivery, not diffusion. Delivery is a fine business, but it doesn’t compound. Diffusion is nothing but compounding.

What we did instead

We eventually fixed our inventory problem.

Not by pointing an off-the-shelf frontier model at raw ERP tables, but by redesigning our entire planning architecture from the ground up. We staffed the initiative with operators who had spent years inside our supply chain and knew where the real constraints actually sat — the lead time, the allocation rule, the supplier commitment that no outsider would have known to model and then applied AI directly to those decision points.

The result: Inventory came down and stayed down, turns improved, and the part that matters for this argument, nobody had to be flown in to do it again the following quarter.

There is no version of that outcome a single outside engineer could have designed, no matter how brilliant the model in his hands.

The bigger stake

Scale this up and the macro picture becomes clear. A country’s AI advantage will not come from a few hundred flagship deployments. It will come from millions of operators applying AI to operational decisions they were previously making badly.

Which brings me back to the man across the table.

We are spending millions sending AI experts to learn business. We should be sending business operators to learn AI.

• Business knowledge is slow. It took most of my career to instinctively know which trade-offs to make around working capital and inventory.
• AI execution is fast. An experienced operational team can master agentic tooling, evals, and model orchestration in a matter of months.

We are running the harder transfer at immense cost and mistaking it for progress.

I don’t need more forward-deployed engineers. I need backward-deployed domain experts.

Nobody is selling those. Which means the only people who can build them are already on your payroll.

In my experience, where you place product management is as critical as whom you hire and how you train them. A team expected to serve the whole organization needs the influence and independence to act for the whole organization.

My view comes from working in companies ranging from trillion-dollar enterprises to startups, and from ongoing conversations with peers and industry leaders building product functions of their own. I have watched a particular mistake repeat itself, most often in smaller organizations under pressure to show fast results with technology.

These organizations make the right call by building a product function. Where they falter is in giving too little weight to where it sits. In my experience, some leaders have never worked with a product manager or been one themselves. They do not fully appreciate what functional independence makes possible.

The sequence is familiar: boards want efficiency, technology becomes part of the answer and the company hires product managers. The new function then lands under whichever business unit head has the most influence, and the placement goes unexamined. The result is a new inefficiency built to solve an old one.

The familiar saying is that culture eats strategy for breakfast. My version is that placement eats good intentions for lunch. Good people and good training matter enormously. Their effectiveness also depends on whether the structure empowers them to work for the organization rather than one corner of it.

How placement narrows the team’s priorities

I see this pattern most often when an organization is establishing product management for the first time, including in financial services and mortgage servicing. Product lands under a single internal function, often close to operations, through momentum rather than a deliberate decision about its independence.

My concern starts with incentives. The person who controls a leader’s performance review and compensation has considerable influence over that leader’s priorities, whatever the charter says. A product team placed inside one function can inherit that function’s metrics. Backlog conversations then start favoring the sponsoring department’s targets over the organization’s needs.

In its analysis of product reporting relationships, TSIA makes the case for the senior product leader to report to the CEO or business unit general manager, as a peer to other leaders. Its research concerns technology businesses; the principle relevant to my experience is the ability to maintain a view across the business.

When other functions cannot get resources, they build their own workarounds. In my experience, the result is consistently worse than if product had addressed the need from the start. Nobody needs to act in bad faith for this to happen. Each department can be pursuing the targets the organization gave it.

That is the local-optimization problem discussed in Askeladden Capital’s explanation. Its example draws on Howard Schultz’s account in Onward of Starbucks focusing too heavily on same-store sales in the mid-2000s. The connection I draw is simple: success against one set of measures can come at the expense of the wider business.

Placement also affects who participates when priorities are set. If product reports into one department, others with an equally valid claim on its time can be left out. The room itself is incomplete.

In a 2026 analysis of product team structure, Userpilot’s Abrar Abutouq describes the risk of product becoming project management when it is buried under IT or operations. I see the same distinction in the argument for independence: the team needs standing to challenge priorities, rather than simply track decisions already made.

What frustrates me is seeing organizations repeat a problem that has already been examined elsewhere.

The issue is especially familiar to me in organizations newly experimenting with product management in mortgage servicing and lending. They are moving quickly and trying to improve how the business works. Yet skipping the structural decision can undermine that intention. My advice is to give placement the same attention leaders already give to finding capable people.

What functional independence requires

Product Focus’s 2026 survey found that 80 percent of respondents reporting at CPO level saw product management as a leadership role, compared with about 50 percent reporting into development or sales. That is a finding about perceived leadership status, rather than proof that a reporting line alone improves performance. It supports taking the team’s organizational standing seriously.

Simon Cast makes a related point in Mind the Product: reporting to the CTO can create a perception of bias toward technology, undermining product’s ability to balance business, customer and technical considerations. In my view, that concern applies wherever product’s organization-wide mandate sits inside a narrower function.

Marty Cagan’s organizational model at Silicon Valley Product Group places product management and design alongside marketing and engineering. His model allows reporting to a CEO, COO or business unit general manager. It supports distinct voices at the leadership table, rather than a CEO-only rule. My preference remains a direct line to the CEO when the team serves the whole company.

Products That Count’s 2025 CPO Insights Report reports that the share of Fortune 1000 companies with a CPO rose from 3–4 percent in 2020 to more than 30 percent two years later. I see that reported growth as another reason to take product’s seat at the leadership table seriously, rather than place it automatically inside an existing function.

However, moving a box on the org chart is not enough. Leaders first need an honest view of where the company is going and what role technology plays in that future. They can then decide what kind of product function they need. For the mid-size organizations I am describing, I believe that function needs a mandate across the organization.

Individual product managers can work closely with specific business units and develop domain expertise. I consider that proximity valuable. Authority over how resources are allocated, however, needs to reflect the whole portfolio. Listening to a department and being controlled by its priorities are different arrangements.

I also see a forward-looking implication for AI-supported prioritization. If a product team uses AI to synthesize backlog signals, usage data and business objectives, I would still expect its independence to matter. More sophisticated tools do not resolve an incentive structure that favors one internal function. My concern is that they could simply reinforce it.

My advice to leaders establishing product management

Before settling the reporting line, decide whether product is expected to serve one department or the whole organization. If the mandate is organization-wide, give its leader direct access to executive leadership and authority to consider resources across the portfolio. Make that placement a deliberate decision alongside hiring and training.

Keep the team open to influence from every department. Give individual product managers room to build deep business knowledge, while keeping the wider function’s priorities independent of any single department’s targets. Pay attention to performance reviews and compensation: the expectations attached to them need to match the breadth of the mandate.

That is my central lesson from experience and conversations with peers. A capable team needs an organizational position that lets it use its judgment for the whole company. Leaders seeking technology-driven efficiency should establish that foundation when they create the function, rather than leave the team to work around its absence.

What if the most disruptive change to enterprise software is not another application, but needing fewer humans to operate the applications we already own?

For decades, we digitized work, integrated systems and moved applications to the cloud. Now we are entering a different era: software is beginning to participate in the work itself.

This changes more than productivity. It changes architecture, economics, security, governance, and ultimately the enterprise operating model.

For most of my career, enterprise application strategy began with these four familiar questions:

• What capability does the business need?
• Should we build, buy or integrate it?
• How does it fit the architecture?
• Can we secure, operate, scale and afford it?

Those questions remain important. But they are no longer enough.

Enterprise applications have historically been places where people perform work. Employees navigate screens, enter information, reconcile exceptions, move between systems and trigger workflows.

The relationship has been remarkably consistent: The application provides capability. The human orchestrates the work.

AI and agentic AI begin to change that relationship.

The strategic question is therefore no longer simply, “What functionality should the application provide?” It is becoming: “Who or what should perform the work?”

We are moving from applications people operate toward outcomes people increasingly supervise.

Gartner has predicted that by the end of 2026, 40% of enterprise applications will feature task-specific AI agents, up from less than 5% in 2025, and anticipates agent ecosystems spanning applications and business functions.

I call this discipline required to manage that transition Enterprise Work Architecture (EWA): The deliberate design of how an enterprise outcome moves across human judgment, machine intelligence, applications, data and authority from intent through execution and evidence.

EWA is not another application architecture, process map or AI governance framework. It starts with the work itself.

The problem is the work between applications

Traditional architecture organizes capabilities around discrete systems: ERP, CRM, HCM, ITSM and procurement. Business outcomes rarely respect those boundaries.

Today, humans often bridge those systems, searching, reconciling, interpreting and escalating. AI Agents can now compress those seams by gathering context, interpreting intent and coordinating authorized actions. The opportunity therefore is not simply AI inside applications; it is redesigning how work travels across them.

I learned through my experience that across complex transformations, some of the greatest productivity constraints lived between systems, teams, approvals, data and exceptions.

Modernizing the platform does not necessarily modernize the work. Put an agent over a broken 12-step process, and you may simply automate the friction.

Automation without work redesign can turn process debt into machine-speed process debt.

EWA: A CIO methodology

I would make EWA discipline operational through six connected steps:

Outcome → Work → Authority → Execution → Evidence → Economics

1. Outcome: What measurable business result are we trying to produce?
2. Work: Which activities are necessary, which should disappear, and which require human judgment?
3. Authority: What may a person, application or agent recommend, prepare, approve or execute?
4. Execution: Which systems, APIs, data and workflows must participate?
5. Evidence: Can consequential actions be observed, reconstructed, challenged and recovered?
6. Economics: Did redesigning the work improve time, cost, quality, risk or experience?

The sequence matters here because many AI initiatives begin in reverse: choose a model, deploy a copilot, connect applications and then search for value.

EWA begins with the outcome and designs backward.

Before and after EWA: A customer billing dispute

Consider a customer whose invoice does not match delivery.

Today, an employee moves across CRM, ERP, fulfillment and contracts, often involving finance or operations before a credit can be approved. One outcome becomes a journey across systems, teams and controls.

EWA discipline redesigns this process:

• Step 1: Outcome. Resolve valid disputes quickly, accurately and within financial controls.
• Step 2: Work. Machines gather and reconcile evidence; humans handle ambiguity, exceptions and consequential judgment.
• Step 3: Authority. Agents recommend or execute within defined thresholds; exceptions escalate.
• Step 4: Execution. Actions flow through governed APIs into authoritative systems.
• Step 5: Evidence. Data, decisions, actions, authority and human intervention remain traceable.
• Step 6: Economics. Measure resolution time, human touches, exceptions, rework, cost and customer impact.

That is the difference between automating a task and rearchitecting the work. And that is the EWA discipline.

The innovation is not an agent writing a faster email. It is redesigning end-to-end work while preserving the integrity of the systems underneath it.

Four disciplines make EWA scalable

Turning EWA into an enterprise capability requires four disciplines.

1. Decompose work before deploying agents

Map intent to outcome. Identify judgment, deterministic activity, waiting, handoffs, exceptions and unnecessary steps. Then decide whether AI should retrieve, interpret, recommend, prepare, execute or escalate.

Remember: Do not automate what you have not first challenged.

2. Separate engagement from systems of record

Employees should increasingly be able to express an outcome: resolve this dispute, investigate this variance, restore this service without manually navigating every underlying application.

That does not diminish ERP, CRM, HCM, SCM or ITSM. It makes their data integrity, APIs, transactional controls and resilience more important.

Systems of record remain authoritative; intelligent orchestration increasingly becomes the engagement layer above them. Gartner similarly describes a progression toward agents operating across applications and business functions.

3. Treat agents as governed enterprise participants and not software features

Once an agent can cross application boundaries and act, connectivity is insufficient. It requires identity, delegated permissions, purpose, data boundaries, transaction limits, segregation of duties, observability, escalation and lifecycle controls.

Retrieving an account balance is not changing a customer record. Preparing a purchase order is not releasing it. Diagnosing an incident is not changing production.

Remember: Capability cannot silently become authority.

The NIST AI Risk Management Framework organizes AI risk management around Govern, Map, Measure and Manage. For CIOs, the practical implication is that as machine agency increases, controls must increasingly operate at runtime, not only at project approval.

4. Measure work redesigned — not AI deployed

Counting agents, prompts, licenses or automated tasks tells a board little about whether enterprise economics improved. Measure time-to-outcome, human touches, exception rates, rework, cost per governed outcome, control overhead and value created.

Gartner has estimated that $234 billion in enterprise application software spending is at risk from agentic AI as organizations reconsider how software capabilities are consumed and work is executed.

The goal is not to make every task faster, but to determine which should disappear, which should be redesigned, which machines can safely perform and which still deserve human judgment.

Applications may become less visible — and more important

This creates a paradox.

Enterprise applications may become less visible to users while becoming more important operationally. Meaning, instead of opening five applications to achieve one outcome, an employee may interact with an intelligent workspace orchestrating those systems underneath. ERP still protects financial integrity. CRM maintains customer context. HCM protects workforce records. SCM coordinates fulfillment. ITSM governs services.

What changes here is the human relationship with them.

That affects application portfolios, integration architecture, licensing economics, cyber exposure, resilience and technical debt. The modernization question becomes not simply, “Which applications should we replace?” but “Which application interactions should humans still have to perform?”

The same issue matters during M&A, where enterprises can inherit duplicate ERP, CRM, HR, identity, data and workflow estates. Agents may provide orchestration while rationalization proceeds, but can also amplify inconsistent permissions, fragmented data and unresolved control ownership.

Deloitte’s Generative AI in M&A research examines generative AI across the deal lifecycle alongside considerations including integration, security, trust and human involvement.

The CIO’s mandate is becoming the architecture of work

This cannot belong to IT alone because work does not belong to IT.

Business owns outcomes. Operations understands process reality. Finance measures enterprise economics. Security establishes trust boundaries. Risk and Legal define obligations. HR understands workforce consequences. Audit tests controls. Enterprise Architecture connects them to systems, data and execution.

The CIO’s opportunity is to make those disciplines coherent.

Start with a work inventory, and not another AI inventory.

Find where employees bridge systems, exceptions concentrate, approvals create latency, repetitive activity consumes capacity and application boundaries become organizational boundaries. Then apply EWA discipline: Outcome. Work. Authority. Execution. Evidence. Economics.”

That creates a repeatable methodology for deciding not merely where AI can be deployed, but where enterprise work should be redesigned.

Boards can then ask a more consequential question: “Are we funding AI features or redesigning how the enterprise operates?”

The first can produce a larger technology portfolio.

The second can change productivity, operating leverage, experience, risk and ultimately enterprise value.

Do not begin with how many agents you can deploy. Begin with the work your enterprise should no longer perform the same way.

Redesign the outcome. Remove unnecessary work. Define authority. Connect execution. Instrument evidence. Establish the economics. Protect human judgment where consequence demands it. Then scale.

The enterprises that lead this transition will not necessarily have the most autonomous software. They will be those that most deliberately determine where humans create judgment, where machines create leverage and where the combination creates measurable enterprise value.

The next generation of enterprise applications will not simply run the business. They will increasingly participate in running it. The CIO’s responsibility is to redesign the work without surrendering the judgment, trust and accountability on which the enterprise depends.

For a few years now, the headlines have become familiar: yet another company laying off workers as a result of AI. But in recent months, we’ve seen a new twist. Some of those same companies are now reconsidering staffing decisions after recognizing the continued need for experienced professionals.  

Ford offers a telling example. In 2023, the company leaned heavily into AI-driven quality control, relying on more than 900 AI-assisted cameras to identify defects at scale. Leaders believed the technology, combined with revised design requirements, would be enough to maintain product quality. It wasn’t. As defects and quality challenges persisted, Ford concluded it had overcorrected in its push toward automation and technology-led processes. The company ultimately rehired 350 veteran engineers, often referred to as “gray beards,” over a three-year period, recognizing that experience, judgment and deep institutional knowledge remained essential.

The company was careful to say this wasn’t a total about-face. According to Ford, it wasn’t a decision to replace AI but to retrain it, catch failure points early and mentor younger staff. As Poon put it, “AI is a powerful tool for catching potential quality issues, but it’s only as good as the people using it.”

And Ford’s results suggest that this approach is working. CEO Jim Farley credited the move with generating “hundreds and hundreds of millions of dollars” in warranty and recall savings. Ford also topped the mainstream automotive brand rankings in J.D. Power’s 2026 Initial Quality Study, its strongest performance in 16 years.

Rather than viewing this as a failure, I see it as an example of organizational courage. In a moment when many leaders are racing to adopt AI, it takes confidence to experiment, evaluate the results honestly and course-correct when the outcomes don’t meet expectations. In my view, this is a more complex and cautionary tale about what separates AI adoption from AI success at a time when we are all trying to figure it out. AI can accelerate analysis, surface patterns and scale knowledge. But judgment remains the capability that turns those inputs into decisions, action and business value. That’s good news for us humans. As AI becomes more capable, our judgment and critical thinking skills become more important, not less.

AI is a force multiplier, not a replacement for expertise

There was an important realization at the center of Ford’s decision: their AI-driven computer vision systems could identify potential anomalies at scale, but experienced engineers were still needed to determine which signals mattered, what risks they represented and what actions should follow.

Research suggests this dynamic extends well beyond the automotive industry. In a recent study by Harvard Business School and UC Berkeley, a field experiment of more than 600 entrepreneurs, AI access widened the gap between high and low performers. Researchers found that the difference stemmed from how participants selected and implemented the AI advice they received.  In the same vein, last year, MIT found that AI models use more confident language precisely when they are hallucinating — a worrying behavior that reinforces why human verification and discernment are non-negotiable.

This isn’t just an academic conclusion, nor is it unique to Ford. Other major employers, including Google, Booz Allen Hamilton and CSX, have recently increased hiring in key areas as companies gain a clearer understanding of AI’s capabilities and limitations. Executives now say they still need experienced professionals to deploy, oversee and complement AI, particularly in complex functions like engineering, cybersecurity and cloud computing.

In the project management field, I see this, too. Teams that treat AI outputs as inputs to a judgment process outperform those that treat AI outputs as answers. The organizations winning with AI are pairing it with, not substituting it for, seasoned expertise.

The rising value of complex problem solving and discernment

When everyone has access to the same tools, differentiation comes from human judgment and critical evaluation. A recent roundtable hosted by Accenture and iResearch came to the same conclusion, positing that 15% of content is now AI slop.

In fact, people who can position themselves as so-called “AI orchestrators”, combining AI fluency with deep domain expertise, are earning more, while the value of low-level, unedited AI output is declining. This underscores why these professionals are more valuable than ever to their organizations. The Ford example reinforces this. The engineers who were rehired weren’t brought back to do manual labor that AI could replace; they were rehired for their domain expertise and judgment built over decades that AI hasn’t replicated.

For CIOs, this new dynamic is likely to change how you evaluate talent and design roles and teams. Judgment and critical thinking should be explicitly assessed and cultivated, not assumed.

What this means for how CIOs build teams and lead

There’s also a practical shift happening, and a broader lesson we can learn from Ford: AI success is rarely determined by the model alone. It depends on the goals, governance, expertise, talent and decision-making systems surrounding it.

As the PMI Standard for Artificial Intelligence in Portfolio, Program and Project Management demonstrates, there is a growing realization among leading organizations: the most successful AI systems combine AI capabilities with structured human judgment, governance and accountability.

In practice, leaders can take actionable steps to build structured checkpoints at which experienced staff review and validate AI outputs, especially in high-stakes workflows, such as those reflected in PMI Certified Professional in Managing AI’s (PMI-CPMAI) phased governance approach.

From a culture and team-building perspective, Ford’s veteran engineers also played a critical, irreplaceable role. They were training and coaching the next generation. That’s another reason why CIOs should treat experienced talent as a retention and knowledge transfer priority, not a cost center to shrink. This is an investment in the future health of your organization.

Avoiding the overcorrection

The answer isn’t to replace human-driven workflows with AI, nor to reject AI altogether. The right path lies somewhere in the middle. Rejecting AI entirely out of fear is unwise when the technology can unlock so much business potential both now and in the future.

The sweet spot is augmented intelligence: knowing where AI adds speed and scale, and where human judgment must have the final say. Bring AI into the workflow as a collaborator because your competitors certainly will. Then make human judgment the differentiator.

Judgment is the skill that scales

My call to action, plain and simple: judgment is not optional. AI didn’t fail Ford, necessarily, but the company’s transformation struggled because judgement wasn’t sufficiently integrated at scale. As AI adoption accelerates, CIOs should treat project management skills, judgment, critical thinking and decision-making as core competencies to hire for, train for and protect. These are the capabilities that will determine whether AI delivers business value at scale. The organizations that win with AI won’t be the ones with the most AI tools, or those that hastily cut the most jobs. They will be the ones that best integrate AI into decision-making and business outcomes and know exactly where to keep humans in the loop.

In one stretch last year, several executives at the same level in one organization each told me, separately, that the hardest part of their job was talking candidly to each other. Each had spent 15 to 25 years in technology, and none of them was struggling with the technology.

I’ve coached more than 1,000 technology professionals one-on-one, and a large share of my practice is now CIOs, CTOs and VPs of engineering and product. AI is supposed to be freeing these leaders from operational work so they can spend more time coaching, giving feedback and working through conflict. What I see instead is that AI is raising the bar on people leadership faster than most senior IT executives can learn to clear it.

AI hasn’t lightened the load for the IT leaders I coach

My clients tell me the relief AI promised hasn’t arrived. They’re expected to produce more, they’re in meetings most of the day and the person above them often doesn’t see how much work the new AI output takes. Several now have a half-dozen AI agents running in the background on top of their existing responsibilities, and nearly all of them oversee teams that do. The agents didn’t replace work. They simply added another layer to supervise, which is one reason so many senior IT executives are burning out without telling anyone.

The research matches what I hear. Microsoft’s 2025 Work Trend Index special report found that 52% of leaders say their work feels chaotic and fragmented, and one in three employees said the pace of work over the past five years has made it impossible to keep up. Deloitte’s 2026 Global Technology Leadership Study, which surveyed more than 660 senior technology executives, found that 41% report their organization sees them as unable to keep up with demand.

AI is also creating decisions that didn’t exist a few years ago. One engineering leader I coach at a large tech company co-leads an organization of a couple hundred people with his product counterpart. The two of them now receive a monthly budget of AI tokens and have to decide together how to allocate them across their teams. That’s a negotiation between peers over a scarce resource, and it lands directly on the skill most of my clients tell me they struggle with.

The leaders I interviewed for this piece described the same split. Yogesh Joshi, senior vice president of global AI platforms at TransUnion, said AI is accelerating the product development lifecycle at his company, but that “it does not create trust, resolve conflict, develop talent or align teams around shared goals.” Diya Jolly, chief product and technology officer at Xero, said AI can draft a product requirements document or scaffold production code in minutes, but it can’t “own the hard tradeoffs, like do we build feature A or B?”

That’s how AI exposes weak people leadership. When it absorbs the technical work, what remains is the people work, and the people work is where many senior IT leaders have had the least practice.

Difficult conversations are the gap I see most often

The executives I described at the start weren’t unusual. Most of the CIOs and VPs I coach struggle with some version of a hard conversation, even though they’ve been leading for decades. Some can’t give their CEO tough feedback. Others put off telling a direct report they missed the mark. The most common, and in my experience the hardest, is the conversation with an executive peer.

Product and engineering are where I see it most. One client, a senior engineering leader, held off for months on a conversation with his product counterpart about who owned the roadmap and who decided which features got prioritized. He shared with me that he was worried about stepping on the other executive’s toes. When the two of them finally talked, the conversation was awkward, but they got aligned, and the conversations that followed got easier. Marketing shows up in these disputes too, though in my experience those conversations tend to be less heated.

Breno Oliveira, CTO at Strider, described a version of this from early in his leadership career. Not long after stepping into a new role, he felt he had to give feedback about a close teammate’s performance on a project, but he held off. “Delaying the hard conversation was a mistake, it cost a few more weeks of misalignment,” he said. “The actual conversation turned out to be far easier than the versions I planned.”

Part of the reason these interactions seem scary is where these leaders came from. Many built their careers in roles where having the right answer was the job. Paul Farnsworth, president and former CTO of Dice, put it this way: “Technical expertise may help get you into a leadership position, but succeeding in that role depends on fundamentally understanding business priorities and communicating with people who have very different perspectives and objectives.”

Few of my clients were ever trained for that second half. Gallup’s 2026 State of the Global Workplace report notes that few managers have natural management talent and many haven’t received the training they need to coach their teams. The same report found manager engagement fell from 27% to 22% between 2024 and 2025, the largest year-over-year drop Gallup has recorded.

AI won’t fix any of this. It takes over the technical work these leaders were good at and leaves them with the conversations they’ve been avoiding.

What I coach IT leaders to do instead

When a client is dreading a conversation, I start by asking what they want out of it. Why does it matter, and what does a good outcome look like? Technical leaders often go into a conversation wanting to convince the other person of their point of view. They want to give direction or advice. I ask them to set that aside and think about what they need to learn.

Then I have them go through their calendar for the day. For each meeting, they write down one, two or three questions that will move the conversation or the decision forward. Many of my clients now do this daily, the evening before. Some print their calendar. Others work through it on screen, one meeting at a time. The prep shifts from a page of talking points to a handful of questions, and they make more progress in the room because they’re listening instead of trying to convince.

The leaders I interviewed use similar approaches. Farnsworth, the Dice president, said he used to get flustered in difficult one-on-one conversations with the people he managed early in his career, and he learned to write down his key messages beforehand so he could stay focused and communicate more clearly. Joshi, the TransUnion executive, said the best leaders he knows “spend less time giving answers and more time asking questions,” and he advises rising IT leaders to treat coaching as a skill that requires deliberate practice. Jolly, the Xero executive, said she had to start fiercely protecting her calendar to carve out thinking time, and she advises leaders to hire people who can do their jobs without them.

I also remind clients that having hard conversations is a skill, and skills improve with reps. The engineering leader with the token budget didn’t get better at negotiating with his product counterpart by reading about negotiation. He got better by having the conversation, debriefing it with me and having the next one.

The market has already noticed. CIO.com reported earlier this year that companies hiring CIOs in 2026 want a business transformation officer with a technical pedigree and high emotional intelligence, and that relationship skills matter more than ever.

AI isn’t coming for the CIO’s job. It’s coming for the part of the job that used to hide weak people skills behind strong technical delivery. The leaders who will thrive are the ones who treat difficult conversations as core work rather than an interruption and start practicing before the exposure arrives.

A pathologically simple playbook emerged in the last few years for winning the AI race: hoard GPUs, hire every AI expert you can find and then watch the magic happen. But as we roll through the second half of 2026, cracks in that strategy have turned into craters. A harsh reality of frontier AI development is finally setting in: you can’t spend your way to the top.

Building a world-class AI system requires deep institutional structures that drive enterprise-wide adoption. It involves cultivating and investing in a tightly aligned engineering culture. It requires the kind of relationships that attract and, vitally, retain the absolute elite.

The compute mirage and the bending demand curve

AI spending has grown to truly unprecedented levels in the past 18 months. The top five tech giants alone are projected to spend over $750 billion combined in 2026 for AI infrastructure. They followed the playbook by buying the chips, generating the power and building the infrastructure. But they did so operating on a core industry assumption: that the demand for massive, monolithic frontier compute would scale exponentially forever.

While plausible, it’s clear the demand curve is starting to bend.

While companies were stockpiling silicon, the open-source community and Chinese AI labs quietly changed the math. Competitors discovered that you don’t need to spend a billion dollars training a frontier model from scratch when you can use model distillation to train smaller, highly efficient models on the cheap.

How they did it: Chinese labs like DeepSeek, Zhipu, Moonshot and MiniMax have aggressively leveraged distillation and open-source foundations. Despite U.S. export controls severely limiting their compute, Chinese models are aggressively closing the gap with U.S. frontier models on key benchmarks at a fraction of the cost.

They also introduced open-weight models with similar levels of quality at little to no cost at all. In a short period of time, open models have become the de facto standard for startups and enterprises. When a distilled, open-weight model can achieve 90% of a frontier model’s performance on a specialized task, the justification for paying massive API fees to a centralized provider vanishes.

So, what does this mean?

Well, when you spend hundreds of billions expecting a monopoly on intelligence, only to find that competitors can essentially pirate your capabilities for pennies, your entire business model evaporates. Companies like Meta and SpaceXAI are experiencing this shortfall firsthand. SpaceXAI is now renting out spare capacity to Anthropic, and Meta is floating “Meta Compute” to sell off its excess power.

In other words, the infrastructure that was supposed to be a weapon has become an expensive anchor, turning companies into digital landlords for their competitors.

Turmoil tax: Why top talent is walking away

Hype cycles in the early 2020s produced a flood of newly minted graduates wielding advanced degrees in machine learning. But as the industry matured, a painful truth emerged: understanding AI theory is common. However, knowing how to build, stabilize and scale a frontier system from scratch is incredibly rare.

Training a trillion-parameter model is a distributed systems nightmare. You can’t just throw a hundred fresh PhDs at a massive cluster and expect a frontier model to pop out. You need a team of deeply experienced engineers who grok the theory while also understanding catastrophic failure points, hardware-software co-design and network optimization.

And right now, the industry is actively driving that talent away. Across major tech giants and leading AI labs, a brutal pattern has emerged: sweeping layoffs executed specifically to free up capital for massive AI infrastructure bills. Engineers are effectively being sacrificed to buy more compute. This astronomical cash burn is creating chaotic, high-pressure environments where shifting goalposts and constant team resets, have triggered a growing exodus of key staff.

This turmoil creates a vicious cycle. Elite AI engineers, the true “10x” talent that actually knows how to string 100,000 GPUs together without the system crashing, want stability, clear mandates and a culture that values their institutional knowledge. When a company signals that it views human talent as a highly expendable line-item, top talent flees to more stable, culturally aligned labs. It’s impossible to build a generational product when your core engineering team has a revolving door.

The public shift: Privacy, cost and fatigue

A fundamental shift in the public and enterprise appetite for AI compounds this pressure. I’ve seen it first-hand.

Back in 2024, companies were willing to pipe their proprietary data into massive, closed models just to see what would happen. In 2026, the honeymoon is over. The public and corporate sectors are increasingly concerned about data privacy and the staggering costs of operating massive frontier models at scale.

Enterprises are realizing they don’t need a multi-trillion parameter model that “knows everything” to summarize internal legal documents or write code. They want smaller, localized, cheaper models that can guarantee their data privacy. This public shift toward cost-efficiency and privacy heavily favors the open-source and distilled models over the massive, costly API walls built by the biggest spenders.

The takeaway

Big Tech is learning the hard way that scaling an AI lab is like scaling a space program.

The moat in artificial intelligence is institutional rather than financial. You need unglamorous, highly disciplined systems engineers who stick around for years, compounding their knowledge of the company’s specific infrastructure. You need a deeply rooted engineering culture that gives researchers the stability to execute. And you need a business model that aligns with where the market is actually going, rather than where you hope it will be.

Hoarding all the compute in the world only gets you so far if your talent is fleeing. Prospects look even worse if your competitors are distilling your models and your customers are demanding cheaper, localized alternatives. Instead of building on the frontier, you’re left building a very expensive data resort. But it’s not too late.

Meta won’t judge employees by how much they use AI when it comes to annual performance reviews, despite early efforts to drive AI adoption focusing on so-called token maxing.

The company has told employees that it “will not use AI adoption dashboards or token counts to evaluate impact,” according to  a report by The Information.

The announcement came in an internal memo from executives Maher Saba and Santosh Janardhan, which said that instead of measuring AI usage, “managers should look at output quality, velocity, problem complexity and scope taken on.”

This marks a culture change for Meta, where engineers had previously competed to consume the most AI tokens, displaying their scores on a leaderboard. Meta then discovered that its employees were being diverted from regular work because they were using AI to carry out additional tasks to boost their scores.

Amazon had similar results when it implemented a leaderboard to track AI use; it also found that some employees were trying to game the system by using AI to complete unnecessary tasks, and it has now deleted it.

The company, however, does also monitor employees’ use of AI for training purposes, in a program introduced in April, but this is information was not used to measure employee performance.

Meta had already started to look askance at the concept of using AI metrics as a tool to assess employees. Earlier this year, Chief Technology Officer Andrew Bosworth told employees in a memo that “nobody should be using AI tools just for the sake of using them,” adding that “token usage alone is not a measure of impact of any kind.”

This article first appeared on InfoWorld.

Picture the meeting. A slide goes up, a number goes down and somewhere in the room, someone claps.

The line item is a renegotiated managed services contract, a hardware order trimmed to “just enough,” or a headcount freeze that quietly became a headcount decrease. Whatever it is, it looks great in the deck. The CFO nods. The COO nods harder. Everyone agrees this was smart.

Three months later, something breaks — an incident nobody can escalate fast enough, a part that doesn’t arrive in time, a senior engineer who finally takes that recruiter’s call. Nobody connects it back to the slide. The slide was right. The spreadsheet said so.

This is the part where I’d like to gently suggest that a lot of very smart people are managing to the cell instead of managing to the outcome — with total confidence, because the cell is the only thing anyone asked them to optimize.

To be clear, this isn’t a jab at the leaders doing it. I’ve done it. I have a Six Sigma certification and a well-worn habit of measuring things, and measuring things is good — right up until the measurement becomes the mission. The problem was never the spreadsheet. It’s mistaking it for a map.

Outsourcing: The invoice goes down, and so does everything you can’t put a price on

I’ve watched this failure mode play out more times than I can count. Across nearly three decades in infrastructure — as chief technology architect at GE Medical Systems (now GE Healthcare), integrating roughly 300 acquired companies into a 420-location footprint — the pattern held: The moment a relationship with the people who actually knew a system got treated as a line item instead of an asset, the organization lost something the spreadsheet never had a row for.

Vendor and MSP contracts are the cleanest modern example: Savings are easy to show, losses are easy to miss. You cut the line item. What doesn’t show up anywhere is the on-call engineer who used to just know — the environment, the history, the thing that broke in 2019 — replaced by a support queue and an SLA that’s met on paper while your business is down in practice.

None of this is the vendor’s fault — they’re delivering exactly what the contract asked for. CIO.com’s own reporting on the hidden costs of outsourcing makes the same point from the other side: Ineffective knowledge transfer and high vendor-side attrition can permanently erode institutional knowledge the client never gets back. The contract took away flexibility. The person who used to just fix it — the one who wore six hats and closed the gap on a Tuesday afternoon — gets replaced by a role with a scope of work. Scopes of work don’t wear hats. A five-minute favor becomes a change request, routed through a ticketing system, against a rate card. You didn’t just outsource a function. You outsourced your ability to handle it — and bought back a slower, costlier version of the same fix, one billable hour at a time.

JIT procurement: A factory formula applied to a business that isn’t a factory

Just-in-time assumes something that doesn’t exist: A crystal ball good enough to see today’s need and whatever shows up next. I learned that the hard way at GE Medical Systems, when a new customer opening a facility wanted several hundred patient-critical bedside monitors customized to match a color scheme from their marketing department. Our processes were built entirely around clinical function — the thing that keeps a patient alive — and nothing accounted for a hospital wanting its equipment to match its brand. It came in from left field. We had no SKU for “must match burgundy.”

We ended up standing up a new department — Specials — because the existing process had nowhere to put a request like that. Building the flexibility after the fact was expensive. But it became a real differentiator: As far as I know, we became the first and only medical device manufacturer with a dedicated specials department. It told customers something that mattered more than paint color: They came first, and we’d find a way to say yes.

The lesson wasn’t “predict better.” It was “build systems with teeth” — flexibility designed in, not bolted on after reality shows up sideways. Dell and HP figured this out decades ago: You can order a PC built to your exact spec and have it shipped in days, because their systems were engineered for change. Most IT organizations still build for demand they can already see, then treat every surprise as an exception instead of the job itself.

This wasn’t a one-off: Supply chain analysts at SupplyChainBrain noted that during the 2021 chip shortage, many manufacturers found their lean JIT models weren’t built to flex under real disruption. “Just in time” only works until the time arrives and the thing isn’t there.

Headroom is savings, too — paid out in advance instead of on the back end, which is why it never gets credit. Nobody puts “the department we didn’t need to build in a panic” on a savings slide, because avoided cost doesn’t announce itself the way cut cost does. The expense of headroom is visible and immediate; the expense of its absence is invisible until it isn’t. It’s an incident report.

The hour that reads as free

I lived a version of this at GE Medical Systems. We built life-critical patient care products in a market crowded with giants — Philips, Siemens, HP — where nothing shipped until it cleared FDA review. On one release, scope crept weekly because sales kept promising new capability to close deals, and no one above us would draw a line around what “done” meant. What we got instead of a defined scope was a war room: Catering, a fridge stocked with Mountain Dew, enough M&Ms to open a candy counter — everything money could buy to keep engineers at their desks around the clock, except the one thing that would have actually helped: Someone willing to tell sales no.

We hit the deadline. The product cleared FDA review. When it shipped, there was no “great work,” no pat on the back — just the quiet message that this was expected of us. We won on the software. We failed on the people. That’s sunk-cost thinking in its purest form: Once a team’s extraordinary effort becomes the baseline, the extraordinary disappears the same way the ordinary already had.

Salaried time reads the same way on every spreadsheet I’ve seen since: Already paid for, so effectively free. Nothing stops it from being spent — on the meeting that could’ve been an email, on the ticket queue treated as bottomless, on “just have IT handle it” as the default answer. Burnout doesn’t have a line item either, until it shows up as attrition, and attrition finally does, at which point everyone acts surprised. It’s not small: Gallup estimates disengaged employees cost the global economy trillions a year — roughly 9% of global GDP, sitting outside any single department’s budget. The spreadsheet didn’t lie to you. It just never had a cell for the thing that mattered most.

The ledger nobody built

Zoom out from these three stories and the pattern is the same: Reporting structure decides which questions get asked. When technology reports through a CFO or a COO, the question every quarter is “what did this cost us today?” Almost never “what did this cost us to keep?” An organization that only asks the first will keep hiring smart people to answer it well — in exactly the wrong direction, forever.

None of these leaders are bad at arithmetic. Most are excellent at it. The tragedy isn’t the math — it’s the ledger: Precise, defensible calculations against books never built to hold the costs that matter most, and calling it leadership. I’ve seen this enough times to give it a name: The leader who runs a technology organization strictly by the numbers handed to them, gets good at it and never gets fired for it — not because they succeeded, but because the failure never had a cell to live in. The spreadsheet balanced. The building didn’t burn down that quarter. They got promoted.

That’s the actual scandal, worth saying to the room and not just the page: A CIO who has never once been wrong on a savings initiative hasn’t been managing technology. They’ve been managing a spreadsheet, and calling the absence of visible damage “success.”

Before the next savings initiative gets a round of applause, three questions worth asking honestly, out loud, in front of people:

1. What does this cost that will never appear on an invoice — and am I certain, or just unbothered?
2. Who inherits that cost, and will I still be in this seat when the bill comes due?
3. If I can’t put a number on it, have I decided it’s zero — and whose job was it to notice first?

The savings will still show up in the deck. If nothing else shows up beside it, that isn’t restraint — it’s the tell.

The concept of digital transformation (DX) has been around for quite some time now. Many companies are adopting digital technologies such as AI, IoT and the cloud to transform their businesses, operations and organizational cultures, striving to improve productivity and create new value.

However, on the other hand,

• They have introduced IT tools and systems, but their operations haven’t changed
• They keep repeating proof-of-concept (PoC) projects, but these remain at the PoC stage and do not lead to full-scale deployment
• Frontline staff and all employees do not view DX as something that directly concerns them

These are just a few of the many challenges frequently reported.

Why does this happen?

The fundamental cause lies in viewing DX merely as a project to introduce digital technology.

The essence of DX is not the D (digital), but the X (transformation).

And throughout history, it has always been people who carry out that transformation.

No matter how brilliant or well-crafted a strategy may be, or how advanced the AI introduced, without the talent capable of mastering it, executing it and turning it into results, the strategy will remain nothing more than a pipe dream, and DX will not move forward. I believe that in the coming era, one of the most important roles required of a CIO is to develop talent capable of executing DX.

DX talent is not simply ‘people who are knowledgeable about IT’

First, let’s clarify what DX talent actually means.

When we hear DX talent, we tend to imagine highly specialized professionals such as data scientists, digital consultants and AI engineers. Of course, such expertise is important. However, it is not enough on its own to truly drive DX forward.

What is truly important in DX is

• Understanding management and operational challenges
• Considering value from the customer’s perspective
• Utilizing digital technology as a tool
• Driving transformation while engaging others

In other words, DX talent is not merely IT talent.

They are individuals who can apply the equation and apply it to actual business operations, organizational structures and customer experiences.

The Kansai Electric Power Group has also set a goal to transform into an AI-first company by rebuilding operations on the premise that AI exists. However, to achieve this, we need talent who can treat AI not merely as a convenient tool to try out, but as a weapon to master and utilize to the fullest, and who can embed it into the organization’s DNA and operating system.

A DX talent strategy is a business strategy, not merely a training or HR initiative

First and foremost, it is crucial not to confine the DX talent strategy to training initiatives or HR measures.

DX talent development, by its very nature, asks the questions:

• What kind of company do we aim to become?
• What competitive advantages we want to build
• What value do we want to provide to customers and society?

In other words, it is intrinsically linked to the business strategy itself.

For example,

• We want to use AI to dramatically improve operational productivity
• We want to use data-driven approaches to enhance the quality of management decision-making
• We want to enhance the customer experience and improve customer satisfaction and NPS

If so, you must define a DX talent strategy that can make this a reality and strategically advance the development of such talent.

When formulating a DX talent strategy, there is one principle I personally keep in mind. It is to align people and organizations with the strategy through vertical consistency and horizontal coherence.

Akio Ueda, Kansai Electric Power

First, vertical consistency refers to:

1. Management philosophy (mission, vision, values) and business strategy
2. The DX strategy as the means to achieve them
3. The DX talent strategy for developing the people capable of executing them
4. Organizational culture, which significantly influences strategy execution

This consistency refers to ensuring that the approach, interpretation, rules and actions regarding these four major areas are maintained along the same policy and logic from start to finish.

Next, horizontal alignment refers to the alignment of the following elements, which tend to have a particularly strong influence on the DX talent strategy:

• The organization’s hierarchy (vertical) and departments (horizontal), rules, responsibilities and authority, as well as employee communication styles and engagement
• The HR systems, which consist of the cycle of recruitment → placement → development → evaluation → compensation

Horizontal alignment also ensures these elements do not contradict the DX talent strategy and are logically consistent with it.

If there is even the slightest flaw in this vertical consistency and horizontal coherence, the listener will feel a sense of unease — thinking, “something doesn’t quite add up” or “can I really trust this?” — before even considering the content itself.

• Have your policies or arguments drifted off course without you realizing it?
• Are there any contradictions between departments, materials, statements and actions?

Only when both of these elements are in place does an explanation become persuasive, and trust in the organization and its people begins to build. That is precisely why I believe it is crucial, when communicating, to carefully verify the vertical consistency within the flow of policies and arguments, as well as the horizontal coherence among stakeholders, information and actions.

DX won’t move forward just by knowing

There is another pitfall people often fall into when developing DX talent. It is when acquiring knowledge becomes the goal in itself.

For example, someone who:

• Took a DX training course
• Learned how to use AI tools through e-learning
• Attended an external DX seminar

These are certainly necessary. However, they alone will not bring about change in people or organizations.

What matters is not knowing but being able to act. In fact, in many organizations,

• Participants understood the material during training
• Got excited during the seminar
• But nothing changes on the ground

This is because there is a significant barrier between knowledge and action.

As part of its DX and AI strategy, the Kansai Electric Power Group has defined and publicly announced its DX Talent Strategy, which clarifies the ideal talent profile, the number of employees to be developed and the training framework.

Akio Ueda, Kansai Electric Power

• Target participants are classified into three tiers: Advanced DX Talent, DX Promoters and All Employees
• We formulated a DX Talent Strategy that defines skills and mindsets based on the Digital Skills Standard (DSS) established by the IPA. As talent development measures tailored to each talent profile and proficiency level, we will offer a total of 31 training courses in fiscal year 2025
• Through further expansion of training content and other measures, we aim to develop approximately 70 Advanced DX Talents and approximately 5,000 DX Promoters across all departments by the end of fiscal year 2028

A key aspect of implementing this DX talent strategy is

• Measuring and visualizing the number of employees across the entire organization for each talent profile and proficiency level
• I believe that rather than simply stopping at attending training sessions, applying what you learn to your actual work allows you to advance your proficiency through the stages of knowing → being able to do → being able to teach.

That is my belief.

Praise is the best tool you can use right away

At the Kansai Electric Power Group, we’re moving forward while being highly conscious of the alignment between our DX talent strategy and our HR systems — that is, the recruitment → placement → development → evaluation → compensation cycle. Among these, the ideal that people with high DX skills who have achieved results in business and operations receive high financial compensation is something everyone can imagine, but the reality is that there are very high hurdles to overcome when actually trying to implement it.

Even in such circumstances, the most efficient and immediately implementable recommendation is to utilize internal and external recognition programs — in other words, praise.

Akio Ueda, Kansai Electric Power

At Kansai Electric Power, as part of our internal recognition program, we hold an annual DX event called KANDEN Digital Day, attended by approximately 1,100 members of the Kansai Electric Power Group. At this event, we honor individuals who have excelled in DX and achieved results as DX Pioneers, and we also recognize those who have created and utilized outstanding custom GPTs through our Custom GPT Contest.

We also actively apply for external awards in fields such as IT and DX. Recently, we have been selected for as many as eight awards; most recently, we were selected as the first electric power company to be included in the DX Stocks 2026 initiative, jointly organized by the Ministry of Economy, Trade and Industry, the Tokyo Stock Exchange and the Information-technology Promotion Agency (IPA).

When we are selected for awards through such recognition programs, the people implementing those DX initiatives not only receive social recognition for their work and gain the psychological reward of joy, but this also transforms into self-esteem and confidence, becoming a further source of motivation and fulfillment and leading to personal and organizational growth — thus setting a virtuous cycle in motion.

Another major effect of this initiative is the feedback loop from evaluation and rewards to recruitment. When we win an award through an external recognition program, positive word-of-mouth about Kansai Electric Power’s DX efforts spreads online. Students and people working on DX at other companies who see this might think Kansai Electric Power is quite advanced in DX. It seems like they’re doing all sorts of cutting-edge and interesting things, so I’d definitely like to join the company and work on this together! In other words, we aim to create a world where the evaluation and rewards provided by these awards generate positive feedback that leads to recruitment.

Furthermore, in the age of AI, we believe that Kansai Electric Power should not only be chosen by people but also chosen by AI.

• Based on the latest information, please create a ranking of companies in the energy industry that are making progress in DX. Please also provide the rationale for your assessment.
• Based on the latest information, please create a ranking of Kansai-based companies that you would recommend for DX professionals seeking employment. Please also provide the rationale behind your assessment.

I intend to strive for continuous improvement and growth every day so that, when these prompts are entered into generative AI, Kansai Electric Power will remain the kind of company that receives the response: Kansai Electric Power is number one.

A CIO is the leader responsible for developing talent for strategic execution and organizational transformation

As discussed so far, developing DX talent is not merely a matter of conducting training and education. It is interconnected with the company’s management philosophy, strategy, business operations and organizational culture.

That is precisely why CIOs are expected to serve not as leaders responsible for technology adoption, but as leaders responsible for talent development to execute strategy and drive organizational transformation. Especially in the age of AI, I strongly believe that a company’s future competitiveness will hinge on how many people it can cultivate — not merely people who can use AI, but people who can collaborate with AI to execute strategy and create value and people who can drive organizational transformation to make that a reality.

Talent development is the greatest investment in DX

In the world of DX, it’s easy to get caught up in the latest technologies and new tools. However, ultimately, it is people who drive change in companies — in every era.

• Identifying challenges
• Consider customer value
• Master the use of AI
• Engage those around you
• Execute the transformation

Only when the number of such talented individuals increases will DX truly take root in an organization.

Developing talent capable of executing DX is not merely about teaching skills. It is, in essence, the very act of building an organization that can continue to evolve.

In this age of AI, the value of people is actually increasing. Isn’t it true that CIOs are expected not only to master technology but also to believe in, nurture and unleash human potential?

Much of the conversation around AI and work has centered on a single question: Will AI take my job?

It’s an understandable concern. Every week AI becomes increasingly more capable. We see AI summarizing meetings, generating content, analyzing data, writing software and automating workflows that once required significant human effort. Agentic AI is also becoming more established in the workplace, with virtual agents that can reason, plan and act across workflows. As those capabilities continue to improve, many employees are looking at the tasks they perform every day and wondering how much longer they will belong to them.

I believe that question reveals a bigger issue that has little to do with the technology itself.

Too many people have become defined by the tasks they perform rather than the value they create. Over time, the administrative work surrounding a role can overshadow the purpose behind it. According to Asana’s Anatomy of Work Index, knowledge workers spend 60% of their time on “work about work” — coordinating, tracking and managing tasks rather than driving meaningful outcomes. As AI automates more of this work, it can feel less like a productivity breakthrough and more like a threat because many employees equate their value with the activities that consume most of their day.

But most people were not hired to perform a task. They were hired to fulfill a purpose.

Tasks are not the job

A customer service representative isn’t successful because they spend their day summarizing conversations, looking up account information or navigating multiple systems to find answers. Those activities may have become part of the job, but they aren’t the reason the role exists. Great service professionals build trust, solve problems and create moments that strengthen customer relationships. AI can, and should, take on this administrative work, but the human value has never been in completing those tasks. It has always been in helping customers through moments that matter.

The industry increasingly recognizes this distinction. In fact, 91% of CX leaders believe human agents will remain a critical part of delivering customer experience, according to my company’s State of Customer Experience 2026 report. As AI takes on more routine work, the role of the employee doesn’t disappear. It becomes even more focused on the judgment, empathy and relationship-building that customers value most.

The same principle applies across every profession. A marketer isn’t measured by the number of presentations they build or approvals they coordinate; they’re hired to shape customer perception and drive growth; an HR professional isn’t successful because they schedule interviews or process paperwork; they’re there to identify, develop and retain talent. The examples go on, but the principle remains the same: Organizations create roles because outcomes need to be achieved, not because tasks need to be completed.

I’ve helped lead four major AI transformations, spanning everything from machine learning and big data to conversational AI, generative AI and now agentic AI. While the technology has evolved dramatically, one pattern has remained remarkably consistent.

The employees who embrace AI tend to focus on outcomes, while those who fear it often focus on tasks. The more someone defines their contribution through a list of activities, the easier it becomes to imagine AI replacing them. The more someone understands the purpose they serve, the easier it becomes to see AI as a tool that helps them deliver greater value.

As part of AI transformations, CIO organizations are often responsible for mapping jobs and core workflows. Inevitably, employees think we’re mapping their jobs to figure out what AI can replace. But once we start identifying repetitive work they’d gladly hand off, perspectives change. Someone says, “If AI handled that, I’d finally have time to work directly with customers.” Another realizes they could spend more time creating. People start thinking less about what AI might replace and more about what they’d finally have time to do. They’re reconnecting with the reason they wanted the role in the first place.

I’ve seen this play out as AI adoption expands. Our team responsible for responding to customer RFPs began using AI to analyze requirements, surface relevant information and accelerate response development. Their purpose is to help the organization communicate our value to customers and win new business. By reducing the time spent on low-value activities, AI created more capacity for strategic thinking, collaboration and customer-focused work, which directly influences the revenue and growth of our company.

I’ve even had to confront this myself. I used to spend hours coaching leaders before operational reviews: reviewing KPIs, challenging assumptions and helping them prepare for difficult questions. I used to think this was part of what made me valuable as a CIO, but I realized that I didn’t need to spend my time repeating the same coaching session. That’s why I built a virtual coach that helps my team prepare for operational reviews using many of the frameworks and lessons I’ve accumulated throughout my career. Now I have more time to spend strategizing on how to lead through the breakneck speed of AI evolution and helping the business think differently.

Rediscovering purpose

What employees are really confronting is a different question: What was my purpose in being hired in the first place?

As organizations move from AI experimentation to AI-first operating models, this question becomes harder to avoid. The tension is already visible across the workforce. A recent EY survey found that 84% of employees are eager to embrace agentic AI because they expect it to improve productivity, efficiency and the overall work experience. Yet 56% also worry about their job security working alongside AI systems. Employees aren’t rejecting AI; they’re trying to understand which parts of their contributions remain uniquely theirs as technology takes on more of the tasks they perform today.

Success will depend greatly on helping employees reconnect with the value they were hired to create. For leaders looking for practical guidance on how organizations are actually approaching AI-first transformation, the World Economic Forum’s AI-First Operating System offers a useful framework. Rather than treating AI as another technological tool, this approach encourages organizations to redesign work around value creation. As AI increasingly takes on routine tasks, employees must become clearer about where human judgment, creativity and relationships can create the greatest impact. You cannot redesign work around value if people no longer understand the purpose behind the work that they do.

In my experience, the organizations seeing the strongest results are helping employees reconnect with the outcomes they were hired to create. The conversation shifts from “What tasks can AI do?” to “What is the purpose of this role?” Once people answer that question, it becomes much easier to decide what should remain human, what can be delegated to AI and where the combination creates the most value.

None of this means change won’t happen. Some responsibilities will disappear. Some jobs will evolve significantly. New roles will emerge that we cannot fully predict today. Every major technology shift creates that kind of change.

But I believe many people are looking at this transformation through the wrong lens.

The question is not whether AI can do your tasks. The question is whether you understand the purpose behind them. Because while AI may increasingly perform the work, humans will continue to provide the judgment, creativity, accountability and value that give that work meaning.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?