Category: Mentoring

A hand with a pencil rests on an unrolled plan covered in penciled question marks, with automated machines running out of focus in the background.

The Questions Are the Job

Allen Hutchison1 Comment

Last month I spent forty minutes on a call with a college student who had just finished a summer internship at Google. He was polite about it, but the question under all his questions was the one I’d ask in his position. The agents write the code. The platforms hide the infrastructure. The CI pipeline is something you copy from a template and never read. So what exactly is he supposed to get good at?

I gave him an answer on the call. It was mostly right and mostly unorganized, and I’ve been turning it over since.

Nobody Asks for You

Around the same time I fixed a bug in a small sync daemon I run on my homelab. It pulls things I’ve saved in various places into Readwise, and on every run it asks Readwise what it has already seen so it doesn’t save duplicates. The agent that wrote it did that the obvious way. It walked my whole Readwise library and built a set of URLs. What neither of us noticed for a while was that the walk included my RSS feed, and on a real account feed items outnumber the things you’ve deliberately saved by orders of magnitude. The daemon paged through 103,819 feed documents and never reached the end.

I caught it because I was reading the logs and knew what my account looked like. The agent wasn’t going to catch it. It had no idea what a normal Readwise library looks like, and nothing in the code was wrong in a way a test would find. Then I had to ask for the second fix too. The dedup set needed to be a cache on disk that warms incrementally, not something rebuilt from scratch every fifteen minutes. That’s a design decision, and the agent didn’t make it until I asked.

Both fixes took an afternoon. Neither would have happened without someone in the loop who knew to ask. I’ve been living the same thing at Vycari at a much larger scale.

What I Actually Do All Day

Chris and I have merged more than 2,600 pull requests across Vycari’s repositories so far, with two people. Two months of that work came to 1.1 million lines of new code. We have an army of agents doing most of the coding, and I wrote in The Backlog Was a Coping Mechanism about what that does to an issue tracker. What I haven’t written about is what it does to my job.

I write very little code and I’m busier than I’ve ever been. I’ve started calling what I do meta-programming, because the work has moved up a level. I write the plans, the rules, the guidelines, the checks, and the hooks that push everyone who touches the codebase, human or agent, toward the right decision. Chris makes changes all over the codebase, and he doesn’t need my sign-off to do it. He’ll check with me sometimes, especially on database changes, but nobody knows what they don’t know. The guardrails exist for that. Whoever picks up a change next, human or agent, needs enough context to get it right, and that context is mine to build. It never stops needing maintenance.

The second thing I do is think about the shape of the codebase over time. We started as one repository. As the product got more complicated I began splitting services out, each into its own repo with its own CI and its own rules. I wrote about why in The Test Suite Is the New Code Review. That makes iterating on any single service fast, and it forces a contract between services that has to be written down. Agents don’t do this on their own, not even the best or newest ones. They’ll add a new top-level directory next to the last one forever, and thirty days in I had a repository full of horizontal directories, repeated code, and no shared components. I refactored it from version zero to version one over a weekend, mostly from my phone while I was at a jazz festival.

The agents were excellent at the refactor once I’d decided what it should be. Mechanical moves, package relocations, extracting an interface and applying it across a dozen subpackages: I could hand those off and not watch. The biggest one moved more than a hundred thousand lines of code, not all of it mechanically, and I was reviewing it on a phone. I only slept because we require ninety-five percent test coverage, and because adversarial review agents were reading the diff alongside me. But the decision that the codebase needed reorganizing, and the decision about what the organization should be, came from me reading the code and recognizing a shape I’d seen go wrong before.

Proportional Scrutiny

The student asked how you get good at systems when the abstractions keep you from touching them. Part of my answer was that you have to read the code the agent writes, which is different from reviewing it.

The distinction matters to me because most code review I saw at Google was style review. Someone would tell you a line was too long, or a name didn’t match the convention, and both of you would feel like work had happened. I don’t do any of that anymore. We use Ruff for linting and formatting, it runs on every PR, and whatever it says is fine with me. I also don’t fight the agentisms. There are twenty-five line comment blocks in our codebase, and I leave them, because the next reader of that file is another agent and the comment might be useful context for it. A comment explaining how a for loop works is wasted tokens, but I’m not going to spend my afternoon hunting those down.

What I do instead is apply scrutiny in proportion to what the code is. If an agent rewrites a pile of CSS, I open the page in a browser, it looks fine, and I move on. I’m not a CSS expert and I have no plans to become one. When an agent touches our core agentic loop, I read every line and I make sure I understand why every line is there. That loop is one of the pieces of the product I’d call real intellectual property, and most of it was guided by me, decision by decision. The agent is the same in both cases. What changes is how much attention I give its work, and knowing where that attention belongs is most of the skill.

That’s proportional scrutiny, an idea I learned from Luiz Barroso. You watch the things that took a big investment, that have a large blast radius, that are consequential to the rest of the system, and you give everything else a lighter look. It applies to engineering management too. Luiz used it to let a few of us chase a long-shot project for a year while he ran an organization of fifteen hundred people.

What Breaks First

My favorite question to ask an agent, and the one I gave the student to take home, is what breaks first if usage goes up by three orders of magnitude.

A hundred queries a second to a hundred thousand. A thousand users to a million. The agent will give you a real answer, and the answer will teach you about the system you’re building faster than any textbook I know of. If you can get a project to the point where you’re confident it would survive that, you’ve done the distributed systems course. Very few systems actually run at that scale. Asking the question is still how you learn to think about scale.

I learned it the expensive way. I’ve taken large portions of Google down more than once in my career, and the lesson from those days was simple: you learn from the outage or you get fired. I once led a team that built a geographic photo search system, and it had to sit in the main search path, so every query to Google.com went through our code. The day we turned it on our baseline was over a million queries a second with a five millisecond budget at the ninety-ninth percentile. The naive implementation took a week. The version that could actually carry that traffic took two years. That gap, between the thing that works and the thing that survives, is what senior engineers carry around in their heads. It’s what the student was really asking how to acquire.

The Bargain We Used to Make

His question is harder now than it was for me. The industry used to run on a trade. A new grad could write syntactically correct code and not much else. We’d hire them, they’d write a lot of code, and a tech lead would sit alongside them and teach them how systems actually fit together. They gave us labor, we gave them judgment. It wasn’t efficient, but it worked, and it’s how every senior engineer I know got here.

Agents took the labor half of that bargain. A new grad’s first year of work, the part where you write a lot of code and learn by getting it wrong, is exactly the work agents do well and cheaply. What’s left is the judgment half, and that was always the part that was hard to teach and impossible to shortcut. I wrote in The Last Programmers that each rung on the abstraction ladder frees us to work on harder problems. I still believe that. But the ladder used to have a bottom rung you could stand on while you learned, and I’m not sure it does anymore.

I don’t think that’s hopeless. I think it means the apprenticeship has to be rebuilt on a different foundation, and so does the university curriculum. Whatever anyone thinks of AI, it isn’t going back in the bottle for coding. The new foundation is the same one the senior people are standing on: the questions.

The Most Patient Teacher You’ll Ever Have

The part of my answer I most want to be true is that agents are the best teachers most of us will ever get access to, if you treat them that way.

Don’t take the PR blindly. Ask why it did that. Ask what the trade-offs of that data structure are. Ask what the runtime implications of that table layout will be at ten times the rows. Ask it to explain the same thing three different ways until one of them lands. It will never get tired, never get impatient, and never make you feel stupid for asking the same question again. Some of the tools lean into this directly. Claude Code ships a Learning output style that explains its choices as it goes and leaves small pieces of the code for you to write yourself. That’s closer to what a good tech lead did for me than anything I got from a book.

I do a version of this constantly. I’ll point an agent at a subsystem and say I want to understand this deeply, walk me through the important files and the control flow. I’ll ask for a diagram of how a subsystem looks in main today and then interrogate the diagram. When I was a senior director that was exactly how engineering reviews worked: someone came in with block diagrams and sequence diagrams and we talked about the project at that level of abstraction. I wrote about coming back to the individual contributor side in Full Circle. One of the surprises has been how much of the director job I still do, just with an agent across the table instead of a team.

I’ve even considered running a full design review this way, asking an agent to build a presentation and walk me through its decisions the way a team would have. I haven’t taken it that far yet, but I may at some point.

That’s the rebuilt apprenticeship. You still have to write some code by hand, and you still need a couple of languages you’re truly fluent in. But the judgment you used to absorb from a tech lead over three years is now something you can pull out of an agent on purpose. You do it one question at a time, starting on your first day.

I don’t want to oversell this. Glyph Lefkowitz makes the strongest version of the opposing case in Programming Isn’t Special. Take away the mundane work and you take away the practice, because “the majority of true skill development happens on the job and always has.” He’s right about that part. Most of my own judgment came from getting things wrong in production, and asking an agent good questions doesn’t replace the experience of an outage you caused. What it can do is get you to your first real failures sooner, with a much better map of what you’re looking at when they happen.

There’s also something the agent can’t teach you, which is anything that happened after its training data ends. When a new language feature ships, the agent won’t reach for it unless you tell it to, because it has never seen it. Knowing when a change like that matters, and when to bring it up, takes judgment and experience of your own.

How We’ll Know

The student asked about hiring, and I gave him a split answer. Google and the other big companies will move slowly on this. The interview you get there in five years will look a lot like the one you’d get today: computer science fundamentals, system design, distributed systems. Those things aren’t going away, and the big companies are right to keep testing for them.

Startups will change faster, and I’m one of the people who gets to decide how. We’re not hiring at Vycari yet, but when we do I’m not going to put anyone in front of a whiteboard. I think that’s archaic now. What I might do is hand a candidate a coding challenge and an agent, and ask for the transcript instead of the code. How they worked with the agent will tell me more about how they’ll work with us than the code will. Did they read what came back? Did they ask why? Did they notice the thing that was going to break at scale, or did they ship the first thing that passed the tests?

I recently built a whole project in Swift, and I had never written a line of Swift before. I mention it because it shows how little the language matters now, and how much everything else does. The student was worried the abstractions were taking the important skills away from him. I think they’re taking the unimportant ones and leaving the important ones exposed, with nothing to hide behind. That makes the job harder. But the questions were always the job. We just used to let people spend a few years writing code before we told them.

An oil painting of a signed acoustic guitar leaning against a chair, its sticker-covered case open on the floor, by an open window at dusk, a framed photograph of a hawk on the wall above, and an open book with a handwritten inscription on the chair.

Partner in Multiple Google Adventures

Allen Hutchison2 Comments

I recently wrote about Theo of Golden, Allen Levi’s novel about a stranger who notices everyone in a small town. All the way through it I kept seeing my friend Luiz Barroso. One of the passages I highlighted explains why it’s taken me this long to write about him: “There is no virtue in advertising one’s sadness. But there is no wisdom in denying it either. And there is the beautiful possibility that great love can grow out of sadness if it is well-tended.”

Luiz died in September 2023. He was 59. Apart from a line in the post about leaving Google, I haven’t written about him at all. This is my attempt.

The Datacenter as a Computer

Luiz André Barroso was a Brazilian computer scientist and one of the most consequential engineers most people have never heard of. He led the small team that rebuilt Google’s data centers so they behaved like a single machine. He and Urs Hölzle laid out the idea in The Datacenter as a Computer. That change shaped how much of the internet gets built. He won the Eckert-Mauchly Award in 2020 and was elected to the American Academy of Arts and Sciences in 2022.

Failure Is an Option

I worked for Luiz for several years. Before Core, when he was running Google Maps infrastructure, an organization of about fifteen hundred people, I’d started a small project to build a maps augmented reality system. We didn’t know if it was possible. Luiz didn’t think it was possible at all, and he let a few of us work on it for a year anyway.

That was proportional scrutiny, one of his ideas I still use: spend your attention where the consequences are. A few people chasing a long shot didn’t carry the consequences of the big bets in his organization, so he let us run. In one of our one-on-ones, I told him I was worried we wouldn’t succeed. He told me, “Failure is an option.” It’s the reverse of the line everyone quotes from Apollo 13. He’d made the bet knowing it might not pay off, and he wanted me to know that he knew.

Later, when he was asked to build the Core organization, I became Core’s chief of staff. I held that job for two years, the first of them working directly for Luiz, and then I helped him create the role he moved into next. That’s where I learned how to think about large organizations.

The Days in Which I Wasted My Career

Luiz was also an artist. He played guitar nearly every day, at home and at the office, and brought it on every vacation. He photographed birds, and a framed picture of a hawk he gave me as a holiday gift hangs on my wall. The year he died, he released Before Bossa, an album of American jazz standards and Brazilian songs from before the bossa nova era.

He made chocolate, too, and roasted his own Brazilian coffee. At Christmas he’d bring little boxes of chocolate to the office and give them to people. Sometimes he’d give me a pound or two of lightly roasted Brazilian coffee, and I savored it.

When the third edition of his data center book came out, he gave me a signed copy. The inscription reads: “To my friend and partner in multiple Google adventures, in hopes that this will remind you of the days in which I wasted my career as an Engineer :-)”

He didn’t think his engineering was a waste. He knew exactly how much it mattered. The joke was about something he took seriously: a person should be more than their job. The guitar, the birds, the chocolate, and the friendships were the other half of a whole life, and he made room for them.

The Only Thing He Carried Was a Guitar

Luiz was one of the only executives I ever worked with who didn’t carry a laptop into meetings. He’d show up with his phone in his pocket, and it stayed there. He didn’t read email between speakers or skim his inbox during someone’s slides. He talked with his team. The only thing he tended to carry into a meeting room was a guitar.

Somehow he was also prompt with email. I knew him for years and never saw him with a computer, but his replies always came back fast. I still don’t know how he managed to be fully present all day and stay on top of his inbox.

After his death, Urs Hölzle said there are constant battles inside the company over what the future should look like. Luiz navigated them, he said, thanks to an endearing personality and his guitar. In a room full of smart, stubborn people, the person who’s actually listening is often the one who gets a decision to stick.

He brought the same attention everywhere. We traveled together a lot. One Saturday on a business trip to Zurich, we spent hours walking all over the city and along the lake. We ended up drinking beer in a park and talking. On another trip we went to Oktoberfest, decided the crowded tents weren’t for us, and found a smaller beer garden away from the main festivities. What I remember from both is his questions. He was interested in everything, and he asked about you because he wanted to know.

He was also the most fun person I’ve ever watched soccer with. During the 2018 World Cup we had TVs set up in the cafeteria of our Google Maps building, and Luiz made it to a lot of the games. Once I took him to a San Jose Earthquakes game, and the things he noticed were so typically Luiz. Someone would make a bad play and he’d say, “You see him, he’s looking at the coach to see if the coach saw his mistake.” Even at a soccer game, he was watching the people.

In the novel, Theo finds ninety-two pencil portraits on a coffeehouse wall and gives each one back to the person in it. Reading those scenes, I felt something catch in my chest, because Luiz did the same thing. The gifts were real, but they weren’t the main way he did it. He did it with time and attention. He listened fully. He was present. He saw you.

What Google Meant to Him

Luiz loved Google, and he loved what he thought it stood for. He’d come to Google from Digital Equipment Corporation, and he’d watched big technology companies decline as they grew and got acquired. DEC was the example he came back to most often. I think he felt a responsibility to help steer Google through its enormous growth, and to keep reminding the company what it meant to be itself.

His essays on engineering culture read to me as part of that work. In the latest edition of the data center book, his co-authors published a small collection of them. In The Eagle has Launched?, he argues that we celebrate the wrong moments. We throw parties for launches, when what matters is the landing: a product that measurably makes users happier, or a system that got simpler and more reliable. In the Roofshot Manifesto, he made the case for steady, mostly invisible 1.3x to 2x improvements. Stack enough of them and from far away it looks like a moonshot.

Both essays are about noticing work that’s easy to overlook. That’s a management problem as much as an engineering one, because what a leader recognizes is what a team learns to value. Luiz recognized the people everyone else walked past. In my review of Theo I told a story about telling a struggling engineer that their work mattered. I said I’d learned it from a boss who was also a close friend. That was Luiz.

Obvious in Foresight

Luiz was brilliant, and he was modest about it. He used to say that all he had was the ability to state the obvious. The catch was that things obvious to him in foresight were usually only obvious to the rest of us in hindsight. In Three Lessons from Three Decades in Engineering, he puts it as advice. Big, important problems tend to be easy to understand even when they’re hard to solve, so develop respect for the obvious.

Luck and the Help of Others

That same essay ends with a line I keep rereading. After listing the lessons of his career, he writes that he’s left out the effect of luck and the help of others. They had as much impact, he says, as any efforts of his own.

That’s one of the most decorated engineers of his generation saying he isn’t sure how much of it he can claim. I think about luck as a multiplier. Talent and preparation still have to be there, and success is still earned. But whether it comes out as a one or a ten depends on things nobody controls. People who see their own success like that tend to hold it loosely and give a lot of it away. Luiz was the most generous person I’ve known, and I think that’s where it came from.

That Last Summer

My mom died two months before Luiz did. When he heard, he reached out and offered to do anything I needed. We spent a morning at his house talking about my mom, and about his dad, who had died a few years earlier. Eventually we drifted into technology and work. He listened.

A few weeks before he died, he came to my house to play guitar. My son plays French horn and trumpet, and he brought his trumpet out and asked if he could join us. We put a few charts in front of him, and the two of them played old jazz standards together, Luiz on guitar and my son on trumpet. It’s one of my fondest memories of him.

At his memorial service we heard from many, many people who’d been close to him. We told stories and helped each other mourn a friend and mentor. The same things ran through the stories people told. Luiz listened, he was kind, and he was smart.

OM-01

When Luiz left Google Maps to build Core, we threw him a big goodbye party. I’d made him a guitar for it, had everyone on the team sign it, and covered the case in Google stickers. I’d built guitars in classes before, but this was the first one I made on my own, so I gave it the serial number OM-01. It’s the guitar in so many of the photographs of him playing.

After he died, his wife, Catherine, gave it back to me. It hangs within reach of my desk now. When I’m stuck on a hard problem, I take it down, play for a while, and ask myself what Luiz would do.

It’s been three years since my friend died. I still think about him every day.

An oil painting of a coffeehouse wall covered in framed pencil portraits, one frame missing, with blooming dogwood trees visible through a window.

Ninety-Two Portraits

Allen Hutchison2 Comments

I mostly read science fiction. My wife read Theo of Golden with her book club and suggested it to me several times. This summer I finally picked it up because I had nothing else to read. I read it a few pages at a time on my Kindle, in the weeks right before I left Google. I went slowly on purpose, because it’s a book that rewards that. It ended up as one of my favorite books of the year.

The first passage I highlighted was the opening: “Theo was in Golden for only a year, from springtime to springtime. He arrived just before Easter, when the Boughery and the Promenade were an ocean of dogwood blooms and azaleas.” Allen Levi tells you on the first page that the visit is short. The rest of the book is about what one person can do with a year if he pays attention.

When I wrote the two-year anniversary post for this blog, I said I’d keep bringing more of my outside interests here, and that some book reviews were coming. This is one of them, and like most of what I read, it got me thinking about work.

The Portraits on the Wall

Theo is an older man who arrives in Golden, a small Southern town, with no obvious reason to be there. Ninety-two pencil portraits of ordinary townspeople hang on the wall of a local coffeehouse. Theo buys them one at a time and tracks down the person in each drawing to give it to them. He calls them the rightful owners.

That’s most of the plot. You wouldn’t think it would be enough for a novel, but in this case it is. Theo clearly loves art, and rivers, and music. But the book is really about his attention. He shows up in person when a phone call would do. He notices the custodian, the accountant, the cellist, and the woman living on the street. Being seen that closely changes each of them, and over the year it changes the town.

I won’t tell you how it ends. Theo lives the way most of us mean to and rarely manage: slowly, generously, and with his eyes open.

Some readers will find it too sweet. It’s comfort food for the soul, and I’m fine with that. At this point in our history, we could all use a little kindness to remind us of the people we should aspire to be.

There’s a quiet Christian faith running through the book. I’m not religious myself. I’ve read the texts of many of the world’s major religions without practicing any of them. But I admire the reported words of Jesus, and I admire people of any faith who actually live what they believe. Theo is one of those people. You don’t need to share his faith to be moved by that.

A Flurry of Questions

Most of Theo’s attention comes out as questions. In one scene with two girls, Levi writes, “Theo was a flurry of questions. The two girls were a flurry of half-formed answers and fully formed dreams.”

I keep coming back to that line because of how much of engineering runs on questions. We ask them in design reviews, code reviews, interviews, and one-on-ones. The person on the other end can almost always tell why you’re asking. Some questions are there to find the hole in someone’s reasoning. Theo’s are there to find out who someone is and what they want, and the girls answer with dreams because his questions leave room for them.

I once took a leadership class built around the idea of listening to learn, and I’ve tried to practice it ever since. You listen without waiting for your turn to say the next thing, and you ask questions to learn rather than to score points. That’s what Theo is doing in that scene.

Managers can choose which kind to ask. “What’s blocking you?” is a question about the project, and you should still ask it and clear what you can. But once the blockers are handled, ask the bigger question. I often put it this way: “If you had a magic wand, what would you wave it at?” Sometimes you’ll get the dream.

Recognition Costs Almost Nothing

A portrait of yourself is a strange gift. It tells you that someone noticed you and that you belong to this place. Most workplaces are bad at saying that. We celebrate launches and promotions because they’re visible. We say much less to the person quietly keeping everything running.

Years ago I was coaching an engineer who was going through a hard stretch and doubting whether they belonged on their team. I told them their work mattered. They’d gone through the same process as everyone else to get their job, which meant they’d earned the right to fully participate in it. It was a simple thing to say, and it brought them to tears. Years later they told me that moment of recognition had been one of the most important things anyone had done for them.

I didn’t come up with that. I learned it from a former boss of mine who was also a close friend.

Make It for Mercy

Another passage I highlighted: “If you not sure what to do and you gotta choose one or the other, I say always go the mercy way. If you make a mistake, make it for mercy. Bad mercy don’t hurt nearly like bad justice.”

Mercy is attention under uncertainty. When you’re judging something someone did, you’re rarely seeing all of them, and this passage tells you what to do with the part you can’t see.

Engineering already has a version of this in the blameless postmortem. It’s partly an information strategy, since blaming a person for what the system did teaches everyone watching to hide their errors. It’s also an agreement about atmosphere. At Google we used to say “assume good intent,” meaning assume the people around you are trying to do the right thing with the information they have. Failures will happen, and when they do, we’ll learn from them and work to prevent the next one. That part is mercy, written into a process.

Sometimes you’ll get it wrong. Someone really was careless, and you treated it as a process failure. That mistake isn’t free. Teammates pick up the slack, and the standard slips a little for everyone. But look at how the passage starts: “If you not sure what to do.” Mercy is the default when the evidence isn’t there yet. The other half is trust but verify. You extend the benefit of the doubt and keep looking, and once the evidence is clear, holding off is just avoidance.

The same goes for a performance calibration, where a room of managers judges a year of someone’s work from a few paragraphs. You won’t have the full picture. When you’re unsure, the book’s advice holds up.

Where the Book Found Me

The timing mattered. I read it in the weeks before I left Google, so it was fresh when I sat down to write my goodbye note. I could only recall about a hundred and fifty colleagues. So I had an agent read twenty one years of my sent mail and help me say goodbye to several thousand. Theo spends a year handing people back their own faces. I was trying a version of it on my way out the door. The difference is that Theo doesn’t wait until he’s leaving to do it.

Read it slowly if you can. And if a name comes to mind while you do, someone who saw you before you’d done much to deserve it, that’s worth acting on.

The book also brought him back to me, and I haven’t been ready to write about him until now. That’s the next post.

A warm, painterly oil painting of a chess board on a wooden desk near a window. Several chess pieces are positioned mid-game with translucent curved arrows showing a sequence of three moves. Golden afternoon light streams through the window, with a cup of tea and a leather-bound journal nearby.

The Three-Move Problem

Allen HutchisonLeave a comment

I was on a video call last week with a mentee who had just finished laying out her plan. She wanted to change her role, change her team, and change her country. All at once. All within the year. She had this energy that I recognized immediately, the kind that comes from finally knowing what you want and not wanting to wait another minute to get there.

She was less than a year out of school, working in a sales engineering role at a large tech company. Her undergraduate work was in electrical engineering, and she’d done several internships in the healthcare technology space. She loved that work and wanted to get back to it. Specifically, she wanted to move into a full-time software engineering position, on a health-focused product team, in a different country. Three big changes, stacked on top of each other like a wish list written on a napkin.

I get it. I’ve felt that same pull. But I’ve also learned, sometimes the hard way, that trying to change everything at once is one of the surest ways to change nothing at all.

The Napkin Problem

Here’s the thing about goals that try to do too much at once: they aren’t really goals. They’re dreams. And I don’t say that dismissively. Dreams are important. But a dream without a plan is just a source of frustration.

There’s a saying I first heard from early SREs at Google that has stuck with me ever since: “Hope is not a strategy.” They meant it about production infrastructure. As in, “I hope the service doesn’t fall over during a traffic surge” is not a valid entry in your runbook. But I’ve found the phrase applies just as well to careers. “I hope all three of these changes work out simultaneously” is not a career plan.

When I asked her to think about what was really being asked of each of those changes, the picture got clearer. Changing from sales engineering to software engineering means proving yourself as a developer, building a portfolio of work, and earning the trust of an engineering hiring manager. That’s a significant lift on its own. Changing teams means building relationships with a new group, learning a new domain, and demonstrating relevance to that team’s mission. And changing countries involves visas, relocation logistics, and finding a manager in a different office willing to sponsor the move.

Each of those is a meaningful project. Stacking all three together doesn’t just triple the difficulty. It creates dependencies and friction between the moves that make the whole thing fragile. One delay in the visa process stalls the team change. One rejection from the health team stalls the role change. The goals aren’t S.M.A.R.T., and that sets us up for disappointment.

Sequencing the Moves

What I suggested was something simpler, but not easier: make a plan, and sequence the steps.

The first move would be to transition from sales engineering to software engineering locally. She was already doing real engineering work in her current role, building demos, writing integration code, debugging customer issues in production systems. Sales engineering isn’t a non-technical job, it’s a different job family. The gap wasn’t in her ability, it was in how that work was recognized. The key was to make her engineering contributions visible in the right context. Start picking up tasks on the engineering backlog. Get her code into the codebase, not just into customer-facing prototypes. Build credibility with the people who would eventually be her peers.

I also suggested she build a relationship with a nearby engineering team and start contributing to their work in her off hours. Those contributions go a long way towards building trust, and if she does good work for them, the next time they have headcount available, she’ll be the person they think of. It’s extra effort, and it means your work-life balance shifts for a while. But there’s a difference between an unsustainable grind and a conscious, temporary investment in a plan you believe in. When you’re making a change on your own terms, that extra work doesn’t feel like a burden. It feels like building something.

The second move, once she was established as a software engineer, would be to get closer to the health space. There were health-adjacent teams in her local office. Not the exact team she wanted to join, but teams working on things like fitness tracking or cloud services for healthcare providers. They weren’t her destination, but they were a lot closer than where she was now. This might even be a two-part move: first into an SWE role on her current team, then a lateral transfer to one of those local health-adjacent teams. With an engineering role already in hand, that lateral move becomes a natural step rather than a leap. And her internship background in healthcare technology becomes an asset in the conversation, not a footnote on a resume that’s asking for too many things at once.

The third move, once she was on a health-focused engineering team with a track record, would be the international transfer. At that point, she’s not asking a manager in another country to take a chance on someone changing roles, changing domains, and relocating all at once. She’s a software engineer on a health team who wants to continue that work in a different office. That’s a much easier conversation.

Each step captures real benefit along the way. After the first move, she’s a software engineer. That’s not a waypoint, that’s a career milestone. After the second, she’s working in healthcare technology, which is what she’s passionate about. The international move becomes the capstone, not the foundation.

The Long Game

I shared my own experience with her, because I think it helps to hear that this kind of sequencing isn’t just advice I give. It’s how I’ve navigated my own career. When I decided to move from leading large teams back to an individual contributor role, I didn’t just resign from management one morning and start writing code the next. It took years.

I started by slowly shrinking my management scope, which gave me more time for technical work. I began contributing to open source projects, rebuilding muscles that had atrophied during years of calendars full of meetings. Then I moved into technical projects at work, building credibility as a builder alongside my leadership responsibilities. Only after I had demonstrated that I could do the work, and that I wanted to do it for the right reasons, did I make the formal transition.

It wasn’t fast. But at every stage I was capturing benefit. I was learning, contributing, and building the case for the next step. And because I had a plan, the waiting didn’t feel like stalling. It felt like progress.

Goals That Actually Work

The temptation to change everything at once comes from a good place. It comes from clarity about what you want. But clarity about the destination isn’t the same as clarity about the route. The best career plans I’ve seen, both in my own life and in the lives of the people I coach, are the ones that break a big ambition into a sequence of achievable moves, each one valuable on its own.

This is actually where our conversation started. Before we talked about sequencing or strategy, I asked her one question: “What needs to be true to allow you to make this move?” That’s the question that unlocks everything. Write down where you want to be, then work backwards. What needs to be true before you can get there? What needs to be true before that? Keep going until you arrive at something you can start doing next week.

My mentee left our conversation with the same ambition she walked in with, but now she had concrete goals and a sequence of moves to get there. Step one was already something she could act on Monday morning. That’s the difference between hope and a strategy.

A spotlight shines on a pianist intensely playing a small, worn piano on a large, dark stage.

The Koln Concert and Creative Constraints

Allen Hutchison2 Comments

This week I was reminded of a story I like to tell, and the value of constraints on creative work. When I’m working, I often set my constraints before I begin. For example, on an old agentic coding project, I set a few constraints: “The orchestration model must be Gemini Flash,” “All tool calls are through sub-agents,” and “Permissions and configurability are at the core of the agentic loop.” From that, I ended up with adh-cli, a policy-aware TUI for working with Gemini that inspired many of the features I worked on in Gemini CLI last year. The project itself is defunct now and not maintained, but the constraints gave me a great way to think about the project and forced creativity in other areas.

We run into constraints in many different ways. Maybe it’s time pressure: How many of you felt like you wrote your best papers 24 hours before they were due? Maybe it’s the environment, like you must integrate with a certain piece of software, or you have to design your system in a certain way. Maybe it’s self-imposed like my example with adh-cli.

Or maybe the constraint is philosophical. Take Mario Zechner’s Pi Agent, for example. In a blog post, Zechner expressed frustration with the bloat of modern AI coding assistants that try to do everything, describing them as “spaceships with 80% unused functionality.” In response, he built Pi around an “anti-framework” philosophy of radical minimalism. He intentionally constrained his default coding agent to just four fundamental tools: read, write, edit, and bash. By stripping away the hidden system prompts and unpredictable context injections, the tool forces developers to be intentional. It proves that you don’t need a massive, opaque framework to build highly capable AI workflows—sometimes, fewer tools create a sharper focus.

Whether it’s a self-imposed architectural rule or an anti-framework philosophy, these software constraints force us out of our default habits and into a space of deliberate, intentional design. Yet, in our day-to-day work, constraints are rarely celebrated. In fact, that is actually how I end up in constraint conversations the most often: people don’t like their constraints because the constraint has been imposed on them externally. They see it as a restriction instead of a way to channel their creativity. To me, a constraint means that we shut down a huge portion of the exploration space. I don’t have to worry about a million different architectural choices because the constraint has made the decision for me. It is incredibly freeing. Whenever I try to help someone turn around their mindset—from fearing or being frustrated by constraints to being excited by them—I inevitably end up telling them the story of Keith Jarrett and the 1975 Köln Concert.

In 1975, a 17-year-old jazz fan named Vera Brandes organized a late-night concert at the Cologne Opera House. She managed to book Keith Jarrett, one of the most notoriously perfectionist jazz pianists of his generation. It was an ambitious undertaking, and almost immediately, it turned into a disaster.

Due to a backstage mix-up, the venue provided the wrong piano. Instead of the premier concert grand Jarrett requested, he was presented with a small rehearsal model. It was horribly out of tune, the pedals stuck, the high notes sounded tinny and harsh, and the bass lacked any resonance. Jarrett, exhausted and suffering from back pain, flat-out refused to play. It was only when Brandes followed him out into the pouring rain and begged him that he relented, taking pity on the teenager. “Never forget,” he told her. “Only for you.”

What happened next is legendary. Forced to play an unplayable instrument, Jarrett had to completely abandon his usual style. Because the high and low registers were awful, he confined his playing strictly to the middle of the keyboard. Because the piano was too quiet to fill the 1,400-seat opera house, he stood up and hammered the keys with immense physical force. To make up for the lack of resonance, he relied on rolling, repetitive, hypnotic rhythmic patterns in his left hand.

He embraced the limitations, and in doing so, he produced absolute magic. The recording, The Köln Concert, went on to become the best-selling solo jazz album in history.

I think about the Köln Concert all the time, especially lately as we navigate the current landscape of Artificial Intelligence and software architecture.

The Bloat of Infinite Resources

In modern software engineering, we are rarely handed a broken piano. We operate in an era of perceived infinite resources. Cloud computing gives us endless horizontal scaling. Context windows for Large Language Models have ballooned from a meager 4K tokens to 1 million or more. If an application is slow or an agent isn’t performing well, the default instinct is to throw more compute, more memory, or a larger model at the problem.

But infinite resources often breed intellectual laziness. When you have a 1-million token context window, you don’t have to think critically about what information actually matters. You just dump the entire codebase or the entire library of documents into the prompt and hope the model figures it out. It’s the equivalent of having a perfect Bösendorfer grand piano and just mashing all the keys at once.

A pragmatic engineering manager might push back here: Developer time is expensive. If I can solve a problem today by dumping an entire codebase into a 1-million token context window, isn’t throwing compute at it just good business?

It’s a fair question, and engineering is always about tradeoffs. But the tools have evolved—building a RAG pipeline doesn’t take a week anymore; with the right utilities, it takes minutes. More importantly, relying on infinite resources often hides long-term costs. When I built adh-cli, I made an explicit tradeoff: by routing everything through tightly scoped sub-agents, I was actually consuming more total tokens than a single massive prompt would use. But because my constraint forced me to use a much cheaper model (Gemini Flash), my bet was that the overall system would be far more cost-effective and resilient. AI doesn’t remove the need for architectural judgment; it exponentially increases it. You have to exercise good judgment to know when throwing compute at a problem is a calculated business decision, and when it’s just masking a fragile design.

The Innovation of Constraints

The most interesting work in AI right now isn’t happening where resources are unlimited. It’s happening at the edges, where constraints are severe.

Take local models, for example. When you’re trying to run an LLM on a consumer laptop or a Raspberry Pi, you don’t have the luxury of a 70-billion parameter model. You are forced to use a smaller, quantized model. This constraint forces you to build better architectures. You can’t rely on the model to “know” everything, so you have to optimize at the edge. Maybe you build robust Retrieval-Augmented Generation (RAG) pipelines. Maybe you implement sophisticated memory retrieval systems to surface exactly the right historical context just-in-time. Or maybe you break complex workflows down into tiny, focused sub-agents, each operating with its own tightly constrained context window. You have to craft highly specific, deterministic prompts.

# Instead of one massive prompt, constraints force modularity
def evaluate_code_chunk(chunk: str, context: dict) -> EvaluationResult:
    """
    A tightly scoped function that uses a small, fast local model
    to evaluate a specific piece of code, rather than dumping
    the whole repo into a massive API call.
    """
    prompt = build_focused_prompt(chunk, context)
    response = local_model.generate(prompt, max_tokens=256)
    return parse_evaluation(response)

Just like Jarrett avoiding the tinny upper register, we learn to avoid the weak points of our tools. We build guardrails. We write cleaner code. We design systems that are elegant because they have to be.

Finding Your Broken Piano

Of course, there is a survivorship bias to the Köln Concert. For every broken piano that produces a masterpiece, there are a hundred broken laptops that just result in missed deadlines. Not all constraints are good constraints. You can’t change the laws of physics, and if a structural limitation is genuinely preventing the work from happening, you have to reevaluate. The goal isn’t to suffer for the sake of suffering. But by starting with strict constraints, you force yourself to explore the boundaries. If you prove a task is impossible under those conditions, you can always loosen the constraints and expand your resources. But if you start with infinite resources, you never learn where those boundaries actually are.

Constraints are not the enemy of creativity; they are its prerequisite. Yes, accepting a severe constraint—especially an external one you didn’t choose—can be incredibly painful in the moment. Keith Jarrett hated his broken piano. He didn’t feel freed; he fought against it until he was forced to adapt. But like exercise or eating your vegetables, the value isn’t in the immediate comfort. It’s about the mindset shift. You accept the constraint to build a muscle, to stay fit, to force yourself to find a new path when the easy one is blocked. When we are stripped of our ideal tools and infinite runways, we are forced to abandon our default habits. Whether it’s the self-imposed design rules of adh-cli, the radical minimalism of Mario Zechner’s Pi Agent, or the physical limitations of a broken rehearsal piano in Cologne, constraints force us into a space of deliberate, intentional action.

If you want to build a truly resilient, innovative system, don’t start with the biggest, most expensive tools available. Start with a broken piano. Artificially constrain your resources. Limit your context window. See what you can achieve with a 7B parameter model instead of a flagship API, or see what happens when you strip your agent’s toolkit down to the bare essentials.

You might just find that the limitations force you to build something far better than you would have otherwise—a system that is elegant not in spite of its constraints, but because of them.

So, look around your current projects. Where are you relying on infinite resources to mask lazy architecture? And more importantly: what constraints have you come across in your own work that felt like a frustrating restriction at first, but turned out to be a blessing in disguise? I’d love to hear your stories.