What we learned from building Quip on 8 different platforms with only 14 engineers
(This post was previously published on my personal blog, The Effective Engineer, and a version has been re-published on Slate as well.)
How do you build a great product that impacts the lives of millions of people with just a small engineering team?
That’s a question I’ve often thought long and hard about during my years at Quora and, more recently, at Quip. I joined Quora when the team consisted of only 12 people and Quip when it had just 13. Both startups have ambitious missions. 1 Quora aims to share and grow the world’s knowledge and to build an internet-scale Library of Alexandria. 2 At Quip, we aspire to build a new class of productivity tool that every person at every company enjoys using every single day.
When you have a small team and a bold mission, the only way to make meaningful progress is to focus on the activities that offer you a lot of leverage — ones that give you a big return on your time investment.
So far at Quip, this focus on high-leverage activities has paid off. We’ve been able to sign on a growing list of customers that love the product, including Facebook, Pinterest, Stripe, Instacart, Product Hunt, New Relic, and many other household names. We’ve built out comprehensive applications across 8 different platforms (web, Mac, Windows, iPhone, iPad, Android phones, Android tablets, and Apple Watch). And we’ve done so with just 14 engineers.
We still have a long ways to go, but here are some of the principles and processes that I’ve seen pay off huge dividends for our small team.
1. Build once, use multiple times
Good abstractions are important whenever you’re building software, but good abstractions that work across platforms are particularly essential for our small team. If we had to rebuild the product from scratch on each of our eight platforms, we wouldn’t get very far. And so we’ve invested significant energy toward libraries and architectures that let us build something once and use it multiple times.
For example, we use Protocol Buffers extensively for data storage, in-memory data structures, and cross-platform communication. This lets us do things like read Protocol Buffers out of MySQL; 3 transform the data on our Python web servers; then send them to our native clients built on top of languages ranging from C++, Objective C, Java, or C#; and even pass those same data structures down to our JavaScript editor. Moreover, all of this happens via auto-generated data serialization code, with strongly typed data structures, and over strongly typed communication channels. If we had used language-specific data structures or even JSON, handling data through those various steps would be much more tedious and error prone.
The theme of “build once, use multiple times” shows up in many other places as well. We share the same C++ library for synchronizing data and supporting offline access across our desktop and mobile applications. All the document editors across all devices run on the same JavaScript libraries — we then layer in native hooks and platform-specific optimizations to make experiences feel polished and performant. Our web, Mac, and Windows desktop applications share the same React UI code, styled to look native to each platform. 4
These technical investments by no means solve all the challenges associated with supporting many platforms, but they do help eliminate large swaths of work.
2. Take advantage of in-network referrals for hiring
Quip is by far the most senior team of people that I’ve had the fortune to work with. On engineering, most people on the team have 6+ years of industry experience, and more than half have 10+ years.
With that industry experience comes a great luxury that’s often hard to come by at small startups: we’re able to work and execute independently on hard problems. We can trust that everyone is generally doing the right thing. We haven’t needed to spend nearly as much time so far training new hires, as compared to a team with more junior engineers. We’re also able to avoid some mistakes that we might’ve made earlier in our careers — it might be obvious, but it’s significantly easier and faster to build an A/B testing framework or a monitoring system your second or third time around. The industry experience lets us shift more of our energy and risk-taking toward challenges specific to the product.
To build that team, we’ve taken advantage of in-network referrals. Many Quip engineers are people that someone on the team had previously enjoyed worked with, and that signal has cut down a lot of risk and noise in the hiring process. Even if you’re just starting out in your career, this highlights the importance of keeping in touch with people you enjoy working with. There’s a decent chance you might find opportunities to work together again in the future.
3. Invest heavily in tooling
Tools amplify your output, and their benefits also stack and compound over time. At Quip, we build lots of tools to help us develop faster: dashboards that aggregate and cluster errors with helpful stack traces, tools to debug and inspect the state of our app, git commit hooks to analyze code and catch common errors, and many other scripts to automate tedious tasks. We graph loads of data, from performance metrics to retention rates, so that we can better understand what’s going on. We build internal tools for our customer support and business teams so that they can help address any customer issues quickly.
This focus on tooling has also helped us to reduce our operational overhead. Continuous integration keeps our build healthy, and push-button deployment scripts streamline our releases. Fine-grained alerts that can be easily tuned, for instance to only page on-call engineers during business hours, help reduce stress. As a result, pager duty at Quip has typically been uneventful compared to other startups I’ve worked at — I’ve gotten paged in the middle of the night only two or three times in the past year. All those investments let us spend more time building and scaling the product rather than just maintaining it.
4. Put more wood behind fewer arrows
We have lists and lists of features and improvements that we’d love to build, but we have limited time and resources. It’s important to focus our energy on key milestones and to aggressively prioritize features and bug fixes so that we don’t spread ourselves too thin. Context switching is costly, and what we don’t build is just as important as what we do.
Both quantitative and qualitative user feedback have been extremely valuable on that front. For A/B tests, we’ll work hard to decompose ideas into smaller testable hypotheses that we can measure and validate to reduce wasted effort. For features, we might build a minimal viable product and then run user tests to collect any initial feedback about what’s confusing and what works. Or we might roll out a feature to a few customers and then work closely with them to understand what they like or don’t like.
For example, when we launched our Mac and Windows applications, we rolled them out in multiple phases to employees and alpha and beta testers, based on their desire to be early adopters and their tolerance for bugs. Their feedback (on Quip documents of course) helped us focus on building out the features in the desktop applications that users cared the most about. We could then defer the longer tail of features until later.
5. Reduce the friction of communication
Emails and meetings are typically two of the biggest energy drains for engineering teams. So at Quip, we generally avoid them. We don’t use email internally in engineering for any communication, aside for managing GitHub code reviews and certain classes of alerts. During most weeks, engineers have only an hour of scheduled meetings: a 30-minute weekly all-hands meeting where we share updates and show off new demos, and then perhaps a small project meeting or a one-on-one. Instead of holding a meeting (with all the associated overhead of scheduling and where discussions tend to expand to fill the allotted time), we’ll hold ad-hoc discussions as necessary to build alignment and get things done.
The bulk of our communication, unsurprisingly, happens through Quip. The product is how we collaborate across the company, and we use it every day, for everything. We use Quip for design documents, product task lists, customer support, and chat. We set up internal integrations for Pager Duty, Zendesk, Twitter, Jenkins, Stripe, Crashlytics, Github, and more so that it’s easy to for the entire team to discuss events as they arise. If a user tweets a bug at @QuipSupport, someone scanning our Twitter chat channel within Quip can @mention an engineer in Quip and ask whether it’s a known issue. If the Customer Success team or a salesperson wants to pass along a feature request from a customer, she can add it to a feedback document or task list, and any stakeholders can chime in or prioritize the request. We even have a document shared with a local sandwich and salad shop where we type in lunch orders, and the wonderful folks there deliver them to our office every day at noon.
Communication is often the first casualty of a team’s growth, and any tools that can reduce the friction of communication — whether it’s Quip, Slack, or something else — can significantly boost the effectiveness of a team. Integrating Quip into our workflows has helped us work together in a way that wouldn’t have have been possible with traditional methods like emails and meetings. It’s also helped build a culture of transparency across the company. Information in email tends to get lost or isolated to a handful of recipients. In contrast, our Quip documents become a growing repository of knowledge for everyone on the team, and the comments and discussion alongside each document provide any historical context so that we’re all on the same page.
We’ve made a lot of progress so far, and there’s still a long and exciting road ahead. If you’re interested in working at Quip, check out our jobs page.
Notes:
- Quora and Quip are similar in many ways beyond having a bold mission. They were both co-founded by a former Facebook CTO, both raised their Series A with Benchmark, and, of course, both start with Qu.
- The Quora Mission.
- For our MySQL data storage, we use a design similar to FriendFeed’s schema-less MySQL design, except that we store data as Protocol Buffers instead of pickled Python objects.
- Bret Taylor wrote a more in-depth technical post on our shared C++ and React architecture: React with C++: Building the Quip Mac and Windows Apps.
