Berlin, late 2013. SoundCloud was spread across different offices around the city, and sometimes you had to take the U-Bahn just to go from one to another. Most of my teams occupied an entire four-story apartment building, where we had converted the living rooms of maybe eight units into shared work areas and fashioned the bedrooms into meeting rooms.

I ran up to the top floor of that building, which we called Moonbase, for a meeting with my boss, Eric, founder and CTO. He had just come back to Berlin after a few weeks in the US, and I had a list of things I wanted to talk to him about. I wanted concrete details about our new monetization strategy, the latest on a possible acquisition he had gone there to assess, and anything else brewing at the company level that might affect my division. I knew some version of all of this would eventually cascade down into priorities for my teams, and I wanted enough context to get ahead of it.

After the usual “how was your trip” small talk, I jumped into my list. Eric stopped me with his calm demeanor and said, “Phil, wait. There’s something I want to talk to you about first. You know, I was checking out a Best Buy in New York and, man, everywhere you go you see speakers with a big ‘powered by Spotify’ sticker. How can we get into that?”

I couldn’t believe what I was hearing. I already had three times more high-priority projects than people to work on them, several tied to contractual deadlines around the major-label launches we had been working toward for years. And now he wanted to put yet another thing on my plate?

I then reached for a tool I had learned from a decade of dealing with ThoughtWorks clients. “Oh, sounds great, Eric. I’d love to do that. I just need to know which of these projects”—I opened my very well-organized, color-coded project portfolio spreadsheet—”you want me to deprioritize to make room for it.”

I could see the frustration on his face at what I thought was a perfectly practical response. “Well, we can talk about it later I guess. What else did you want to chat about?”

We went through my list. We never talked about the speakers again.

I worked closely with Eric over the five years I ran engineering at SoundCloud, but this is probably the interaction I think about the most. For years I remembered it as a good example of me being right.

And in a sense it was, as our capacity was genuinely limited and adding a new project was going to require something else to give. What took me a long time to realize is that Eric wasn’t handing me a project.

He had just told me about a strategic opportunity. Spotify was no longer just an app—it was becoming a feature of the hardware people bought to listen to music, and we weren’t on any of it. He was inviting me, as the senior engineering leader, to help figure out whether that mattered and what we could do about it.

That kind of conversation is the actual job of a senior leader, where they add the most value, and I had made myself too busy to have it. For someone who likes to say that engineering exists to create optionality for the business, I certainly made a fool of myself.

Dude, where’s my time?

The reason I didn’t have time to even entertain Eric’s idea wasn’t that I was hands-on coding or running projects. We already had well over a hundred engineers and a healthy ratio of managers to teams.

I have always been direct with engineering managers that their job isn’t just to act as amateur life coaches; it’s to build and manage their team’s delivery machine. And by most measures, that was working. My involvement in the day-to-day execution of most projects was minimal, and I had built a solid project portfolio management discipline around the rest.

What was consuming me was everything that didn’t fit neatly inside one of those teams.

I had to be the tiebreaker in turf wars between infrastructure and development teams almost daily. I had to resolve cross-team priorities ad hoc as projects collided with each other. I had to make staffing decisions on the spot. I had to decide whether we were going to sign with this vendor or that one.

And each of those decisions cost much more than the meeting itself. If I didn’t want to give people drive-by opinions, I had to spend time understanding the problem, talking to the people involved, reading whatever material existed, and acquiring enough context to actually be useful.

I had gotten good at building delivery machines that didn’t need me to operate them. The machinery inside the teams worked. The machinery between them didn’t. And whenever it failed, I was the mechanism we used to compensate.

None of these were fake problems. They were real decisions, often consequential ones, and in every case I was accountable for the outcome. That is exactly why it took me so long to see the pattern: there was almost never a moment when somebody brought me something that sounded obviously solvable one level down.

But almost none of them were strategic. For a senior leader, every tactical decision that reaches you simply because it has nowhere else to go is a defect in the organization you are building.

So what do we do with a defect?

I use the word defect deliberately, not because every escalation is a crisis, or because a well-designed organization never sends tactical decisions upward. I mean it roughly in the same sense as a bug or technical debt: something about the system is behaving differently from how you intended, and that fact needs to be acknowledged and managed.

It does not necessarily need to be fixed, immediately or ever. Sometimes the right thing is to attack the root cause. Sometimes treating the symptom is enough. Sometimes you knowingly live with it for a while. What matters is that you notice it and make that choice deliberately.

This is especially useful for senior leaders, because senior management has terrible feedback loops. There is no dashboard telling you that your organization is 23% too dependent on you, or that a team technically owns an area but doesn’t believe it has permission to make decisions about it. Often the first observable signal is simply that another question has landed on your desk.

I started treating those moments as telemetry.

I might still make the decision. I might spend ten minutes on it and conclude that fixing the underlying problem would cost ten times more than continuing to deal with it. But I want to notice that it happened, and ideally understand why. Over time, the defects give me a picture of the organization I actually built, rather than the one my org charts, project spreadsheets, and carefully designed processes tell me I built.

Where the defect actually lives

Understanding why is harder than it sounds, because escalations rarely surface where they come from. So before fixing the escalation in front of me, I try to answer a different question: what is it about this organization that made this decision require me?

Over the years, I’ve found that a surprisingly small number of anti-patterns account for most of these issues. Here are some of the most common:

There is no owner

Meetup, 2018. I was the Senior Director responsible for Platform and Infrastructure, in the middle of a replatforming whose direction had been decided before I arrived. The new architecture was serverless-native, built heavily around AWS Lambda, and at the time moving a fifteen-year-old application onto serverless infrastructure was not exactly a well-trodden path.

There were a lot of questions and nobody had the role to make cross-cutting decisions, so they climbed until they reached me. Every team was learning the new model while still owning delivery, and they made reasonable calls as they hit them, but nobody had the job of stepping back to work out how those calls fit together.

For the first few months I treated that as my job. Then, having learned something from the SoundCloud days, I recognized what was happening: I had become the stand-in for an ownership gap, and it would happily consume whatever time I gave it.

This is the kind of gap organizations try to fill with process and committees. If nobody owns architecture, create an architecture review. If nobody owns FinOps, create a committee. But a process can support an owner; it cannot replace one. A review can challenge decisions and a committee can collect perspectives, but neither wakes up in the morning thinking about where the thing needs to go.

I didn’t have headcount for the obvious solution, so I split the gap in two.

Developer experience was a domain I knew well, so I became its part-time owner and established a playbook the teams could work from. Serverless was different: I knew enough to understand the questions, but nowhere near enough to answer them from experience. So I brought in someone I had worked with before and trusted deeply in the area, for a part-time engagement to work with our engineers and establish the principles we could operate from.

You don’t necessarily need a new team, or even a full-time person. You need somebody with enough expertise, time, and authority to develop a point of view about the whole problem rather than answer decisions as they arrive. Maybe that’s a hire. Maybe somebody takes it on part-time. Maybe you borrow an expert, or take it on yourself—as long as somebody actually takes the role, rather than just fielding the questions one by one.

Decision rights are unclear

At PicPay I was CTO of an organization with over 800 engineers, and it was probably the job where I was furthest from the day-to-day work. I had the usual portfolio mechanisms to understand what was happening, but I was rarely involved in the tactical decisions of individual projects.

That worked fine everywhere except one place. I kept getting pulled into the new API Gateway project, sometimes to decide how we were going to paginate results or which time format to use.

At first I worried that this was a diffusion-of-accountability problem: if I personally approved a decision, nobody could later blame the team for it. So I asked the project manager and engineering manager what was going on. I was happy to be accessible and help when useful, but I thought these were their decisions to make.

Their answer was much simpler. The team was using the Backend-for-Frontend (BFF) pattern, something I had helped develop and write about years earlier, and because I had such a personal history with the architecture, they assumed I would want to stay close to it.

That was perfectly reasonable. I had already done a Q&A with the team about the history of the pattern and some of the context that never made it into the articles, and I had told them I was available to spar on ideas. What I had failed to make clear was that being available for context was very different from being an approver.

So we made the decision boundaries explicit. I worked with the managers on a very light RACI-like matrix spelling out the kinds of decisions I expected to be involved in, the ones where they might want my advice, and the ones that were simply theirs.

An org chart can tell somebody that they own a project and still leave them guessing about what ownership actually allows them to do. Saying that teams are “empowered” isn’t enough; people need to understand where their decision rights begin and end.

Being accessible is great, but being required is a defect.

Ownership is fragmented

Back at SoundCloud, one of the things consuming an absurd amount of my time was the relationship between Product Engineering and Infrastructure. It was, in fact, one of the things I was carrying up to Moonbase that afternoon.

Our product engineering strategy rested on breaking the monolith into independently owned and deployed services. That meant any meaningful project needed something from infrastructure: a new database, a new piece of middleware, a new deployment model. Product needed to move fast; Infrastructure was accountable for whether any of it stayed up, which made a more conservative model of how these systems should be operated an entirely rational position.

Neither Product Engineering nor Infrastructure had enough end-to-end ownership to make these decisions alone. Nobody had the authority to say yes, and either side could say no.

Every product team negotiated that boundary independently. An engineer building a Node.js service might find themselves arguing about databases, provisioning, and AWS with an infrastructure engineer, and when they couldn’t agree the disagreement climbed until somebody could force an answer, usually me.

The obvious fix for fragmented ownership is to refactor ownership: redraw the boundaries so that one team owns enough of the value stream to decide on its own. But Infrastructure was a separate division, and I had neither the authority nor the political capital to reorganize somebody else’s org around my architecture.

So I asked a narrower question. How much ownership could I concentrate on my side of the line, so that fewer decisions had to cross it at all?

That became the Platform team: product engineers who could also build and operate infrastructure. Their job wasn’t to relay requests between Product and Infrastructure. It was to take the raw capabilities Infrastructure provided and turn them into self-service primitives my teams could own outright. Provisioning, deployment, and operational patterns stopped being things to negotiate and became things a product team could simply do.

The goal wasn’t to eliminate disagreements, but to constrain the majority of day-to-day project decisions inside a group that could say yes. We still crossed the boundary, and sometimes I still had to break a tie. What changed was the cardinality: instead of dozens of product teams repeatedly solving the same boundary problem, one team solved it once.

The defect was never that Product Engineering and Infrastructure disagreed. It was that our organizational design required the same negotiation to happen dozens of times, with me as the fallback whenever it failed. It took me an embarrassingly long time to see that as a design problem rather than as my job.

Fragmented ownership is nasty because everybody involved can be doing their job correctly. The best fix is to redraw the boundaries so that more of the value stream has one coherent owner. When that isn’t possible, concentrate as much decision-making as you can on either side of the boundary, and make crossing it the exception rather than the routine.

The solution space isn’t bounded

At DigitalOcean, we were trying to change the speed of the entire engineering organization. The company had shipped very little product in the previous couple of years, and I was given the goal of driving five major feature releases in one year.

One of my teams was rebuilding an important system for our sales organization—ultimately an overspecialized CMS, deeply integrated with our internal systems. Conventional work, competently staffed, and exactly the kind of project that should never have needed me.

At the first portfolio review, I discovered the team was using an entirely different technology stack from the rest of the company. The choices weren’t crazy on their own merits, but delivering five releases in a year depended on consolidating around a small set of technologies we knew how to support, staff, scale, and operate without surprises. So I asked them to either migrate to the common stack or write an RFC justifying the exception. “We know this technology better” wasn’t enough to justify a stack the company would have to support for years.

The review caught it early enough that the wasted work was only a few weeks. It should have been a non-event.

Except that after that meeting, the team started bringing me everything. Adding a library. Building a component the design system didn’t have. Releasing something as early access rather than waiting. At first I barely noticed; every question seemed reasonable on its own.

Interestingly, they understood perfectly well that the decisions were theirs. They weren’t asking for approval but rather double-checking, constantly. They had spent weeks making what they believed were perfectly reasonable decisions, only to discover that one of them violated a constraint they hadn’t known existed. Their reaction was rational: don’t let that happen again.

I had told them one point in the solution space was unacceptable. I had never shown them where the boundaries were. We had a product engineering strategy and it was well-known, but too many of its day-to-day implications were still in my head.

So I made the strategy operational: the supported stacks, the trade-offs we were willing to make for delivery speed, the reliability and cost expectations that came with our scale. Then each project had to make its own constraints explicit within that space—what date actually mattered, what budget it had to stay within, which trade-offs were different for this particular problem, and where the team still had complete freedom to choose.

Engineering problems have an effectively infinite solution space. You can build or buy, spend a month or a year, optimize for cost or latency or delivery speed, introduce another database or language or framework. My job as a senior leader isn’t to pick the point in that space but to draw the region and let the team move freely inside it.

When people can only discover the edges by crossing them, they stop moving without checking first. “You’re empowered, figure it out” isn’t empowerment if I’m withholding the constraints I will later use to judge the answer.

Back to Moonbase

None of these fixes were clever. Name an owner. Write down who decides what. Move the boundary or build a better interface across it. Make the constraints explicit. All easy enough to arrive at once you understand the problem. What’s hard is noticing there is one, because every escalation arrives looking like work rather than like evidence.

Which is why I was standing in a converted living room in Berlin with a color-coded spreadsheet, being asked to think about where the industry was going, and answering as though I’d been handed a ticket.

The volume of escalations tells you how much of yourself the organization still needs just to function. You won’t ever get it to zero—strategies change, people disagree, and sometimes somebody senior does have to break a tie. But whatever capacity is left after servicing them is all you have for the actual job: understanding where the business is going, deciding what engineering should be doing about it, and building the organization that can. Nobody escalates that work to you. It only happens if you have the room for it.

What that job actually consists of is a longer conversation, and one for a future article.