How corporate politics actually work
With Ethan Evans, a former Amazon Vice President.
Most engineers think the best technical work wins promotions. After 15 years at Amazon, Ethan Evans will tell you it doesn’t.
He joined as a Senior Manager in 2005, helped launch what became Prime Video, and by the time he left in 2020, he was a VP running teams of over 800 across video games, the Amazon Appstore, Twitch, and Prime Gaming. Before Amazon, he was a VP at a startup by age 30, then got laid off twice from VP-level roles when his “brilliant and blunt” style stopped paying off.
That last part matters. Most of what Ethan teaches now is what he learned the hard way. He has seen promotion decisions from both sides: as the engineer who thought good work would speak for itself, and as the VP making the calls on reorgs, transfers, and scope.
What follows is the part nobody writes down. The polite fictions, the back-channeling, the early signs you’re in trouble months before HR gets involved.
In particular, we will talk about:
Who Ethan is. Engineering degrees at Carnegie Mellon and Purdue, two startup layoffs that changed how he leads, and 15 years at Amazon, ending as a VP.
The moment technical skill stopped mattering. Running QA, IT, documentation, customer service, training, and HR at a startup taught him that the job had almost nothing to do with code.
Why “best work” loses. Engineers define best as most technical. Managers reward visible impact, easy collaboration, and the people they actually like working with.
The polite fiction. Why “I have a personal commitment” sometimes means “I’m interviewing elsewhere,” and why both sides keep the fiction intact.
Where influence ends, and manipulation begins. Same tactics, different motive.
Umbrella vs. funnel managers. No manager thinks they’re a funnel. Here’s how to actually find out which one you are.
PIPs are already over before they start. The real warning signs show up months earlier, inside soft feedback most engineers hear as encouragement.
The “brilliant and blunt” excuse. Ethan was that engineer until two layoffs forced him to change.
Building relationships in remote teams. The hallway moments are gone, and you have to manufacture the rest.
Ethan fell short of his own advice. As a VP, he made decisions based on who he wanted to work with, not always who was most qualified.
The advice he wishes he could take back. Get a mentor. He explains why most mentor relationships die after two meetings, and what to do instead.
So, let’s dive in.
Auth0: First Enterprise connection is free now (Sponsored)
Every time I’ve built a B2B SaaS product, the same thing happens. A customer asks for SSO, and your auth provider suddenly wants an Enterprise contract you can’t justify. Auth0 just changed that. The Free plan now includes one Enterprise Connection, unlimited Okta connections, SCIM, and Self-Service SSO. On Essentials, you pay for M2M tokens and MFA only when you use them.
1. Can you introduce yourself and tell us a bit about your career path, from engineer to VP at Amazon?
I’m Ethan Evans, a former Amazon Vice President now running a business as a writer, teacher, and coach. My mission, which I left Amazon to pursue, is to pay forward my good fortune by helping others find both career success and satisfaction.
I was educated as a hardware and software engineer, earning a BS from Carnegie Mellon University and an MS from Purdue University. After college, I joined a series of startups in Pittsburgh, Washington, DC, and Boston. In those jobs, I very quickly became a lead engineer and then a manager. By the time I was 30, I was a Vice President at a startup, managing about 30 people.
I joined Amazon in 2005. Amazon treated titles differently from the startups I had been at, and I joined as a Senior Manager. I had the good fortune to be hired to lead a new project selling online video, which would later become Amazon Prime Video. This is the most impactful and widely known product of my career.
While working on this video product, I was promoted to Director. After that, I switched to working on video games and the Amazon Appstore. In those roles, my team eventually grew to over 800 people around the world, and I was promoted to Vice President. I stayed at Amazon and continued to work in video games, working for Twitch.tv, which Amazon acquired. I also launched the gaming pillar of Amazon Prime at this time. In 2020, I left Amazon to focus on teaching and coaching.
2. When was the moment you realized that technical skill alone wasn't enough?
I experienced this early on, moving into management less than 2 years into my career. However, it was a few years later when it really sank in. I was a VP in a startup, leading six teams of very different functions, which made me realize that management was a completely different skill set. At that time, I was leading the Quality Assurance, IT, Documentation, Customer Service, Training, and Human Resources groups. Only one of these groups, QA, was really related to software engineering. The others were a wide range of support functions. Leading these groups made clear that it wasn’t strong technical skills that were driving my career growth, but my ability to hire individuals and team leaders, then organize and motivate the teams to hit our business goals.
I discovered that a willingness to lead, make decisions, set direction, and organize groups of people was more relevant to my success than technical expertise. My role exposed me to many different experts: software experts, deskside support, technical writing, human resources, recruiting, etc. I realized that if I could understand and harness the skills and knowledge of various experts, I did not need to have that expertise myself.
3. Most engineers believe promotions reward the best work. What are people missing?
The idea that promotions reward the “best work“ has a couple of problems. The first problem is that engineers tend to define “best“ as the strongest technical work, rather than the work that the business or manager most needs done. So if a manager rewards the worker who generates the most impact or does the most consequential work, stronger technical experts who use a narrower definition of “best” may feel passed over.
The second issue is awareness. If one engineer does great work silently while another does good work and publicizes it well, a busy manager may hear more about the good work than the great work. Managers do not spend a lot of time investigating who is doing the best work. They are usually overwhelmed with their own workload and are just trying to survive. In this survival mode, highly visible decent work gets more credit than less visible, better work.
Finally, personality and relationships color promotion assessments. It is human nature to forgive small errors in those we like while being harsher with the work of unpleasant people. While it is not always true, technical experts have a reputation for being curt and intolerant toward less able peers, or at least lacking the social skills to explain their work well. It is common for managers to value those who are easy and pleasant to work with a bit more than those who may be highly skilled but are difficult to work with or understand.
As a simple summary, social skills matter in the workplace and are a large part of the promotion equation. Engineers tend to prefer a more pure and narrow definition of “best” that only focuses on technical ability and work quality, but the reality that soft skills and relationships matter is what many engineers are missing.
4. You have this concept of the "polite fiction," a statement that's warm but firm, where everyone understands the real message. What is it about?
I use the term “polite fiction” for situations where it is awkward and may hurt relationships to speak the complete, literal truth, but many people will know or suspect the truth behind a softened version of the message.
The simplest example I can give is when someone says they have a “personal commitment”—perhaps a child’s school event or a doctor’s appointment—when they are really taking a day off to go interview somewhere else. This is plausible and believable because we sometimes do take days off for our kids’ events or medical appointments. However, when an employee takes a few Mondays or Fridays off in rapid succession, many managers realize that the employee might be interviewing elsewhere.
The reason people use a “polite fiction” in situations like this is that telling your manager you are interviewing elsewhere can cause extra stress for everyone. The manager may be insulted, or they may want to ask what is wrong and try to fix something about the job. Then the employee may worry they will be passed over for raises or promotions if the company knows they are speaking to other employers. As long as neither party is completely sure of what the other knows, the polite relationship is maintained, and everyone can continue on as normal.
5. Where is the line between manipulation and influence?
The best definitions I know differentiate manipulation from influence, as follows:
Manipulation is when you try to persuade someone of something primarily for your own good. In so doing, you are at best indifferent to whether this outcome helps or harms the other person, and at worst, you actively accept harm to the other person to get a benefit for yourself.
Influence is when you try to persuade someone of something, primarily to help them or someone else (the team, the customer, etc.). It may be that you will also benefit from this, but the persuasion begins with seeking the good of the client.
As a hypothetical example, if I have a product or service that I truly believe will help you with a real problem you have, then trying to sell you that product involves influencing you. On the other hand, if my goal is to overcharge you for a product or get you to buy something you really do not need, that is manipulation.
In summary, the difference comes down to motive. I can reframe, back-channel, and pre-wire a decision that achieves a positive outcome for you and is not manipulative. Or I can do the exact same things while harming or disregarding you, and it is manipulative. That said, certain actions, such as omitting facts or lying, are likely always manipulative. Tearing down another person, taking credit for work you did not do, or lying about competition is always manipulation. But doing a good job organizing your case to help someone else decide to promote you or buy something from you is just good influence. There is nothing manipulative about that.
6. What is the difference between an umbrella manager and a funnel manager?
An umbrella manager is a manager who shields the team from outside distractions and influences so that they can focus on their work. A funnel manager is someone who routes all work through them, turning themselves into a bottleneck.
To figure out which one you are, talk to your team. Or better yet, have someone else talk to your team. If you have been a manager long enough, have someone call a few of your former employees and ask them what they thought of you. The most honesty will come from those who worked with you long enough to know your style well, but who are now safely away from you and a year or more into some other job. This will make them feel comfortable sharing the truth. Have this other person ask them if you were a good advocate and protector as a manager, or if you tended to let pressure from above come through onto the team.
In general, we fail to check references as often and as thoroughly as we should. We accept that a company will require us to supply three references and may even call them, but we do not do this ourselves when we want to know about a new manager or company. With LinkedIn and other professional networks, it is very possible to track down former employees of a company or even a specific leader and check up on them. While I provided one example of how to use this to learn more about your own management style, this powerful technique has many uses for job seekers. Most people who have joined a bad company or are working under a bad leader would say that if a few phone calls could have saved them, it would have been well worth the hour it takes to make them.
7. It is said that by the time a PIP starts, it's already over. What are the early warning signs that show up weeks or months before that most people miss?
First, let me cover briefly why it is “already over” when a PIP starts. The reason is that PIPs are a lot of work for a manager, and they usually require them to tell their own boss that they have a problem employee and then get approval from Human Resources to start the PIP process. Most managers will avoid all this hassle if they believe that there is any chance you will improve. Also, many employees immediately start looking for another job when they realize that they are seen as poor performers. For all of these reasons, most managers try to help an employee as much as they can before resorting to a formal PIP. So, by the time they do start a PIP, they have exhausted their own ideas of how to help the employee. This is why it is nearly impossible to recover from a PIP – the employee must do so well that the manager is willing to change their own view and then go tell both HR and their own boss that they were wrong about you. Very few managers will be willing to do that, even in cases where employees make drastic improvements.
The early warning signs that people often miss usually take the form of bad feedback that doesn’t convey the message. This is in part because many managers present negative feedback softly, not wanting to start an argument or scare the employee into leaving prematurely. So, managers give soft hints of problems while the employees, wanting to believe the best about themselves, tend to focus on the good news. They hear negative feedback as a few things for them to work on to get even better, not as job-threatening gaps in their performance.
There are two important solutions to this. First, take even minor feedback seriously. Second, ask for clarity on where you stand as an employee. Ask a manager to be very direct about your level of performance and to tell you openly if any of your problems are not just opportunities for improvement but problems needing to be solved for you to be seen as successful at your job.
8. Your frameworks assume you can build champions and be likable. What's the playbook for someone who knows they'll never win on likability?
There are two options for someone who feels they will “never win on likability.” The first is best described by the title of a book by Cal Newport, So Good They Can’t Ignore You. As the title says, this book and its subsequent book, Deep Work, define a process to get so much done and to perform so far above everyone else that you will be valued no matter what.
That said, the second option is to work on emotional intelligence. You have framed this question as “someone wo will never win on likability,“ but I would challenge this framing as, at least in part, being a choice and an excuse. While it is certainly true that some people naturally have more social skills than others, I also know plenty of engineers who choose to be judgmental, argumentative, and even combative as a way of trying to establish their own intellectual superiority. I think many engineers who might like your characterization of “brilliant and blunt“ actually just enjoy being right more than they care to be the slightest bit polite.
I say this, partially, because I was one of these people. I went to very good schools, am smart, and grew up debating as a way of life. As a result, I often set out to prove everyone around me wrong and to show that my ideas were superior. I “won” far more of these arguments than I lost, but later in my career, it began to take a toll. I was laid off from two VP-level jobs at startups when my caustic style caused the leadership teams to decide that my expertise wasn’t worth the friction I caused.
So, the second thing an engineer should do is to have some humility and recognize that being right is not the only thing that matters. Being able to get along with others also matters. Further, there is plenty of evidence that social skills can be learned and improved. I improved my own, and after being let go twice, went on to become a VP at Amazon and lead teams of hundreds of people.
Basically, I reject the premise that “brilliant and blunt” is a fixed state and an excuse to be abrasive. Engineers who say they are brilliant but blunt are making a choice. They can change their approach and build at least average interpersonal skills so that they are no longer holding themselves back. Doing so requires admitting that they may enjoy being brilliant and blunt, and finding new ways to bolster their self-image rather than doing so by winning arguments.
9. Most of your examples come from in-person Amazon culture. How does all of this change when teams are remote and distributed?
Remote and distributed environments come in a few different flavors. If you are the only remote person or you joined a team that used to all work together physically, you have a bigger challenge. That said, it is very possible to build relationships online. At this point, many millions of people have formed businesses, met spouses, and formed large online followings on social media websites. So it is clearly possible to develop significant collaborative relationships virtually, but it does take intention and effort.
The old in-person environment reduced the effort needed to build connections because it put people together in “non-work” moments, such as in the elevator, getting coffee, or over lunch. In a remote world, you have to create these moments more deliberately by participating in chat conversations in Slack or Teams, by asking social questions about kids, sports, or travel, and by intentionally investing in getting to know someone beyond their work.
The simplest, quick advice I can give anyone who wants to build better relationships is “be curious.” Smart people can think of a million questions to ask someone if they choose to put their minds to it, and most people like to be noticed and to talk about themselves at least a little bit. So, ask them a few questions about things like their goals at work (not just the current project, but what they care about, what they hope to do), their family, and their interests or hobbies. The classic book How to Win Friends and Influence People will help here.
The bottom line is that with remote work, we have to put effort into creating the casual connections that came for free in a shared office setting. The key is recognizing this need and choosing to put in some effort. It doesn’t need to be a lot, and for some people, it can even be easier because much of the interaction can be through a keyboard at the time of your choosing rather than on the spot in the hallway.
Milan here, one book that I found very useful in the corporate life is The 48 Laws of Power by Robert Greene.
10. At the VP level, you were the one making different decisions. Did you ever catch yourself doing the exact things you now teach people to defend against?
There were definitely times when I made decisions based, at least in part, on who I wanted to work with rather than who was more strictly the “most qualified.” When you are working 60 or more hours a week, enjoying that work time matters. So there were definitely times when I chose to focus on people and projects that would give me joy. Sometimes those choices were conscious, but more often they were subconscious and unintentional. However, the outcome was just as real.
One of the things I teach is that managers are human and thus have all the normal human weaknesses, particularly when stressed out and exhausted. So while a manager may intend to do the right things and treat people fairly, this can often fall short in practice. I definitely fell short of my ideals at times when rushed or pressured.
My advice to readers is not to expect your manager to be perfect, but rather to plan for them to be human, just like you and me.
11. If you could go back and un-teach one piece of advice, something you gave that turned out to be wrong or that people consistently misapply, what would it be?
I think if I had to change one piece of advice, it would be telling people to “get a mentor.” Mentors can be tremendous, but it is easy to mess this process up in many ways. Many people will ask the most senior person they can find to mentor them. This person is already very busy and should be spending their time mentoring much more senior people than the person who usually asks. You are better off asking someone who is closer to your level, but still above you, than simply shooting for the top person.
Second, they get a mentoring commitment and then do not follow up on it. As an example that amazes me, I charge between $1000 and $2000 per hour for coaching, and I require people to pay for 6 sessions in advance. I have many clients who, after a few sessions, never schedule another call. Now, you could say this is because they do not value my advice, but if they were unhappy, presumably they would want a refund. Instead, it appears that they are happy with the advice, but then just get busy and never even continue to claim the coaching they have paid for. This happens to a much greater extent with mentors, whose services are free. If I had a dollar for every mentor who has been abandoned after one or two initial meetings, I could buy a very nice yacht. So, I would tell people not to have a mentor unless they have a very clear focus on their goals and a strong commitment to following up.
📔 The Laws of Software Engineering book is out
The book began as a document I wrote over the years. During my 20+ year career in Tech, I saw the same things happening at companies with different technologies and teams. I wrote down what I saw. I learned about Galls Law from a project that did not work out. Brooks’ Law was observed in a team that grew larger, but everything became slower. Goodhart’s Law arose from a time when we met all our goals, yet the results were no better. They have been even worse.
Later, I met engineers who had figured out the same things. Most of them learned these lessons the hard way, as I did. They had a project that failed a team that got tired or a codebase that was a mess. This is how engineers usually learn these lessons because no one tells them. It is true, and it costs a lot.
This book is a list of what I learned.
This issue covers 20 software engineering laws. My book covers 56 laws across architecture, people, time, quality, scale, code, and decision-making.
Each chapter discusses what the law says, where it comes from, when it applies, and what it looks like in a project. Some chapters also include connecting ideas such as The Two-Pizza Rule, The Cobra Effect, and Impostor Syndrome.
This book is something you can keep at your desk and look at when you need help.
Forewords are written by Dr. Rebecca Parsons, CTO Emerita at Thoughtworks, and Addy Osmani, Engineering Director at Google Cloud AI. Reviewed by 20 engineers and leaders from Google, Amazon, Uber, Oracle, Yelp, Nutanix, and CodeScene.
Want to advertise in Tech World With Milan? 📰
If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.
Love Tech World With Milan Newsletter? Tell your friends and get rewards.
Share it with your friends by using the button below to get benefits (my books and resources).