This question originally appeared on Quora, the best answer to any question. Ask a question, get a great answer. Learn from experts and access insider knowledge. You can follow Quora on Twitter, Facebook, and Google Plus.
Answer by Edmond Lau, engineer at Quip:
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 give you a lot of leverage as an engineering team.
We still have a long ways to go, but here are some of the principles and processes that I’ve seen pay off big dividends for our team so far.
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. We support eight different platforms for our product: Web, Mac, Windows, iPhone, iPad, Android phones, Android tablets, and Apple Watch. If we had to rebuild the product from scratch on each platform, 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, 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—all 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.
These technical investments by no means solve all the challenges associated with supporting many platforms, but they do help eliminate large swaths of work.
Leverage 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 six-plus years of industry experience, and more than half have 10-plus 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 with a team of 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 else on the team had worked with at previous companies, and that has cut down on 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, since there’s a decent chance you might find opportunities to work together again in the future.
Invest Heavily in Tooling
Tools amplify your output, and their benefits also stack and compound over time. So 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, 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 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 with other startups—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.
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. What we don’t build is just as important as what we do.
Both quantitative and qualitative user feedback has 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 apps, 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 apps that users cared the most about and punt on the longer tail of issues.
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 roughly 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 service 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 nearby 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 integrating Quip into all our workflows has greatly reduced the friction of communication. It’s 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, but we also have a long and exciting road ahead of us, with plenty more to learn about how to keep our team effective as we continue to grow. We’re up to 13 engineers now, including the two co-founders.
How is Quip able to build such a comprehensive app with 12 engineers? originally appeared on Quora. More questions on Quora:
