The breadcrumbs we leave on the table.

The premise

There are tons of relationship-driven organizations, like ESOs, doing work that depends heavily on the people they’ve built connections to: their network. Despite this, the network management responsibilities for these types of organizations tend to fall to the wayside, both in terms of attention and actual tools to support.

Over the last 3 to 4 months, I’ve been having discussions with leaders in different types of support organizations, primarily entrepreneurial support organizations (ESOs), and I want to use what I’ve learned from those conversations paired with an interview with a thought leader to illustrate these points.

I’ve called on one of our own ecosystem’s best voices, Chris Heivly, to share his thoughts based on the immense amount of work he’s done in these spaces.

Chris and I took some time to talk through these ideas from start to finish: what the actual work of these organizations is, what makes their relationships valuable, why keeping track of all of this gets so difficult, and what might actually change if we could get better at it.

There was one important assumption Chris called me out on almost immediately, though. I was assuming that organizations already understand their network is one of their most important assets.

I don’t disagree with him. That said, this is an entirely different write up in itself. I wrote that separate piece on the “invisible work” of these types of programs alongside this one, and you can visit it here. For this piece specifically though, we’re going to focus on the conversation I had with Chris and the important ideas that came from it.

The real job of a support organization

Ultimately, entrepreneurial support organizations, and similar organizations, are responsible for doing everything they can to build and maintain a network of people (a community) that can help elevate the larger ecosystem that they support.

This idea is clearly supported by the substance of the work that ESOs actually do: accelerators that pair founders with experts on topics, coworking spaces that put founders in rooms with other founders and connections, mentorship programs that pair mentors with people in need, or pitching events that put founders in front of a crowd of people, to name a few.

The people included in this work are the true value of the ESO. If these orgs had empty stages, vacant coworking spaces, and accelerators with no external support, their value would diminish almost entirely.

I asked Chris how he thinks about this distinction between the programming we can see and the network that actually sits behind it.

Chris’s point was that simply collecting connections isn’t really the goal. LinkedIn can tell us that two people are connected, but the value comes from what sits underneath that connection.

Chris broke this into three basic steps: understanding you need to have a network, intentionally building connections, and then making as many of those connections meaningful as possible.

This also means doing a lot of work that doesn’t necessarily generate an immediate visible outcome. I asked him about this because I think it’s one of the harder parts of getting people to actually invest time into their network.

Organizations often under-value the power of building relationships without a concrete ask because they believe that they’ll be able to instantly build or activate the network in the moment, but obviously Chris disagrees with this notion. It’s clear, then, that we must begin building the network before it’s actually needed. Chris described this through Techstars’ idea of “Give First,” while acknowledging there are plenty of other terms people use for basically the same concept.

This creates a challenging situation for the organizations doing this work... They’re left constantly building relationships and learning things from people without necessarily knowing when, how, or even if a specific relationship or piece of information is going to become valuable later. On top of that, they’re expected to build and maintain massive networks for later activation, but our ability as people to actually do this is quite limited. Let me explain.

The natural limits of doing that job

Dunbar’s number

During our conversation Chris called out research that analyzed the number of relationships we can realistically maintain at once. The research he was referring to was by Robin Dunbar. Dunbar came up with something called Dunbar’s number: the idea that a human’s social relationships tend to fall into nested layers.

What this means for ESOs that want to service hundreds, if not thousands, of people through their programming is that, as things scale, our ability to keep track of all of it, without extra systems supporting us, falls dramatically.

There is obviously a gigantic difference between having met 6,000 people and being able to actively remember 6,000 people, why you know them, what they care about, what you spoke about, and why they might be relevant to something you’re working on now. And the challenge goes further than the raw number of relationships we can hold. The important bits of context we pick up from the relationships matter just as much. Chris calls this information breadcrumbs.

The context we lose: breadcrumbs

This idea of breadcrumbs is one of the first steps to having an org’s network survive beyond one person. That said, Chris immediately calls out that it is extremely important to remember that, at the end of the day, the relationship is created between individuals, not orgs.

He used the relationship between the two of us as an example. If I leave NC State, Josh and Chris can still have a relationship. That relationship doesn’t suddenly belong to NC State because that’s where we originally connected. At the same time, though, the organization, ideally, shouldn’t lose everything that it learned or every connection it participated in creating just because I left.

If we want to memorialize and continue relationships beyond the individual who knows of the person, we have to capture actionable context about those relationships that anyone could pick up and use in the future to continue the relationship. Chris calls this context “breadcrumbs”. To dumb it down for me, Chris described us going to Starbucks and talking for an hour.

During that coffee, he might happen to mention that his brother is an AI manufacturing expert living in Toledo, Ohio.

That’s it.

Right there, that’s what Chris calls a breadcrumb. A small piece of information that came from a relationship that could be used at a later date to make some sort of impact, like filling a speaking role, or getting a mentor assigned to a startup, by basically anyone, not just me.

Over the course of the conversation, we might discuss dozens of random things, many of which don’t seem particularly important at that exact moment, but are, inherently, breadcrumbs.

The problem? After talking, we get up and leave, often forgetting these little pieces of context.

When the time comes to activate this context, we have to hope that I just happened to remember it came up. If I’d left NC State and taken that info with me? Even worse: the org now has no way to activate that relationship from context that could have been captured.

What this means for organizations

So the challenge for ESOs is twofold. We’re limited by the number of people we can realistically maintain relationships with naturally, and by how much of the context generated through them can be retained and acted upon.

Surely there’s a solution to these challenges, right?

What’s being done about it today

I asked Chris pretty directly what he thought about the options that exist today.

While straightforward, I think the answer here is true. I’ve seen it first hand, more on that soon. It’s not to say nobody has tried to fix the issues- Chris himself has personally tried to solve this multiple times to no avail.

I think understanding what’s being done today is important when trying to understand how we might chip away at a solution that helps orgs better maintain their networks. So over the last few months I’ve been doing customer discovery interviews and can pretty confidently bucket what current orgs are doing today into 3 slots: trying to keep things in the head, cobbling together information from various locations, and trying to make custom built software.

Kept in someone’s head

Firstly, on the “kept in the head” note, many ESOs, both large and small, are keeping a lot of their relationship based knowledge in the heads of their operators and directors. Across my conversations, almost every single person attested to the fact that there’s a large amount of institutional relationship knowledge in the head of someone they work with. The person is simply who the team goes to for ideas around who to connect with for what.

This is great, but creates a situation where the network of an org is separated across individuals, not shared. It feels like organizations, especially small ones, aren’t seeing their networks as a team resource, so I asked Chris whether he sees organizations thinking about the issue this way or not.

Earlier we spoke about how Chris starts with just getting people to realize there’s a problem here, but after that, and only after that, he says the idea of that becoming a team resource comes to fruition:

This ultimately leads to a team having a split network that’s stored in the heads of teammates, and not anywhere safe or persistent. This becomes an obvious problem when a team goes through a transition, causing a heavy loss of network context, or when a team begins scaling so much that they can’t all track who they know by memory anymore.

Existing software that almost fits

Once teams get to that point where keeping it in the head becomes a big enough problem to warrant change (again, transition or scale), most teams seem to begin trying to get everything organized using a blend of existing platforms designed for general knowledge management and project management, or they’ll default to trying a CRM.

These solutions seem like a Trojan horse to me. They look great on the outside, but once you get into the nuance of how relationships are actually managed, they begin to struggle.

For instance, consider CRMs, platforms designed for “customer relationship management.” At first glance it sounds like a CRM makes total sense, but once one is adopted it becomes clear that the goals of many traditional CRMs and those of an ESO differ greatly.

CRMs aren’t designed for long term management of important key relationships, but rather for moving a large number of individuals through specific funnels. Chris has basically come to the same conclusion.

Building something custom

The last frontier I’ve observed in these teams is giving up on existing tools and using low code / no code tools, and AI coding tools like Claude Code and ChatGPT, to build entirely custom internal tools that help organize their network.

This works excellently for the orgs that have team members who can build them, but there are obviously a huge number of ESO-style organizations with non-technical teams who don’t have the time or technical know-how to build custom internal tooling from scratch.

Nothing quite fits

Wrapping this all together, it’s obvious that organizations and their people are trying different approaches to getting their networking action out of their heads and into a system, but it isn’t so clear that there are any available systems actually designed around the need. This leaves us victim to the two issues Chris and I discussed earlier, the number of people we can know and the realistic amount of context we can retain. Our ability to create, maintain, and activate a network falls dramatically.

So what happens if we could get better at it?

What if the systems were built for this?

The limits that would move

Earlier we discussed two variables that shape an organization’s ability to make an impact: the raw number of relationships it can hold, and the amount of useful information (breadcrumbs) it can extract from that network.

Let’s say I’m a five person ESO and we’re insanely good at networking so we max out the Dunbar number: 150 relationships apiece, zero overlap between team members. Our org might be accessing about 750 relationships at that point.

Now imagine a purpose-built system doesn’t eliminate Dunbar’s limit, but allows each of us to keep enough context around 500 people that those relationships can still be surfaced and reactivated when relevant. Suddenly our effective network isn’t 750 people, it’s 2,500.

Great. But increasing the number of accessible relationships only solves half of the problem. A directory with 2,500 names isn’t useful if all we can hold against those names is an email address and a title.

What if those 2,500 relationships also carried forward the useful context generated through previous interactions? Chris made an important distinction here.

We aren’t just trying to change the amount of meaningful relationships a human can maintain. We’re giving ourselves a way to artificially expand what we can recall at the exact moment we need it, too.

For instance, instead of remembering Joe is an “investor,” we could remember this:

Now we’re talking about scaling both the relationships and the context captured within them. In this world, we’d have more than 3x the relationships available to draw from, with far more context that could be captured and activated to make an impact on programming, mentorship, investment, and more.

What that would change

I asked Chris what he thinks the actual impact of getting this right could look like.

It’s also the entire reason the support organization exists in the first place.

How it might actually happen

This is where I explored some genuinely tough questions with Chris. Do we need founders to build new software? Should organizations just use existing platforms better? Is this not really a software problem at all, and instead organizational leaders simply need to tell their teams that managing the network is part of their job and figure it out?

Chris didn’t pretend there was some obvious answer. He told me he’s given up on finding one several times and defaulted back to things like Google Contacts.

But there is one change that both of us kept coming back to: AI. I almost hate writing that because I don’t want this to become another generic AI article. We’ve had enough of those, but I do feel like there are specific capabilities that are unusually relevant to this problem.

Chris doesn’t know exactly what configuration wins, and neither do I (despite my obvious bet with the work I’m doing with Elephants). It could involve automatically gathering breadcrumbs from recorded conversations. It could involve pulling information from different systems. It could involve simply making an enormous amount of context searchable in a way that wasn’t realistic before.

But the thing to underline, I think, is that AI gives us an increasingly good mechanism for doing something humans are extremely bad at: taking a gigantic pile of unstructured context and pulling the right tiny piece of information back out at the exact moment it becomes relevant. That feels like something we shouldn’t ignore today.

The ask

So what’s the ask? I’m still writing this to make a general call to action. I want us to begin treating relationship infrastructure as seriously as we treat program infrastructure, and for founders and technologists to build tools around the way these organizations actually work.

That said, I think Chris put it simply:

If Post-it notes are legitimately the thing that helps you do this, use Post-it notes. If you want to build your own AI-powered personal CRM, do that. But do something and, importantly, think about it at both the individual and organizational level so these efforts don’t evaporate every 3 years.