From the Help Desk to the Committee

I spent my first years on technical support and systems operations, and what that gives you is not the technical knowledge — most of that is obsolete now. It is that you have watched, hundreds of times, the gap between what a person says is broken and what is actually broken. Someone tells you the system is down. It is not down. Their password expired, or a printer queue is stuck, or a colleague changed a shared file. Learning to hear the difference without making the person feel stupid is a skill I have used in every meeting since, including the ones with no computer in the room.

The second thing it gives you is a calibrated sense of how software behaves in the hands of people who did not choose it. Every design decision I have taken since has been quietly checked against that memory. Whatever you build, somebody will use it at the end of a long day, under pressure, without reading anything, and they will do the thing you assumed nobody would do.

What the frontline does not teach is how to say no, because your entire job is to say yes and then make it true. That habit takes years to unlearn and it is the first thing that limits people who are good at support. You will be promoted for saying yes and then measured on a portfolio where saying yes to everything is the failure.

If you are there now, I would tell you to keep a private list of the requests you could not fulfil and why. It becomes, without your noticing, the beginning of a service catalog and the beginning of an argument about capacity — and both of those are things you will be asked for years later by people who assume you have always thought that way.

The step that changed the most for me was moving into service management and service operations, because it was the first time coordination was treated as a discipline with rules rather than as something helpful people happen to do well.

Before that I coordinated by being available and by remembering things. It worked, and it does not scale, and the way you find out it does not scale is that you become the single point of failure for information nobody wrote down. The discipline replaces you with a structure: a queue with defined states, an owner per state, a classification that means the same thing to two people, and a record that survives your holiday.

What surprised me is how much of it is about language rather than tooling. Half the value of a ticket taxonomy is not reporting; it is that two departments finally use one word for one thing. I have since watched large programs lose weeks to two teams meaning different things by ready, and it is the same failure at a bigger scale with more expensive people involved.

The honest cost of that step is that you spend less time solving and more time defining, and if you took the job because you like solving, the first year feels like a demotion. It is not. It is the difference between being the person who fixes it and the person who makes sure it stays fixed after you leave the room — and only one of those two is a job you can still be doing at forty.

Between technical roles I spent a period as deputy general manager of an insurance agency — running the business rather than its systems. On a résumé it reads like a gap in the line. It was the most useful thing that happened to my technical career, and I would take it again.

Sitting on the business side, you discover that technology arguments you found self-evident are not arguments to anybody else. You watch a manager choose a slower manual process on purpose because the fast automated one produces a number they cannot explain to a client. You see a budget where your entire annual request is one line among fifteen, and the fourteen others also have people behind them who believe in them. And you learn what a month-end actually feels like from the side that has to close it.

It changed how I write. Every technical proposal I have written since begins with what stops or improves for the business, not with what the system will do, because I have been the person on the other side of that paragraph and I know which half gets read. That is not a communication technique. It is having been there.

If a step like that is offered to you, my advice is to take it and to be explicit that you are going to come back. The risk is real — two years away from the tools are two years of drift — but the compensation is that you stop being the person who has to be translated for, and there is no course that does that.

Supervisor, then manager. On paper it is one promotion. In practice it is the hardest transition in the sequence, because it is where the thing you are rewarded for stops being the thing you are good at.

As a supervisor I still did the work and checked other people's. As a manager the work was done by people whose choices I would not always have made, and my job was to be answerable for the outcome anyway. The instinct to take the keyboard is overwhelming and it is almost always wrong: you fix one thing and you teach the team that the way to get something difficult done is to wait for you to be free. I did that more than once before I understood what I was training.

What replaces it is unglamorous. You write things down. You make the standard explicit so that a review is against a standard rather than against your taste. You decide, deliberately, which mistakes you will let happen because the learning is worth more than the rework — and you tell nobody outside the team which ones those were, because from the outside all mistakes look the same.

The part nobody warns you about is that your feedback loop gets much longer. On the frontline you knew within an hour whether you had done well. As a manager you find out in a quarter, sometimes in a year, and often only when somebody leaves or stays. Learning to work without that fast signal is, I think, the actual skill of the level.

Heading a technology function is a different job from managing one, and the line between them is the budget. Before it, you argue for resources. After it, you allocate them, and every allocation is a refusal of something else that somebody wanted.

What surprised me is how quickly it stops being a financial exercise and becomes a communication one. The number itself is rarely the argument. The argument is whether the room believes your account of what the number buys, and that belief is built in the quarters before the meeting, out of small accurate statements about things that went well and things that did not.

The second surprise was how much of the role is sequencing other people's calendars rather than technology. When I held the technology function of a holding group across several operating entities, most of what determined whether a program landed was whether the right person could decide in days rather than weeks. That is not a technical constraint and it is not in any architecture diagram, and it is the one I now ask about first.

And you learn that ending things well is part of the job. Mandates close, groups pause change programs, priorities move for reasons that have nothing to do with you or your team. Handing over cleanly — a documented estate, named owners, no undocumented dependencies on your own memory — is the last professional act of the role, and the one people remember longest, because they meet it after you are gone.

I co-founded a company and built a product while holding executive technology roles elsewhere, and I run an independent practice alongside both. Doing that honestly requires one rule above all others, and it is a boundary rather than a technique: the advisory scope and the operator accountability never touch. Different clients, different hours, and nothing from one desk decided at the other. If you cannot draw that line cleanly you should not take the second chair, and saying so publicly is part of keeping it clean.

What building a product taught the operator role is how expensive a small ambiguity is. Inside a company you can resolve a vague requirement by walking over and asking. In a product, a vague requirement ships, and then it is a support conversation with somebody you will never meet, repeated. That has made me much harder on specifications in my day role, and much more willing to spend an hour now on a sentence that saves a quarter later.

What the operator role taught the product is that features are not the constraint. Adoption is. I have watched genuinely good systems fail inside organizations because nobody owned the change, the training was a slide deck, and the old process stayed available. I now assume that any capability I ship has a companion problem in somebody's organization that has nothing to do with the code, and that assuming otherwise is the most common way a good product disappoints.

The cost is real and I would not recommend it lightly. Two chairs means neither gets your best hour every day, and the compensation is that each keeps the other honest — the product stops you theorizing about operations, and the operating role stops you believing your own launch copy.