High baud rate founders
4 key drivers of “broadband” communications for startups. (Originally posted on my Medium on ¼/2014.)
Speed of iteration is crucial to the success of any early stage company. What enables that speed to exist, however, is not always clear. So-called “life hackers” will promote their own techniques to get the most out of a 24 hour period. Agile software development practices can also push the envelope on speed. Simply working longer hours than others over a sustained period of time can be incrementally helpful, if you can keep it going without burning out.
Yet, the root cause of reductions in cycle time for startups always comes down to one thing: the rate of information transfer between actual people. We see this over and over again; the early startup teams who communicate most effectively with one and other tend to get the most done in a given period of time.
I call the people who start these companies “high baud rate founders.” They transfer information between one and other at an astoundingly high rate. (Strictly speaking, I should call them “high bit rate founders,” but baud sounds better to me. If you’re a stickler, read more here on the difference.)
A number of factors drive a high baud rate, and I have attempted to list the most important ones here:
1. Raw intelligence
It should not come as too much of a shock that some peoples’ gears turn faster than others’. This is a relative thing, but when I meet founders, I usually ask myself the question, “Is this guy or gal smarter than me?” I can get a sense for this by engaging that person in an intellectual conversation, in an area where I should be on equal footing. Basic math, science, or engineering usually do the trick.
If the whole team exhibits the same elevated pace of thought relative to me, that’s usually a sign of a high raw intelligence factor. It is essential that each founder possess this quality, since the overall processing speed of the group is governed by a min() function.
2. Efficient communication techniques
A processor can run as fast as it wants, but if it throws away cycles on useless tasks it is underperforming. Along those lines, high baud rate founders tend to send short, punchy emails with only the necessary detail. They tend to say a lot with a little. They tend to cluster similar tasks to avoid the penalty of “context switching.” In short, they maximize the amount of signal in their frequent interactions.
As an outsider, it can be hard to observe how founders economize their communication. I often get signals from forwarded email traffic, as well as the configuration of an office. There’s no substitute, however, for spending time at a company and casually observing this phenomenon directly.
3. Unspoken bonds
To deliver a message, the only thing better than an economy of words is none at all. I am always impressed by founding teams that have a bias for action, knowing full well how their colleagues will react, with no need to communicate in a confirmatory fashion. This can only be possible if the company has (A) a clear plan and (B) a strong culture. The former is necessary for the “what,” while the latter is necessary for the “why.” If both of these are solid, then each individual can usually figure out the “how” on his or her own.
I often ask founders about their product plan and what they will do in different contingent situations. Finding consistency in multiple founders’ independent responses is a really good sign.
4. Empathy for each other’s role
It is hard to have a high baud rate interaction with a peer without knowing his role and priorities. The quantity of empathy between founders is therefore strongly correlated with their collective baud rate. Founders with cross functional backgrounds (e.g. eng + product, sales + marketing) tend to be the best at this, but even a little bit of time spent out of one’s core functional area can improve the collective baud rate significantly.
This empathy can often be gleaned just by looking at the team’s background. A stronger signal, however, is the manner in which each founder speaks of the other and his respective contributions to the company. I view a “throwing it over the wall” attitude in an early stage company, for example, as a sign of trouble on this front.
In short, going faster should not be the goal. The goal should be higher throughput of all communications on the team. Getting this right will enable speed, and so much more.
1 Notes