Ryan Drapeau

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

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

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'm sure there are a few of you out there wondering what I have been up to since I left Cadence. I was lucky enough to join a terrific startup called Metrics Design Automation. I’d like to tell you how wonderful our products are, but it would be better if you saw for yourself. If you have any interest in simulation, please go to www.metrics.ca and check it out! While you're there, watch a couple of the videos we put together that show you how easy it is to get started with DSim.

29

1 Comment

In this world of ongoing layoffs, companies going against the grain to build highly customized in-house tech stacks that don't track to the skills and expertise engineers need for their past and future jobs will find themselves becoming a black hole devoid of talent. The ones who are good enough to leave will, and the ones who aren't will feel stuck because their work isn't advancing their skills in a way that adds to their value as an employee.

13

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

In a few days, I'll have spent 10 years at Amazon. Why do I stay? I had a job satisfaction rubric when I started here:  1. Peers  2. Manager  3. Compensation  4. Subject Matter I thought that if I could hit all of these I'd be happy--and for the most part I have hit them; and I've been happy. But as my career progressed I noticed something new that was missing from my rubric: for the first time I was able to be my authentic self--and that self was successful! As time has gone on, I've come to value this one aspect above the original four. Reflecting on my tenure, me from 10 years ago would be shocked by the this post's opening. When I applied, I was convinced I'd never be hired; and when I was hired, I was convinced that I'd never see my sign on RSUs vest--I had done my homework and was aware of the short median lifespan. But the anecdotes I was quickly amassing were at conflict with everything I thought I knew about Amazon. My manager had been there 10 years, a couple of my peers 5, and I never saw anyone crying at their desk (much to the relief of my parents). Rather things went well. My first surprise was to discover that my coworkers universally did what they said they'd do. More so, what I naturally did was often right, whether that was disagreeing in a meeting, or diving deep into some bug in a service I did not own; I was rewarded for following my instincts. This lead to my own personal virtuous cycle: the more I was myself, the more encouraged I'd be to be that self. Of all the satisfaction criteria, this is the one that keeps me excited to stay and continue growing. This leads me to be super curious about others. What keeps you where you are? (10 year cake is--of course--a figment of AI) #amazon #careers

165

17 Comments

"Your main job is to make your product win." I think this should apply to any product that your company makes. I also like what he says following this statement about what is NOT your main job. I will summarize here: "Your main job is not to make your manager happy, it is not to make execs happy." Also, note, this main job doesn't only apply to PMs, but also to senior Engineering Managers, Tech Leads, and Designers. #makeyourproductwin #leadership

5

2 Comments

"Build in primitives" -Andy Jassy, #Amazon CEO https://lnkd.in/gHMYt7NX Happen to take the time to read this year's Annual investor letter from Andy Jassy. Deep in 2nd half, it talks about how Amazon started thinking about "building in primitives" and how it has been game-changing for them and their customers. Probably old news for some, but eye-opening for me. Definitely a good read!

2

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

Distinguished Engineers (E9) at Meta make $4m/year. That's 16x the Bay Area median ($255k) Let's break it down [output = input x leverage] We all have 24 hours in a day, so there is a cap on [input] But hey, let's say they manage to have 2x-3x more focused time, so their [input] is 2x-3x There is still 5.3x-8x to go And that's [leverage] Here is the [leverage] they have: 1️⃣ Writing Every piece of text they write is clear to everyone, and they write a lot, for a lot of people 2️⃣ They create something from nothing And that something has clear value to the business 3️⃣ They influence other Engineers around them They are often described as having a "Midas Touch" in terms of their ability to uplift and develop other Engineers around them The best indicator is that the Engineers in their teams get promoted faster 4️⃣ They are well known and have an impact beyond Meta, promoting the brand 5️⃣ They have industry-leading experience in some areas There are rumoured to be <50 E9s at Meta

13

1 Comment

Want to tease something my team has been working on over at Buffer! The attached image isn't a mockup, but a screenshot of a live prototype of RSS feeds directly in Buffer! It's only available internally and still pretty rough at this point, but we'll have it available for user testing soon. With this enhancement, we hope to help Buffer users easily find new and engaging content to share with their audiences. What do you think? Will RSS feeds in Buffer help you create more content?

19

1 Comment

Whenever I get "worried" that an LLM will take my job as a SWE in the near future I look back at this benchmark leader board of real-world issues and am reminded that LLMs have been stuck at making marginal improvements bellow 20% resolved rate for over a year now. That being said, I do think AI will become an increasingly powerful tool in a SWEs belt in the coming years if it hasn't become one already. I personally use it to help me explore a problem space faster and come up with boilerplate for trivial problems and expand from there. In those cases it's like using Google and Stack Overflow and other forums, but faster. Edit: I'd like to also point out that I really like this benchmark because you cannot train a model on it unlike HumanEval. It's in essence, a true test of an llms ability to generalize and solve problems. Source: https://lnkd.in/epK2GQ2w

2

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

I will steal what Ian Jiang, iOS principal engineer, wrote about this. "There are more than 2 million apps on the app store and only around 2500 apps been made App of The Day since the feature was introduced in the revamped iOS App Store in Sep 2017. And now we're one of them. We should really be proud of what we've achieved!" I sincerely believe that Domain currently has the best Australian real estate App currently in market. That recognition by Apple is the tip of the iceberg of why I believe that. There is a lot I could share about how we got here but I will only share a few: 1. It takes a massive effort for everyone involved - it's years of investment in the making with a few big steps that require some leadership buy-in and many small steps that require constant commitment to quality from the team. In UX, we frequently talk about "death by a thousand cuts". The opposite is also true: a win by a thousand small fixes. 2. It takes a high functioning team with an insanely strong collaboration between product, tech and design. 3. It requires to live in the future (what should we build next, what problems we solve next, how we differentiate, what insights do we have that our competitors do not have) and the present (what problems are users facing right now, what usability issues do we have, what technical problems are blocking us now). 4. It requires to be very open and in constant communication with our users in many ways: usability testing, answering to reviews, consumer listening sessions https://lnkd.in/gDJBJEzn I cannot write this without mentioning Matias Emiliano Di Giovanni and Leigh Masson, who are behind all of this a lot more than anyone else, especially me.

67

6 Comments