Will Larson: The Revised Rules of Engineering Management

In a cold open, Will Larson names the worst lesson of 2010s engineering management: once you joined the ranks, you were told never to make a technical decision again. That is not the ethos today. He was just as frustrated by the idea that staff engineers principally got to work on interesting, personally rewarding problems. Some of his best engineers wanted the more interesting work. He told them he only had suffering to offer, and that suffering was what would make the business succeed.

People are asking whether middle management is a career trap. Larson calls it a hard time to be there. What he has found rewarding is getting back into the details of writing software—a rare moment to reskill. If you are in management right now, he thinks you either get back into the details or you do not.

Gergely Orosz introduces Larson as one of the best people to talk about how engineering management has changed. He has been an engineering executive for ten years across four companies, wrote some of the most widely read books on engineering leadership and staff-plus levels, and is, Orosz says, a deep and thoughtful thinker on the subject.

The episode covers how zero interest rates shaped a decade of management habits that are no longer helpful; why solving problems the business cares about matters more; and why line managers often make better engineering executives than middle managers. If you are an engineer or manager wondering what a career looks like with AI in the mix, and how the path to CTO works now, this is the conversation.

After a sponsor read, Orosz welcomes Larson. They have known each other for years as writers, and have hung out before, but this is the first time they are recording in person. Orosz wants to start at the beginning: how did Larson get interested in computers?

From age five they had a Mac IIci-class machine at home—not the very earliest, but basic. The one thing a four-and-a-half-year-old understood was Kid Pix, a children’s drawing program of squares, circles, and little graphics. There was no internet to speak of and no way to look anything up, so you banged on the machine until it worked. That, Larson says, is still the fundamental of writing software.

He was not doing much real software then beyond multi-user dungeons. Orosz has never played a MUD. Larson explains them as text-based games—the idea World of Warcraft later put graphics on. In high school the path ran through IRC, mIRC, and MUD clients with heavy regex triggers. That is where he learned regular expressions. He did not start writing software in earnest until college.

He arrived at college not knowing what to study—physics, English, or economics, the last because his father was an economics professor. He fell into computer science at a small private school in Kentucky. The entire program the year he graduated was about thirteen people; four graduated in his class. An intro CS course was a random graduation requirement, next to a history-of-Christianity course. He liked CS better.

Did he already plan to be a professional programmer? Larson’s point about careers is that elite-school paths are escalators. At Waterloo, students are coached into software jobs, trade interview answers, and have years of co-ops. MIT and Stanford work the same way: stay in the program and it carries you. Those students are excellent. It is still an escalator.

A school with four CS graduates a year had no such path. A talented person from the class above went to write horse-racing betting software in Lexington, Kentucky, at a company of maybe five engineers—because that is what they knew how to find. Larson was not sure what he would do. He taught English in Japan for a year on the JET Programme, in the middle of nowhere in Gifu Prefecture.

That is when he started writing a lot. He was sure he would not be an English teacher past the one-year contract, did the year, had no interest in a second, and came back trying to break into Silicon Valley from there. Orosz asks why Silicon Valley already, and what the Valley was like.

At first Larson did not even know what Silicon Valley was. He wanted a job that paid well. He graduated in 2007, taught English the next year, and started at Yahoo around early 2009. He began as a remote contractor on the East Coast because he had written a series of blog posts about Yahoo BOSS—Build Your Own Search Service—a product that was not getting much industry traction.

When BOSS launched he was writing a lot: three or four tutorials on using it from Python and Django, including a search library that may have been named Django Springsteen. Yahoo got excited that someone was writing about it. That became the contract. After a year as a contractor you had to go full-time, and full-time meant moving.

The reason he was a contractor at all was a year-long hiring freeze after the financial crisis. Yahoo was going through layoff after layoff: it could hire a couple of contractors, not full-time employees. At twelve months, compliance said convert or you are gone. If you converted, you moved. So he had a Yahoo job if he moved to California, and no job if he did not. He had few obligations besides employment, so he moved.

Orosz notes that Yahoo’s star was fading against Google, but it was still a strong company with real talent—the WhatsApp founders famously came from there. Larson thinks Yahoo is an interesting company to understand. If you entered tech in 2007 or 2008, open source had already made a lot of things easy. Yahoo predated those libraries.

How did you run a server at Yahoo in 2007? You ran YApache, their fork of Apache. On it you ran YPHP, their fork of PHP. The UI library was YUI. Installation was Yinst, a Perl script that walked dependencies, the way apt would elsewhere. It was a fast-moving place, but they had made every layer from scratch. They even had a Kafka precursor, something like YRepl, a read-log replication tool outside the database that was core to managing state.

His favorite Yahoo story: David Filo, one of the founders, famously approved every server allocated in the company. The theory was accountability—you had to prove you needed more machines. What it created was a black market. On Larson’s team, one engineer had thirty servers left from a canceled project and would effectively sell them for favors and IOUs if you could not get approval.

The result was masses of outdated, power-hungry servers that nobody ever gave back. To launch a project you had to find someone who liked you and had spare machines. It was a vivid lesson in how incentives drive wild situations. Orosz figures Larson remembered it as a later engineering leader. Larson wonders whether Filo knew about the black market. He assumes he did. The top-down mandate did not change.

After Yahoo he went to Digg, then a famous startup with an even more famous later story. Depending on who you ask, the narrative differs, but Larson’s version is that Digg was the big community site before Reddit. Reddit had subcommunities that voted with an algorithm. Digg’s front page was centrally curated: consistent quality, less of a subreddit-bias problem, and a central-moderation problem instead.

There were IRC channels where people traded favors to get stories onto the Digg front page. When Digg v4 changed the algorithm, people told him they would murder him for stealing their livelihood—their business was selling access to that page. The new algorithm did not support it, and they were literally threatening lives. Digg still mattered. At one point it was a top-ten website.

When he joined Yahoo, that era of the web was already fading, but a little earlier even Yahoo Sports on the Yahoo front page had been a static file on a NetScaler. Digg started as that kind of important static page and became a dynamic community. It has been restarted a few times since and never recovered the traction. Orosz remembers it as top ten, which is why the rewrite story stuck.

From the outside, Digg was still popular, with complaints a bit like Stack Overflow years later. Then it did a massive rewrite, disaster followed, and it became a juicy story: the community was upset, and there was a bit of celebration that Digg had messed it up and deserved it. Orosz wants the inside view, because Larson was building it.

Larson was there for the launch and after it. He joined about three to six months before v4 went out. The Friday before he started, the CEO was removed and Kevin Rose, the founding CEO, came back. They had a hard deadline to launch Digg v4, a rewrite. Digg 3.5 had been PHP on distributed MySQL, running on hardware they owned in a colo—not something you could just spin up.

V4 was trying to solve several problems, but first the internet was changing. A former top-ten site was losing traction to Facebook and losing search traffic. Google algorithm changes—Panda and others—were reshaping how traffic flowed. For Digg, Larson wants to say 60 to 70 percent of traffic came in via search onto permalink pages.

A permalink was Digg’s copy of someone else’s great blog post, plus a small link to the original and comments. Those pages often outranked the source. You can argue they should not have; that would be today’s view. At the time, Digg was creating the discoverability and the conversation, before Twitter and before Facebook had substantial distribution. It was also where they sold the most ads. Losing that traffic was tanking the company’s finances.

From the outside Digg looked like it was working, maybe even growing. Inside they knew it was shrinking. They had one beautiful month of profitability, then an algorithm change hit. It was existential. When he joined they were about 110 or 120 people. This was 2010, when funding rounds were a million or three million dollars, not $500 million. Even 110 people was substantial, and they were running down the remaining coffers fast.

Did the launch go poorly inside? From outside the perception was that it went terribly, the community hated the change, and people who were very involved did not like being disrupted. Larson points to an intricate four- or five-part Digg-versus-Reddit comic someone made at the time, blue versus red, a giant war. There was a lot of passion. That is the challenge of a passionate community: you foster it, then you change what you are, and the community does not like it.

Power users like Mr. Baby Man, unsolicited curators of what reached the front page, lost their business. The launch went poorly for many reasons. First, it was not technically ready. They made aggressive technology decisions. Larson had arrived about three months earlier, so he does not take much responsibility—it was his second job, after two years at Yahoo. Later in his career he will own anything that happens. This one, he says, was not really his fault.

They launched on Cassandra. The joke at the time was that Cassandra was a Trojan horse to ruin industry competition, because anyone who launched on it was screwed afterward. For Digg, Larson thinks that was true. Cassandra replaced a complicated but working sharded MySQL system. He would argue Cassandra basically did not work. A team was supposed to load-test it before launch. Two days before, he and another engineer, Rich, were pulled aside: the load testing had never been done.

Rich was a software engineer like him. They installed JMeter and tried to figure it out. They had a conversation with Chris, who headed the Cassandra initiative. Larson said he could not do the reads. Chris said that was not true. He said he could not do the writes. Also not true. Then: if he was writing, he could not read; if he was reading, he could not write. That, Chris agreed, was true. They were supposed to launch in two days. They launched anyway, without fixing it.

The company thought they were dying. The company was dying: it was running out of money. It was the most interesting day of Larson’s professional life. He probably got in around 8 a.m. Orosz asks whether interesting means stressful. Larson asks him to judge. They decided to have a launch party the same day. Caterers in tuxedos walked around with sushi trays and champagne. The entire office was there to celebrate.

In the center of the room they pulled out a giant table, maybe three or four times the size of the one they are sitting at, where the engineers sat. They did not have enough hardware to run the new system and the old one concurrently, and it was hardware they owned, so they were wiping old servers and installing the new software. They could not roll back. They had budget for the party, not enough for extra servers.

They wiped server by server, spun each up, and the thing functionally did not turn on. They had a down-for-maintenance page up for roughly 24 hours. Champagne and tuxedos kept coming around. There were people upstairs getting massages. Certain groups, unnamed, played ping pong while they tried to bring the site up. Larson calls it magical realism: normalcy while the site imploded. Orosz says this is not how he imagined a launch. Larson says you could never imagine a launch like this.

It is also a moment he takes a lot of pride in. He had been there three months. They did get the site working, but there were many issues, and people just gave up. Day by day they stopped showing up. A small group of maybe six was left trying to keep it up. In the first two days, the same Rich and Larson wrote a caching system from scratch on Redis that helped the site stay on for hours. They still had huge memory leaks, restarting every process every hour or two. Rolling restarts were the only way to keep it up.

It took a full month to debug. Larson later wrote a blog post about it. The core bug was a Python API service for third parties, written by people who did not know Python well, calling another Python gRPC layer that hit Cassandra. At the time, a mutable default parameter in Python persisted in memory: if you used a list as a default and appended IDs into it, every later call still had every user ID that had ever been passed in. Memory ballooned until they restarted.

They put Memcached in between; Memcached would fall over and take Cassandra with it. Finding the bug took about four weeks. Once found, it was trivial to fix. They got the site up. A new CEO started essentially the same day Larson fixed it. Then the entire company was laid off over the next year. A Pyrrhic victory: it worked, but you cannot have a central site hard to use or down for a month. The counterfactual is that keeping the old site would also have killed them. He does not know they made the wrong choice. At the time he was pretty salty about it.

Orosz asks how Larson got into engineering leadership. They overlapped a little at Uber but never worked together. The end of the Digg story was an acquisition in three pieces. Digg had patented in-stream ad units—the kind of native-looking ads you now see on X—and a broader portfolio. One company bought the patents. BetaWorks in New York bought the digg.com brand, later sold again. The team went to Social Code, a Washington Post Company subsidiary, alongside the Post and Kaplan, that did advertising on Facebook.

He stayed a couple of years. When he left he wanted engineering leadership, but he could not get hired into a large role: he was managing maybe twelve engineers, and nobody would hire him for a big job he had not already done. A fifteen-person startup’s head of engineering still only has five engineers. The scale is not there. His thinking at the time—it has changed a lot since—was that if he wanted a large team he had to join a company growing really quickly. Looking around, that was Uber.

Orosz dates it to 2015 or 2016. Larson says 2014, when growth was just kicking off and still early. You had to be in San Francisco to know Uber was doing that well; the news spread in 2015 and was global by 2016. Larson knew because Jeremy Grosser, an infrastructure engineer from Digg, had left and joined Uber. Digg had built tools that almost nobody else used. One, Clustered, was a key-value store for infrastructure state, a bit like HashiCorp Consul years before Consul. Larson thinks only Digg, Uber, and Second Life ever adopted it.

Grosser had brought a lot of the Digg stack into Uber as one of the first infrastructure engineers. His team was hiring. Larson had been a generalist: hired at Yahoo to do front-end, which he is not sure he was qualified for, then at Digg doing front-end, Cassandra, backend, everything. Uber hired him to run an “SRE” team that was really just infrastructure they called SRE. He read a DevOps book the week before—maybe The Phoenix Project—trying to figure out what the job was. Orosz guesses the Google SRE book; Larson does not think that one existed yet.

The interview was classic: the traveling-salesman problem on a whiteboard in Python, which did not evaluate DevOps acumen. The company was a little desperate on hiring. He got the job. When he joined he was managing about six people with an incredibly broad scope. Uber was 2,000 people and 200 engineers. That team of six managed databases, Kafka, and the servers once they were racked—tech ops racked and installed them—plus service provisioning. There was a two-person developer-experience team. They owned everything else in infrastructure.

Orosz wants the leadership path: how far did the Uber team grow, then Stripe, Carta, Calm. The team was five or six when he joined. When he left two years later it was 70, all external hiring. Uber doubled headcount every six months. You could not steal people from other teams; those teams were hiring too and also underwater. He learned how to hire at Uber. He had no idea how before.

One favorite: they gave an Eventbrite engineer an offer at 4:30 p.m. on a Friday, and he started Monday at 8:00. Less funny: someone interviewed with Uber four times, got rejected four times, and Larson saw him interviewing a fifth. He said they could not hire this person and should stop wasting his time. That team made an offer. The candidate joined, quit within six hours, and took Twitter, a block away. He spent more time interviewing at Uber than working there.

Scope increased a lot in those two years. Some companies today remind him of that Uber. When he joined, every Friday they were manually reallocating software between servers to keep the fleet up, because Friday rush hour was the weekly peak. Saturday might have more volume, spread over more hours, because people were not all leaving work at once. It was a manic place. He was there a couple of years.

Then Stripe, about four years, 2016 through early 2020. Then Calm, his first CTO job, about three and a half years—a deliberate move. Stripe had done well: he joined at a $5.5 billion valuation and it was around $96 billion four years later. The work was going well. Someone who joined the day he did was around employee 500; by the time he left the company was 1,500 to 2,000 people. Stripe grew about 70 percent year over year while he was there, a lot less than Uber doubling every six months. Uber later contracted much more aggressively, the natural consequence of that pace.

He was worried his entire savings sat in one company that was never going to go public, which he thinks has been true, so it was partly diversification. It was also wanting to know what it felt like to fully lead. At Stripe he was always one step from the CEO: reporting to his first manager for a year, then to David Singleton, who joined as head of engineering and later became CTO, through early 2020. He wanted that seat, and whether he could do things better. It has been educational ever since.

Then several CTO jobs: Calm three and a half years, Carta two years, Imprint a year or a year and a half ago, where he is today. Orosz, hearing three times CTO, wants the mental model: as an engineer you imagine the job has some management but that CTOs stay technical and close to the work. How was it, and how is it now, especially with AI?

One of the worst parts of being an engineering manager in the 2010s, Larson says, was the first lesson: never make a technical decision again. Let go of technology decisions. That was the ethos then. It is definitely not the ethos today. What he loved aspirationally is that CTO was the one place where the technically oriented career and the managerial one converged.

He has believed in, and still does, having both engineering managers and individual-contributor engineers report directly to him as CTO. Today he has fourteen direct reports; four or five are ICs, the rest managers. For a long time, many management roles simply did not let you be a technical leader. Getting to the level where those paths converge again, and you are allowed to lead on technology and management, was a big part of the appeal.

There were also a lot of bad CTO decisions out in the world. He does not mean this as a reflection on the people he has named: David Singleton in particular was excellent, and decision quality at Stripe was generally high. You might disagree, but you could not say a call made literally no sense. Outside Stripe, he often saw decisions that did not make sense, and thought maybe he could do it better.

What he has loved in this most recent era is that you are not just allowed to be in the details again—you are required to be. That has been the most fun part of being back in software. He has done more than 500 pull requests in a year and a half at Imprint, all the way to production, substantially more than in his prior career combined. That is pretty cool, and fun. And he is doing it as CTO.

Orosz asks if he is more than CTO at Imprint. He joined as CTO and is also leading product and design. Product, design, and engineering report into one person: a unified EPD structure. Orosz has been hearing CTPO—chief technology and product officer—for two or three years, and now design folding in as well. Is that a trend?

Larson does not know if it is a trend. One challenge with agents going mainstream is that you have to make decisions quickly: how you do things, how you do not, how agent adoption works for product and for design. If design is not using new tools—Flow, the Figma MCP, and so on—they become the bottleneck. Who owns design then? Imprint has been experimenting with developer-led design for second-tier features. It solved a bottleneck. It also created fights over who is responsible when engineers redesign and miss the design system.

A unified point that can make those trade-offs is powerful in a moment of immense change. In his core he believes the industry is changing more in how it creates software than at any point in his career, which started in late 2008. Earlier changes were more subtle, cultural or social. How he creates software is really different than a year ago. A centralized mechanism has helped. He does not personally think it is a long-term trend. He is trying to avoid deep future predictions. Everything is changing a lot.

After another pair of sponsor reads, Orosz wants to go back to how building software and leading teams changed, from around 2007 to today, in the Silicon Valley bubble that is still a useful one to talk about. Larson’s first job was as a 22-year-old remote contractor at Yahoo. Nobody else on the team was remote. When he went full-time he kept the same manager. In two years he had two one-on-ones with that manager.

Orosz had a similar experience: no real one-on-ones, or one a year for pay conversations. Promotions were “congratulations, you make more money now.” Larson had no expectation of more than two. The first was the manager fishing for signal on another employee’s performance, not feedback for him. The second was after he had given notice: what’s going on? That was normal.

The way that manager saw the job—and Larson thinks he was really good at it—was to go find an opportunity in the company for the team to have impact, bring it back, and let the team implement it. There was no idea that he was helping Larson have a rewarding career. That was irrelevant to him. This is pre-2010.

At Digg, Larson thinks all the managers basically got fired. He became a manager because he was the only one dumb enough not to say no. He had two and a half or three years of experience and knew nothing about management. At Yahoo he had barely interacted with his manager; a tech lead set direction and got upset if he screwed something up. That was the entire leadership model. At Digg there was really no management besides him in the last year, and he did not know what he was doing.

He learned a lot at Uber, but everyone was so busy there was no management there either. It was sink or swim. If you did not get decisions right, the scale of growth around you would crush your team. There was really no support. Orosz notes that by 2017, when he became a manager, Uber had put together its first apprentice-manager program: a few days together, mentors assigned. Most engineering managers never had that. Uber did it because bad managers were becoming a really big problem.

The Uber Larson worked in was extremely myopic. One unofficial value was solve it yourself: people did not get blocked on other teams, they just built it. Orosz recalls “let builders build,” “be an owner not a renter,” and a spirit of don’t ask for forgiveness, just get it done. Larson found the no-dependencies culture empowering. If you said you were blocked, the answer was you are not blocked, go figure it out. Painful, but you could always take responsibility.

He remembers signing purchase orders for Uber China when they could not get anyone else to sign—a multi-ten-million-dollar PO. He was maybe 27. Amir, the head of tech ops, and he stared at each other and signed it. What he loved about Uber of that era is that nobody ever followed up. Probably not good from a corporate-governance perspective, a little ad hoc, but they did not get in each other’s way and they did amazing things. It was also an extremely challenging place to work. People left and burned out for a reason.

He got to Stripe around 2016. Stripe famously did not have a management culture either. When he joined there were maybe three managers. One he loved working with, Raylene, had somewhere between 40 and 50 direct reports, because Stripe had read the Google paper from the period when Google tried having basically no managers. They followed that model for a long time. He joined in the wave of managerization as one of the early managers in that wave.

There were three or four managers: Raylene, Jorge, and one or two others. Jorge was managing a team of about 30 with maybe one manager underneath him. Raylene had no managers under her. It was chaotic, but coming out of Uber he was familiar with chaos, and the business was growing really fast. That Uber-to-Stripe period is when the cultural change around the manager’s role started to cement: not core giver or decision-maker, but facilitator.

One reason he wrote Staff Engineer, which came out in 2021, was collecting feedback from staff engineers he worked with. He was frustrated by the idea that staff engineers principally got to work on interesting, fun, personally rewarding problems. That was not what he needed. He needed them on the business and scalability problems. When he left Stripe his team was around 250 or 260. He had all these problems. Some of his very best engineers wanted a more interesting problem. He only had suffering to offer, but that suffering would make the business succeed.

How do you refocus them? Many felt that was a violation of the management contract: the manager’s obligation was to give them interesting work they wanted. Ten years earlier that would have sounded absurd. He does not think the “interesting work” perspective was ever really right. The people who were truly senior, at Stripe and everywhere he has worked, were doing the valuable work the company needed. You never saw that view take hold in the executive ranks, but a lot of people coming in believed it. Without naming names, certain companies they came from had very strong versions: the obligation of the manager, for senior hires, was to give them fun work. The industry has really reverted on that one.

Orosz asks whether this was a zero-interest-rate phenomenon. He has written about how an abstract interest rate probably shaped funding, hiring, and startups that did not have a business model but were still funded—and, downstream, software-engineering archetypes, manager types, and management decisions. The music stopped around 2022, when efficiency became more important. A lot of people, himself included, are asking whether everything they did in that era was even right at the time.

Larson asks if Orosz has read Ranjan Roy’s “ZIRP Explains Everything.” Orosz loves that writing. One of Larson’s Digg colleagues, whom he later hired at Uber, writes The Margins with Roy. The piece resonated. He does think ZIRP explains the entire 2010s in how management styles changed, salaries went up, and the ability to hire, close, and retain became the differentiator between successful companies and the rest, because you simply could not retain great people.

That pulled leverage back into engineers’ hands and created a different environment. Companies pitched themselves as more relaxed, more focused on you, more career development, often in self-defeating ways. There is a broad judgment of Google perk culture; he does not think any company that did incredibly well, other than maybe Google and Meta, had that level of perk orientation. Ignoring the perks, there were many other ways companies tried to focus on rewarding, interesting work.

One example: maybe engineers should not be on call—that is for second-tier SREs. Every person he has worked with knows that engineers being on call for their own work makes the software better. And yet companies still said, for the enjoyment of it, let folks not be on call for what they ship and page other people who were not involved in creating it. That orientation reveals the shift in priorities.

Orosz wonders if that was also when managers were rewarded for low attrition and for filling headcount. It sounds crazy now, but filling headcount was difficult. A director with a team of 30 might get ten reqs, senior and above, not new grads. Fail to fill them and it counted against you, or someone else got the headcount, which might help their promotion—forty-plus people and you might be a director. Managers who did well in that environment were a bit of people-pleasers. They started shielding engineers from the business.

That shielding has bitten a lot of people, because engineers are now expected to be savvy about the business. That is when you are in demand, when you can hit the ground running at a startup. He still hears from people who left a big observability company for a seven-person startup and say it is terrible, they are not being let to do things. It is a seven-person company. How are you not asking what the business needs and doing it? They were socialized somewhere else for a long time.

Larson thinks incentives are a huge part of it: headcount filling, team management, employee-survey results. Those tools are valuable—he gets a lot out of them—but he remembers spending a lot of time at fast-growing companies analyzing manager quality from survey scores. High or low scores do not mean good or bad manager. There is context. You have to ask why the team is upset. The scores became a goal rather than an interpretation mechanism, which in a lot of ways is just lazy middle management.

He hates headcount conversations. They are almost never the most interesting conversation. In a world where managers are not allowed to make technology decisions, the only lever they have to execute faster is headcount or prioritization. Orosz restates it: conventional wisdom said do not make technical decisions, so savvy managers put their energy on the non-technical side, underinvested in technical calls they should have made, and over-indexed on the soft side, including shielding the team from the business. Larson: 100 percent. That is very true.

What he tells teams now is that hiring is the least interesting way to solve every problem. They should almost never talk about hiring. The corollary: if you already have open headcount, asking for more should not be the conversation either, because what matters is hiring throughput—you cannot use more reqs anyway. They told managers they could not think about technology solutions, so what did they have? Process, scheduling, or people. That was the natural consequence of bifurcating the two roles. He is not saying you should never split them, but you need effective leadership on both, or people over-anchor on hiring, and that drove a lot of the bloated orgs of the past.

Orosz turns to careers, starting with individual contributors at startups and mid-size companies. There used to be a clear ladder—Eng 1, Eng 2, senior, staff—and a clear story of how you got promoted. Eng 1s and 2s wrote the code; they are now getting better at architecture; people talk about loops. Do we still have a career ladder? Should a manager be worried about putting one together right now?

The expectation from teams is certainly that you should have ladders. The belief, which Larson thinks is backed by research, is that rubrics drive fairer decisions than no rubrics. Anchoring on career ladders is here to stay. If you do not have one, you undervalue maintenance work, glue work, gel work, and overemphasize flashy things that happen to work. He is still a believer. What should be on the ladder is much less clear.

Some consultancy has been selling the same packaged ladder from small company to small company. Those are really outdated, and there is no next version yet. When he thinks about people getting to staff or principal these days, he has been considering an add-on to Staff Engineer he will get to in the next decade sometime. It is really about decision-making in complicated situations—navigating ambiguity.

At Stripe they wanted to go multi-region. The engineers trying to lead it kept saying they needed product to decide how cross-region replication worked: what product behavior to support under consistency and availability trade-offs. They wanted the product team to make CAP-theorem decisions. Product cannot possibly make CAP-theorem trade-offs. What those engineers were doing was finding a way to get stuck.

What you need someone at staff or principal to do is navigate ambiguity by making trade-offs, building conviction, and prototyping whether the assumptions are valuable and workable. Those ambiguous problems are still a strong marker, even with agents. Some of the trade-offs, as Orosz said about understanding the business, come from product implications: what users are actually trying to do, the unit economics of the product, the cost to serve it, what you charge. You have to be quite broad. Decision-making is still where staff and principal engineers make impact. That has not changed.

He does not think agents are exceptionally good at those trade-offs. They often do not even recognize them, because they are not in the context window. They settle implicit things that live outside the software. Orosz asks about Eng 1 and Eng 2. A senior engineer had told him AI is clearly as good as Eng 1s and 2s at writing code, which is a lot of what those roles were for, and that someone will still make it to senior, but not right now. In Larson’s org, how does he think about new grads and people under senior—people you cannot fully trust yet on judgment, for hiring or for developing?

He tries to stay away from what he calls artificial specificity. What is the difference between an Eng 1 and an Eng 2? It is actually pretty hard to be super concrete. A lot of companies successfully say the difference is three years of work experience. Is that equitable? He is not sure there is a super equitable way. A really bad Eng 1 you can identify. A really good Eng 1 versus Eng 2 is often time in role, building more context. It is not that they can or cannot do a specific thing, especially with coding harnesses: they can do anything. Deciding whether they should is increasingly tricky. In a situation with a lot of direction, you cannot even perceive their judgment.

He hears less and less about fine distinctions. Time and level is probably good enough for a lot of this. Getting incredibly detailed on criteria is a fake victory: you made it precise, but you have been in calibration meetings with people who played the rubric. At one company, a mentoring requirement for staff meant people went out, talked to someone once, and reported them as a mentee. Talk to that person and they did not know why they had been talked to. You get what you measure.

Promotions have always involved a lot of judgment. Whenever you try to remove the judgment, you do not get good outcomes either. A rubric to guide people is useful; ultimately it is pretty subjective. For a lot of these things, constraints are more interesting than comprehensive rubrics used to make judgments. At Carta there was a lot of cost pressure. He had a ratio: you could not have more than this number of staff engineers relative to the rest. It was not possible to exceed it. That annoyed a lot of people.

He thinks it is more honest about where the industry was fifteen years ago, when there was not a role past senior at most companies. Senior really was the terminal role. As people have gotten further along—twenty, thirty, forty years of software experience—companies opened more levels. A lot of those levels are time-in-role titles rather than an obvious change in capability. He tries not to worry as much about the details. A hard block of one-to-eight, or whatever it is, is really helpful if what you are trying to do is manage costs. When you are managing costs, you have to be honest that you are managing costs. That was Carta.

At Imprint they are not trying to manage costs; they are trying to manage velocity and quality, so they have not thought about a ratio at all. Part of leadership is knowing what you are doing, explaining how you are doing it, and letting people accept the consequences. Because of the Carta cap they had to shift hiring less senior, so there was a pipeline filling those levels. A lot of things followed from that fix, and it worked. Fixing the ratio without fixing the earlier funnel would not have. He is less of a believer in a perfect description of things that are true than he was earlier in his career. There are so many exceptions.

Orosz says that when they both worked at Uber, and later at Stripe, it was pretty well understood what a senior was: you could typically trust them with a project, and if they had juniors they would mentor them. A staff engineer you could trust to set direction over a unit or multiple projects. Eng 1s and 2s could execute code without too many issues and take feedback. They were almost apprentice levels—not a destination, just growing. Some companies, including Uber, expected you to grow to a certain level. They were getting to the point of having good judgment.

Now everyone is using AI harnesses a lot more, including for reviews, and code review is slowly going away. They are doing less of the very visible coding feedback they used to give each other. How would Larson define the role of a software engineer? Is it different, more ambitious? Orosz feels it is getting more ambitious and cannot quite put his finger on how, especially from a CTO’s chair. Staff engineers at mid-size and above companies never did that much writing of code anyway; they were busy making sure the right thing was being built. Now nobody is writing that much code, and even the smallest roles have to decide whether they are doing the right thing.

Larson says we are still in early days. Some people will tell you the software teams of the future are five people for any size company. Maybe that is true; maybe we will get there. We are definitely not there right now, and he does not know if we will get there soon. There are companies with a small number of engineers spending a staggering number of tokens in productive ways, which is pretty cool to see. Where is the role of software going? We are going to find out. That is why it is such a fun time to be in the industry.

The profession is changing in a more extreme way than anything he has seen since he entered. For someone always oriented around the outcomes of the work, it has been the most fun time he has had. He has also spoken to people who got their joy from being in the zone, in flow. They have fallen out of love with software because what they loved was the art of doing it. One person he spoke with recently is retiring: more productive, but he just does not enjoy writing software anymore. He has lost the flow state.

The role is shifting in a really interesting way. Larson has had this idea of software where time to implement is approaching zero. These systems are still slow in practice. You still have to make all the decisions. It still does not work in all these ways, still scales poorly in all these ways, still breaks user expectation, still has the wrong unit economics to be a profitable business. Even if software were literally free to write, it would still be really, really hard.

Today you see that if software is cheap, engineers run ahead of the PRDs from product and the high-fidelity mocks from design. That is creating a ton of issues for design teams trying to work with an engineering-led model. Something they are still figuring out at Imprint, he says honestly. Orosz sees opportunities too: an engineer who puts on a design hat or a business-domain hat and runs a full experiment. There are only so many experiments you can run without confusing customers, which goes back to strategy—someone has to say no. Customers have finite attention. Netflix does not show you all 8,000 movies.

If software is getting faster, engineers will need to discover the constraints of the rest of the business: the domain, the customers, the reality, the unit economics, how money can be made. Larson thought about this a lot at Carta. Carta is a low-scale business: not hundreds of thousands of requests per second, no massive infrastructure problem. It is an incredibly detailed business. How cap tables work is really, really specific, with tons of exceptions. Accounting has to be right from an auditability perspective. You work with law firms that have a strong point of view about how everything should be done. You can be in a legal battle between two founders arguing about how much equity actually vested.

The other businesses Carta went into, like fund administration, were also incredibly detail-oriented. There are a lot of businesses where domain context has always been the hard thing. It is not super clear to him that those businesses have benefited that much yet from the AI tools. Cap-table management is still incredibly hard because of the details, the laws, the relationships with law firms, training the paralegals. Complex-domain businesses still have a lot of defensibility. He thinks that will change. He does not know how.

Every two or three years there is a meme that product engineers are the new king, the new superhero. Now it is the AI engineer. Larson says those really are product engineers who use AI techniques, which is pretty much every product engineer these days. He has never quite understood what “AI engineer” means. He thinks it means someone who uses harnesses and wants to get paid a lot of compensation, and it probably also means nuances he has missed.

Can you actually get individuals to hold all this context in their head? People used to talk about the front-end engineer who was actually a good designer, or the designer who could write production front-end code. That person was always rare. Now a designer with a little taste can write production code, and a front-end engineer with good design taste can do design. Why don’t we see more of that yet? He thinks it is a social constraint.

Orosz has been asking the same thing. He saw data from Linear that PRs from designers and product managers are up. An engineering manager messaged him: hang on, we should be seeing more designers push to production. He asked around ten companies; Orosz asked another ten, including Linear, Ramp, and OpenAI. Except for exotic edge cases, he has yet to hear of designers pushing production code. They find bugs, they identify them, but they still get an engineer involved who confirms the approach works in the codebase, especially outside prototyping. They prototype more. He wonders if it is accountability—like changing a light bulb versus calling an electrician for the house wiring—or specialization.

One worldview right now is that if you have a great design system and you actually use it, you do not need product designers anymore. Larson has not found that to be true. Even with a good design system, understanding how components fit together, the missing components, and trade-offs across screens while presenting a unified experience are still really hard. Attention is all you need is not about human attention, but people are still constrained on attention. Great product designers and design-system designers are so constrained on the details of doing it well that they do not have a ton of time to branch out.

Does that inherently have to be true? He does not think so. In theory, if you have a great design system, a ton of consistency, and linters that force it to be used a certain way, design-system folks and product designers can look at the exceptions much more aggressively. That is where they are trying to get at Imprint: the base case done by engineering on the stock design system, product design on the complicated versions and on extending the system. It is not working that way yet. It is still a little tricky. As the people deep in AI say, assume it is a skill issue and you will get to the other side. It is still a skill issue for them. They are still figuring it out.

Orosz points to Larson’s article “The Revised Rules of Engineering Management.” One rule he wants to highlight: durable, high-ownership teams with domain context are even more important. Larson is quoting his own Uber lesson: persistent durable teams work magic by accumulating domain context, building camaraderie, and feeling an increasingly strong sense of ownership as they keep working an area. That was 2014–15, more than ten years ago. He still feels it is very relevant.

Larson thinks this is the only way to build scalable organizations. It seems obvious, but it is a bit of a non-consensus take. You are at a 50-engineer company. A partner project is late. There is still the mythical man-month, but someone says we are moving fifteen more people onto this key project. The Mythical Man-Month was 1975, second edition 1995—more than fifty years ago. We know this does not work. A lot of it is optics, creating the perception of doing everything possible so that when you miss, it is not your fault.

Not only does it not work, it destroys the thing that does: little pods that own areas. When Larson joined Stripe he took over the team Jorge had been leading; Jorge moved on to lead Connect. Larson had 30 people and one manager running four or five of them, and he was directly managing 23 or 24. The first thing he did was figure out pods—areas someone could own. Once he saw progress, he stopped thinking about them entirely until something went really wrong, so he could focus on the bigger problems, the ones you could not solve.

This works so well. He did the same at Uber, at Imprint, at Calm. Carta was already a well-scaled organization when he joined, so he did not need to. If you do this well, people do better work than you will from top-down dictation, simply because they understand it, and it lets you put your attention on the highest-leverage or most painful parts of the company. It is a strange non-consensus take that just works, but optically it almost always looks wrong, which is why it is hard to do. A partner launch is late and you say you are not moving people off important work; the team on the critical path will work hard as hell together and burn to get through it, but you will not pull everyone over.

What you might have done in the past, Orosz says, especially in a world of meetings and recruiting, is strip the critical-path team of all the BS: recruiting, the university trip, all-hands. That works so much better than adding people. Sometimes you tell people this will be a two-week push, anyone who can commit including extra hours, and in return you take time off afterward. You treat them as adults. People will often take a thing for this one thing, especially when they know you will repay them in kind.

If you do not do that, at a real growing company there is a crisis every day. If you rotate people to crises, there is a crisis for everyone every day, and it creates a sense of devastation. Larson remembers talking with someone at Stripe a year or two in. His metaphor for how Stripe had run was people on a wall trying to defend a castle, always running to the place about to be overwhelmed. They got faster and faster at running and still could not be everywhere at once.

What they were trying to switch to was many people in many places. The people in one spot had to solve that spot; they did not have to be everywhere. To be a successfully scaling company growing quickly, you have to get to a mode where it is not the same people running everywhere, because those people completely burn out, and there is a point where they cannot cover anymore no matter how amazing they are. The question with AI is whether that point is much further out. He is not sure it is. He still thinks their attention runs out before their ability to write code does.

Orosz has been thinking about durable high-ownership teams with a Slack example. Google Chat, Mattermost, Microsoft Teams, Slack: four big competitors in chat. A startup could instruct an AI to copy Slack, and it would copy the UI or find open source. First, a lot of decisions have never been documented; people at Slack know them, and they take years, and if you build you will figure them out if you are big enough—concurrency, deliverability, and so on.

Taking that aside, Slack launched Slack agents: coding agents that do the work inside Slack, well thought out, from a team with domain context. Why has Google Chat not launched the same thing? That example made Orosz realize there is probably value in Slack’s large team. From the Uber years you would be horrified at the headcount. They are not only operating what they have; they keep reinventing what customers will want. The others have not responded, even though agents have been here for a while. Slack did something objectively good. How did they get there?

Larson recalls some paper about the size of the bureaucracy managing the British empire: the number of bureaucrats kept growing even as the territory being managed kept shrinking. Companies expand, create bureaucracy, create overhead. Sometimes they have just lost the plot and their ability to move. His assumption—he thinks this is true of Meta as well—is that when really interesting products come out, there are one or two highly empowered people connected to the founder, the CEO, the executive team, pushing it through, able to make painful trade-offs that are not well liked: legal versus company, product trade-offs, not doing the sacred things the way they have always been done.

His guess for Slack is that there was some sponsor. People hate overemphasizing executives, but he does think executive sponsorship is what empowers people to do something difficult. Imprint moved to Linear from Jira three or four months ago. They did it in less than four weeks. Basically zero people thought it was a good idea when he decided to do it. They still did it in less than four weeks, and now people are really glad. It solved a lot of problems about having centralized issue management so agents could know where tasks were, pull them down, work them, unify tasks. They were having a hard time managing workloads without that.

Maybe three people out of about 230 thought moving to Linear was a good idea before he did it. He pushed it through. Now people are glad. Sometimes someone has to take the risk. The flip side is you then judge executives on whether those risks were good. Three months later nobody talks about Jira. If people had hated it, they should have been rallying to fire him. A lot of times sponsors are not held accountable, and that is how you also get the boneheaded calls.

That is a segue to executives. Larson has been a CTO, which is a form of executive. Orosz wants his interpretation of what an executive is, and what the career path looks like today from engineer to that seat—someone who likes the idea of making decisions, including unpopular ones, helping people and companies. What was the old path, and what is the new one, if there is any?

The old path: you are a software engineer for some number of years, could be pretty short, then you get into management, climb through middle management—engineering manager, senior manager, director—and then you get to CTO. There are a lot of problems with that. First, the people selected for management initially often were not the most focused on the technical pieces of the work, because they were trying to get promoted into management. The selection bias is toward people who can operate well, which does not necessarily have a lot in common with the technology side. Often they happen to be really good at technology, but there was not a strong selection bias for it.

You really do have to be a good bureaucrat to be an executive. That is one of the interesting challenges. A lot of Larson’s work is incentive management: knowing that if we roll out this sort of performance review, here is how it is going to fail, so we should not do that, we should do this other thing instead. If you have not done the reps of being a bureaucrat, you actually cannot run a function, because a lot of running a function is in fact being a bureaucrat. Orosz asks how he learned to be a good one. Out of necessity. He was a bureaucrat.

At Uber there were not really rubrics. There was not a structured interview. They had no structure for how they interviewed, so you had to make it all up yourself for your function. They were doing tons of interviews, and each time they did not give an offer he was pained, because he was doing so many. He had to figure that out. Stripe was a much more structurally cohesive company, with a lot of structured process. He got to work on a lot of that and learned a lot. A lot of the structure he thought was not working well when he joined, so he iterated and improved little pieces as they grew quickly.

Those middle-management jobs taught him how to be a good bureaucrat, which is part of being an effective executive: you learn which processes and incentives work. He cites James C. Scott’s Seeing Like a State, about how a state sees citizens and how that shapes policy. Same idea. If you have never been a bureaucrat, you cannot see as one. If you can only be a bureaucrat, you do not know how software actually gets made. That is very damaging.

Orosz checks he has it right: to be a good engineering executive, VP of engineering or CTO, you want to be excellent at technology—knowing how it works, being hands-on if you need to—and also a good bureaucrat who can run the function. You want both. If you go the middle-management route, it might happen that you either never were a good technologist or you stop being one by the time you get up there: a good bureaucrat, not a technologist. If you go from great technologist straight to CTO at a startup tomorrow, you will not be a good bureaucrat. Larson: that is exactly right.

Often line managers are better instinctual executives than middle managers, because they are used to working the detail. They can make better calls for the team or the company. Their judgment is just better on all the non-bureaucratic dimensions of the job. Then their judgment is terrible on the bureaucratic dimensions. That is why being an executive is hard, and why it is a hard career path. In the 2010s in particular, you had to climb layers of middle management to learn the bureaucratic component, and that was the only way to get the scale to understand it. Now those layers are kind of gone.

The interesting thing is that the other half of the job is now really emphasized: better decision-making, understanding the actual product, the actual business, how software ships, in a way they used to deemphasize. People ask if it is easier or harder. He does not think it is any easier or any harder. It is a lot harder to become a bureaucrat now, which has negative connotations, but learning how to actually operate a function is really difficult work. As a C-level you often end up running three or four functions, often one you do not know much about yourself.

At Imprint he ran customer operations for much of the last year, not a function he is deep in, though he had an excellent leader in place. At Stripe he ran support engineering and data engineering, neither of which he had done himself. You learn to operate a function that way when you have to. Those jobs are hard to get. You also get to stay a more detail-oriented leader for longer. That is why he thinks the best future executives are line managers: middle management selected for a different skill set. Getting both was always hard, and it is hard now in a new way.

Orosz asks whether middle management is slowly dying. Larson agrees it is a hard time, especially if you came up in the 2010s. You were selected for an empowerment, functional-bureaucracy model. Now people say they do not want it and do not need it. You have risen to a pinnacle you cannot step off, because the execution skills were deemphasized and the rubric changed under you. Super frustrating. He does not know how this wave of executives will be minted. It has always been a hard road.

Orosz has two people who asked him for advice. One is a head of engineering with about seven reports, wondering about their future. The other has three EMs reporting to them, with ICs also reporting to the VP; they have been doing an AI transformation, the VP is satisfied, and they are still wondering. Both ask: am I in a career trap? Both spent years in middle management. They are technical enough, but the old next step—VP of engineering—is unlikely in their current companies.

It is a hard time in middle management. There is a lot more competition for these roles. What Larson has found personally very rewarding is getting back into the details of writing software. When he left Carta his team was 250, maybe something like that. When he joined Imprint the team he was leading was about 25. For him this was a unique moment to actually reskill. If you are in management right now, either you have to get back into the details, or the world is changing so radically that the profession you know will not be valued in three years. You sort of have to decide: am I retiring now, or am I reskilling?

He thought about that too. At Carta he could just have been done. Is that what he wanted? It is not. He really wants to still be participating. He genuinely believes the way we work has radically changed in the last year. It has not changed everywhere. There is a long tail that will take a long time to catch up. In the places he works, it has changed a tremendous amount, and for him personally it is a lot more fun.

First there has to be some openness to taking a backwards step or a lateral step. What people want is very different, and you have to be open to getting a different look at it. Going back into a line-management position, for example, is actually much more educational than middle management. The tools for line management and writing software are so good. The tools for headcount planning or doing performance reviews are basically terrible. LLM applications for those things are not good. You are missing a lot in middle management right now. He would try to find his way out of it.

One hire at Imprint is Jasmine, whom he worked with at Carta. She came in as a VP who line-manages: an experienced manager who had run engineering at Mux. She is writing a tremendous amount of software, which she never had time for at Carta or Mux because she was too busy running the function. People willing to get their hands back on the work are so valuable. If that is you, you have to say so, or nobody will offer the job. He would hire more people like this all day long.

Orosz connects it to ZIRP-era engineers who got used to the company existing to let them do what they wanted: platform, not product, even if the business needed product—and sometimes they quit. He wonders if managers have a version of that: I thought I would be VP of engineering soon, but is that what the industry wants? Right now companies want really good line managers. The best engineers he knows put ego aside when the business said it needed product, even if they were great at platform.

He felt that with Larson too: 250 people, compensation, equity, status, and he went down to a lesser-known startup, not as well-known a brand yet, a much smaller team, smaller responsibility. You left the ego at the door, and then you learned so much more. Larson says in a lot of ways it was just a much better situation for him. It was not “this is a hit.” That is not how he thought about it. It was the perfect situation because what he wanted was getting back into the details, relearning how to do software in the current age. That is what he believes is the unlock to the longevity of his career. Also it is just much more fun, much more energizing.

He has always been someone who got tricked into management, going back to the Digg story: they needed a manager, so he said yes. Then they made him a director so it looked like they had a director in the acquisition conversations, more palatable, but he did not know how to line-manage, let alone direct. They kind of needed one on paper. For him this has been what he wanted, a unique opportunity. For a lot of folks there is a sense the industry has betrayed them, that they are owed something they have worked for. The thing is, they are right: they have worked incredibly hard. The rules have changed.

At certain moments the world looks very stable, and our industry looks very stable. In the 2010s we forgot that our industry is actually very volatile. It has changed a staggering amount every decade. Things are just radically different than they were in the decade before, and we lost sight of that. People who came up in an era of a lot of stability do not always remember. We have to be willing to take lateral moves, to be a little bit humble. If doing the actual work that matters to the company is humility, then we have lost track of what we are doing here, because we really do just get paid to do things that are valuable to the companies. There is no entertainment orientation to why these companies employ us.

What about the TLM role, tech-lead manager? They both declared it dead, a dead end, back when tech leads were given a very small team to manage as well. In ZIRP that was just a career rut, a trap; Larson has an article. What does he think about the role now? It is funny. It is still a trap, but it is a highly demanded trap. In many cases there is no alternative, so it is less a trap than simply what is there. In a lot of companies management is getting flattened. Orosz is starting to see a director with a bunch of tech leads and an org of like 30 people of tech leads here and there.

Larson sees two models. There are engineering managers, but they are managing much larger scopes, so they are actually less hands-on with individuals than before—managing 12, 13, 14 people instead of four to eight. And there are directors managing tech-lead managers instead of line managers. Different companies are trying different things. That is where he sees the industry asking for people right now. Some of the best folks they have hired at Imprint were in more pure management roles, came in, really wanted to be writing software, and have been doing an amazing job of a blend of both.

It is hard to find those folks. It is almost: interview them to be a great EM, then, do you just get frustrated you are not writing more software? That is really the person you want. They have not been interviewing that way so far; they have just found a few great people. That is the role they really want. It goes back to wanting people who have the capability to do the bureaucratic parts but do not want to—the capability but not the desire. Those are the folks he sees as super effective these days. They can use that when they need to, but they default to actually writing software, which is really where most of the value is.

As a closing topic, Orosz wants to ask about how Larson writes. He has been such a prolific writer; Orosz still enjoys the blog, checks every new article, and is subscribed to the email. How does he approach writing, and what does he think about AI? There is a lot of AI writing going on, not just LinkedIn, but also authors who did not write with AI before and now are starting to, a little.

Larson has been writing online for about twenty years. He founded Irrational Exuberance in 2007—maybe May or June—so he is getting close to the twenty-year anniversary. When he first started writing he was simply trying to figure out how to network his way into a job. He did a ton of tutorials: here is how I did this. That was a different era. Now that is the sort of thing you would just ask an AI, and it would write a great tutorial just for you, or maybe just do it for you directly.

As he started working at Uber he wrote a little more of the things he had been learning at hyperscale. It really took off when he was writing at Stripe, a place that both had a lot to learn and a real love of writing, which energized his work. Then he wrote his first book, a culmination of the Stripe writing, An Elegant Puzzle, and got a lot of momentum. He thinks a total of four books. He is probably not writing another for at least a decade, maybe not ever.

It has been so transformational. When people know him, which is not that often, it is exclusively from the books or the blog. He really believes writing is a unique way that we as individuals can actually change the shape of the industry. When you have done that, little things pop up. For Orosz, the tri-modal salary piece: first a memorable name, which helps, but also a really important observation a lot of people did not understand. Larson thinks Orosz has changed how a lot of people approach compensation. Patrick McKenzie has his work on negotiation, which has probably created so much wealth for people in the world.

For his own books, he really thinks he has changed the industry. Staff Engineer, notably: that book created staff-plus as a concept. There are other things that are less quotable but have mattered. There is nothing he could have done in his work at any company that could have impacted the industry this way, this many people, this positively. Orosz remembers reading An Elegant Puzzle and Staff Engineer and taking a lot of guidance from them. That is just so powerful.

Then he thinks about writing with AI. He has spent tens of thousands of hours over twenty years on this. He is not craft-oriented: he is trying to get ideas out, not write the best blog post. Orosz likes that the ideas are punchy. Larson is a decent, enjoyable writer, but that is not why Orosz reads him. The idea arrives and makes him think. The presentation is fine; the idea is what brings him home.

Larson calls it pretty minimal writing. Orosz notes some of the articles are short. It is not even about length. Orosz is way more wordy in his own writing, which is his natural style. What he likes about Larson’s is that he does not waste a breath when there is not much, and that is complete. Then Larson thinks about all the stuff he has put together, all the things he has tried to change people’s minds on. Writing with AI would just be throwing that away.

He has never done a newsletter trying to collect a huge number of folks. It is more: if you want to read what I am writing, this is what it is. It is not his business the way it is for Orosz. Still, he has gathered some number of people, and they read what he writes, and that is really powerful. He knows that if he writes something, often there will be hundreds of companies talking about the idea in the next week. That is such a privileged spot to be in. If he just wrote slop, he would throw it away, and he can never get it back. He will never spend another twenty years doing this.

When he thinks about the advantages he has carefully built over two decades, why would he throw that away? If he does not have something to say, he just does not say something. He is not trying to manufacture content. It would be such a devastating moment to throw that all away for nothing. If he were throwing it away for something, he could maybe get there. He thinks it would just be an uncompensated loss if he wrote AI-slop articles. He does not think anyone would read them, and he would throw away this thing he has spent so long putting together. He assumes Orosz feels the same way.

Orosz does. Writing is how he thinks. People ask about his social-media strategy; the following is mostly a byproduct of researching the industry almost full-time and talking with engineers. He starts a draft, parks the idea in a tweet in another window, keeps writing, and later finds it has traction because it was interesting—or controversial. He is not polishing those posts. He is more interested in the conversation.

Sometimes the tweet distracts him, but it also forms the idea. A lot of his writing is observation: are you seeing this? That generates conversation. He tried a Pragmatic Engineer bot trained on his archive and found it almost hilarious. His views change. The bot would spit back something from years ago. They were just talking about TLM. A Will Larson bot would still say TLM is a trap. Today they are talking about how there is way more to it.

He tells people not to put their thinking through that. When he sees someone write on LinkedIn, especially a fellow professional, or they message him, they often comment with their real voice, and he thinks: why don’t you just write that, imperfect? That is you. I like the you. He does not like the sterile thing, and he does not like how AI has the same voice for millions of people, whereas millions of people talking have millions of different voices.

This connects to something Larson thinks is really related: a lot of people believe that to be successful they need to be writing content, but they do not really want to be writing content. So: I really hate writing content, but to get promoted, to get my next job, I need to be writing. How do I do that? Obviously AI. He has been trying to push back on that for a while. He wrote a piece, he forgets the exact name, about how to be a tech influencer. Orosz is going to link it. It is not catchy, almost click-baity, and it is the single best post about how to be influential in tech. He has forwarded it to so many people. Thank you for writing that.

The reason Larson wrote it was people saying they needed to write 200 things, 300 things, every week. If your goal is to be visible, what you need to do is write one thing that gets traction. Spend a lot of time on it. Test it. Figure that out. You do not actually need to write a ton of stuff. There is almost no value in writing a ton of stuff unless you are running a business based on a subscription. If you are just trying to get your ideas out, be a little more visible, show proof you can write cogently, you can write two things, three things, one thing every two years. You do not have to write a lot.

He thinks about Tanya Reilly, who has not written a lot on her blog, but when she writes something it says something really interesting. She is not a volume writer, but she has been able to have really impactful pieces. Glue work is the most obvious, one that has really been transformative. Even for people who do write a lot, people do not remember the vast majority of what they write. There are a few pieces that stick out. If people reoriented around the real goal, maybe a thousand of visibility, one or two good things matter so much more than volume. He wishes people would stop creating volume if they do not actually—he thinks it does not serve their goals.

He has seen candidates over the last year with AI-slop content and a huge volume of it. He is pretty conflicted on those candidates. People are not reading it, and you keep doing it. Why are you continuing to do something that does not serve any purpose, because no one is responding to it? It feels like people running a recipe who are not tasting the product. It is cargo-culting. They do not actually know why they are doing it. To him it actually implies poor judgment rather than a sign of an ambitious person trying hard.

Orosz asks for a book, or books, Larson has enjoyed. Larson would certainly recommend his own books to anyone who enjoys spending money on things. Orosz says they are all excellent. Crafting Engineering Strategy came out last year, the newest one, and there are a lot of interesting ideas in it. Thinking in Systems: A Primer by Donella Meadows is one he thinks about a lot. Orosz read it based on Larson’s recommendation. Larson says it is honestly the book that formed his view about management and operating in companies. It is not really about operating companies, but it is a mental model you can use. Incredibly helpful.

Really, any book that forces you to have a different perspective on something. He spent a decent amount of time a couple of years ago thinking about typing—not typing on a keyboard, but how to have better type systems, which is not that relevant to his work on a day-to-day basis. There is another great book, whose name he is losing, on TLA+. Orosz: Hillel Wayne? Exactly. Wayne has been on the podcast. Fantastic book. Larson is not using a lot of TLA+ day to day, but the ideas are incredibly powerful: using languages to increase the verification of your software, which is one of the biggest problems of our time.

If all of our software is getting written by someone else, which is an agent, making verification cheap is really critical. Even if TLA+ is not the tool for that in many cases, thinking about that problem is valuable—the same reason typing is really interesting. Right now those are some useful ones. Orosz thanks him. It was awesome to finally have this conversation. Larson: likewise, thank you for having me.

In the recap, Orosz says he has known Larson for so many years, and it was great to sit down in person, at a time when traditional best practices of engineering management and engineering career progression are both in flux. One really interesting topic was how far managers used to bend over backwards to find interesting projects for their engineers. Larson recalled that at Stripe some of his best engineers asked for more interesting problems. Back then he already pushed back: the only thing he has is suffering to offer, meaning not particularly glamorous problems, but that suffering is what will make the business succeed.

In the 2010s and early 2020s, lots of engineers saw that approach as not particularly great management behavior. Today it is kind of the default. For career stability and promotions as an engineer, especially at senior-plus levels, you will want to help the business solve its most pressing problems, and that includes having empathy for those problems.

Orosz also found it eye-opening how Larson thinks about what it takes to be a great CTO. You need to be two things: a standout technologist who knows what to build and how to build it, and a bureaucrat who can run a whole function, including a function you might not be an expert on, like product or design. In the 2010s lots of managers learned mostly about the bureaucracy part, and by the time they became CTOs they had lost the technology side. Today, with smaller teams and less middle management, many CTOs will be technologists first, which Larson thinks might be better overall. Orosz agrees.

Finally, he appreciated Larson’s advice to middle managers—engineering managers who have managers reporting to them. Larson did not beat around the bush. Yes, today it is a hard time to be in middle management. The two paths: go back to being closer to where software is being built, on a smaller team or as a line manager, or accept that expertise of mostly being a bureaucrat, not a technologist, may not be valued that much in a few years.

Larson himself took a step backward when he left a 250-person engineering team at Carta for a 25-person team at Imprint, consciously, to learn how to build with AI changing the profession. Orosz finds it inspiring that Larson not only talks about learning the new rules of software engineering, but walks the walk. He points to show notes on related Pragmatic Engineer deep dives on zero interest rates and engineering and EM careers, and asks listeners to subscribe and leave a rating.