Building is getting easier. Getting it right is getting harder.

There's a nasty rumor going around that AI is replacing everybody. If AI can write code, the thinking goes, we don't need as many engineers doing it, right? 

Wrong. AI really is making engineers faster, sometimes dramatically so, but the parts of the job AI is good at were never the parts that mattered most in the first place. When code is cheap to produce, the cost of building the wrong thing goes up, and the value of someone who can tell the difference goes up right alongside it.

That's the throughline of Multiplier, a free e-book published late last year by four of Zillow's senior principal engineers. The book is a guide to the parts of an engineer's job that AI isn't coming for, such as prioritizing, strategic thinking and collaborating. 

The work that matters isn't only the work on your calendar

Think about your week ahead. A code review, a flagged bug, a few meetings, a doc you owe somebody, a side project you've been chipping away at for a month. The natural instinct is to put your head down and knock items off the list until the week feels conquered.

AI makes that instinct more seductive than ever, because the list shrinks faster. The thing that used to take a day takes an hour, and the code change you would have written Friday is drafted by Wednesday. It feels like productivity, and in one narrow sense it is. But for principal engineers, racing through the list is the wrong move. The most valuable thing you can do in a given week is almost never the next thing on your list, it's the thing that, if it goes well, deletes items from everyone else's list.

A useful framework here is Dwight Eisenhower's urgent-important matrix, which sorts work into four quadrants: urgent and important, important but not urgent, urgent but not important, and neither. The trap is that principal engineers spend most of their time on the first and third — the things that feel pressing — and almost none on the second, where the highest-impact work actually lives. That's the strategic thinking, the architectural decisions, the relationship-building that pays off over quarters and years. If you don't make the time for it, chances are no one in the organization will.

The hard part is that quadrant two work (the important but not urgent work) is almost never on anyone's calendar, nobody asked you to do it, and there's no ticket for it. A few examples: stepping back to identify a systemic issue causing recurring incidents; writing the doc that aligns multiple teams before they start solving the same problem three different ways; making the case to leadership for a long-term investment that won't pay off until next year; investing in the mechanisms for reviewing the AI-generated code more effectively.

That kind of work was always important, and AI doesn't change that. If anything, it raises the stakes. When engineers can ship faster, they can also ship the wrong thing faster, and the chance of pointing the whole team in the wrong direction goes up. The skill of figuring out what's worth building in the first place is exactly what AI can't do for you.

So how do you actually do it? First, establish planned focus time: block it on the calendar, put a "slow to respond" status up on Slack, and treat it like any other meeting you wouldn't skip. Second, write things down before they feel ready. Keep a running document of half-formed ideas, observations, and questions. Most of them won't go anywhere, but the ones that do will be most of the way developed by the time you need them, and the document itself becomes a tool for pulling other people into the thinking.

How decisions actually get made

Knowing what to work on is one thing. Getting other people to come along is another, and it's most of the job. Almost every piece of high-leverage work touches people you don't manage: other teams, other leaders, other engineers with their own priorities. 

Influence is a craft that’s learned over time through trust, expertise, and clear communication. And it’s distinct from any formal authority you might have. The thing most engineers get wrong is treating decisions as events that happen in meetings, when, in fact, most decisions get made in the quieter conversations around them.

There's a Japanese term for this: nemawashi, or "the meeting before the meeting." You spend the days ahead of the meeting on individual calls surfacing concerns, adjusting your proposal where it needs adjusting, and finding the version everyone can live with. By the time the formal meeting happens, the decision is essentially already made.

The same logic applies to writing. In a distributed company, a well-written design doc isn't just a deliverable, it's a tool for thinking with other people. A good one keeps working when you're away from it. Someone reads it on their own time, absorbs the reasoning without the distortion that creeps into every verbal explanation, and comes to the next conversation already most of the way there. In a fully remote company like Zillow, written communication does the work the office used to do.

None of this is what most people picture when they hear "principal engineer." It's not architecture diagrams or clever code, but a lot of small, deliberate acts of communication that, over months, add up to a team making decisions it would not otherwise have made. It's also exactly the kind of work AI is least likely to replace, because the value isn't in the artifact but in the trust and context built around it.

That's the work AI isn't coming for, and it's the work that matters most. It's also the real value that principal engineers, at Zillow and everywhere else, bring to the table.