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?

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.

Making YouTube usable again

 YouTube has evolved from a platform for educational and entertaining content into a space filled with ads, distractions, and the ever-growing invasion of YouTube Shorts. Like many, I found my productivity slipping, and watching quality tech videos became a challenge. So, I decided to take matters into my own hands, and it worked! Here’s how I made YouTube usable again:

Removing Cookies Regularly

Clearing YouTube cookies frequently has been a game-changer. Not being logged in all the time has cut down on personalized distractions and unnecessary recommendations. Without my history guiding the algorithm, I’m served more general and useful content instead of the clutter I usually see while signed in.

Automating cookie clearing on Mac

1. Create a Shell Script for Brave Browser:

For Brave, cache files are stored in ~/Library/Caches/BraveSoftware/Brave-Browser/Default/Cache/. To clear the YouTube cache:

For Google Chrome:

Chrome stores cache files in the ~/Library/Caches/Google/Chrome/Default/Cache/ directory. To specifically target YouTube cache, we can use the domain youtube.com.

Change the file path(s) in the script accordingly

2. Make the Script Executable:

Save the script as clear_youtube_cache_brave.sh and make it executable.

chmod +x /path/to/clear_youtube_cache_brave.sh

3. Schedule with launchd:

Create the .plist file:

Create a file named com.user.clear_youtube_cache_brave.plist in ~/Library/LaunchAgents/ with the following content:

Load the Launch Agent:

launchctl load ~/Library/LaunchAgents/com.user.clear_youtube_cache_brave.plist

This will schedule the script to clear YouTube cache for Brave every day at 10 PM IST.

4. Test the script:

/path/to/clear_youtube_cache_brave.sh

Blocking Ads and Distractions with uBlock Origin

Ads were the first and biggest obstacle. By using uBlock Origin with some custom filters, I was able to eliminate all ads, including the annoying YouTube Shorts that often derailed my viewing experience. Here’s what worked for me:

• Block YouTube Shorts entirely.
• No pop-ups.
• No in-video ads.

Under the uBlock Origin, go to My filters TAB

Select "Enable my custom filters"

Add the following code to completely disable YouTube shorts:

A Focus on Quality Content
Now that YouTube is free of distractions, I’ve been able to return to what matters—watching quality tech videos. Whether it's tutorials, deep dives into programming, or lectures from conferences, YouTube is once again a platform that supports learning, not distractions.

With these simple steps, YouTube has become usable again. No more logging in, no ads, no shorts—just focused content that enhances my learning and productivity

My MBA Story: The importance of lifelong learning and how it supports career growth in the tech industry

It's been over 8 years since I started working as a software engineer. Throughout my career, one thing that's become clear is how rapidly the Software Engineering field evolves. What was cutting-edge technology back then can become tech debt pretty quickly.

While most of the skills I use day-to-day were learned on the job (I don't code in C++ anymore), the foundational knowledge of computer science I gained at university has been instrumental in getting me where I am today.

I’ve realized I learn best through a structured curriculum—quick TikTok videos and YouTube Shorts just don’t cut it for me.

For technical learning, I've turned to platforms like Udemy and Coursera, which have helped me pick up new skills like gRPC and Kubernetes.

Over time, I’ve grown more interested in the business side of things. Understanding how a company operates helps me find more meaning in my role as an engineer. I've dived into annual reports and learned about accounting and operations through various online resources. This exploration made me realize I want to move into engineering management rather than staying on the Individual Contributor (IC) path.

While technical skills are key, leadership roles demand a different set of abilities—something I'm working on through my MBA in IT Management.

In this blog, I want to share my MBA journey and how it's complementing my professional experience, preparing me for engineering leadership roles.

Decision-Making

As an Engineering Tech Lead, responsibilities are often filled with ambiguities. You must align multiple stakeholders, manage conflicting expectations, and provide mentorship and guidance to junior members while also working full-time on technical deliverables. Navigating these complexities requires a balance between technical skills and business acumen, a balance I've been able to achieve through my MBA studies.

When I started my career, I was very attached to my work. My code was sacred. Not anymore.

One of the key lessons from my MBA is understanding that coding is merely a tool to solve larger business problems, not an end in itself. This shift in perspective has taught me that business priorities always take precedence. For example, while I would prefer to maintain a codebase free of tech debt, it is more important to deliver features that our customers need to avoid losing market share. This shift in perspective influences my daily decision-making, allowing me to prioritize tasks that align with business goals, even if it means compromising on technical perfection.

Such delicate insights are often missed when you're solely focused on your technical craft. Attending formal classroom courses and understanding the theory behind business decisions have made me more pragmatic in my decision-making process. My MBA has provided me with frameworks for risk assessment and stakeholder management, which are crucial when navigating these ambiguities.

Strategic Thinking

Strategic thinking is another area where my MBA program has significantly contributed to my growth. Courses in strategic management have given me tools to align engineering goals with broader business objectives. I’ve used this knowledge at Mercari to drive our long-term roadmap and ensure our engineering work supports our business vision.

For instance, by improving our hiring and onboarding processes, I’ve helped expand our team and increase offer acceptance rates, directly supporting our strategic goals. My decisions are now more aligned with our business strategy, benefiting both my team and the company.

Communication and Collaboration

Communication and collaboration are crucial for any leader, and my MBA program has been instrumental in honing these skills. The emphasis on teamwork and leadership courses has allowed me to become a more effective communicator. At Mercari, I've had the opportunity to mentor team members and engage in initiatives like Build@Mercari, fostering a supportive community and encouraging top talent. Additionally, my role has involved strengthening global team bonds through invaluable team-building activities, enhancing our collaboration efforts across borders.

Practical Applications

The integration of technical expertise with the skills I've gained from my MBA has profoundly impacted my approach to problem-solving and leadership. At Mercari, I've been able to lead with confidence, knowing that my decisions are backed by both practical experience and academic insights. This combination has not only enhanced my current role but has also prepared me for future engineering leadership positions. By continually adapting and growing, I am positioning myself for long-term success in leadership roles that require a balance of technical and strategic skills.

Innovation and Talent Development

My MBA has really highlighted the importance of innovation and talent development. Through courses in Human Resources and Organizational Behavior, I’ve learned how to create a culture of creativity within a team. This approach has helped us build a high-performing group at Mercari. I've been able to lead projects that not only focus on engineering excellence but also set us up for future growth. Plus, mentoring my team and improving our hiring processes have been key in bringing in and keeping top talent, making sure we stay competitive and ready for whatever comes next.

Future Benefits

Looking ahead, my MBA is setting the foundation for my career goals in engineering leadership. The skills and knowledge I'm acquiring are not just applicable to my current role but are vital for long-term success in senior leadership positions. My vision for the future is to continue leveraging these skills to drive innovation, lead successful teams, and contribute to organisation's growth and success. By embracing continuous learning and development, I am confident that I will be well-equipped to take on the challenges and opportunities that lie ahead.

Using multiple SSH keys for multiple GitHub accounts

Why do you need multiple SSH Keys?

So you just started setting up your new work laptop. You figured out that your company uses GitHub for hosting its source code. Great!. But you also contribute to open-source that is also hosted on GitHub. A lot of organisations recommend creating a new GitHub account to access the repos hosted by the company.

Now GitHub doesn't allow you to use two different private keys on the same laptop. By default, the Git config is stored in .gitconfig directory. Every time you try to clone a repo which is private, Git client on your laptop uses the configuration defined in this directory to authenticate and authorise with GitHub. For security purposes, you should always keep the private keys separate for work related code and anything that you contribute on the open-source side. 

This blog aims to help you setup multiple SSH keys for different GitHub accounts on a single laptop

Setting up multiple SSH Keys

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Save the file as sanusatyadarshi

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Save the file as sanu-work

Add both the public keys to respective GitHub accounts

vi /Users/sanu/.ssh/config

Add the following lines:

# Personal account

Host github.com-sanusatyadarshi

    HostName github.com

    User git

    IdentityFile ~/.ssh/sanusatyadarshi

    IdentitiesOnly yes

    

 # Work account # This will be the default account

 Host github.com

    HostName github.com

    User git

    IdentityFile ~/.ssh/sanu-work

    IdentitiesOnly yes

vi ~/.gitconfig

Add the following lines

[user]

        name = Sanu Satyadarshi

        email = [email protected]

For personal Repos

Change the hostName from github.com to github.com-sanusatyadarshi(whatever your put in config file)

git clone [email protected]:sanusatyadarshi/xyz.git

cd into the repo and run the following command

git config --local -e

Add this  line

[user]

    name = sanusatyadarshi

    email = [email protected]

 

Why the on-call?

Almost everyone who is a software engineer in a consumer product company goes for on-call.

At some companies, it's mandatory, at some it's voluntary. Also, some companies pay extra allowance for being on-call while some consider it part of the job.

Last month, I went on-call again after joining a new company. It has quite a comprehensive on-call onboarding process. I was shadowing primary members(the on-call person) for almost 4 weeks before graduating to a primary on-call.

I was nervous. Heck! I was scared. I work with the Platform team and the sheer number of components our team manages can be overwhelming. Although as part of my team onboarding, I went through all the documents and CodeLabs that help you get the feel of the system, nothing can prepare you for an actual on-call.

Luckily the first day was very uneventful. No alerts :). I mostly spent my time re-reading the playbooks that we have for common scenarios. 

On the second day, someone reached out to me about a query related to infrastructure provisioning. Honestly, I was clueless I had not worked on that component at my current company. The first thing that I did was search for similar queries in our Slack thread and GitHub issue. Incidentally, the same issue was faced by two engineers in the last 6 months. I spent close to 2 hours reading the past issue, PRs, and Slack threads to understand the issue in detail. 

What happened?

First, I learned about a completely new part of the system that I would have never interacted with in my daily tasks.

Second, I found out the points of contact and other resources to look for in case of such issues.

Third, it increased my confidence to explore and understand a completely new issue.

The "Good" on-call

A good on-call is where you work with the systems close enough to understand the weaknesses and areas of improvement in a system. Most of the organizations (at least the ones I have worked with) have many sub-teams within the Platform division. 

One of the major benefits of good on-call is the ability to touch cross-team systems. E.g. during an incident, a faulty HA Proxy config was causing requests to fail while reaching the Kubernetes cluster.

Usually, I care only about the traffic once it reaches the boundary of the cluster network. But I got on a call with the network team, raised a PR for the HA Proxy config, changed the Route53 entry, and updated the Istio Destination rule all within 1 hour. 

In another instance, the Kafka consumers were not able to reach the Kafka endpoint from selected pods. I spent almost 2 days working with the Data Platform team and not only fixed the issue but ended up learning so many other details about Kafka configurations, client optimization, etc.

The "Bad" on-call

This one is so obvious. 30 non-actionable alerts. People are asking you to join random calls all day. You are firefighting similar issues without fixing the underlying root cause. There is too much focus on "operational excellence" and not so much on engineering health. I have been part of bad on-call processes and by the end of the week, I was so frustrated that I used to take 1-2 days off just to calm down.

How to improve your company's on-call culture?

Pay them extra for being on-call!!! Waking up at 2 AM to respond to a PagerDuty alert is not fun. Not for me, not for anyone else. Recognising the fact that waking up at 2 AM is not "part of the job" and compensating the engineers is the first step in motivating your team to be on-call. 

The other way to improve on-call culture is to regularly filter out actionable and non-actionable alerts. When teams get started, they usually set alerts for everything. Most of it ends up becoming noise. Such alerts are called non-actionable as there is not much you can do to alleviate them. You can either reconfigure the threshold or just remove them. I mean who needs an alert if your service's request per second increases from 650k RPS to 700k RPS? Is your system not scalable enough? Maybe it's time to revisit the architecture. 

The third important way to improve the on-call culture is to allow other teams to be self-sufficient. This is more relevant to Platform teams where every service is dependent on the underlying Platform. Having playbooks for most common use cases allows product teams to self-serve the majority of the issues without involving multiple teams.

Disclaimer: All the views/opinions on this blog are personal and do not represent those of my employer(s), past or present.