the translator's job

every year, around this time, planning season opens. it’s not one meeting — it’s a string of them, calibrating our list against everyone whose work touches ours. new features and modernization items end up on the same list. the features sell themselves — somebody wants the thing, and we’re going to build the thing. the modernization items are where it gets harder.

it’s not that the people in the room don’t care. it’s that what we put in front of them is a list of cve numbers, end-of-life dates, version strings, and architecture diagrams. the people on the other side of the table are smart, and they know what they don’t know. what they don’t know is whether any of this matters as much as we say it does. so they nod, and they trust, and three weeks later the modernization theme is the first thing trimmed when something else needs the capacity.

for a long time i treated this as a stakeholder problem. they didn’t get it. we needed better executive comms. we needed a steering deck. none of that was wrong, but none of it was the actual problem.

the actual problem was that i was the only person in the room who could feel the why, and i hadn’t given anyone else a way to feel it too.

what changed for me was metaphor. not every metaphor, though. we’re building the plane while flying it, the cloud is just someone else’s computer, microservices are just lego blocks — catchy, memorable, almost useless. they get repeated in slide decks and don’t survive contact with the actual question. they’re metaphor-shaped, not metaphor.

the kind i mean compresses a piece of technical reality into a shape a brain that doesn’t live in code can hold and reason with. a good metaphor doesn’t simplify the work. it simplifies the stakes.

modernizing a platform is renovating a building while it’s occupied

when we say we need to spend a quarter migrating a core platform, what we’re really saying is: the foundation underneath everything we ship is aging, and we have to replace it without asking anyone to move out. it’s slow, it’s expensive, and most of it will be invisible from the outside. the work doesn’t make the building taller. it makes sure the building is still standing in five years. the alternative isn’t not doing the work — it’s the floor giving out at a moment we don’t get to choose.

observability is the dashboard the service didn’t come with

without observability, running a service in production is like driving with the dashboard blank. the engine runs. the wheels turn. but you can’t see your speed, your fuel, or your temperature. you only find out something’s wrong when the car stops or smoke starts coming up from the hood. with observability, the dashboard works. same engineers, same on-call rotation — dramatically faster, dramatically less wrong. the investment isn’t in tooling. it’s in not flying blind.

a hardened base image is the same crate with fewer doors

a standard container image is like moving into an apartment the previous tenant left fully kitted out — every appliance, every gadget, every tool they ever owned. you get what you need plus a hundred things you don’t, and every one of those is a door someone could come through. a hardened image is the same apartment with only the appliances your application actually uses. less to break. less to patch. when something does need patching, the people maintaining the place show up faster, because the place is smaller.

the metaphor isn’t the point — the foothold is

the foothold has to be something the other person has already lived through. nobody has to explain renovation, or what the dashboard is for, or what it’s like to inherit somebody else’s clutter. they already know those things are miserable and necessary, and they know the cost of skipping them. that’s the part you’re borrowing.

none of these metaphors are precise. a platform migration isn’t really a renovation. a container image isn’t really an apartment. if you push on the analogy hard enough, it breaks. that’s fine. the metaphor isn’t there to be airtight; it’s there to give someone a foothold so they can carry the why with them when i’m not in the room.

that last part is the one i keep relearning. as a technical leader, you are not in most of the rooms where decisions about your work get made. the roadmap discussion happens without you. the trade-off conversation happens without you. the moment when somebody asks do we really need to do that platform thing this year? almost always happens without you. what’s in the room instead is whatever model of the work the other people walked in with.

if that model is a list of cves, the work loses. if the model is a building with an aging foundation and people still inside it, the work has a chance.

the translator’s job isn’t a soft skill bolted onto the technical one. it is the job. the technology is the easy part — somewhere on the team, somebody already knows what to do. the hard part is making sure the people who decide whether we get to do it understand what we’re really asking for.