Monday, November 17, 2025

Optimists, Pessimists, and Realists: The Clash of Cultures in an AI-Native World

I've been building an Artificial Intelligence team at Mercari during the last 6 months. During this journey, I've interacted with many Engineers, Managers (both technical and non-technical), and Industry leaders. Almost everyone I talked to had a very strong opinion about how AI will change our world—or at least our jobs. It's been both an interesting and exhausting experience hearing so many polarized perspectives. Feels like everyone has already seen their version of the post-AGI world and can't fathom an alternative future.

To simplify my approach to working with these varied groups of people, I decided to categorize them into three broad buckets: The Optimists, The Pessimists, and The Realists. This classification isn't meant to undermine anyone's perspective—it's a framework to help me lead effectively, understanding what motivates each group and where friction might emerge.

Part I: Understanding the Three Cultures

The Optimists: The Force Multipliers

The Optimists are primarily two subsets of people: senior leadership (CXOs) and highly technical engineers building AI/LLM-based products directly.

It's hard to resist the infectious energy that comes from talking to this group. I routinely hear "This is the best thing to happen since the Internet" from them. They see AI as a genuine force multiplier—work that used to take weeks can now be done in days, if not hours. (Yes, that's an oversimplification, but the spirit of it is real.)

What makes this group special is that they embrace AI with open arms—whether it's for improved bottom lines, faster product development, chasing the IPO dream, or for the ESOPs. Their motivation varies, but their enthusiasm is consistent.

As a leader of an AI team, this group is the easiest to work with. They're ready for bold ideas, willing to challenge the status quo, and excited to try something truly unheard of. They become your champions for organizational change.

But here's the nuanced part—and this is where I've learned something important: optimism without intellectual humility can become a liability. There's a difference between healthy ambition and credulity. The best Optimists are those who maintain their passion while asking hard questions: "What are we assuming? Where might this fail? What constraints are we not seeing?"

The Pessimists: The Psychology of Resistance

The Pessimists are everywhere. The Reddit communities are full of them. Many non-technical (or hands-on) managers fear that the busy work keeping them afloat will no longer be safe. Engineers working in support, maintenance, and boilerplate code generation—roles heavily dependent on following SOPs—worry deeply about AI's impact on their value.

I don't say this with disrespect. Based on my interactions, this group seems to be operating from a place of genuine fear rather than pure denial. I remember recommending "Hands-On Large Language Models" to a colleague, and he almost snapped at me. His response? "We don't need to learn AI. Knowing how to use Cursor or Claude is enough."

Here's what I've learned: resistance to AI isn't fundamentally about irrationality. It's about perceived threats to professional identity, loss of autonomy, and uncertainty about the future.

These people have built careers within well-defined frameworks. They've become masters of their domain by deeply understanding procedures and edge cases. When you introduce AI, you're implicitly saying that reliability and procedure-following—the foundation of their value—is becoming commoditized. That's genuinely threatening.

The colleague who was skeptical wasn't rejecting knowledge. He was reacting to what psychologists call a status threat—the possibility that his accumulated expertise might become less valuable.

To work effectively with this group, I've adopted a framework of empathy and encouragement. If they push back, I show them working examples. If they're skeptical, I ask for their input and feedback. Because here's the truth: skepticism, when channeled properly, isn't a bug—it's a feature. It's the thing that prevents overly ambitious teams from making expensive mistakes.

The Realists: The Foundation of Everything

Then there's the most "boring" group—and I use that term with deep respect: The Realists.

This is the group actually working day in and day out with LLMs, RAG systems, agentic workflows, and even fine-tuning models. They treat AI as a tool—one among many in their toolset. Not like a magic wand. Not like a curse that will end humanity in some dystopian future.

I consider myself incredibly lucky that both my manager and the leadership in my organization, as well as the engineers in my team, are acutely aware of both the potential and the current limitations of AI. When I propose an unrealistic solution, they give me candid feedback without sugarcoating or overselling the capabilities of current offerings.

The Realists are the unsung heroes of sustainable innovation. They understand something that neither the Optimists nor the Pessimists fully grasp: the difference between proof-of-concept brilliance and production reliability. They've seen great on-paper architectures fail catastrophically when exposed to real-world multi-agent client side development. They know where the bodies are buried.

This group needs less motivational rhetoric and more practical enablement: clear goals, removal of bureaucratic obstacles, and genuine authority to make technical decisions. When you grant this, they self-motivate.

Part II: Where the Cultures Clash

Now that we've roughly defined these groups, let's talk about their clashes—both in the workplace and beyond.


 

The Optimist vs. The Realist: Vision Meets Pragmatism

The first clash typically looks like this: An Optimist proposes an ambitious AI application with a compressed timeline. The Realist, having done similar work, explains why the 12-week timeline would require either cutting corners or delivering a brittle system.

This is where many organizations fail. They resolve the tension through top-down mandate—the Optimist's ambitious goal overrides the Realist's technical warnings, and the Realist disengages, knowing their expertise will be dismissed.

But here's what I've discovered: this clash, when managed well, produces superior decision-making. Organizations combining visionaries with pragmatists consistently outperform teams of either type alone.

The key is establishing what I call collaborative conflict management. This means:

  • The Optimist learns to provide ambitious goals while genuinely respecting technical constraints

  • The Realist learns that sometimes constraints themselves can be rethought if you're willing to take calculated risks

  • Both see each other as having valuable, non-competing perspectives

As a leader, your role is to be the translator. You ask the Optimist: "I love this vision. What would have to be true for this to work? What are we assuming?" And you ask the Realist: "What if we resourced this differently? What would it take to compress this timeline without compromising quality?"

The Optimist vs. The Pessimist: Momentum vs. Inertia

This clash is perhaps the most destructive if left unmanaged. It operates at the level of organizational identity and momentum.

When an Optimist proposes a bold new direction and a Pessimist immediately lists reasons it won't work, observers form quick judgments: Are we a company that believes we can transform? Or are we fundamentally defensive?

The organizations that fail at AI transformation often do so not because the technology is hard, but because leadership fails to actively manage the narrative tension between ambition and caution.

I've learned that successful organizations deliberately create what I think of as containers for productive disagreement—spaces where:

  • It's safe to voice concerns without being labeled "not a team player" or a pessimist

  • It's acceptable to express ambition without being labeled reckless

  • Disagreement is seen as valuable, not divisive

My framework of "empathy and encouragement" for the Pessimists is built on a key insight: when people who are naturally skeptical feel understood rather than dismissed, they often become valuable contributors rather than blockers.

But here's the subtlety: empathy is not agreement. You can profoundly understand why someone fears AI will eliminate their role while still maintaining that reskilling and adapting is necessary. You show them working examples not to prove them wrong, but to build confidence that change is manageable.

The Realist vs. Themselves: When Pragmatism Becomes Inertia

There's a final clash worth watching: when Realists' grounded pragmatism hardens into institutional conservatism.

This happens gradually. The legitimate caution of the Realist gets institutionalized as organizational risk aversion. Over time, even genuinely innovative ideas from within the Realist camp get filtered through an overly cautious lens. The organization becomes good at execution but loses its capacity for transformation.

The solution? Deliberately create autonomy and protection for what some call "innovation that doesn't need to ship"—exploratory work that might fail, but builds organizational capability and keeps the Realist group thinking expansively.

Part III: Leadership Strategies for the Three-Culture Organization

So how do you actually lead an organization with these three cultures? Here's what I've learned:




 

Leading the Optimists: Vision With Rigor

Your role with Optimists is to be the translator between vision and reality.

This doesn't mean dampening their enthusiasm. It means channeling it with intellectual discipline. When an Optimist comes to you with an exciting idea, your job is to:

  • Get excited with them (authentic enthusiasm is contagious)

  • Ask clarifying questions: "What would have to be true for this to work? What are we assuming? Where could this fail?"

  • Inject rigor without killing momentum

The best organizations I've seen manage their Optimists by giving them visibility and influence while surrounding them with pragmatic advisors who ask hard questions. This combination drives innovation without recklessness.

Leading the Pessimists: From Fear to Engagement

Fear-based resistance transforms when people experience psychological safety and see working proofs.

Your approach matters here:

  1. Show working examples, not arguments. Data and proof-of-concept matter more than rhetoric when someone is skeptical.

  2. Involve them in shaping solutions. When a skeptical engineer has input into how an AI capability is implemented in their domain, they move from "this will hurt us" to "this might work if we're careful about X and Y."

  3. Acknowledge their legitimate concerns. The support engineer who worries about job loss isn't being irrational—they're responding to genuine uncertainty. Acknowledging this builds trust far more than dismissing their fears.

  4. Offer reskilling and growth opportunities. Show them a concrete path to remaining valuable in the new world. This transforms anxiety into curiosity.

  5. Create quick wins in their domain. Let them experience AI as a tool that makes their job easier, not obsolete.

Leading the Realists: Autonomy and Trust

This group needs less motivational rhetoric and more practical enablement.

  • Give them clear goals and remove bureaucratic friction

  • Grant them genuine authority to make technical decisions

  • Protect their time for deep work

  • Ask for their candid feedback and reward truth-telling

  • Let them build systems that work, not systems that look good

When you do this, this group becomes self-motivating. They don't need constant affirmation—they need the space to do excellent work.


Part IV: Building the Three-Culture Organization

What I'm attempting to build at Mercari—and what I think every organization attempting AI transformation needs—is what I call high-context decision-making. Rather than imposing a single view of what AI means, we're creating an environment where different perspectives are understood, valued for what they contribute, and managed actively.

The Optimists keep us ambitious and push us to think bigger. The Pessimists force us to think about consequences and edge cases. The Realists keep us grounded in what's actually achievable.

All three are necessary. None are optional.

The Exec Lens

As I think about my own journey, I realize that technical excellence alone isn't enough. The future leaders of AI organizations will be those who can:

  • Synthesize vision (from the Optimists) with caution (from the Pessimists) and pragmatism (from the Realists)

  • Create environments where all three perspectives are heard and valued

  • Make decisions that balance ambition with realism

  • Build teams that innovate responsibly

This is the intersection of technical depth and leadership wisdom.

 

The Reality Check

Here's something I want to be honest about: this is hard. There are days when the Optimist's impatience with the Realist's caution frustrates me. There are days when the Pessimist's resistance feels like obstruction rather than wisdom. There are days when the Realist's pragmatism feels like a lack of vision.

But I've come to see these tensions as features, not bugs. Organizations that suppress dissent and enforce a single view—whether through aggressive optimism or institutional conservatism—are the ones that eventually fail.

The organizations that succeed are those that have learned to dance with their contradictions.

Final Thoughts

Six months into building an AI team, I've learned that organizational transformation is less about deploying technology and far more about managing the competing worldviews that different stakeholder groups bring.

My framework of Optimists, Pessimists, and Realists isn't meant to be predictive or judgmental. It's meant to help me—and perhaps you—navigate the genuine complexity of leading in the AI era.

If you're building an AI team, you probably have all three types. The question isn't how to eliminate one group. The question is: How do I create an organization where all three perspectives make me smarter, not slower?

My goal is to build an AI organization where vision, skepticism, and pragmatism reinforce each other.A culture where Optimists stretch us, Pessimists harden us, and Realists ground us—without any group overpowering the others.

That's the challenge. That's also the opportunity.

If AI is forcing a new kind of cross-cultural leadership, which culture are you unconsciously empowering in your organization—and what is that costing you?

Monday, June 2, 2025

I Built a Silly CLI Tool, Just Because I Can

No roadmap, no real need — just an engineer having fun again.

Why I Built This Silly Little CLI Tool?

There’s a part of me that still lights up when I ssh into a Raspberry Pi or see logs scroll past on a terminal. Even though my job title has grown, my love for getting my hands dirty hasn’t gone anywhere. I’ve been doing more engineering leadership work lately—mentoring, aligning org goals, enabling teams, writing roadmap docs. And while I deeply enjoy shaping how we build and scale systems, I missed something very basic: the raw, low-stakes fun of building stuff for no reason.

So I built Mantra, a silly little CLI tool that does a bunch of random things—like pinging a website, checking HTTP headers, doing DNS lookups, and even adding a few numbers. It’s not groundbreaking, but that’s the point. It’s not supposed to be.

It’s me putting on my “just an engineer having fun” hat again.

I Missed Being a Geek

I'm the kind of person who self-hosts their entire digital life. Seriously—I've got a Kubernetes cluster running on Raspberry Pis at home. Grafana dashboards track everything from smart light usage to DNS queries. I run a local DNS sinkhole to cut out ads. My NAS is packed with movies I’ll probably never finish watching. If something can be self-hosted, it probably already lives in my home lab.

This stuff doesn’t have to be perfect. It doesn’t even have to be useful to anyone but me. I just love that feeling: learning, tweaking, experimenting. Breaking something and staying up late to fix it. Writing GitHub Actions that somehow works. Debugging issues that no one else will ever care about. That’s my fun.

Mantra = Formula

The name मंत्र (Mantra) comes from Hindi, meaning “chant” or “formula.” Traditionally, a mantra is a sound, word, or phrase repeated to focus the mind or invoke inspiration.

In the context of this project, Mantra is like a personal formula—a simple set of commands that help me focus, have fun, and reconnect with the joy of building. It’s a reminder that sometimes, the smallest routines or tools can bring clarity and energy to complex days.

Mantra is my little playground. I didn’t want to build the next productivity tool. I just wanted to build something. Something that lives in the terminal. Something I could ./mantra webstatus sanusatyadarshi.com at 9 p.m. after a long day of meetings and still feel like an engineer.

$ ./mantra webstatus sanusatyadarshi.com
The response from sanusatyadarshi.com is: 200 OK

I picked Go because I like how it feels—pragmatic, tidy, and fast. And because I missed the satisfaction of building something from scratch and watching it actually work. Mantra checks if a website is alive. It shows you headers. It does a little math. It’s not a full suite of tools, it’s just a weird little robot that does things I find fun.

I Treated It Like a Real Project

Even though this was just for fun, I couldn’t resist going the extra mile. I set up proper CI/CD with GitHub Actions. I created versioned releases with changelogs. I even tagged commits like I was shipping production software.

Why? Because it felt good. It reminded me of the pride that comes from seeing something go from a vague idea to a packaged, released binary. And honestly, if you're going to write code, why not write it well?

Hacking Makes Me a Better Leader

Here’s the thing people don’t talk about enough: side projects make you better at your “real” job—even if that job isn’t coding full-time anymore.

When I build things like Mantra, I reconnect with the parts of engineering that frontline devs deal with every day: messy bugs, docs that lie, error messages that make no sense, tradeoffs that happen in the moment. It keeps me close to reality. It makes me more empathetic. When a dev on my team says “debugging this took forever,” I actually get it—because I just spent two hours wondering why a slice wasn’t updating.

It also keeps my judgment sharp. It’s one thing to talk about system design in a meeting. It’s another to experience why a library’s abstraction is frustrating or how an interface breaks down in practice. Even small tools like Mantra remind me that details matter—and so does developer experience.

And frankly, building things with no business value makes me better at recognizing what does have business value. It keeps my BS radar strong.

TL;DR

I built Mantra because I missed the feeling of making something silly, simple, and mine.

It’s not big. It’s not important. But it reminded me why I started writing code in the first place—and why I’ll never stop, no matter what title I hold.

When Platform Teams Succeed — and When They Don’t

Success for platform teams isn’t just about building great tools. It’s about getting the whole company to move with you. And for that, you need the right kind of backing.

Disclaimer: Views expressed are my own and do not represent those of my current or former employer(s).

Summary

Platform teams win when they have the authority to drive change, not just recommend it. That means sponsorship from the top, alignment with business outcomes, and the ability to say, “This isn’t optional.” Without that, your roadmap becomes a graveyard of unadopted migrations. And your engineers? Burnt out and invisible.


Platform Work Is Critical—and Often Thankless

If you’re on a platform team, you’re probably doing the invisible work that makes everything else possible: infrastructure, developer experience, observability, CI/CD, and org-wide migrations.You power the foundations of SDLC at your company-but hardly anyone cares.

Why?

Because you don’t ship customer features. Your metrics live in internal dashboards, not company OKRs. So when you say, “We need every team to migrate by Q3,” what you usually hear back is:

“We’ll put it in the backlog.”

That’s where the success or failure of platform teams starts taking shape.



When Platform Teams Fail

It’s rarely dramatic. It’s a compounded burden of ignored deadlines and growing disillusionment.

  • Migrations stall. Nobody pushes them. Product teams are focused on features.
  • Morale dips. Engineers working on infra or devtools feel unheard, sidelined or even ignored. They become the internal help desk.
  • Shadow tools emerge. Teams build their own pipelines or tweak infra, defeating standardization efforts.
  • The team loses credibility. And once trust erodes, it’s hard to recover. The platform team becomes a cost center instead of a force multiplier.


The Fix: Top-Down Authority

Successful platform orgs are not consensus-driven. They are mandate-driven. And that mandate comes from executive sponsorship—VPs, CTOs, even the CEO in some companies.

When leadership is aligned, three things change:

  1. Org-wide clarity. Migrations aren’t “optional.” They’re tied to core goals: uptime, velocity, scaling bets.
  2. Incentives shift. Product teams prioritize the migration because it’s tied to their own success metrics.
  3. You get support. The PMs, TPMs, security teams, and budget you need show up—because the execs said so.
You don’t need to beg for adoption. You drive it.

This kind of sponsorship turns platform work from a "nice-to-have" into a business-critical priority.

Case in Point: Driving Migrations

Let’s talk migrations — the litmus test for platform teams success.

  • Without support: A new performance optimisation tool is rolled out, but only 30% of teams adopt it. The rest don't prioritise it or don't adopt it due to incompatibility(due to prior unfinished migrations).
  • With support: Migration deadlines are communicated org-wide. Dashboards track adoption. Engineering leaders follow up directly. And suddenly, everyone’s moving in the same direction.

This isn’t pressure—it’s alignment. Alignment gets adoption. Adoption gets results.

What Platform Teams Can Do

Even if you’re not a Principal Software Engineer with a decade long tenure at the company, here's how you can tilt the odds in your favor:

  1. Tell compelling stories. Translate technical initiatives into business impact: “This migration will reduce infra cost by up to 15%.”
  2. Build alliances. Partner with security, compliance(finops/engineering office etc.), and product leaders. Their needs are often aligned with yours.
  3. Push for sponsorship. If a migration affects the whole company, make the case to engineering leadership early. Don’t wait until adoption stalls.

In the End: Platform Is Political

Success in platform engineering isn’t just about great features and offerings. It’s about influence.

Yes, the systems matter — but so do the people who shape how those systems are adopted.

When leadership recognizes the strategic role of platform teams — and gives them the mandate to drive change — the results are transformative: faster delivery, higher reliability, happier developers.

When they don’t? The tools gather dust. And the people who built them quietly leave.

Final Thought

If you’re in a platform team today, ask yourself:

“Do we have the executive support to drive change — or are we just building great tools no one will use?”

If it’s the latter, start the conversation. Your success — and your sanity — might depend on it.

Optimists, Pessimists, and Realists: The Clash of Cultures in an AI-Native World

I've been building an Artificial Intelligence team at Mercari during the last 6 months. During this journey, I've interacted with m...