Your Career Has a Load Balancer — And You're Probably Not Registered With It

Day 13: Networking Is a Routing Table, Not a Personality Trait

Here's the part nobody says out loud: correctness doesn't get you promoted. It doesn't even get your Slack message answered on time. What gets you unblocked in an hour instead of buried for a week is whether you sit on an edge — whether someone's routing table points at you at all. Be right and invisible, and being right buys you nothing.

The Engineer Who Wasn't the Best Coder

I've watched this play out on every team I've run. Someone gets bumped to staff, and the engineers who write cleaner code, ship faster, and know the codebase better than the promoted person feel robbed. Here's the uncomfortable bit — they're not wrong that the promoted engineer wasn't the strongest IC. But that person was who three different teams pinged the second something broke: infra, data, the PM who didn't even know who else to ask. Everyone's requests routed through them. Sit with both halves of that at once — "that's not fair" and "that's not wrong" are both true. Merit built their skill. Something else entirely built their reach.

Stop Calling It Networking — Call It a Routing Table

Drop the word "networking." It makes this sound like a social skill you either have or fake your way through at a conference. What you're actually building is a routing table: for a given kind of problem, who do you resolve to, and in how many hops? A distributed system with a bad routing table doesn't fail because its nodes are weak — it fails because requests can't find a healthy one in time. Careers break the same way. You can be the strongest node in the entire org and still be unreachable, because nothing points at you.

Why Engineers Resist This

We're raised on a beautiful lie — that the system should route on merit and correctness, full stop. Now look at how production traffic actually moves. A load balancer sitting in front of your inference fleet doesn't send a request to "the most correct model." It sends it to whichever healthy node has capacity and low latency right now, based on health checks it can actually see. Correctness nobody can discover doesn't get routed to — not in a cluster, not in an org. A stuck problem doesn't go to the best-qualified person; it goes to whoever the asker's routing table resolves to first. Refusing to build edges because "the work should speak for itself" is the career equivalent of never registering your service with the load balancer, then wondering why it gets zero traffic.

The Failure Mode: Leaf Nodes

A leaf node has edges pointing out and none pointing in. That's your technically excellent engineer nobody routes to — they can solve the problem, sure, but no one thinks to ask, and nobody says their name in a room they're not standing in. Multi-agent systems hit the identical failure: a genuinely capable sub-agent sitting behind a supervisor that never learned to call it produces exactly zero value, no matter how good it is. Same failure, same fix. The supervisor — your manager, your peers, the org — needs a reason to know you're the shortest path to something specific.

My Own Arc: CTO to EM, and the PhD Side Door

When I was CTO and founder, my network showed up inbound by default. People came to me because of the title on my badge, not because I'd built a single edge myself. Then I stepped into an EM role and started a PhD on multi-agent systems, and that inbound engine just stopped overnight. Before that, I assumed advisor relationships got built at conferences and cold intro emails — high effort, low hit rate, and honestly I mostly avoided the whole ritual. What actually worked was smaller and stranger: replying in depth to niche technical posts on multi-agent coordination and agent-orchestration failure modes. Not small talk — a specific comment on a specific gap in a specific paper. Three of those replies turned into real working relationships. Zero came from an event. The edge formed because I was findable for one narrow thing, in public, repeatedly. Not because I "networked."

The Mechanism: Shortest Path to One Specific Answer

The actual mechanism is narrow, almost boring: pick one specific kind of question and become the shortest path to its answer, publicly and repeatedly. Not "backend engineer" — too broad, too many nodes competing for the same slot. Something specific enough that when the question comes up, exactly one name surfaces.

• ▹"The person who actually understands why our multi-agent handoffs drop context between steps"
• ▹"The person who knows why p99 spikes the moment the agent fleet autoscales mid-burst"
• ▹"The person who can explain exactly what changed in our eval scores after the last prompt revision"
• ▹"The person with an actual opinion on when to use a supervisor-agent pattern versus a flat tool-calling loop"

You build that reputation the same way you'd document an API: consistently, somewhere people can actually find it, specific enough that it's obvious who to route to. A Slack thread you always show up in with a good answer. A niche post you keep circling back to on the same theme. Repetition beats reach — you're not chasing fame, you're trying to be the zero-hop answer for one thing.

This Week: 3 Edges to Build

• ▹Write one niche technical post on the narrow thing you want to be findable for — not a broad take, a specific, opinionated answer to the question your team keeps quietly re-asking.
• ▹Do a five-minute internal reroute: message a peer on another team and point them straight at the right person for a problem that isn't yours to solve. Building routes for other people is the fastest way to become one yourself.
• ▹Close the loop on a stuck problem you already fixed for someone outside your team. Don't wait for them to remember you did it — follow up yourself. That's the edge forming, not just the fix.

Day 14 picks up right here: once you've got edges, how do you tell which ones are worth maintaining and which ones are just noise sitting in your routing table?

Extend your knowledge

• ▹Look up how service mesh routing (health-check-based load balancing in Envoy or Istio) decides where a request actually goes — the same 'discoverable plus capacity, not abstract merit' logic runs your career routing table too.
• ▹Read up on supervisor/orchestrator patterns in multi-agent frameworks like LangGraph or AutoGen — the routing failure where a capable sub-agent never gets called is the exact same shape as the leaf-node problem above.
• ▹Audit your last 90 days: list every time someone routed a problem or an opportunity to you without being asked. Short list? That's your leaf-node signal — not a verdict on your skill.
• ▹Pick the one narrow thing from your own work you could become the zero-hop answer for, and draft the niche post from this week's action item.