There is a stretch of a technical career that appears in no job description. It does not start on the day you stop programming, because that day never comes: the code keeps getting written, and on top of that you start deciding the architecture other people will be using for years. From the outside it looks like a wider remit. From the inside it feels more like failing twice instead of once.
In the architecture meeting I think about the component I am not finishing. In front of the editor I think about the structural decision I left half made that morning. There is no point in the day when the feeling is one of being fully where I should be.
I am writing this because senior engineers who have just entered that stretch raise it with me often, and because the usual answer, manage your time better and block out the calendar, does not describe the problem. The problem is not a scheduling one.
What changes is not the job title, it is the yardstick
The title changes overnight. The real change takes far longer, and it is not about learning to draw diagrams or mastering new vocabulary. It is about rebuilding the internal yardstick you use to decide whether you did your job well.
That yardstick was formed over years in a craft with rules of its own. An interface developer knows the day went well because the component works, the test passes, the diff has been reviewed and the contrast is compliant. Those signals arrive the same day and leave little room for argument. When the work becomes deciding which components exist, what contract they offer and what stays outside the system, none of those signals apply, and nothing has taken their place yet.
That gap is the in-between stretch. It is not that both jobs are being done badly: it is that the yardstick of one craft is being held up against the other.
The gap is one of latency, not of level
Writing code has a feedback cycle measured in minutes. The test passes or it does not, the layout holds or it breaks, the review lands the same afternoon. An architecture decision has no equivalent. When I define the API surface of a component, the evidence of whether I got it right does not show up in that iteration; it shows up when the third consumer arrives with a use case I had not anticipated, and that happens months later. In between there is nothing to measure against.
Which is why the discomfort of that stretch reports nothing about the ability of the person feeling it. It reports the distance between how fast the role has changed and how fast the yardstick can be updated, and updating it means repeating the same class of decision several times until it stops looking like an exception. It means seeing, a year on, that the component you designed held up under the change you designed it for. That is flying hours, and no amount of reading brings them forward.
The misreading comes next: if nothing verifiable exists at the end of the day, the conclusion is that nothing was done. It is the conclusion a compiler would draw about a language it does not parse.
Leading signals, so you are not waiting six months
Accepting that the evidence takes time does not mean working blind in the meantime. In a design system there are indicators that move before the final verdict and serve as a reasonable proxy.
The first is how many consumers have had to override a component’s styles instead of using it as it comes. The second is how many exceptions are requested per iteration, and which components they cluster around. The third is how often the same question repeats in the system’s support channel, because a repeated question almost always points at a badly named contract. And the fourth, the fastest to warn you: whether requests ask for new props or ask for composition. When somebody copies the component into their own repository rather than consuming it, the decision has already failed, and that shows up weeks later, not quarters.
None of those four numbers proves an architecture is right. They shorten the cycle enough for the yardstick to have something to train on while the good evidence takes however long it takes.
How I split the week, and what it costs me
For a while I tried to hold both jobs using the working shape of the earlier one: keeping ownership of a feature stream, so as to still have my hands in the code, and fitting architecture into whatever gaps it left. That option has an argument in its favour that I still consider the strongest of the lot: daily contact with production code is the only honest source of information about whether the system is helping or getting in the way.
I dropped it because of its cost. When the person deciding the architecture sits on the critical path of a delivery, structural decisions get postponed until they stop being decisions. They arrive late, once three implementations already contradict them, and what gets signed off then is not a decision but a justification of what other people already built.
What I do now is different. The code I write is prototype and review, never delivery committed to a date. Prototype, to test a decision before proposing it: writing a component twice, with and without the prop under discussion, costs half a day and saves an hour-long meeting that would otherwise have been settled on instinct. And review, so as not to lose sight of what is being built on top of the system. Neither of the two blocks anybody if architecture eats three days of that week.
The cost of this split is real and worth stating: I lose the kind of knowledge that only comes from maintaining code in production for months, the kind that tells you a decision is awkward before you can explain why. I make up for it with reviews and by pairing once per iteration with whoever does maintain that code. I only make up for part of it.
The split holds in an interface team with several consumers of the system and somebody able to finish what I prototype. In a team of three where the architect is also the one delivering, it does not: there the only mitigation that has worked for me is reducing the number of structural decisions left open at once, even when that means leaving parts of the system without a criterion for a while, stated and written down.
When it stops feeling like this
I have no date, and I distrust anyone who offers one. What does change is the question you ask. I stopped asking why I still felt this way and started watching two figures: how many of the architecture decisions I made six months ago are still standing without exceptions, and how long it takes me to settle a decision of the same class compared with the first time I faced one.
When those two figures move in the right direction, the discomfort stays around for a while longer. The difference is that from that point on it no longer describes the work: it describes a habit of measuring that has not been updated yet.