How I Failed at Learning to Stop Giving a F*ck and Love the Contradiction: A Leadership Guide for Recovering Overachievers

Or: How I Might Have Learned to Stop Worrying and Love the Contradiction

There is something oddly therapeutic about writing this post. It’s soothing like a good vanilla pudding. I hope you find it therapeutic as well. Enjoy!

You know what's funny about engineering leadership at Amazon? Well, actually, let me rephrase that. You know what's fascinating about engineering leadership at Amazon (or, for that matter, any software engineering firm)? Because "funny" implies there's some cosmic joke being played, and after ten years, I can tell you with absolute certainty that the joke is on us, and we're all laughing because the alternative is a nervous breakdown in the Spheres.

But I'm getting ahead of myself. Let me start with a confession: I've spent the last decade mastering what Mark Manson calls "The Subtle Art of Not Giving a F*ck," except in corporate America, we call it "strategic prioritization" and put it in a PowerPoint with at least seventeen bullet points and a swimlane diagram.

The Paradox of Caring Deeply About Not Caring

Here's the thing about not giving a f*ck in engineering leadership—and forgive the language, but we're all adults here, and if you can't handle mild profanity, you definitely can't handle a P0 incident at 3 AM on Black Friday—the thing is, you have to care enormously about what you don't care about.

Stay with me here.

I learned this during my third year at Amazon when I realized I was spending 40% of my time in meetings about meetings, 30% of my time explaining why we couldn't just "make it go faster," and the remaining 30% wondering if that add up to 100% because math was never my strong suit, which is probably why I went into engineering management in the first place and didn't become a senior principal engineer or distinguished engineer. I also lack the technical god complex skills and the ability to talk about Conway's law on demand.

The breakthrough came when Charlie Bell had a 1:1 with me and here's how it went. (Content warning: awkward thigh-touching incident ahead that will make you question Amazon's leadership development methods, but stick with me because there's actual wisdom buried in this workplace weirdness.) "Uncle Charlie, why can I not be a genius like all the people in the CHOP?" He gets up from behind his desk in his little professor's office in Blackfoot and comes over and sits next to me.

Oddly, he placed his left hand on my right thigh. I suppressed the urge to squeal to exercise my god given rights and seek protection from the thought police (HR). He rubbed the cotton of my pressed Brooks Brothers pants and just said, "We all wear pants in the morning. It's just, my son [Editor's Note, it just sounds better when I add the “my son,” it sounds almost apostolic], we have an information advantage.”

“We get to hear about the thousands of projects happening within Amazon and across our many zillions of customers.”

“In contrast, you, my son, are stuck in solitary confinement with your single, isolated, motherf***ing myopic view of your service."

And that's when I stopped caring about being the smartest person in the room—which, let's be honest, at Amazon is like not caring about being the tallest person at a Lakers game—and started caring about making the smart people in the room more effective. For 99.9% of us, it's literally impossible to be the smartest, most prepared person in the room when you have people who invented core teachings in distributed computing, security, and cloud computing sitting right there, casually explaining why your brilliant idea violates the CAP theorem.

It's like being a conductor who can't read music but somehow makes the orchestra sound better by waving a stick with just the right amount of confidence and barely concealed panic.

The Art of Vocally Self-Critical Leadership (Or: How to Roast Yourself Before Others Do)

Now, there's a delicate balance here that would make a Cirque du Soleil performer nervous. You need to be vocally self-critical—because nothing builds trust like a leader who can admit they once accidentally deleted the production database during a demo to Jeff Bezos's staff meeting—while maintaining enough self-confidence that your team doesn't start updating their LinkedIn profiles.

I call this the "Presidential Self-Deprecation Protocol." Think about it: the best leaders in history could acknowledge their mistakes while never letting anyone doubt their capability to lead.

It's like saying, "Yes, I may have just walked into a glass door in front of the entire engineering organization, but I assure you, my strategic vision for this quarter remains crystal clear."

The trick is timing. You roast yourself before the retrospective, not during it. You acknowledge the process failure before the stakeholder meeting, not after they've already planned your professional funeral. It's preemptive honesty—like diplomatic immunity, but for your career.

Think about the masters of this art. John F. Kennedy, after the Bay of Pigs invasion: "Victory has a hundred fathers and defeat is an orphan." Boom. Owns the failure, takes responsibility, moves forward.

Compare that to... well, let's say certain leaders who shall remain nameless but may have once emphatically declared "I did not have sexual relations with that woman" only to later discover that definitions matter and lawyers are expensive.

For all those young f*ckers out there who haven’t watched “The Godfather” I’m talking about Bill Clinton.

Now go watch “The Godfather,” please. I even gave you a link to Prime Video, TikTok, or whatever you watch Barney on these days.

Or consider the corporate world: when Reed Hastings admitted Netflix's Qwikster pivot was a terrible idea, the company's stock eventually recovered and they became the streaming giant we know today. Meanwhile, we've all watched leaders double down on obviously failed strategies like they're playing poker with Monopoly money and their reputation as the ante.

Take Enron's leadership, who responded to mounting evidence of their accounting "creativity" by essentially saying "Have you seen our stock price?" right up until the moment they became a case study in business schools about how to spectacularly implode.

This anecdote is really giving me the urge to create a Delaware C Corp called Chewbacca. Hats off to you, Andy Fastow. That was cool. I’m going to name my next startup Death Star.

Or Elizabeth Holmes, who dealt with questions about Theranos's blood testing accuracy by... doing more blood testing demos. It's like responding to your house being on fire by turning up the thermostat and insisting it's just getting cozy in here.

Now, there are also those… special… individuals—in any culture, especially Amazon—who believe that the primary reason they're eligible for L7/L8/L10 compensation is because they can, declare with great dramatic flair, in front of the most senior group they can assemble, declare "No son, your house is on fire!" without offering a single constructive idea on how to put out any of these so-called fires.

There is a special place in hell for finance leaders who proclaim “we need to sell more” without offering a single clue as to how - as though that is like a magical, deep, f*cking insight.

These are the people who've weaponized pattern recognition into a performance art, who can spot problems from orbit but couldn't find a solution if it came with assembly instructions and a YouTube tutorial. Yeah, f*ck them.

It's better to not give a f*ck about impressing these individuals and get ahead of their inevitable pronouncements of doom by actually, you know, solving things and admitting when you can’t.

Servant Leadership vs. High Standards: The Eternal Wrestling Match

Here's where it gets philosophically interesting, and by "philosophically interesting," I mean "existentially terrifying." Amazon introduces tension by simultaneously challenging leaders with both "Earn Trust" and "Have Backbone; Disagree and Commit."

It's like being told to be simultaneously Switzerland and... well, not Switzerland.

You're supposed to be a servant leader—humble, supportive, focused on removing obstacles for your team. But you're also supposed to maintain incredibly high standards and set clear, uncompromising direction. It's like being asked to be both the supportive parent who believes in you no matter what and the coach who makes you run sprints until you can taste your own disappointment.

I've found the solution is what I call "Compassionate Relentlessness." You care deeply about your people while being absolutely unforgiving about the mission. You'll move mountains to help someone succeed, but you won't move the deadline. You'll provide every resource, every bit of guidance, every ounce of support—and then you'll still expect excellence.

It's like being a therapist with quarterly goals—or a Google manager trying to balance psychological safety with their infamous "Googleyness" bar, which somehow manages to be both inclusive and exclusionary at the same time.

Word of caution: don't try to apply Compassionate Relentlessness to your spouse. I tried it once with my half-Filipino wife and am lucky to have come out of it with all of my limbs and spherical organs intact.

Turns out "I care deeply about you while being absolutely unforgiving about the mission of taking out the trash" is not relationship advice that translates well from the office to the home.

I still remember trying to bar raise the Customer Obsession of the mattress delivery guy who couldn't fit a new Favre-f**king Tempur-Pedic mattress through my front door.

Side note: invest in a Tempur-Pedic if you're an Amazon GM (or GM Delegate)—it truly does feel good on your ass when you get the fiftieth GM delegate page at 2 AM because EC2 blew up in the tiniest region in the world because they lost air conditioning in some datacenter deployed in the Vietcong-owned rainforest.

The Great Agile-Waterfall Paradox

And then there's agile. Oh, agile. Everybody loves agile methodologies, especially your baby-faced junior software development manager (or TPM) who gives you a theological agile lecture right before you go into your Andy "roadmap review.”

Sympathy hint: he's really not going to help you with your roadmap,

“Sid, it is absolutely unacceptable to really plan what you're going to ship in the next, I dunno, five minutes or five days,” he says to you.

And how it violates their sensibilities and human rights to be able to forecast what features they will ship beyond the length of their current sprint.

We have daily standups, sprint planning, retrospectives, story points, velocity tracking, burn-down charts, and enough SIM tickets to power a small renewable energy initiative.

Microsoft has its "One Week" iterations and quarterly business reviews that somehow always require you to commit to shipping features you haven't even designed yet.

Google has OKRs that change faster than their messaging app strategy, which is saying something.

But here's what's hilarious—and by hilarious, I mean "the kind of cosmic irony that makes you question the nature of existence"—leadership always, always drives a waterfall objective and mentality, regardless of whether you're dealing with Amazon's narrative culture, Google's data-driven everything, or Microsoft's consensus-building ceremonies that would make the United Nations jealous.

"We need to be agile!" they say. "Iterate quickly! Fail fast! Embrace uncertainty!"

And then, literally in the next breath: "So when exactly will this be done? And can we get a timeline for the timeline? Also, we promised the board we'd have this by Q3, so that's not really negotiable, but make sure you're being agile about it."

It's like being told to improvise a jazz solo, but also stick to the sheet music. You must be spontaneous, yet follow the script, and embrace change while hitting every predetermined milestone.

The only difference is whether you're failing to hit your sprint commitments, missing your OKR targets, or disappointing your stakeholders in your quarterly business review—the fundamental contradiction remains the same across all these organizations that have gone from good to great (uh oh, get it, I said good to great, cookie please).

I've learned to navigate this by developing what I call "Schrödinger's TPM Methodology"—we're simultaneously agile and waterfall until leadership observes our process, at which point we collapse into whichever state they want to see. It's quantum project management, and yes, it's exactly as exhausting as it sounds. It’s superposition meets assume the position.

Final hint on the Great Agile-Waterfall Paradox: stop giving a fck about agile principles and religion. The only religion you should adopt is the religious beliefs of your choice (which are wrong) and my belief (which is right) that there is only one God and God sent his only son down from heaven to absolve you of your sins (of which you have many), and trust me, you will commit many sins as a leader. Just get over it and stop giving a f*ck.

Amazon vs. The Catholic Church: A Theological Comparison

Speaking of religion, Amazon bears a striking resemblance to the Church (wait, there is more than one), with one key theological difference: one organization is focused on saving souls. In contrast, the other is focused on making sure little Jimmy gets his Barney the Dinosaur f**king tricycle on time. Everyday Low Prices™️ meets Same-Day Delivery™️.

Trust me, bro, I don’t hate the f***ing purple dinosaur.

Both have deeply entrenched hierarchies, unwavering faith in their core principles, and the ability to make grown adults confess their sins in public forums (retrospectives vs. confession booths—same energy, different lighting).

Both have sacred texts that everyone claims to follow but interprets differently depending on their level in the organization. The Catholic Church has the Bible; Amazon has the Leadership Principles, and let me tell you, I've seen people debate the true meaning of "Customer Obsession" with the same fervor that medieval theologians argued about how many angels could dance on the head of a pin.

The Church has its mass, who is accepted into communion, and how to go from padre to cardinal.

Amazon has its WBR, top grading, promotion documents, and hiring process. I wrote another blog comparing cultural DNA replication across the two organizations. Yes, you sicko, they replicate cultural DNA without actually, you know, fu*king.

Both organizations also have their versions of papal infallibility—except instead of pronouncements on faith and morals, we get pronouncements on why this quarter's terrible metrics are actually a sign of our long-term strategic brilliance. And both require you to have unwavering faith in the mission, even when that mission seems to involve an awful lot of suffering for the greater good.

The main difference is that when the Catholic Church asks you to sacrifice for others, it is referring to eternal salvation. When Amazon asks you to sacrifice for others, they're talking about ensuring that Karen in Ohio gets her organic dog treats before she has to go to a store, like some kind of medieval paisan.

I suspect, but lack data, that these patterns—much like the Catholic Church—exist in any big tech environment: FANG, FAANG, FAAANVBDFG, or whatever the f*ck they're calling it these days. The names change, the acronyms multiply like organizational chart boxes, but the fundamental dynamics remain the same: hierarchical structures, sacred principles, and the unwavering belief that your particular flavor of technological salvation is worth dedicating your life to.

The Leadership F*ck Budget

So here's what I've learned about not giving a fck in engineering leadership: you have a finite number of fcks to give, like a monthly budget, but for caring. Amazon likes to call this "Attention Units." These sound like something a therapist would charge by the hour. Or a currency you'd use to buy focus in some dystopian workplace where your ability to concentrate has been monetized.

"Sorry, I can't attend your meeting about optimizing our meeting optimization process—I'm down to my last three f*cking Attention Units and I need to save them for something that actually matters."

And just like a real budget, you're going to overspend on stupid things and then have nothing left for what actually matters.

For example, in my first year at Amazon, boy, did I overspend attention units on a systems engineer who had no chance in hell of ever meeting the leadership principle bar.

His "Bias for Action" either swung from one extreme of looking like an overdose of Haldol (otherwise known as Haloperidol) to another extreme of executing a change on a tier 0 system the night before Black Friday without a MCM. There's a sweet spot between catatonic indecision and reckless endangerment of global commerce, and somehow this individual managed to miss it by several zip codes.

I spent months trying to coach this person, attending every 1:1, crafting detailed development plans, providing constant feedback—it was like Sting being able to f*ck for days on end without having an orgasm.

Now, my young apprentice, this would be an example of giving a f*ck way too much.

Sometimes you need to recognize when you're putting in maximum effort for minimal results and redirect that energy somewhere it can actually make a difference.

You cannot care equally about everything. You cannot fight every battle. You cannot fix every process, attend every meeting, satisfy every stakeholder, and still have the mental energy to lead effectively.

The secret is strategic f*ck allocation. Care intensely about your people's growth. Care deeply about technical excellence. Care passionately about customer impact.

But that meeting about updating the meeting cadence for the working group that's reviewing the committee's recommendation about standardizing our standardization standards? That's a hard pass.

The Subtle Art of Not Giving a F*ck About Feedback

Speaking of strategic allocation, let's talk about the zillion pieces of feedback you'll receive on every narrative or PR/FAQ. Do not accept all feedback uniformly.

This is critical: not all feedback is created equal, despite what your kindergarten teacher told you about everyone's opinion being special.

Frankly, the only three people whose feedback actually matters are the person who asked for the meeting, Andy (or whoever the senior-most person reviewing it will be), and your boss.

God help you if all three of those people are the same person (actually no, I don’t give a f*ck about you, you’re getting paid enough to deal with it). Maybe you do need to give a fck then, I dunno, because I died on the battlefield of fcks way before reaching that level of organizational complexity.

Everyone else's feedback falls into the category of "interesting perspective, thanks for sharing," followed by the strategic filing of said feedback in the circular receptacle next to your desk. Yes, I'm sure the L5 engineer has very strong opinions about taking a Flagship S-Team goal to eliminate the need for them to carry a pager, and I'm equally sure that accommodating those opinions will not materially impact the success of this initiative.

The Conclusion (Or: How to End a Blog Post Without Actually Concluding Anything)

Now, let me be clear about something: I haven't exactly mastered the subtle art of not giving a f*ck yet. You see that I was being vocally self-critical early.

Good puppy. Does puppy want a treat?

No, sir, I have a long way to go towards learning that, although my good friend Rob Francis would say at least I'm admitting the problem. Which is the first step towards healing—admitting you have a problem.

"Hi, my name is Sid Rao, and I still give a f*ck."

"Hi Sid," drones my support group in response.

And they're right. I care about everything. I care about the font choice in our design docs. I care about whether we're using the Oxford comma consistently in our commit messages. I care about the strategic implications of our microservice naming conventions. I probably care more about a team's code review response time than I care about my own sleep schedule, which explains why I'm writing this blog post at 11:47 PM on a Sunday.

After ten years at Amazon and twenty years of leading tech teams, I've realized that engineering leadership isn't about having all the answers—it's about slowly, painfully learning which questions actually matter.

It's about being comfortable with contradictions, skilled at managing paradoxes, and somehow maintaining your sanity. At the same time, everyone around you acts as if software development is a predictable, linear process that can be managed with spreadsheets and positive thinking.

The subtle art of not giving a f*ck in engineering leadership is really about giving the right f*cks at the right time to the right people for the right reasons. Everything else? That's just noise.

But here's the thing—I'm still learning to distinguish between the symphony and the static. I'm still that person who reads every single comment in the code review, who stays up thinking about whether we should have chosen a different architectural pattern, who genuinely worries about whether the team feels psychologically safe enough to tell me when I'm being an idiot.

And that’s OK. Cause who gives a f*ck.

Maybe that's not entirely a bad thing. Maybe caring too much is better than caring too little. Maybe the goal isn't to stop giving a fck, but to give fcks more strategically, more intentionally, more effectively.

Work in progress.

Very much work in progress.

Send help.

An Epilogue

And just remember, motherf**kers, all these people are fu*king people.

Not drones.

Not whatever they named that motherf**king dorky Amazon bot Peckie. They aren't all powered by Claude (just a few of them are).

Take care of your people and they will, for the most part, take care of you.

And when they don't, cut them a COE.

But seriously f*ckers, we all are living under the bar of the human condition first, then some f*cking bar you invented the night before the ops review.

Peace, Love, and Fuck Off.