Why Quip doesn't have platform-specific engineering teams
If you're responsible for an engineering team, you have a lot of things to think about. You want your team to be happy, and you want to ship stuff. And you want your product to look good and work consistently across multiple platforms. So as a leader, what's the best way to organize your team to achieve your goals? Do you align people with features, projects, or platforms?
What most teams do
Even at small startups with both a web and client component, it's pretty common to see at least one engineer dedicated to building for a specific platform. If you want to build a good iOS product, the easiest way is to have someone that owns iOS development — an “iOS Team.” The same goes for Android, your web app, Mac, Windows, and so forth. This makes sense: you have a problem to solve (iOS Development), and you dedicate a specialist to figure it out (an iOS Engineer). The problem surfaces months or years down the line, though — when you've built teams around those specialized developers, and your engineering team is primarily organized by platform.
Ultimately, your organization shapes your product.
Why is this a problem? Because your engineers are isolated from one another, and your product starts to diverge. Ideally, your product should look great and function the same everywhere — but that becomes more and more difficult to maintain as a platform-oriented engineering organization grows. Different groups of engineers, who have separate areas of expertise, need to build the same features (you want sharing to work the same on web and mobile, right?). This is hard enough when engineers work side-by-side, but even more difficult when they're siloed off from each other. Every time feature descriptions or requirements are passed from one person to another, you run the risk of re-interpretation, inconsistency, and inefficiencies being introduced. You can rely on product managers and process to try to smooth things out, but it's an uphill battle.
What Quip does instead
At Quip, we hire engineers who enjoy working on different platforms — and we give them a lot of support. We've invested heavily in foundational infrastructure and tooling from the beginning, so you don't have to be a deep expert just to be able to get something done. This means that every engineer builds features into our mobile or desktop apps, even if they aren't necessarily experienced on those platforms. Of course, we do have engineers who are deeply knowledgable about certain platforms, but instead of pigeonholing them, we position them as a resource for everyone else to become more skilled — and to keep our frameworks running smoothly.
We make this possible by sharing a lot of code between platforms, so in many cases, building a feature once means that it's available everywhere. There are two main components that are shared by our clients: our C++ library that manages common functionality, like RPCs, local state and syncing, which keeps us from having to reimplement working with data for different platforms. When appropriate, we also make use of web views (i.e. HTML & JS) to render certain very complicated or visually rich features across different platforms. All of this means that when an engineer wants to implement something, they're able to build it once in these two domains, maybe add some platform-specific glue — and the same functionality exists across all our clients.
In other words, then, Quip's teams are organized by feature. When an engineer starts work on a new feature, whether it's small (the 👍 button) or large (spreadsheets), the engineer implements that feature on every platform.
It makes for a better product
The main reason we have this emphasis on code-sharing is because it helps us ship a better product. We get consistency across platforms because the same engineers own what they're building no matter where those features are. We can also move faster: when we get rid of the delays caused by communicating and coordinating a feature across platforms and the process for reconciling the inevitable inconsistencies, the feature gets done sooner, and engineers can move onto the next thing. Candidly, it's a big reason we're able to get so much done with a relatively small eng team here at Quip.
We also believe that this results in better quality. With a team full of people responsible for features, not platforms, fewer people have to work on each new project. There's often one, single engineer thinking about how things interact at all levels of the product, without the loss of context that's inherent in platform-based teams; nothing gets dropped during handoffs, like finer details or edge cases.
It makes for happier people
The secret sauce, though, is that we believe that this type of structure also makes for happier engineers. For starters, it gives engineers more ownership over whatever they're working on — after all, if you're a developer on an Android team inside a large organization, your work is often a piece of a larger effort. It's hard to see the big picture, and it can become a bit of a grind. Engineers at Quip are in control of their feature from start to finish, and ultimately get to see their work realized in several different places. Additionally, engineers learn more this way. When the work is more varied, engineers encounter (and then solve) different types of problems, and develop more breadth.
Perhaps most importantly, though, this structure helps ensure that your job is not your identity. In our experience, engineers don't like to be pigeonholed into a single category — to be known as an “iOS” engineer, or “Windows” engineer, or even an “infrastructure” engineer. Those sorts of titles, though they come from a good place, can often have an insidious effect on someone's career. If you start your job working on a particular type of platform or project, and you get good at it, you're almost “doomed” by your success to stay on that type of project, if your team is organized by platform. When your team is organized by feature, though, you're naturally encouraged to keep growing and keep finding new skills and areas to develop.
Quip's founding team spent a lot of time and effort up-front to build a solid cross-platform foundation, and we leverage that to keep our team small and our product awesome. It's easy to end up with platform-specific teams and lots of hand-offs. But, when you have enough confidence that you're building the right thing and you expect to be around for awhile, it's worth investing in your long-term code quality, your team's productivity, and most importantly, your people.
Does working like this sound like your 🍵 of tea? If it does, let us know — we're hiring!
