Speed Limits

One of the great frustrations of my life is that everything takes longer than one would hope. Preferably things would be instant: have that great idea for a product or technology and poof it appears. Instead not only do you need execution capability to back up the idea, but you also need a lot of time.

Even with a great team, perfectly capable of executing, you might not have enough time. We talk about this concretely in Silicon Valley in the form of runway. We talk about this generally in how short life can be. To get more mileage, you can either make life longer or you can do more faster.

At first it seems like there are many ways to make things go faster. Adding people is a famously bad one. Sometimes it can work out if the units of work are appropriately decoupled and parallelizable. But there’s also the issue that you probably don’t know what to build yet. This is reflected in how waterfall specifications are always wrong or at least underspecified. The response to this is the variety of things we call “agile” and the time constants appear to be determined as much by the rate at which humans absorb and synthesize knowledge as by how quickly they can write code.

It’s not obvious how to speed that up. For starters, shouting “go faster” is definitely not one of them. If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea, wrote Antoine de Saint-Exupéry. That helps, and is critical for keeping everyone engaged over the long time things will take. But ultimately there appear to be some intrinsic speed limits.

We need pencil and paper to do basic arithmetic. [This is] not [an] attribute of the pinnacle of possible intelligences. — ggreer, Hacker News

Speed limits are something I’m hoping AI helps with. You can see on the horizon a system that you drop interactive mocks into and get back React and CSS, or trade high level system designs for completed PCB layouts and firmware. Better developer tools feel like an underexplored area in deep learning, but I’m also not an expert and it could just be too early.

The lags introduced by human-to-human coordination are also things I don’t think I’ll ever get used to. Meeting with another company with clear next steps? Great, schedule a follow up for two weeks from now. For most business contacts outside of a “live deal” you’ll only really touch them 5-10 times, maybe 20 tops, per year. But turn this around and you see where it comes from: I have to track all of the different threads going on, and one can only really do a few things each day, and there’s a relatively high penalty to context switching. If all you’re doing is responding to emails that might go fast, but as soon as you have to go gather information or check with someone else or produce some original content the costs go up and time flies by.

Estimating time for engineering accurately is a notoriously hard skill to develop. The Transcriptic hardware team is the best at this I’ve ever seen: I’m not sure if they’ve lost more than a week total against their Gantt charts in the history of the company. I know it takes a lot of effort and diligence to get that good without sandbagging, which they’re definitely not.

I strongly believe that speed is a defining characteristic of successful startups, and those who can execute quickest have a huge advantage, so in this things taking a long time is relative. If we can ship a new system in 4 months and it takes everyone else 12 months, that’s a major win. But I still don’t get that many 4-month cycles per year and there’s more stuff to do.

Value is built over time. You have an obligation to your employees, investors, and to some extent society to grow fast, but you must consistently go fast over an extended period of time to actually realize a company’s potential. Fast growth does not excuse a lack of patience or persistence. One of the things I’ve been surprised by at Transcriptic is how much things improve over years and how hard it is to effect dramatic change over weeks, the timescale I naturally think over. While we invest aggressively in projects designed to drive growth now, there’s a lot to be said for runway and the steady, relentless, compounding execution of a great team over long periods of time, even when you’d rather it just all happen yesterday.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.