The One-Person Network: Auditing the Relationships Your Career Can't Survive Without
Photo: DFID - UK Department for International Development, CC BY 2.0, via Wikimedia Commons
Ask a tech lead about bus factor and you'll get a crisp answer. How many people can vanish before the project stalls? Two? Three? The number is usually low, and everyone knows it. Now ask the same person a harder question: if your current job disappeared tomorrow, how many people could actually move your career forward? For most of us, the honest answer is one or two names. That's a bus factor of you, and it's lower than any codebase you'd ship.
The metric you already understand
Bus factor comes from engineering. It's a measure of fragility: how many key people can disappear before the work stops. We audit systems for single points of failure all the time. We add replicas, failovers, backups, and runbooks. We do not do this with relationships. We assume the recruiter who placed us will always pick up, the former manager will always take the call, and the conference friend will always remember us. Then a layoff, a pivot, or a startup failure lands and the assumption breaks.
The dependencies hiding in plain sight
Most tech pros describe their network in vague, flattering terms. Lots of people. Good connections. A strong LinkedIn presence. The actual dependencies are narrower. There is the one recruiter who knows your niche well enough to fight for you. The one former manager who has seen your work up close and will vouch for it. The one conference friend in an adjacent market who hears about roles before they post. The one person who has reviewed your code, your deck, or your startup idea and told you the truth. The one founder who would take your call on a bad day.
These people are not interchangeable. If all five are the same person, you don't have a network. You have a bottleneck. And if that person changes jobs, moves cities, or simply gets busy, your options shrink faster than you'd expect.
The afternoon audit
Block two hours. No apps, no CRM, just a document.
- List 25 people. Not the most impressive names. The ones who would actually reply. Include current and past colleagues, classmates, meetup regulars, open-source collaborators, and yes, a recruiter or two.
- For each person, note how you met, the last real conversation you had, and what they'd plausibly do for you: take a reference call, forward a role, review a deck, make an intro, cofound something, or hire your team.
- Mark the load-bearing links. If you needed a job in 30 days, who are the first three calls? If you needed a design partner for a startup, who are the first three? If you needed honest feedback on a technical decision, who?
- Circle the categories with only one name. Those are your single points of failure.
- Rate each relationship from 1 to 5 on strength and recency. A 5 from 2019 is a 2 today. Time decays everything.
- Pick three gaps. Not ten. Three.
Build two people deep
Redundancy doesn't mean collecting 5,000 connections. It means having two people who could plausibly help in each critical category. Two recruiters who understand your specialty. Two former managers willing to vouch. Two conference friends in adjacent markets. This isn't about using people. It's about not overloading them. One person cannot be your entire safety net, and it's unfair to ask.
A maintenance schedule that survives real life
Quarterly, 20 minutes. Review the document. Send three notes to people you haven't talked to since the last review. No ask, just a specific memory or a useful link. Put it on the calendar next to your dependency updates. The goal is not constant networking. It's keeping the path warm enough that a crisis email doesn't read like a cold pitch.
When the layoff email lands
If you did the audit, you're not starting from zero. You're working a list. You know who to call, what they've seen you do, and what you need from them. If you didn't, start anyway. The best time to build redundancy is before the incident. The second best time is the afternoon after.
Codebases get backups because downtime is expensive. Careers are the same, only the logs are quieter. Run the audit. Find your single points of failure. Then go make a second connection.
