DocSend

DocSend's engineering team structure is fairly flat. We are a diverse group of people who work collaboratively on interesting problems while keeping the codebase convenient and enjoyable to work with. We work on one-week cycles that begin with a group planning meeting where we discuss and estimate what's coming up; and ends with a retrospective meeting (for the regex lovers out there, the actual meeting name is "(?

One of our challenges involves turning complex concepts into simple, usable features. In some cases, we're having to capture thousands of visits per document or hundreds of visits per team member in a single notification or entry in a list. This type of challenge requires a strong understanding of what the user needs and a bit of technical creativity in order to architect the right solution.

A lot of those features are released in phases, which is another interesting challenge we regularly encounter. This starts with designing zero-downtime database migrations. It often ends with internal releases that are rolled out to our company's DocSend accounts, then a public release. Every project is similar and different in its own way, and we do all this while maintaining high uptime and reliability for our users throughout the entire feature development process.