Dhiraj Borade

When I first moved from IC to manager at Amazon, the hardest thing was letting go of doing everything myself, especially when I took over manager role in the same team where I was operating as individual contributor. As ICs, we get rewarded for solving problems directly. As managers, success depends on enabling others to solve them. That shift feels unnatural at first. As manager you are doing everything backstage to setup your team for success. Your success depends on your ability to force mulitply yourself consistently and repeatedly. Navigating It: • One path is micro-managing: you still feel “in control,” but your team loses trust and creativity. • Another is disappearing: you stop diving in, but your team feels abandoned. • The sweet spot is being a coach—close enough to guide, distant enough to let them own outcomes. Pros/Cons of Approaches: • Micro-manage → ✅ quick results, ❌ long-term team frustration • Hands-off completely → ✅ team feels trusted, ❌ risk of chaos • Coach → ✅ sustainable growth, ❌ requires patience and conscious effort Actionable Tips: • In your next 1:1, ask: “What decisions do you feel comfortable owning without me?” • When tempted to jump in, pause and ask: “Is this a growth moment for them, or a rescue mission for me?” 👉 What was your biggest struggle in “letting go”? Share in comments—and tag a friend stepping into management!

52

10 Comments

Amazon Layoffs Incoming — And This Time, It's Principal Engineers Rumors[1] are circulating that Amazon is preparing another round of layoffs — and what's especially striking is that principal engineers are among those being targeted. This is a sharp reminder that: - Being senior doesn't make you immune to layoffs - As you climb the eng ladder (which is just another term for the corp ladder), you have to sustain your performance/impact, so cruising is not an option compared to common beliefs - Companies are entities that try to maximize revenue/profits – being laid off sucks, especially if you're on parental leave (or any kind of leave), on a precarious visa situation etc. I think we have seen enough layoffs in tech companies that these are probably the new normal. Companies who struggle to fire people through a regular process, will rely on layoffs to occasionally clean house. This sucks.

503

35 Comments

How I Made Decisions at Amazon In 5.5 years at Amazon, I made thousands of decisions. Some were small. Scope tweaks. Deadline shifts. Meeting structure changes. Some were big. Launch calls. Escalations. Resource tradeoffs. Risk acceptance. And here’s what I learned: Indecision is usually more expensive than a wrong decision. Amazon forced me to build a decision framework…not rely on instinct alone. Here’s how I approached it: 1/ I asked: Is this a one-way door or a two-way door? ↳ A one-way door decision is hard to reverse ↳ Long-term architectural changes ↳ Big resourcing bets ↳ Major customer commitments These required deep dive, multiple perspectives, and slower motion. ↳ A two-way door decision is reversible ↳ Pilot launches ↳ Process changes ↳ Messaging experiments These required speed. Most people treat two-way doors like one-way doors. That’s how velocity dies. 2/ I defined the real risk before acting ↳ What’s the worst-case outcome? ↳ How recoverable is it? ↳ What’s the cost of waiting? Often the cost of delay was greater than the cost of being imperfect 3/ I gathered just enough signal…not perfect clarity ↳ 70% confidence was often enough ↳ The remaining 30% came from moving ↳ Over-analysis was a hidden tax on momentum 4/ I wrote my thinking down ↳ Framing the decision in writing exposed weak assumptions ↳ It also made it easier for others to pressure test it ↳ Writing sharpened judgment 5/ I owned the outcome…even when it missed ↳ If a decision didn’t land, I didn’t blame the inputs ↳ I asked: What did I miss? What pattern did I ignore? ↳ Decisions compound…so does accountability The biggest shift Amazon gave me was this: Decisiveness is a leadership trait. But structured decisiveness is a competitive advantage. 📬 I write weekly about clarity, ownership, and high-stakes execution in The Weekly Sync: 👉 https://lnkd.in/e6qAwEFc What’s one decision you’ve been overthinking that might actually be a two-way door?

34

1 Comment

🚨 H-1B Visas: $100,000 Fee Could Reshape US Tech Hiring 🚨 Over the past few days, Trump announced a $100K fee for new H-1B visas - nearly 50x the current cost. While clarified as a one-time fee for new applicants, the ripple effects could be huge: 👉 Talent Pipeline at Risk: For 30+ years, H-1Bs have fuelled US innovation, from Silicon Valley startups to hospitals. With 70% of H-1Bs going to Indian professionals, this program’s future is suddenly uncertain. 👉 Hiring Challenges: Median salaries for new H-1Bs (~$94K) don’t even cover the fee. Expect more offshoring, remote contracting, and selective sponsorship as companies adjust. 👉 Broader Impact Universities, hospitals, and startups could face talent shortages. H-1B holders contribute ~$86B annually to the US economy - this isn’t just a visa issue, it’s a competitiveness issue. 🇺🇸 Will US companies adapt - or will innovation hubs shift elsewhere? 🇺🇸 #SoftwareEngineering #USHiring #Recruitment #Visas #OverseasTalent #H1B #TechHiring #ImmigrationPolicy #TalentPipeline #FutureOfWork

14

3 Comments

At 3 AM on a Wednesday, Amazon needed me. I wasn’t even on that team anymore. Back when I was an SDE at Amazon, a Sev-2 had hit one of our services. Many customers were impacted. The team had been chasing it for hours. Still, they called me. I rolled out of bed, opened my laptop, and joined the bridge. The tricky part was that the fault started a week earlier. A code change had shipped behind a flag, traffic ramped slowly, and the failure signature was noisy. Logs were chatty in all the wrong places and silent where we needed them most.Dashboards showed errors, but no clear line to the root. We did unglamorous things. We wrote a minute-by-minute timeline. We diffed deployments, configs, and flags across regions. We checked queue backlogs and retry storms. We sampled logs with new filters. We bisected the traffic ramp. We rolled back the smallest safe thing first. Then we added one log, in one hot path, and the picture snapped into focus. By sunrise, we had the root cause and a fix. The impact was contained. Customers recovered. What stayed with me was not the fix. It was why they called. They did not call because I am smarter. They called because, over months, I had done the boring work. I wrote runbooks when no one asked. I paired with juniors on their first on-call. I shared context so others could make decisions without me. I showed up when it was not my ticket. Trust is not built in one night. It is built in all the small days that come before it. Ownership is simple. If it affects your customer, it is your problem. Org charts are for payroll, not for 3 AM. If you are early in your career, remember this: → Document the weird corners when you discover them. → Add one useful log where it hurts, not twenty where it is easy. → Keep a living checklist for rollback, not a static wiki page. → Teach one person the thing you just learned. → Read your dashboards when things are calm, not only when they are red. At 3 AM, you will not rise to the occasion. You will fall to the level of your habits. Build the right ones while the house is quiet. That’s how you earn trust that lasts beyond teams and ownership that outlives org charts. A few days later, this moment turned into an accolade from the team..  a reminder that trust is built long before it’s tested :)

334

45 Comments

As an SDM at Amazon, I often hear concerns that “𝗜𝗻𝘀𝗶𝘀𝘁 𝗼𝗻 𝘁𝗵𝗲 𝗛𝗶𝗴𝗵𝗲𝘀𝘁 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱𝘀” can become a bottleneck to delivery. That hasn’t been my experience. When practiced well, this principle isn’t about adding friction at the end of the process or holding teams to vague perfection. It’s about investing in a learning culture where engineers understand 𝘄𝗵𝘆 the bar exists and are empowered to raise it themselves through better design reviews, stronger testing, and clearer ownership. High standards, when paired with strong coaching and trust, actually accelerate delivery. Teams spend less time reworking issues, firefighting in production, or debating expectations. Instead, they build confidence in what they ship and continuously improve how they build it. For me, insisting on high standards is less about saying “no” and more about helping teams learn faster, make better trade-offs, and sustainably deliver great software at scale. That’s not a bottleneck but a leverage. The real question isn’t whether to insist on high standards, but how to practice them in a way that enables teams rather than slows them down. I’ll dive into that in my next post.

23

1 Comment

BREAKING: 🇺🇲 Microsoft is laying off 9,000 employees but has already requested 14,181 new H-1B visa workers so far this year - CBS News #Microsoft #layoffs

8

1 Comment