Pressure is a Privilege: Leading Engineering Teams Through the AI Revolution

"Pressure is a privilege" - Billie Jean King

I've been thinking about this quote a lot lately. Not because I read it in a leadership book, but because it surfaces in the back of my head as I take part in every standup, every refinement session, every conversation about what we're building next.

The ground is shifting beneath us. Weekly. Sometimes daily.

And here's what I've learned after leading teams through three years of the AI revolution at Fenergo: this pressure isn't something to manage away - it's the most valuable thing we have.

The Day Everything Changed (Again)

I remember the exact moment in early 2023 when one of our senior engineers put forward a What Did Not Go Well card in our team's retrospective with the title: 'My work is doomed to be obsolete even before release.' He had just built an SQL authoring tool, and he made the argument that ChatGPT could build better SQL with just a short prompt.

This wasn't the first time I'd heard this. I've been in engineering for over 20 years - from military aircraft systems to banking compliance platforms. I've seen Y2K, the cloud migration, the mobile revolution, microservices, DevOps transformations.

But AI is different.

The pace isn't measured in years or even quarters anymore. It's measured in weeks. The skills that made someone valuable six months ago? They might be table stakes now. The architecture decisions we made with confidence? They're being questioned by foundation models we didn't even know existed when we made them.

For the first time in my career, I've watched engineers with 15 years of experience feel like they're starting over.

And you know what? That's the privilege.

What "Pressure is a Privilege" Really Means

When Billie Jean King said "pressure is a privilege," she wasn't talking about enjoying stress. She was talking about the opportunity to compete at the highest level - to be in a position where what you do actually matters.

For engineering leaders today, the AI revolution is exactly that moment.

We're not under pressure because we're failing. We're under pressure because:

• What we build directly shapes how humans and AI will collaborate in the future
• Our decisions define whether AI empowers or replaces human expertise
• The systems we architect today become the foundations for industries we can't even imagine yet

Think about that. How many times in a career do you get to work on something genuinely transformative? Not incrementally better. Not evolutionary. Transformative.

At Fenergo, we're not just adding AI features to compliance software. We're fundamentally reimagining how financial crime fighters interact with their systems. From doing the work to orchestrating intelligent agents that do the work.

That's not pressure. That's privilege.

The Three Shifts That Define AI-Era Leadership

Leading teams through this revolution has taught me that success requires three fundamental shifts in how we think about engineering leadership:

1. From Knowledge Keeper to Learning Architect

I used to pride myself on having the answers. Deep technical knowledge was currency. Authority came from expertise.

Not anymore.

Today, the engineers who thrive aren't the ones who know the most - they're the ones who learn the fastest.

When we started building our AI ecosystem and our Agent Operating System, I didn't have all the answers. None of us did. AWS Bedrock was new. Multi-agent architectures were emerging. Agentic AI patterns were being invented in real-time.

My job wasn't to know everything. It was to create an environment where my team could:

• Experiment safely - We set up dedicated innovation time and hackathons (like the Athens 3-day session that birthed Kyra)
• Share relentlessly - Every discovery, every failure, every insight got documented and distributed
• Question everything - Including my own decisions about architecture and approach

The result? We went from zero to a production multi-agent platform in less than 18 months. Not because I was the smartest person in the room. Because we built teams of rapid learners.

2. From Stability to Intelligent Instability

Traditional engineering leadership says: minimize change, reduce uncertainty, create predictable delivery.

AI-era leadership says: embrace strategic instability.

Look at our agent architecture. We're running:

• Anthropic Claude for complex document processing
• Amazon Nova Pro for real-time screening decisions
• Llama for cost-optimized binary decisions and the list goes on.

Why multiple models? Because we learned that optimization means flexibility, not standardization.

Six months ago, some of these models didn't exist. Six months from now, we might be using completely different ones. And that's not a bug - it's a feature.

The teams that succeed aren't the ones desperately clinging to their chosen tech stack. They're the ones that built for change from the beginning - using abstraction layers like AWS Bedrock that let us swap models without rewriting systems.

This requires a different kind of leadership:

• Clear principles, flexible implementations - We're rigid about our AI governance framework, flexible about which models we use
• Architecture for obsolescence - Build assuming everything will be replaced, not that it'll last forever
• Celebrate pivots - When we changed our approach to agent orchestration mid-flight, we didn't call it failure. We called it learning.

3. From Team Builder to Culture Engineer

Here's the uncomfortable truth: some engineers won't make the leap.

Not because they're not talented. Not because they're lazy. But because the psychological shift required is enormous.

Going from "I'm an expert in React" to "I'm an expert at figuring out what I need to learn next" is terrifying. It means trading the security of mastery for the vulnerability of perpetual learning.

As leaders, we can't force this shift. But we can engineer a culture that makes it feel like opportunity rather than threat.

At Fenergo, we've done this through:

Psychological Safety at Scale

• Our innovation culture explicitly protects "failure" as learning
• We showcase POCs that didn't work alongside ones that did
• Team members present "what I learned this month" sessions where admitting "I don't know" is celebrated

Mentorship That Goes Both Ways

• Senior engineers learn AI from junior engineers who came in with more modern backgrounds and ideas
• Junior engineers learn system design from seniors who built our platform
• I learn from everyone - and I'm explicit about it

Recognition That Transcends Delivery

• We celebrate learning velocity as much as shipping velocity
• Recognition for asking the best questions that challenged our assumptions
• Public acknowledgment of people who helped others learn

The result? Exceptional retention on my teams over the past three years. Not because we pay more than competitors. Because engineers feel like they're growing faster than anywhere else they could be.

The Real Cost of Not Embracing the Pressure

Let me be direct: if you're an engineering leader trying to "shield" your team from AI disruption, you're doing them a disservice.

I've seen well-meaning leaders say:

• "Let's wait until things stabilize before we invest in AI"
• "We'll let others figure it out first"
• "Our team has enough on their plate"

Know what happens to those teams?

They become irrelevant. Not gradually. Suddenly.

Because while you're waiting for stability, your competitors are:

• Shipping AI-powered features your clients will expect as baseline
• Attracting the best talent who want to work on cutting-edge problems
• Building institutional knowledge about what works and what doesn't

The stable ground you're trying to protect? It's already gone. You're just pretending it's still there.

At Fenergo, we made a different choice. We ran toward the uncertainty. We:

• Deployed our first AI features in production while the technology was still emerging
• Let clients opt into beta capabilities knowing they weren't perfect yet
• Built our compliance framework and governance model in parallel with building features

Was it comfortable? No.
Was it risky? Yes.
Was it worth it? Absolutely.

Today, we're not catching up to AI. We're defining what AI-powered compliance looks like. We're the ones others are trying to copy.

Practical Strategies for Leading Through Constant Change

Theory is nice. Tactics matter more. Here's what actually works:

Create "Innovation Containers"

Don't let innovation be chaos. Structure it.

We run:

• Quarterly hackathons - 2-3 days, clear themes, demo at the end
• 20% exploration time - Not just Google's policy, our reality
• POC pipelines - Clear criteria for what moves from experiment to production

This gives engineers permission to explore while maintaining delivery accountability.

Build a "Learning Stack" Alongside Your Tech Stack

We invested in:

• Shared knowledge bases - Every AI experiment documented with outcomes
• Regular "What We Learned" sessions - Monthly, team-wide, celebrated failures included
• External expertise - AWS partnerships, academic collaborations, conference attendance budget

Make learning infrastructure as real as your production infrastructure.

Transparent Decision-Making on Tech Choices

When we chose AWS Bedrock over building our own LLM infrastructure, I didn't just announce it. I:

• Shared the evaluation framework
• Explained the trade-offs
• Invited challenge and debate
• Documented the decision for future reference

Engineers respect leaders who think out loud, not leaders who pretend to have certainty.

Metrics That Matter for AI-Era Teams

We track:

• Learning velocity - How fast teams adopt new capabilities (not just ship features)
• Experiment volume - Number of POCs attempted (not just succeeded)
• Knowledge sharing - Documentation contributed, sessions led, peers helped
• Retention - Are our best people staying and growing?

What you measure signals what you value. Measure learning.

Personal Vulnerability as Leadership Strategy

I regularly tell my teams:

• "I don't know how to solve this yet"
• "I was wrong about that approach"
• "You know more about this than I do"

Not as weakness. As model behavior. If I can admit not knowing, they can too. And that's where real learning begins.

The Human Side: When Engineers Struggle

Not everyone thrives in constant change. Some engineers are genuinely overwhelmed.

I've had conversations like: "I spent 10 years becoming an expert in this domain. Now it feels like none of that matters."

Here's what I've learned to say:

Your expertise matters MORE, not less.

AI doesn't replace domain knowledge - it amplifies it. The engineers who understand compliance deeply are the ones who can:

• Ask the right questions of AI systems
• Evaluate if AI outputs are correct
• Design prompts and agents that actually solve real problems

But - and this is crucial - you do need to learn the new tools.

It's like when we moved from waterfall to agile. Your programming skills didn't become obsolete. But refusing to learn agile methodologies would have made you obsolete.

For engineers who struggle, we offer:

• Paired learning - Work alongside someone further along the AI curve
• Focused education time - Dedicated hours for courses, experimentation, learning
• Low-stakes projects - Start with AI features on less critical systems
• Honest conversations - Sometimes the answer is: this might not be the right fit anymore, and that's okay

We've had a couple engineers choose to move to teams doing less cutting-edge work. And that's fine. Not everyone wants to live on the bleeding edge.

But for those who stay? The growth is exponential.

Looking Ahead: The Next Wave

Here's what keeps me up at night (in a good way):

We're still in the early innings.

Everything we've built - Kyra, our Agent OS, the multi-model architecture - will look primitive in 18 months. The foundation models we use today will be obsolete. The patterns we think are best practices will be laughably naive.

And I can't wait.

Because that means:

• More problems to solve
• More opportunities to build something transformative
• More chances to prove that humans plus AI is better than either alone
• More learning for my teams

The pressure isn't going away. If anything, it's accelerating.

Good.

Because pressure is a privilege. And I'm privileged to lead teams through this revolution.

To My Fellow Engineering Leaders

If you're feeling the weight of constant change, here's what I want you to know:

You're not supposed to have all the answers.

Your job isn't to be the expert anymore. It's to be the person who:

• Creates the environment where expertise can emerge
• Builds teams that run toward uncertainty rather than away from it
• Makes learning feel like opportunity rather than obligation
• Shows that vulnerability and leadership aren't opposites

The teams that thrive through the AI revolution won't be the ones with the smartest individual leader. They'll be the ones with the fastest collective learning velocity.

One Final Thought

In 2023, I stood in front of my leadership team and said: "Everything we're comfortable with is about to change. We can resist it and become obsolete, or embrace it and define the future."

Some thought I was being dramatic. Drama was born in Greece after all - maybe it's just me staying true to my roots.

They don't anymore.

Because we've watched AI go from experimental features to the core of our entire platform. We've seen clients transform how they work. We've experienced our teams go from uncertain to confident to pushing boundaries I didn't even know existed.

The pressure was real. The privilege was greater.

So if you're an engineering leader feeling overwhelmed by AI's pace of change, I'll leave you with this:

You're not falling behind. You're in the arena. And being in the arena - that's the privilege.

Now go build something that matters.

Warm regards,
Evangelos Liatsas
Director of Engineering
Fenergo Ltd