The Plan Is Not the Work

I recently went through an interview process for a minor Engineering Manager role and did not get it.

The feedback was that I was too theoretical. That is probably fair, at least from their side of the table. I had been given a leadership case study, wrote the response the way I actually think about teams, and then spent the interview trying to explain why I would not walk into a group of engineers and immediately prescribe the whole operating model from the throne.

The interviewer kept coming back to a version of the same question: yes, but what would you do?

Not in the abstract. Not as a principle. Not as a philosophy. What meetings would you run? Who would you talk to? In what order? What would happen on Monday? What would happen on Tuesday? What exact management sequence would you impose on this team so everyone could see that a manager had arrived and was managing?

I kept answering, in different ways, that I did not know yet.

That was not me avoiding the question. It was the answer. I would need to meet the engineers. I would need to understand the work. I would need to see where knowledge actually sat, who trusted whom, where decisions were getting stuck, where the business was creating noise, and which parts of the written scenario were false the moment they touched reality.

Apparently that was not satisfying.

The frustrating thing is that I understand why. Large organisations often want management to be legible before it is useful. They want a plan because a plan can be reviewed, compared, approved, and criticised in a meeting. A plan gives everyone something to point at. It looks like control. It creates the pleasant illusion that the messy future has been converted into a sequence of responsible calendar events.

But the plan is not the work.

The work is what happens after the plan meets the team, the system, the business, the customers, the missing context, the awkward interpersonal history, the quiet resentment, the undocumented process, the overloaded senior engineer, the stakeholder who is unavailable every time a decision is needed, and the technical assumption that turns out to be wrong on the first afternoon.

That is the part I care about.

One of the ideas that has helped me survive in startups is that reality gets a vote. You can walk in with a beautiful operating model, an immaculate delivery plan, and a calendar full of carefully named ceremonies, and by lunchtime on Wednesday the whole thing may be wrong. Not slightly wrong. Structurally wrong. Wrong because the work was not what people said it was. Wrong because the team did not have the capability you assumed. Wrong because the person with the real knowledge was not the person with the title. Wrong because the company described a process but omitted the politics that keep it alive.

This is not an argument against planning. That would be childish, and also a wonderful way to rediscover preventable chaos while calling it agility. Planning matters. Structure matters. Sequencing matters. Meetings can matter if they exist to make decisions rather than perform management for the comfort of people nearby.

The problem is pretending the first plan is more than a hypothesis.

In the case study, I did give a plan. I said I would keep the engineers as one team rather than splitting them prematurely. I said I would start with the CRM work because it appeared more contained, while using a Principal and Senior Engineer to begin discovery on the more ambiguous automation work. That discovery was not meant to be an engineering-only exercise. It was meant to pull the people doing the work into the rest of the organisation early: talking to the stakeholders who owned the outcomes, learning where the real constraints lived, and closing the gap between “the team over here” and “the business over there.” I said I would avoid turning temporary workstreams into permanent team boundaries, because those boundaries calcify into barriers. I said responsibility and authority should stay together. I said the people doing the work should make the meaningful decisions about the work, which only works if they can see enough of the organisation to make those decisions well.

Those are concrete decisions. They are just not the sort of concrete decisions that pretend management happens by reciting a ritual sequence before understanding the room.

The part they seemed to want was more prescriptive. The Monday morning meeting. The stakeholder map. The weekly cadence. The one-on-one schedule. The escalation path. The process document. The visible apparatus of management.

I can produce those things. Any competent manager can. The internet is full of templates for them, because humanity discovered bureaucracy and then apparently decided to put it in Notion. But producing those things too early can be worse than useless. It can create a false structure around a poorly understood problem.

If I walk into a young engineering team and immediately tell them how they are going to work, I may get compliance. I may even get short-term order. What I will not get is ownership. I will have trained the team that the manager owns the system and the engineers operate inside it. That may feel safer to the organisation, but it weakens the people doing the work.

I do not want engineers waiting for me to define reality for them.

I want engineers who understand the goal, understand their authority, understand the boundaries, and can make decisions without routing every difficult question through management. My job is not to become the lord emperor of Jira. My job is to create the conditions where capable people carry real responsibility because they already have enough organisational context to act, not because I stand between them and the rest of the company.

That sounds theoretical until you have seen the opposite enough times.

The opposite is a team where people are technically responsible but not allowed to decide. The opposite is a senior engineer who must approve everything, becoming both bottleneck and emotional support animal for the delivery process. The opposite is a manager who prescribes workflow in order to look useful, then wonders why the team has no ownership. The opposite is a company where everyone knows the process but nobody feels responsible for the outcome.

This is why I kept returning to the engineers in that interview. Not because I had no answer, but because the answer depends on them. The shape of a team is not independent of the people inside it. A process that works for one group can suffocate another. A meeting cadence that helps one team coordinate can turn into theatre for another. A structure that gives one engineer clarity can bury another in interruptions.

You do not discover those differences from the case study prompt. You discover them by working with the team.

That is the part I have learned the hard way in startups. Startups punish rigid plans quickly. Sometimes brutally. The company is too small to hide dysfunction behind layers of process, and the work changes too fast for a manager to survive on ceremony alone. You have to observe, adjust, simplify, and move. Sometimes the decision you made in the morning is obsolete by the afternoon because a customer, supplier, founder, investor, hardware fault, production incident, or cash constraint has changed the shape of the problem.

This does not mean flailing. It means staying close enough to reality that the plan can change before the damage compounds.

At Refilled, that approach mattered. The company had hardware, software, operations, manufacturing realities, customers, and the usual startup habit of discovering new problems slightly faster than it solved old ones. A rigid management plan would have been ornamental. What worked was keeping the structure simple, giving engineers real ownership, paying close attention to the work, and adapting as the problem changed.

The through-line was keeping engineers connected to the rest of the organisation. Sometimes that meant translating messy business pressure into clear goals and constraints so they could act without guessing. More often it meant bringing them directly into the business context because the knowledge they needed was sitting outside engineering, and I was not going to become the permanent bridge. Sometimes it meant letting them choose the tool, the method, or the sequence because they were closest to the work. Sometimes it meant stepping in because the space between teams was becoming messy and somebody needed to turn organisational fog into decisions.

The pattern was not random. It was adaptive.

That’s probably be the part I failed to communicate.

When someone asks, “What would you do?” they may be asking for confidence. They may want to hear that you can impose order. They may want a manager who arrives with a known playbook and applies it cleanly enough that the organisation feels safe. In that environment, answering “I need to work that out with the engineers” can sound evasive, even when it is the most honest answer in the room.

It can sound like theory because it does not satisfy the desire for visible control.

But a manager who refuses to prescribe too early is not necessarily passive. They may simply understand that premature certainty is expensive. They may understand that a team is not a spreadsheet, that people are not interchangeable resources, and that the written shape of the problem is rarely the real shape of the problem.

There is a skill in being dynamic that is hard to describe because it looks like judgement from the inside and vagueness from the outside. Ask a fish how it swims and you may get a useless answer. Not because swimming is simple, but because the fish has integrated the motion so completely that explaining every micro-adjustment becomes awkward. It responds to pressure, flow, balance, and resistance without writing a framework about water first.

That is not an excuse for being unable to explain yourself. If anything, it is the opposite. If you cannot explain your judgement, people will assume you do not have any. That was probably my failure in the interview. I tried to justify adaptation with principles when the interviewer wanted to see the mechanics. I described why I would not prescribe too early, but did not make the adaptive process legible enough.

The better answer would have been something like this.

In the first week, I would meet the engineers individually to understand what they think the work is, where they believe the risks are, what decisions are currently unclear, and what they think is slowing the team down. I would talk to the relevant business stakeholders to understand what outcome actually matters, what deadlines are real, and what consequences exist if the work slips. Then I would stop mediating those two conversations as separate briefings and put the people doing the work in contact with the people who own the outcomes, so context does not have to live only in my head. I would look at how the team currently tracks work, how decisions are made, where production ownership sits, and whether the current structure supports or fights the work.

Then I would bring the team together around a small number of immediate decisions: what is the current goal, who owns which part, what do we need to learn first, what can be delivered earliest, and what should not be started yet. From there, I would set the lightest structure needed to keep those decisions visible. Not because meetings are sacred. Because ambiguity needs somewhere to go before it becomes politics.

That is a plan. It is just a plan for discovering the right plan.

Maybe that is incompatible with some larger organisations. Maybe they need managers who can walk in with a standard operating model and apply it consistently across teams. There is value in that. Repeatability matters at scale. Large companies cannot have every manager inventing reality from scratch, because then the organisation becomes a federation of personal styles held together by expense approvals.

But I do not think adaptability is incompatible with larger organisations. I think it has to be translated better. The larger the organisation, the more important it becomes to distinguish between principles that should be stable and practices that should respond to context.

Stable principles: authority and responsibility stay together. The people closest to the work make meaningful decisions. Teams need clarity, trust, and ownership. Teams stay connected to the outcomes and people outside engineering; the manager is not the only bridge. Business context should be converted into usable goals and constraints. Structure exists to help the work, not to prove management is happening.

Adaptive practices: which meetings exist, how often they run, who attends, how work is tracked, how discovery is handled, how much process is needed, and where the manager should intervene.

That distinction is the operating model.

The mistake is treating flexibility as lack of structure. The opposite is true. Real flexibility requires a stronger internal model, not a weaker one. Anyone can follow a fixed playbook. The harder skill is knowing which parts of the playbook matter, which parts are cargo cult, and when reality has changed enough that continuing to follow it becomes irresponsible.

The interview did not go my way. That happens. Not every organisation wants the same kind of manager, and not every manager explains themselves well under pressure. The useful part is that the rejection exposed a gap between how I operate and how I describe that operation.

I do not want to be the manager who walks into a team and tells everyone how they are going to work before I understand what I have walked into.

I want to be the manager who can enter an ambiguous environment, find the real constraints, build trust with the people doing the work, create enough structure to move, and keep adapting as the plan collides with reality.

That is not the absence of management.

That is the work.