Pragmatism

I’m convinced that one of the things that made Meetingbird work is that the founding team (my twin brother and I) were not good engineers. I don’t just mean that we didn’t have industry experience; I really mean that we were bad engineers. The first Meetingbird commit was made two months after I took my first JavaScript tutorial online and Henry and I had only taken a few introductory computer science classes at the time. Many parts of the Meetingbird codebase would inspire horror from more experienced engineers. And yet, there were virtually zero technical decisions we made in those early days that had to be painfully reversed or re-engineered later on, and we never had a customer issue caused by an implementation shortcut. It’s not until recently that I’ve begun to understand why that was the case.

A common observation in engineering is that a junior engineer thinks about how their changes impact the file they’re working on and a senior engineer thinks about how their changes impact the entire repository. One intriguing corollary of this is that junior engineers are pragmatic by default. Oblivious to the impact of their changes on the rest of the project, they typically choose the implementation pattern that requires the least work to accomplish the task at hand. More experienced engineers on the other hand are instantly able to visualize the ripple effects of their changes on the entire project, which tempts them to abandon an easy solution for a more thorough and elegant one. Presented with this choice between a simple hack and an elegant system, experienced engineers far too often choose the latter, which is usually the wrong decision for a number of reasons:

• The added engineering effort doesn’t materially improve the customer experience.
• The assumptions around the future usefulness of the system are misguided (there are countless products that were built to handle 1000x more scale than they ever received).
• The delay in execution increases the risk that the project loses momentum and never ships due to deallocation of resources or changing company priorities.

The results of overly idealistic decision making are all too familiar to most; missed deadlines, product stagnation, and frustrated customers.

In contrast, the simplest solution delivers the required user experience with the minimum amount of technical effort and postpones more costly technical investments for the future, when they can be de-risked with more user feedback and validation.

One common counterargument to pragmatism points to the current trend in software that products are of increasingly higher polish and quality. Competing with this higher quality, as the reasoning would have it, demands more perfectionism, not pragmatism. The problem with this argument is that it conflates being pragmatic in execution with being sloppy in the delivered result. The most effective product teams have extremely high standards and ambitious visions for their product, but they execute towards that lofty vision in a pragmatic way by prioritizing ruthlessly and delivering value as quickly as possible. This strategy is actually especially important in an increasingly competitive software landscape because the margin for error and inefficiency is thinner.

Starting your own company turns out to be a very effective way of understanding the importance of pragmatic decision making because it’s very difficult to justify a 6 month detour when you have 12 months of runway in the bank. It’s similarly difficult to stomach a proposal for an elaborate codebase refactor when you’ve seen first hand how much can be accomplished by a small, scrappy team in the same amount of time.

Outside of the founder experience, the key to cultivating pragmatism is to empower team members to be product-driven. Laser-focused attention to a particular business outcome elevates technical decision making from an exercise that’s solely motivated by technical tradeoffs to one that puts the user experience first. There are a few tactical ways to promote this kind of thinking:

1. Set a clear, measurable business outcome that engineering and product should influence. These should look like “increase X by Y%”, not “ship X with Y features”.
2. Measure progress toward the goal with clear metrics that are available to everyone and reviewed regularly (weekly emails and sprint planning meetings work well for this).
3. Require technical specifications to explain the metric the project will impact and outline data-driven success criteria.

When Meetingbird was acquired by Front (now a 160 person company with an exceptionally strong engineering team), my expectation was that we’d finally learn the “right” way to do engineering that traded our simple hacks for methodical, deliberate execution. We surely found higher quality code and greater thoroughness in QA and testing, but the broader realization was that the same pragmatic approach to product development was exactly what had made Front as successful as it has been. Today, the focus at Front is on sustaining that pragmatic decision making as we grow rather than curtailing it.

This turns out to be a crucial focus area because pragmatism usually erodes as startups scale. The proportion of team members that remember the fragile early days decreases as the team grows. Projects that used to be “make or break” for the company are now just one entry in a catalog of product bets that may or may not work out. And the relative abundance of engineering resources means that elaborate product proposals appear more feasible. The result is a brand of thinking that’s entitled and idealistic. Larger companies can sustain themselves without pragmatism longer than small companies, but the outcome in the long run is no different; a stagnant product and unhappy customers. The scarcity of pragmatism in larger companies explains why they’re often outperformed by small, pragmatic teams.

One memory I think back upon fondly is the weekly sprint planning Henry and I used to do in our Sunnyvale apartment when we were going through Y Combinator. On a piece of Home Depot’s “white panel board” (we were too cheap to buy an actual whiteboard), we drew seven columns for each day of the week. Under each column, we didn’t write notes about fixing a small bug or making incremental progress on some feature, we just had a list of the full, complete user-facing features that we’d ship that day. We’d work like crazy for the subsequent week, and nearly every feature would get shipped. It’s a constant reminder for me of what’s possible with a pragmatic mindset.

Thanks to Henry Dornier, Mathilde Collin, Laurent Perrin, Keith Rabois, and Delian Asparouhov for reading drafts of this essay.