Lowering the Barrier

Making programming (everything) more accessible

08 Nov 2020

Evolve Ruthlessly

Evolve Ruthlessly

There comes a point in a startup’s life, if it lives long enough, when its creators look around and say “we need to get our act together.” Years of non-stop building have yielded a system that works, that does what people want, but can’t withstand growth without constant babysitting.

I love this stage! I’ve been around startups before and after this point, and come to know that this is my sweet spot. The process sounds pretty simple when you write it down: find the most pressing problem, fix it, and put tests or monitoring in place so you don’t slide backwards when you move on to other problems. The trick is choosing the right problems to focus on, especially when the large fire drills have multiple causes. You’ve also got to constantly remind yourself what’s going well. It’s all too human while focusing on what’s wrong to start believing everything’s wrong.

Having gone through this cycle before, it’s dawning on me that you have to beware overcorrection. You slow down, double- or triple-check your work, contemplate the best way to push intricate changes out instead of pushing them out, and before you know it you’re moving slowly and, because no one’s perfect, still breaking things. You won’t know you’ve overcorrect unless you pay attention, because it’ll seem like your efforts are paying off. The site’s reliable! We’ve introduced fewer bugs! Uptime has never been higher! The pager magically only goes off during business hours! Yet the product looks the same as it did six months ago.

Repl.it’s focused on simplifying and stabilizing our core features right now. That’s meant pulling more functionality into repls, paring back anonymous repls, deleting features and code that haven’t panned out, and tightening up services where latency spiked. It’s working - the site feels a lot faster and our internal dashboards look amazing. We want to keep the simplicity and stability without becoming timid.

Amjad’s been thinking about the adage “move fast and break things.” You can take that phrase as permission to push out code that doesn’t work or systems that harm people. But you don’t have to take it that way. The overcorrection I described above happens after you’ve reached a certain level of success. You don’t want to alter (break) the product you’ve built or make the people using it unhappy. So you stop moving fast. You spend your time propping up current systems while daydreaming of better ones. As Amjad pointed out to me, “most of the value lies in the future, and you want to get to the future as fast as you can.” Pushing a lot of small features won’t get you there. Holding on to the way things currently work won’t get you there either. You’ve got to make bold moves in the product and behind the scenes, make sure growth doesn’t nosedive (even if it dips slightly), and keep going.

I summed this idea up as “be bold and pay attention,” which, admittedly, isn’t that catchy. Amjad put it more concisely: evolve ruthlessly.

Time and attention are pretty limited resources. So if you want to get to the future as fast as you can, you’ve got to take large strides. Measuring engineering velocity by outputs has always felt off to me. It’s not that measurement itself is inherently bad - software people have made it easy to measure the performance of systems and of other humans - it’s that the universe doesn’t care how many pull requests you merge or deploys you do. Are you delighting the people who use your product? Measuring that directly would be awesome! Mismeasuring delight as time spent on a web page has wrought so much damage in our world.

Every Friday at Repl.it we have a Weekly Wins meeting. Amjad talks about the state of the company, Patrick shares how the business is doing, and Obaida gives us the pulse of all our different feedback channels. Every single person at the company then shares a win they’ve had that week. If we keep hearing effusive praise from the people using Repl.it and each week at least one of us shares a win that directly helps other humans in a big way, then we’re on the right course. The answer isn’t a graph of number of human-helping wins per time unit. It’s making sure we’re keeping a streak of having at least one of those wins each week.