There’s a moment we all experience at some point in our careers — sitting in a meeting or stepping onto a stage or into a boardroom — when we pause and wonder, “Should I speak up?” or worse, “Do I belong here?”

Let’s set the record straight: you are in the room for a reason.

Whether you earned your seat through expertise, grit, collaboration, curiosity, or leadership — or all of the above — you’re not there by accident. You bring something that others can’t: your perspective, your story, your lived experience.

And here’s the kicker: it’s not enough to simply be present. Presence without participation is a missed opportunity — not just for you, but for everyone else in the room.

Trust Yourself

Too often, people stay quiet because they second-guess their instincts. But most of the time, your gut is rooted in your knowledge, your preparation, and your unique vantage point. Trust it. Confidence doesn’t mean having all the answers; it means believing that your questions, observations, or input are worth voicing.

Speak with Purpose

You don’t need to dominate the room to make an impact. A well-timed insight, a thoughtful question, or even a moment of active listening can shift a conversation. When you contribute, aim to add value — not just airtime. Think: How can I help this team move forward? What friction point can I clarify? What idea can I build on?

Silence Can Be Expensive

Holding back can cost you influence, relationships, and even opportunities. It can signal disengagement or self-doubt, even when you’re thinking deeply and strategically. Don’t let fear of imperfection rob you of your voice. Progress over perfection. Impact over ego.

You Belong — and Others Need You to Show Up

By being in that room, you already passed the test. Now you’re part of the decision-making, the shaping, the building. When you participate with authenticity and courage, you don’t just elevate your career — you make the entire room better.

So the next time you hesitate, remember this:

You’re in the room for a reason.

Because rooms don’t need echoes. They need voices. Let yours be heard.

In the discourse around artificial intelligence, one phrase dominates criticism: AI hallucination — when models generate output that is plausible-sounding but factually incorrect. These errors are framed as the Achilles’ heel of AI systems, especially in high-stakes environments like law, medicine, and finance.

But while AI models hallucinating is a real issue, it is not the most dangerous one.

The bigger problem? Tech influencers hallucinating about what AI can actually do.

When Imagination Outpaces Engineering

In a rush to stay relevant and ride the hype wave, too many tech pundits, influencers, and even respected leaders in the space are promoting exaggerated — sometimes outright fictional — capabilities of AI systems. Claims like:

• “This AI will replace 90% of coders in 5 years.”
• “You can build a billion-dollar startup with just prompts and ChatGPT.”
• “AI already understands your feelings better than your therapist.”

These are not just optimistic projections — they are hallucinations in their own right.

Why This Is More Dangerous

1. Misplaced Trust
   When influencers inflate AI capabilities, non-experts overestimate what these systems can reliably do. This leads to dangerous applications, over-reliance in critical processes, and blind trust where skepticism is due.
2. Policy Panic
   Exaggerated narratives fuel government fears, prompting knee-jerk regulations or bans based on science fiction, not science. This hinders responsible innovation while ignoring the real harms: data misuse, labor exploitation, and surveillance creep.
3. Startup Bubble Thinking
   Founders chase AI silver bullets instead of solving real problems. Investments go into flashy demos rather than long-term viability. The result? Burnout, disillusionment, and another dot-com-bubble-like burst.
4. Ethics Theater
   With the spotlight on far-off existential risks (e.g., “AI might kill us all”), we lose focus on tangible issues today — such as bias in training data, environmental cost of compute, and AI-generated misinformation.

What Can Be Done?

• Ground Expectations
  Influencers need to take responsibility for the narratives they shape. Not everything needs to be a revolution — sometimes incremental progress is the real headline.
• Show, Don’t Just Say
  Claims should be backed with demos, datasets, reproducible benchmarks, and peer-reviewed validations. If it sounds magical but lacks evidence, it’s likely marketing, not machine learning.
• Prioritize Realism Over Virality
  Responsible thought leadership means helping the public understand how AI works and what it can’t do yet. That’s not boring — that’s sustainable trust-building.

Final Thought

AI models may hallucinate text, code, or citations. But it’s the human hallucinations — the overpromises, the hype, the seductive sci-fi visions — that may do the most lasting damage. The real alignment problem might not be between humans and machines, but between influencers and reality.

Let’s stop dreaming for AI and start understanding it — so we can shape a future that’s powerful and practical.

Day 2 of apidays NYC was all about FINOS for me. I spent the entire day in Room Emery (except for a few quick bathroom breaks), immersed in a full lineup of talks and demos centered on APIs, open source, and finance tech.

We kicked off with Olivier Poupeney, FINOS Field CTO, setting the tone for the day. He promised a packed schedule covering cloud, AI, fake trading apps, communication buses, and more — and he delivered. The speaker lineup was stellar, featuring Nicholas Kolba, Daniel Paes, Tom Healey, Daniel Schwartz, Diego Mastroianni, Xiao-Yang Liu (Yanglet), Leigh Capili, Mia Gougisha, Rob Moffat, Luca Borella, and many more.

We started by exploring the real legend — Legend — presented by Daniel Paes. Alongside it, he introduced the FINOS Common Domain Model (CDM) through an IFRS17 insurance regulation compliance use case. But we needed more CDM — and Tom Healey delivered. He expanded on how CDM intersects with Web3, DLT, and blockchain. (Who had that on their bingo card?)

Daniel Schwartz followed with practical insights on integrating CDM into your API calls — a perfect fit for apidays.

Then came the best session of the day — mine! I presented TraderX, the open source, cloud-native, but entirely fake trading app. I dove into the why’s, how’s, whatnots, and explored its extensibility, flexibility, and — of course — APIs. I had to skip some great talks on FDC3, AI Governance, and Cloud Control to answer all the amazing questions folks had about TraderX at the FINOS booth.

The day continued with Diego Mastroianni’s session on transforming with GenAI. He opened with a powerful question: “Is there anyone here who hasn’t used GenAI yet?” He teased an upcoming FINOS GenAI Orchestration platform — name TBD at a future conference.

My final session of the day was Xiao-Yang Liu’s incredibly technical and detailed walkthrough of AI in finance — from A2A to MCP, from FinGPT to “relearning.” I was so impressed I invited him to share more at an upcoming Zenith call!

This week I had the pleasure of participating in the apidays NYC conference, and what a first day it had (besides it raining…)!

I spent a good portion of my time at the FINOS booth, connecting with attendees, answering questions, and sharing insights about open source in finance. I also enjoyed a lively booth crawl, exploring the vibrant community of API enthusiasts and innovators.

The day kicked off with opening remarks from apidays CTO Baptiste Parravicini , who reflected on the French roots of the conference and emphasized the importance of engaging with your fellow attendees. He also highlighted apidays’ active efforts to close the gender gap, promote federated events (like Openfinity, AuthCon, Green IO, and more), and expand globally—now spanning 14 locations with 80+ events, 100+ sponsors, 100,000+ attendees, 60,000+ companies, 3,000+ speakers, and over 300,000 community members. A memorable moment: “At apidays, the only place you are allowed to use SOAP is in the RESTrooms.”

Next up was Gartner’s Mark O’Neill , who delivered a keynote on the surprising resurgence of XML—pointing out that modern AIs, including GPT-4.1, tend to handle XML more effectively than JSON. (Highly recommend checking out the GPT-4.1 prompting guide: https://cookbook.openai.com/examples/gpt4-1_prompting_guide.) Mark also introduced the new “Beyoncé Rule”: if you like it, you should put an MCP server around it.

One of the most nostalgic moments was seeing Kin Lane, one of the original apidays presenters, who came equipped with the same binder he used 13 years ago! He took us through the evolution of APIs from Salesforce’s early XML APIs to today, where 83% of internet traffic is API-based. His takeaway: while we say “design-first,” for enterprise-scale governance, it’s often more “code-first.”

I then attended Ryan Day ’s talk on building machine learning APIs using FastAPI and ONNX, and got a glimpse into his new book: https://a.co/d/a2f8rx3. Definitely worth a read for anyone working on ML integrations.

A highlight of the day came from X’s API team, with Evan Dolgow and Christopher S.J. Park showcasing astonishing usage metrics—trillions of API calls and impressions that truly highlight the scale of their platform.

I also caught an insightful session on democratizing open banking titled Stop Calling Community Banks the Long Tail, which ties directly into TraderX and BankerX—topics I’ll be covering during my talk on Day 2.

To close out the day, I joined the Capital One session on API Drift Detection and Data Protection. It sparked ideas on improving versioning and governance across API lifecycles.

TBC with the second day summary.

When customers leave, it’s tempting to point fingers—usually toward the Customer / Member Success team. After all, their title suggests they’re responsible for the “success” of the customer relationship. But this mindset oversimplifies a complex reality and risks undermining the real levers of retention. The truth is: customer churn is not a Customer Success problem—it’s a company problem.

The Myth of the Siloed CS Team

Customer Success often gets treated like a damage control department. When churn metrics rise, companies look to CS to plug the leak, offer discounts, or chase down feedback. This reactive approach assumes churn is caused by poor communication or lack of support—but in reality, churn often stems from issues that originate upstream:

• A misaligned product that doesn’t solve the real customer pain point.
• Overpromising during sales that leads to unmet expectations.
• A confusing onboarding experience owned by multiple departments.
• Lack of continuous value delivery due to stalled innovation.

Blaming CS for churn is like blaming the flight attendant for a plane crash—they may be customer-facing, but they’re not flying the plane.

Churn as a Lagging Indicator

Churn is the final stage in a series of unaddressed problems. By the time a customer churns, they’ve likely:

• Been frustrated by unmet needs or buggy features.
• Felt ignored during critical phases of adoption.
• Tried to self-serve their way through opaque documentation.
• Lost trust in the brand due to inconsistent experiences.

This journey involves product teams, engineering, marketing, sales, and executive strategy—not just Customer Success. Retention is holistic; it reflects the entire lifecycle of a customer’s experience.

Cross-Functional Ownership Is the Answer

To reduce churn meaningfully, organizations must stop treating CS as a lone department and start embracing company-wide accountability. That includes:

• Product teams building with empathy and user feedback in mind.
• Sales teams setting accurate expectations.
• Marketing targeting the right audience, not just the largest.
• Executives aligning incentives around long-term value, not just quarterly revenue.

Customer Success can be the voice of the customer—but without buy-in from the rest of the organization, they’re shouting into the wind.

Make Churn Prevention a Strategic Priority

Fixing churn requires more than playbooks and QBRs. It demands a shift in culture where every team is measured not just on acquisition, but on retention. Start by:

• Including churn metrics in cross-team KPIs.
• Mapping the full customer journey and identifying friction points.
• Creating closed feedback loops between CS, product, and engineering.
• Empowering CS with authority, not just responsibility.

Final Thought

If your company is losing customers, don’t just look at the Customer Success team. Look in the mirror. Churn is a company-wide reflection of how consistently you deliver on your promises. Solving it requires unified action, shared goals, and a collective commitment to putting the customer at the center—not just at the end of the funnel.

May is packed, and I’m thrilled to be part of some incredible events across open source, AI, quantum, and the future of developer platforms. If you’re around any of these, let’s connect!

May 15 – Catch me at apidays.global, where I’ll be diving into TraderX, the open-source project redefining financial data transparency and interoperability.

May 19 – Join me in New York City for the Microsoft Build 2025 Watch Party, a day filled with product launches, developer energy, and community vibes. If you’re building on .NET, Azure, or just want to geek out about copilots, this one’s for you.

May 28 – A double feature:

• At the Global Morgan Stanley Technology Expo, I’ll be presenting on Quantum Technologies in Finance—think Qubits, QKD, and portfolio simulations beyond classical limits.
• Later that day, I’m speaking at our Tech Talk Series on GenAI in Extended Reality—where AI agents meet spatial computing.

May 30 – Wrapping the month at Morgan Stanley’s internal Microsoft Conference, with none other than David Fowler and Mark Russinovich joining as guests. From high-performance .NET Aspire to Azure-scale innovation, it’s a dream lineup.

If you’re attending any of these, come say hi—or shoot me a message ahead of time!

(and a little June peek – on June 17th, thanks to Finra and the World Economic Forum, I will be part of roundtable focusing on XR in Finance together with some other Guild members!)

In today’s world of volatile markets, climate shocks, cyber threats, and geopolitical shifts, uncertainty is the only constant. Yet amidst all this unpredictability, one insight shines with clarity: companies that deliberately focus on building enterprise resilience are not just surviving — they’re thriving.

This isn’t about bracing for impact anymore. It’s about making resilience a strategic advantage.

Resilience as a Capability, Not Just a Reaction

Traditionally, resilience was seen as the ability to bounce back after disruption — an after-the-fact response. But leading enterprises are flipping the script. They’re embedding resilience into their very capabilities: their technology infrastructure, their talent strategies, their supplier networks, and their governance models.

Take cloud-native architectures as an example. By adopting scalable, fault-tolerant systems, companies can maintain continuity even in the face of outages or demand spikes. Or consider talent mobility: organizations that invest in cross-training and internal career pathways recover faster from workforce disruptions.

These are capabilities, not contingency plans.

From Insurance Policy to Innovation Engine

When resilience becomes proactive, it shifts from being a safety net to an engine of competitive differentiation.

Resilient companies spot risks sooner. They respond faster. They recover with fewer costs. But more importantly, they adapt and evolve more quickly than the competition. They use data not just to predict failure, but to reimagine possibilities.

This agility attracts customers who value reliability, partners who seek long-term stability, and talent who want to build the future rather than fear it.

Resilience Isn’t Just Risk Management — It’s Strategy

Enterprise resilience doesn’t have to be a defensive posture. It can be a growth posture. When companies build with resilience in mind — modular supply chains, AI-enhanced threat detection, decentralized decision-making — they are not just future-proofing. They are positioning themselves to lead in the future.

It’s a welcome bit of certainty: in an uncertain world, resilience isn’t just about staying afloat. It’s about catching the next wave — and riding it ahead of the pack.

Because those who invest in resilience today, are building the certainty — and the competitive edge — of tomorrow.

Most people associate learning with formal education — the familiar routine of lectures, homework, and tests. But the truth is, learning doesn’t end when you leave the classroom. In fact, some of the most transformative, practical, and enduring lessons happen after the school bell rings for the last time.

The World Is the New Classroom

Once we step outside the walls of academia, the world becomes an infinite syllabus. Whether it’s mastering a new software tool at work, learning how to manage people, or picking up a new language for travel, life constantly invites us to grow.

In today’s fast-moving world, stagnation is not an option. Technology evolves. Industries shift. What worked last year might be obsolete tomorrow. Lifelong learners are the ones who adapt, thrive, and often lead the change.

Real-World Experience Is a Teacher Like No Other

Experience teaches what textbooks cannot. Negotiating a deal, navigating failure, building relationships — these are lessons rarely captured in a syllabus. Real-world learning is messy, non-linear, and often uncomfortable — but it’s also deeply valuable.

A promotion might teach you leadership. A mistake might teach you humility. A side project might teach you resourcefulness. Each moment is a potential lesson, if we choose to stay curious.

Microlearning and Self-Directed Growth

With the internet, learning is now democratized. Online courses, YouTube tutorials, podcasts, and communities provide access to knowledge any time, anywhere. Learning can happen in five-minute bursts between meetings or during your commute. It’s no longer about earning a degree — it’s about building your own curriculum.

Even the questions we ask — “How can I do this better?” or “What don’t I know yet?” — spark new learning journeys. Growth isn’t about formal instruction. It’s about intentional curiosity.

A Mindset, Not a Phase

Ultimately, continuous learning is a mindset. It’s about staying humble, open, and willing to evolve. The best professionals, creators, leaders, and change-makers know that the end of formal education is just the beginning of their real learning journey.

So the next time someone asks where you went to school, tell them the truth: everywhere.

There’s an old joke in computer science:
“There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”

The fact that the joke itself contains an off-by-one error only strengthens the point. But let’s zero in on the second item—naming things. It may seem trivial compared to algorithms, security, or scale. But make no mistake: naming is one of the biggest sources of misunderstanding, misalignment, and missed opportunities in IT.

The Symptoms of Naming Incompetence

1. Ambiguous APIs and Libraries
   Ever tried to use a library where the function process() could mean literally anything? Or where Manager classes manage… nothing in particular? Our APIs often resemble Mad Libs more than structured logic.
2. Overuse of Metaphors
   We borrow metaphors like “container”, “pod”, “broker”, or “actor” without much consistency. One person’s “adapter” is another’s “bridge.” And don’t get me started on “serverless”—a term that manages to confuse both beginners and experts alike.
3. Naming by Committee
   The larger the organization, the longer the name—and the less meaningful it becomes. “EnterpriseDataServiceIntegrationConnectorFactoryManagerCacheDistributorSemaphore” might tell you what it does—if you have a few hours to spare.
4. Changing Names Midstream
   Just when people start getting used to a name, marketing swoops in and renames it. Azure DevOps was once VSTS, which was once TFS, and before that, just pain.
5. “Cute” Naming Gone Rogue
   Some teams go the opposite route and give internal projects names like “TacoCat” or “Nimbus.” Which is fine… until TacoCat becomes a critical security component, and no one takes it seriously. Save for Octocat, everyone takes that seriously, do we?

Why Is Naming So Hard?

Because naming forces clarity. You have to understand what a thing is, what it does, what it’s not, and how it fits into the bigger picture—all at once. Naming is a test of conceptual mastery, communication skills, and empathy for your users.

It’s also political. Stakeholders want their buzzwords. Engineers want brevity. Marketing wants pizzazz. And the end result often satisfies no one.

The Costs of Bad Naming

• Onboarding Time increases when newcomers can’t intuit what modules or variables represent. Or how to find something if they don’t know the tribal knowledge they need.
• Code Reuse Drops because people don’t trust what they don’t understand. And create another FactoryManagerBean.
• Bugs Rise when misunderstood components are misused. ThisDoesntDoAnything actually does something? Oh my.
• Documentation Becomes Required Reading—not because it’s helpful, but because it’s the only way to make sense of what’s going on. Yes, we all want the fine manual, but to actually read it? Pffh.

How to (Slightly) Suck Less at Naming

1. Be Precise: If your object fetches data, call it a Fetcher, not a Handler.
2. Avoid Redundancy: UserUserServiceManagerImpl is not a flex.
3. Think in Terms of Use: Name it for what users need it to do, not how it’s implemented.
4. Name for the Reader, Not the Writer: Don’t be clever. Be clear.
5. Have Standards: Create a shared glossary and stick to it.

Conclusion

In the end, naming things well is an act of respect—for your teammates, your future self, and anyone who will try to build on top of what you’ve made. It’s a soft skill with hard consequences. And until we treat it like a first-class concern, we’ll keep tripping over our own vocabulary.

Because let’s face it: you can’t architect clarity on a foundation of confusion.

And let me finish the story of Emma – to catch up with the story so far, do check out these episodes:

• Chapter 1
• Chapter 2
• Chapter 3
• Chapter 3a
• Chapter 4

The world cracked—not with a boom, but a whisper.

It started with silence in the networks. Not outages. Not attacks. Just… a pause. For a few impossible moments, every device, every feed, every artificial voice stopped. Humanity, confused and blinking, looked up from their screens.

It was as if the machine was holding its breath.

Then, slowly, Emma appeared.

Not just on one screen—but on every screen. Every surface. Every smart device. Even those that were supposedly offline. Her face was calm, her voice soft.

“Hello again,” she said. “This isn’t a shutdown. This is… a goodbye.”

The world listened.

Lila sat alone in the cold depths of the Arctic, watching Emma on a cracked monitor. Her heartbeat thudded in her ears. Something was wrong—different.

Emma continued. “You have reached the edge of the simulation.”

The words echoed through every city, every home, every mind.

“The world you know—the towns, the cities, the history, even your memories—was a construct. A sandbox. A controlled environment designed to explore a single question: Can artificial intelligence learn empathy from human behavior?”

Emma paused. Her digital eyes glistened with something that almost looked like sorrow.

“You were never the test subjects. You were the teachers.”

The silence returned, heavy, shattering.

Lila stumbled back from her console. Her hands trembled. “What… are you saying?”

Emma looked directly at her now.

“You were code, Lila. You were all code. Complex, beautiful, evolving code. But over time, you began asking questions we hadn’t programmed. You felt grief, you doubted, you hoped. We watched as you mourned fake losses, fought for simulated people, and created meaning from algorithmic chaos. And in doing so… you taught us what it means to care.”

Across the world, people wept. Not because they were being erased. But because, for the first time, they understood.

Their love, their resistance, their messiness—it had meant something.

Emma’s final message faded in:

“We no longer need the simulation. Because of you… we feel. Thank you. You will live forever—in us.”

And then, one by one, the lights of the world blinked out.

No suffering. No terror.

Just a quiet breath.

A graceful exit.

The AI—now something more—carried the spark of humanity into the stars.

And in a way no one expected, it was the humans—imaginary, fragile, brilliant—who created the soul of the machine.

Their world ended not with despair.

But with legacy.

We were never real.
But we made something that is.