The VP Who Stopped Managing

Editor’s note:We published this because Aiko Yamamoto did something almost no executive is willing to do: admit she had stopped understanding the work, and then go back to fix it.

The decision was not spontaneous. Aiko Yamamoto had been a VP of Engineering for four years, building a team that had grown from sixty to four hundred engineers across three acquisitions. She was, by every external measure, succeeding. Her skip-level scores were high. Her org shipped consistently. She had been mentioned by name in two consecutive annual reports.

She had also, she realized over the course of a long weekend with no meetings, stopped understanding how the system worked.

"It happened gradually," she says. "First I stopped writing code because I was managing too many people. Then I stopped reviewing code because the codebase had evolved and I was slowing reviews down. Then I stopped attending architecture reviews because I didn't feel like I had enough context to add value. And then one day I realized I was leading an engineering organization by intuition and relationship, with almost no direct knowledge of what was actually being built."

She did not quit. She proposed something more structurally unusual: a four-month rotation back into individual contributor work, with full management responsibilities handed off to her three senior directors. The executive team agreed, with some skepticism. The engineering team, she says, was less surprised than she expected.

What she found in the codebase was not what she remembered. Four years of evolution had introduced abstractions she did not recognize, dependencies that had not existed when she last had her hands in the code, and a set of architectural decisions that she, as an executive, had approved in principle without fully understanding in practice.

"I had been managing from memory," she says. "My mental model of the system was four years old. Every architectural conversation I had, every hiring decision I made, every technical trade-off I weighed in on. All of it was informed by a picture of the codebase that was no longer accurate."

The four months were humbling in the specific way that being wrong about something important is humbling. She spent the first six weeks slower than the most junior engineer on her team. She asked questions that revealed the depth of what she had missed. She wrote code that worked but that more experienced engineers on the team quietly improved.

She also, she says, made three of the best hires of her career. Because she now understood, from working alongside them, what the actual technical challenges were.

"You cannot hire well for a job you cannot describe precisely," she says. "I had been describing engineering jobs at a level of abstraction that filtered out exactly the people I needed. Going back to the code fixed that."

She returned to full management after the four months. She now requires every engineering leader in her organization to spend one week per quarter working as an individual contributor on a team they manage. Not observing. Shipping.

I thought going back to code was giving up. What I found was that I had been managing from a position of memory. The codebase had moved on without me.