The Engineering Judgment Library

QWhat is empire building, and why does it persist at large companies?

Ethan defines empire building as focusing on raw headcount rather than on what a team does or the impact it has. He says it exists because it is rewarded, and it is rewarded because counting people is the easiest thing to do. Impact is subjective: one leader may think a project was hard and another may think it was easy. Nobody can argue with the fact that one manager has 42 people and another has 17.

Ethan adds that some companies write headcount thresholds into the criteria for promotion. High performers given such a target will find a way to hit it, including by claiming they need people or by taking over other groups, and they will rationalize that to themselves.

QDo reorgs often carry a second, unstated motive, such as getting someone promoted?

Ethan says there is always something else going on. Leaders know that too many reorgs cost them people, so they wait as long as they can. When they finally act, they ask how to get everything they want: how to give less to someone they would like to see move on, set up a high performer, and keep key people. Once the business case is settled, he says, the question becomes what else can be loaded onto the ship before it leaves the dock. He notes that people often come to him saying a boss told them they were being placed under a peer so that the peer would have enough scope for promotion.

Because a reorg is usually large enough that someone will audit it, Ethan says the leader must build a narrative: the reorg rewards the deserving, meets the business goals, and any pain lands on people who are not top performers. He recalls his own reorgs as mostly about retention, asking who he must keep and who he could live with losing. He cannot recall putting someone in a role expecting them to quit, but he can recall using a reorg to give a person at risk of leaving something more attractive.

QDoes the squeaky wheel get the grease in reorgs and promotions?

Ethan says there is truth in the old saying, and that people do not like this harsh fact. If two people perform about equally and one has made clear they are thinking of leaving, a manager may reason that the loyal one will wait another six months. That manager then uses those six months to save the other person. It is not meant to hurt the quiet employee, Ethan says, but that person can fall behind simply for being nice.

He often tells coaching clients that they are very nice and that, in this context, it is not a compliment. Ethan does not say people need to be jerks. Pushy people get more up to a point, and beyond it they antagonize and get less. In a reorg, he adds, a leader may serve the pushy people first because that keeps the whole team intact, while assuming the quiet people will be fine.

QDid demanding high performers ever irritate Ethan so much that he refused them?

Ethan gives two answers. First, if a very demanding person has become a net negative, a flat no will usually make them quit, even for a lesser job, because they are driven to get what they want. There is a calculation about which answer produces the result the leader needs.

Second, Ethan preferred to make a deal. He would tell a high performer that he would help them get what they wanted if they delivered exceptional results on what he needed. He says he always followed through, with one early-career exception that he still regrets after about twenty years.

QDo managers keep a queue of who is up for promotion next?

Ethan says there is a line, and big companies often have a policy on it. At Amazon, HR tracked a forward-looking slate of promotions by half-year, with names projected at six, twelve, eighteen and sometimes twenty-four months. There was a sense of whose turn it was, though he says there was no strict quota in his time.

He says someone he coached at Google described a strict quota, for example two people moving from L8 to L9 in an organization in a given half. Ethan notes that this is a second-hand report. In his view, quotas appear mainly at rare, expensive senior levels, where a position such as staff, principal or distinguished engineer can cost around a million dollars a year. Early-career levels usually have no quota.

QHow should a leader handle someone in the organization who tries to take scope from a colleague?

Ethan says this has become more common as growth has slowed. When a company is growing quickly, as Amazon did for much of his tenure, it is easier to get new people than to fight over existing ones. In flat-headcount companies, he describes more cannibalism. His answer is that a leader cannot let a team member act as a pirate who captures another person's ship, because that leaves the leader looking clueless and no longer in charge. The leader has to find the person a path, convince them to wait, or, if they turn toxic, let them become the one who leaves.

Ethan notes that blatant self-service is restrained by the risk of getting caught. His advice to people who want more is to tell their manager in advance that they are interested and ready to step up if an opening appears, and that they intend to stay. Reorgs shake things up, and managers worry about placing someone in a role who then leaves. Ethan says a person who signals they will stay becomes the most reliable candidate, not necessarily the best.

QWhat about engineers who create scope by finding a problem nobody asked them to solve?

Ethan says that can also work, and that he recommends both paths: ask your manager how you can help, and also think about what you could do on your own. His example is custom-printed t-shirts, which he says Amazon now sells at over a billion dollars a year. Ethan helped start the business and funded the first team out of his Appstore organization. His boss asked what t-shirt printing had to do with the Appstore.

Ethan told his boss that he saw a big business there and needed 10 people out of 800. If he could not spend about one percent of his resources on something he believed in, Ethan said, that would be micromanagement. The boss disagreed but agreed. Ethan says about 790 of his 800 people worked on what his manager wanted and 10 on his own bet, and that a leader who runs side projects must shut failures quickly and keep a good hit rate. His summary is that there are multiple paths to the top, and he tried them all: be the helpful person, and also be the inventor.

QHow are reorgs used to manage certain leaders out?

Ethan says in practice a leader puts the person on something they do not want to work on and claims it was the only seat available. He tells of an early Amazon group where leaders owned Prime Video, Prime Music, the Kindle and an ingestion pipeline. One leader was given database maintenance, quality assurance and a few small items, and joked that his group was Other. The VP objected to calling it the garbage can, but Ethan believes the VP expected that leader to leave. The leader, calm and a team player, was reportedly still at Amazon twenty years later.

Ethan's view is that giving a pushy, overly ambitious person the Other seat can create a vacancy within weeks. He himself tended to fire people directly, but he calls the bad-seat move classic and not unique to Amazon. In Japanese culture, as Ethan understands it (he says he is not an expert), a window seat signals exile from the center of action, the opposite of how Americans see a corner office.

QWhat should an engineer do about a weak manager: can they go to the manager's boss?

Ethan says escalations like this reach him all the time, and that employees underestimate how the skip-level boss thinks. A boss hearing about a weakness in a direct report faces two options. One is to decide the complainer is overly sensitive and high maintenance, in which case the problem is the complainer, and the boss can pass it back to the manager. The other is to agree, which creates three problems: deciding what to do with the manager, hiring and training a replacement, and doing the manager's work in the meantime. Even if it is subconscious, he says, the boss has many reasons not to believe easily.

So his advice is never to mutiny alone. If the employee really wants action, they should bring two or three colleagues, or send them in sequence. He describes a leader who treated the women on the team badly. A lone report would probably have been ignored, but when Ethan asked several women and they confirmed it, he realized he had been blind to a problem and acted.

QHow can someone find careful wording for these conversations, such as the polite fictions Ethan has described?

Ethan says he is not sure how to teach this, but one common mistake is not thinking through wording before entering the room. Most of these conversations are not spur of the moment: they are on the calendar, like a performance review, or are known to be coming. He advises preparing a key phrase in advance so that it can be said with sincerity. In his examples nothing was a lie, yet he delivered the lines warmly. He says delivery matters as much as content: the same words with a hard tone provoke a hostile reaction, and the same words with a warm one do not.

To engineers who say they hate politics, Ethan replies that this is simply human interaction, with other people's emotions, defensiveness and stress, and that they should get good at it.

QWhen a manager or colleague is a skilled influencer, is that a positive sign or a warning?

Both, Ethan says. He argues that the skills of influence and politics are the same, and that the difference is motive. He teaches executive presence and points out that Darth Vader had plenty of it. When he meets a skilled operator, he asks which side they are on. There are three cases: people with good motives, who are easy to work with; people entirely out for themselves, whom he compares to the Sith; and a middle group whose motives are workable. With the third group he can make deals: they are not altruistic, but they want something he can help with, and the two can ship something or earn something together without being friends.

QHave other organizations tried to take scope from Ethan's organization, and how can a leader defend against that?

Ethan says he saw it all the time. In his account the people trying to take scope rarely think of themselves as pillagers. They know their own mission well, so they see clearly how your scope would help them, while not understanding your mission, so they can imagine that your organization is not important. He quotes a smart engineering leader who said respect between two engineering teams is inversely proportional to their distance. He gives the example of Amazon S3, which stores hundreds of trillions of objects and is sometimes dismissed as a big disk drive; the closer you get, the more complexity you see. Few people plan to be evil, he says; they want something and construct a line of logic for why it is good.

He lists defensive tactics. The skunk trick is to make yourself unattractive: list the unglamorous things you maintain that the other team does not know about, and have customers explain how important they are. Another is to be thorny, so that the attacker looks for a softer target, though he warns that behaving in a way that discredits you makes you an easier target. A third is to expose motives while making a strong case for the value of your work, which is easier from a base of strong performance. A fourth is delay: reorgs cost about six months of productivity, so a team that is hitting its goals can argue that now is the wrong time. Ethan says the common thread is narrative, because people reach an emotional conclusion and then rationalize it, so the better storyteller wins.

QWhat can a leader do about a well-liked person in another organization who is a major problem for their own organization?

Ethan says one of his managers once assigned a person he called a meat shield, whose job was to keep that difficult person away from the rest of the group until a project finished. The manager was honest that it was a terrible role and promised to make it up later. Ethan says that if you want to change things, the most important step is to understand why the person is valued in their own organization. Their leaders are probably thinking the person has sharp elbows but gets a lot done, and that others are soft.

He then describes two discussions. One is to say we want the value without the pain and ask for a better way. The other is to say the person is mistreating the team and either the interface changes or cooperation will stop. Ethan's private version is to retaliate with delays and process. His outward version is polite: the colleague is valued, but the team is struggling, and Ethan offers a new point of contact or, otherwise, distance between the teams, which will create friction that takes both leaders' time. He notes he has people ready to leave and asks what the other leader would do in his place. Ethan says this is the same message with no threat, and that leaders at that level sense the unspoken stick without needing to hear it. He compares this to telling a rough opponent in ice hockey that he also has elbows.

QWhy does an engineer need a manager who can stand up for the organization, and what can the engineer do if the manager will not?

Ethan says a manager does not need to be mean to be firm, but does need to be skilled. Many people can only deliver hard messages after working themselves into anger. He tries to stick to his beliefs without using anger as fuel, while admitting that friends tell him when he has been a jerk. He repeats an image that managers are either an umbrella or a funnel, and a funnel passes pressure to the team. A yes-man manager chooses between pushing back on their boss, which feels dangerous, and pushing on the engineer, who has less rank.

Ethan says the engineer has to change the balance of safety: either help the manager feel safe pushing back on their boss, or make it feel unsafe to ask for a fourth weekend. Ryan thinks the first option sounds almost impossible. Ethan replies that the second option is exactly how a manager gets a backbone. He gives a sample script for weekend work: raise the pattern, offer data, say that family is important and that the engineer cannot keep working weekends, and ask how to plan the pushback next time so the manager is not left having committed to work that will not happen.

QWhat is backchanneling, and when does it help?

Ethan separates good backchanneling from manipulative backchanneling. Manipulative backchanneling is doing something you would not say in public, such as undermining a proposal or painting another leader negatively. He says that is usually unnecessary and he would like to say never necessary. Positive backchanneling is giving people a chance to ask questions and share concerns without having to do so publicly. A finance person worried about the budget, for example, can ask in private rather than in a meeting.

Ethan says it works not only because information is exchanged but because the other person feels understood, consulted and heard, and that emotional buy-in builds trust. When an executive chooses between two similar proposals, he explains, the executive asks who they can count on, how the decision will make them look, and how conflicts will be resolved. A leader who consulted them can win even if the other proposal pays slightly more. Ethan contrasts this with backroom deals, such as kickbacks, which he describes as a proposal to do something wrong because both parties benefit. He says some people accept because they tell themselves they are owed, and that if you can learn their story, you have a better chance to redirect it.

QCan influence come from somewhere other than the number of recursive reports?

Ethan says he has seen soft power come from ideas. Amazon built a storage product called Cloud Drive, which he compares to Dropbox or Box, and the proposal came from a newly graduated engineer. The engineer won an invite to an engineering conference, emailed Jeff Bezos to ask him to visit the poster, and pitched the idea. Bezos liked it and emailed the engineer's triple-skip manager, a VP who was Ethan's own boss. That VP disliked the idea, but Bezos had said to look into it, so Ethan funded the project and it got built. Ethan also mentions a slightly more senior colleague who helped put forward the Amazon Fire TV proposal after doing legwork and building connections.

Ethan says the common thread is a story: a vision told as an understandable soundbite that nobody disagrees with, such as having a cloud storage system or a low-cost living room device. It usually starts with real facts, is told with enthusiasm and repeated, and is told to people who have the power to act.

QWhat are the least discussed reasons that people get fired, beyond what appears in performance notes?

Ethan says there are legal rules about when and how a person can be fired, so the public story is almost always about performance. He says the unspoken reason is often incompatibility of style: detail-oriented versus high-level, or technology-first versus business-outcome-first. A small difference can become a debate that turns into labels, such as technically clueless or only about money. Once a person is labeled, he says, everything they do is read through that lens, and that is where people get fired, though it is always called performance.

He also describes a case in which a newly hired executive at a very senior level was reported by several women, including an HR representative, for sexual harassment, and was terminated right away. Ethan explains why such people can be hired again elsewhere: the company had no legal proof, so naming the person risks a lawsuit, and a former employer typically confirms only dates of employment. Ethan says he later saw that the executive left the Amazon job off a resume, and he does not believe it was a one-off.

QWhy is it harder to fire a bad manager than a bad engineer, and how does Ethan do it?

Ethan says he agrees it is harder, for three reasons. First, managers tend to be more experienced, so their weaknesses are subtle. The first person he ever fired had stopped coming to work, which was easy. Second, a manager's work is hard to measure: hiring, reviews, shipped features or bug counts all have limits, so the conversation becomes a he-said, she-said problem. Third, managers understand the system and can quickly position themselves to be hard to remove. Ethan still terminated a large number of managers.

His ideal method, which he could not always use, was to raise socially that things may not be working and ask whether the manager would like help finding a better place. Smart managers hear that their boss is unhappy and is offering a door, perhaps with time to find a job or a severance package. He avoided the words fired or performance because, as he understands it, they can create a legal issue called constructive termination. A smooth manager will answer that they are sorry the boss is dissatisfied and are open to changes, which Ethan reads as the start of a counter-negotiation. The other route is formal performance management, with documented expectations and misses. He says almost all managers quit before that finishes, since the process gives them roughly 90 days to find a job.

QHow can someone break out of the staff-engineer or front-line manager level where many people get stuck?

Ethan says this is his bread and butter. People get stuck because they keep doing the current skill harder rather than learning the skill of the next level. What gets someone promoted early is hard, effective delivery. Later they need to delegate, communicate and let go of hard skills, because micromanaging drives away good engineers. He points to Marshall Goldsmith's What Got You Here Won't Get You There.

His practical advice is to talk to people a level or two above and ask what they had to let go of and learn, and what they see holding the person back. He prefers asking for advice to asking for feedback, since feedback asks people to criticize and advice invites a more positive version of the same information. He sees many people working brutally hard but ineffectively.

QHow do you win champions for a senior promotion packet when you have no natural collaboration with the leaders you need?

Ethan's favorite method requires the manager to be on your side. As a manager, he would email peers or skip-level leaders to say that Ryan would be up for promotion in six months, that their group was adjacent, and that he would ask them for feedback. That gives them six months to watch, it does not feel self-serving since it focuses on their time, and six months later the leader cannot say they hardly saw the person. Ethan says he got good at getting people promoted, which helped him attract and keep talent; one person who missed a cycle gave him another six months, and the promotion came through.

If the manager is not on board, the next best option is for the person to approach the leaders and ask how to be in a natural position to give feedback over six months. Ethan advises oversubscribing, because of departures, reorgs and refusals: if you need four champions, ask six or seven. The ask can be framed as doing it properly and in advance, rather than as the usual last-minute request.

QWhat can someone who despises politics do to avoid it?

Ethan gives two answers. First, choose a leader who shares the disdain, ideally from a similar technical background, and wants to reward the work. Second, work on the hardest area available, where expertise matters and the engineer stands out. He recalls Andy Jassy, then head of AWS, saying that a few principal engineers working on the hardest problems were relieved of the usual duties of reviewing architecture and mentoring because the company needed them solving those problems. Ethan notes that such engineers had the perfect boss.

He adds that a unique, valuable skill brings exceptions. When others complained that a high-level employee was not working at an Amazon level, Jassy said he agreed but that the person was in a role the company needed and knew it, so they would live with it. Ethan concludes that avoiding politics requires an essential skill and real leverage, which is the point of Cal Newport's So Good They Can't Ignore You.

QWhat advice would Ethan give his younger self about navigating corporate politics?

Ethan wishes he could tell his early self that being right and technically astute is not enough, and that there is a lot more going on. He says he was blind to it or deprioritized it as management stuff, but management stuff controls the world even for an individual contributor. In a single sentence, he says people should take seriously that relationships are what actually control their progress.

QIs John still bullish on Meta and MSL after working there from the inside?

John says he is very bullish on Meta as a company, now as a stockholder rather than an employee. He is much less bullish about being an employee who holds little equity, which he says describes most people, since most staff are paid mostly in cash.

He says working at Meta is less enjoyable than before, even though the business is run very well for the bottom line. He keeps investing in the company and expects to continue. He describes being an employee there as a more stressful time than before.

QDid the promise of career growth change as a retention tool at Meta?

John says many Meta divisions stopped talking about pay, purpose, and enjoying the work as reasons to stay. People instead said the only reason to do anything was a clear story about a promotion. When he moved from data infrastructure into AI infrastructure, he found almost no one whose first goal was not promotion.

Monetization was the strongest case. It hired people out of AI infrastructure with detailed plans for getting promoted. John says that worked for promotions but wrecked many teams, including several he later managed and had to repair. People on those teams agreed the work was bad and unlikely to succeed, yet shipped it to meet their promotion bar.

He says this made good software decisions almost impossible, and that the skills that would help careers most became separate from promotions. When the market turned against employees, managers told people to fear layoffs more than they hoped for promotions. He does not think that was a good cultural fix, though he sees it as an attempt to undo earlier damage.

QHow was your early time at Facebook on the experimentation tools, before the promotion pressure?

John says his first two years at Meta were some of his happiest, though also among the most frightening. He had asked for six months of leave to work on Julia, a language he was a core contributor to. While he was away, the manager who hired him left, and the team he had joined split into core data science and data science infrastructure.

He wanted to join core data science but worked closely with data science infrastructure, which owned the experimentation tools. He says that work was the most valuable thing he did as an individual contributor, and that people who know him from Meta remember him for it. Core data science was turbulent, with reorganizations, new managers, and churn.

A few months in, a paper from a research-leaning group that John was affiliated with became a major PR problem for Meta. John remembers it as something like 'Emotional Contagion in Social Networks'. He tried to prevent the problem but lacked the authority. The author later apologized to the company in a Q&A. John found himself in meetings with the head of legal, and his team faced the possibility of being disbanded. He calls it a formative experience, though the fallout faded.

Over the following years he became one of the main developers of Deltoid, its third iteration. When most senior engineers left within about six months, he became the only person who remembered how the system worked. At about IC5, he became a de facto tech lead and drove the vision for the A/B testing tools for years. He calls it some of the most fulfilling work he did at Meta.

QDo you have a regret that others could learn from?

John says he has a stock answer, because he is asked often. For his first several years, his skip-level manager, Javi, ran office hours. John's manager, Danny, kept suggesting that someone should go. John did not go, because he felt he had nothing valuable to say to Javi.

Later, as John ran office hours for a larger organization, he wished people would come, and he realized Javi had felt the same way. John says he missed a valuable opportunity and made things worse for Javi as well. He calls it a decision made out of fear that harmed both parties.

His advice for junior engineers is to go when a leader says they want to hear from people. Directors and above are far removed from the work, and John says he sometimes had managers managing managers. Bring a concrete idea rather than asking how to get promoted, he says. Leaders welcome that, and many people are afraid to do it, which makes everyone worse off.

QIf you could go back to the start of your career and give yourself advice, what would you say?

John says he holds strong opinions but can be more self-conscious than he should. His advice is to believe that bigger work is possible, and that with high discipline it is. From high school through college, he says, he too often cast doubt on what he could do. He calls that the biggest set of mistakes he has made: not being ambitious enough, or not believing a problem was tractable.

He also says people over-convince themselves of others' greatness and under-convince themselves of what they can achieve. That combination makes them take fewer risks than they could. Until he worked with many people who succeeded, he says, he did not see how often those people were not much better. They just tried, and others did not. For a 20-year-old version of himself, that is the main lesson he would give.

QHow do quants and software engineers collaborate?

Nimit says it depends on the company. At Jane Street, the number of people called quants is small, and traders are technical and implement much of their own work. At Citadel, which Nimit calls more quant-forward, quants may be roughly equal in number to the technical staff. Roles overlap a lot across quants, software engineers, and traders.

At some firms, quants design strategies and hand them to engineers to build. At others, one person may do both, because the person who can implement something best understands its reasons and edge cases. Nimit did a lot of coding, mostly in C++ and some Python.

QWhat sets the top 1 percent of AI researchers and quants apart?

Nimit says there are several paths. Raw technical skill, intuition, and execution speed all matter. So does playing the political game, which can help people rise. Quant is harder to game because performance is easier to measure. A strong alpha quant who makes the firm a lot of money is clearly recognized.

In AI, the measure is harder to read. A seminal paper or a real breakthrough, such as a much better model, plays the same role. Nimit adds that being in the right place at the right time matters in both fields.

Compare risk-taking and groupthink across organizations

Nimit says big labs have strong resources, compute, and many researchers. The flip side is that they can be averse to out-of-the-box ideas, prone to groupthink, and less willing to take risks, because failed experiments are expensive. Startups can be more nimble and explore strategically, challenging orthodoxy. That is what drew Nimit to Cartesia.

QWhat do you think of stack ranking, attrition targets, and performance improvement plans?

Evans describes an Amazon attrition-target system from his management experience: a list of people whose departure was considered unregretted, with pressure to reach an annual proportion through improvement, resignation, or termination. His quoted percentages vary by period and are historical recollections, not verified current policy.

He says that when Amazon experimentally removed the target, managers stopped having difficult conversations with struggling performers, and the goal returned. Managers may avoid acting when a person is well liked, especially in a large organization where the immediate cost is not obvious to them. The target forced attention to a real problem.

The other side is distortion. A quota can put someone on a list who still had a plausible chance of success. Once a manager has mentally decided a person should leave, confirmation bias can make the improvement plan psychologically unrealistic. Evans believes many plans therefore function more as a route to departure than an open-minded attempt to improve.

He reports unsuccessful experiences coaching roughly half a dozen people on Amazon PIPs and similar outcomes among people who did not use his coaching. He now urges people in that situation to prepare for another job rather than rely on reversal. That is a strong warning based on his cases, not a measured universal failure rate.

Even a manager starting with good intentions may face pressure from HR and leadership to count an exit, or to name another person if the first improves. Evans’s broader diagnosis is that companies often fail to train managers for early, useful performance conversations, then depend on a distorted late-stage process.

QWhat prevents a manager from presenting an employee unfairly to HR?

Evans distinguishes removing one employee from repeatedly driving people out. A pattern of high turnover can eventually expose a manager, but one case may remain difficult to challenge. The manager usually has higher status and can frame the issue for HR before the employee realizes that a dispute is developing.

He illustrates narrative ambiguity with code reviews. The same large number of reviews can be described as improving everyone’s code and developing the team, or as nitpicking others while contributing little original implementation. Counts do not by themselves determine which interpretation is accurate.

He says he has not personally used this power to target someone unfairly, and notes that keeping capable partners serves a manager’s goals. His concern is the vulnerability to a vindictive manager or a genuinely different view of what constitutes useful work. HR hearing a familiar denial of poor performance may not easily distinguish a legitimate complaint.

His practical conclusion is to repair the relationship where possible or find a different manager, rather than assume HR will necessarily rescue the employee. This is his description of a power imbalance, not approval of retaliation or a claim that every organization lacks checks.

QHow do you receive credit when collaborators compete for visibility?

Evans argues that recognition depends partly on who tells the story. Communicate a real accomplishment promptly, name collaborators, and state your own contribution clearly. If somebody else announces first, add a useful comment about the specific problem you solved rather than hoping that silence will be interpreted as modest excellence.

He also observes that later career narratives are often less contested than immediate credit allocation. His own shorthand about being an early engineer on the product that became Prime Video illustrates how an accomplishment’s public description can outlast detailed memories of everyone involved. He treats this as a practical feature of recognition, not proof that colleagues’ contributions cease to matter.

QDoes encouraging visibility reward noise instead of impact?

He agrees that an organization in which everyone talks without adding value is unhealthy. His proposed response is to raise the quality of one’s own contribution, rather than opt out of communicating. Tell leadership something it needs to know, such as whether a launch is ready for growth or will require additional investment if successful.

Evans directs the strongest part of his argument toward people who remain quiet because they dislike self-promotion. He says that refusing to participate does not create a fairer assessment system; it can leave useful work unseen. This is a pragmatic argument for useful visibility, and the host’s concern about excessive political behavior remains a real limitation.

QShould you be as loud and outspoken as possible?

No. Evans distinguishes making the strongest defensible claim from becoming a boastful person who claims falsely. He favors simple accomplishment language that an audience can remember, while accepting that simplification may irritate people who prefer a more exact label.

His example is calling himself the first engineer on Prime Video even though his work began on Amazon’s video product before the Prime name existed. A colleague disputed the naming, rather than whether Evans had done the underlying work. Evans is comfortable with that boundary; the discussion exposes a contested judgment about how much simplification is acceptable, not a rule that every embellished statement is harmless.

QHow can a naturally quiet engineer make work visible?

Writing can substitute for speaking in meetings: email, internal posts, Slack messages, white papers, and technical talks all expose work to an audience. Another person can also help publicize it. The central requirement is that the work should not remain in isolation.

A shared component used widely can create its own reputation. Evans recalls Amazon’s interview-tracking system being called the Matt Round Tool, or MRT; he knew of its author through the widely used tool despite never meeting him. Even this supposedly silent route needed distribution and a recognizable association with its creator.

QIf you find a valuable new opportunity, how do you secure the chance to lead it?

Make three cases together: the idea is valuable, you can execute it, and you can make time for it. A manager needs trust in your ability and a credible plan to hand off, document, or automate existing obligations. Originating the idea gives you a useful lead because you have thought about it most, but it does not erase a weak track record or another critical assignment.

Explicitly express enthusiasm for building it. Otherwise leadership may hear only an idea and assign it to someone else. Evans also recommends making disappointment visible when an opportunity is taken away rather than responding as though every allocation is equally acceptable.

He candidly describes a managerial temptation to appease demanding employees while postponing help for easygoing ones. He says a manager may intend to come back to the quieter person but never do so. His advice to be somewhat difficult to disappoint addresses that pattern, while acknowledging that it is an unfair practical tradeoff rather than an ideal of leadership.

QWould you prefer an entire team of ambitious stars or steady role players?

Evans prefers a mix. A high-growth business can sometimes supply enough attractive projects for many highly ambitious people; with flat headcount and constrained opportunities, those people may compete destructively with one another and the manager.

Only easygoing role players can produce a calm team without enough pressure for change. He values some people who question constraints and push ideas, while too many people simultaneously pushing in different directions can create chaos. The best composition depends on the business’s supply of useful scope.

QHow do you handle peers who want to take part in your attractive project?

His first move is to challenge scarcity thinking. Other engineers’ excitement can make the project larger, faster, or more valuable, with its originator coordinating contributions. Try to create a shared win before treating every interested colleague as a threat.

If protecting ownership is necessary, being further along in a prototype or waiting until responsibility is clear can help. Offering other worthwhile ideas may give peers useful opportunities without displacing yours. He also describes handing off existing work to free capacity, but explicitly warns that appearing to dump unattractive work on named colleagues can create enemies.

Evans stresses understanding motives, satisfaction, fears, and emotions. His poker analogy separates competing skillfully within accepted rules from cheating, such as secretly seeing another player’s cards. He believes a person can understand the social game and win without dishonest manipulation. Some examples, including challenging a peer to demonstrate commitment through weekend work, are described as social tactics rather than presented as obligations every teammate should accept.

QHow do you protect yourself from unwanted work that somebody else wants to hand off?

Evans recommends establishing valuable initiatives before a handoff arrives. If people already know what important work you are driving, there is a credible reason not to load you with somebody else’s maintenance. Once you are only defending against a specific assignment, he considers you behind in the negotiation.

If somebody calls the work easy, ask why they cannot automate or solve it. Be clear about capacity and about the cost of replacing your other work. He uses an aggressive animal analogy to make the point that people sometimes give assignments to the person least likely to object. That observation explains his advice to set boundaries, although it does not make offloading work onto a quieter colleague a fair result.

He also proposes constructive bargaining. Acknowledge that unattractive work needs doing, complete a bounded amount of it, and ask for a better opportunity afterward. Volunteering in advance for a maintenance sprint can show that you are on the manager’s side while creating a specific exchange, rather than silently accumulating an indefinite backlog.

QHow do you win a promotion when only one slot is available?

First ask whether the competition is realistically winnable. If several qualified and more senior people are already waiting for a single role, leaving for a growing organization may be better than trying indefinitely to jump the queue. Evans will not promise that every constrained situation can be solved.

Where there is a path, state your interest and ask what circumstances would make you the manager’s first choice. This invites concrete criteria instead of mind-reading. He then emphasizes being the person the leader can depend on during difficult problems or crises. Ask what keeps the leader awake or which of their biggest problems is worst, and help solve it.

He is explicit about cost: crises may fall outside convenient working hours, and becoming exceptionally dependable can require sacrifice. He has answered how to compete for the role, not how to guarantee it with no additional effort. The advice concerns making a real contribution valuable to the leader, rather than only expressing eagerness.

QWhat if your manager will not talk explicitly about promotion?

Evans first considers whether a different manager would be more compatible with your ambition. If changing is impractical, study what this manager actually rewards. Look at several promotions, talk to those people about the work and conversations that preceded them, and learn the manager’s language for growth rather than assuming everyone negotiates as directly as Evans.

If no one progresses, or the manager’s choices have no workable pattern, there may be no usable process to follow. Accepting a slow and uncertain system or moving elsewhere may be the real choice.

He suggests using AI to examine a manager’s communication and propose an approach that fits their style. His confidence about personality inference is his opinion, not a validated assessment presented by the interview. He distinguishes adapting communication from manipulation, while predicting that persuasive manipulation and AI countermeasures will become more important.

QHow do you handle a promotion carrot that remains vague?

First separate legitimate uncertainty from avoidance. A manager may need a committee, skip-level approval, or another decision maker and cannot guarantee their response. Ask what it would take for the manager to become an enthusiastic advocate, rather than demand a promise about the final result. Evans’s own VP sponsor committed to put his reputation behind the attempt but could not guarantee Jeff Bezos’s approval.

A manager may also be uncertain whether the work will be strong enough, or reluctant to specify a checklist that ignores new requirements. Acknowledge those limits while explaining the practical effect of having no visible target or timing. Ask what success would look like, how to measure progress, who has succeeded, and how you are supposed to work toward an unknown destination.

For a manager who simply strings people along, compare your experience with others’ outcomes. If people do receive opportunities, investigate what differentiates them. If nobody gets anything, Evans recommends leaving that manager or changing the leverage in the relationship. His suggestion to use negotiation questions is aimed at eliciting clarity; it does not create a guaranteed promotion where no real opportunity exists.

QWhat if your manager’s lack of advancement is blocking yours?

If the manager wants to grow, consider a shared plan: help them achieve a goal that creates room for both careers. Evans says he enlisted strong reports in arrangements where their promotions and his reinforced one another. Ask about their goals rather than assume stagnation means indifference.

If the manager does not want to advance, ask whether they can help you find an opportunity elsewhere. Some less aggressive leaders are strongly motivated to support people and may be willing to do that. If they need to keep you, explain that your career matters, that you would prefer to grow in the team, and that you will need to consider alternatives if a path cannot be created.

Evans proposes explaining an authentic season of urgency, such as plans for family or caregiving. The host challenges the gray area when future plans are uncertain. Evans defends expressing feelings and possibilities but says not to lie. The defensible substance is to explain a real priority and preference, then let the manager respond; the transcript does not establish a right to invent a personal obligation.

He also distinguishes normal ambition from implausible demands. A new graduate insisting on becoming a VP in two years needs a reality check. A manager who rejects ambition entirely may simply be a poor fit for this audience, while a hard-driving manager can create a different problem by demanding too much.

QDid your own reports use these political tactics on you?

Evans recalls a few very smooth negotiators, but most people were direct, perhaps because he openly discussed growth. He says he also encountered dishonest claims and removed people who made them. He distinguishes these cases from legitimate ambition.

Some strong reports wanted roles he could not offer quickly enough. He supported departures when another company had a substantially better opportunity, including a move to a large role at Samsung. Even an ambitious and supportive manager can run out of available scope.

He is frustrated by unspoken, passive-aggressive dissatisfaction because it prevents either fixing the problem or honestly discussing its limits. At the same time, he recognizes that some employees are in a life stage where they want to do their job and be left alone. That choice can coexist with a team of climbers, although he warns that such employees may receive less desirable work.

QHow can a manager remove someone for lying when the normal process requires evidence?

Evans says provable dishonesty may support a direct termination, but suspicion without decisive evidence is a different case. His broader, disturbing claim is that a manager in good standing has many informal ways to drive one employee out: unattractive assignments, discouraging advancement, critical reviews, excessive scrutiny, or a pattern of demands that makes continued employment unpleasant.

He illustrates how seemingly defensible work allocation can conceal punitive intent, and how a powerful manager can frame the situation for HR before the employee complains. These examples explain an abuse mechanism; they do not establish that such behavior is fair, lawful, or a sound management practice. Evans acknowledges that an innocent person could be harmed and relies on decent managers’ desire to retain good people as the usual restraint.

His stated distinction is between getting rid of someone he considers dishonest or damaging and targeting a good employee. That distinction depends heavily on the manager’s judgment, which is precisely the vulnerability the host presses.

QCan an employee successfully challenge an unjust manager through HR?

Evans thinks framing and timing matter: a manager may already have described the employee as a performance problem. An employee should instead bring factual behaviors and their effect on productive work, rather than lead with a demand that the manager be fired. Independent corroboration, an established performance record, and specific documented misconduct can make an uphill case stronger.

He says he has removed managers after multiple employee accounts accumulated and matched his own observations. He also thinks leaders often protect managers they personally like, even while employees leave. In one coaching case, a leader had tried for 18 months to improve a manager whose people kept quitting. Evans challenged the leader to consider what they would recommend if the same story involved somebody they did not like.

The practical limitation is institutional inertia. He believes leaving is often easier than persuading a hierarchy to remove a manager who has a good relationship upward. His numerical language about odds and first-mover advantage is rhetorical, not measured probability or a guarantee about any particular HR process.

QHow do performance and being liked affect power at work?

Evans describes poor performance combined with broad dislike as easiest to act on. A mediocre but widely liked colleague is harder to remove: no single disaster supplies an obvious reason, and others defend the person’s helpfulness and warmth. In his view, relationships therefore change the practical consequences of similar performance records.

He reconciles likability with boundaries by recommending ordinary friendliness and selective, modest pushback when an assignment or decision matters. Humor can communicate that a repeated pattern is unacceptable without creating a confrontation. His playful “tokens” example frames a limited amount of unpleasant work as something he will accept, then asks whether the manager wants to use part of that allowance now.

The token framing is an illustrative negotiation tactic, not a formal employment limit. Its purpose is to make a cost and expectation visible while remaining cooperative.

QFor job security, is being liked more important than performance?

He says the answer depends on context. Decisions can include considerations beyond output. A leader might defend a likable person by arguing that their presence will help morale and cooperation after a difficult event. Evans recounts a layoff discussion that used family circumstances, which he labels improper; the book treats this as his recollection rather than verified legal guidance.

A technically indispensable but unpleasant engineer can also be retained, yet the team may be actively trying to transfer that knowledge so it no longer depends on them. He calls that dependency a fragile form of protection. The aspiration is to be capable and decent, not necessarily unusually charming.

He adds that managers can feel insecure about their technical ability. Publicly humiliating a manager may threaten both ego and authority. People then rationalize retaliatory choices as serving a greater good. This is his account of a social failure mode, not a justification for retaliation or an instruction to avoid all technical disagreement.

QHow do you defend against peers undermining you while competing for a promotion?

If the behavior is already visible, discuss the pattern with leadership before a specific accusation defines you. Evans suggests asking to be judged on actual contributions and given a chance to demonstrate them, while declining to join a campaign of mutual attacks. He thinks this makes later disparagement easier for a manager to recognize.

If the accusation has already landed, ask calmly what the manager has heard and what evidence would give them a full picture. He recommends reflective questions, including mirroring a few words, to draw out information rather than immediately become defensive. Then make the work verifiable and agree on better future visibility.

He also describes supporting colleagues whose contributions are unfairly dismissed, which may help them notice a pattern of undermining. That can be constructive when it means accurately affirming work; his language about traps and planting doubt also shows how quickly defensive politics can become another political campaign. He returns to an important exit option: teams full of this behavior are not the only teams available.

QIf everyone uses political tactics expertly, does the best strategy change?

Evans first rejects the premise that workplace relationships must be adversarial. Honest credit sharing, growing people, better business performance, and rising equity value can produce shared gains. The darker cases in the interview are failure scenarios, not his ideal organization.

In the hypothetical where everybody maneuvers expertly against everybody else, he expects the advantage to cancel out. His practical advice is to find an environment where your particular combination of skills creates a clearer edge. For his own coaching business, he combines public speaking, career knowledge, and social-media experience; he does not need to be the best individual practitioner of each to have a distinctive intersection.

He compares being a star on a less prestigious team with being a bench player on a championship team. Status, compensation, learning, and preferred competition can point to different valid choices.

QDid you build an empire as an Amazon VP?

In hindsight, Evans says yes, though he often told himself that more people would let him execute more useful ideas. He recalls an Amazon Appstore staffing request that Jeff Bezos rejected because the proposed buckets were large and their purposes vague. After two weak answers, Bezos asked for a new plan with small groups of two or three people and exact responsibilities, then reviewed it line by line. Evans thinks Bezos was right: the team had imagined possibilities instead of doing the allocation work.

Later he tied expansion to concrete businesses, customers, and results. He describes negotiating staged releases of hiring capacity and proving that he could recruit good people into each tranche. The important difference was making resources produce value, rather than simply asking for a large team.

Merch by Amazon illustrates a pivot. His team tried printing merchandise for game developers as a way to attract apps to Amazon’s store. That original theory failed: merchandise was not important enough to change developers’ platform choices. T-shirt printing nevertheless found demand for slogans, events, and other designs, and became a separate business. Evans reports a very large later revenue scale, but that is his interview claim, not independently verified current financial information.

He also moved people from failed projects onto promising ones before leadership could reclaim them. He admits that colleagues might regard his tactics as slippery and that he rationalizes them by pointing to results. The interview preserves both the value he believes he created and the resource competition he participated in.

QHow should people prepare for uncertain AI effects on technical careers?

Evans offers predictions, not a crystal ball. He expects winners, losers, eliminated jobs, changed jobs, and new roles. He favors flexible learning and human skills alongside practical familiarity with AI tools. He worries that specializing only in operating a tool may preserve a role briefly while the work itself is automated away.

He also considers the opposing possibility: easier production can expand demand, just as tools have done in some other industries. People experimenting with software may eventually need engineers to make it reliable. He does not know which effect will dominate.

His central recommendation is to watch where value moves. More code or more features is not necessarily what customers need. Choosing what to build, what to omit, what to release, and how to explain it may become more prized. He would rather occupy a position requiring judgment and taste than depend entirely on manual operation of the tools. His claims about where AI is strongest or weakest describe his expectations at interview time.

QIs flattening the management hierarchy a permanent change or a cycle?

Evans sees pressure to remove layers as cyclical, especially when a company wants to keep headcount flat. He doubts that new tools remove the human need to organize, centralize, and communicate work. AI might let a manager oversee more people, but greater output can also generate more decisions and coordination needs.

He cautions against generalizing from exceptional leaders with many exceptionally senior direct reports to ordinary first-line management. A team of highly independent senior leaders is a different problem from a manager trying to scale from ten engineers to a hundred. His reference to a very long history of administration supports his intuition rhetorically; the transcript’s ancient-history details are not established here as verified historical facts.

QHow can you reduce layoff risk and explain a layoff without negative optics?

For explaining it, state the organizational fact briefly and truthfully, then turn toward what you can contribute next. If an entire organization closed, say that; do not imply a whole-organization event if it did not happen. Evans believes large-company layoffs have become common enough that such an explanation carries less stigma than it once did.

For prevention, he first admits that some layoffs cannot be avoided. He has seen leaders try to place key people elsewhere when an organization shuts down. Strong ratings, recognizable accomplishments, needed unique expertise, and visibility to leaders above the immediate manager can help someone be considered for those moves.

The pattern remains a combination of valuable work and relationships. He does not promise that either technical indispensability or executive familiarity guarantees protection when a business is eliminated.

QWhat is executive presence, and how do you develop it?

Evans defines it partly through what other people do: do they respect you in a room and seek your judgment even outside your direct work? He also cites a framework combining gravitas, communication, and appearance, with a roughly 60/30/10 weighting. That numerical framework is his reported reference, not an independently validated formula in this book.

He distinguishes expertise from the signals of authority. Confidence, decisiveness, controlled pace, pauses, body language, composure, and specificity can make somebody appear credible. He also points to unfair social biases involving physical appearance and identity; he describes those as biases people respond to, not as desirable standards.

His own failure mode is sounding more certain than his knowledge justifies. His wife has sometimes withheld a correct objection because he sounded so confident. He deliberately invents a precise “62%” statistic during the conversation to show how confidence and specificity can make nonsense sound convincing. That number is a demonstration of fabrication and must not be reused as evidence.

He says no single superficial trait is necessary. A strong record can create respect without theatrical speaking. The examples contrast a quiet, established expert with leaders who consciously control stage presence; they are his interpretations of public figures.

QHow do you build relationships at work organically?

Find something you enjoy, know reasonably well, and can share. Turn it into a class, talk, tool, recording, useful service, or advice. Giving something valued creates a common interest and a reason for future conversation without demanding that you become an expert at approaching strangers in a room.

Evans taught managers how to hire quickly and well, then expanded his teaching and online advice. Another Amazon employee arranged bulk ski tickets and resold them at a discount internally. That person benefited from something he enjoyed while building hundreds of connections with other skiers.

The expertise need not be extraordinary or even technical. Shared interest makes conversation easier, and sustained useful interaction can deepen into a relationship. Engineers can do the same with a technology they understand better than the average colleague.

QHow can you form an organic relationship with a powerful decision maker?

Evans starts with value you already provide. A useful tool, class, or service may interest a VP directly, or may matter because many of their employees benefit from it. A modest note explaining that usage can open a conversation without pretending to share a personal interest you do not have.

A network can also supply an introduction through someone who already knows the person. He recounts seeking help to transport medical supplies for Ukrainian refugees to Poland; a contact connected him to the chair of United’s board, and the bags traveled without the expected fee. The outcome was far beyond what he had originally needed.

His explanation is that a well-placed, easy favor can let the intermediary contribute to something worthwhile and feel good about helping. A network is therefore useful for needs that cannot be anticipated when the first relationship forms. He does not reduce every helper’s motivation to self-interest; he acknowledges the legitimate desire to help.

QHow did you respond when people approached you with an obvious networking motive?

He was often explicit about his limited time. For someone asking for regular mentoring, he sometimes offered one meeting and challenged them to bring an interesting idea or information he did not know. If the meeting created value and maintained his interest, they could have another.

Evans presents this as a more useful opening than a blanket refusal. Some people used the opportunity well; others did not return. His direct, transactional style suited him but is not assumed to be every senior leader’s preference.

QHow do you discover what someone wants when they do not explain incentives directly?

He gives four methods: ask, listen, triangulate, and observe. Listen to the problems and goals mentioned in meetings; ask people who work with the leader what they have heard; and examine where the leader puts time, money, hiring, and attention. Actions can clarify priorities that general statements obscure.

Then move toward something the person values and make that contribution visible through an appropriate route. That may be a report, a mutual contact, a hallway conversation, or a direct question. The style must fit the relationship.

Evans regards explicit value-for-growth agreements as fair when the opportunity is open to everyone, but recognizes that some people prefer implicit arrangements and tolerate less direct language. Building trust can eventually make a private conversation clearer even when the person remains indirect in public. Until then, more ambiguity may be unavoidable.

QWhen somebody disappears suddenly from a company, what may be happening behind the scenes?

Evans says abrupt departures can concern conduct or risk rather than an ordinary performance process: harassment, racism, theft, disclosure of confidential information, or similarly serious events. He recalls employees being removed after leaking internal material to reporters and leaving a trace in company systems.

He gives two unusual examples to distinguish intent and consequence. A game artist brought a real gun collection to the office as visual reference for weapons; leadership considered it thoughtless rather than threatening and sent him home with an instruction never to repeat it. In another case, a cleaner’s alarming harassment of a female employee led to removal and, in Evans’s account, an order barring contact.

The stories show why colleagues may see only the sudden absence while managers know a confidential conduct incident. They do not let an observer infer the cause of any particular unexplained departure, nor establish that every sudden exit involved wrongdoing.

QDid you ever have to harm somebody else to get ahead?

He is reluctant to claim an unqualified no because people rationalize their own behavior. He remembers competing and trying to come out ahead, but does not recall deliberately targeting someone for destruction.

The case he feels worst about happened in his first week at Amazon. He was offered a choice between a customer-facing video product and ingestion infrastructure supporting video, music, and books. He chose the product without knowing that another incoming manager had apparently been promised it. That person arrived the next week and received infrastructure instead, an outcome Evans believes was bad for him.

Even if told about the conflict, Evans says he would have advocated for the job that fit his experience and interest. He distinguishes wanting an opportunity from intending injury, while admitting that the other person still bore a lasting cost. Lack of malicious intent does not erase that result.

QWhat do you say to people who find the whole political game morally distasteful?

Evans shares the wish for a world in which merit, intentions, and contributions receive fair recognition. His defense is that people must navigate today’s limited resources and biases while trying to improve them. He believes transparency, honoring agreements, and coaching people through existing discrimination can help without endorsing the discrimination itself.

To make the moral conflict concrete, he recounts helping fund a bribe that, in his account, enabled a Ukrainian friend’s husband to leave military service after two years. He recognizes that somebody else may have borne a cost and says he does not know whether that consequence occurred. The story is his personal claim and moral justification; its legality, details, and effects are not verified by this transcript.

He is comfortable with the decision because it helped someone he knew, while admitting that it can be condemned from other moral positions. The example makes his approach more complicated than simply being helpful: he accepts partiality and uncertain external costs. The host’s ethical discomfort remains part of the discussion rather than being resolved by an editor’s endorsement.

QWhich books do you recommend on people, negotiation, and power?

His first recommendation is Leadership and Self-Deception by the Arbinger Institute. He takes from it the distinction between seeing people as humans with concerns and treating them as obstacles or interfaces whose buttons you press to obtain a result. The former can make cooperation warmer and less manipulative.

He recommends Chris Voss’s Never Split the Difference for negotiation and understanding motivation. He also reluctantly recommends The 48 Laws of Power as a catalog of darker tactics. He says awareness may help readers recognize manipulation, while acknowledging that the same material can be used to become manipulative.

QIf you were trying to reach VP as quickly as possible today, what would you do?

Evans would not assume that his Amazon path is repeatable in a company growing much more slowly. He reports that Amazon expanded dramatically during his tenure, creating opportunities that he thinks are less available in the setting discussed. His suggested hypothetical is to learn intensely for roughly 18–24 months, develop externally valued expertise such as AWS knowledge, then seek a high-growth company where that expertise solves an important adoption problem.

He would deliver value, make growth goals explicit, learn management, decision making, psychology, and organization, and take some large risks. He argues that high-visibility wins can accelerate advancement, while admitting that failures and multiple company moves may be part of the path. His language about leaving the “smoking ruins” of failures exposes a real cost of optimizing solely for career speed; it is not a guarantee that repeated risk-taking succeeds.

He thinks early engineering-level growth may still be possible inside a mature company, but higher-level advancement increasingly requires an available business case. A skill that makes you one among thousands inside a large company can make you uniquely valuable elsewhere. His employee counts and salary comparison are illustrative approximations, and his recommendation reflects the interview’s market view rather than a verified present-day forecast.

QWhat did your career look like before Amazon?

Evans wanted to work in computing as home computers emerged. Apple’s reply to a letter about employment helped shape his choice of university; he attended Carnegie Mellon and later completed a master’s degree at Purdue. His early jobs were a sequence of small companies connected loosely by networking, search, network management, advertising, and audio streaming, with a brief detour into entertainment lighting.

Amazon eventually recruited him partly because streaming-audio experience fit its planned video work. Most of the startups after his first struggled or failed around the dot-com era. He describes being made redundant twice, with his confrontational behavior contributing. Becoming an Amazon VP was not his initial life plan; the path evolved.

QWhy did you initially choose startups over established companies?

The first choice was driven mainly by friends and an apparently attractive opportunity, not a carefully reasoned comparison of company sizes. Friends joined a local company founded by professors and introduced him to stock options. An earlier-joining roommate did especially well; Evans joined later but earned enough for a house down payment. Only afterward did he learn to make more intentional career decisions. The story illustrates why a successful early choice need not have begun as a sophisticated strategy.

QDid you see the layoffs coming, and what part did abrasiveness play?

No, despite warnings. His first manager had already noticed combative problem-solving, and Evans once proudly framed being a “loose cannon” as being aimed at people who were wrong. Technical ability and energetic execution still carried him into startup leadership, but peer conflict became increasingly costly.

In one company, a product leader warned that the planned scope could not be delivered with available time and resources. Evans now thinks the warning was correct; at the time he treated it as disloyalty to the mission. During downsizing, he offered to leave for another startup, and the CEO accepted. He suspects removing conflict made that easier.

In the next company, he argued with a sales leader who promised capabilities that did not exist. Evans still sees the truthfulness problem, but recognizes that the company was fighting for survival. He was the only person in the resulting “layoff,” so he regards it as being fired to remove contention. After the second experience, he finally investigated his own recurring role in the pattern and changed how he dealt with disagreement: more questions and listening, less escalation.

QWas early aggression useful, or would interpersonal skill have made it better?

Evans thinks energy combined with good interpersonal skill would have been better. He still favors having an opinion and advocating for it; pure compliance is not his model of leadership. The difference is how one argues. His earlier version raised his voice and dismissed ideas as stupid. A more skillful version can be persistently challenging without being abrasive or hostile. Being right often let him get away with the poor version, but did not make it the best version.

QHow can a leader avoid being removed through politics behind their back?

He says excessive confrontation can cause people to stop debating with you and start discussing you with others. The first defense is to leave enough room for honest disagreement that people do not feel a private campaign is the only route.

The second is a wider set of trusted relationships. Evans lacked allies who would tell him when another peer raised a concern; instead those people agreed that he was a problem. Technical correctness cannot replace relationships and the feeling people have while working together. He acknowledges that organizations sometimes choose a less technically good solution because it feels easier to support.

QWhat finally made you take interpersonal skill seriously?

The second departure, followed by difficulty finding another job after the dot-com crash and September 11, forced reflection. An interviewer challenged the story that he had been so valuable yet could not be retained. Evans concluded the missing capability was not coding or driving projects, but working well with people. He studied motivation, questions, and the psychology of work, then became interested in how to lead and inspire rather than only state answers. The painful feedback became a sustained learning interest.

QWhy was moving across the country to Amazon worth the risk?

While at a search company partnered with Barnes & Noble, Evans had investigated why that retailer was losing online to Amazon. Seeing Amazon through a competitor gave him a concrete appreciation of its capabilities, which he could discuss when Amazon’s recruiter approached him.

He was also tired of startups struggling with funding and product-market fit. Amazon was public and not yet profitable, but its scale looked stable compared with firms of dozens or hundreds of people. The decision combined admiration for the business with a desire for a different risk profile; it was not a bet on the million-person company Amazon later became.

QWhat did promotions to director and then VP actually require?

For director, Evans describes the ability to lead a business or major effort with only high-level goals. In his case an outsized event mattered: he pursued a video partnership with TiVo despite leadership’s advice against it, explicitly giving the senior leader a chance to order him not to proceed. It worked, and his promotion narrative emphasized that the partnership would not have happened without him.

He also made his career priority clear to his VP, who was preparing to leave. Evans politely explained that if Amazon did not value his growth as much as he did, he would need to consider that. The timing created retention pressure because both leaders leaving would damage the project. He sees both demonstrated judgment and explicit advocacy as central.

He admits a troubling managerial tradeoff: when two people were similarly qualified, the one pushing for advancement and threatening to leave sometimes got priority over the patient team player. He describes practical retention pressure rather than defending it as ideal fairness.

The successful project was a genuine risk. An ordinary result might have left him where he was, while a disaster after ignoring advice could have hurt him. He would take more calculated risk in retrospect, but his outcome does not erase the possible downside.

VP involved a longer process of building stakeholder support and trust with a stable manager. He worked on a partnership in which he would solve important problems and his manager would advocate for recognition. After roughly two and a half years, the VP agreed to stake his reputation on the attempt, without guaranteeing the final decision. A reorganization soon afterward highlights how favorable timing mattered alongside effort.

QWhat went wrong when you promised a strong engineer a promotion early at Amazon?

A young engineer agreed to help ship the first version of the product in return for support moving from the entry engineering level to the next one. Evans agreed in good faith but assumed promotion worked as it had in startups. He was preoccupied with launch problems and did not know Amazon had fixed review cycles. The window passed.

He explicitly owns the error. The engineer was not responsible for the manager’s ignorance, yet the engineer bore the career cost. Evans recommends that employees learn the process anyway: check whether the manager knows it, identify deadlines, and ask about concrete documents and dates. A new manager may sincerely intend to help while lacking the necessary procedural knowledge.

The engineer left and had a successful career elsewhere. Evans regrets the lost time but stresses that a year’s setback need not define a career lasting decades. The appropriate lesson is both managerial accountability and employee awareness of the process, rather than blaming the employee for a broken promise.

QWhy leave an 800-person organization for the Twitch integration role?

Amazon used a VP as an integration liaison after acquisitions, while leaving the acquired company’s CEO in charge. Evans sought that position after Amazon bought Twitch because it would test influence without authority. He would advise the CEO rather than command him, with no team of his own.

He had learned to run a large global organization with formal authority. Now he had to work with a younger, newly wealthy founder serving an audience and business culture different from his own. He gave up the large team to learn that challenge and enjoyed both the partnership and learning to stream on Twitch.

QWhat gaps did you see in a young founder running a rapidly scaling company?

Evans recalls Twitch treating continuing losses as normal because venture funding had always been available, and initially assuming Amazon’s money made profitability less urgent. His leadership wanted profitability, so a core challenge was establishing that the objective mattered at all.

He also saw the difficulty of loyalty to early employees whose skills did not scale with the organization. Bringing in a more experienced leader above a friend, or changing their role, required hard conversations and sometimes led to angry departures. He notes that the founder might describe the gaps differently; this is Evans’s view of the learning process.

QHow did Jeff Bezos and Andy Jassy differ as leaders in your experience?

Evans reports dozens of meetings with each and emphasizes founder status as a major difference. He recalls a budget discussion in which Bezos answered a warning about limited cash by asking how much there was, because he might want to spend it. Evans interprets that as the founder claiming the authority to take extraordinary bets with the company he created.

He describes Jassy as a more conventional executive who must partner with other leaders and operate within board and founder expectations. Both demanded a great deal.

His personal fit differed too. He felt Bezos’s questioning was followed by enthusiasm and a sense of shared commitment, while Jassy’s questioning felt more like scrutiny followed by personal accountability. Evans explicitly says other executives could have experienced the opposite. This is a comparison of his working relationships, not a universal ranking of either person.

QWhat happens to a VP’s review when a business initiative fails?

Evans distinguishes meeting near-term goals from achieving the business vision. Prime Gaming could ship features and meet some financial targets without making Amazon the major gaming force its founder imagined. He says he received strong VP ratings even while some businesses did not deliver that larger ambition.

He recalls expecting to hit all his Appstore goals while considering them ultimately unimportant. His broader criticism is that large organizations can let products persist because nobody wants to admit failure or close them, while nobody knows how to make them major successes. His comments about later shutdowns and possible future gaming outcomes are interview-time claims and speculation.

QWhat do stack ranking and performance plans get right and wrong?

Evans describes a historical Amazon attrition goal that pushed managers to deal with weak performance. When it was removed experimentally, he says managers avoided hard conversations, particularly with well-liked people, so the goal returned. He gives varying annual proportions as recollections of the system, not current verified policy.

The problem is that a quota can turn a support process into a departure process. By the time a manager writes a PIP, they may already have decided the employee should leave. Confirmation bias and pressure from HR or leadership to record an exit can work against genuine recovery. Taking one employee off the list may create pressure to identify another.

He reports that the people who asked him for help on Amazon PIPs were later fired, as were several who did not use his coaching. He now urges people to prepare for another role. His strong warning comes from personal cases rather than a controlled success-rate study.

His diagnosis is that companies often do not train managers to address issues early or conduct useful difficult conversations. A formal plan arrives late and under distorted incentives, even when the manager initially believes they intend to help.

QWhat prevents a manager from framing a report unfairly?

Evans distinguishes a pattern of removing many employees, which can become visible through turnover, from one targeted case, which may be hard to challenge. The manager has status and can establish the performance narrative before the employee complains.

The same review count can support opposite narratives: a strong engineer improving everyone’s work or a person nitpicking while producing little original code. Neither count alone answers the value question. The manager may be malicious or may honestly evaluate the work differently.

He says he has not personally targeted an employee this way, and recognizes that good managers benefit from capable partners. The danger concerns a vindictive leader with power over the narrative. His practical advice is to improve the relationship if possible or find another manager, rather than assume HR will automatically rescue the employee. This is an account of a vulnerability, not an endorsement of unfair treatment.

QWhat advice would you give yourself at the start of your career?

Keep preferring growth. He compares his career ladder to an escalator because fast-growing businesses created upward movement alongside his own effort. The scale change he reports at Amazon supplied opportunities that personal drive alone could not create.

Learn sooner that work is done with humans. Expertise and being right should be paired with friendships, trust, and being known. An introvert can use writing and online tools rather than force a single extroverted style. Amazon approached him, and he sees a strong reputation as part of what makes that kind of opportunity possible.

QWhat most explains your rapid rise to senior staff at Uber?

Attwell credits the combination of a growing engineering organization, strong people to learn from, and a culture he experienced as meritocratic. Growth supplied many problems, though he acknowledges that a company does not need growth to have useful work. He also regards caring about the team as essential to sustained success.

His intentional choice was unusually intense work. He believes learning compounds and that managers assign valuable work after seeing evidence of capability, so he created time to develop that evidence himself. Early in his career, he expected to have more discretionary time than later. His claimed relationship between effort and growth is his judgment, not a demonstrated universal formula.

QHow much of that trajectory was luck?

He separates frequent actions from infrequent decisions. Doing many small things well repeatedly gives less room for chance than choosing a company once every few years. He chose Uber intentionally, but recognizes that the choice could have gone wrong.

He thinks his effort and mindset would probably have served him well inside that particular merit-oriented setting. Joining an organization that did not value the same contributions could have delayed growth. He explicitly rejects a fully deterministic mapping from personal effort to career outcome.

QWhat signals made Uber attractive, and how would you evaluate another company?

He would examine the quality of engineers and the hiring process that brings them in. He favors difficult, job-relevant tasks requiring reasoning about conflicting requirements, rapid assimilation of new material, and tradeoffs, rather than only recalling practiced solutions.

His example is reading a complex postmortem and debating what it reveals about the team or architecture. He believes designing good interviews for many distinct roles requires substantial leadership effort and ongoing experimentation. Assertions about tests and intelligence reflect his hiring philosophy, not independent scientific validation in the episode.

QHow would you test the reasoning ability you are looking for?

Attwell prefers tasks that require keeping multiple ideas and constraints in mind while remaining relevant to the job. An applied programming problem with conflicting requirements or a postmortem whose details challenge one another can reveal more than practiced recall.

He is also considering formal intelligence screening, especially to reduce the time spent on unsuccessful PM interviews. He describes such tests as a screening aid rather than a complete ranking of already strong candidates. His statements about their trainability, predictive value, and AI’s limitations are attributed claims and are not established as research findings by this transcript.

QWhy are product managers harder to interview than engineers?

He sees the role as less consistently defined, more varied across disciplines, and lacking the same established educational and interview traditions. His organization asked several CEOs what excellent PM work looks like, wrote its own definition, and designed a process around it because there was little it wanted to borrow unchanged. He again frames intelligence screening as a possible early filter, while leaving later interviews to distinguish good from exceptional applied performance.

QBeyond being smart, how do you choose the best use of your time?

Attwell agrees that other skills need conscious development, especially prioritization. He considers the value of an initiative over a fixed period, how much his involvement changes its chance of success, and the time it will require. He is trying to maximize incremental expected value per hour.

The company’s top priority may already be well staffed by the time a junior engineer hears about it. A less prominent but still valuable initiative may have a larger gap that the engineer can fill. Working on the most important project and making the largest personal contribution are therefore different questions.

QHow can an engineer learn to estimate business value?

Ask why a metric or quarterly goal matters. A model-recall target might be intended to reduce churn, which in turn relates to revenue. Use one-on-ones to understand why leaders choose or cancel projects. If the company has an initiatives sheet with estimated value or a reason each project matters, study that column: it exposes other people’s reasoning and helps build intuition. He expects this to be learned, since most new engineers have little business background.

QWhy did you eventually become a manager?

He delayed the move despite several managers recommending it. At his later company, a strong group of engineers already treated him as a technical leader, so he enjoyed directing work without the full obligations of formal management. When his boss said the group needed either him or a newly hired manager, he accepted because he wanted to protect a team and technical vision he cared about.

He initially did the job poorly, hiding in coding instead of handling management fundamentals. A new teammate once asked after three months whether Attwell was actually his manager. He took that as evidence of neglect, improved those skills, and afterward saw the organization reporting to him grow rapidly. The story does not make technical leadership an automatic substitute for people management.

QWhy did more organizations keep moving under you?

He begins with a belief that even a strong team may have major room to improve. Rather than preserve every inherited practice, he invites people to question assumptions, including his own. Suspicions about a long-standing process are useful starting points for discovering waste.

An integrations team maintained about 1,200 connections intended to gather restaurant-industry information. Each had once seemed a good investment, but maintenance had accumulated without a fresh comparison of value. A colleague questioned how all of them could still be equally important. The team spent days estimating their value distribution, stopped supporting a low-value subset, reduced pages, and improved support for the important remainder.

He describes the overall product as improving even though it now supported fewer integrations. Reclaimed time also enabled new work. The example shows how subtraction can create capacity when the useful outcome is broader than the count of supported items.

QHow do you handle the people conversations when scope moves between leaders?

Attwell says these conversations need empathy and honesty. A capable person may nevertheless not be delivering what a particular role now requires, or may need a smaller scope. Explain the needed work, identify the gap, and recognize what the person still does well or contributed previously. His description favors clear expectations over hiding the reason for an organizational change.

QHow can incentives keep managers from clinging to scope?

He regards an automatic link between promotion and organization size as a poor design because it encourages empire building. His company originally borrowed a ladder resembling Uber’s, then attempted to improve it. Travis Kalanick challenged the revision as still too focused on scope and insufficiently insightful.

Attwell and a colleague then invested months in understanding other systems’ weaknesses. His core concern is that scope captures one kind of complexity while rewarding position and political maneuvering more than useful ability.

QWhat changed in the redesigned leveling system?

They began with roughly a thousand examples of people differentiating themselves through real work, grouped those into about 250 attributes, and used an analysis he calls principal-component analysis to arrive at twelve skill dimensions. He describes compensation as rising with demonstrated skill and impact along those dimensions rather than primarily with position.

The emphasis shifts from influencing teams as a status marker to having sound ideas, including successfully questioning foundational assumptions. Communication remains a separate competency with examples of good work. He wants people to improve capabilities that generally help the company even if they are also trying to earn advancement.

QIs it especially difficult to remove an underperformer whom everyone likes?

Attwell disagrees with treating this as an insurmountable problem. A frontline manager may feel attached and see the social bonds, but hardworking colleagues may also resent covering for the person. He expects a difficult immediate response can give way to a happier team afterward. This is his view of the tradeoff; the episode does not show a particular termination or prove that this outcome always follows.

QHow do you provide evidence of truth-seeking?

Look for useful discoveries that challenge accepted practice: an important problem in plain sight that nobody recognized, or a justified departure from an industry norm because the team’s constraints differ. A novel opinion by itself is not enough; there needs to be value and reasoning behind the divergence.

He admits subjectivity remains and managers must be calibrated on examples. Existing technology-company ladders are not wholly broken, and he expects changes at the margin rather than completely different results. The distinction he wants is somewhat more attention to the leading behaviors that produce good results, rather than rewarding only an already-achieved position or outcome.

QCould excellent work still be rewarded when its project gets deprioritized?

Yes, in his system. If a person did excellent work and leadership cancels the project for a reason unrelated to that work, the person’s contribution can still be evaluated. He places responsibility for late cancellation partly on leaders. At the highest levels, he expects greater business judgment about whether a project should exist, so that qualification changes how the case is assessed.

QWhy do some large companies fail to reward their highest performers strongly?

Attwell thinks they can sometimes retain people anyway, especially when appreciating equity already makes compensation feel good. He objects to using past investment gains as a reason to reduce future reward and says his company tried to avoid that. He favors designing processes around fairness for long-term organizational benefit. These are his judgments about incentives, not a verified description of every large company’s pay policy.

QWhat did starting at Google teach you?

It left him skeptical of how well large technology companies are managed. He recalls a teammate he thought did little work, yet a manager and director emphasized that the person was pleasant and liked. Attwell complained, and the person eventually moved elsewhere, though he cannot prove his complaints caused the move.

He thinks leadership should at least have had a serious performance conversation. The anecdote is his perspective on one situation, not an evaluation that the reader can independently verify.

QWhy might a large company avoid that hard conversation?

Attwell argues that individual-team performance can be weakly connected to a large company’s near-term results, letting managers prioritize convenience over difficult improvement. Raising standards takes energy; asking less of people often creates little resistance. He expects standards to drift downward unless leaders deliberately counter the trend or a crisis forces change.

He also reports that several Google managers told him of a past strategy to retain smart people even when they were not productive, partly to keep them from competitors. He explicitly says he did not see this in writing and cannot prove it existed. That uncertainty is central; the anecdote should not become an established corporate policy.

QWhat is it like working directly with Travis Kalanick?

Beyond the familiar intensity, Attwell sees a patient teaching side. At a senior-engineering offsite, Kalanick taught backgammon and coached people in water skiing between work sessions. Attwell describes enjoying that patience, including with less athletic teammates. This personal story adds a different dimension without claiming it represents everyone’s experience of the founder.

QShould someone choose an early-stage company largely because of its founder?

He thinks that can make sense because a founder with substantial control shapes composition, culture, and standards. A strong person can multiply the company’s effectiveness, while the wrong leader can do the opposite. The advice is to assess that influence carefully rather than treat founder reputation alone as a guarantee.

QWhat advice had the greatest impact on your career?

A high-school computing teacher repeatedly told him to figure things out himself. Attwell never knew whether that was deliberate teaching or simply the teacher not knowing the answer, but it helped him accept self-directed learning. He believes most professional learning requires that habit: keep moving beyond the area in which you are already comfortable.

QAre there notable stories from your growth into a software development manager at Amazon?

Stefan says his ownership meant he was often the de facto tech lead and effectively acted as the team's manager, because his boss had no time for the niceties managers normally provide. The title lagged what he felt he was doing, so he pushed for it.

He believes he got it prematurely. People feel ready, he says, without realizing how far they have to go. Most new managers make many early mistakes, and the support structure around them largely decides how they fare. His first year was uncomfortable and he was failing in ways he did not fully see. Around 18 months in he began to get a knack for it.

QDo you have tips for improving storytelling?

Stefan calls storytelling a bedrock skill and says part of it is practice. People tell stories all the time without attending to them: recalling details is a story, and so is the motivation you give yourself to get out of bed. His first trick is to notice those moments and ask what story he is telling himself today, since one version helps you get up and another does not. Once you can critique your own stories, you can practice telling them better.

He says it came naturally to him as a manager. Every few months he looked back over what the team had accomplished and painted it clearly so people could feel proud, for example that they started as a team of two with a poor on-call, fixed it, and used the freed bandwidth to deliver.

Stefan's claim is that a team that feels it is winning, with the manager defining what winning means, gets much else downstream: people avoid zero-sum thinking and bickering, and feel excited about their work. Without that story, such problems fester.

QWhat was your manager doing, and how did you get to do the manager's role before having the title?

Stefan's manager was a senior manager expected to manage other managers but did not want to hire other SDMs, or wanted to delay as long as possible. Stefan's impression was that this was a way of keeping control of the product, which the manager loved: working with design and refining it for market. Stefan finds it debatable that this was the best use of the manager's time. Tasks a manager traditionally owns, such as checking progress, understanding careers and mentoring, fell by the wayside.

QAt the end of your Amazon stint, what made you leave and join Meta?

Stefan first stresses that Amazon is a special and worthwhile place, undoubtedly successful and with a strong engineering discipline. His reasons for leaving built up after a considerable time there.

First, succeeding at Amazon involves assimilating into a distinctive leadership style the company called its peculiar ways. He came to feel that makes you a good Amazonian, not necessarily a good engineering leader, and he worried he was not growing. Second, Amazon keeps compensation more even, at some cost. He recalls a promotion or very high rating with no change to his compensation, explained by stock appreciation, which he found frustrating since it applied to the whole team.

Third, when a Facebook recruiter reached out, he was not a fan of the product but admired the engineering culture. The team was in integrity, working on child safety and preventing terrorism. At Amazon, his supply chain and ML work moved profitability, which had some effect on people but not the same qualitative impact. The first two reasons made him look, and this one tilted him into the move.

QWhat was the story behind your promotion from frontline manager to senior manager?

Stefan was promoted about three and a half years into Meta, after roughly seven managers in that period. That turbulence held him back, and he suggests part of his promotion story is how to handle organizational shifts while keeping momentum.

On joining he wanted to be useful quickly, so he joined the on-call and wrote code, which built trust with his engineers and peer teams. That cannot be sustained, so he shifted to recruiting, where he says he had a blank check from his director. How people perceive a manager is a headwind or a tailwind, he says, and being pigeonholed can be devastating because people struggle to update their view of what someone will become.

Once his team's effectiveness was shown, he was given an additional manager. Leading a leader, he says, is yes and no the same as leading engineers: a far smaller shift than becoming a manager, but treating it as identical fails quickly, and for many it ends in mutiny. In manager stacks there is an unstated competition, since if the org is not growing, leaf-node managers can advance by taking the place of those they report to. His promotion came when his org reached about 30 to 40 people. By then he sat in calibrations alongside other M2s, and it was hard to deny he was doing the job.

QAre managers harder to lay off than ICs?

Stefan says moving managers is inherently painful because the blast radius is larger. Whether removal is hard depends on whether the person is load-bearing: someone with a tight team and deep domain knowledge, whose cross-functional partners are not pulling their weight, is very hard to move out. If the team sees little value and partners complain, removal can even be invigorating.

On layoffs, he does not think managers are less likely to be cut. Most companies target a ratio of managers to ICs, so after cutting many ICs they need fewer managers. Companies also do span-of-control reductions, which he believes Amazon did recently, and managers go first. He does not think it is easier or harder for a comparably leveled IC.

QWhat leadership is most effective in a very small company versus a very big one?

Stefan says small companies need inspirational executors. Work is all hands on deck, and people want to work for someone impressive who could do their job and step in. As companies scale this gets harder, and those same people often lack the organizational aptitude needed. In big companies, he says, focus is a precious commodity. Go-getters who run at an opportunity without aligning or moving information up and down the chart get in the way and siphon energy from core initiatives.

He contrasts how Amazon and Meta scaled. Amazon built concrete API-like boundaries between teams, each owning two or three metrics, so leaders could assemble dependable pieces into a tall stack. The cost was value lost in organizational seams and slow response to change. Facebook's org was malleable: engineers moved between projects, assignments were weak, and code was communally owned. Its leaders needed soft alignment skills, knowing people's strengths and how to move and inspire them.

Stefan adds a caveat: a company cannot be staffed only with organizationally savvy people, since it turns negative-sum, with sharks fighting each other. As an example he offers OpenAI, noting he has not worked there and is relying on its hiring process and conversations with people inside. Its interviews favor technical achievements over organizational skill. It has plenty of politics, he says, but in its early phase it needs technical achievers to attract talent. As orgs grow there is entropy, and a need for people who can navigate it.

QIf a typical M1 were dropped into an M2 role, what would be the biggest skill gaps?

Stefan says the main gap is credibly adding value to the people who report to you. Managers of managers have fewer ways to interact with teams, and a straight M1 struggles to recognize those limits and where to use the important ones.

His illustration is a new M1 who sets up skip-levels and asks an indirect report, Jan, leading questions about whether her manager, Jim, is doing the job. Jim confronts the M1 a week later, and Jan says the M1 has insights Jim lacked. The M1 has disintermediated Jim, demotivated Jan and created new problems. Small acts by a senior leader have magnification effects, he says, and you learn them by observing or by having a good model of how things propagate.

Such mistakes are the easy way for a new M1 to fail, and he says leadership expects them, as with a first-time manager. Strategy and org design mistakes come later, but small behavioral ones in the first weeks can sink you.

QHow do IC and management growth paths compare, and are both meritocratic?

Stefan says at high levels everything becomes opaque and fuzzy. In calibrations he found it hard to stomach very senior ICs talking a big game without visible evidence, since it was unclear whether they were merely around valuable initiatives or instrumental in driving them. The same goes for managers: attribution is hard. Over a long run, such as four years of continued success in a role, it is undeniable, but on a half-to-half basis it is dubious.

For ICs at the sixes and maybe sevens, an outside observer can tell more easily, and an M1's team and deliverables allow a decent read. Further up, someone outside the leadership chain cannot see as clearly, and Stefan sees some unaccountability in much of management, comparable to judging a company's leadership team in the stock market. At some level, he says, it is difficult to have the data. The host summarized this as early promotions being easiest to verify and later ones more open to optics and narratives, and Stefan said that was a good summary.

QWhat cultural differences stand out between Meta and Amazon?

Stefan says Amazon is disciplined, a major strength, and he would expect more structured design reviews there. He thinks Meta engineers were on average a bit stronger but less disciplined, so reviews were fuzzier. Amazon was more predictable, partly because the business moves slower and partly because you can rely on other teams to meet SLAs. At Meta you might have to make the change yourself because the owner now works on photos. Many who move from Amazon to Meta find the unstructured environment paralyzing.

At Meta, the main positive he saw was openness and collaboration: engineers on his team worked with orgs across the company, such as a researcher in Paris, often without him setting it up. He also liked Meta's focus on empowering people. Amazon is process-oriented: when something fails, it adds a mechanism to prevent a repeat, whereas at Meta someone is more likely to say they learned the lesson. That has downsides, he says, and many of Facebook's privacy issues reflect an inability to do the process work Amazon does well. In ML, he was surprised by how hard data access was at Amazon, with teams building their own data lakes, while Meta had one shared warehouse.

Stefan prefers Meta's approach, especially for leadership, but missed some things from Amazon. For some people, he thinks Amazon is the better fit, since they would like it more than Meta's chaotic execution.

QHow do the performance systems at Meta and Amazon compare?

Stefan says they are pretty close. There is a public process in which ratings are set and given to reports, and a more private process, usually limited to higher levels, to decide where to invest: a top-tier designation at Amazon, additional or discretionary equity at Meta. The aim is to find the linchpins the company wants to keep. Whichever company, people must believe the process rewards performance.

He once tracked the time spent on Meta's review cycle (PSC) and estimated the cost at about $15,000 per engineer. The tempting reaction is that this is wasteful, but he says that misses the forest for the trees: the integrity of the review process is the whole ballgame, and if people do not believe it produces outcomes for them, they will not perform.

One difference he saw is that Meta was willing to go to bat for the upper quintile. Amazon, partly from frugality and partly from fairness, did less of this. In his org some engineers received about twice as much compensation as peers through extra equity, because they were seen as very important and going places. At Amazon that is uncommon, and the company tends to find a way to pull it back.

QDid you experience low-performer quotas, and how do they work?

Stefan says every company of scale has them. In Meta's PSC process a merely good half gets written up as world-shaking, and assessments inflate in a way that cannot be true on average. Companies therefore target a distribution and, to keep performance high, must let some people go. Managers dislike this, Stefan included, but if a team does not act on a low performer, the team suffers because it no longer seems fair.

He says the share placed in the lower bucket varies, typically seven to 15 percent and sometimes up to 20, called needs improvement at Amazon and, per the captions, meets some or meets most at Meta. Some in that bucket are expected not to make the cut, and that is when PIPs start. Managers fight to keep people out, mostly to save face.

The worst scenario, he says, is telling a team how hard they have worked, then being told by your director that someone must be in the low bucket, and having to tell that person their work was not acceptable. A better case is a manager who messages a lower-quartile outcome early, so nobody is surprised.

QWhat are your thoughts on job hopping, given you stayed in roles for around four years?

Stefan says that for ambitious people at lower levels, moving usually has advantages, because growth tends to come when you are uncomfortable in a new environment and must generalize your skills. He has not subscribed to it himself, since his motivation is going deep: after about two years he reaches the point where he can make an impact, which he finds most rewarding.

At higher levels, he says, frequent moves are a bad sign, because it is hard to get deep enough to build relationships and understand the domain. As a hiring manager he would second-guess a senior person moving every 18 months or two years, since he would invest a year ramping them up and then see them leave. For a mid-level hire that is a decent tenure, but for staff level he would hesitate. Early on, moving makes sense; as you get more senior, it pays to find places to put down roots.

QLooking across your career, when did you grow the most, and why?

Stefan says mostly at transitions, when he is in a new space learning and applying at once, which stress-tests his skills and shows what is durable and what was fake. Moving to Facebook stretched him, from a leadership perspective, in unexpected ways amid a lot of stress in the company. The pivot into an ML-focused role left him feeling he had a lot to prove, which brought external pressure he appreciated.

Other growth happens over smaller spans. A lot of his effectiveness as an IC and manager comes from writing well, which he largely learned at Amazon. He says some of Amazon's writing culture is a waste of time, with people nitpicking trivia, but the company encourages good writing, which means good thinking at some level.

QIf you could advise yourself just after college, what would you say?

Stefan says he could have been better about finding mentorship. He did much of it alone, and asking someone like himself three questions might have saved months of toil.

He also points to written plans: taking stock of where he was, deciding where he wanted to go, and building a checklist. He still has an old plan in his Dropbox for getting into ML. Such plans paid incredible dividends that he still under-emphasizes. Most people lack the agency to decide where they want to go and then take it, but the world is very malleable to such plans.

He recalls that shortly after becoming a senior manager he told his boss and director a long list of things he would get done, many of which he did not know how to do. The director later told him that this was the moment he knew Stefan would succeed in the role. Lack of agency holds many people back and is hard to instill, Stefan says, but forcing yourself to write a plan for what you really want has a huge gradient on your ability to grow.

QHow did the failed project affect performance reviews, and should an engineer fear canceling a project?

The guest describes negative performance feedback as the signal that forced him to face the problem. A new manager saw the work with fresh eyes and told him it was not working. Rather than protect the framework indefinitely, he took responsibility for ending it.

That meant helping teams migrate their existing products and features to native code, React Native, or another chosen approach, and deleting the framework entirely. He did not leave a permanent remnant that someone else would need to maintain or clean up. He also shared the lessons. In his account, this responsible closure earned goodwill and helped his standing in the immediate aftermath. It does not mean every failed project improves a review; the point is what accountable cleanup looked like in this case.

QLooking back, what signals should you have acted on sooner?

He says he knew during the project’s last year that it was not going well. His instinct as a prolific coder was to write more code and convert more features until adoption took off. That response avoided the harder conclusion that the project itself might be wrong. He wishes he had acted on the unease sooner and found another useful way to contribute.

QHow many people does Amazon expect to manage out?

The guest declines to give an exact figure. Five or six percent appears as a hypothetical illustration, not a disclosed quota. In his account, guidance became more of a mandate in recent years, while a lack of backfills made repeated cuts more troubling.

He acknowledges the limits of his perspective as someone who considers himself a high performer: he has participated in decisions but cannot fully represent the experience of fearing dismissal. He stresses that performance conversations concern real people and emotionally consequential outcomes.

With ordinary backfilling, he could view some departures as an exit from a cultural mismatch. Without replacement, repeated cuts reach people who would previously have been considered strong enough. He was surprised by colleagues who lost their jobs and is particularly uneasy about applying percentages to very small management populations.

QWhat happens in performance discussions, and how does a senior IC participate?

Senior engineers begin to be pulled in, and L7 or higher participants are regularly involved in his account. He describes lengthy meetings that can reduce people to metrics and feedback. He does not disclose the detailed process, but says it is not a simple linear algorithm. Time tends to concentrate on the edges of the distribution rather than allocate equal discussion to every person, partly because the population is too large.

QWhat advice would you give engineers near the performance boundary?

He dislikes treating a difficult fit as proof that the person is inherently a low performer. Passing a demanding interview already suggests considerable ability; the company’s expectations, culture, and the person’s assumptions may simply differ.

His advice is to identify the specific dimension on which expectations are not being met, then work toward solid performance before targeting exceptional ratings or promotion. Ask the manager directly what the expectations are and whether you meet them. If something is missing, agree early on a concrete improvement plan.

He views this as proactive growth rather than waiting for a formal performance-improvement process. The point is to discover actionable information while there is still time to respond. His estimate that few engineers explicitly ask about expectations is an impression, not a measured survey.

QWhat led Singleton from individual contributor to manager so quickly?

Singleton was an engineer having a great time and was surrounded by product managers who helped the team see its impact. Singleton walked into the manager's office and said they wanted to be a product manager. The manager suggested engineering management instead, arguing it would give similar fulfilment from impact while keeping technical work. Google then had a role called TLM, or 'Uber tech lead', and Singleton found the choice easy. Singleton acknowledges that the team needed managers, so they were also solving the manager's problem, but says they get real energy from helping people do more together.

Singleton stayed deep in the details, writing code and designs, and over time managed several teams at once, with management taking most of the normal work day. Google encouraged its 20 percent time, and for a couple of years Singleton managed teams during the day and then worked on personal engineering projects once people went home, at a time when Singleton's spouse had a very busy job. One of those projects was the first version of Google Translate on the iPhone. Singleton's advice for anyone who loves code but wants managerial impact is that if you can find a place to do both, it can be very fulfilling, and if something gives you energy, go at it.

QAs a VP at Google, was Singleton still doing feature work?

Not as a critical contributor, Singleton says. But Singleton believes deeply, and took the idea to Stripe, that however senior you are, effective leaders find a way to experience the team's work at what Singleton calls the one-foot level. As VP of engineering running Android Wear, which Singleton describes as the foundation of the wearables platform in Google smartwatches and which Singleton ran almost like a general manager across product, engineering, partnerships, user experience and marketing, Singleton found it valuable to experience the toolchain the engineers used. Roughly every two or three months Singleton did a small project in the codebase, which made it easier to ask smart questions and see what was needed to unblock people.

QWhat is the best way to decide between becoming a manager and staying an individual contributor?

Singleton agrees with the advice that managing and individual contribution are different jobs and should not be done together, and has given that advice to many people. If you are considering management, Singleton suggests finding an environment where you can do it full time, set your own individual work aside, and pay close attention to what makes the team productive and happy. People who do it that way tend to thrive, while doing both is harder unless carefully structured. A company willing to let you try management on a trial basis is fortunate, and Singleton recommends taking that option if it exists.

When people tell Singleton they want to go into management, Singleton often first tries to talk them out of it. Singleton says that ten years ago, though less so now, there was an odd incentive structure in which managing ever-larger teams was seen as the prize. Companies such as Google and Meta have since cultivated career ladders that let individual contributors progress very far. Being a manager who feels fulfilled requires getting a lot of energy from getting more out of other people, and that is not for everybody. Singleton advises reflecting on whether that excites you and, if so, trying it.

QWhen you moved from frontline manager to manager of managers, what was your biggest skill gap?

Singleton thinks they learned the wrong lessons as a very early manager. With a single team, you can do everything to make that team happy, which is not the same as getting the best impact from it, and the team may not look back on that time as the best of their careers. Singleton won Google's 'great manager award' while managing one team, an award voted on by the teams themselves, and says they did not deserve it.

As a manager of managers, Singleton learned that teams that are perfectly happy are rarely performing at their potential. For the biggest impact, low performers have to be managed directly, and you cannot make a whole team happy unless people feel surrounded by colleagues who pull their weight. Singleton saw some managers who understood the goal, cleared distractions, and pushed their team a little, and others doing what Singleton used to do. Singleton's answer was to help the latter get more from their teams, and to step onto the balcony more often to see how the whole group configured itself.

The tools change too. A line manager needs good one-to-ones, one-to-one documents and goals, and some craft coaching. A manager of managers can think about the systems of the organization, such as product reviews and the hiring process, and Singleton says they were lucky to be able to change these at each stage. As a software and distributed-systems enthusiast, Singleton found it exciting to treat the organization as something like an operating system, asking how everything done daily, weekly, monthly, quarterly and yearly fits together. Singleton calls this a whole new toolkit that a line manager does not think about.

QWhat changed between being a very senior manager and being a VP?

Singleton says this varies by person, but for them the defining change was taking responsibility for functions beyond engineering. The title was VP of engineering, but by then Google paid little attention to job family and cared about assembling the full set of skills needed to get something done. This changed Singleton's perspective. Earlier in a company Singleton regards as engineering-first in those days, Singleton had thought the other functions existed to feed engineers. Singleton now says that is not true. Without other functions to help ensure you solve the right problem, get the right user input and make the right business deals, you will have less fun and less impact.

It was also a personal adjustment. When you manage a function you have worked in, you have a visceral sense of how to do the work. Singleton has designers reporting to them and calls themself a pretty lousy designer who would do badly in Figma. Singleton still had to learn to lead them well, and found they care a lot about design and can have high-bandwidth conversations about it. The hard part was gaining confidence that being unable to jump into any seat in the organization and perform the job did not stop them from leading. Singleton calls this the biggest transition of that jump.

QHow should an engineering leader get better at communication?

Singleton splits communication into speaking and writing. For speaking to large audiences, the number one method is practice. Early on, Singleton was quite nervous presenting to a large internal audience, and a supportive manager responded by giving more chances to practice. That led to speaking to a whole auditorium of Google customers while Singleton was working on ads. Singleton recalls one in London, near King's Cross, with maybe a thousand people, a live demo and an inspirational talk about local ads. It was scary, but Singleton did it, and says repetition is what makes it go well.

On writing, Singleton says they are still learning and uses Claude a lot. Condensing the most important points into a short clear document is valuable, Singleton argues. Speaking to a large audience may reach perhaps 30 percent who are really listening, and people forget. A good document gets passed around, read, and revisited, so it is a highly leveraged way to communicate at scale. But Singleton thinks both are needed: people listen to those they have a personal relationship with, which comes from live conversation, and once that exists, written material scales easily.

QWhat are high-leverage ways for a senior leader to scale beyond coaching direct reports?

Singleton points to the organization's rituals and processes. As an early-career engineer, Singleton thought 'process' was a dirty word, partly because of Symbian's process library, a quality-certification practice in which people were meant to look up and follow documented processes. In practice nobody did, and people filled out the paperwork afterwards if someone asked. When Singleton became an organizational leader and was told to think about processes, the first reaction was dismay. Reasoning from first principles, Singleton realised the point was the rituals and ways of working through which things get done, and that getting them right is very impactful.

As an example, Singleton set up, with help from colleagues, a set of meetings at Stripe called ops review. A weekly one run by Singleton looked at the most important matters, and a nested set ran across all engineering teams in the company. Singleton says this helped the whole company pay attention to and improve things such as reliability and efficiency, which would have been hard to move just by talking to direct reports and letting the message trickle down.

QHow do you get a remote engineering site to carry the right culture, drawing on London?

The host noted that the Facebook London site lead had credited Singleton with the best advice on starting that site. Singleton explains that they led Google's London engineering site while the other person led Facebook's, so they were in a fierce battle for talent, often discovering that both had offers out to the same candidate. The other site lead eventually reached out, and Singleton admires that. Singleton values a Silicon Valley attitude in which fierce competitors still help each other with the craft, and believes the two helped raise the engineering bar in London.

For a site far from headquarters, such as London to Mountain View with perhaps one hour of daily overlap, Singleton pushed for teams to be able to unblock themselves and run autonomously, so they use the overlap for as few things as possible. Every London team needed a clear and complete mission, a lot of autonomy, and all the equipment to execute on its own. The worst arrangement, Singleton says, would be half a team in each place, because the hundred daily conversations needed to unblock work would not fit the time window. A site in the same time zone, like Stripe's Seattle office relative to San Francisco, can be set up quite differently.

Singleton also describes an earlier London site lead who rarely sat in London and explained that the best thing for the site was to be in Mountain View, building personal relationships and bringing context back. Singleton later did the same, travelling to California a lot so others did not have to, and making sure the team's capabilities were visible, such as London's experts who had worked on WebKit.

Finally, Singleton says every effective remote site had a bit of its own culture. A sense of identity makes people willing to spend energy fixing friction, because they are part of a clan. But the culture must not be radically different from the whole company's, or people start to see the other side of the ocean as fools. The trick is enough identity for people to help each other, rooted in the company culture. In reply to the host's prompt, Singleton confirms this meant t-shirts and laptop logos and gatherings to discuss what work the site was good at, which Singleton then carried to California.

QWhich big tech company has the best-designed engineering culture?

Singleton says they are at a disadvantage, having worked only at Google among the big companies and knowing the others by reputation. Google's culture, in Singleton's account, was phenomenal: everyone was there to do big things, was encouraged to have impact, and was given a lot of agency. But Singleton does not think it was very deliberately designed. It was not chaos, and there was an org structure, but it grew mostly organically.

In contrast, as Stripe designed its org structure and ways of working while scaling, Singleton looked to companies that had been deliberate, especially Amazon. Singleton talked to many senior leaders there. The ops review that Stripe ran, and still runs, was modelled on Amazon's. Singleton recalls Charlie Bell spending a lunch walking through how it worked, and Stripe took the parts that fit its size and culture. Singleton calls Amazon the company with the systematic organizational and operational design that has most inspired them, though they never worked there.

Singleton says they would love to work at each such company for one project to experience it. Apple, for example, builds products Singleton loves, is not very transparent inside, and is deliberate about its org structure, with an Apple University where joiners learn to work the Apple way. This reminds Singleton of dealing with the mobile handset makers at the start of their career and seeing many ways to reach the same ends. Singleton would like to choose from the smorgasbord, but has only worked at one big company and gone deep with leaders at one other.

QStripe's operating principles seem to echo Amazon's. How are operating principles different from values?

Singleton explains that operating principles differ from values. The early Stripe team asked what about how they worked made them most effective. Their principles were concrete, distilled from the behaviour of effective colleagues, and revisited over time.

The principle that most motivated Singleton was being meticulous in your craft: taking pride in reliability, polished edges, and careful public communication. He says that care has a dramatic effect on how people perceive the work, even when it is hard to quantify. The broader lesson is to make the working principles behind a team’s success deliberate.

QAt what company stage should you start thinking about culture, and how does a leader enforce it?

Singleton is building a very early-stage company and thinks culture matters from day one. On the day they incorporated, Singleton and the co-founders went for a drink and wrote down their values, which they have used in hiring and in how they run things. Because an early-stage company often gets 'smacked in the face' by surprises, values help show where to compromise and where not to. Singleton says it would be too early to schedule a weekly culture activity, and at this stage culture should be organic. But in later-stage companies you need to be intentional, because companies are large groups of people, and without something that brings them together with shared purpose and alignment, entropy takes over. If you do not invest in culture, Singleton says, you almost by definition will not have one. Singleton notes that intentional organizations such as Stripe and Amazon tend to be very effective, and that some companies they worked at early on, which were not intentional, have not lasted.

QWhat intentional engineering-culture changes enabled Stripe's many nines of reliability?

Singleton says Stripe reached more than five nines of reliability during their tenure and that they have heard it reached six nines last quarter. These are Singleton's figures and are not verified here. For a payments business, every second of downtime costs businesses real money, so reliability matters greatly. Singleton says it started with being intentional. The pandemic in 2020 brought a rush of offline businesses online, and Stripe's systems were scaling much faster than expected, so the company knew it had to raise the bar. The engineering organization had not been wired for that. Earlier it had rightly focused on product-market fit, with emergencies fixed as they came, but at scale reliability mattered. Singleton calls the change mostly cultural.

Singleton's approach was to give every team the tools to reason scientifically about trade-offs between feature work and reliability work. That meant ops review plus a nested set of systems, meetings and data tools, and repeated chances to look at the data and decide what to do. In short, build conviction that it matters, set up a repeatable system so everyone has the right input, and look at it often enough to act. Because everything was measured systematically and surfaced widely, Singleton says, progress also came on efficiency and performance.

QWhat did Stripe do to hire such strong engineers without relying on LeetCode-style interviews?

Singleton starts with attraction. Many strong engineers wanted to work at Stripe and reached out, usually because they had a good experience with the product. At its core Stripe is a developer platform with a deserved reputation for some of the best documentation in the industry. Stripe treated documentation as part of building the product, written by the product teams rather than a separate team, with nicely designed APIs and pride in presentation. So, Singleton says, ship a great product and people will want to work on it.

On evaluation, Singleton says the industry was still doing a lot of whiteboard interviews when they joined, and all of Singleton's own interviews before Stripe were of that kind. Stripe believed, and Singleton still believes, that writing code on a whiteboard is not a great way to simulate seeing an engineer do real work. So Stripe designed a process in which candidates used a laptop with their usual tools and pair programmed with an interviewer, to give the most realistic experience of work possible. The exercises were deliberately designed to select for people who wanted to be meticulous in their craft and had the core engineering, design and inquisitive skills to find what needed doing. Singleton credits this with maintaining the talent bar for years.

QWhat did Singleton learn most from the Stripe leadership team?

Singleton says the biggest lesson from friends and peers on the leadership team was the value of thinking from first principles, something Singleton was not good at when joining. At Google, which invented many of the ways of working in the industry, Singleton's habit was to ask how it had been done last time and reuse it. At Stripe the constant refrain, when facing a problem, was to ask what is actually going on and to understand the dynamics. A related technique was to ask people at several external companies how they had handled similar problems and triangulate. Singleton says that can sound slow, but applied to the most consequential problems it brings the benefit of multiple perspectives, and Singleton still does it.

QHow different is Singleton's day-to-day now from the first time as a frontline manager?

Quite different, Singleton says, mainly because of the experience and lessons since. Singleton is applying much of what was discussed: stepping onto the balcony periodically to see how everything works, and putting far more energy into preparing for each week and making sure the team knows the most important things to work on. Early in their career it was more a matter of following your nose to the most obvious next thing. Singleton also finds much that is similar, so it feels a little like home and also like a wonderful new challenge. Singleton would not want to work on anything else, believes this is a profound technological leap, and says the work is hard but rewarding, with a lot of type two fun being created now.

QLooking back like an incident retrospective, what went well in Singleton's career?

Singleton starts with luck in early choices. Landing at Symbian was formative and, in Singleton's words, fairly random, so Singleton is not sure what others can take from it. The bigger factor, Singleton says, was always making sure they were learning, which explains the long stay at Google and the enjoyable time at Stripe. Singleton also moved teams within companies specifically to learn outside the comfort zone.

As an example, Singleton worked on mobile at Google before Android. There was a weekend, which Singleton remembers clearly, when mobile search queries exceeded desktop queries, a wake-up call for the company. The small side team building mobile things decided to disband and push that work out into the rest of the company. Singleton's default path would have been to join the Android team, which they later did. Instead, Singleton decided the best thing to learn then was ads, because Singleton had no idea how Google made money. Already fairly senior, Singleton joined an organization whose people had mostly grown up in it, and had to learn at a tremendous rate. Singleton now understands the auction systems and the publisher and advertiser business model, and would not without that leap.

QIs there a book that really affected your career?

Singleton names High Output Management by Andy Grove, former CEO of Intel. Singleton says that almost every way of working they met at Google and assumed Google had invented turned out to have come from Grove, including OKRs and how to run efficient one-to-ones. It is a short book, which Singleton read on a flight from London to Mountain View, and a bit of a page turner. Singleton accepts that some of it may no longer make sense but says reading it was a pivotal moment in thinking differently about how to run everything at work.

QIs there a habit that had a lasting impact across your career?

Singleton describes a planning habit. For a long time Singleton just did whatever arrived: emails, calendar invitations, and one-to-ones already scheduled, so the calendar and inbox ruled them, even when goals existed. Singleton realised that was backwards and began, many years ago during the Google period, to write a to-do list for each week. A week is, in Singleton's experience, the right level of granularity. On Sunday nights Singleton asks what would have to be done for it to have been a great week and writes it down. The document is called the rocket doc, with a rocket emoji as soon as Google Docs supported emojis, to convey the energy wanted. During the week, rather than going to the inbox or calendar, Singleton goes to the rocket doc to decide what to do next.

Later, Singleton shared the document with executive assistants, which Singleton calls a cheat code. The shared goal was for Singleton to spend time on those things, so by mid-day Tuesday an assistant might ask how it was going and chase Singleton to do the intended work, and help shape the calendar around it.

QWhat advice would you give your younger self, just graduated and about to enter the industry?

Singleton would repeat the earlier lesson. When you know something and assume it is because you are not the person in charge, speak up. Singleton believes good things happen when you do, and that doing it even more would have produced more good things in the roles Singleton held.

QHow did Netflix differ from the other companies David had worked at?

David says every earlier employer, from IBM through several smaller companies, tolerated prima donnas: very smart people who were hard to work with, who yelled at colleagues and customers, and who could not admit mistakes. He describes one 1990s engineer treated as indispensable, with a cubicle packed with junk, who avoided other people and fixed problems overnight while managers did not understand his work. When he quit, the company survived, and the rest of the team came to understand the area he had guarded.

At Netflix, David says, nobody was like that. The culture deck said the company did not hire brilliant jerks and would let go anyone difficult or unapproachable, however smart. David calls this revolutionary in the early 2000s and notes that the large tech companies he knows now work the same way.

His interview with Patty McCord, then chief people officer, who approved every hire at that small company, surprised him. David says she told him Netflix did not value 24/7 work and that he should impress the company with what he could do in an eight-hour day. David later watched a manager say he could not keep working around the clock. McCord thanked the manager, then told him not to do it again and to set up his team so that he did not have to. David calls that unthinkable in 2008 or 2009 and says he learned more about leading and collaborating from McCord than, he thinks, even from Reed Hastings.

David gives his own example. During early, unstable attempts at continuous deployment, a strong engineer remarked that David must enjoy having weekends off, because the systems would fail if the team stopped working. David told him in a one-on-one to take a vacation and said he did not care if things broke. The engineer took a week off, others rested too, and David says the team then stabilised the system quickly with its own approach.

David ends with Hastings. According to David, Hastings saw DVDs by mail as a stepping stone to streaming, which is why the company is not called DVDsbymail.com. Hastings was not a video expert but built a team of strong leaders and engineers to solve the problem.

QHow did the Netflix culture change as the company grew?

David first says the culture memo is aspirational. When people asked whether Netflix really worked that way, he answered that it described what the company aspired to be.

He then describes what failed to scale. Netflix credited the team, not individuals. When the company shipped on the PlayStation 3, David says, Sony's DVD division asked Netflix to stop because it had not designed the console for this, and Netflix carried on. Afterwards nobody named the foundational engineers; the credit went to Netflix. That worked when the company was small. As it took on many products, individual contributions got lost, and if engineers are not credited, he says, leaders collect the credit.

Netflix also had no engineering levels. Everyone was an engineer or a senior software engineer, and a business card could carry any title except manager, director, VP or chief. That suited an all-senior team. As it hired more juniors, David argues, teams contain strong, good and weak engineers, and without an objective way to tell them apart and reward wins, the best people leave. By the late 2010s he was arguing for levels. He assumes they have since been added, but he has been away for six years.

David adds that McCord interviewed almost every early hire and Hastings met a few new hires at a time, which could not continue as the company grew. When he left, he felt the memo suited a very small, aggressive, engineering-focused company.

QHow does David identify really strong software engineers in hiring?

David says his hiring succeeded all the way up to Meta. Large companies such as Meta, Google, Amazon and Microsoft need structure and consistent standards, so they use a formal interview system. At smaller companies, when he made the hire or no-hire decision himself, he, three team members and HR interviewed each candidate.

He tells of a late-1990s candidate who had built driverless-train software. David was the last interviewer, and his 45-minute slot ran to 90 minutes, with two whiteboards covered in state transitions. He says her grasp of a complex system of interacting parts was among the best he had seen. Others gave her coding questions and she did fine, but the panel was lukewarm and his boss pushed back. David argued that the team was struggling to integrate disparate systems and needed her. They hired her, and he says she excelled. He claims his hiring record at small companies was close to perfect.

David knows his next view is controversial: he does not love LeetCode. He says it shows how fast someone can write code for a problem practiced many times. He accepts that at the volume Meta and Google hire, they have little alternative.

His alternative is an engineering foundation: understanding complex systems, strong technical intuition, and sound decisions without enough data. He has seen engineers from other fields do very well in software. He has also seen people who aced LeetCode and rehearsed system-design questions such as Google type-ahead get hired and then produce poor engineering, which he saw in their review packets. He believes this foundation is largely innate, like musical talent, and says he can help someone improve their software but cannot teach them to make good decisions.

His second story is about a project partner in graduate classes at San Jose State, taken in his 50s just before he joined Meta. She was finishing a master's in civil engineering, worked in wastewater treatment, and wanted to move into software. David was impressed by her analytical mind and command of statistics and wanted Netflix to hire her. Her take-home video-software task took three weeks and had rookie mistakes, so to help close the deal David suggested she teach the team something. She spent two hours at a whiteboard on wastewater treatment, and halfway through David realized he was watching a very complex state machine. A manager asked what sewage had to do with software but hired her, and later told David at a Meta event that she was doing very well. David says that when you see a brilliant engineering mind, LeetCode speed or building a scalable type-ahead does not matter, because those can be learned quickly.

David accepts that this approach does not scale at Meta or Google, where legal and policy problems would break it, so they set a bar and a level. His level advice is to take a lower offer: someone who was a 6 elsewhere and is offered a 5 at Meta should accept it and execute at the higher level, because bonuses, multipliers and refresh stock follow. An over-leveled hire who struggles has no clean fix. His rule is that when in doubt, go low and earn the quick promotion.

QWho was the strongest engineer David worked with, and what made that person strong?

David names Giannis, though he usually avoids names. The captions garble the surname, so it is omitted here. They met in 2000 at InterVideo. Giannis had left the industry to teach signal processing in Greece, and in summer 2010 David brought him in during a break to help with ideas about parallel encoding. David says that work led to content-based encoding, which the whole industry now uses, and to an early patent.

Giannis later joined Netflix and, David says, took the idea further, in what the captions render as "convex all encoding", probably convex hull. David says it delivers the highest quality for a given bandwidth and is now the model at both Netflix and Meta. Giannis also built a cost-benefit model for codec evaluation. David sees his strength as forcing academic rigor into practice: decisions rest on tests across 10,000, a million or a billion videos, not on what two compressed videos suggest in theory.

QHow did David come to be recruited to Meta?

David says the early Netflix culture deck advised interviewing often to learn your market value. When Facebook contacted him in late 2017, as he recalls, he had not interviewed in about ten years. He went in, in his own words, a bit full of himself, citing how Netflix had built the highest-scale encoding platform. One interviewer told him Facebook could not solve its video scale problem with CPUs. David was floored, later thanked him, and realized he had understood video too narrowly. He got an offer and turned it down because he was not ready.

Soon after, Giannis told David about a Facebook offer and the custom chip (ASIC) work he would do. David saw a passion in him that he had not seen for a while. He thinks Netflix's culture, not built around individual contributions, may not have rewarded Giannis, and that the problems may not have seemed big enough to him. David says he did not try to talk Giannis out of it: as his boss he did not want to lose him, but as his friend he could not argue against it. David had been interviewing mainly to exercise his interview skills, but in the end he came to see Facebook's video work as a very hard problem. His team was solid and a successor was ready, so in 2019 he left Netflix, and Facebook offered him a job quickly.

At Netflix his encoding team had grown from one person to about 55, and trust grew with it. At Meta he took over a video processing team of 55 to 60 who did not know him. In an early meeting he talked about what needed work. A team member told him in a one-on-one that he had been there two weeks and was already telling the team what to do. David concluded he needed to stop talking and build trust, a skill he had never had to develop.

His lesson is that leadership is about relationships. If a team is broken, the leader's job is to fix it. If it is already executing well, the job is first not to break it and second to help it move forward, and he had jumped to the second step. David calls the saddest thing about Meta that it was his last job. He believes he would now be a much better organizational and engineering leader but no longer wants that responsibility, and he says he learned the most about engineering leadership there.

QWhat was David's favorite work or project at Meta?

David first names bringing Netflix-level quality to Meta's scale, which he says succeeded. He then turns to COVID. He joined in late July 2019, and by March 2020 everyone was working from home. Meta planned for New Year's Eve from the summer because video traffic spiked for 24 hours. By April 2020, David says, every day looked like New Year's Eve in uploads, streams and live video. Systems that had never run at that sustained load were slowly bleeding out, with race conditions among the problems. He says the prime minister of India was addressing the country on Facebook Live, and he was terrified by the weight of it. The team worked from home, found the problems and resolved the race conditions. After about a month the systems and metrics held, and David says he was proud of that.

He also describes how his view of the company's value changed. He had first seen Facebook through a US-centric lens as a social app. He came to see what 3.5 billion customers means. By David's rough comparison, Netflix's roughly 300 million subscribers are the wealthiest 5 percent of the world by income, while Meta reaches the wealthiest 50 percent. He calls wealthy a loaded term, since at the bottom people live on about $68 a day. He says Instagram, WhatsApp and Facebook are a lifeblood for small shops across India, and an Uber driver from Somalia in Seattle told him WhatsApp kept his scattered family in touch.

David says US debate about social media focuses on harms such as fake news and overlooks how much the products improve lives elsewhere. He believes the company changed lives by giving people a business, a platform to share and earn from video, and a way to stay close to family, and that it feels good to be part of that in a small way.

QHow did work-life balance change across David's career?

David says that in the late 1990s he worked hard for a visionary executive because the team was trying to catch up, not because anyone demanded it. At InterVideo, a startup, the expectation was 24/7. He arrived around 10:30 in the morning and left around 10 at night, sometimes at 2 or 3 in the morning, often seven days a week, chasing deals to lift the stock price after the IPO.

In January 2004 he fell ill on a Sunday and kept getting worse. On the Friday his wife took him to the emergency room, where, he says, a doctor said it was colon cancer, with a blockage that could kill quickly. He was in hospital for about three weeks with two surgeries and chemotherapy. It was stage three with lymph node spread, and he puts his five-year survival prognosis at about 25 percent. His children were two, four and seven, and he says the youngest barely knew him.

In hospital he decided that his way of working was wrong. He told his boss he still wanted the job but could not work that way, and he says that if a company threatens to fire you for not being there late, the best thing you can do is leave. He believes InterVideo used hours to cover for poor leadership. He calls work-life balance something thrust upon him, and he was determined never to be a leader who expects people to kill themselves for a job. Hearing at Netflix that the company did not value 24/7 work was a shock.

His advice is not to wait for cancer or a heart attack. Bake balance in early, take vacation, and leave the company alone for a week. If it cannot survive seven days without you, David says, that is its problem.

David says high-performance companies such as Meta and Netflix are often misunderstood. He recalls a Meta poster of a rocking horse that read, in effect, do not mistake motion for progress. He suggests agreeing with your boss on the most important work and telling the boss which tasks you will not do; if one matters, someone else must do it or priorities must change. Crunch time will come at big tech companies, but it should be the exception, planned in advance, such as a push in May and June followed by a vacation. He says balance is achievable even at Netflix or Meta, if the manager gives clear context.

QWhich job taught David the most, and why?

David says his last four jobs each contributed. The first turned him into a high-performance software engineer, performing by problems solved, not hours worked. The second gave him a video foundation. Netflix, he says, was zero to one, and there he learned leadership, hiring and firing, context setting and cross-functional work, which he brought to Meta.

What he lacked on arrival at Meta was an objective process for planning, reviews and performance. He calls the PSC performance cycle both his most dreaded and his favorite time of year. In his account, everyone writes a self-review, the manager builds a packet with feedback tied to goals, and managers then defend their engineers in calibration meetings. Each manager thinks their team is the best, David says, so the aim is to persuade with data about who deserves what level and who did what on a project. He valued getting each engineer's impact on paper. He says departing employees keep every performance package they were ever given.

David had heard horror stories about the performance cycle but found it mattered once inside. His greatest joy, he says, was giving a direct report a top rating, and he also valued helping people who were below expectations recover. He adds that he used to think he understood scale from books on sharding and microservices, but in his view those authors do not know scale at Meta's level. The most valuable thing he would bring to a new job is a system for objective planning, review and performance.

QIs there a top book that influenced David's career?

David chooses a late-1990s book he names as 12 Secrets to Microsoft Success; the title comes from auto-generated captions and was not checked. He says it described radical thinking at Microsoft. One idea was betting the company, which he says he saw at Netflix, Amazon and Meta when a big opportunity is worth risking the company on without going all-in. Another was good failure: in a healthy company, projects and people will fail, and what counts is how you fail, what you learn and whether the bet was reasonable and managed early.

As he recalls the book, Microsoft was the first company to say publicly that it aimed to hire the top 5 percent of software engineers, and it coined the term dogfooding. When the NT server was failing badly in the mid-1990s, he says, Bill Gates made the whole company move to it, which put the bugs in front of everyone and got them fixed. After rapid growth Gates also imposed a company-wide hiring freeze because people were working on things that did not matter, such as Microsoft Bob. Executives were forced to kill projects, and David says the bottom 20 percent were cut, which he thinks should have happened anyway.

David says Microsoft set early models for modern engineering leadership, and others borrowed from it. Before the 2022 crash he thought the hiring rate did not add up. During COVID everyone accelerated hiring and nobody slowed. He believes that had big-tech leaders read the book, they would have seen in late 2021 that hiring was out of control.

QIs there anything David regrets that others could learn from?

David says his first six years out of school were wasted at very large failing companies. He names Hughes, spun off from General Motors, and an IBM division sold to Siemens, both of which failed. He had a good salary and an easy job, thought only about the moment, and did not think about growth. He does not mean being ambitious about a vice-president title in ten years, just thinking about growth.

For software engineers in particular, he says, everything learned will be obsolete in about five years. When he joined Meta, the bootcamp and the whole development environment had been replaced; he had been proficient as a director, but when he later went to an individual-contributor role he found everything had changed. His way of staying successful, David says, is to keep pushing toward the edge and keep learning new engineering skills.

QWhat advice would David give himself at the start of his career?

First, work on hard problems. David says that if the job is not difficult, you are not growing. Once a role flatlines, he says, an engineer at a company like Meta, where moving internally is easy, should find another hard problem. Hard problems are what move engineers forward.

Second, company size does not matter, but everyone should work at a small company or startup at some point, ideally while young. He cautions against being too taken with the technology and says to work for visionary leaders who can also execute, since vision without execution goes nowhere. He cites Zuckerberg and Hastings as visionary, and says Hastings was one in 1999, when Netflix had four people. Leaders should make you dream of sailing the seas, not just cut lumber for a ship.

Third, plan for work-life balance deliberately from the first job. Work and life are in tension, he says, but the best engineering comes from people who love the work and also enjoy time off.

Fourth, start financial planning on day one, because as technical people succeed they earn more and, without a plan, will not know where it goes. David recommends a deliberate plan for spending and for short- and long-term savings, small regular contributions in your 20s, and no extended credit or debt. He says that by the early 40s this will not usually allow retirement unless you were lucky, as with an early job at Facebook or Netflix, but it can give financial independence, so you could take a lower-paying job. In his view a 401(k) alone and Social Security will not be enough for those who start late. He knows many engineers in their 50s who earned well but have no plan, and says a good engineer employed for 30 to 35 years has no reason not to retire comfortably. He says elsewhere that he is not a financial planner, so this is one person's opinion.

QHave reports escalated problems with their managers to you, and why might a skip-level leader resist acting?

Ethan Evans says such escalations were common. He describes an uncomfortable incentive: accepting one report’s account can create three problems for the skip-level leader—deciding what to do about the manager, replacing and training someone if necessary, and covering the work in between. Dismissing the report as oversensitive instead makes the problem easier to delegate back to the manager. Evans presents this as a possible subconscious bias, not a defense of ignoring a valid concern.

He recounts discovering a leader’s poor treatment of women only after several reports accumulated and he spoke with affected colleagues. A lone earlier report might not have moved him, a failure he describes candidly. Multiple independently supported accounts changed his understanding. He therefore recommends corroboration when colleagues are willing to provide it; the speaker’s “mutiny” metaphor concerns workplace escalation and should not obscure the seriousness of the example.

QCould you seek a move for business reasons instead of organizing an escalation?

Evans separates two approaches. If there is a genuinely plausible case that another role would make the engineer equally or more valuable to the organization, lead with that case and do not introduce the manager complaint. If the real need is incompatible working relationships, explain that blame-free and think several moves ahead about the choices the leader actually has.

He describes his own move at Amazon. His leader wanted to keep him in the current role, but Evans had another available role outside that leader’s organization as well as a preferred role inside it. Explaining that remaining where he was had ceased to be an available choice changed the decision from “keep him here or move him internally” to “keep him in the organization or lose him.” After weeks of resistance, the internal move happened quickly. The story depends on having real alternatives, not on inventing an outside offer.

QHow did you communicate those alternatives without sounding threatening?

He framed the situation in terms the leader would recognize. Both were vice presidents, and the alternative offer came from a senior vice president. Evans explained that he needed to answer and that once he gave his word, he would have to honor it—as the leader himself would. That let the leader understand the constraint without a blunt demand.

Evans recommends preparing the key phrase before a predictable conversation rather than improvising under pressure. The facts and commitment should remain true; careful framing changes how the other person receives them. Delivery matters too. The same statement about needing to consider one’s career can sound hostile or calm and understandable depending on tone and body language.

He acknowledges that some engineers dislike workplace politics. His argument is that leaders still have emotions, stress, and defensiveness, so understanding the human interaction helps a person communicate an honest need more effectively. He does not claim he has fully figured out how to teach the skill.

QWhat skill gaps appear when a first-line manager steps into a manager-of-managers role?

The guest emphasizes learning how to add value to the managers who report to you. A more senior role changes which interventions help and which undermine the organization. He illustrates this with a skip-level meeting in which a newly promoted leader asks leading questions about an employee’s manager. The employee may start relying on the senior leader instead, while the manager feels bypassed and weakened.

The important failure is not simply having the meeting. It is overlooking how questions and judgments propagate through a management chain. Small actions become magnified across multiple relationships. The guest says these subtleties are often learned through observation and practice, not only from reading about management.

He expects some mistakes during the transition, just as new managers make mistakes when moving from individual contribution. A promotion decision should therefore consider the support around the person: whether their own leader can help them recognize and repair problems. Strategy and organizational design also matter, but early interaction errors can cause damage before those longer-term responsibilities become the main issue.

QHow do individual-contributor and management growth compare, and are they meritocratic?

He says that evaluation becomes more opaque at high levels in either path. In calibration discussions, a person may be associated with a valuable initiative without having been instrumental in its success. The same attribution problem applies to managers. A short review period can make it difficult to separate a persuasive account from a clearly demonstrated contribution.

Longer observation can clarify the picture: a leader who repeatedly produces good outcomes over several years is easier to assess than someone in one half-year cycle. He thinks some senior IC and first-line-management work is more visible to an outside observer, while higher-level work often requires access to the internal details and leadership chain.

He does not offer a simple verdict that one ladder is fair and the other unfair. His concern is insufficient evidence and accountability when the relevant impact is hard to trace. The resulting frustration is real for employees with limited visibility, and a desire for fairness does not automatically create the data needed to judge it.

QWhy did you choose to join Airbnb?

Laurent had worked at Apple and Meta and decided developer productivity was the area he cared about: making engineers more effective at writing software. Moving to San Francisco turned his existing commute into roughly ninety minutes each way, which prompted a search. Airbnb combined people he liked, an office he could walk to, and a developer-infrastructure organization early enough to offer substantial work to shape.

He joined as one of two test-infrastructure engineers just as the broader effort was becoming multiple teams. The choice combined everyday quality of life with a technical opportunity; it was not a purely title-driven move.

QWhy transition from test-infrastructure IC work into management?

One manager was responsible for several teams and more than fifteen people, leaving limited time for development and support. Laurent had already begun doing some of that work as tech lead. As his team grew toward six to eight engineers, many early in their careers, he thought a dedicated manager could support them better and improve delivery of the large project.

He pitched the need to his manager and offered to try the role with help. He began with two reports and later managed the whole team. His rationale was an organizational problem he could help solve, rather than management as the automatic reward for technical seniority.

QHow did management change your experience of boredom at work?

He treats boredom as a signal to examine what is wrong rather than simply tolerate it. Becoming a manager initially supplied intense learning: hiring levels, reviews, promotions, then building relationships and planning reports’ growth. Later he used his optimization instincts to improve the team’s working conditions.

He built a calendar tool to reduce fragmentation across his own and reports’ schedules. He also surveyed every team process in detail—meetings, planning, code review, and ways of working—to improve team health. The survey showed that everyone thought the long stand-up was useful for someone else, while no one actually benefited much from it. Changing that and other processes improved engagement and enabled more work with less time.

After a three-week wedding trip, he returned to find the team had planned the next quarter and assignments using the process they had established. That successful independence also left him bored. The next possible step was managing managers, but he did not feel ready and missed coding, shipping, and seeing the effect in production. He returned to IC work. The story frames a well-functioning team as success even when its manager then wants a different challenge.

QDid learning management make you a better IC afterward?

Yes. Understanding reviews, career framing, progression, and promotion helped him navigate his own work, while coaching and difficult-conversation skills improved his leadership of others. He continued developing those abilities after returning to IC work. The benefit was a new set of skills rather than merely privileged knowledge of a committee.

QIs pitching the organizational value a good way to move into management?

He broadens the lesson to alignment with a manager. People often hesitate to say they want promotion, expertise, or another kind of growth, then present a year’s activity at review time and hope for the desired result. He prefers an ongoing conversation that gives both employee and manager the chance to shape the work.

As a manager he used a “surprise factor” exercise: before delivering the review, each person wrote the expected rating and promotion result, and they compared that with his own written assessment. Agreement was the desired outcome. He got close to full agreement without reaching it. The purpose was reducing uncertainty and demonstrating whether communication during the year had been effective.

QWhen should ICs try management, and what are the tradeoffs?

Laurent found the experience invaluable and encourages people who are considering it to try. It is a different job, so direct experience can reveal both useful skills and whether the role fits. Even a poor outcome can teach something about one’s preferences and limitations.

He recommends starting with an intern while warning that one intern is a highly biased sample. Interns often need more direction and inspire strong personal attachment, unlike a group of experienced ICs. He recalls emotionally difficult intern calibrations because mentors strongly wanted their own intern to succeed and confused a return offer with proof of good management. A manager can do a good job even when the correct decision is no return offer. He helped run calibration sessions to make that distinction clearer and the process less frightening.

QWere your own promotions and reviews free of surprises?

He first says he was often surprised, then clarifies that the surprises were ratings rather than promotions. He sees that as evidence he had not understood the system and its values well enough. In one transition, he expected his technical leadership to support a staff promotion but switched into management near the end of the cycle.

The rating came back as meets expectations because he had spent too little time in the new role. He found that frustrating and redirected his effort toward reaching the next management level. He now thinks he should have explicitly asked beforehand how the timing of a role change would affect review and promotion.

QHow can a manager or IC successfully challenge an established rule?

He starts by examining the biases a process may introduce and what makes employee evaluation fair. Gather evidence, understand the reason behind the rule, and make a case. The history may reveal a useful constraint you did not see—or an old precedent that no longer fits.

He generally prefers initial one-to-one conversations to a public confrontation in calibration. In front of a group, people can interpret disagreement as a threat to reputation and become defensive. Understanding those human dynamics improves the chance of changing the process rather than just winning an argument.

QWhat stood out about Airbnb’s engineering culture?

He found it harder to explain why low-level infrastructure mattered in a designer-led company, but that different professional perspective also produced useful ideas. During a period of reliability problems, the company drew on people with emergency-response backgrounds to improve crisis management.

He admired the rigor and practices that resulted and took some to later jobs. His positive example is the willingness to ask which other field already handles a similar kind of problem well, rather than assuming all incident-management expertise must originate inside software engineering.

QWhy return from Airbnb to Meta?

After four years, the original stock grant’s vesting cliff affected earning potential, which was one reason to consider a move. He also thought he wanted to be an infrastructure generalist after working across testing, compute, databases, and other areas. He later decided that self-description was wrong, but it led him to Instagram at the time.

A disruptive July Fourth on-call experience prompted him to pursue reliability improvements. He knew Facebook already had tools addressing patterns Instagram still suffered from. He pitched adopting and partnering around that infrastructure to his skip-level manager and joined the resulting cross-organization project.

QHow did you choose a mentor, and what makes coaching useful?

He sought people who were thoughtful, direct, able to challenge him, and capable of changing his mind in a way he could engage with. Those traits need not belong only to engineers; he sees them in his current coach too.

The Facebook-side collaborator had those qualities and helped him examine where his problem framing was wrong. A useful measure of coaching is whether the person actually changes how they think and act afterward, rather than repeating the same behavior. Although the host asks about his explicit mentorship pitch, the answer mainly explains selection and value; it does not provide a detailed script for making that request.

QWhat were your first impressions of Stripe?

He encountered strong engineers, as he had in other jobs, and especially valued the emphasis on collecting and analyzing data before deciding. He considered its metrics-and-experimentation culture even stronger than the Meta culture he knew. That judgment is his personal comparison. It suited his own enjoyment of measuring progress and success.

QHow did your technical-lead role grow across a much larger developer-infrastructure organization?

He joined to lead build, test, and tooling across roughly thirty-five engineers, in areas he knew well. His first task was gaining credibility with people who already understood the local systems. He deliberately avoided citing his previous employer as automatic proof that a design should be copied or rejected.

Instead, he embedded with teams for about a month on concrete work, learned their rhythm, and asked questions that helped people reconsider decisions themselves. He made an exception for urgent incident response, where direct instructions could be necessary. Over a year he worked across most parts of the group and met the people repeatedly.

Leading a larger organization also meant accepting that each specialist knew more about their own domain than he did. He could guide with a broad developer-productivity perspective without pretending to be the local expert everywhere. Later he took two-to-eight-week assignments with different people or teams to bootstrap work and make it sustainable. Documentation and automation should allow the work to continue without requiring his constant presence or interrupting vacations. Being the sole keeper of secrets was the opposite of success.

QHow did you scale yourself across so many engineers?

Set realistic expectations: no leader of seventy people can know every current project in detail. Maintain contacts who can supply information, and be willing to say that you do not know yet and will return with an answer by a stated date. He believes confident misinformation damages trust much more than candid uncertainty; his emphatic career warning expresses that concern rather than a literal rule applying to every mistake.

He used office hours instead of attempting weekly meetings with everyone, providing enough capacity that people could get time within the week. Because about half the group was in Europe, he shifted his schedule to begin around five-thirty in the morning and create overlap with both European and American colleagues. Scaling still required direct communication and accessible help, just through a different structure.

QWhat do coaches commonly get wrong?

They identify with a single style—hands-off, highly directive, or hint-based—and apply it to everyone. Laurent instead uses the person’s mastery, confidence, motivation, and immediate situation to choose the help. In his early Facebook onboarding work, three of four mentees progressed normally while one stalled; learning a situational-leadership model helped him adjust and unlock that person’s performance.

He describes moving from direction for a beginner, to encouragement and shared decision-making, to support, and finally delegation as skill develops. The assessment is specific to a skill and situation. A technically capable person can still need explicit help with something unfamiliar. A tired parent calling at four in the morning about an iPhone problem needs clear steps, not generic praise or a lecture on systems. Choosing only the supportive stage leaves many other needs unmet.

QWhy can the senior-to-staff transition feel harder than the next transition?

He sees a mindset change at staff: independently find the problem, choose and pitch it, solve it end to end, explain the result, and document it. Senior engineers can be strong designers and implementers while still working on problems identified by someone else.

In his model, later levels continue that complete cycle with larger scope rather than introduce the same fundamental autonomy shift again. This is his account of the distinction, not an assertion that later promotions are easy or mechanically determined.

QHow can someone stuck at senior begin finding staff-level problems?

Laurent channels frustration with real workflows. In developer productivity, each awkward command, window, delay, or repeated manual task can expose an opportunity. Stripe’s friction logs institutionalized that observation: work through a flow, record the steps with images, and ask why each action or loading screen exists.

He could identify dozens of possible improvements during a code change, then group related problems, rank them, and address the valuable ones. The goal is not merely collect annoyances. Look for families whose removal improves the overall experience. He also imagines a tired user: where would that person get confused, stuck, or drop off?

He applies the same habit beyond software. Repeated business travel can be an opportunity to refine the process each time until the twentieth trip is smoother than the first. The staff habit is continually learning from use, identifying friction, and deliberately improving it.

QWhich book most influenced your career?

He names Kim Scott’s Radical Candor, which helped him handle difficult conversations while building trust, motivating, and coaching reports. He appreciated its explanation of the manager-employee relationship and ideas he thinks many experienced managers still miss. This is his personal recommendation grounded in his transition, not an external review of the book.

QWhat would you tell yourself at the beginning of your career?

The field changes even faster than it appears. Laurent contrasts interview practices he encountered early—such as estimation puzzles—with much more technical and monitored interviews he observes in the interview’s 2025 context. The examples illustrate change rather than establish a universal hiring policy.

He recommends staying curious and regularly reading technical news and discussions. He follows highly ranked weekly Hacker News items and has used that habit throughout his career. He expects the skills and experience of software engineering to keep changing substantially and would encourage his younger self to remain attentive rather than assume the original model of the job will persist.

QHow do you balance an important project against team health?

First establish whether the situation really warrants an exceptional push. Fung remembers Marketplace lockdowns or war rooms that concentrated people on an urgent objective. That focus could be valuable, but it had a real cost to morale. Leadership should discuss the tradeoff deliberately with the team, rather than allowing the cost to remain implicit.

One war room had a growth target as its exit condition. The team initially imagined that a few fixes might achieve it, but the effort continued much longer than expected. In hindsight, she would have assessed the likely duration more realistically, discussed the effect on team health, and explained the journey and expected length up front. A measurable target alone did not make the sustained intensity manageable.

QWhat changes when you become a manager of managers?

The relationship becomes a partnership between people who each bring management skills as well as technical skills. When she first supported managers, including a TypeScript manager she considered an exceptional compiler engineer, she asked what each person did well and how they could divide responsibility. Supporting another manager creates more opportunities to complement strengths.

Delegation also needs a balance of trust and verification. If delegation removes too much contact with the project, the supporting leader can lose touch. She asks managers for fast feedback and transparency about both successes and problems. The useful conversation is the one that exposes where help is needed; a reassuring report that everything is fine can conceal the very issue the partnership should solve.

QHow can a mentor make the relationship useful?

Begin by asking the mentee what they want from the relationship and what success would look like after three or six months. An explicit goal gives both people a way to use their time effectively.

Also distinguish mentoring from coaching. In her description, mentoring combines listening with advice drawn from experience. Coaching acts more like a mirror, helping the other person discover answers within themselves. Clarifying which mode the person wants can change how the conversation should work.

QWhat should an individual contributor do with one-on-one time?

Put routine status reporting into an asynchronous channel. Fung uses messages or a shared, living one-on-one document where either person can add updates.

Use the live conversation for topics that benefit from interaction: something the person wants to learn, a deeper discussion of their work, or a product question worth exploring together. The point is to reserve the scarce meeting time for conversation, while making the operational updates available separately.

QWhy did you leave Microsoft for Facebook?

She had friends enjoying Facebook, but repeatedly wanted to finish the work in front of her at Microsoft. Her final project there involved JavaScript and TypeScript, and she cared about helping the team deliver TypeScript 1.0. A former Visual Studio colleague, who became her first Facebook manager, contacted her in late 2014 about building a product around buying and selling in groups. She joined in 2015.

The commerce mission mattered for three reasons. Used goods could make a meaningful affordability difference for people with tighter budgets. Reuse could give existing goods a second, third, or fourth life. A selling platform could help a local business begin without first needing a physical store. Marketplace also represented a new kind of connection for her: meeting new people, rather than only reconnecting with people she already knew.

After eleven and a half years at Microsoft, she also wanted to test and broaden her engineering ability outside an ecosystem in which she had become comfortable. The move combined a mission she cared about with a chance to learn beyond familiar tools and practices.

QWhat stood out about the difference between Microsoft and Facebook?

Both offered talented colleagues who cared about their work. The clearest difference in her example was speed: early Marketplace shipped weekly updates, while the Visual Studio work she remembered used roughly four-week sprints. Even those four-week sprints had once felt short compared with earlier development cycles.

Facebook also felt much smaller at the time. She appreciated the expectation that a problem was everyone’s responsibility, regardless of role. Her example is a willingness to lean in and help, rather than to treat an issue as belonging exclusively to someone else.

QWhy is using your own product so valuable?

Her first job involved using Visual Studio to build Visual Studio, so daily product use was built into the work. It gave her empathy for users and a feel for the product’s condition. She carried that habit into Marketplace, keeping items to sell so that she could experience the workflow herself. Meeting users also made the effect of the work tangible and motivating.

On VR and related device teams, she used Quest devices and early Ray-Ban products. For a manager who rarely gets to write code, using the product can be a way to experience what the team is building and to contribute directly. She describes reproducing a difficult floor-height bug at home and collecting logs as a small piece of maker time.

Peterman adds that a leader’s report can bring attention to a bug that was already known but had lost urgency. Fung emphasizes another effect: team members notice when a leader uses and cares about their product, and that can build rapport.

QHow do you make frequent product use sustainable?

Integrate the product into something you enjoy. She used VR for exercise, watching movies, and knitting while watching. Enjoyable everyday use creates repeated exposure without making the activity feel like a chore.

At the time of the interview, building Claude Code with Claude Code made that feedback loop part of her day job and let her ship production software again. She also mentions continuing to submit Meta product feedback after leaving.

Leaders can add structured product sessions. On her last VR team, she and her product and design partners tried nearly ready features together on Fridays and gave fast feedback. That complements daily use with a regular opportunity to inspect what is approaching release.

QHow can an engineering leader work well with product management?

Start with the shared objective of the leadership group and the strengths each person brings. Because there will be more work than people, agree explicitly on who owns which pieces and divide the work accordingly.

Using the product also improved her partnership with product managers. Their one-on-ones could become substantive product conversations grounded in something they had actually experienced. The discussion links partnership and product knowledge: an engineering leader has more to contribute when they stay close to what customers use.

QWhat does kindness contribute to an engineering organization?

She connects the principle to the pandemic, when device teams were trying to ship Quest 2 and develop Ray-Ban products without normal access to offices, labs, and colocated specialists. People were doing difficult work while also coping with pressures at home.

A personal example made the principle vivid. Her grandmother was in a Canadian care facility that she could not visit. Staff could arrange only limited FaceTime calls, and a rare available slot conflicted with a one-on-one she had promised to attend. The person she supported readily accepted a last-minute cancellation. What may have felt like a small accommodation to him had a large effect on her.

The lesson is that a colleague’s private circumstances are often invisible. Kindness is a practical way to work with people whose full situation you do not know, while the team is trying to accomplish difficult things together.

QWhy did you choose Anthropic?

She was happy working on VR and Horizon OS at Meta and was not conducting a broad search for a new job. The choice she describes was essentially joining Anthropic or staying in a role she already enjoyed.

Using an internal AI tool to build useful work tools showed her that AI was already changing her own workflow. Conversations with Anthropic employees then drew her to their mission orientation, emphasis on safety, and sense of shared responsibility. She likens that attraction to the mission that had drawn her to Marketplace. These are her reasons for the move and impressions of the organization at that time.

QDid Facebook’s culture change as it grew?

Yes. She treats culture as a living thing expressed through actions, rather than a statement on a wall. Growth changed the company, although she still saw strong commitment to the mission within teams such as VR.

When new employees asked which team would give them the most impact, she also asked what they were passionate about. That question restored a dimension that could disappear in a comparison focused only on career impact.

QWhat stood out during your first two months at Anthropic?

She saw the mission and responsibility toward society expressed in onboarding, which made it feel more substantial than an interview slogan.

The speed of the Claude Code team also stood out, even compared with the Marketplace period she remembered as fast. Broad internal use supplied a rapid cycle: build an idea, launch internally, get feedback from employees, release publicly, and keep learning. Her concern as the team grew was preserving that agility and speed.

QWhat feedback most changed your career?

It was feedback on how she received feedback. Her instinct as an engineer was to debug the situation immediately: ask questions, replay what happened, and determine how to improve. Someone pointed out that giving constructive feedback was already uncomfortable, and her questions could make the person feel they had to justify it.

She changed the first conversation to listening and learning. Questions could wait until another day, after she had reflected. The distinction is about timing and the experience of the person raising the issue: a sincere wish to understand can still feel like a demand to defend the feedback if it arrives too quickly.

QWhat would you tell yourself at the beginning of your career?

Enjoy the experience while it is happening. Work and life move quickly, and the moments that later feel like the good old days are also the moments you are living now.

QWhy did you ask for a demotion at Meta?

Igor joined at senior staff and felt he had to acquire deep technical context, relationships, and trust quickly enough to perform alongside experienced peers. He describes a much longer ramp than the title alone suggests: an external hire can initially know less about the environment than an intern who has already spent a few weeks there. The higher the expected scope, the more layers of competence and context there are to rebuild.

After about a year and two months, his own assessment was that he had reached something closer to staff-level effectiveness. Performance pressure made that gap feel risky. His description of the company’s performance environment is his experience at the time, rather than a statement of current policy.

He also discovered a preference for the work in the E5–E6 range: coding, debugging, designing, and mentoring. The senior staff role involved more leadership, meetings, and design documents, with less direct coding. He asked whether he could drop a level, understanding that existing stock and compensation made this awkward. He was told that staying in the same job category while reducing the level was not supported by the process available to him.

QWhy had the senior role worked at Google and Cruise?

At Google he joined as a junior engineer and grew through repeated promotions, including attempts that initially failed. The senior staff promotion followed a substantial project on a team where he had already spent years. Expertise, familiarity, and credibility had accumulated together.

Cruise also required a difficult first-year ramp. Over time he found a role that combined coding, mentoring, and broader technical guidance. He was happy there before the accident and subsequent company disruption he describes led him to leave.

QWhat would you change about your onboarding?

He spent too much time trying to build foundational knowledge by reading documents before doing enough actual work. In retrospect, he would learn and build in parallel: take a task, get his hands dirty, and acquire the relevant context while making progress.

He had not changed companies often, so this form of onboarding was new to him. He also felt the management team had limited experience ramping senior external hires because many senior employees had grown inside the company and already understood its basic machinery.

QDoes moving companies become harder for senior individual contributors?

He has seen Google colleagues leave and return after a move did not work out. Such stories are harder to hear because people tend to share successes more readily than failures. He also suspects repeated moves could build the skill of ramping in a new environment; his own limited experience should not be treated as proof that every senior move will fail.

QDid anyone give you feedback about the level gap?

Yes, although he does not share the private details. He gives a project example: work he expected to take two weeks became much more complicated. Even if he completed it successfully, he did not think its scope would justify E7. Underestimating complexity and selecting insufficiently broad work were different problems that combined in the same project.

QWould returning to Google also restore your old team context?

No. The people and infrastructure would be new. The advantage was familiarity with the company’s operating patterns and culture, rather than retaining all of the specific knowledge and relationships from his previous role.

QWas returning at L6 instead of your former L7 straightforward?

It required work from the recruiter because the usual return process supported the same level or a higher one. A request for a lower level could raise questions about why the person wanted it and whether they would accept the lower compensation.

He explicitly reassured the recruiter that he understood and would accept a significant compensation reduction. They made the arrangement possible in his case. He does not claim to know how his hiring manager interpreted the request.

QHow did the return hiring process work?

The recruiter sent openings, he spoke with several hiring managers, and he pursued the team that seemed to fit best. He then spoke with engineers and the manager’s manager.

Despite having been away for about three and a half years, he did not have to repeat the normal interview process. There was a discussion of whether returning at L6 would require a coding interview because a more senior role might have involved less coding, but he received an exception.

He does not know whether that was a general return policy or a special arrangement for him. The process described is one person’s experience.

QWhy are you willing to discuss this publicly?

He is generally open about positive and negative experiences, but also emphasizes the security that makes his openness possible. He does not depend on an employer for a work visa, has access to health insurance through his spouse, has grown children and no mortgage, and can afford time without work.

Those conditions reduce the consequences of losing a job after speaking publicly. He would not automatically advise someone with different constraints to disclose their workplace challenges. His willingness to share comes with a clear acknowledgment of privilege.

QWhat changed between pursuing promotions and pursuing a lower level?

Earlier in a career, it can be difficult to imagine what a role several levels above actually feels like. Experiencing the progression clarified his preference: his happiest work involved a relatively small team, substantial coding and debugging, design, and mentoring. A higher title was less valuable to him once its daily work became concrete.

QWhat did strong senior peers do that you felt you lacked?

He warns against combining everyone else’s strengths into one imaginary competitor. One colleague may be strong at presentations, another at communication, and another at leadership. Comparing yourself with the whole group can create an impossible standard.

He thinks that with enough time he could have become fully productive at E7. He simply was not enjoying the process and did not have to continue it. Friends and family questioned leaving before being forced out, or declining to seek the same level elsewhere. His response separates an ability to do something from a desire to spend his life doing it.

QIs there a mentorship story you particularly remember?

An intern he hosted when he was around L4 later joined full time and eventually became the manager of that team. Igor had moved to another project by then, so he did not report to his former intern. His lesson is straightforward: do not underestimate an intern’s potential.

QWhat advice would you give your earlier self?

Ask whether the work matters to the company and who needs it. He remembers working on projects whose purpose was unclear to him and that leadership later shut down. Choosing useful work is a more concrete guide than remaining on a project only because it has been assigned.

QWhy do some names and ideas become better known than similar work?

Asked why Paxos became more familiar than Viewstamped Replication, Liskov recalls Lamport’s explanation that he gave the talks while she implemented the work. She acknowledges his presentations and papers as a source of visibility. When the host wonders whether the catchier name also helped, she agrees that it is a appealing name without treating naming as a proven causal explanation.

QWhy did some people question the significance of your Turing Award work?

Liskov first challenges the host’s assumption that only she faced negative comments. Her husband happened to read those comments online; she thinks other recipients may have encountered similar treatment if they looked.

Her more interesting interpretation is that some of the work had become so fundamental that people could no longer imagine the previous world. Even her graduate students had not fully grasped that abstract data types and the modular-programming mindset had to be invented. A specific protocol is easy to identify as an invention; a way of thinking that permeates ordinary practice can become part of the unnoticed background.

She therefore viewed the dismissive comments, despite their intent, as a kind of compliment to the broader research community that created those foundations. The impact had become difficult to see precisely because the ideas were taken for granted.

QHow do you find the problems that matter most?

Brooker recommends looking broadly rather than optimizing only the volume of one’s own code. Customers reveal work they find difficult, investments they are making, and operational chores they wish did not distract from their businesses. Technical trends supply another input: faster networks, storage, compute, multicore systems, and GPUs can make previously impractical designs possible. Changes in the wider world create openings too.

QWhat makes a good postmortem?

Begin by understanding what actually happened, rather than fitting the event to an existing bias. If that is impossible, the difficulty itself identifies missing observability, logging, metrics, or simulation capability. Then examine causes at several levels: the code defect, why testing missed it, why the testing approach or assumptions were inadequate, and which team or organizational decisions shaped those conditions.

QWhy should a team with weak postmortem habits invest in them?

The choice is where to spend engineering time: improving the product or fighting the same fire repeatedly. A weak culture may lack a sufficiently clear focus on outcomes and customer experience. Standards need not be identical everywhere; durability-critical systems deserve especially high standards, while another product may deliberately accept more defects to optimize other goals. The important distinction is an intentional tradeoff.

Another failure mode is normalizing operational heroics. A team that stays up all night, tolerates constant pages, and fixes every emergency may feel admirable from inside, yet spend its strongest ownership and expertise on an expensive repeating break-fix cycle. The corrective move is to redirect that energy into understanding and removing causes. Preventing recurrence creates time for deeper product improvements.

QWhat would you say to a new engineer frightened by those higher expectations?

He does not expect a new graduate to know everything immediately. Employers and early-career engineers both benefit from people succeeding, so organizations must build a supported learning path. First customer conversations can be scary; mentorship, feedback, guardrails, and progressively larger experiences make them learnable.

He compares this with other professions where much practical learning occurs on the job. What changes is the emphasis of the learning, not the fact that graduates need it. Leaders must rethink the career ladder rather than simply hire beginners and demand expert performance. He acknowledges uncertainty while remaining optimistic about the scale of opportunity.

QWhy write so much as an engineer?

Writing lets expertise travel across both people and time. A product, individual mentorship, and talks all spread knowledge, but an old written explanation can still help a reader a decade later. He values writing as a multiplier rather than merely as a visibility activity.

It also sharpens the writer’s thought. Putting an idea into prose forces a depth and clarity that speech or slides may not. Brooker sometimes writes with no intention of publishing. He appreciates Leslie Lamport’s stronger case for formal mathematics while seeing prose as an accessible starting point. Sharing ideas, preserving them, and understanding them better are separate but compatible motives.

QWhat do you say to engineers who see documentation as busy work?

Ask what the writing is for and whether it operates at the right level of the problem. Brooker does not find every design notation useful; he criticizes UML as focusing on a semantic level that did not help his own work. A document can be valuable because it preserves a decision for future readers or helps reason through a difficult, hard-to-reverse design or API choice. Routine, reversible choices do not all warrant the same process.

For important designs, recording the rationale also distinguishes careful decisions from temporary guesses made without data. Future engineers can reconsider arbitrary choices with new evidence while taking more care to understand the reasoning behind deliberate ones. The amount of prior thought matters alongside the result. Writing for that purpose is a skill worth developing even if the activity is not naturally enjoyable.

QHow do you balance doing the work with discussing it?

He sees both extremes as failure modes. A deeply capable person who never communicates could have more impact by sharing and could miss important problems by staying inside an IDE. Someone who only talks could make their advice more relevant by returning to practice.

Brooker personally spends roughly seventy-five to eighty percent of his effort practicing and the remainder teaching or communicating. Strong colleagues vary from approximately ninety-ten to fifty-fifty; he offers these as observations rather than an optimal allocation formula. Dedicated communicators can have a different job, provided they remain curious and honest about what they do and do not know. During fast change, he would lean somewhat more toward practice without severing contact with the outside world.

QIs it better to be overrated or underrated?

For the long term, he would choose underrated. Being overrated may feel good but is difficult to sustain. Sports and crafts expose the gap between appearance and capability quickly; engineering can leave room for qualitative perceptions longer. The careers he admires are built on honesty about actual knowledge and skill, not on maintaining an inflated image. This complements his recommendation to communicate useful expertise rather than hide it.

QWhich AWS engineers do you admire, and why?

He highlights retired colleague Al Vermeulen, whose work included major contributions to S3 and database design. Brooker remembers debating fine points of Paxos with him around 2010 while also seeing him discuss executive-level cloud strategy and explain what the business should build. He admired the ability to move across those levels without losing depth.

More generally, he respects colleagues motivated by useful work and customer impact rather than celebrity. Breadth, detail, and purpose together form the example he wants to follow.

QWhat advice would you give yourself when first joining AWS?

Be a little bolder about moving when learning and impact begin to taper. He loved his early teams in EC2 and EBS and was more hesitant to leave than he now thinks ideal. He made about four substantial organizational changes and suspects a few more might have been better, rather than recommending constant movement.

He would repeatedly ask what he is learning, whom he is learning from, and whether another environment would help him learn more quickly. Following curiosity has been both useful and enjoyable in his own career.

QHow do you balance a provocative headline with honesty?

He opposes misleading clickbait. The aim is communicating the most interesting true parts effectively. Lying can attract attention but destroys the basis for a useful relationship with users.

QWhat about charts with a truncated axis?

He rejects deceptive chart presentation and then emphasizes the real benchmark difficulty: caches, project selection, and unrelated native builds can change the observed result. No single graph captures every situation. That does not remove the obligation to give users an honest sense of performance; he admits his own team may sometimes get the balance wrong.

QDid willingness to walk away give negotiating leverage?

He agrees that he had a strong position while declining to portray himself as an expert negotiator. He emphasizes aligned, supportive investors and little pressure beyond suggestions to grow more aggressively. That positive experience was fortunate; he recognizes other founders can have different relationships.

QWhat surprised you as an engineer becoming a first-time founder?

He distrusts universal startup advice because successful founders can give contradictory instructions and survivorship bias hides alternatives. Choose principles suited to the team and the life you want. Remote work let him hire a team he could not have assembled in one location, despite real benefits of meeting in person. Fundraising optimized for trustworthy partners, reasonable terms, and getting back to work. He did not force a cofounder relationship merely because it was recommended, though he later felt the absence of a peer sharing the burden.

QWhat advice would you give yourself after graduation?

Trust decisions made for sound personal reasons, while remaining aware that hindsight can make a lucky path look inevitable. He worried that choosing Khan Academy cost him big-company experience and compensation; he now values the experience he actually wanted. He would not pretend to know how the alternative would have gone.

QHow much glue writing, such as launch posts, updates and design docs, is now written by LLMs at Anthropic?

Thariq's rule of thumb is that if you would be happy to show someone the prompt, you can send them the output. Often the prompt just collects context. Before each one-on-one, Thariq has Claude read Slack messages, GitHub messages and PRs and compile a report of what Thariq did. The manager lacks that context, and Thariq is comfortable with them knowing the prompt.

For data readouts, Thariq suggests showing you have read the result, for example with small edits or a sanity check of the numbers. For a pitch or new concept, people want to know you believe in it. Even if Claude's idea is excellent, Thariq would say that Claude generated it and that Thariq thinks it is great. What people dislike is feeling misled.

Some writing depends on individual words. Anthropic's internal essays arguing for a direction are generally human-written, and Thariq says having Claude write your essay is looked down on, because every word should be intentional.

QShould software engineers post on Twitter or X to build visibility?

Thariq says to share your work externally as much as you can, though some employers do not allow it; side projects are an option. Before joining Anthropic, Thariq worked with different companies, built things, and wrote and talked about them. Thariq says this increased their "surface area of luck", and that the bar is much lower than people think.

Thariq says they give this advice to many people and almost none follow it, while everyone who did is in a job they are excited about or running their own company. The recipe: ignore your resume, choose an interesting project, work hard and lock in, then ship it and write about it. There will be reasons not to, but if the first attempt fails, do it again.

Twitter may not be the right place; Reddit or Hacker News might fit better. The goal is to find people who like what you do. People want high-quality content, which is a lot of work, and Thariq says there is no shortcut such as asking Claude to run your Twitter account. Engage authentically. Thariq compares it with going to the gym daily: simple, disciplined and easy to quit, and Thariq says they have not seen anyone who kept trying fail.

QShould an engineer organize a career around promotion or around developing useful behaviors and impact?

The guest strongly favors impact over title. In evaluating advancement, he wants to see important outcomes rather than an attempt to negotiate a checklist whose completion mechanically triggers promotion. A person can technically satisfy a stated activity while performing it in a way that adds little value; that leaves the underlying reason for advancement unmet.

He also acknowledges a personal reaction: repeated attempts to pin leadership down on rewards can feel transactional and annoying to him. That is his perspective as a leader, not a guarantee that all managers respond alike. His substantive argument is that genuine impact remains what should be recognized.

QHow should quieter engineers balance impact with making their work visible?

The host challenges a pure impact-first account: good engineers can be weak at communicating their results and may lose out when promotion decisions depend on people noticing. He distinguishes useful visibility from cynical self-promotion.

The guest agrees that visibility matters. Engineers need contact with people who understand important challenges, coordination with collaborators, and recognition of their capabilities so others can entrust them with bigger work. His distinction is the purpose and framing of the communication: making work understandable and coordinating it can lead to different behavior than trying to brag about oneself.

Updates should also recognize collaborators and thank the team. That makes the contribution legible without implying only the sender mattered, helps others feel valued, and supports the trust required for leadership. The host observes that two motives can produce superficially similar updates; the guest emphasizes how much the message centers the individual versus the work and other people.

QDoes the loud high performer often get promoted sooner than an equally strong quiet colleague?

The host argues that persistent lobbying can win extra attention even when both people have real impact. The guest says outcomes depend on organizational culture and that his own culture tries not to reward that behavior. He admits there are edge cases where lobbying earns consideration simply by keeping someone top of mind.

He does not advise abandoning ambition. He wants ambition expressed as a desire for greater impact: ask whether you are working on the most important problem, what you could learn, and where you could contribute more. A hardworking engineer can otherwise spend extraordinary effort on a low-priority task and still miss the outcome they sought.

Making those aspirations known and asking for opportunities are valuable conversations. What he opposes is reducing the relationship to contractual boxes followed by a demand for promotion. The debate therefore retains a real tension: the host worries about unequal recognition, while the guest prefers impact-centered visibility and managerial judgment to promotion bargaining. Neither establishes that recognition will always perfectly match contribution.

Build motivation through user relationships

Socially, Facebook was a product everyone had heard of and had opinions on. Novati could get plenty of feedback about what people liked and disliked, and found it motivating to build something people cared about. Novati adds that the company went through ups and downs, even during the tenure.

QWhat does Novati think of "move fast and break things," now that the culture has changed?

Novati describes having been "the move fast and break things person" at the time and still likes the framing. In Novati's reading, the "break things" half was partly an outside perception, and Facebook did not want to tell the public that people were recklessly breaking everything. The original spirit was breaking norms: first-principles thinking, trying things from scratch, not following trends for their own sake. It was not meant as causing havoc.

Novati still thinks it would be a fine motto today. At a larger, more mature company, though, even the smallest bug can cost millions or tens of millions of dollars, so Novati can see why the company dropped it.

QDid the culture change over the years, given that Novati started when there were about 200 engineers?

Novati describes an extremely engineer-driven culture. Designers and product managers had to win engineers over, because work an engineer would not build did not get built. Nearly all internal tools were written in-house and used by employees, which set an engineering-first tone that Novati loved.

Novati sees the 2012 IPO as a turning point. The stock fell afterward because people asked how Facebook would make money, a question that had barely come up in the first three years. As the company grew, Novati developed a more mature view: ad optimization, cost savings, and efficient infrastructure became more important. Early on, senior engineers argued out designs head-to-head, largely independent of management. By the end, VPs of two teams more often negotiated and the result percolated down.

QWhat was the internal newsletter that made Novati well known, and why start it?

It was called "the weekly Novati", a weekly post on the Notes product, Facebook's blogging feature. Notes had no owner when Novati joined in 2009, so Novati improved it at hackathons, adding rich text to what had been plain text. The change was an 11,000-line diff, so large that Novati had to organize an in-person meeting to review it. Novati also used the product constantly, as part of Facebook's dogfooding habit.

A few slightly controversial posts about product building drew traction, so Novati posted more regularly, often off the cuff. Facebook was adamant about staying on the Menlo Park campus, while startups such as Stripe and Uber in San Francisco were drawing employees away. Novati wrote repeatedly about it, including a post proposing a South San Francisco office, and that office later opened.

QWhich engineers impressed Novati most, and why?

The product infrastructure team, which built PHP abstractions that evolved into today's React framework. Novati watched the framework go up brick by brick and saw those engineers as a different type, a specialty that was not Novati's. The person most like Novati was Evan Priestley, who Novati says was the top committer before Novati. Priestley wrote the internal code-review suite essentially alone, and it was later forked and open sourced (the captions render its name unclearly).

QWhat impressed Novati about the React-framework engineers, whose archetype differed from Novati's?

Novati files them under the specialist archetype: people very good at one stack. Another example is an engineer who was one of perhaps ten people in the world who deeply understood email protocols, including the practical side of spam and routing. Novati likes a sports-team analogy: on a baseball team every player can play most positions reasonably, yet you want distinct roles and mutual respect for each player's place. Novati respects those engineers and sees the team as exceptional when it has different kinds of players.

QNovati has said about 30 percent of time went to the team and 70 percent to self-directed projects. How does that work?

Novati frames it as being a senior engineer on a team of about ten while spending more than half the time on codebase-wide initiatives: cleanups, refactors, a new framework, one-off help, and emergencies. The 30 percent was a share of mental focus, not a slice of the eight-hour day. Novati was on the team all day, reviewing code, bouncing ideas off junior engineers, mentoring them toward promotion, and writing features the team had queued. Novati also joined product meetings and assessed feasibility of what product managers proposed. The volume of code from team work was that of a senior engineer.

QHow did Novati transition into IC7, solving the hardest problems for the whole org?

Novati says output was already at coding-machine level from day one. What improved was taste and judgment. As an example, there were two forks of the task tool on the same data source, one fast and streamlined, one bloated with features and slow. In a week or less, Novati merged them into one with the speed of the first and the features of the second. Novati told no one, posted to the whole company that the tools were merged, and says this could not be done now.

Everyone congratulated Novati, but the lesson was that surprising hundreds of users with changed URLs was not the best way. Novati had not understood the consequences for teams. Over many large changes, some too fast and some buggy, Novati kept the same speed while improving judgment: how much to change at once, what other people will feel, and which spots are sensitive. That accumulation of judgment and taste is what crosses the line into IC7, Novati says. Advice on building it depends on context: talk to a manager, then a skip-level manager, then a very senior engineer in a similar org.

QWhat do taste and judgment mean for a software engineer?

Novati likens taste to the patina on a cast-iron pan, built up in layers of history. Some people have stronger instincts early, perhaps from upbringing or from experience outside code such as dancing or sports. In general it takes experience. Novati's second image is a speed skater: you cannot read a book, put on skates, and be fastest. It takes years of feeling the ice at different temperatures and the difference between a skate used once and twice.

Novati sees too many people early in their careers trying to jump ahead, like entering the Olympics before building that feel. That is okay, Novati says, and nothing is wrong with them. The advice is to put in practice and reps, get feedback, iterate, and have the grit to keep going; without feedback, practice does not improve skill.

QNovati was touching everyone's code. Did other teams give feedback, and how was it handled?

Yes. In one case Novati refactored an old framework in the live version of a team's tool while that team was building a newer tool and carefully maintaining backward compatibility. They had many diffs in flight, and the refactor caused merge conflicts. They wanted it reverted. Novati had not paid attention to that, and the lesson is to be careful where teams are mid-migration on complex, longer-term work.

QAs engineers get more senior they are pulled into more meetings. How did Novati protect focus time?

Novati minimized meetings. When calendar invites arrived without context, Novati asked what they were for and pushed back on many. Novati skipped standups unless relevant, for example during a crunch to ship within a month, and did not attend ones that were social chitchat. Novati was strict about time and chose teams deliberately, valuing managers who understood that their job is to help reports perform exceptionally. Novati's managers protected Novati from unnecessary meetings so impact could be highest.

Novati admits being too arrogant at times. Novati recalls walking out of a meeting or two after deciding it was no longer useful, and now regrets it, feeling bad for whoever ran the meeting.

QHow did Novati develop the skill of picking problems that mattered, so the code was more impactful?

Novati says first that Novati is not great at it and is still poor at prioritizing. Novati tended to pick things where Novati could already see the answer, so the only question was how fast the code could be typed. That is also why LLMs help Novati so much: the idea is in Novati's head and the tool gets it out faster.

Novati calls this one of the things that probably held back the career. When a manager asked for task A, and Novati could not see the answer, Novati did B through H instead. That earns a passing grade and is appreciated, but if A really mattered, the company's overall impact would likely have been higher had Novati done it. Novati frames it as a weakness, limited by what Novati can figure out how to do.

QWhat did the IC7-plus engineers have in common?

Novati says there was a common bar regardless of archetype, whether coding machine, specialist, or fixer. Everyone showed extremely strong diligence and conscientiousness, and was sharp. Novati cites a straight-A school record and a sense of being fairly smart, yet acknowledges that many in the group are probably smarter. In a room, a newly proposed protocol would not get an hour-long presentation; people would ask sharp follow-up questions at once. Attention to detail was very high.

For Novati these are personality traits, such as using obsessive tendencies productively on every detail of the product. Others reached them through 25 years of experience. In conversations with junior colleagues, Novati says, context is often missing, follow-ups are less sharp and take longer, and projects are usually smaller in scope.

QAt the highest levels of performance, how much is talent and how much is hard work and growth?

Talent exists, Novati says, shaped by biology, upbringing, and opportunity, and some of it is undiscovered. Someone who feels untalented may simply not have found it yet, or may be talented at something that is not their day job. Novati says this is the mission behind the current work of helping people find the most impactful work they can do, since not everyone had the chance to explore. Novati believes everyone is better than most at something, and finding it is a big piece of high performance.

Hard work, in contrast, is within your control. A friend of Novati's makes the point that talent and luck are outside your control and effort is not. If you are good at your job and like it, Novati says, you can outwork similar people and will probably be recognized for it.

QWhat percent of Novati's career growth is luck?

Novati says 50/50. Coming from Canada, Novati's first day at Facebook was a surprise: Novati took a laptop and left onboarding, and was called back because Novati had not collected a phone. Facebook handed over a phone and accessories as if rolling out a red carpet, and Novati wondered what it all was. Staying in Canada would probably have gone well, Novati says, but without the same acceleration.

The luck was landing at Facebook when Novati did: a perfect fit for Novati's personality then, aligned values, and code that matched what Novati could handle. Novati has seen people without the same drive who got the luck and are doing well, and says either factor can work out. Novati says both applied here.

QWhat advice would Novati give to a just-graduated self?

Novati sees many people, including those preparing for interviews, seeking approval: a green check mark, a perfect grade. Novati was that person, wanting an A+ without really knowing what was being learned. Because of that, Novati treated feedback as a grade to judge by and not as input for improving, and pressured toward 100 percent next time instead of toward improvement.

The advice to ambitious people who want perfect scores is to reflect on feedback and push past the comfort zone, instead of treating feedback as judgment.

QWhere were you in your career at that point, and how did it grow as you worked on these projects?

Holly says early Mozilla had a choose-your-own-title culture, and Holly chose 'negative entropy' for the complex codebase. By Firefox Quantum, Mozilla had a more standard ladder. Holly had reached senior staff during Quantum CSS, and after launch Holly and the engineer who led the other half of Quantum were promoted to principal engineer, a level held by probably fewer than five people at the time by Holly's estimate.

Holly's long-term dream was to be like Boris Sabarski, one of Mozilla's three distinguished engineers, and the route was to be prolific across as many parts of the code as possible: WebRender, mobile, multiprocess, layout. Holly's manager, who ran engineering, asked Holly to spend one day a week not opening a terminal and to think about impact more broadly than direct code. Holly was shocked and says it was not a natural way to work.

QIn the industry I hear two approaches to growth: focus on the promotion first, or build skills and behaviors and let the promotion follow. Which is better?

Holly has strong opinions and says to focus on impact, not title. That is what Holly looks for when deciding whom to advance. Someone having that level of impact does not need to sell themselves the way promo hacking implies, which means pinning down a management chain on exactly what must be done to earn a promotion.

Speaking frankly, Holly finds that annoying, comparing it to a child asking for a reward in exchange for doing what was asked. Holly also sees a substantive problem. A person focused on impact will achieve things, whereas a person focused on boxes someone else presented may technically satisfy a stated condition in a box-checking way that misses the point. Impact is what should be recognized and rewarded.

QYou were focused on impact and had distinguished engineers as role models. What did the growth look like next?

Holly kept working on the hardest challenge in the browser and moving from team to team, assuming that Boris Sabarski's level of impact would eventually mean becoming a distinguished engineer. Then the CTO at the time sat Holly down. The existing distinguished engineers had held the title since about 2010 and no new ones had been made since. The CTO said Mozilla would make new ones for the first time in almost a decade and that Holly would not be among them.

Holly was a little surprised, since Holly thought anyone would say that, though perhaps not at Boris's level, Holly knew the Firefox code better than almost anyone. The CTO explained that this was the traditional Mozilla model and that he now wanted something oriented around industry impact.

QWhat does distinguished-engineer-level impact look like? Can you describe some people who have done impressive work?

Holly describes three engineers promoted at the time as archetypes of world-changing impact for an individual contributor at Mozilla.

The first is Martin Thompson, still at Mozilla, whom Holly calls an international standards extraordinaire. His name is in the author line of protocols such as HTTP/2, QUIC and web push, and Holly says he was heavily involved in WebRTC and geolocation, adding that Holly is not familiar with every credit. This was core design work, not editorial formatting. By designing new protocols that were faster, giving the industry a business reason to adopt them, while leaking less metadata and having fewer security issues, he increased the privacy and security of the internet.

The second is Luke Wagner, whom Holly considers the person most single-handedly responsible for WebAssembly. Running non-JavaScript code such as AutoCAD in browsers had relied on plugins, which Holly calls awful for security and user experience. A side project from another engineer compiled C++ to naive JavaScript, which worked but was very slow. Wagner, then a lead engineer on the SpiderMonkey JavaScript engine, wanted it viable, and the idea became having the tool emit a restricted subset of JavaScript the engine could detect, verify and run more natively. That started a flywheel of compiled native experiences in browsers and then momentum for a real bytecode format, WebAssembly, which is native-speed, sandboxed and portable. Google was pushing a plugin-like alternative, Native Client, so Wagner handled the technical and political pieces to forge a browser consensus.

The third is Tim Terbury, the codec lead. Native video playback was blocked because the dominant format, H.264, was heavily patent-encumbered, which an open-source browser could not ship. Mozilla spent years developing royalty-free codecs. Terbury's team built the Opus audio codec and then a video codec called Daala, which was incorporated into AV1, now an industry standard from the Alliance for Open Media. Holly says that powers video today and that the vision for truly unencumbered codecs came from Terbury.

QWhat advice would you give someone who wants to become a distinguished engineer?

Holly's answer is writing, which anyone can work on at any level. Holly says Mozilla, including Holly personally, did not have much developed capability here, and that writing is one of the most powerful skills. Holly points to an internal memo, now public, called 'writing things down', which argues that writing matters both for the artifact, which helps coordination, wide review and feedback, and for the process, since writing is thinking, refining and articulating ideas. Holly calls clarity of thinking one of the most important things and says you only get it by forcing yourself to write your ideas down.

As timely advice, Holly says not to use an LLM to produce text you put your name on. It is fairly easy to tell, and more importantly you lose the thinking that writing forces.

QIf you could give yourself advice when you had just entered the industry, what would it be?

Holly's answer is to be humble. Holly says the younger attitude was not strictly about self but about engineering, that engineers were the center of the universe. Over time Holly realized that many other things matter, and that when you start at an organization you do not understand why certain processes and functions exist, such as a legal team. Moving into leadership, Holly developed appreciation and empathy for the different players in the organization and industry, recognizing that everyone has a point of view and a place they are coming from, and that working to understand where people are coming from is how to make progress.

QWhat do the engineering levels mean, from junior to staff?

Ricky explains that junior engineers write and ship code with a fair amount of help. Mid-level engineers work more independently but still need help at times. Senior is often a stopping point, with few people expected to go further. Staff engineers set a team's direction and lead engineers at other levels. Ricky estimates that moving from junior to mid-level takes about two to four years, and mid-level to senior a similar time.

Ricky says some companies use an up-or-out policy, where people who do not reach the next level leave, and that Google is less aggressive about this. Ricky estimates, without exact data, that 90 percent or more of people reach these levels. The speakers say the levels site is fairly accurate, except that equity pay moves with the stock price.

QHow do interns succeed, and how are they judged?

The speakers say interns are judged on three things. The first is productivity: how much of the assigned project they finish, ideally in half the internship. The second is quality, shown by fewer rounds of code review by the end. The third is communication, including proposing improvements or a new project after finishing the first one. A strong intern does all three.

QHow did you get promoted so quickly to staff engineer in your 20s?

Ricky says each level expects a different kind of work. Many projects at the current level do not earn the next promotion. One project at the next level, which clearly shows readiness, counts for more. Managers often describe these expectations as behaviors. Ricky and Ryan focused on projects that would move them up, not on busy work that would not.

Ricky also says that, after each promotion, Ricky asked the manager what the next level required and then took on that kind of work. The manager explained which skills to build, and Ricky credits this for the fast promotions.

QIs career success mostly luck?

Ryan says luck is a big part of it, but people can raise their own luck through initiative. After about eight months at Amazon, Ryan felt stuck and could not see the path to the next level. Ryan applied to many companies and received offers from every company interviewed with except one. That led to Meta.

QWhat one piece of advice would the speakers give?

Ricky says the main advice is to ask a lot of questions, at work and during an internship. Ricky once told a mentee to keep asking, and at the end of the internship the mentee said Ricky had not really meant it. Ricky says the biggest difference between people who succeed quickly and those who do not is how fast they start asking questions, learning, and unblocking themselves. Fear of looking foolish holds many people back.

QAre the best engineers the smartest students in the class?

The speakers say no. Strong engineers need solid technical skill and soft skills, such as persuading and influencing others. Work is a large group project, and disagreements are common. Telling a colleague that their idea is bad does not win them over. Naming the other person's frustration, acknowledging their view, and proposing a middle ground makes it more likely that the work ships. The speakers say these skills matter about as much as coding.

QHow much of the job is actually code?

One speaker says code is a smaller part of the job than new graduates expect. Writing is a large part of it. A design doc comes before the code, a change needs a written description, and a finished project needs a write-up of its results. The speaker says this writing is how a person influences others, so people skills often decide how far an engineer goes.

QDo experienced engineers still get imposter syndrome?

Ricky says imposter syndrome is very common, and that most people feel it. Ricky felt it on joining Google, after passing the interviews and the internship, and found the other engineers very strong. Even after promotions, Ricky wondered whether the company had made a mistake. Ricky copes by learning as much as possible and doing the best job possible, on the view that even being fired would leave something learned. Ricky says the feeling still returns in waves.

QHow do you advocate for yourself at work?

Ryan says good work is required but not enough, because people decide promotions and they must know about the work. The last few percent of effort is to tell people about it. That can mean writing about a result, presenting it in a meeting, or telling a manager that a milestone is done early and the next task is ready. Ryan says a clear post about strong results makes a return offer hard to refuse. Ryan says this step is often skipped, especially by introverted people.

QHow do managers measure impact?

The speakers define impact as the concrete, measurable results of the work, such as revenue, cost, speed, or user growth. The measure depends on the team. On an ads team it may be money. On infrastructure it may be the cost or latency of a database. On a growth team it may be daily active users or sign-ups at key steps. Engineers should learn the measure from their team and manager, because that is how their work is rewarded.

The speakers also say one small change that improves a key number can matter more than ten thousand lines of typo fixes. Their example is a one-line change that gives a 20 percent gain on something that matters.

QDo you need an MBA for engineering management?

Ryan says no, and Ryan is a manager without one. Ryan describes a graph from a company that gathers LinkedIn data, covering a few thousand directors and above. Pay with and without an MBA looked comparable, and pay without one was slightly lower. Ryan describes this as research done with a company, not a published study.

QWhat are your goals now, and did you push for promotion?

Ricky says Ricky was not very career-driven at first. Ricky and Ryan were roommates and still are. Ryan would ask whether they could aim for promotion faster than the usual timeline. Ricky had seen data on how long each level took, and Ryan's push made Ricky test whether a faster path was possible.

Ricky says Ricky put in the effort, was promoted faster than average, and did not give up other interests to do it.

QShould people change jobs every two or three years for pay or promotion?

Ricky says the answer depends on the case. Ricky has stayed on the same team under the same manager at Google, while still looking at other teams. Ricky notes survivorship bias, because people who left may have had a worse time. Ricky suggests asking every six months whether you still want to be there, whether the opportunities still fit, and whether the team and manager support you.

Ryan says the common advice to job hop for promotion is more nuanced. Early in a career, job hopping can be the fastest route, because momentum matters less than reaching the next level. At senior levels it can backfire. Ryan says companies usually do not hire outside candidates straight into E7 or L7, and promotion there depends on credibility and a track record that frequent moves do not build. Ryan's advice is to job hop aggressively early and to be more deliberate later.

QWhat actually happens in a hiring committee, and who touches a candidate between first contact and the final decision?

Austin says that when a senior packet reached the committee, the first thing Austin read was the behavioral interview. Austin wanted to see the scope the engineer had operated at, their level of influence, insight and communication, and the size of the organization they had worked in. Committees are made up of engineers and influential engineering managers, recruited by a chair such as Austin, and work with recruiting on two decisions: hire or not, and level. Austin describes a company-wide committee that mostly does a gut check against a cross-company bar, and says that at Meta a final committee of engineering directors makes the hiring and leveling call.

The path starts with a sourcer, an entry-level recruiting job whose task is to find candidates or process referrals. The sourcer looks at the job description, years of experience and past companies. The phone screen that follows is often a coding interview, and sometimes a multiple-choice technical quiz used as a pre-filter. A clearly strong phone screen goes straight to on-site scheduling. A borderline one comes to the hiring committee for the first time, which decides whether to add a follow-up, move the person on, or pass for now.

The committee is also consulted for specialized candidates, for example a low-level C++ mobile engineer who needs a fitting system design interview, and for the choice between senior and staff. That choice changes the loop. At Meta, Austin says, staff candidates get two system design interviews, so no one could be hired at staff without them, and principal and distinguished loops add further behavioral interviews. After the on-site, the committee decides hire, level and follow-ups. Behavioral interviews generate most follow-ups, because Austin considers them among the hardest to give and to read. Committee members sometimes go with the recruiter to the directors to argue for taking a chance on someone whose packet is weak in one area but strong in a trait the company needs.

QThe host said engineers often assume the behavioral round can be improvised. What should a candidate do to be placed at staff?

Austin says the most important task, in any behavioral story and in the first chat with a recruiter, is to establish scope: what size of business problem was solved with technology, how much ambiguity was handled, and what kind of organization the candidate operated in. The recruiter call is effectively a behavioral interview, so the opening “tell me about yourself” should be the greatest hits of the resume, with metrics, and with depth and complexity.

Austin contrasts “I improved performance in the Facebook app” with an account of organizing about 100 engineers across a twelve-month performance project that hit hard technical problems, needed several staff engineers, and ended in three core principles. A candidate should convey technical depth, organizational depth and business impact, because every interviewer in the loop is listening for the same things. Crisp practice on that opening is the first place to land in the right leveling bucket.

Responding to the host's point that staff promotions also require cross-organization work, Austin agrees and says preparing for behavioral interviews makes someone a better engineer. Most of Austin's coaching clients undersell rather than exaggerate. They need to show how hard the problem was and what impact it had on the team, code quality and the organization over time. Telling the whole story takes preparation, but it is the same skill used in weekly one-on-ones and executive updates.

QWhat is the most common mistake candidates make in compensation conversations with recruiters?

Austin says they are not a negotiation expert and recommends getting advice from people who are. Their own view is that early anchoring is dangerous: when asked early about compensation expectations, a candidate should be careful, because whatever is said anchors the rest of the conversation.

Austin tells candidates to learn the local laws and says that in California and New York recruiters are required to share salary and total-comp bands, which a candidate can use to see where they sit (this legal claim is Austin's and was not checked). Austin thinks the biggest mistake is not having multiple offers. Without them, a candidate negotiates from weakness, so Austin urges candidates to time offers to land at about the same moment, even though that is more stressful and more work.

QIf a candidate who wants only staff roles sees they are being funneled into the wrong loop, can that be corrected mid-process?

Austin says that depends on the company and process, but it is a good conversation to have with the recruiter. Companies uplevel candidates as well as downlevel them, and recruiters will usually try to keep someone in the process. Austin suggests pushing to complete as much of the evaluation as possible for the desired level up front, so that follow-up interviews and late changes are not needed. If a team offers only a lower level, it depends on the job and total compensation, but Austin would aim to excel and then ask for consideration at the higher level.

Austin names two methods. The first is to anchor every conversation at the higher level, starting with “tell me about yourself” and then in the behavioral and system design interviews, so that interviewers see large-scope projects and impact and reset what they expect from the rest of the interview. The second is story choice. Behind every behavioral question is a question the interviewer actually cares about: is the candidate operating at the expected level? Interviewers forget the details quickly.

Austin says their book gives four considerations for choosing a story, and scope comes first. The candidate's job is to leave having told the most important stories of their career, and since the interviewer drives, to steer the conversation toward the signal that best represents them.

QWhat do senior, staff and principal scope look like, and how should a candidate express them?

Austin first says to research the specific company's level expectations, then offers a simple rubric for big-tech-style companies, shown in the table below. Levels are really about how much ambiguity a person can handle. Austin notes that the ambiguity facing an intern differs from the ambiguity facing a chief executive, and says that difference is what separates both levels and pay.

Staff versus senior comes down to breadth of impact: a whole team or several teams rather than a small project. Stories involve working across a large organization. For that reason Austin thinks startup engineers struggle to reach staff unless they were founders, because a few engineers and one stakeholder limit how much organizational leadership they can show.

Austin adds two more things to quantify or mention. For technical complexity, a candidate should give a sense of the time involved, the risk, how many people were consulted, and how hard it would have been to back out of a decision. For leadership, which engineers often forget because they love to talk about technology, a candidate should describe influence, getting concessions from other teams, aligning roadmaps, and mentoring people to make the team and organization better. Austin recommends reflecting on one's own career to identify what differentiates it, and talking about those things.

QWho actually makes the hiring decision?

Austin lists the decision points. The sourcer, who decides from a LinkedIn profile whether to contact someone, is distinct from the recruiter, who takes over after the phone screen, runs the negotiation, organizes the loop and advocates before the committee. The phone screener is another decision point, whether a sourcer's multiple-choice question or an engineer's coding screen.

The hiring committee then decides, usually by consensus and sometimes by vote, whether to hire at a level, add a follow-up, or drop the candidate. Two or three engineering directors above the committee make the final call, again mostly by consensus and sometimes by vote.

QDid Austin ever see bias in a hiring committee, such as nepotism, and how much do referrals matter?

Austin has never seen overt nepotism or bribery, but has seen referrals play a huge role, especially when the referrer is senior or shows up in the committee room to advocate. The referrer's seniority matters: a VP or director risks personal reputation, while a note that someone knew a candidate at school carries little weight. Content matters as well. A referral saying the person worked directly with the candidate and listing specific strengths helps much more, so Austin tells candidates to write the referral for the referrer.

Austin says referrals matter most for candidates on the bubble. Austin's own phone screens went poorly, and Austin believes a follow-up interview was granted because a former schoolmate who had worked with them directly had referred them.

QHow well does interview performance predict performance on the job?

Austin says the committee did not track how many interviews someone passed. It looked at the interviewer's stated confidence in a hire-and-level decision, and that confidence correlated with later performance. Austin reads this as evidence that calibrated interviewers who have run hundreds of interviews sense what good looks like even when it is hard to define, and that a rubric reduces bias without removing the gut feel.

Austin also notes that some candidates excel in interviews and then do poorly, and others look rocky and then do well. Interviewing is a skill separate from the job, and Austin says candidates need to spend time getting good at it.

QWhat does the behavioral rubric look like, and how should a candidate use it?

Austin says it varies by company. Well-run large companies often employ industrial-psychology PhDs, called selection scientists, who study what makes engineers successful and codify it into signal areas. At Meta, according to Austin, there are five: driving results, embracing ambiguity, resolving conflicts, growing continuously and communicating effectively. These are not Meta's company values. Candidates should ask the recruiter for the rubric in advance or search for it.

Austin groups the typical five to eight items into eight broader signal areas, described in their book, and tells candidates to categorize their stories by those areas. Inside the interview the core loop is decode, select, deliver: work out why the question is being asked and which area it probes, select a story that supplies that signal, and tell it engagingly. At smaller companies a formal rubric may not exist. There Austin suggests relying on company values and asking recruiters or team members what makes engineers successful and what the hiring process looks for.

QHow should candidates tailor behavioral stories for OpenAI and Anthropic?

Austin starts by mapping stories onto the eight general signal areas, because most company values reduce to them, and then adds whatever the company's own values contribute. For OpenAI, Austin reads “act with humility” as growth: taking feedback and improving yourself and those around you. “Feel the AGI” is outside the eight areas. Austin reads it as being optimistic about what AI could do for the world.

For Anthropic, the caption renders a value as “hold light and shade”, which Austin takes to mean understanding both the positive and negative implications of AI. A story about using AI at Anthropic should mention the potential harms the candidate thought about and how they assessed and mitigated them. Without that, Austin says, the interviewers will not feel comfortable hiring. At OpenAI a candidate who is not AI-forward or excited about new domains for AI will interest them less. These are Austin's readings of the values, not official definitions.

QWhat are the most common behavioral interview mistakes for senior engineers?

Austin lists several. First, the wrong stories, meaning stories that do not match the target scope. Second, too much context: senior people are good communicators and tend to talk, but only the context needed to understand the behaviors is useful. If about thirty seconds pass without an action in the story, Austin suggests the candidate is giving too much backstory or technical detail. Work stories are not exciting, Austin admits, so the action must keep moving.

Third, inviting uncharitable readings. Interviewers hiring a senior leader are risk-averse, so a candidate should think defensively. Saying the codebase had heavy technical debt may sound like a good story, but a senior engineer in the room invites the question of how it got that way. Austin recommends adding the judgment behind the situation, for example that the team was a startup that had to close its next funding round and so accepted the debt, then chose to prioritize paying it down.

Fourth, too little on non-technical work: mentoring, organizing, delegating, influencing the roadmap, resolving conflicts, working across teams and managing up. Fifth, long, multi-year stories need an organized shape. Austin suggests opening with a short table of contents (the business context, then perhaps five parts such as proposing the idea, aligning stakeholders, solving hard problems and a long rollout), so the candidate can return to the key parts after interruptions.

QHow should a candidate split preparation time across coding, system design and behavioral rounds?

Austin says most people spend too much time on coding and too little on system design and behavioral, which are murkier to prepare for. For juniors, the technical signal matters most, and the behavioral focus should be on thinking, motivations and ideas tried, as signals of future impact, since juniors have fewer accomplishments.

For mid-level engineers, Austin says the old approach of focusing only on technical work and not flubbing the behavioral no longer works. Austin gives two reasons: layoffs have produced many candidates, so one must shine across all interview types, and more technical work is being done with agentic coding, so employers want mid-level engineers who own problems end to end and keep learning as engineering changes quickly. Austin says that ownership and growth show up in the behavioral interview. Coding practice should come early because coding assessments come first, but some weeks before the on-site a candidate should choose core stories, study values and the rubric, and make sure each key area has a story.

From senior up, Austin says it mostly comes down to behavioral. For a staff packet Austin went straight to the behavioral interview, since there are only so many ways to design a web crawler or solve two-sum, and the behavioral shows organizational impact, influence, conflict handling, scope and business impact. At staff-plus levels, extra rounds may include a cross-functional partner such as a PM or a project deep dive. Austin sees the technical rounds there as checkmarks to pass and the behavioral ones as what gets someone hired.

Austin thinks most people underinvest in behavioral preparation, which takes at least a few weeks. Staff candidates and above should start when they start LeetCode, work on positioning stories, get feedback, and do mocks with a friend or professional. For in-demand companies such as Meta, OpenAI or Anthropic, Austin recommends a mock interviewer calibrated to that company who can give a feel for its culture.

QHow much does subjective likeability matter, and how does presence affect the outcome?

Austin says it scales with level. At big companies, behavioral interviews for juniors are structured, with forms, to reduce the “beer test” effect. For seniors the interviewer expects the person to influence others on the job, so how they come across counts. Austin describes a Silicon Valley quality of “casual excellence”: looking calm yet sharply competent. A disheveled or nervous candidate who cannot be present is giving signal about how they will show up in meetings and before a CEO.

Austin adds that cultural norms differ by country and company. The conversation here is about a Silicon Valley or Seattle style that opens with playful banter and then turns to hard-hitting questions, and candidates should learn the expectations of the place they are applying to.

QWhich counts more, the first impression or the last impression?

Austin says that if forced to choose, the beginning. Austin often decides within the first ten or fifteen minutes whether to hire, since Austin opens with the biggest-scope questions (favorite project, most ambiguous project, something proud of). If Austin would like to see that performance replicated in the organization, the rest of the interview is a check on other areas such as conflict resolution and growth.

The ending still matters, mainly through the candidate's questions. Austin says candidates often prepare stories but then ask something generic like a day in the life of an engineer, which is similar everywhere. Questions drawn from real thought about the team, organization, product and company, and that help the candidate decide whether to join, leave the impression of an engaged candidate.

QWhat are the best ways to tell a behavioral story with the least effort?

Austin says a story needs an arc, with a beginning, middle and end, and must deliver the signal area the interviewer is after: past behavior that can be repeated in the new organization. STAR (situation, task, action, result) is the best-known shortcut. Austin does not love it but says that anyone with prepared STAR stories the night before should use them, since they give an arc, context for the actions, and results.

Austin prefers CALR: context, actions, results, learnings. The difference between situation and task is not useful in a long project, which has many tasks, so context followed by actions is simpler. For senior engineers STAR leaves no room for reflection, judgment or learning, and Austin looks for whether the candidate can see what made them successful or not and apply it forward.

QThe host asked Austin to explain, in terms of scope, why Austin was promoted to M2 at Meta.

Austin says getting to M2 meant solving hard problems in recruiting, with the most important being diversity. Austin left a team building products for teenagers, which Austin calls a hard time for Facebook, to lead teams in the internal recruiting products organization that supports candidates, recruiters and sourcers. What drew Austin was a team working to hire more diverse engineers, and Austin was motivated by opening technology, which Austin calls the largest wealth opportunity, to more people.

Austin says a product team cannot decide school curricula or all hiring decisions, but could move the needle by improving interview preparation, and credits that with helping diversity hiring at Meta. Austin also supported other teams in building high-quality candidate data in Facebook's applicant tracking system. The host heard multiple teams, an ambiguous problem and strong self-motivation. Austin agrees and adds company-wide impact from leading the iOS and Android recruiting pipelines, which scaled Austin beyond the teams directly managed. These are Austin's own account of their record.

QLooking back on big tech, does Austin regret anything?

Austin does not regret leaving and says they enjoyed working with wonderful people. The regret is the anxiety brought into teams and into their own life. Austin points out that no one at the end of life wishes they had gotten a few more percent of an engagement number, and says people value relationships and connection.

Austin says they made conscious choices to favor life experience over career but were not always honest with themselves about the trade-offs in pay, progression and status. Since leaving big tech to support a spouse's business, income has dropped. Before leaving, Austin decided to accept lower cash flow in exchange for more time with their kids and more community volunteering, and has returned to that choice when money was tight. Austin wishes to have made that kind of values-driven decision earlier.

QWhat is the best career advice Austin ever received?

Austin says it was the importance of creating scope. Many people wait for someone to give them the opportunity, but a manager once told Austin that to get an M2 role, Austin had to create an M2-scope team and solve problems of that size. Advancing does not mean doing the same thing better. It means doing something different, which is creating more scope and room for the organization to succeed.

Austin adds a test: what is the VP saying about your project, and if the VP is not telling peers or their manager, is it the right work? Candidates already work backwards from the signal area they want to show in an interview and from the packet they want in a promotion. Austin suggests working backwards in the same way from what leadership should say about the accomplishment, then finding a way to achieve it. The host adds that promotions built on self-created scope are the most satisfying because they need no one's permission.

QWhat advice would Austin give a younger self just after college?

Austin says imposter syndrome held them back. After completing a computer science PhD, Austin spent summers doing university research while peers took industry internships at places like Google or Facebook, because Austin did not want to go through interviews and risk rejection. Austin loves their career and would not change much, but says that fear slowed their understanding of how big organizations and large codebases work, coming from academia.

Austin's summary advice is simple: do not give in to fear.

Make useful contributions visible

Feinberg says the strongest signal is evidence of building something that others use. Useful contributions to an existing project give a candidate concrete proof of impact and make their capabilities visible to the people who might work with them.

QDoes the advice change for an internal transfer, such as an infrastructure engineer moving into a frontier team?

Feinberg says the advice so far assumed an external hire. Many large organizations do not build frontier models, but still use them. Feinberg gives the example of a colleague from the search side who moved onto Feinberg's team. That colleague's approach was to help the product area adopt the technology as well as possible. Feinberg says there is a large gap in applying and serving LLMs effectively inside such an organization.

Feinberg says becoming the person who closes that gap creates business value and raises the standing of the organization. It also makes that person the natural partner for the research side, so models work well inside that org. Feinberg says transferring is then optional. The work is already cutting edge, because it puts new technology into a product people use.

QIf you could advise yourself just after college, what would you say?

Feinberg's first advice is to chase the problems people face today. Feinberg says a person should not avoid a smaller or less glamorous part of a big problem, even if it is not fancy research math. Working on what matters shows what moves the frontier. Feinberg calls for humility in how to approach problems.

Feinberg's second piece of advice is professional: be the co-worker others want to see succeed. Feinberg contrasts this with workplace leaders who squeeze people for short-term results. Feinberg says the most effective people are kind, and cites a mentor who first introduced Feinberg to computer science as one example.

Feinberg says a generous approach can look naive when viewed as workplace game theory, but it builds collaboration and a willingness to help. That trust matters for large projects that need several people and skill sets to finish. Feinberg's summary is to be the kind of person other people want to see succeed.

QHow do you choose good teammates?

Look at demonstrated skills and projects rather than titles alone. She checks GitHub work, activity, and experience relevant to the proposed project. She also values enthusiasm, effort, resourcefulness, and a willingness to attempt the unfamiliar. The best credential is useful evidence that the person can contribute to this particular build.

QWhat is the social part of a hackathon?

It includes both the team and the judges. Inside the team, motivation matters over the whole event: one person giving up can affect a small group disproportionately. An enthusiastic teammate can lift the group, and she has seen the strongest results when everyone is fully engaged.

QHow do you present a project to judges?

Keep the pitch short: state the idea, explain what it does, and spend most of the time demonstrating it. Watch whether the judges understand and let them interact with the result. In her experience, many judges were not deeply technical, so a list of frameworks was less persuasive than a product whose value they could see.

This does not rule out technical ambition. A complex project can feel clear and simple when it works well and the presentation makes its purpose obvious. The mistake is assuming that complexity alone is the reason it should win.

QDid hackathons strengthen your initiative?

She already had some willingness to try unusual things, but thinks the events helped. School sometimes felt repetitive, and building offered a more stimulating outlet. Coming from an environment where few people were seriously pursuing startups made that experimentation feel different from the usual path.

QWhat can a student at a less recognizable school do to stand out?

Develop initiative and responsibility: lead a club, help decide the direction of a substantial project, or make useful work visible. Her point is to become someone who makes decisions and carries them through, rather than relying exclusively on the school’s name.

QWhat does a personal brand do for a student?

It makes subsequent work easier to discover. A project shown to a small group reaches only that group; a visible body of work can reach many more recruiters or potential collaborators at once. She sees it as increasing the chances that useful opportunities find her.

QHow did you choose your first team at Meta?

An initial London-based option lost its appeal when code review across locations took days. Sash then met someone who saw his mix of design and engineering experience as a fit for a team that would turn designers’ unused prototypes into shipped experiences.

That News Feed delight team prioritized animations, playful interactions and other small moments of enjoyment without a clear metrics requirement at the outset. He loved it, but the team lasted only about half a year. Looking back, he recognizes that an enjoyable proposition without a durable impact story was unlikely to survive scrutiny in that organization.

QHow could a design-oriented team prove its work was successful?

Sash retrospectively sees the need for an executive sponsor with a credible theory of value. He recalls a survey measure asking whether people felt Facebook cared about them, which supplied a possible connection for delight work. The measure was subjective and open to interpretation.

He thinks it is harder to defend such teams when the company is intensely focused on efficiency. This explains a tension in his choices: he sought work he found compelling even when its measurable payoff was uncertain.

QWhat were you optimizing for when choosing teams?

Initially, fun. He followed people, intuition and opportunities that seemed interesting, then made sense of the resulting path afterward. Over time he became somewhat more deliberate but still preferred risky zero-to-one work.

He noticed that many strong engineers wanted a clear product definition, diagram or design before beginning. His comfort working without those gave him a useful niche. Breadth accumulated tools, relationships and knowledge that could become valuable on later projects, although that does not guarantee a successful outcome for every move.

QWhat makes a designer especially good to work with?

A willingness to collaborate continuously. An initial design need not anticipate every engineering constraint, but the team eventually has to resolve missing data, network failure and other real-world conditions. Engineering can also introduce possibilities the designer may not have considered, such as sensors affecting an interaction.

He values short feedback loops. On an unreleased hardware project, he worked on a makeshift pipeline that showed Figma designs on the device quickly so designers could change them and immediately see the result. Both sides listening and adjusting produces a stronger product than handing off a supposedly finished idea.

QHow was your performance judged when you committed so little code?

The early team’s expectations centered on reducing uncertainty, not simply landing production code. It was staffed with senior people who understood that a risky project needed that kind of work. Sash describes this as one way a large company can encourage exploration without promising a promotion.

He also sees a tension in review cadence: frequent feedback is useful, but a short cycle can discourage bets whose outcome takes multiple cycles. He does not claim there is a review process that perfectly serves everyone. The important point in his example is that expected contribution was aligned with the project’s exploratory stage.

QWhat made the senior back-end engineer on that project so effective?

Deep familiarity with the existing system. The colleague knew how to create a feed, make a post work without an image and understand consequences elsewhere in the application. Their conversations rapidly became working front-end/back-end changes that Sash could test.

Large, mature primitives also helped. A high-level operation could provide defaults and integrations without each engineer rebuilding lower layers. The knowledgeable partner knew how to use those facilities appropriately. Sash’s playful comparison with a copilot emphasizes accurate context and judgment, rather than a literal substitute for the person.

QDid sharing prototypes build the reputation that led to new opportunities?

He cannot know exactly what others thought, but believes repeated internal demonstrations made people associate him with fast, exploratory work. Prototypes using company technology could not be shared publicly, so internal posts were an important venue even when immediate engagement was modest.

Responding to an ambiguous inquiry with something working also showed initiative. Early projects benefit from people who can move without a fully assigned checklist. He thinks that behavior stands out amid the meetings and alignment work common in a large company.

QWhy does a prototype communicate better than a written proposal?

A written description depends on everyone constructing the same mental model. An image narrows that ambiguity; a video narrows it further. An interactive prototype lets people experience the behavior directly and talk about a specific interaction.

Sash has seen meetings progress for some time before participants discover they imagined different products. A prototype can expose that disagreement early and shorten the ambiguous part of a project. Its fidelity helps alignment, not merely publicity.

QHow do you assess your growth from IC4 to IC6 despite frequent team switches?

Staying in one space usually makes leveling easier: expertise, goodwill and relationships compound around a known problem. He saw that in a colleague who remained on the original team for years. He often found that kind of continuity less interesting for himself.

His choices favored enjoyable projects and breadth over maximizing promotion speed. They accumulated connections and knowledge, with some wrong turns along the way. Because he worked long hours, enjoyment mattered to sustaining the effort.

He explicitly resists turning his path into universal advice. The right strategy depends on the career and life a person wants. His eventual promotion does not prove that repeated switching is the fastest route, only that the route can develop a useful niche for someone with his preferences.

QHow did your path compare with people from your original bootcamp group?

He remembers peers becoming managers or remaining in the same application or domain, generally doing well. They preferred vertical growth more than his broad exploration. The comparison is a small anecdotal sample, not evidence that one strategy wins.

When leaving, he found it difficult to identify a replacement for a role centered almost entirely on prototyping. He thinks large-company incentives naturally direct most people toward predictable impact. Yet a company also needs some people prepared to test uncertain directions. That balance may help it discover options beyond its established work.

QWhat are the limits of optimizing only for a metric?

Sash invokes the familiar problem that a measure can become less informative once it becomes a target: people learn to game it. He also thinks important parts of product quality are difficult to measure and require taste.

A relentlessly increasing local measure can obscure opportunities that require a temporary setback or a different direction. He recognizes the difficulty of translating that insight into a scalable framework, because large organizations also need repeatable processes. His preference for experimentation is a response to that tension, not a fully specified replacement for metrics.

QDo you regret any of the ten team switches?

Some paid off less than he hoped, but he learned from them and built relationships. Trying to be a good teammate made those connections useful in both directions: someone could invite him to a later project, or he could bring them along.

The size of that network became particularly visible after he left Meta, when people offered introductions or expressed interest in what he might build next. He values the adventure and people as outcomes, rather than evaluating every move only by title progression.

QWhat advice would you give yourself at the beginning of your career?

Address weaknesses enough that they do not obstruct the work, then invest in the strengths that make the contribution distinctive. A manager helped him see that fixing every shortcoming was not necessarily the highest-value development plan.

For Sash, that means choosing a setting where his comfort with ambiguity, design collaboration and rapid prototyping can be useful. The advice asks a person to understand their own strengths and fit, rather than copy his specific team choices.

QWhy create a podcast about senior engineers’ careers?

Ryan wanted to become a better speaker, a skill he believes affects careers, relationships, and how others perceive someone. Toastmasters supplied useful practice, but he found that recordings often went unreviewed amid other priorities. Publishing created a stronger commitment: because people would listen, he examined every word during editing. The content became both practice and a feedback loop.

QWhat was harder about podcasting than ordinary conversation?

Natural verbal acknowledgments—short agreements and listening noises—can obscure a guest’s answer in an audio recording. Ryan had to learn to express engagement with nods while holding back interruptions. Producing something pleasant to hear calls for a different listening habit than an unrecorded conversation.

QHow did you learn to let go of implementation work?

Hejlsberg offers a counterexample to the assumption that letting go is always progress. On C#, his central role became language design and specification, with less direct compiler implementation. He gradually found that too detached from the difficult coding problems he enjoyed.

Participating directly in TypeScript’s compiler restored that enjoyment. He likes design work, but writing code is also what makes him eager to begin the day. The lesson was to delegate without accidentally removing the activity that motivates him.

QHow can a very senior engineer continue coding while meeting expectations for broad impact?

His impact comes from architectural guidance as part of a group, while he remains involved in a portion of the implementation. That involvement lets him notice awkward code, emerging refactoring needs and practical issues that a specification alone would not reveal.

He distinguishes the impact of any single line he writes from the judgment supported by staying close to the codebase. Combining guidance with direct work allows him to understand the thing people use, not only describe its syntax.

QWhat advice would you give yourself at the start of your career?

Learn to work with other people earlier. Also, do not automatically accept another person’s declaration that a technical goal cannot be achieved: their limit may reflect their experience rather than a fundamental impossibility.

This advice invites investigation and persistence, rather than proving that every ambitious idea will work.

QWhat was the work behind your senior-staff-equivalent promotion?

The guest began on a project estimating usage of a Facebook property around 2015. Moving between separate data-pipeline and machine-learning systems was cumbersome, so he built helper scripts that let pipeline work live within the orchestration environment. Sensible defaults removed repeated boilerplate, with an escape hatch for advanced configuration. He estimates that a task needing roughly 300 lines in the older system could need about 20 in his library.

That experience redirected his interest from a single analysis to helping analysts and machine-learning engineers work faster. Notebook setup was another repeated pain: people used outdated wikis to install Jupyter or RStudio manually. With his manager’s agreement, he spent an initial two or three months exploring an automated setup, then recruited others. The earliest Bento was just a setup script; the larger vision was a browser-accessible environment integrated with internal libraries and eventually other languages.

Over roughly a year, the team built the platform and on-demand instances that users could request and release without maintaining their own server. He also assembled a team of six to eight people by inviting engineers who already loved building tools on the side to do it full time. He moved into a tech-lead-manager role and says his TLM2 promotion depended largely on his individual technical work and the Bento vision. The host explains that level as senior-manager or senior-staff equivalent.

QHow did you turn a useful internal tool into something widely adopted?

Bento did not initially require converting everybody’s existing workflow. The team targeted onboarding programs, where new data users had no attachment to legacy setup. In a fast-growing company, that supplied many users; existing employees then saw more colleagues on the new system.

For people who remained on legacy notebooks, the team provided maintenance and support in previously underserved channels. That created trust before a migration request. When someone needed an awkward setup, the team could offer either a long manual recipe or the simpler supported Bento path.

The team also spoke with analytics leaders about concrete pain in their groups. Those conversations revealed a larger backlog of data-tooling needs. Because no dedicated team served that area, the guest moved from core data science into developer infrastructure to create one. Adoption was therefore a mix of a convenient entry point, service to existing users, leadership relationships, and a fitting organizational home.

QHow do you take a promising risk when short-term performance expectations are strict?

The guest thinks underperformance has greater consequences than it did a decade earlier, but the key practice is the same: agree on expectations before departing from normal work. He was assigned to data consulting, while the proposed work was infrastructure, so he asked his manager and skip to make a bounded exploration part of his job.

If the tool succeeded, the team benefited; if it failed, completing an agreed exploration was still the expectation. He sees that as much safer than disappearing for three months and returning with work nobody knew had displaced his normal obligations.

Over-communicate and be prepared to hear no. He credits a manager who supported this experiment and remembers later proposals that leadership rejected. The story does not promise that every risk can be negotiated away or that an exploratory project guarantees a promotion.

QWhat did imposter syndrome delay?

A third guest would trust his judgment sooner. Successful projects, good collaboration, and feedback eventually built confidence, but earlier anxiety kept him from trying some ideas because he feared rocking the boat. Several of those disruptive projects later worked well. He wishes he had tested them earlier and spent less time worrying, while grounding the eventual confidence in experience rather than claiming every first idea was right.

QHow can a combination of ordinary strengths become distinctive?

A guest who admired specialists in design and engineering worried that being only moderately strong across several areas would not work. His actual advantage was negotiating across those areas. He would focus less on being the best at a single discipline and more on the unusual combination he could bring.

He would also be braver about sharing ideas. His fear of public speaking at school contrasted sharply with his comfort pitching a product he cared about. Explaining material as a test of knowledge made him anxious; advocating for a change he wanted to create gave him a different purpose. Passion did not magically remove every challenge, but it changed what speaking meant to him.

QWhat matters beyond being the person who writes requested code?

Addressing his younger self as Dwayne, this guest would ask how anyone knows that a requested implementation is the right thing to build. He would seek participation in those decisions, instead of defining his value only by what he can type. That wider role would have helped counter his early imposter syndrome and clarify that ideas and judgment can matter more than raw output.

QHow would you become more courageous without pretending embarrassment disappears?

Addressing himself as Brian, the next guest would be more courageous and less embarrassed by failure. He immediately qualifies the short advice as the beginning of a larger conversation about understanding feelings, not a command that makes them vanish. He thinks being more in touch with emotion, possibly through therapy, can help both the person and their relationships.

QHow do you choose an environment that values your strengths?

Another guest says a strong front-end engineer can struggle on a back-end team, or a person who loves improving frameworks can receive poor results on a team focused on product delivery. Activity alone is insufficient: even hundreds of changes may not serve the team’s priorities. Recognize a persistent mismatch and seek a team and management chain that need what you are good at. The principle is fit between strengths and valued work, rather than simply doing more of a strength in any environment.

QWhat should guide you when an organization’s inherited practices seem strange?

The final guest recommends common sense. Large companies can have misaligned incentives and processes retained mainly because they have always existed. Startups also need judgment about what markets and users actually want. He would trust and develop that practical judgment rather than assume organizational convention has already answered the problem.

QWhat distinguishes the work at E7, E8, and E9?

Philip Su begins with scope of influence: how large, valuable, or long-running an effort can someone reliably bring to completion? He offers approximate historical expectations, such as influencing roughly ten to fifteen people at senior/staff-adjacent levels and perhaps fifty at E7. He explicitly warns that his leveling information may be stale. These are illustrations from his experience, not a promotion standard for any company today.

Higher levels also differ qualitatively. An unusually deep specialist may solve problems that several less-senior engineers cannot substitute for. A broad generalist may integrate many kinds of work for a small or new team more effectively than separate hires. Headcount alone misses that distinction.

He recalls E9 being created after his initial E8 promotion and early decisions involving only a few very different candidates. Such a small and varied group makes a universal checklist implausible. At the top, informed judgment from peers and more-senior leaders matters: do they recognize work of that level, and why? He compares it to the qualitative recognition involved in academic seniority. The point is not that all evaluation is arbitrary, but that a list of tasks cannot fully represent exceptional and varied contributions.

QWhat if a strong E7 has no E8 or E9 nearby to learn from or assess them?

Su recognizes the problem both in small companies and in weaker teams inside huge organizations. Being the strongest local person can distort self-calibration or remove opportunities to observe better judgment. He recommends an environment where there is room to grow alongside strong colleagues, rather than treating being locally best as the only goal.

At very high levels, merely copying another senior person may not work because their archetype and strengths can differ from yours. He favors access to a coach who participates in the relevant promotion decisions and can give a qualitative assessment. That person can explain where the work remains short of the bar and help discuss what stronger work would look like. The desired input is specific feedback, not an assumption that proximity to a prestigious title automatically produces growth.

QWhat scope of work contributed to your own E9 promotion?

Su helped start Meta’s London engineering presence with twelve people and, over roughly four or five years, grow it to around four or five hundred. He describes managing the strategic and organizational transitions as the site expanded. A team of twelve could be run well by a capable engineering manager; several orders of magnitude of growth made problems more varied and answers less clear-cut.

One example was planning London internships and headcount based on anticipated visa constraints affecting future full-time arrivals in Menlo Park. He used data to recommend decisions roughly eighteen months before their consequences. Another was examining the site’s seniority distribution and whether engineers were developing at appropriate rates, rather than only checking each person’s nominal level.

The increased scope involved both breadth of people affected and the time horizon of judgment. He presents a collection of such decisions as the promotion story rather than naming one isolated code change or asserting that simply growing a site guarantees the same level.

QWhat was the story behind your first senior-level promotion, at Instagram?

After the rumor work, Adrien met Instagram's co-founder and CTO. Facebook had acquired Instagram in September 2012, and the core team had about 30 people. Instagram had no personalization and no A/B testing. He started with the Explore tab, adding personalization, and needed a way to measure whether it worked. Product leaders said they had bigger priorities during Instagram's move from AWS to Facebook infrastructure.

He built the testing system anyway, with a product manager giving cover. He reused Facebook's system. Because Instagram ran on different infrastructure, he added a custom Facebook API endpoint, allowlisted to Instagram's app ID, to log exposures. He calls that hacky and probably expensive. He also added user hashing, connected the logs to the data warehouse, ran a server-side A/A test, and worked with mobile engineers on small experiments.

He says he did not know promotions existed. He was an IC4, and when his manager announced an IC5 promotion, he had to ask what the level meant. He then handed the A/B testing system to a newly created team that owned it.

QWere there cultural differences between the early Instagram team and Facebook?

Adrien says he never officially joined the Instagram team. His data science group worked like consultants, embedding in other teams while his reporting line stayed the same, and he had two managers in his first few years. Instagram felt like a startup within a startup. Facebook had about 2,000 employees, and the core Instagram team of 30 to 40 people fit in one conference room, with a focus on design and craft over data.

QCan you tell the story behind your IC7, or senior staff, promotion?

Adrien worked on projects that brought data to non-data teams. One project to count users of a Facebook product needed machine learning and inference, but the tools were poor. He built a library to run data pipelines inside the machine learning framework. He says a pipeline that took about 300 lines in a standard system could take about 20 with the library. That convinced him to build tools that help others move faster.

Half the company used Jupyter and half used RStudio, and setup depended on outdated wikis. He proposed that everyone have a Jupyter instance, pitched a two-to-three-month trial to his manager, and built the first version of Bento. At first it was only a setup script. The vision was to connect it to company tools, so a user could open a browser, type Bento, and get a notebook with internal libraries ready.

Bento on demand later let users request a temporary instance instead of a shared dev server. Adrien helped lead the work and built the team by hiring people who were already building tools on their own time. He became a tech lead manager and was promoted to TLM2, which he says is equivalent to senior manager and to senior staff engineer in the industry.

QWhat is the step-by-step process for getting internal tooling from an idea to something everyone uses?

Adrien says Bento did not try to win adoption within existing workflows. The team targeted bootcamp, the onboarding program for new hires, and told everyone who worked with data that this was the way to set up. The company was growing fast, so many newcomers did not know the legacy systems, and others followed their peers onto the new tool.

The team also maintained legacy setups that had gone unmaintained. Doing that built trust with users.

QYou took on a performance risk to build something that could flop. Is that harder today, and how should someone take risks for bigger rewards?

Adrien says the stakes for underperforming are higher now, but the approach is the same. Align with your manager first, because people are judged against expectations. He told his manager he would step away from assigned work and asked for two or three months to explore the idea. He called it a calculated risk that the team agreed to.

He thinks doing your own project in secret is riskier, since you can show up after three months with a result nobody knew about. His advice is to overcommunicate and be ready to hear no. Later, when he tried to build consensus for other ideas, he was sometimes told no.

QWhat was the thinking behind moving into a tech lead manager role?

The team was building a product that had to scale, and it needed more people. Adrien could hire a manager with a different vision or try management himself. The move was driven by a wish to lead the team he had assembled, not by a plan to become a manager. The team needed a manager, and he became that manager.

QWhat advice do you have for ramping up in a completely different domain?

He starts with a social network exploration: talk to people and ask who else to talk to. Do not fear basic questions, since everyone knows a newcomer is new. He also gets hands-on. Although he never officially worked on firmware, he read the code and made a few changes. He then picks a hard problem he roughly knows how to solve, because he learns by doing.

QWhat scope got you promoted to IC8, principal engineer?

Adrien became responsible for all experiences on a device, across dozens of teams and about 35 product managers. Partner teams owned the operating system layer. His job was coordination, architecture, and hitting milestones. For a product such as Ray-Ban Meta, the experiences include on-device AI, music, photo capture, and the companion app.

IC5 surprised him. For IC6 he asked his manager to put him forward, and IC7 took a couple of review cycles. For IC8, his manager had never run that promotion, so they worked out the packet together, and Adrien wrote much of it. He built consensus with several vice presidents early, and asked a director for monthly check-ins on the gap to that level. Six months later, the director supported the promotion because he had been involved throughout.

QWhen a role is limited to one person, such as the only tech lead for a program, how do you secure scope?

One engineer was the tech lead for the whole program. Adrien saw that much of the experience work could be handled by someone focused on it. He took it off the lead's plate so the lead could focus on the wider program, while the lead kept the systems work. The two built trust. After about a year, Adrien asked leadership to formally recognize the role, so he could describe it in one sentence.

He rejects the idea that taking scope is stealing. It is a problem only if you do not talk to the person. He asked the engineer first, who agreed, and he asked again later about a related area. Overcommunicating is the consistent theme.

QYour career has been a series of bumping into the right people. Do you have tips for maximizing luck with people opportunities?

Adrien says none of his work happened in a vacuum. Early on he had rough edges and strong opinions that did not help him, and he learned that people succeed together. He says trust and respect mean people show up when you need them, but you should not help others in order to get something back.

He also says do not be afraid to ask. For career changes, he never applied through a job website. He reached out to people he knew and asked for small favors, with an easy way to say no. People are busy, so silence is not a verdict. On luck, he says taking more shots increases the odds.

QIf you could go back to yourself right after graduating college in France, what advice would you give?

He would say to be a good person, invest in things that are fun, and invest in relationships with co-workers. Credit matters less than it seems, since everyone gets credit for something. He was very credit-driven early on. He would also tell himself to be patient, since he sometimes pushed for promotions before he was ready, and to stay curious and enjoy the work.

QCan you give the high-level story of your time at Symantec and how you grew to fellow?

Nachenberg started in about 1992 as an intern at the Peter Norton Group, which Symantec later acquired. He thinks he was the first intern there and says the company had no desk for him, so he worked in the QA lab. By the time he left in 2016, he had gone from the most junior person to the most senior engineer at Symantec.

QWhat did the career ladder look like at Symantec, and how did hiring work for someone as senior as you when you joined Google?

Nachenberg says the levels tracked those at Google and Meta from junior engineer up to staff. They differed at the top, with distinguished engineer and fellow at Symantec. Google told him it could not hire a fellow without knowing how he would perform there. He was effectively downgraded to principal engineer, level 8, from what he says would have been about a level 10 and a vice president role at Symantec.

QWhat do promotions at the highest levels look like?

At Symantec, Nachenberg says, promotions up to senior technical director were handled within the organization, provided a vice president or senior vice president agreed. Distinguished engineer and fellow went to a core group of technologists led by the chief technology officer. The group met quarterly, reviewed applications, and had candidates present their work. The aim was a consistent bar across the whole company, not division by division.

QWhat set you apart from other engineers on the way to fellow?

Nachenberg credits impactful projects, not always the most technically difficult ones. He looked for gaps: things the company needed that no one was stepping up to do. Symantec in his early years was, in his words, the wild west, with no agile process and no engineers testing their own code. He was never handed a boxed-in project. Because he already knew the technology as an intern, he was told to work out what to do and do it, and he says he chose projects that landed, shipped and transferred into the product.

QWhat kept you at Symantec for so long?

Nachenberg says, honestly, imposter syndrome. At Symantec he felt secure because he was well known there. He worried that his success came from having grown up in that company, and that he might not be good enough for Google or Meta. He stayed because it was comfortable and he complained a lot. Near the end he was unhappy, since senior roles bring more meetings and less building, which he describes as a lot of BS.

QWhat was Google X like, and were there cultural differences?

Fewer than expected, Nachenberg says. The main difference was the quality of the people, who were very smart, whereas Symantec lacked an engineering culture, at least until it began to form around 2016. What was the same was that many people lacked project taste. They were smart, but he doubted they picked projects that would land or were feasible. He says this is true of engineers at any company.

QWhy did you eventually leave Google?

Nachenberg again cites imposter syndrome, plus a wish to work at a startup instead of a slower, more regulated environment. He says there were big problems he could have taken on, such as moving Chronicle's expensive storage design off heavyweight systems like Spanner. He lacked the confidence to try. Expectations at senior levels are high, and at Google he did not feel leadership would back him if a months-long attempt did not land. At Symantec his managers had known him for years and gave him rope. He was offered other roles, such as secure databases that compute on encrypted data. He wanted something new, and talks with Waymo people while at X had made him want to work on self-driving cars.

QHow did you become a lecturer at UCLA, and how do you make your lectures engaging?

Nachenberg taught programming at Learning Tree around 1990 to 1991, including to DeVry staff. He also ran evening whiteboard sessions at UCLA as an undergraduate. Years later, a colleague at Symantec who lectured part time at UCLA told him to apply. Nachenberg assumed his lack of a PhD ruled him out. After months of silence, UCLA called in a panic when a lecturer dropped out, and he had two weeks to plan an undergraduate course. That was about 25 years ago.

For lectures, he designs for roughly the 30th to 50th percentile of the class, and uses himself, a slow learner, as the model. He asks what he would want to know on first meeting a topic, and what students are likely to be fuzzy on. He says he spends days with ChatGPT o3 simplifying concepts, then checks with Gemini and compares differences, because he finds good online material scarce and textbooks poor. He also wants students to enjoy class, so he adds humor, color and surprise.

QLooking back, is there anything you regret or would change?

Nachenberg says he should have left Symantec earlier. His rule is to stay while you are learning, building skills and feel free to fail occasionally. He lost that at Symantec, but stayed because he lacked confidence, not because the work interested him. He still values staying five or even ten years as long as you learn. Switching teams can keep a good reputation and institutional knowledge. Staying too long makes you stale and comfortable.

He also notes the cost of leaving. At Symantec he was widely known and appeared on TV and in major newspapers about Stuxnet. At Google nobody cared what he had done before, so he had to rebuild trust and reputation, which is stressful.

QIf you could advise yourself on graduating from UCLA, what would you say?

Nachenberg says there is no single item. First, do not let fear of failure hold you back. You can probably do more than you think, and he says he might have had a richer career had he listened. Second, focus on outcomes: who will use the work, what they care about and how they measure success. Problems often need a small square piece, not a perfect round thing.

He says he once presented technology to senior leaders, who did not care how the algorithm worked. They wanted to know whether it was faster, by how much, and what it meant for revenue or headcount. Speak to their needs, not your own. Third, find a good manager who trusts you and gives you rope, since a manager can make or break your career and happiness. Fourth, learn to collaborate and not assume you are right and tell others they are wrong. He says he still struggles with this.

QWhat was the overall promotion and compensation timeline?

Ricky joined Google as a new graduate in 2017 after an internship. He reports approximately $180,000 annual compensation plus a signing bonus, then promotion to L4 after a year and a half at about $250,000, L5 after another year and a half at roughly $350,000, and L6 three years later at roughly $500,000–$520,000. The amounts are retrospective figures from his own situation, including equity effects, rather than current compensation guarantees.

He credits a fortunate team match and considers reaching senior in three years faster than the typical path he observed. Staff took longer and involved a different kind of responsibility. The career story combines his deliberate work with opportunities he did not control.

QWhat happened in the junior-to-midlevel promotion process?

In the review system Ricky describes, ratings arrived every six months. He first met expectations, then exceeded them, and received a still stronger rating alongside promotion. He believed his impact and independence matched the next level but worried that short tenure might count against him. His manager supported the attempt.

QWhat behavior made the first promotion possible?

Independence: finishing projects with less handholding and finding ways to unblock himself. This did not mean refusing to ask anyone for help. It meant learning enough to move the project without requiring the manager to solve every obstacle.

QWhat changed when working toward senior?

He became the owner and go-to person for a defined area, learning its code and delivering several impactful projects there. Ownership meant being able to answer questions and advance the area, not merely shipping more isolated changes.

QHow did you recognize projects that were genuinely at the next level?

He studied teammates’ successful senior promotions to understand the scope and complexity expected, generated comparable ideas, and asked his manager to calibrate them. Roughly a year before his promotion he proposed a roadmap and asked whether completing it would meet the bar.

This gave the manager something concrete to assess and made the growth plan explicit. The roadmap emerged after approximately six months of exploration following L4, rather than immediately on the day of that promotion.

QWhat did you do when requested work did not advance that roadmap?

He learned to say no to unrelated projects that consumed time without helping him grow. He distinguishes that from accountability: a bug he caused, or a bug within his owned area, still needed attention. A new request could also be worth accepting if its impact and scope were stronger than the existing plan.

QHow did you learn which ideas would have impact?

First define what the organization values. In his advertising area, revenue was a central metric, alongside whether the work helped users, advertisers, and publishers. Other teams might care about active users or product interactions. Running experiments exposed gaps where improvements could move the relevant outcome.

He found measurable results persuasive in arguments about project value. His emphatic statement that numbers settle the matter belongs to his experience in a revenue-measured area; it should not be treated as a claim that every engineering contribution is captured by one number.

QHow did the senior promotion itself feel?

It felt more uncertain than the first promotion. Ricky believed he was ahead of the timing commonly observed around him and worried that the committee might want a longer record of next-level work. His manager supported submitting while setting realistic expectations that it could fail. It succeeded on the first attempt, which Ricky describes as fortunate.

QWere there growing pains in becoming a leader?

Yes. Handing project ideas to junior engineers made him anxious about whether experiments would succeed; some did not. He had to become comfortable with a portfolio of ideas rather than expect every one to work. A comparatively good success rate, mentoring, and positive influence on other people’s projects supported the case, while confidence developed through practice.

QDid you feel stuck waiting for staff?

Rather than wishing it had arrived sooner, he sometimes wishes the opportunity came later. Senior offered more flexibility for breaks and personal activities, whereas broader projects created meetings and a more rigid schedule. He advises looking at the actual calendars and work of nearby staff engineers before deciding the trade is desirable.

QWhat was the biggest difference between your senior and staff work?

At senior he knew and owned a space and delivered projects within it. Toward staff he challenged the boundaries of that space, questioned the established direction, and guided consequential decisions across teams and functions. Some changes required senior-leadership buy-in. Knowing an area became a platform for shaping where it should go, rather than only operating effectively inside it.

QHow did you find the anchor project for staff?

Deep familiarity made him question practices that no longer made sense. In one example, established user research supported a conclusion but product experiments contradicted it. He pushed the evidence that another direction could produce greater impact. He does not disclose the specific product decision, so the lesson remains about examining assumptions and reconciling conflicting evidence rather than a reproducible advertising tactic.

QHow did you influence other teams and partners?

He had developed a reputation for finding impactful projects. He shared ideas, collaborated without trying to displace others, and turned proposals into projects that launched successfully. Relationships and repeated results gave his judgment weight.

QWhy did you want to try management?

He already enjoyed helping colleagues grow, finding projects for them, and seeing them succeed. A formal management opportunity appeared after he had expressed that interest, and the team supported it. Fulfillment in developing others was the principal motivation.

QWhat changed most between IC leadership and management?

Technical leadership supplied enjoyable elements of helping people succeed. Formal management added difficult performance feedback, review writing, and calibration overhead. At the same time, seeing an actual report get promoted felt especially rewarding because he had direct responsibility for supporting that growth.

QDo you regret becoming a manager?

He mainly wishes it had happened later. In an unusual period with around twenty new hires, he was informally helping many of them; becoming the formal manager of four narrowed that responsibility and gave some time back. Nevertheless, he would have liked a few more years of senior-level flexibility and lower stress.

He now better understands what higher-level work entails: much of the influence is through other people, so meetings increase whether one is an IC or manager. A nine-to-five calendar can still be an intensely committed day with little discretion about naps or gym trips. Ryan adds that fragmented daytime meetings pushed his own technical work into evenings after reaching staff. The title’s appeal should be assessed against its daily experience.

QWas the staff promotion different from the previous applications?

He again felt uncertain despite sustained top ratings. Moving from senior to staff could feel like a job change: being an exceptional senior with high impact did not automatically prove readiness for the broader role. A supportive manager and a successful first submission made the outcome fortunate.

QCould you repeat that career path, or did luck explain much of it?

He benefited from enjoying the team he was matched into, organizational stability, and managers able to support him. Reorganizations, poor fit, or a manager’s absence could have delayed otherwise good work. He separates the chance that an opportunity appears from being prepared to use it. Effort helped with the second; it did not fully control the first.

QWhy stay at Google for seven years?

He regularly reassessed whether he enjoyed the work and whether the team still offered what he wanted: growth, travel, and work that was sufficiently interesting. Staying was an active decision, not proof that he never considered alternatives. He also acknowledges survivorship bias: people without comparable growth or fit might have had good reasons to leave.

Ryan describes the accumulated advantage of staying in a healthy setting: relationships, code knowledge, and organizational context can expand from expertise in one area to many. That momentum can enable unusually fast growth, while changing employers can offer other benefits. They do not reduce the choice to a universal rule about job hopping.

QWhat advice would you give your new-graduate self?

Trust his judgment more and try boundary-pushing ideas earlier. Anxiety made him postpone ideas he later pursued successfully. He believes earlier confidence could have reduced stress and enabled more experimentation, though he developed it gradually through results and good feedback.

QHow does Microsoft's leveling system work, given that levels run upward from 59 with about two levels per title?

Fowler says he cannot explain why numbering starts at 59, and guesses the lower levels cover non-engineering roles. A college graduate typically starts at 59 or 60, depending on how many times they interned and how well they did. Fowler equates entry level with an SDE I at other companies.

A title maps to a band of about two levels, so a title does not reveal which level someone holds. Principal is the exception at three levels, and Fowler says that band is so broad that a new arrival from senior and a long-serving principal share a title. Above principal come the partner levels, which Fowler says have three bands, and then technical fellow.

QWhat did your performance review look like after NuGet, for someone who was not yet a senior engineer?

Fowler's first promotion came about eight months after joining, before NuGet. Because he had interned twice, he arrived with a lot of Microsoft experience. Beyond assigned work, he read forums for feedback on Microsoft's products, built features to answer it, and showed the results to product managers, architects and the team. Looking back, he says those people became sponsors and positioned him to build NuGet.

Fowler calls himself a code-first, ask-questions-later person and says code is currency: a working sample beats a PowerPoint or a document. A director once told him he would send people to talk to David because David has energy.

QHow can others start projects like this within a large company, when the motivation comes entirely from them?

Fowler's one-sentence answer is that you can just do things, which people now call agency. He does not recommend spending every night and weekend on projects, but early on his goal was to get better at software engineering, and the way was to build everything possible: games, websites, many kinds of software.

The second habit was to find someone on the team whose career he wanted. Fowler attached himself to the architect David Ebbo, whose role spanned several areas and looked ahead, copied his behaviors, and for a while coded Ebbo's ideas, which turned into doing it independently. He then built prototypes and showed them to an advocate, the architect or the product manager, to ask whether they were useful. He says he would build a thousand things and maybe one would hit.

QWhat led to the promotion to principal?

Fowler recalls a boss who, when he reached senior, said promotions would slow. The jump to principal turned out to be large. Alongside SignalR, he built Kudu, an early Azure tool that let people push code and deploy an app instantly, as Heroku and AppHarbor did. A director then pulled him onto a new project that became the cross-platform .NET Core.

Fowler was senior, and he and another principal engineer were chosen as architects over about 30 engineers with free rein, which he calls amazing and terrifying. At first he tried to code review every change and was burnt out within a year, and had to learn to trust people and separate urgent from not urgent. He had his first child and was promoted to principal that same year.

QWhat does the architect role mean at Microsoft?

Fowler says it is a semi-official role open to the middle principal bands. When he joined, he saw a principal software architect and decided that was the role he wanted. He describes it as breadth over depth: overseeing the design of the whole system. Other archetypes at the top include a super coder who builds enormous amounts, deep specialists such as one of the leading garbage-collection experts working on the .NET collector, and people overseeing a hugely impactful product area.

As architect for ASP.NET Core, he oversaw the web framework, the web server and how packages shipped, vetting decisions that could last 20 years. He had not done this before and learned by shadowing mentors who had.

QAs a distinguished engineer, how has the share of your time spent writing code changed?

Fowler says the job may no longer reward daily coding, but selfishly he codes every day and currently sends many pull requests on a project involving Aspire. He does not want to be an architect who gives instructions without knowing the code and then disappears. He wants to be a peer on the team, facing the builds and the tests.

QWhat is the story behind the promotion to distinguished engineer?

Fowler calls it the craziest promotion he has experienced. Distinguished engineer is the last level within partner, and it comes through an official process, not an annual review: a set of technical leaders peer-reviews the candidate. Guido van Rossum, who created Python, is at the same level, and Fowler describes maximum imposter syndrome. He also thought he was young for the role, though that did not count against him.

Fowler says earlier work carried it, because the role requires a body of work and a track record, not one good year. The email promoting him from principal to partner cited .NET Core, by then about seven years old, and he had acted as architect helping many teams adopt the new .NET internally. NuGet and SignalR counted as signals of how what he helped build affected the industry and the company. He says the fellows decide.

QWhat does the final level, technical fellow, look like?

Fowler says people at that level are unicorns with different paths, so the useful move is to look for proxies for impact, not copy anyone. A fellow needs industry-wide impact. His examples: Anders Hejlsberg, whom people in his division idolize, made Turbo Pascal, Delphi, C# and TypeScript. Dave Cutler, who Fowler says built Windows NT, the Azure operating system and the Xbox hypervisor, is the only senior technical fellow, a title Fowler says is simply his own.

Fowler adds that Microsoft recently hired a fellow who invented RSS, and that a teammate was once an intern for Tim Berners-Lee and is on the HTTP specification. These are Fowler's own statements and were not checked against other sources.

QWhat did that mentor say that made a difference?

Fowler says much career advice is vague, such as telling someone to do a super impactful project, whereas Snover was direct. He suggested going to the people who decide, including the CTOs, and asking what the role requires. Fowler found it jarring, since no one had told him to ask the source, but very helpful, because it showed him what he should and should not be doing.

A second mentor helped after Fowler received a feedback package from his manager and peers listing strengths, weaknesses and behavior under stress. His first reaction was to fix every weakness. The mentor said to amplify his strengths instead, because no one is promoted to these roles for being average. About five years ago this changed how Fowler works. He now builds teams around his gaps: he does not schedule meetings or run every shipping checklist, and makes sure someone who is good at that does. The host likens this to a power law, and Fowler agrees.

QWhich engineers do you look up to, and what makes them impressive?

Fowler's team includes about five other partner-level engineers with more than 20 years at the company, each excellent for a different reason: a garbage-collector expert, a super coder who he says is a true 10x engineer, someone who seems to know obscure details across C, compilers and the operating system, and others with a strong eye for what to build.

On the C# language design review team, Fowler sits with Hejlsberg, whose feedback he says never talks down and stays pragmatic, even though the code Hejlsberg commits looks like it is inventing theory no one has seen. Fowler also names Mark Russinovich, CTO of Azure, who still codes and recently emailed about a performance improvement he wrote. Fowler is inspired when senior engineers still code.

He warns about the meeting trap. After becoming partner, he sat in meetings all day and was sad. A mentor told him an individual contributor needs time to think and build, and to block at least eight hours a week. It took him a while to learn to decline meetings.

QYou tweeted that when promoted to senior you felt others were smarter and should have gone first. What did you take from that?

Fowler worried about being promoted early on a fast path. His team had four people from MIT and two from Carnegie Mellon, and he had gone to Florida Tech, so he worked through imposter syndrome by working very hard.

The promotion taught him that impact is not about being the smartest, but about whether the work is at the top of the business, as NuGet and SignalR were. He had always felt he needed to go deeper on some technology, and now asks whether that is for you or for your career. He says an engineer does not need to know how TCP/IP works to be promoted to senior. It helped him separate being smart from making impact.

Co-workers were happy for him, at least outwardly. When he asked about others who had risen fast, he was told everyone knew it would happen, and he adds that you never know which category you are in.

QOne of your big-company tips is to ask when the last reorg was before changing roles. What is the thinking behind that?

Fowler calls big companies machines and recalls hearing, perhaps tongue in cheek, that executives show motion through reorgs. A reorg is always coming or has just happened, so learn about the last one: who the leaders are, what triggered it and where the org is heading. Because Microsoft is so big, he says, every new org is effectively a new company. The tweet likely followed a mentee who had been reorged several times in a row, or something that happened to him.

QWhat has kept you at Microsoft for so long, since your internships?

Fowler describes himself as part of a millennial generation that broke from the boomer-parent habit of staying in one place forever, and says many job-hopping friends were paid well for it. His closest call came when he was senior and a boss who had left for pre-IPO Twitter asked him to interview there. He interviewed at Twitter and GitHub, got both offers, and stayed after much deliberation. The morning Twitter went public, he adds, brought instant depression that lasted about a week.

Microsoft's counteroffer was fine but not the main reason. An executive vice president told him he would be a distinguished engineer in five years, which Fowler says oversold it. What mattered more was that he had built something impactful and permissionless and had gained autonomy, and leaving meant starting over. People overlook the network and track record they have built, and the people matter as much as pay: not just good engineers but good people to work with.

He also stayed because he got to work on something new about every two years, by design, which kept him from feeling the need to go elsewhere.

QDid you notice the culture shifting internally when Satya Nadella became CEO?

Fowler says the shift was huge, but it is hard to see the jump from Steve Ballmer's era because he lived through it and it happened gradually. A big one was that, historically, two teams could work toward the same end state and one would win. Under Nadella the focus moved to collaboration over being first. He saw teams building solutions before knowing the problem, though not on his own team.

He describes changes in meetings, email and remote friendliness. He remembers being surprised by someone raising a hand in a Teams meeting, having grown up in a culture where you wait for a pause and talk. Earlier meetings were often a highest-paid-person's-opinion affair, where a loud senior person could stop others from feeling safe to speak. Early in his career he saw people shouting and wondered whether he would have to shout too. Now leaders model behavior such as inviting quiet people to share their views.

Collaboration also became part of reviews: engineers who avoided other teams' work, or cloned it, were marked down. The host summarizes this as a change driven by performance incentives and top-down messaging, and Fowler adds the behaviors leaders modeled. The host recalls the XKCD comic that draws Microsoft as people pointing guns at each other. Fowler says the real shift went from guns to ambivalence, with teams staying out of each other's way, and then to rewarded collaboration.

QIf you could advise yourself when graduating college and entering the industry, what would you say?

Fowler's answer is to negotiate the salary. He did not know it was possible when he took his first job. A new graduate should get multiple offers and push the number up. Coming from Barbados and grateful for the most money he had seen, he was shocked to watch friends decline offers and say they would check Google or Facebook first. Having since sat on hiring committees for interns, he finds it impressive to watch a candidate bump up an offer well.

QWhat work and team context supported your unusually fast growth?

Simon stayed with the same team and manager for about five and a half years. That continuity was unusual in his experience of Meta, but the team’s responsibilities changed substantially. It worked in ads payments, initially improving payment experiences and revenue, then supporting a large infrastructure migration, and later returning to product work.

The product context mattered. Revenue provided a relatively direct measure of impact, while local behavior created concrete problems to solve: in Thailand, for example, people bought through Messenger and exchanged bank slips as payment evidence. His career story therefore combines organizational continuity with changing technical and product scope, rather than repeating the same job for years.

QHow did you earn the IC3-to-IC4 promotion in your first half?

His earlier Meta internship reduced the learning curve for custom internal tools. He estimates that familiarity with tools such as Phabricator and the task system saved four to eight weeks. Before joining full time, he had also explored technologies through small projects, so bootcamp tasks were easier and he could help other new hires.

He joined as the second engineer on a new ads payments team. That gave him substantial access to a technical manager and impactful projects. Simon says the projects he delivered produced more than three times the team’s half-year revenue goal. The behavioral distinction was ownership of complete projects: finish the task, seek the next related opportunity, investigate disappointing results, and bring the work to a conclusion while asking for help where needed. In his account, promotion followed demonstrated next-level behavior rather than promising potential.

QWhy join a tiny product team, and where did the technical mentorship come from?

He originally expected to join an infrastructure team because C++ infrastructure was his interest and his internship background. During bootcamp, however, the first manager he met connected career growth with revenue impact and made a persuasive case for ads payments. The team also felt welcoming.

The manager had recently moved from IC6 engineering to management and could guide technical decisions as well as product experiments. Simon ran 20 experiments in his first half when the broader organization ran about 50. He attributes much of that velocity to direct, technically informed coaching.

QWhat produced the first “redefines expectations” rating at IC4?

Simon says impact was the primary driver. His project exceeded an already ambitious team revenue target measured in many tens of millions of dollars. Recruiting and onboarding additional engineers also contributed, and he broadened his reviews across JavaScript, Hack, Android, and iOS as the team grew.

The revenue result was not obvious at the outset. A strong data scientist suspected opportunities, but several initial experiments were neutral. In one, a failed-payment notice did not help advertisers as expected; examining the result led to better targeting and design, after which the project contributed roughly a fifth of his impact that half. In another, a daily script changed advertiser settings but experimentation logging failed. He read the code, contacted the experimentation team, and worked with the data scientist to understand the failure. The important pattern was continuing to investigate rather than declaring the first neutral result final.

His code review also aimed to develop people. That required calibration: some feedback said his reviews were overbearing, while other feedback said they made colleagues better engineers. He does not present helpful review as having been effortless or perfectly balanced from the start.

QDid you expect those early ratings, and how did you interpret them?

He had little context for the rating scale. As a new arrival from Sweden, he had not understood that restricted stock would become a large part of compensation, and he was not predicting ratings closely. The first promotion was revealed through his manager’s routine of taking newly promoted reports to dinner.

He was happy with the later top rating, but receiving strong results so early made it hard to judge how unusual they were. His only prior comparison was a promotion with a “greatly exceeds” rating. He knew someone else with a top rating, which also made it seem less rare. His account cautions against treating a person’s early expectations as a reliable guide to the broader distribution.

QHow could the highest performance rating come without a promotion?

In Simon’s explanation, ratings largely recognized what he achieved, whereas promotion asked how he achieved it. IC4 work meant driving his own project. IC5 required broader responsibility for others and their projects. He was helping onboard people but was not yet accountable for their success, so very large individual project impact did not by itself demonstrate the IC5 role.

He and the host stress that ratings and promotion are correlated without mapping one to one. Repeating a great deal of current-level work can produce a strong rating while leaving the next-level behavioral gap unresolved.

QWhat happened during the COVID review pause and your eventual IC5 promotion?

The first COVID half used annotations rather than normal ratings and did not include promotions. Simon understood his annotation as indicating substantially above-expectation performance. He was disappointed because he felt on track; at that point a single half represented a large fraction of his career, although he now recognizes careers are much longer.

In the next half, he received another “redefines expectations” rating and the IC4-to-IC5 promotion. He qualifies that result: ratings were somewhat boosted to recognize work from the prior half, and his unadjusted result might have been near the boundary with “greatly exceeds.” He does not claim that all strong performers were automatically bumped to the top rating.

The substantive change was leading a pod of about four people through an unscoped product space from initial idea to completed projects. The product itself was not as successful as hoped, but handling the work, people, and director-level escalations showed broader ownership and communication. Promotion therefore reflected changed responsibilities even when the product outcome was imperfect.

QWhy did the team trust you to lead a pod while you were still IC4?

Simon sees two foundations: strong technical ability and an interest in people’s growth. He had studied computing from high school in Sweden and enjoyed solving difficult problems across platforms. He also cared about whether colleagues succeeded, had helped people improve, and had already done some sprint planning before taking full responsibility for a pod.

He distinguished prioritizing work from owning its outcome. Earlier he could help plan tasks without being responsible for the project’s or engineers’ success; the pod leadership assignment added that responsibility.

QWhat changed between IC5 and IC6?

He earned the next promotion in two halves. First, one pod became two pods with roughly seven people, forcing him to delegate sprint planning and recruitment follow-through. He coached new pod leads and colleagues doing outreach, sometimes retaining the difficult initial recruiting conversation while letting others manage the candidate afterward. Those assignments also created growth opportunities for the people receiving them.

His initial delegation had a serious gap: he trusted that work would succeed without tracking it well enough, then discovered slippage near the end of the half. He later learned to zoom out, establish milestones and goals, notice stalled projects or struggling people earlier, and intervene in the specific gap rather than wait for a crisis.

His later scope included an eight-person team plus a separate project involving about 13 people. This tested whether he could combine roadmap and people leadership with deep technical contribution. Detailed reviews across clients and back ends helped him understand system interactions and catch incompatible implementations. Near a payment milestone, he also debugged a difficult path spanning Android or iOS, Instagram servers, Meta’s main backend, C++ payments infrastructure, and an external payments partner. He credits both broad coordination and the ability to go deeply into a hard technical problem.

QAfter reaching IC6, how did you decide whether to pursue management?

He remained ambitious, but management presented an identity concern: he valued being a capable engineer and worried that years away from technical work could leave him feeling less useful. The opportunity nevertheless came with his longtime manager’s support. Both had moved to London, and his manager was leading two teams with too many direct reports. Simon already led one of those teams technically.

He chose to try management because learning under a manager he admired seemed unusually favorable. He hoped to become a similar kind of manager, rather than viewing the move as the inevitable next promotion.

QWhat made that manager unusually helpful?

Simon emphasizes care for people, projects, and impact; familiarity with Meta’s processes; and firsthand understanding of rapid engineering growth. The manager was also strong at product direction, setting a clear roadmap and communicating upward and downward. That let engineers execute while learning how to reason about data, growth, and product choices.

Written communication was another major lesson. Simon believes people can do excellent work yet limit their careers by explaining only what they did, without explaining why it mattered, what was learned, or what the company gained. A clear internal post can reach thousands and remain available for future decisions.

QWhat makes a project update effective?

Assume a reader may spend only five or ten seconds on it. Simon recommends a genuinely short summary, visible before any “see more” expansion, with meaningful numbers when available. Readers should be able to recognize the result and its importance immediately.

He organizes the early portion around context, impact, and next steps, then offers technical details for specialists. Most of a large audience will not know the exact subsystem, but they can still care about outcomes and reasons. The host adds that engineers often lead with code-level investigation that only one or two collaborators understand; status, metric movement, and why the audience should care are more useful first.

QWhat did the management experiment teach you about technical work and role fit?

He managed for less than a year, too little time to know whether his technical abilities would truly decay. The more immediate problem was that he struggled to stop doing technical work. Reports asked him to step away; when he saw a gap, his old tech-lead instincts made him want to fill it. He acknowledges that he did not fully correct this before returning to individual contribution.

The circumstances were also unusually difficult. His immediate manager had an accident and was out for months, his skip-level manager was on parental leave, and the nearest available leader was a California-based director returning from prolonged sick leave. Simon was in London, so context and time-zone support were weak. He also had to leave London and was trying to support two engineers who wanted IC5-to-IC6 promotions on a small team. He believes he overpromised: one could take his former technical leadership role, but finding equivalent scope for both was hard.

Burnout and the loss of his support network contributed to switching back. When a director asked if he wanted to return to IC work, the answer felt immediately right. He remains open to management later. His conclusion is qualified: better circumstances might have kept him in management longer, although he suspects he might still have returned to engineering.

QWhat was the discretionary or additional equity you received?

Simon describes additional equity as extra restricted stock units granted at a director’s discretion. He received it twice: around the IC5-to-IC6 promotion and about a year later as he moved into management. The first arrived through an unexpected 15-minute director meeting. He had seen compensation-group posts about such grants but recognizes that those posts skew toward unusually strong outcomes.

He speculates that retention and a low original new-graduate stock grant may have contributed to the first award; he does not know the decision makers’ full reasoning. He associates the second with successfully shipping a priority product in London faster than expected. Together, the awards materially increased his compensation. Market comparisons were hard at the time because Meta’s stock price had fallen.

QFrom your experience as intern, intern manager, and intern director, what helps interns succeed?

He nearly failed to get his own return offer, later managed two interns with very different starting points, and served as an intern director overseeing roughly ten intern managers. That director role involved checking project plans and reviewing ramp-up at three weeks, midpoint progress, and the final evaluation.

He sees project completion and velocity as central, with safeguards for badly scoped assignments. A common problem is failing to ask enough early questions. During the first weeks, expectations are low and asking about basics is appropriate; delaying until week six makes the same gap much more consequential. He told interns and new graduates to ask him when a small question consumed more than roughly 30–60 minutes rather than lose repeated hours to an issue an experienced colleague could resolve quickly.

Peers matter as well as managers. A shared chat can distribute support when one person cannot answer everything. Peers also provide important evaluation evidence; knowing the intern’s project and behavior helps them give substantive feedback rather than forcing reviewers to reconstruct what happened.

QWhat workload has felt sustainable, and how does motivation affect it?

He estimates an average around 50 hours a week, with variation for California meetings and his morning routine. He enjoys the work and people, but noticed that the same hours began to feel like a grind when his interest in the product area faded.

After reflection, he moved to an infrastructure team and regained enthusiasm and better-quality output. He and the host connect the felt burden of work to interest and motivation as well as hours. This is their experience, not a claim that enjoying work eliminates the need for limits.

QLooking back, what most explains your career growth?

Simon’s central theme is expanding ownership. Early on it means ensuring that a specific task succeeds; later it means owning a team’s success. Curiosity is integral: when another system blocks you, inspect its code and history, understand why a decision was made, and bring a researched question or proposal rather than simply wait.

He interprets Meta’s saying that nothing is someone else’s problem as permission to investigate, not as an excuse to ignore people. Cross-functional ownership requires empathy: learn a partner’s goals and incentives, including whether your proposed improvement damages the metric on which they are evaluated. Technical investigation and understanding people both help unblock the work.

QHow much of engineering career growth is technical skill versus other behavior?

He does not give a numerical split. He believes a solid technical baseline can support considerable success, including IC5, if an engineer can execute work to good quality, work with designers, use data, and collaborate effectively. Extraordinary ability to solve any technical problem is not his minimum requirement for that level.

He regards interpersonal skills as particularly important for gaining trust and opportunities to grow. He also qualifies this: exceptional technical talent can outweigh other weaknesses in some cases. His view is a description of a path he has seen at Meta rather than a universal rule for all roles.

QWhy have you stayed at Meta for your whole career so far?

People and flexibility have kept meeting his needs. His initial team grew from two engineers to around 16 before splitting, and because he helped recruit many of them, the young and supportive group felt close. He continues to value colleagues’ empathy and technical skill.

Internal mobility let him live and work in several locations, including California, London, and New York, and recently move into work that revived his interest. He did consider leaving when his motivation declined, then chose to give an internal move a chance. He acknowledges that some experiences cannot be found at Meta and that his preferences may change; he has simply not yet reached that point.

QWhat would you tell yourself when joining as a new graduate?

Ask enough early questions to become productive, then keep investigating why systems work as they do. Be curious, take ownership, and avoid treating every existing constraint as permanent. In a large codebase, past decisions and abandoned experiments may no longer make sense; understanding their history can reveal useful cleanup or a way past a blocker.

He pairs that advice with time awareness. A new engineer still needs velocity and should not disappear indefinitely into investigation. Curiosity becomes more valuable once basic productivity is established.

QWhy specialize in front-end engineering?

Marius describes a longstanding enthusiasm for the web, dating to school lessons in HTML and a CSS book he requested as a Christmas gift. He deliberately sought jobs where he could build web applications, including agency work while studying computer science.

The specialty was a positive choice about work he wanted to do, rather than merely the first technology assigned to him. That preference later helped him decide which opportunities and teams fit his career.

QWhy did strong performance ratings not immediately lead to promotion from IC4 to IC5?

In his account, one behavioral gap held back the promotion: cross-functional collaboration. Strong conviction about his ideas sometimes came across as too insistent or intense. Advocating for a proposal was appropriate, but he needed to recognize when continued pressure became counterproductive.

He distinguishes a rating for delivered impact from promotion readiness. A person can deliver a great deal while still missing one behavior expected at the next level. His promotion also encountered a later company-wide pause during the early pandemic, after he had worked on the feedback. He describes these as separate causes, and his eventual promotion came at the end of 2020.

QHow did you handle the frustration of a delayed promotion?

He acknowledges frustration, especially after peers reported a visible improvement and an external company decision still blocked the result. He reminded himself that careers are long and a half-year delay has limited meaning across that span.

He continued growing and taking work beyond his current title. With a lagging promotion system, refusing to demonstrate next-level behavior until the title arrives defeats the process itself. The work and learning could continue even while the paperwork lagged, and were eventually recognized.

QWhat work led to the redefined-expectations rating and IC5 promotion?

As an IC4, he took a leading role in a large web project considered IC6 scope. More than ten engineers and several partner functions contributed. Delivering it on an ambitious pandemic-era timeline required much more than coding: interpreting product ambiguity, dividing workstreams, coordinating people, running meetings and communicating progress.

Operational excellence mattered too. A large launch that breaks systems does not become successful simply because many changes were submitted. The project landed without major issues, with attention to release hygiene.

Marius does not claim to know every detail of the calibration conversation. His interpretation is that work two levels beyond his assigned scope made the unusually strong rating easier to explain. Ratings need an articulated progression from expected work to additional contribution, rather than an unexplained assertion of excellence.

QHow did an IC4 get trusted with an IC6-sized project?

The opportunity arose through a staffing domino effect. A senior engineer was on parental leave while a major priority changed the team’s work. Another engineer covered that gap, and Marius took a project that might otherwise have gone to someone more senior.

There was luck in the timing, but preparation shaped who was considered. He had established himself as a web specialist who wanted responsibility for that platform and had a record of strong delivery. A relevant opportunity was therefore a plausible match. He calls this increasing the surface area for luck, while recognizing that wanting the project did not guarantee receiving it.

QHave you always been ambitious about this work?

Yes. Understanding conditions and loops in JavaScript gave him an early sense of agency: he could make the machine do something of his own choosing. The web also appeals to him philosophically as connected documents making knowledge widely available.

His later ambition grows from that intrinsic interest, not solely from the promotion ladder. That distinction helps explain both his sustained effort and his preference for particular kinds of engineering.

QWhat led to the next redefined-expectations rating and IC6 promotion?

He led another time-sensitive web project that enabled other pieces of a larger investment. Missing its hard deadline would block their impact. More time was unavailable, and other people were already assigned to important work, so he had to manage scope and quality with the team he had.

His preference was to reduce scope rather than casually sacrifice performance, reliability and design craft. A smaller well-built outcome was preferable to a broad but poor implementation. Some concessions can be necessary, but he wanted them made deliberately.

Product-management support was limited and important questions remained unresolved. He received credit for operating as a product-engineering hybrid: clarifying what needed to be built, aligning the decision with product and engineering leadership, defining success, sequencing work and then contributing heavily to implementation. He likens the early ambiguity to exploring a fog-covered map before the work becomes operational.

QWhy switch to Instagram web after things were going well?

His previous organization’s priorities moved away from the work he wanted to pursue. He had learned that web engineering and product quality—performance, reliability and design craft—were especially satisfying. Staying successful on a less aligned direction was not necessarily the right long-term choice.

The Instagram web team had recently migrated its technology stack and needed quality work. The opening matched his experience and interests. He began with the notifications surface, which needed modernization and alignment with the native applications, then spent much of his time in product infrastructure.

That layer sits between visible product features and deeper infrastructure: code structure, safeguards, testing and architecture that help other engineers iterate confidently. It offered increasing leverage as the expectations for his own impact grew.

QWhat do you mean by engineering leverage?

Leverage means shaping defaults and tools so other well-intentioned engineers can succeed without personally consulting the specialist for every decision. The framework guides them toward a good outcome. Marius illustrates this with front-end reliability and React error boundaries, which contain a rendering failure to part of an interface.

Adding one missing boundary fixes one location. Auditing the whole site systematically solves a broader problem. Writing guidance that explains how to trigger failures and how to distinguish primary, secondary and tertiary content lets other teams apply the approach themselves. Adding lint rules can make the editor warn about a known unsafe pattern before a change is submitted.

He uses that sequence to illustrate increasing levels of impact, while treating the level labels as his practical interpretation rather than an official formula. The more comprehensive solution continues helping after he moves on to performance or another problem. He cannot personally inspect every web product in the company, so direction and tooling extend his contribution.

QHow did you begin working on Threads web?

His manager offered an introduction to a small, initially secretive project. Marius discussed the needed web work with its hiring manager and became the only web engineer for roughly the first six to eight weeks. Scope was initially limited and later expanded.

He values that rare opportunity to help launch a new application from its beginning inside a large company. Other engineers subsequently joined, so being first is not the same as having built the entire eventual product alone.

QWhat made the Threads work a convincing IC7 promotion case?

The work was intense, but its impact story was clear. Threads needed a web presence. Marius established its foundations, helped grow and organize the team, led delivery and wrote a substantial amount of code. The scope grew from logged-out viewing and sharing to a logged-in client with feeds, notifications, settings, search and posting.

The launch and reception made the outcome visible. He says this was an unusually easy self-review to write because the connection between business need, his responsibilities and delivered work was straightforward. That clarity does not mean the project was easy or that his teammates’ contributions were unimportant.

Attribution also required senior reviewers to understand that his involvement materially changed the result. Clear ownership and responsibility for the outcome supplied that connection more convincingly than a count of isolated tasks.

QWhat does owning a launch actually require?

Marius thinks through failure modes before launch and works backward to prevent them. A new domain raises DNS and infrastructure questions; the right experts should verify the setup rather than the team simply assume it works. Other predictable risks deserve the same treatment.

Not every problem can be anticipated. Operational readiness includes error reporting, QA, release hygiene and responsive feedback channels so an unexpected browser-specific problem can be diagnosed quickly. Ownership covers the outcome of that system of preparation, not only writing the feature.

QDoes being the directly responsible individual mean doing everything yourself?

No. He divides the product into meaningful areas owned by other senior engineers. Those engineers are accountable for their areas, while he remains accountable for the overall launch. Delegating a portion does not allow the overall owner to blame that portion if the product fails.

The difficult skill is adjusting the amount of oversight. A lead should give people room to grow without disappearing from the work. His driving-instructor analogy places a hand near the emergency controls while someone is learning, then gradually increases freedom as trust and capability become established. The relationship should prevent avoidable failure without turning every decision into micromanagement.

QHow should a senior engineer distribute scope while preserving their own impact?

Marius favors reasonable ownership boundaries matched to people’s capabilities. A stretch assignment can develop someone; work far beyond their ability can set both the person and the project up to fail. Work far below their capability may also be a poor match.

He does not expect every change written by a senior staff engineer to contain extraordinary technical complexity. Sometimes the important contribution is quickly implementing many straightforward pieces that unblock a critical workstream. At other times the right role is coordinating work across teams or organizations.

The value is the necessary result and the role in achieving it. Hoarding work or judging every diff in isolation misses the context that makes the overall contribution important. He treats fast coding and broad coordination as different tools for different situations.

QWhat are you considering for the next part of your career?

He has no fixed answer about IC8. At the time of the interview, he had moved from Threads web to an important Instagram server-side project, deliberately extending beyond his front-end comfort zone toward fuller-stack work. He finds that both exciting and a little intimidating.

Management is not his preferred direction because he enjoys deeply technical individual-contributor work. He wants his work to matter and offer learning, without assuming that the next title must be the immediate goal. He also offers the Tron: Legacy soundtrack as a personal recommendation for concentrated coding.

QWhen you reached IC6, did you immediately start aiming for IC7?

Not in the way he had immediately looked ahead after reaching IC5. A more senior promotion needs a business need that matches the level as well as successful execution. Threads web supplied a timely opportunity of that shape.

The opportunity was necessary but not sufficient: the work still had to land. Conversely, an engineer without such an opportunity may struggle to make a case despite ability. His story therefore combines delivery, fit and timing rather than treating ambition alone as the explanation.

QHave higher-level expectations ever frightened you?

Yes. As an IC4, he saw IC5 as the eventual expected destination under the policy he understood then, was apprehensive about IC6 and believed he never wanted IC7. His preferences changed as he grew. Even later, he was not actively pursuing IC8 because the role would need to fit and he would not want to lose too much work he enjoys.

The account is a reminder that a person’s view of the next level can change with experience. It does not prescribe indefinite promotion seeking, nor establish a current company policy for every role.

QWhat was your most unusually high coding output?

He recalls just under two thousand diffs during the year Threads launched. The number suggests an intense implementation period, but he immediately cautions that diff counts are gameable and at best directionally interesting.

He sees no meaningful automatic distinction between, for example, three hundred and four hundred changes in a period: one person may simply split work into smaller commits. Output volume should be interpreted alongside the outcome and the context, not converted into a universal target.

QWhat advice would you give yourself when entering the industry?

Things are going to be fine; do not add unnecessary pressure. Early ambition led him to publish a blog post every week while balancing degrees, near-full-time agency work, friends and a demanding hobby. He sometimes wrote late at night merely to keep the commitment.

He enjoyed that work, learned a great deal and thinks his public writing helped a recruiter find him. He does not regret it. But he no longer considers that intensity a healthy default and would tell his younger self that the existing effort was already enough.

His practical web work also complemented university fundamentals. Theory gave him useful concepts, while years of building applications supplied expertise in the technologies he used daily. The lesson is a sustainable combination, rather than dismissing either kind of learning.

QWhat project or projects got each panelist to staff level?

Zach moved up by changing companies. At Netflix every engineer held the senior title, but Zach felt the responsibilities were already staff-level, and Airbnb later hired Zach at staff. The project Zach credits is an asset inventory at Netflix. Netflix used microservices, which give each team ownership but also leave thousands of separate applications that could each hold their own vulnerabilities. Zach built a graph database describing applications, code bases, data sets and employees and how they connect to one another. The work took about two years.

Lee was also hired at staff level rather than promoted into it. Lee had managed people for about three years at Amazon before joining Meta. Lee says technical work alone was not enough. Some people point to a large, complex project they delivered alone, but staff-level readiness also depends on whether they planned the work, split it into parallel work streams, and reduced risk so the hardest part was not left until last. Lee's hardest technical project was a custom class loader that let an Android app use multiple executable files before Google supported that, so that Amazon's video app (now Prime Video) and its combined apps did not hit the method limit. Lee did not want engineers forced to write poor code to fit a technical limit.

Ryan Peterman describes a large efficiency project that made video processing at Instagram much cheaper, 94 percent cheaper for some basic encodings. Ryan says the project reached staff level because Ryan created the scope: Ryan found the problem, convinced people it was worth doing, got buy-in, and led execution. Ryan stepped in personally only on the riskiest components. Several engineers did most of the work while Ryan led and reviewed code. Ryan stresses that staff is one of the first levels where influencing others is a baseline expectation, because software is collaborative.

Carly says the step up is not just technical brilliance. It comes down to trust and to being a collaborator that others rely on. Carly points to a presentation of security findings to an executive leader and the CTO. Carly could explain technical work to people who did not want to sit in an engineering meeting, and received a job offer from a leader in that meeting. That became an internal move to staff. Carly says this is not a normal route. The wider lesson is to know your numbers, be ready to state your impact to technical and non-technical audiences, and work on large, cross-business problems that address a real pain point. The people who decide on promotion are often both kinds of audience.

Rahul names two projects at Meta. One was an internal tool that improved debugging of the product. Rahul measured that it saved thousands of engineering hours in a year, and other engineers could plug in their own debugging tools, which multiplied the impact. The other was re-architecting the product's calling architecture, moving it onto another team's set of APIs. Rahul's lesson is to think in terms of a portfolio of bets. A big-tech company has many things outside your control, so pair one main project with a smaller one you control, and switch when one is blocked. Two or three projects is realistic, not ten. Rahul adds that a company must also have enough business need for staff-level scope, so some people get promoted simply by moving to a company that needs their skills.

QHow should a senior or staff engineer balance delegating work and doing it personally? (An attendee, Brian, asked, and Rahul rephrased the question.)

Zach recalls weekly conversations with an Airbnb manager about whether Zach was managing, delegating and coding enough. Zach loves to code Scala all day, and says that doing so has sometimes been to the team's detriment. Frank talks with a manager about how time is spent helped Zach see when more leadership was needed.

Lee says each person should know their own bias. An engineer who came from management may spend too much time on people and too little on reducing technical risk, while others lean the other way. The split does not need to be 50/50 each week. Lee also asks whether the engineer is leading from the front, finding the path and sending others down it, or from behind, pointing people in a direction. The answer varies by team: a team of peers differs from a team of new graduates. Lee says a manager's input helps here. A manager can point out that a 4 percent performance gain is good, but that no one knows which tools were used and nothing would be committed if the person were unavailable. In Lee's view how you do the work matters as much as what you do, and pairing with junior engineers helps them follow the threads.

Carly gives a manager's view, using Zach as an example. Carly would rather Zach had input into research, design and the roadmap of the big projects, so that someone with Zach's depth can quickly say what will break, and others do the deep implementation. Zach would step in when something is very complicated. Carly says the balance is hard to get right and is something to settle in talks with the manager.

Lee builds on this: one of the most powerful tools is asking the right question at the right time. A senior person who hears a team plan to re-architect something can say it is not the right focus and that it can sit behind a shim for now. Twenty minutes of that person's time can save two or three developer-years. Lee says that people's time should go where a design matters, because a missed hallway conversation can be costly.

QWhere does a staff engineer find, or make up, the scope?

Lee says that as you become better than your managers at your job, they can no longer see the landmines or the technical constraints on a project. Lee rejects the idea of making up scope to justify a promotion as a bad choice. The job is to identify what is hurting the team and holding it back, raise it, and convince others to fix it. Lee compares this to the question of whether calculus was invented or discovered. Lee says most scope is discovered: work that others fear, do not see, or do not think is valuable, and that you must persuade them will speed up the next three projects or enable something the product could not do before. It may be found by looking through code, or in product requirements where there is a gap.

Lee's own habit is to put a hand up when no one else will. Lee gives the example of an old, fragile system that no one wants to touch. Lee says that when someone suggests turning it off, it may turn out to generate hundreds of millions of dollars in revenue, so it is worth a gradual replacement such as the strangler fig pattern. Lee admits that this sometimes leaves a person stuck with something awful.

Rahul sums up that asking how to find scope to justify a promotion is already the wrong question. The right one is what the most burning problems are, and what is on the mind of the manager, director and other engineers, and whether you can build something that helps them. Rahul compares it to a startup: you start with the problem, not a solution. Knowing those problems takes relationship building and being embedded in the organization.

QHow deliberate were you about building relationships with mentees, tech leads, managers and directors who might speak for you at review time? (Rahul)

Carly calls it extremely intentional. Carly looks for people with a common problem or approach and teams up with them. Carly now has friends across business units, including people Carly seldom works with. Carly says that being remote full time makes this much harder than working in an office. Carly describes being an introverted extrovert and says people have to push against the urge not to message others, because no one will argue for you if no one knows you. Carly adds that someone working late and shown as online will not be noticed for that. People vouch for those they have seen deliver on time, on scope and on budget, and waiting to be rescued is the wrong approach.

Another panelist says that they were poor at happy hours, but their work was highly visible and they were promoted even during the pandemic. The key for them was to communicate the work: share the plan, get buy-in, and report the results. Writing and communication are strong tools, because in practice work does not market itself. A manager can be a cheerleader for only so long.

Lee says that being known was the difference between being stuck at L5 and being the person who pulled together Android engineers across Amazon, with data on when apps would run out of methods. People then send others to that person, and the person can point to the next step even when they lack the answer. Lee says human relationships are all there is. Lee worked remotely at Meta, never visited, and did not succeed. Lee had decent relationships but not the visibility, and so lacked help once things went wrong. Lee began asking one off-topic question a day on an Amazon team during the pandemic. Lee now does so in the chat rooms of two organizations at Google, and says people recognize Lee as the question person, which makes it easy to ask a product manager for help. Lee also suggests asking a manager whether anyone on the team needs a mentor, since even a no changes how they think of you, and sitting in on a product managers' event to understand their process and offer a developer's view. Lee says it may sound like politics, and sometimes it is, but it is part of the job. Lee, who describes being autistic with many social challenges, says Lee still has to do this to succeed.

Rahul offers a litmus test. If you asked a teammate what a person is known for, would they answer cohesively, such as saying that person is the expert on a system? If not, that is a bad sign.

QWhat heuristics improve the chance of promotion to staff, for example the choice of team, its size, or infrastructure versus product work? (Rahul)

One panelist advises talking to someone above staff, such as a senior staff or principal engineer, asking what they would fix if they had the time, and doing that. A principal who supports your document goes a long way. The same panelist says to write the promotion document now, not when it feels ready. Show it to the people who review promotions and ask why they would reject it, then work on those gaps. Otherwise a promotion project might turn out not to be the right one, and that is the candidate's own fault. If the feedback is that you have never led anyone, the next project needs to show leadership rather than more code. Not understanding the process, the panelist says, leaves the outcome to luck.

Another panelist says they favor work on churn and finance-related problems at each company, because that is where the pain in the business is.

Zach puts the relationship with your manager first: without it, even a star will struggle. For data engineers, Zach says the data sets must be ones many other pipelines read from, such as master data. A data set made only for a visualization is not staff-level. A staff analytics engineer may instead own the whole chain from logging to data set to visualization and perhaps a model.

Another panelist describes three common rubric dimensions. One is the size of the work stream, such as the number of engineers and the duration. A second is complexity: could someone a level below solve it, or does it need domain knowledge such as distributed systems or AI? The third is impact: does it span several teams or reach significant business goals? This panelist says leverage comes from building things that other engineers build on, which biases toward infrastructure and tooling teams. Leading a very large product initiative is limited to a few places, and someone must grant permission, so those chances are fewer and harder to compete for.

QAudience question: once you are at staff level, how do you keep exceeding expectations?

One panelist says behaviors at staff and above are similar: influencing through others, growing people around you, and taking on the largest problems. What changes is that the initiatives are a step bigger. To exceed, find something larger in scope, such as influencing two larger organizations instead of one group of about 50, or building infrastructure for hundreds of engineers instead of dozens.

Zach, who says they received an exceeds rating at staff level at Airbnb for 2020, describes two parts. One was delivering the main "big rock" project, which for Zach was refining pricing and availability metrics. The other was design work on longer-term questions, such as a document on best practices for moving data from the data lake back into the Airbnb app, with feedback from principal engineers on edge cases. Zach says that missing the first means not meeting expectations at all, and doing both is what moves a person toward the senior staff level.

QAudience question (Alan): what resources help with technical communication and finding mentorship?

Rahul says the core skill is knowing your audience. At Meta, Rahul checked who belonged to an internal Workplace group before posting an update: engineers, leadership, or a cross-functional mix. Rahul then adjusted the depth, avoiding both too much detail and too little. Before a stand-up or meeting, find out who will be there and how much they know and care. Rahul has no book or video to suggest, and says the way to build empathy for different audiences is relationship building, which gives a sense of the personas you address.

Zach adds that posting on LinkedIn almost every day while at Airbnb taught Zach to say dense information concisely, because the platform rewards short posts. Zach recommends that skill for growth.

QAudience question (sesh): should a senior engineer become a tech lead first on the way to staff?

Ryan Peterman sees tech lead as a set of behaviors that can occur at any level, not as a level between senior and staff. Senior engineers on some teams lead smaller projects. Ryan suggests checking the company's own leveling system.

Another panelist cautions that if the missing pieces are leadership and visibility, being a tech lead may give more chances to practice them. But it is not necessarily a stepping stone, and doing the behaviors well does not guarantee a path to staff. A further panelist says the expected behaviors at each level should be written down at the company. Use that with your manager to see where you exceed and where you fall short, and ask for the documentation if you do not have it, because otherwise you can only guess.

QAudience question (Sam): how can a data engineer show backend work to a manager who is not their day-to-day lead?

Zach says that if there is no shiny front-end piece, part of the answer is to work with the data scientist or analyst who builds the visualization on top of your data. The other part is to show downstream impact. Zach says a data set can be sold as improving one of three kinds of decision: an executive's strategic decision, a data scientist's or analyst's product decision, or a machine-learning algorithm's automated decision. Zach's pricing and availability data sets at Airbnb fed Smart Pricing, an algorithm that sets prices for listings, which had a large effect on the business.

Zach adds that data engineers can also cite optimization numbers, such as a pipeline running 30 or 40 percent faster. At Airbnb, Zach cut the size of the pricing and availability data sets by 90 percent, so the company could use data 10 times smaller. Zach admits that data engineering can fall into the shadows because it lacks the show-it-off quality of a front end or a SQL query. Where the gain is only visibility, Zach suggests building a story around it.

QHow do you tell which problems are worth solving, when a staff promotion needs enough scope?

Zach describes a move at Netflix from an automated threat-detection project, which looked too ambitious, to a shared graph database that other teams could use in many cases. The shift brought more pay, more respect, and a larger leadership role.

Zach adds that scope is not the only test. Risky projects that may never pan out also waste time. Senior engineers can judge how much impact a project will have before investing in it, so a small request to them may sit in a backlog.

QFor Carly and Lee: how explicit should someone be about wanting to reach staff, and how much should they tell a manager?

Carly manages staff engineers and says people raise promotion in different ways. In Carly's experience, about half of the requests to move to staff came from people who were not yet ready. The other half came from people who were ready long before they asked. Carly sees two groups: people who ask readily, sometimes before they are ready, and people who wait until readiness is proved, often a year past it.

Carly suggests reflecting honestly on readiness without setting the bar so high that a reserved person holds back.

Lee says promotions often trail performance at large tech companies, so a person who never raises the question may not know what is missing. Lee suggests stating the goal directly: a wish to grow on the technical track rather than into management. Ask what is missing, build a plan, and write down the evidence, so the manager has the material when the person is ready. Lee notes that not everyone wants a promotion, and some people prefer their current level.

QDoes a high performer have leverage with a manager?

A panelist says strong performers have leverage inside a company, because a manager wants to keep someone who solves the team's problems. Asking for growth from that position is more likely to get a receptive response than asking from a less central role.

The same panelist names the limits. A manager cannot promote someone on request, because processes and other decision-makers are involved. A manager can still steer projects toward the gaps named in a promotion plan. If the current team cannot offer that work, the honest options are to move to another team or look outside.

QHow much control does a manager have over promotion at each level?

Zach says that at Airbnb, managers decided promotions up to senior, while promotion from senior to staff and above went through a committee. Zach describes Amazon before it used committees for promotion, where decisions moved up the management chain through skip-level managers and directors above the senior level, not only the direct manager.

QHow should someone judge which team is the best place to earn a staff promotion?

A panelist offers a rough test. At a company with many products, a team that works on the core product usually has more visibility than a team on a side product. The panelist jokes that working on a smaller app such as Garage Band is unlikely to lead to a promotion, while the flagship product gives visibility almost for free.

Another panelist says a team with less visibility can still make progress. Find the team that owns a weak spot, show them the problem in their code, and offer to help or pair with them. Fixing a real problem with that team makes a person a strong partner, which is different from a small cosmetic change.

A third panelist says caring about the work matters as much as its impact. During a Google interview, that panelist was offered an ads role and said it did not interest them. Work a person cares about gets their best effort, and that makes it easier to advocate for the product to others.

QDo product or infrastructure teams offer a clearer route to staff?

Ryan says staff-level opportunities are more common on infrastructure teams. Ryan's view is that product engineers usually reach high impact past senior by leading large projects, and there are few such seats. Infrastructure work has leverage built in, because foundational technology helps many teams move faster, which creates more roles. Ryan says Ryan's own infrastructure team is quite senior compared with others.

QHow do remote or hybrid engineers compete with colleagues who sit close to the manager?

A panelist says the main answer is documentation, communication, and proof. Written evidence of impact lets the manager and others see the work without relying on physical proximity. The panelist has worked only in fully remote settings, so the hybrid case is an extrapolation.

QDid staff promotion require unusually long hours?

Panelists give mixed accounts. One says the project that led to promotion took more than 40 hours a week. Zach recalls about 50 to 55 hours, including the Netflix graph-database build. Another panelist says 50 to 60 hours was common but still left time for sleep. A further panelist notes that some people are promoted while working 40 hours.

Panelists who moved into management say hours mattered less. One says that as a manager, the panelist did not exceed 40 hours a week, and that multiplying other people's output shows impact in fewer hours than personal delivery. Another plans by goal rather than hours, working around 60 hours one week and around 30 the next.

QDo inflated startup titles lead to down-leveling at big tech?

A panelist says down-leveling happens when a candidate does not meet the level the company expects. The panelist does not think it can be avoided, except by being stronger or interviewing better. Startup titles are often inflated, so the panelist advises comparing the scope of the work with what each company expects at each level, rather than targeting a title.

Another panelist says title matters less than pay and meaningful work. That panelist moved from a mid-level role at a startup to a junior role at Facebook, for about an 80 percent pay increase, and calls that a good trade.

QSeniority opens doors, but bigger projects tend to come after promotion. How do you break that cycle?

A panelist says seniority helps but matters less than internal brand. The person a manager or director thinks of first for a hard problem usually gets the work, and level often tracks that trust. Being known as someone who gets things done brings opportunities even without a senior title.

Another panelist says title is one way through the door, not the only way. A person can be trusted with larger scope than their title suggests if a manager or senior sponsor vouches for them, and their own actions build that trust. A director-level sponsor can push for the scope, but the person still has to go find it.

QHow do you get visibility without feeling that you are self-promoting?

A panelist says visibility is necessary to move up, even when it feels awkward or the person is reserved. Visibility does not mean posting about every win. It can come from giving tech talks after a major launch, running a talk series that brings others in, or answering questions on an internal forum. The key is that the people who speak for you know what you do.

Another panelist adds that an internal brand comes from being approachable and helping teammates get unblocked. A promotion case usually needs peer feedback from three or four co-workers who can vouch for the person. Reaching across disciplines, such as product managers and data scientists, strengthens that case, because a person who wins over only one group is still not moving up.

QWhat was the main reason to seek promotion: money, title, or work-life balance?

One panelist says the main reason was the kind of work. Senior and principal engineers at Amazon were doing influence-heavy work, such as mentoring people, helping engineers grow, and shaping decisions above their own team. The panelist wanted that work. Pay was welcome, but it was not the main draw.

QHow many people does a staff engineer typically affect?

A panelist thinks about the number of people affected rather than team size. A senior engineer should affect at least their own team and the scope of the senior manager above them. The panel's rough estimates are about 20 to 30 engineers at senior, up to 50 to 60 at staff, and into the hundreds at principal, which can mean a VP's organization.

Another panelist recalls an Airbnb marketplace organization of about 75 engineers, with around five staff engineers within it.

QHow does office politics affect advancement, and what should people do about it?

A panelist says politics is mostly about people. Some colleagues are difficult, and some use relationships to get ahead in harmful ways. The panelist does not expect a person to change or remove those colleagues, so the better move is to raise your own standing. If the environment is truly toxic, the right answer may be a different place.

The same panelist adds that when people talk about politics, they often mean difficulty communicating with executives or with another team. That gap can be fixed, and fixing it is part of the job.

QYou did not have a grand plan to manage all of Uber's stateful workloads, so how did you convince people to start running databases in Docker?

Recht credits the freedom of early Uber, which also came with a cost: at one point someone counted around 52 different database technologies in use. Because few people had to approve it, adopting the approach for Recht's own team was easy. The harder part came when the team realised it should be done for everything.

Recht says they deliberately did not try to convince everyone at once. They would start with what the Denmark office owned, then move to teams owned by friends in other departments, then to increasingly resistant groups. They also knew the platform would not be ready on day one anyway. Recht prefers not to force anything on anybody, and would rather build something, make sure it works, and let sceptics see it running elsewhere. Recht says this incremental approach helped a lot and also took a very long time.

QWas this a bottom-up effort, and when did leadership get involved?

Recht says the effort could only go so far from below. Uber's stateful side was split in two: the online databases (MySQL, Postgres, Cassandra and similar) and the data stack (HDFS, Kafka, Pinot and similar), which sat in a completely different org whose management chains met only at the CEO. The data-stack side initially said the idea sounded nice but they did not care.

Over time more support built up the management chain, and eventually leadership declared Odin the future and said teams would no longer be allowed to run their own servers. Recht says the mandate helped adoption, because stragglers always exist however good the product is, and full alignment is hard to reach alone.

QFor people interested in the career side, how did your career grow at each step of this?

Recht describes a self-admittedly naive hope that promotion is not always fair, but pretty fair, and tied to the scope of the work and the number of people affected by it, not through direct authority. Odin followed a natural expansion: first inside the team, then the local org, then the wider platform, then beyond. Running a project of that scope to success, Recht says, produces a series of promotions that happen almost automatically, and it drags the whole team along.

Recht acknowledges some luck: one project lasted a very long time, whereas many people are shuffled around or see projects cancelled, which makes it harder, though not impossible, to show expanding scope. Recht's promotions tracked the work. Background work came first, then the first version of the platform, which Recht thinks earned a promotion. Expansion to standard MySQL and Cassandra then led, Recht believes, to principal engineer (title names changed along the way). Handing the project to the team so Recht could do other things led to distinguished. Recht says that progression was never the reason for doing the work.

QYou said promotions are typically fair, based on the impact of the work. What does it mean when you say they are sometimes not?

Recht has sat on promotion committees for a long time and says the format changed a great deal. The first one covered all of platform engineering. Managers, VPs, senior directors and senior engineers sat in a room for a day to go through every engineer, with Recht guessing the number was somewhere in the hundreds, with no preparation or written material. Each manager said how good each person was and, unsurprisingly, thought everyone should be promoted, so a point system was improvised. In that setup, Recht says, outcomes depended on how well the manager could present the case: a weak manager meant a weak case, though a good manager could also be attached to weak work. Recht links this unfairness partly to Uber's early culture problems.

Structure improved, but Recht says objective judgment is impossible. An engineer may depend on another team that never delivers, or a nearly finished project may be cancelled by management for reasons that are not the engineer's fault. A committee must then choose between promoting on code that nobody used and denying someone who did good work, trading fairness against motivation. Some engineers also feel treated unfairly because they excelled compared with a weak team, or lived on an island and had not realised other groups were much stronger. Recht recalls Uber moving from Python and JavaScript to Go when nobody knew Go, and committees judging some groups' output as simply not good enough.

Recht says that feels unfair to people who were not prepared for what they entered. That is why Recht wrote a guide to what it means to be a software engineer at Uber, which Recht expects differs from Meta or Google. The title, something like beating the promo committee, was just catchy. Recht regrets that people prepare packets and collect peer feedback without correction along the way, only to be turned down.

QCommon advice is to scale yourself by delegating and becoming a tech lead who stops writing code. What is your view?

Recht does not subscribe to that idea at all, and sees it often. Part of it is taste: Recht has always liked writing code and says they would probably still do it without a job. But Recht also gives reasons. If an engineer stops writing code, the system keeps evolving and the engineer loses touch with it. Designs grow more idealistic and detached from reality, and when they are handed off, the implementers wonder who the person with the whiteboard and documents is, because the real problems are different.

Recht defines scaling oneself as enabling as many people as possible to work efficiently, not cloning oneself, which rarely works. That is easier when people trust you, know that you understand their pain points, know your suggestions usually work, and know you listen. As people rotate in and out, a leader who is not hands-on loses touch with both people and system. Recht says the result can be hostility, with people not saying so to the leader's face. Recht personally dislikes being told what to do by someone without skin in the game, while staying open to input, and promises to stay out of others' work in return.

QYou had to influence many people to scale your project across Uber. How do you influence other engineers and avoid that situation?

Recht says someone somewhere will never be convinced, and 100 percent is not the goal. Recht believes in leading by example: if you say what will be built, you help build it and take on much of the pain. The higher the level, the more one is told to concentrate on the hard things only the senior person can do, but Recht says there are very few of those. Recht argues that the person who had the idea tends to keep the interesting parts, such as new algorithms or the fun work, whereas most of the time the hard work should be delegated down, to people who can barely manage it, with support to keep them on track. The senior engineer keeps the boring work, since at that level there is nothing left to prove.

Recht says taking the grind earns a lot of credit and lets others grow much faster, because a challenged team works and grows faster. Leading by example mostly means writing code, plus improving documentation or fixing odd bugs, which usually brings little glory. Recht is a strong believer in it.

QAs you advanced, did your role become more political?

Recht first asks what political means, then describes what changed. There is more talking and more fighting, because one must promote ideas and, perhaps worse, listen to everyone else's. There is also more exposure to reality. As a junior engineer it seems someone has a grand plan and everything is under control. Later, Recht says, one realises nobody is in control, and decisions can rest on a vision from the shower or on a conversation with another person who does not know either, and that becomes the strategy. Recht finds this scary for a rational engineer, says it is not for everybody, and did not like it at all.

Recht's coping approach was to abstract from it and do their own thing. Recht has seen many people get sucked into weeks of planning. Because Recht does not need others to tell them how to do things, they do not tell others either. Recht was never a career planner and has a strong aversion to projects that look like dead ends, which Recht left to others, saying no a lot, perhaps too much in some people's view. That works only if one's own work is significant enough to fill one's scope. Recht also has low patience for talking about doing something for days and ending with a vague plan for next year.

QYou said the best outcome is when the other person thinks the idea is theirs. What do you mean?

Recht says it does not happen often, but those are the best days: overhearing someone argue with conviction, months later, an idea that Recht had put forward and that they had not liked, without crediting Recht. The Odin resistance is an example. A team that had to rebuild tooling it already had could initially see only the cost, and later came to see the benefits without being forced.

Recht may have nudged a few times, or the environment may have changed the person a little. Recht describes the feeling not as being proved right but as pride that those people are now on the right track, reached without force.

QYou reportedly pick mentees outside your own org and disperse them to increase your influence. How do you pick mentees?

Recht says mentoring sounds appealing but is very inefficient as a way to scale, because it is one person talking to one other person. Recht therefore aimed mainly at a network and at two-way conversations, in which the other person also shares something. Mentoring inside one's own team raises the question of who is actually learning what, and close-range advice can be given informally in group settings.

With people further away there is more work and also more benefit. Recht can learn what they do, give input on their work, and plant seeds. Recht has seen people who complained about getting bad projects start to think another way of working might be possible, which can rub off inside their teams and eventually the wider org. That is why Recht prefers mentees who are not very close.

QWhat was it like to experience Uber's cultural backlash around 2017?

Recht says Denmark and Silicon Valley differ a lot, and found the news bewildering, having assumed everyone was just coding and having fun. The distance was a help. With a nine-hour time difference the office's days stayed quiet and it could keep executing while people left or were fired and board members and the CEO were pushed out.

Recht's impression of Uber's culture was that performance reviews, promotions and even salary negotiation were all about the individual and not the team, which Recht finds baffling. The Denmark office never fully adopted that mindset, so for them the change was smaller. Recht cites scandals they could not understand, such as misuse of someone's private data and a board member's remark about women on the board during a company-wide livestream after a harassment scandal. Recht had mixed feelings, glad of the distance but sometimes watching with popcorn. On visits to US offices before 2017, Recht found it odd to be offered whiskey on a Tuesday afternoon.

QKnowing what you know now, what advice would you give yourself at the start of your career?

Recht says to try things and not be afraid because something looks hard or because others seem much better. They might be better, but one can get there; it is not rocket science, just computers, and anyone who likes computers is well off if they keep going. Recht advises letting curiosity lead, and not assuming that the current work is the best available, because something better probably exists or soon will. Do not discard it just because the present work is fun. Recht admits it is hard to tell what is better than what one has, so sometimes one simply has to take a chance.

QWhy are Waterloo’s co-op students so effective?

Grigorik credits alternating academic terms with work terms, rather than treating industry experience as an optional interruption after years of study. Roughly six placements offer repeated experiments with industry, company size, role, and working environment.

A short placement can disprove a preconceived preference without the resume stigma of repeatedly leaving permanent jobs. Someone who imagined Wall Street may discover the city, people, or work do not suit them. Repeated choices build a better model of personal fit.

The applied work also puts theoretical tools in context. An engineer must solve a real problem under constraints and recognize when a theoretically sophisticated optimization does not matter—for example, when the array has only ten items. He would like more universities to adopt that repeated learning loop.

QWhy found PostRank after graduation?

He initially planned graduate school partly because he did not know what to do. During the summer, he explored a product idea: links could signal useful content, but comments, likes, and other social interactions could add signals in the newer web. PostRank aggregated those interactions to rank posts.

His launch brought both demand and implementation problems. He recalls several sleepless days because the servers struggled, admitting that poor code contributed. Publicity led to investor conversations.

Facing the graduate-school start, he noticed that the courses most appealing to him concerned entrepreneurship. He could study those ideas academically or learn while already speaking with investors. He postponed the program, closed funding, and never returned to complete the degree. The choice was an experiment connected to a real opportunity, rather than a predetermined founder identity.

QHow did Google’s acquisition conversation begin?

After a conference presentation, a Google Analytics product leader approached the team and invited a conversation. The discussion was friendly and exploratory, beginning with understanding the product and asking whether they could work together. Grigorik later understood that Google’s response to Facebook and its social initiatives created demand for relevant talent and infrastructure. Analytics could use their experience to understand social engagement, making a mutually useful connection.

QWhat was your role in Google Analytics, and why leave a director trajectory?

He joined as an engineering manager because he had been founder and CTO. He remained committed to the original aim of helping publishers understand engagement and spent about a year rebuilding the stack. With the team on a sound trajectory, he considered another direction.

A VP offered a clear path toward director, but Google’s technical environment drew his curiosity. Internal documents showed work far ahead of published papers, and engineers sometimes lacked time rather than permission to share the advances. He became interested in contributing to a broader web ecosystem.

The Make the Web Fast group worked across cellular systems, protocols, proxies, and the fundamental question of measuring speed. Grigorik chose a lateral move into IC work even though he might be downleveled and reset the conventional management path. He valued more self-direction, fascinating problems, and collaborators he admired.

QWhy later return to management in developer relations?

He regards movement between IC and manager as an underappreciated pattern among senior engineers. A person may first discover a path alone, then realize that building the full solution requires a team. His analogy distinguishes cutting a trail from constructing a highway.

His performance work moved into browser standards and metrics. Once those metrics existed, the bottleneck became adoption across analytics vendors and open-source projects. One person could not do all that outreach. A developer-relations team could accelerate adoption that otherwise might take several years.

He therefore returned to recruiting and organizing people in service of the problem. The management move was a means of carrying work through a new stage, not a permanent declaration that people management was the only kind of growth.

QWhat does principal-to-distinguished growth at Shopify require?

He does not supply a checklist or name one promotion project. A principal engineer must identify useful work amid ambiguity. He expects someone entering an unfamiliar area to learn the landscape, build partnerships, understand leaders’ problems, and determine where their skills apply.

For distinguished work, he emphasizes a demonstrated range across technical layers and business requirements. Someone must understand low-level constraints, reconstruct the actual problem, and connect it to what product and business partners need.

The execution mode also changes with the situation. A frontier problem requires rapid experiments that reveal unknowns; a long-lived platform API requires slow consideration of consequences for the ecosystem. In either case, exploration must lead to a recommendation and useful execution. He compares the role’s ambiguity with a VP receiving difficult problems that lower layers could not solve.

QDoes a broad skill intersection make a generalist distinctive?

He agrees. A person with sufficient knowledge of several relevant areas can combine them for an unusual problem and change their contribution as circumstances change. Management experience is another available tool: even as an IC, he can coach, give feedback, and partner effectively with managers. His probability-language analogy expresses uniqueness; the interview does not establish an independence-based mathematical model for career success.

QWhat regrets should others learn from?

Do not let success raise the threshold for trying so high that it stops learning. His early writing and code now seem embarrassing, but publishing them generated feedback and encouragement that made improvement possible.

A larger audience creates an expectation of exceptional output. That can suppress ordinary observations and experiments that would once have been shared freely. He continues to struggle with that filter and encourages the courage to be mistaken or disliked without claiming to know everything.

QWhat author or book influenced your career?

He recommends Sir Ken Robinson’s books and talks about education, creativity, and finding one’s element. The philosophy resonates with the co-op discussion: allow people to discover their strengths and combine skills rather than fit a rigid age-based factory model. He recognizes that implementing such an education system is difficult; his endorsement concerns its direction rather than a ready-made policy.

QWhat would you tell yourself at the beginning?

Value the ability to combine skills rather than feel inferior because friends excel more deeply in individual areas. Early uncertainty about his own broad but uneven competence eventually gave way to recognizing its usefulness.

He would also be braver and filter himself less. Public speaking once terrified him; pitching a product he cared about felt entirely different from performing knowledge for a class. Passion changed how he engaged. He could not have predicted that communication would later become a large part of his job.

QWhat did you think when you reached distinguished engineer—did you want another promotion?

Early in his career, Su assumed that promotions would continue every few years and did not consider an eventual end. By level seven, he recognized that higher roles require more scope and that the business must actually need that scope. An organization might limit partner-level positions for budgetary and organizational reasons, irrespective of an individual’s ambition.

When Facebook first introduced level nine, the initial promotees seemed extraordinarily accomplished and universally recognized. He did not consider going further realistic. His recollection challenges the idea that every promotion simply starts another predictable step upward: roles narrow, opportunity matters, and people encounter limits.

QWhat kept you growing through staff and beyond?

For much of his Microsoft career, levels provided a substitute for the grades and tests he had enjoyed at school. Professional work offered few clear numerical indicators, so promotion felt like an achievement score. He actively pursued that score into his early thirties.

Beyond level seven, he became unsure whether he would enjoy the changing work or meet its expectations. His later promotions to eight and nine were consequences of work he found interesting, rather than explicit targets. Facebook was then small and mission-focused; he says he did not even know levels existed there until his manager told him he had been promoted.

QWhat changed your view of promotion?

The reward became less uncomplicated. A promotion brought expectations he was no longer certain he could fulfill. Staying at a level where he already enjoyed the work began to feel comfortable, and he recognized that it might be his final level.

He recalls immediately asking how to reach eight after a mentor promoted him to seven. The mentor asked whether they could spend one meeting celebrating. Years later, Su realized that this respected, more experienced mentor was himself at the same level. He now sees his earlier response as insufficiently humble: doing excellent work at an existing level is already a substantial accomplishment.

QBefore seeking a demotion, did you ever ask not to be promoted beyond IC7?

Not when moving from seven to eight: that promotion surprised him, and the smaller Facebook of that period still involved relatively little organizational overhead. Later, the Seattle office alone had grown from a handful of desks to more than two thousand people. Senior roles in a much larger organization contained more coordination and less direct technical work.

He distinguishes enjoyable people work—welcoming colleagues and creating collaborations—from politics, unhappy colleagues, and constructive feedback. He felt effective leading Facebook London but much less effective at some of the latter responsibilities. Even a senior IC without direct reports is expected to improve people around them, so opting out of management does not remove interpersonal demands.

QWhat changed that made the higher level harder to sustain?

His environment changed. In a small company, his generalist range was useful: for Facebook video calling, he wrote code, negotiated partner contracts, dealt with testing arrangements, and spoke to the press. A large company assigns those tasks to specialized functions. He thinks senior domain experts fit that setting better, while his own strengths became less relevant.

One later team spent an entire half fixing bugs in an internal tool. He was willing to help, but it was not work in which he felt especially distinguished. Meanwhile, he tired of the pressure to meet senior expectations. Earlier, being the weakest person on a team could feel exciting because he was catching up; later it felt like a recurring risk rather than a desirable challenge.

QWhat does Philip credit for the fast climb through Microsoft's ladder?

Philip names several causes. One was working with very good managers and teammates. The Microsoft tablet PC team had about 20 people, and three of them were distinguished engineers, which Philip calls very rare at Microsoft. Philip learned a great deal quickly from them.

Another cause was very long hours. In the first year Philip kept a sleeping bag in the office and often slept there. Philip set a 3 a.m. alarm to follow what Philip describes as Da Vinci's idea of sleeping in two four-hour blocks, coding between them.

Philip sums up fast growth as luck, talent and hard work. Luck means being in the right place at the right time, for example being at Stanford when Sergey and Larry were there. Talent matters because Philip rejects the idea that anyone can become anything: Philip will never be a great basketball player, and a weak public speaker can become passable but not a Cicero. Hard work matters because someone who outworks equally talented and equally lucky people will get further. Philip adds that Philip does not recommend this to everyone.

QWhy did Philip become a manager, and why did the role keep changing?

Philip says the promotion to the Microsoft equivalent of E7 came as a manager, after which Philip also worked as an individual contributor at that level. Early on Philip was very ambitious and came from a culture, as an ethnically Chinese person, in which managers were more respected and advanced further. Philip now calls the belief that management was the next growth step somewhat misguided.

Over a career Philip has moved between managing and individual contribution at least six times. Philip loves being an individual contributor but is often asked to manage, for example as a temporary manager.

QHow should someone decide between staying an individual contributor and becoming a manager?

Philip is open to new experiences and generally advocates trying management if you think you might like it or be good at it, with a few caveats.

The first caveat is not to walk through a one-way door by accident. Philip has gone back to being an individual contributor roughly six times, but says many people cannot. They become managers of managers, drift far from the code, and are then unwilling to take a lower-level job or unable to meet an individual contributor's expectations at their old level. Philip kept the door open both ways by diving into code even while managing teams.

The second caveat is that people tend to think only about themselves when they want to manage. Philip's test is that you are ready to lead when your team would have elected you: "Would you want to work for you?" If the answer is not a solid yes, there is something to improve. Philip notes that nobody can truly make you lead, because teams can slow-roll or sandbag work, so people have to want to work for you. Philip expects that once those improvements are made, people will ask you to manage.

QDid Philip lose progress by switching between the two tracks?

Philip says yes, intentionally and willingly. When Philip moved from site director of Facebook London to an individual contributor on Oculus, Philip was eventually releveled from E9 to E7. Philip bought into that and says it was necessary, because the skills shown as a site director differed from those needed to be a good coder on Oculus.

Many people cannot accept such a step, Philip says, either for ego reasons or because lifestyles grow to fill whatever compensation people earn. Those who will not change their lifestyle paint themselves into a corner with fewer and fewer jobs they can take.

Philip also says timing matters. One or two years into a career, a lateral move such as junior software developer to junior product manager is easy, and many people will coach you. Around the senior E5 range, moving from E5 software developer to E5 product manager is very difficult, unless the engineering work already involved product management. At more senior levels the skills converge again, so the shape is a diamond. An effective E8 individual contributor, in Philip's description, has a technical vision, understands infrastructure weak points, plans staged migrations, coaches well and understands business strategy. Philip concludes that the middle of a career is where changing tracks is hardest.

QHow did Philip handle the move down from E9 to E7?

Philip had worried about this when first promoted from E8 to E9 as London site director. Philip told the Facebook CTO of the day (captioned "Shrep") that, because Philip liked being an individual contributor, Philip doubted the performance level could be kept when moving back to coding. The CTO replied that they should worry when it happened and not withhold a promotion because of a possible future return to coding.

Back in code, Philip understood the E9 expectations were out of reach. Being moved back to E7, the level Philip joined at about eight years earlier, felt great. Philip says it is far better to perform well at a level than to barely tread water at one where you feel imposter syndrome and doubt you will stay qualified. Philip also did not want pay above what Philip deserved relative to teammates.

Philip says few people make so large a change, and it demands a particular ego. Philip went from running a site of perhaps 400 or 500 people to reporting to a manager who reported to a manager. Philip also had to avoid voicing opinions about running the site, and avoid using outsized influence from the past, so the new leaders could succeed.

QWhat do engineers at E7, E8 and E9 typically do?

Philip caveats that Philip's information is coarse and probably stale, since it comes from working at Meta starting about 15 years earlier. In general, levels reflect scope of influence: how big, long or valuable a project one can single-handedly guarantee. An intern might guarantee a small feature. A senior developer at E5 or E6 should deliver the work of about 10 to 15 people. At E7, Philip would expect regular influence over about 50 people, driving technical direction for a team that size, being consulted by product and engineering managers, and personally delivering about six months of work with no check-ins. A director might influence about a hundred people.

On the individual contributor side, Philip says large scope comes in different forms. Some people are narrow but deep in a way others cannot match, and four E6s cannot replace them. Others are broad generalists, especially valuable for new teams and startups, where three E6s cannot outperform one great generalist E8.

Philip stresses that the qualitative difference matters most and cannot be captured in an HR bullet list. People at those levels excel for different reasons, and someone more senior must judge them. When Philip was first promoted to E8, E9 did not exist. Philip says the company later had to invent such levels for individual contributors like John Carmack. Philip recalls, if memory serves, that when the first E9 promotions were discussed the company had several thousand people and was considering three engineers, each a different archetype. Philip compares this to becoming a professor, where there is no formula and it comes down to whether other E8s think you are an E8.

QWhat project or scope earned Philip the E9 promotion?

Philip brought 12 people to start the engineering portion of Meta's London office and, over roughly four or five years, grew it to about 400 or 500. A good level-six engineering manager could run 12 engineers, Philip says, but with each order of magnitude of growth the problems get harder and the solutions turn gray. The promotion rested on handling a wider variety of things and more strategic decisions.

One example: in one of Philip's last meetings as site lead, Philip argued to people in Menlo Park about how many interns to hire and how much headcount London should have that summer. The argument rested on math about expected H-1B volume 18 months ahead, for full-time offers moving to Menlo Park. Earlier, as an E8, Philip was the first of Meta's sites to look at the seniority pyramid and ask whether people were growing at a commensurate pace. Philip describes these as decisions that grow in scope, by breadth of people affected or by how far ahead one must think.

QWhat made the London site's engineering culture strong?

Philip names two helps. First, before London Philip had been the second person hired in Meta Seattle, the company's first office outside its Palo Alto headquarters, and saw it grow from four desks to 120, including mistakes in how it grew. Second, before starting London, Philip interviewed site directors from other companies. One was the former site director of Google London, David Singleton, whom Philip says later became Stripe's CTO.

Singleton told Philip that Google had experimented with landing teams, the group sent to bootstrap a site's culture, and concluded the team should commit for at least two years. Philip contrasts this with companies that send a team for three or six months and then leave the site on its own. Philip thinks that is a mistake, because culture is hard to hold while new people are about as numerous as those who have been around more than three months. The CTO wanted enough engineers for two full interview loops, about 10 to 12 people.

Philip interviewed nearly 50 volunteers from the company, plus some of their peers and their managers, to choose 12 who would carry the culture. Each was asked to bring a project to lead, and the group included exceptional individual contributors who were happy to do whatever the site needed. Philip says Philip was lucky in the choices and credits learning from people who had done it before.

QDoes Philip have favorite stories from working with Zuck and Bos?

Philip's first manager at Facebook was Bos, who later became CTO, and during the London years Philip's manager was the then-CTO captioned as "Shrep." Both gave great advice and guidance. Philip spoke one-on-one with Zuck only a few times, so Philip's insight is limited, but Philip says Zuck felt genuine in how he led.

What impressed Philip most about both Zuck and Bos was their willingness and ability to grow. Philip joined at 33, when the company's median age was 27, and was the oldest person in the Seattle office for the first seven months, so most of the people Philip worked for were younger. People who had worked with either for years could say exactly how they had grown. Philip saw both as open to coaching, probably seeking it, and making a deliberate effort to improve.

Philip's small example is Zuck's AMAs. Within about two years of Philip joining, Philip says, they had improved a lot. Philip is pretty sure someone coached Zuck on how to hold his head, because early on his natural pose had the head tilted slightly upward, and over the years he deliberately corrected it to face the crowd straight on.

QWhy did Philip buy the whole company coffee for a day?

The host remembers it as a day of free coffee for everyone and puts the cost at over $23,000. Philip did not state a figure in this answer. Philip says the idea began several years into the Facebook years. After the company moved to its Menlo Park campus, a coffee shop opened in Hacker Square, and one Christmas Philip bought everyone a coffee for a day. Philip found the joy infectious, and the chief executive of the coffee chain wrote to say its staff had never seen anything like it.

When Philip left, Philip wanted to give something back. Philip stresses luck. People forget, Philip says, that when Philip joined, the talk was that Friendster might return, that Google+ would roll over Facebook, and that Facebook would never make money on mobile. Philip had left Microsoft after 12 years, in which Philip says the stock rose about 15 percent, and had low expectations. The Facebook outcome was, in Philip's words, "a brick of money" that came from luck, not design. Philip says Philip gave all IPO proceeds to charity because they felt undeserved, citing luck in being born when an interest in computer science pays and in emigrating to America. Philip then coordinated with coffee shops at the major Facebook sites, around five, by calling the owners, and says it was fun and rewarding.

QHow did OpenAI compare with Facebook?

Philip first notes that the stages differ: Facebook had about 500 engineers when Philip joined and OpenAI about 120. With that caveat, Philip calls OpenAI the highest talent density of any group of engineers Philip has worked with. Moving from Microsoft to Facebook was a big jump in the average quality of colleagues, and Philip felt OpenAI was a notch above that.

QHow did Philip develop such strong writing?

Philip says Philip was a bad writer through college because Philip did not respect communication. Coming from a culture that prized getting A's, Philip viewed the hard sciences as real and history and English as a waste of time, with no right answers, and so did not invest in soft skills.

At Microsoft, in spare time, Philip reread classics hated in high school. Philip names Hemingway and The Great Gatsby, saw them differently as an older reader, and developed a love of language. Philip cites Virginia Woolf for the idea that to write well you need to read well, and names David Foster Wallace, Alice Munro's short stories and Pilgrim at Tinker Creek as writing that shows what language can do. Philip then came to see writing as a skill as valuable as a hard science skill, and started working at it.

Beyond reading well, Philip says, it takes a willingness to rewrite several times and to leave material on the cutting-room floor, and many of Philip's well-known posts were rewritten repeatedly. Philip also notes clever rhetorical moves in other people's Substacks and tries to remember them. Above all, Philip says, the change came from no longer disrespecting the skill and seeing it as essential even for scientists and technical people.

QHow did Philip win respect as a very young manager?

Philip says it was difficult, because Philip lacked humility and was overly ambitious. Philip says Philip would not have worked for Philip's own 24-year-old self. Philip became a manager because Philip was one of the team's strongest engineers, and the team figured it was better to keep a good engineer happy by letting Philip manage.

In that first year, at 24, Philip had to fire a 40-year-old. Philip calls it exceptionally difficult, made harder by awareness of how junior Philip was. Philip says the person deserved it for missing expectations but was two levels above Philip's own level, and Philip says Philip was too immature to know how to manage someone more experienced.

Philip says Philip was a pretty bad manager at first but obsessed with growth: Philip collected mentors, asked for feedback and read nonfiction about managing teams and hard conversations. Philip says Philip made huge mistakes even in the last year of managing. The biggest weakness Philip names is giving feedback. Philip pulls punches, hates confrontation and downplays how serious the feedback is, so people miss the point. Philip says Philip has gone from very bad to passable and does not expect to become excellent. A strength is motivating action, since Philip joins only teams Philip believes in, and Philip's passion and vision excite people.

QHow was Rahul leveled at Pinterest, and how did he choose a team?

Pinterest had just created a leveling system, borrowed from Google and Facebook. Rahul came in at L3, the entry level (L4 is mid-level and L5 senior). He moved away from recommendation systems and data engineering into mobile, which he calls a career reset. It meant a longer ramp-up and, later, a rejected promotion.

Pinterest let new hires choose a team through "base camp," a two-to-three-week version of Facebook's boot camp. Rahul decided against backend work. He wanted to be close to the product and able to build things end to end, including side projects, and liked the idea of an app in the Android store that his Android-using family could try. His startup had no mobile team, so he saw Pinterest as a chance to learn Android professionally with strong people and benefit twice, at work and on the side.

QHow did Rahul eventually get promoted after the failed promotion at Pinterest?

Rahul calls it a difficult journey. The first rejection came about a year after he joined. He thinks the feedback was fair: he had done Android professionally for only about nine months and had not shipped much. He tried again six months later and was rejected again, which he found truly demoralizing. He had arrived through an acqui-hire expecting to be among the best engineers, and two rejections for the same promotion were a real setback.

Pinterest had an appeal process, and Rahul worked with his manager to use it. The appeal succeeded. The anonymous committee had read one project in his packet, described as 16 months of work, as a lack of urgency. Rahul says that was not true. His manager clarified and advocated for him. His lesson is to be clear about what a document says, because readers may interpret it differently, and to have promotion and one-on-one documents reviewed by experienced people.

Ryan notes that a long project can instead signal larger scope. Rahul agrees that context decides: align with the manager on the narrative and collect feedback from tech leads, because 16 months can look impressive, or count against you if it was a minor experiment others expect to take three months. His conclusion is not to assume how others will judge you. Software engineering is a social endeavor, so learn your evaluators' view of your growth areas before a review.

QWhy did Rahul leave Pinterest for Meta in mid-2017?

Rahul gives three reasons: Meta was a much bigger company with a stronger engineering brand, it paid more, and he did not see a clear path to rapid growth at Pinterest. He wanted to see whether he could get a meaningful bump in level or compensation.

He thinks job hopping works better early in a career than later. As people move up, he says, impact comes mostly through influence. A staff or principal engineer rarely writes enough code to justify the role; they build frameworks, tools and systems that make other developers productive, which takes years of relationships and trust. Early on, showing you can write high-quality production code may be enough to be hired higher.

Ryan's experience matches. Ryan's move from senior to staff was unusually quick because of long relationships on one team, while peers who switched companies quickly had fewer such ties.

QWhat cultural and technical differences did Rahul notice between Pinterest and Meta?

Culturally, Rahul found them similar, since Pinterest's culture was shaped by ex-Facebook and ex-Google people. He describes Facebook as the authentic version, "on steroids." At Pinterest, every change needed at least two reviewers, and Herald rules added blocking reviewers automatically. At Facebook one accept was usually enough to land code, which shocked him.

He also found people more direct at Facebook. At Pinterest, he says, a common criticism was that the company was too nice: people avoided hard feedback or prioritization, so projects and people who should not have stayed lingered. At Facebook people more readily said a project made no sense and should be cut, and he perceived a more aggressive performance-improvement-plan culture.

QWas Rahul hired at IC5, and did he have to do anything special for that jump?

Rahul was hired at IC5 (senior), so the move from Pinterest was effectively a promotion. He did nothing special, he says; the level was Meta's proposal after interviews in which he felt he had solved nearly every problem.

He also came from a position of strength: a couple of pending offers, a Facebook internship, time at a respectable company, and a hot market for Android developers, all of which made Meta want to give him a compelling offer.

QWhat work led to the promotion from senior to staff (IC6)?

Rahul worked on Portal. Facebook already had a mature cross-platform video-calling infrastructure inside Messenger. Portal's first step was to fork Messenger and go its own way as an experiment. Once Portal had hundreds of thousands of daily users, the team needed to return to the normal infrastructure, because the Messenger RTC team kept improving it. Rahul's main project was migrating Portal's core infrastructure back to Messenger's, keeping Portal's custom features and adopting the new capabilities RTC offered.

He calls it cross-functional work with a lot of bureaucracy, involving the Messenger team, Portal leadership and product managers. Some people can rely on one big project at staff level, he says, but a portfolio worked well for him. The second project was the debug tool, purely engineering-driven and built for himself and his teammates. Together, he says, the two made a clear promotion case.

QWhy did Rahul move from IC6 to tech lead manager (TLM)?

Rahul says his current company is about helping people, and he sees good managers as people with a real desire to help others grow. As a byproduct, he says, they can have large impact, since managers are usually senior and respected. He also had context and relationships, so the move felt natural: a growing team needed someone to give feedback and keep people on high-impact work, and he had already expressed interest.

QIn which period did Rahul feel the most skill or career growth?

Rahul names three. The first was meeting the mentor at Pinterest: pair programming, learning by osmosis, and discovering he was empowered to change his environment. The second was at Meta, leading the migration and building the debug tool, which was the first time in big tech he felt he created value, from an idea of his own that people chose to adopt. Before that he often felt like a worker bee carrying out work passed down from above. He says this helped give him the confidence to start a company.