Fully Distributed & Asynchronous: Building Eventually-Coordinated Teams That Ship Andrew Montalenti Co-Founder & CTO Parse.ly @amontalenti

Page views Visitors Engaged time Social shares Audience loyalty Devices Video Titles Authors Sections Tags Referrers Campaigns Publish dates Channels + Much more A product…delivering content metrics for digital storytellers.

• Over 1 billion monthly unique visitors in the Parse.ly data network. • Over 2 million page views per minute at peak time. • Over 300 enterprises, with hundreds (or, thousands) of user seats in each. • Over 5,000 sites, including many of the world’s highest-traffic sites. • 99.99% SLOs with sub-second latency — a relentless real-time stream of data. A large-scale SaaS app… deployed to hundreds of companies.

A team… that’s fully distributed & asynchronous.

No content

No content

But first, let’s go back in time… to 1999.

“We are Software In The Public Interest, producers of the Debian GNU/Linux system. This is the ‘social contract’ we offer to the free software community: 1. Debian Will Remain 100% Free Software 2. We Will Give Back to the Free Software Community 3. We Won't Hide Problems 4. Our Priorities are Our Users and Free Software […]” - Bruce Perens (1997)

“[…] hacker culture is a 'gift culture’, in which participants compete for prestige by giving time, energy, and creativity away. […] The only available measure of competitive success is reputation among one's peers.” “[…] given enough eyeballs, all bugs are shallow.” - esr (1998)

My takeaways from open source back in the early 2000s: - amazing feats of collaboration
 happen entirely over the web - programmer tools create a
 default-async working model - great programmers regularly
 code for free, on the right problems - what’s good for the goose…
 must be good for the gander

“Hire smart people, and they will produce good stuff that you can sell and make money off. Then everything else follows.” - Joel Spolsky (2000)

“Most software managers know what good office space would be like, and they know they don’t have it, and can’t have it. […] Not only did we get spacious, windowed private offices, but even the common areas are hidden in clever angular alcoves, so everyone gets a private space without line of sight to anyone else.” - Joel Spolsky (2003)

My takeaways from Spolsky back in the early 2000s: - great programmers work best in small groups - every professional programmer needs a private office - process is about ensuring quality, not about physical oversight - managers are helpful janitors,
 not babysitters, gods, or kings

Could we build a startup by combining the best of each? Wherein engineers self-manage — in an async way — on juicy technical problems? Wherein everyone worked from their ideal office — one set up at home — with no commute?

The Parse.ly Manifesto (2008) We distribute our work. We communicate openly. We are all adults here. We value results, not effort. We have fun. We believe that our distributed team is an asset, not a problem to be managed.

Defining “fully distributed teams.” Hint: it’s not a work-from-home policy. • Vertically-Scaled: One office that must get bigger to house staff; collaboration is face-to-face preferred, but remote unfriendly. See Pixar 2000-present in Emeryville, CA. • Horizontally-Scaled: Multiple offices with distinct cultures; collaboration is face-to-face preferred, yet remote tolerant between offices. See Google 2009-present in SV/NYC/Boston/etc. • Fully-Distributed: No “office” – the web is the office; collaboration is remote-preferred, face-to-face occasional. Scaled 2018 examples are Elastic (1,200+) and InVision (700+). • Parse.ly is a fully distributed team, though operating at sub-100 headcount scale.

Note: I don’t really think any one of these models is “better” than the other. Like their equivalent software designs, they involve a series of trade-offs.

No Unnecessary Meetings. “Hey—it was in my offer letter.” • “No Unnecessary Meetings: We are a company focused on productivity and happiness. We know that multi-tasking is deeply unproductive, and that people need to enter a flow state to get things done. As a team, we will be managed with the idea of limiting work-in-progress to keep every individual focused and productive. We will use lightweight meetings for occasional status checks, but won't push this beyond the necessary.” • “At any moment, if you think you are in an unnecessary meeting, you can ask to adjourn it early, or leave. For any proposed meeting, you can always ask the question, ‘is this meeting necessary?’ If someone thinks you’re being rude, remind them of this guarantee, and have them consult their offer letter.”

What’s the ‘CAP Theorem’ of teams? I’d say Brooks’s Law gets close. • “Adding people to a late software project makes it later.” • Software projects are often: • Irreducible: “the bearing of a child takes nine months, no matter how many people are assigned.” • Communication-heavy: “an added burden of communication with two parts: training and inter-communication.” • Ill-defined: “the hardest single part of building a software system is deciding what to build.”

No content

Takeaway: It’s 10X more difficult to communicate even though the company is only 3X bigger.

Takeaway: It’s 10X more difficult to communicate even though the company is only 3X bigger. (Ugh!)

No content

Takeaway: A 4-person surgical team communicates 10X more efficiently than the 16-person group of which it is a part.

Takeaway: A 4-person surgical team communicates 10X more efficiently than the 16-person group of which it is a part. (Yes!)

Beating Brooks’s Law is kind of like beating the CAP Theorem • The key is to recognize what we’re willing to lose. • Coordination: everyone knows what others are doing. • Action: everyone is making forward progress. • People: everyone fits in a small room. • Yes, we can’t have a “big, always coordinating, always acting” unified team.

Beating Brooks’s Law is kind of like beating the CAP Theorem • The key is to recognize what we’re willing to lose. • Coordination: everyone knows what others are doing. • Action: everyone is making forward progress. • People: everyone fits in a small room. • Yes, we can’t have a “big, always coordinating, always acting” unified team. • BUT, we can have an “eventually coordinated, always acting” asynchronous company of autonomous sub-teams! • That’s the model we chose! “Eventual coordination!”

Key Insight: If everyone is coordinating, no one is acting. Coordination is necessary, but not for every action.

No content

No content

Our approach is to be thoughtful. But also, recognize work’s humanity. • Distributed teams are not “cheaper”, because you need to allocate the money you save on offices to team retreats. • Work is all about communication, collaboration, and cadence, and distributed teams need it all in abundance. • Have new hires meet their colleagues face-to-face: it always helps to get to know someone personally. • Realize that on-boarding is traditionally a physical process of “office osmosis”; since you don’t have an office, you need managed on-boarding. • (BTW, if you have an office, you also need managed on- boarding — if you don’t have it, you’re relying on a crutch.)

And… we make sure to write things down!

The coolest part about the fully distributed model?

It scales.

No content

Thanks for being awesome. Happy hacking!

Fully Distributed & Asynchronous: Building Eventually-Coordinated Teams That Ship Andrew Montalenti Co-Founder & CTO Parse.ly @amontalenti ~ Questions? ~ https://bit.ly/fully-distributed-teams