The Day You Stop Writing Code Is the Day the Job Gets Harder

I kept my lab environment running for fourteen months after the last time I legitimately needed it. Every few weeks I'd rebuild something in it at half past nine at night, tell myself I was staying current, and go to bed feeling like an engineer again.

It wasn't about staying current. It was the only place left where I could tell whether I'd had a good day.

As an engineer you had a scoreboard and it updated constantly. Tests went green. The ticket closed. The config pushed and the link came up. You went home on a Thursday knowing, with something close to certainty, whether Thursday had been any good.

Then you get the team, and on your first proper Friday you sit there and genuinely cannot answer the question "what did I do this week". You were in meetings. You unblocked something, maybe. You had a conversation with someone about their workload that might matter a great deal or might have been nothing. There is no green tick anywhere in any of it.

This is the part that makes people miserable, and it gets misdiagnosed. People think they miss coding. Mostly what they miss is feedback. Engineering gives you feedback in minutes. Leadership gives you feedback in quarters, and some of the most important things you'll do this year you will never get feedback on at all, because a problem that didn't happen doesn't send you a thank you note.

You have to build your own scoreboard, deliberately, because the job no longer supplies one. Mine is three lines on a Friday: what moved this week because I was here, what's now unblocked that wasn't on Monday, and who is further along than they were. Some weeks it's blank. A blank week is information, not a failure, unless there are four of them in a row.

Within about eighteen months you'll be in a design review where someone you hired explains an approach you don't immediately follow, using a tool you've never used, and they'll be right.

The instinct is to hide it. Nod, go and read about it at eleven that night, turn up next week with an opinion. I did that for longer than I'd like to admit, and it costs you far more than the thing you were protecting.

Try the other thing. "I don't know that tool well enough to have a view. Walk me through the failure modes." You've just done three useful things at once: you got the information you actually needed, you told the room that not knowing is allowed here, and you modelled the behaviour you want the moment somebody is out of their depth on a Sunday during a cutover.

Your technical credibility doesn't vanish. It changes shape. You stop being the person with the deepest current knowledge and become the person who asks the question that saves the design, which is usually about operations, failure, cost, or who supports this in two years. Those questions don't decay the way tool knowledge does. They get better with every project you've watched go wrong.

An automation team of seventeen engineers at a credit bureau, three squads, with a lead who had come up through the deepest part of the estate and was unquestionably the strongest engineer in the building.

He kept the hard work. Not all the work, just the genuinely difficult pieces, because he could do them in a day and a half and anyone else would take five. Every individual decision was defensible. You can do the arithmetic and he was right every time.

What that produced, after about eight months, was a queue. Anything genuinely hard waited for him, and he was in meetings for most of the week, so "waiting for him" averaged two weeks. Three squads, and the interesting work in all three of them routed through one person's Thursday afternoons.

Two things followed. The senior engineers who wanted the hard problems left, because there weren't any, and when he went on leave for a fortnight the whole thing simply stopped. Not degraded, stopped, because the only person who knew how the trickiest part worked was on a beach.

The arithmetic that matters runs longer than one task. You're three days faster than them once. The fifth time they do it they're as quick as you are, and you've bought back every Thursday afternoon for the next two years. Enabling beats doing on the numbers, not just on principle.

The other thing that arrives with the title is a set of conversations you have no training for, and there's a fair chance you've been quietly dismissive of the people who have them.

You'll be asked why a change costs what it costs. Someone will ask whether the delivery is still profitable and expect you to know. A salesperson will commit to something in front of a client and you'll need to work out, in about four seconds, whether to correct them in the room or afterwards. Contracts, margin, day rates, what a delay actually costs the business rather than the plan.

This is learnable and it's not deep. Find out what a day of your team's time costs the business. Find out whether your current delivery is fixed price or time and materials, because those are different jobs and the second one changes what you should optimise. Ask your finance business partner to spend half an hour walking you through how your project appears in their numbers. They will be delighted, because nobody ever asks, and you will understand more about why the last two decisions went the way they did than any amount of internal speculation would give you.

Technical leaders who can hold both halves at once are rare, and they get listened to in rooms where the deepest engineer in the company doesn't get invited.

There's one piece of technical work you haven't let go of. You know exactly what it is. It's the thing you tell yourself is faster to just do, and it's the thing you'd be quietly gutted to hand over.

Hand it to a named person this week. Not "the team", a person. Tell them it's theirs now, tell them you'll pair on it once and then you're out, and put the date in the calendar so you can't drift. Then leave the lab environment running if you want. Just stop pretending that's where the job is.