CEO Friday: Startup Management as a P2P Network
At some point, a startup outgrows its lack of structure, but isn’t yet ready for the real deal. What do you do? There are some lessons to be drawn from how P2P networks grappled with the same problem.
1. Fully Connected (2-4 people)
When a P2P network is very small, every node sits next to every other node. If there’s something you need, you just directly ask the nodes around you, and they can give it to you in one step. This is akin to the early days of a startup: just turn to the left or right and every problem is solved.
2. Gossip Protocol (5-10 people)
As the network grows, not every node sits next to every other. But this is fine, because the network is still small: even if your peers don’t have the answer, odds are they just need to ask one of their peers, and the answer is found. So every question can be answered in 2 steps, which is still pretty good.
3. Supernodes (10-20 people)
However, as the network continues to grow, sometimes gossip isn’t effective: it’s possible that there are nodes sitting more than 2 steps away. In startup terms, this means peers who are off in their own direction, and nobody knows what they’re doing. But because everybody has already accepted there are things both they and their peers don’t know, it’s easy to assume that somebody else knows what they’re up to — when in fact nobody does. Accordingly, people can be overlooked: they don’t get the support and oversight they need to be effective.
To solve this problem, a small group of well-intentioned employees — generally without any formal acknowledgement — steps up to take on greater responsibility. They don’t have any formal titles; nobody technically reports to them. But everybody knows they are doing far more than being individual contributors: they are “supernodes” who just take it upon themselves to pay attention to more than most. They are the people who walk around and ask questions. They notice when people are unhappy, overwhelmed, unsupported, or unsupervised. They are the people everyone turns to when nobody knows the answer. They are the unsung heroes who keep a startup from imploding under the weight of success.
But inevitably, the supernodes themselves burn out. After all, they’re consciously doing more than anybody else — but without any real extra incentives, resources, or authority. And when a supernode burns out, the whole network they support burns out, too.
Up until very recently, that’s where we were. So we’re moving on to the next stage: DHT.
4. Distributed Hash Table (21-?? people)
Because supernodes are volunteers, they don’t necessarily have any formal accountabilities — being a supernode isn’t a job, it’s a calling. And though over time supernodes tend to focus on certain areas, and though all nodes tend to learn what those areas are and act accordingly, those focuses aren’t documented or even formalized. This means new employees don’t know who knows what; people don’t know who is more qualified to make a decision than the next person. A supernode can only do so much as a volunteer: at some point your organization needs to upgrade to a DHT.
At a high level, a “distributed hash table” is a data structure where given any particular question, you can determine who knows the answer — in one step. No searching, no gossip: just ask the right person and they will know. In organizational terms, it’s kind of like an org chart: it documents which people are in charge of which areas. Ideally anybody can look at this chart and immediately determine the correct person to ask any question.
But it’s only a partial org chart: only the supernodes are put into the chart, and all the other nodes are left ambiguous. It’s not about strictly defined teams operating under a chain of command — it’s about a mob of people, where some people carry megaphones. Anybody can switch who they follow at will, depending on what they’re trying to accomplish. But those carrying the megaphones coordinate to ensure that the mob overall continues heading in the right direction.
That’s where we are today. Expensify is a mob, with megaphones. Naturally, I reserve the loudest megaphone for myself (as would any benevolent dictator), but more and more it’s the jobs of the supernodes to keep the mob moving forward — with me just helping coordinate behind the scenes.
How long will this last? I’m not sure. Like so many things, our lack of overt structure has worked much longer than I think anybody realistically thought was possible. Indeed, I attribute how well things have worked so far entirely to the fact that we only hire a very particular sort of person who can thrive in this environment. But I’m confident that it’ll keep us moving forward at our already astonishing rate, to whatever level comes up next.
Q: Why not a strict hierarchy; isn’t that more efficient?
A: In content delivery terms, that would be a “broadcast tree” — you have a single source, which broadcasts to the first set of nodes, each of who broadcast to the second set, out until all nodes get the content. It’s a top-down control network, and yes, it is optimally efficient. In an established company where all the kinks of the business have been ironed out, everyone’s job is well defined, and the success of the organization rests upon minor tweaks applied top down — yes, it’s ideal. Most large companies are structured this way for a reason.
But a startup is nothing like that. At least, our startup isn’t anything like that, and we all quit places like that to come here.
Rather, it’s more like I throw a flaming torch way out ahead of us, and we all try to figure out how to get there. Sometimes it involves building bridges, blowing up mountains, and occasionally burning our boats behind us. But my job is only to figure out (roughly) where we need to be: how we get there is up to the mob. So our structure is optimized to put maximum control into the hands of the most people. It can be chaotic, confusing, and sometimes a bit scary. But it’s a lot more productive, and infinitely more fun.
Founder and CEO of Expensify
Follow us at @expensify