Igor Dvorkin

What does it feel like to be an engineering manager at Amazon: Since the RTO announcement it became popular to write shit about Amazon, but it's still one of the best companies around the world. A few weeks ago, Gilad Naor shared with the 'Leading Developers' readers 3 lessons from his time as an engineering manager at Amazon. Here is the first one, read the full article here: https://lnkd.in/dHBxv2Ha 𝟭. 𝗦𝗼𝗹𝘃𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀 𝘄𝗶𝘁𝗵 𝗺𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺𝘀 My first meeting at Amazon was baffling. I entered a room with about a dozen Software Development Managers (SDMs) and Product Managers (PMs). Everyone sat in silence and looked at their laptops or the printed papers they had before them. It was my second day at Amazon, and I picked up one of the extra sheets and started reading. After those first ten awkward minutes, everyone finished reading and the meeting began. Why do Amazon meetings always start this way? This is a specific example of how Amazon approaches problem-solving. It is the "Good Intentions Don't Matter" approach. In a famous internal video, Jeff Bezos talks about why good intentions are irrelevant. When things don't work, it does not matter what people wanted. All that matters is fixing the problems with mechanisms. For example, many busy managers come to meetings without first reading the prep material. They all intended to read the 6-Pager before the meeting. They just got sidetracked by the latest emergency. Scolding the managers won't solve the problem. A mechanism will. This is why all Amazon meetings start with a study period. The remaining meeting time is then spent on high-quality decision-making. Meta solves the same problem by creating cultural norms. I can't count the number of times that I heard a senior leader cut off the presenter: "Stop, assume that everyone here already read the slides. Let's get to the point." This is a culture-first approach. I have seen this work well in some teams, and not work at all in other teams. At Amazon, the solution is part of the company's "operating system". ------------------------- Anton here - by now everyone is familiar with the 6-pager concept, but that "operating system" thinking can be used almost anywhere. Think about something annoying that your developers do, and how can you solve it. For example, I remember being annoyed that people don’t update the Jira tickets. Finally, after requesting multiple times, now we just take 20 seconds from the standup to update them.

56

8 Comments

I first joined Amazon in December of 2005. Even though I left for two years, my "Amaversary" still coincides with the end of the year and a natural moment for reflection. As I reached my 17 year mark this December, I also had the privilege of working with Amazon Careers to share some of my journey and thoughts about individual contributor technical leader and people manager career paths. In my ruminating, I put together far more content than could be used for a single article. So, I've decided to post here as a series of Q&As - in case others might find my observations, experiences, and perspectives interesting or useful. Below is the first of 6. 1. 𝘽𝙧𝙞𝙚𝙛𝙡𝙮 𝙨𝙝𝙖𝙧𝙚 𝙮𝙤𝙪𝙧 𝙘𝙖𝙧𝙚𝙚𝙧 𝙟𝙤𝙪𝙧𝙣𝙚𝙮; 𝙬𝙝𝙖𝙩 𝙢𝙤𝙩𝙞𝙫𝙖𝙩𝙚𝙙 𝙮𝙤𝙪 𝙩𝙤 𝙩𝙖𝙠𝙚 𝙤𝙣 𝙙𝙞𝙛𝙛𝙚𝙧𝙞𝙣𝙜 𝙘𝙖𝙧𝙚𝙚𝙧 𝙥𝙖𝙩𝙝𝙨, 𝙄𝘾 𝙫𝙨 𝙢𝙖𝙣𝙖𝙜𝙚𝙧? I started my career as a software engineer 25 years ago. I've worked for startups, enterprise companies, and 7 different organizations over 17 years and two tours at Amazon. I've written firmware for robotic camera mounts; built highly scalable distributed systems; designed restaurant marketing, ordering, logistics, and operations software; created automated test harnesses for mobile games; tested HD DVD encoding; helped launch grocery delivery to customers around the globe - just to name a few of the many cool things I've had the privilege to work on. I've been an entry-level software engineer, a technical lead of teams, a software manager on a couple of occasions, chief software architect reporting to a CTO, and (for the last few years) Amazon Principal Engineer directly supporting a VP with about 200 engineers within my remit. I first became a manager because I mistakenly thought it was the only way to continue growing as a leader, and in many ways I failed. I learned some very humbling lessons about leadership through that experience, which I used to be a better individual contributor technical leader on my path to Senior Engineer. My second time as manager was because my organization had a need that I could fill. I had grown enough as a leader that this time I was much more successful. I said yes to an opportunity that started with managing a small team through delivery of a complex and critical project. Once I grew a high performing team that delivered that initial project, I took on more scope and expanded into multiple teams. After a couple of years of success growing and investing in my teams so that we could deliver greater value to our customers and business, I decided to prioritize being close to my family. For me, at that time, it meant giving up my people management role and returning to the role of an individual contributor technical leader that supports a globally distributed organization. Even though I really enjoyed my time as a people manager, there is no better job for me than that of a Principal Engineer. #amazon #careerdevelopment #technicalleadership #peoplemanagement

91

3 Comments

While there are certainly individual variations in skill and experience when discussing modern software development the story is much more nuanced than pure individual effort.  * software development is a team sport -- individual performance is heavily impacted by the system in which they are asked to operate in.  * we pair skill and experience to this model of understanding performance by expecting people to be able to influence and adapt in direct proportion to their seniority, aka the more senior you are the more responsible you are for the outcomes of your work, the less senior you are the more your manager and management chain are responsible.  * humans want to succeed, we're social animals who derive purpose from demonstrating skill, and working collectively. All of which is to say there is no way you have over 1000 people underperforming at your company without senior leadership deeply implicated in.  If nearly 10% of your company is failing, versus just having the market move against you, you need to fire the CEO.

150

9 Comments

I just realized: we should start saying "build memoization" rather than "build caching." We aren't really talking about least-recently-used or time-to-live algorithms, we're talking about "don't bother recompiling this piece if none of its inputs changed." (It has been puzzling me that some people are so deeply fearful of "build cache" as a concept, and honestly I think it's mostly because most build systems have non-hermetic state scattered all over the place. Maybe a slightly more precise term for the type of caching we're concerned with would clarify the semantics in question.)

83

9 Comments

📚 My Book-Of-The-Month for October was "Working Backwards: Insights, Stories, and Secrets from Inside Amazon" by Colin Bryar and Bill Carr, former Amazon executives that I overlapped with 📚 It wasn’t until I left Amazon in 2020 and spent 4 years at Google that I realized that all the things I took for granted and considered *common sense* at Amazon didn’t necessarily exist outside Amazon. Jeff is disciplined, so Amazon is disciplined. Jeff and the early s-team encoded a number of mechanisms to ensure Amazon’s core DNA would survive the massive scale that it faced: inspection mechanisms like WBR/MBR/QBR, planning mechanisms like OP1/OP2, hiring mechanisms like the Bar Raising program, and of course the crisp encoding of the Leadership Principles and their ubiquity in everyday life. For all of Amazon’s existence we operated on thin margins, so we needed that discipline and efficiency to survive. If you invented a time machine and transported the 2009 Carlos to 2024, he would recognize Amazon and feel right at home. Yes Amazon 2009 was more of an adolescent amazon and Amazon 2024 is more of a grown-up amazon but the core DNA is still very much there and recognizable. I truly believe that Amazon is an exceptional place to work - not because of the perks and pampering (hum, there's never been many of those LOL), but because of the environment around you. #bookofthemonth #carlosbookofthemonth

257

23 Comments

Waymo is probably both more expensive and longer waits on average than Uber or Lyft today, but they are close enough, and rapidly getting better. These markets will flip to fully autonomous when the tech is ready.

2

Amazon-to-Google-to-Amazon #a2g2a thought of the day: interesting to see how RTO (Return-to-Office) outcomes are entirely different for the two companies. In my post today, I don't really want to go down the path of debating whether RTO is "good" or "bad". There's very emotional and valid opinions on both sides, and it affects people's personal lives in real ways. Please be respectful. Whether you agree with the policy or not, for it to actually work it does need *critical mass*. Both companies have essentially the same RTO policy (3 days/week expectation), but there's significant differences is in how the message was delivered and enforced - and the outcome. Google’s 3-days-per-week was mostly a “pretty-please, would-you, if-you-don't-mind” with no actual enforcement (but some vague threats). So most people ignored it. They still do. Leadership got frustrated and the message got less polite over time, but nothing really changed. Even as of 3 weeks ago, when I was still a Google employee, the buildings were fairly empty. That made being physically in the office significantly less useful, other than enjoying the perks of free food and massages by myself (and occasionally with 1 or 2 coworkers). Amazon’s 3-days-per-week came with actual enforcement. Amazon used badge reader data to track when people were actually coming to the office, with consequences. It does feel a bit draconian, but you can’t argue with the effectiveness of saying “we have a policy that we believe is business-critical and we’ll enforce it or else.” I appreciate that when I come to the office, I can find my coworkers there and we can have f2f meetings. There’s critical mass for RTO to actually be effective. Amazon has picked a lane. Personally, I have not figured out how to truly be productive and happy working remotely in the last 4 years. I respect and appreciate the fact that some people have, but I haven’t. I do like the option to stay home a day or two, skipping my long commute, working from a lounge chair in my backyard on a sunny day. But there’s nothing like the energy in the room of a good group meeting, or the chemistry of a face-to-face 1:1, or the enthusiasm of two engineers standing in front of a physical whiteboard drawing boxes and arrows with markers brainstorming about the future. Or the bonding of sharing a meal or a walk between buildings with a coworker. I feel energized when I’m physically in the office. It literally charges my batteries. I’ve been coming to the office 4x/week and loving it. 

183

34 Comments

Check out the latest in our "Debuggability" blog series! This blog is authored by Kevin Downey Jason Johl and me and talks about how we built a Debuggability Paved Road at Intuit using Ephemeral Containers and Argo Workflows. We'd love to hear your thoughts on the topic. Also, what tools do you build as-a-platform to help debug service, compute and network issues in Kubernetes at scale? #intuit #kubernetes #debug

23

Hey everyone, I am an investor and advisor to Katanemo.... They are reinventing the infrastructure primitives for GenAI and launched Arch - https://lnkd.in/gCrbbkEV - an intelligent prompt gateway. Give the project a look on Github, and star the project if it resonates

88

3 Comments

Why Amazon's RTO Policy Misses the Mark: A Growing Opportunity for Software Engineers Amazon’s return-to-office (RTO) policy has sparked heated debates, with leadership asserting that face-to-face collaboration enhances efficiency and innovation. While that may hold true in certain contexts, in a global company as vast as Amazon, the policy feels increasingly out of touch with the realities of modern, distributed teams. Think about it: At Amazon, you're often not collaborating with people in the same room—or even the same continent. Your team might be spread across Seattle, India, and Europe, necessitating virtual meetings regardless of where you log in. Even when everyone is in the same city, logistics like elevator delays in a packed high-rise mean it’s often faster to join a video call from your desk, whether at home or in an office cubicle. So what purpose does mandatory office attendance serve? It doesn't address the core challenges of remote collaboration. Companies like Microsoft are setting an example by investing in tools and systems that enable seamless virtual teamwork, acknowledging the inherently global nature of modern businesses. The irony of Amazon's RTO push is that it’s creating an unintended side effect: more engineers are actively seeking new opportunities. Talented professionals value flexibility and work-life balance, and policies that disregard these priorities push them to consider employers who embrace hybrid or fully remote work. If you’re contemplating your next move but concerned about confidentiality, platforms like Mirajobs offer a solution. Their tagline, “Search for a new job without your SDM knowing,” reflects their mission of enabling anonymous job searches. Platforms like this protect your identity while you explore roles that align better with your personal and professional values. You can engage with recruiters discreetly, without the risk of jeopardizing your current position. Amazon's RTO mandate is a wake-up call for professionals and companies alike. For engineers, it’s a chance to reflect on what work environment best supports their growth. For employers, it’s a reminder that talent retention requires more than just policies—it requires trust, flexibility, and a genuine understanding of how work gets done in a globalized world. What are your thoughts? Are rigid RTO policies the solution to collaboration challenges, or do they simply drive top talent to seek greener pastures? Let’s discuss! #amazon #RTO #anonymousjobsearch #techcareer #faang

8

1 Comment

"Over 25% of all new code at Google is now generated by AI", according to CEO Sundar Pichai in today's earnings call. But is this shift aimed at speeding up the development of complex software, or simply cutting engineering costs? One potential indicator will be if Google reduces headcount by 25% while boosting revenue per employee. Here are some details behind this productivity metric in Google's own research page . Majority of this '25% code' is in the area of code completion, not in code creation. "LLM-based inline code completion is the most popular application of AI applied to software development..." Watch the video to understand further on this metric.

16

3 Comments

🍜Anybody up for some ramen? I am excited to share that I am back in the garage, building again (it’s actually a house in the Berkeley Hills). We are taking the wraps off of Supercog AI, a new startup focused on solving Application Integration using LLM powered agents. My co-founder in this new venture is a great friend of mine (and a former co-founder partner), Alex Osborne. Alex and I have worked around the application integration space for a long time, and we are unrealistically excited about applying the GenAI stack to this problem. Not many people relish the task to get some bits to move from system A to system B. But it’s a critical job to be done, and that’s led to a lot of brittle scripts, a myriad of inflexible “no code” tools, and a lot of hand crafted SQL. But the power of the Large Language Model, trained on a huge corpus of information, offers a remarkable tool to solve this problem. The LLM you use today already knows the APIs of hundreds of popular systems. It knows the SQL dialects of every major database. It understands the semantics and data schemas of many popular SaaS systems. It understands much of the specific domain in which your business operates. I like to call the AI revolution “the last platform shift”. That may turn out to be hyperbole, but I definitely believe we are in the very early stages of seeing what this new stack can enable. I know we are hardly the first folks to claim that “amazing stuff is coming!”. But this is why Alex and I have decided to focus on a real and hard problem. If we can prove that LLMs can power a new way to solve this problem, it will be the first successful *new* approach in 15 years.. We will have much more to share about this new platform soon. In the meantime, if you’re interested in getting a peek - or even better if you have application or data integration tasks that you would like some help with - please reach out because we want to help. #genai #startups #backinthegarage

164

37 Comments

My Journey to Securing 7 Offers for Management and IC Roles Across FAANG and Startups I’ve been considering opportunities beyond Amazon since 2020, but I was fortunate to be offered enriching experiences year after year, which kept me from making the leap. By early 2024, after laying the foundations for AWS App Studio, I decided to explore other roles within #Amazon. However, I realized that Amazon’s presence in the Bay Area was shrinking, and with its #RTO policies, the management opportunities in #bayarea were limited to just a few roles, none of which aligned with my interests and goals. A combination of limited internal opportunities, and changes in Amazon culture and policies, motivated me to explore external options. Initially, I had two interviews with a FAANG company and a startup, but I failed them miserably. Securing new interviews proved difficult due to factors like scarce roles, high competition, and increasing expectations in both technical and people-management skills. I quickly realized I needed to make every interview count by preparing more methodically and strategically. In a future post, I’ll dive into how I: a) Adjusted my job search to land new interviews consistently b) Staggered my interview timeline to maximize preparedness and increase the likelihood of receiving multiple offers c) Prepped for technical skills, as many companies now expect managers to be as technically competent as senior engineers I also decided to interview for individual contributor (IC) roles for several reasons: a) I’m still hands-on with my side projects b) Companies are reducing management layers c) I enjoy both IC and management roles d) Compensation for ICs at some companies can be higher than for managers at others e) Since I was preparing for technical interviews anyway, I figured I might as well explore IC opportunities too I segmented my job search into four categories: Startup/FAANG and IC/Management, staggering my applications to focus on startups first and then #FAANG. This approach created an avalanche effect: I started receiving IC and management offers from startups, followed by multiple FAANG offers across both IC and management roles. Here are the benefits of this approach: a) I was able to fairly evaluate startup opportunities without bias toward cash components. One startup came close to winning me over, but by that point, I had FAANG offers and ultimately decided to pursue those. b) I gave myself a chance to objectively reconsider an IC role, as I’m still mid-career c) I ensured that for any managerial role I considered, the company culture and its policies aligned well with my values. d) This approach helped me negotiate effectively and secure a top-of-market compensation package. e) I was at my best in the final interviews (both FAANG and startups) after having multiple real-world practice sessions with other companies.

40

6 Comments

Your ability to adapt to changing conditions will be your super power. Being overly adapted to existing conditions makes survival questionable.

5

1 Comment

That's wild 🤯. Meta & Google is still on mono repo in 2024. I suppose it's more cost effective for both companies to re-engineer Mercurial & Perforce (respectively as "Sapling" & "Piper") & build custom development tooling, than to change their workflow for all of their engineers. In the case of Meta: a standard git merge operation would have taken 45 minutes. Legends has it, they consulted the Git team & was told to break up their repo. So instead, they went to the Mercurial team & got a better reception. Here's a perspective from one of their engineer. But wait... 🤔 the source code for Sapling & Piper + all of its IDEs & build tools are (probably) not store in the same repo? For sure with Meta Sappling, it's not (you can find it on GitHub). Same story with Android. These repos have totally separate concern domains 🤓 I get it. So maybe, it's "mono-repos" & :. truly, no actual mono repo 😅 With the collective wisdom of the Meta & Google engineering teams (combined!), who am I to judge 🫠

5

1 Comment