Over the last year, I’ve had more conversations about AI strategy than I can count. Some are exciting. Some are thoughtful. Some are deeply pragmatic.
But, underneath almost every conversation is something we don’t talk about enough: People are trying to figure out what this transformation means for them.
Not just for the company. Not just for productivity metrics. Not just for quarterly planning.
For their careers. Their identity. Their value. Their teams.
In my 20+ years in the software industry, I’ve led engineering teams through major industry changes, platform rebuilds, hypergrowth phases, and everything in between. I think engineering leaders in particular are underestimating how emotional this moment is.
Below, I share what I’ve observed first-hand in my role as CTO of Scripta Insights, and from talking to my peers in the industry.
AI transformation is not just a technology shift
We often talk about AI adoption like previous platform transitions:
- Cloud Migration
- Mobile-first Transformation
- Big Data
- Dev(Sec)Ops
- SaaS
But this feels different for many people because AI directly touches the thing knowledge workers have historically tied to their professional identity: their ability to think, create, solve problems, and produce value. When a new infrastructure platform appears, engineers learn new tooling.
When AI appears, people quietly ask themselves:
- “Will my role still matter?”
- “Am I falling behind?”
- “What happens if younger engineers adapt faster than I do?”
- “Will leadership use this to help us or replace us?”
- “Do I still have a future here?”
Most people won’t say those questions out loud. But, they’re there.
And organizations ignoring that reality are going to struggle far more than they expect.
Fear and excitement are happening at the same time
One of the interesting things about this moment is that teams are often experiencing contradictory emotions simultaneously.
People are burned out and energized.
Excited and terrified.
Inspired and skeptical.
A lot of 1-1s with both teammates and external peers reflect this. I think we’re both pulled in by the possibility of AI in our lives, but scared about what it means to us, our livelihood, and this profession we’ve all been part of. The question I most often hear is “What will this mean for me, specifically, and my job?”
And, as we discover that together, I’ve seen engineers become dramatically more productive using AI tooling while also privately worrying they’re automating away the parts of the job they enjoyed most.
I’ve also witnessed leaders push teams aggressively toward adoption while simultaneously struggling to understand where AI genuinely creates value versus where it creates operational risk.
And, I’ve watched organizations accidentally create anxiety by framing AI adoption entirely around efficiency instead of empowerment. That framing matters more than leaders realize.
If employees hear:
“AI will help remove repetitive work so teams can focus on higher-value problems.”
They respond very differently than if they hear:
“We expect AI-driven productivity gains across the organization.”
Those may sound similar in a boardroom. They do not feel similar to the people doing the work.
Trust becomes the critical organizational currency
The companies that navigate this transition successfully will not necessarily be the ones with the biggest AI budgets. They’ll be the organizations that maintain trust during rapid change. Trust that:
- leadership is being honest,
- experimentation is safe,
- employees can adapt,
- learning is valued,
- mistakes made while evolving won’t be punished,
- and AI is being adopted with teams, not forced on them.
That last distinction is incredibly important.
When organizations treat AI as a top-down mandate, adoption often becomes performative. Teams demo prototypes nobody uses. Leaders celebrate pilot programs disconnected from operational reality. Employees quietly disengage while pretending enthusiasm.
Instead of transformation, that’s organizational theater. Real transformation requires participation, iteration, and psychological safety.
Burnout doesn’t disappear when productivity increases
This is another dynamic I think leaders are underestimating. There’s an assumption that AI tooling automatically reduces burnout because it increases efficiency.
Sometimes it does.
But often, organizations simply raise expectations to consume the newly created capacity. Teams already struggling with delivery pressure now feel pressure to:
- learn new tooling
- redesign workflows
- experiment constantly
- maintain existing systems
- and somehow move even faster.
At the same time, the pace of change itself becomes exhausting. People are trying to absorb new models, frameworks, workflows, organizational expectations, and existential career questions all at once.
That cognitive load is real. Leaders who ignore it risk creating organizations that are technically accelerated but emotionally depleted.
Organizational identity is changing, too
One thing I find fascinating is how AI is forcing companies to rethink what kind of organizations they actually are. For years, many technical organizations defined themselves around engineering velocity, technical specialization, operational scale, and domain expertise.
Now the conversation is shifting toward adaptability, learning velocity, systems thinking, human judgment, and organizational resilience.
The best engineers are no longer simply the people who can produce the most code manually. Increasingly, they’re the people who ask the best questions, validate outcomes effectively, design reliable systems, navigate ambiguity, and combine technical depth with strategic judgment.
That’s a meaningful cultural shift, and it requires leadership teams to rethink how they hire, mentor, evaluate performance, and define growth.
The future belongs to organizations that can adapt together
I don’t think AI replaces the need for strong engineering organizations. I think it increases it.
Because as tooling becomes more powerful, the differentiator becomes less about access to technology and more about whether organizations can evolve without losing trust, culture, or clarity of purpose.
In the AI era, my early experience shows that the teams who survive will likely be the ones that:
Embrace experimentation without abandoning rigor
Engineering is still about learning and growing, without abandoning product quality and the things that make our work most viable. We should embrace AI, with a scientific perspective that tests and measures the impacts it has on us, both positive and negative.
Invest in people alongside tooling
I still try to focus on career development in addition to expanding my AI budget. I want humans to still drive these outcomes, and don’t want to neglect the people still responsible for fundamentally writing prompts and making decisions on their efficacy. We still need to grow talent in the profession and build stronger engineering acumen.
Communicate honestly about change
At Scripta, I’ve focused on making these decisions with my team. We pilot AI tools together and talk about the benefits and weaknesses of a strategy. People can weigh in and have a decision as to how we build this strategy together. AI mandates from on high just disillusion folks. It takes a little more effort to get people comfortable with the transition, but the rewards are that the team is bought in and willing to invest in the strategy alongside you.
Recognize that transformation is as much a human challenge as a technical one.
I think this is the biggest takeaway I have after embarking on this AI journey. We need to cut past the hype of what’s eventually possible and stick with where we are today. This is a period of uncertainty and flux for a lot of employees. I try to account for that in every decision around automation I make, because the human dynamics here are just as important as the ROI from AI.
Technology changes quickly. Human adaptation does not. Engineering leadership in the AI age increasingly means managing both.
The post The human side of AI: A CTO’s take on fear, trust, and identity in the AI age appeared first on LogRocket Blog.
This post first appeared on Read More