The product work that started arriving at my desk

Somewhere in the last few years the decisions arriving at my desk stopped being engineering decisions, and I did not notice for a while because they were still wearing engineering clothes.

Whether a capability gets exposed to the businesses building on us or stays internal. How long a version keeps working after we replace it. What an error is allowed to reveal about what happened inside. Whether a partner’s edge case becomes a feature, a configuration flag, or a refusal. Every one of those has a defensible technical answer, and the technical answer is not the answer, because what is being settled is who may build on us and what we have promised them.

The part my engineering judgement did not cover

I could price all of it technically: what a change costs to build, where it breaks, what it drags behind it, how long it takes. What I could not do, for an embarrassingly long time, was say what we should refuse.

Refusing is a product act. It needs a view of which customers you are for, which you are not, and what you are willing to be worse at than somebody else. I did not have that view. I had a queue and a sense that everything in it was reasonable, which was true and useless. When everything is reasonable, sequencing gets done by whoever asks most persistently, and I let that happen for longer than I would like — not out of indecision, but because I had nothing better to decide with.

What changed it was not a framework. It was writing the refusals down. Once “we are not going to support this” had to exist as a sentence with a reason attached, the reason had to survive being read back a week later, and the weak ones stopped surviving contact with paper.

The refusals that did survive usually rested on something commercial, and that is the part I had to learn somewhere else. I used to treat pricing and packaging as another department’s problem, which meant I proposed technically elegant options that were commercially unserious and could not tell the difference. Knowing enough about margin and channel structure to be argued with changed which of my refusals held up in the room.

The part I have not solved

Customer exposure. I work from summaries, I know summaries are lossy, and I still do not talk to enough of the businesses building on us to have priors of my own about them. I can tell when a summary contradicts something I already know, which is a much weaker skill than being able to tell when it is wrong.

None of this is a claim about where the CTO role is going in general. It describes one job, in a company whose shape made the product decisions unavoidable, and plenty of technical leaders will go deeper into platform and infrastructure instead and be right to. What I now hold is narrower: when implementation stops being the bottleneck, a technical leader who keeps only technical judgement has quietly moved away from where the expensive decisions get made.