Eric Dorsey

An observation about basketball and software engineering teams. I was always the “big man” on basketball teams growing up. Big men usually don’t shoot threes. I excelled at anything within a 6 ft radius of the rim. My senior year my shooting percentage was off the charts partially because I was out half the year due to a broken foot, but also because I only took shots within that 6ft radius. As a big man, you can still score three points, if you can make your free throws. But, it’s not really a…

Much has been written about the potential upsides and downsides of AI, how it may shape our future, and what we should do about it. Most of these takes are at one end of the spectrum or the other. AI will either doom us all or save us all, but a middle ground does exist. The answer is not in regulating or slowing it down. From an American perspective, our rivals will make no such concessions. The solution has two parts: AI deterrence, very much like nuclear deterrence - mutually assured…

Half the challenge of software engineering in a startup is deciding what should be nailed down now and what definitely shouldn’t be. You’re gonna get multiple at bats at the same code. Most code doesn’t need to be perfect today. Doing this well is where speed comes from. You can do this poorly in two ways and both slow you down, but slightly differently: Nailing too much down Not nailing enough down Nailing too much down causes up front costs to balloon and you add unnecessary overhead to…

Single Sign On is widely considered to be an enterprise feature. Most enterprises already have a username and password database and don’t want to manage the complexity of syncing all those user identities and credentials for all the online services they make use of. In the days before the Cloud, we used LDAP and Active Directory to solve these problems, but by todays standards, these protocols are lacking. Facebook, Twitter, Google, Apple and others created a mechanism called OAuth that would…

Facebook and Microsoft recently declared themselves spokes-companies for Metaverse. These companies have built, acquired, influenced much of what came from the web the past 20 years. We are living in a future that they had a large hand in influencing. I’m not so sure we should assume that this phase will have better results. It seems that they are taking their same approach of: "trust us, we know what we are doing. We are all from Stanford and Harvard and Very Smart (TM)." Just like humans…

A few years ago, I observed that the wealthiest people on the planet all had one thing in common: they all seemed to have a significant amount of control over a very large amount of compute power, or be in close proximity to someone with that control. It's stuck with me ever since. Sometimes I relay it to other people, partly in jest, but lately it's seemed a bit more "real". I recently came across the ideas of Jaron Lanier and that very much triggered some reinforcement bias, but what he had…

A few years back, I joined a startup in the Cloud Security space. I was hired to take ownership over the React app they had built. On my first day, I met the rest of my new co-workers. One of which was responsible for the API that I needed to interact with, let's call him Happy. I had enough problems to deal with in getting their web application ready for prime time, so I didn't focus a ton on the backend. I assumed that it was being competently built. That is until I started having to nag…

“Good ideas" are just that. Good. Not great. Not the ones that hit with such impact that people’s jaw’s drop. Not the special ideas. The ones that are just good enough to warrant speaking life into them. Don’t be afraid to sacrifice the good ideas. The good ideas, while sometimes clever and useful, aren’t what matter. The value they deliver when implemented is linear, not exponential. There is far more value in being willing to sacrifice these ideas than stubbornly refusing and forging ahead…

I've been thinking about how to build a billion dollar technology company in Kansas City for awhile now. This post represents a slow hunch that's been gathering steam in my mind for the last few years. A little over 4 years ago, I published a post called Starting up in KC with some tactical advice and lessons I'd learned up to that point. Then a few years later I wrote What Kansas City Lacks for Startups, where my premise is we lack the density of experience required to truly take a company from…

In the last few years I've learned a lot about how a business can continue iterating on a product built upon a software stack that is starting to show a bit of age. One of the lessons I've learned is that products that target businesses should be built API-first, particularly B2B SaaS. What this means is that you start by building the API for the product, the API isn't an after-thought that gets added on when a customer wants to integrate. What is an API? API stands for Application Programming…

I sometimes find myself giving technical advice on how to handle different issues to founders or engineers at their companies. One thing that usually comes up is timezones, so I'm writing down my advice here. I've implemented timezones a number of times in my career as an engineer. A calendar app whose concept of a timezone was only the offset (-5) from UTC was one of my first implementations. Each time I've implemented timezones, I've done it better and my understanding has improved. First…

They said the Internet promised a new way. That software was eating the world. That travel agents, brokers, and middlemen were a thing of the past. But, look around us. That’s not what we’ve achieved. Nor are we even close to achieving it. We’ve simply created a better middleman. While it might have brought less friction, it also has a downside, these middlemen are based on algorithms we cannot read and cannot hope to fully understand. Maybe what we’ve achieved is removing the humanity from our…