Fully Distributed & Asynchronous: Building Eventually-Coordinated Teams That Ship

Fully Distributed & Asynchronous: Building Eventually-Coordinated Teams That Ship

"Fully Distributed & Asynchronous" describes a new scaling model for teams, which is dramatically different from vertical scaling (one big office) or horizontal scaling (multiple offices across regions).

The Fully Distributed model takes inspiration from how top-tier open source projects are run (e.g. Linux), wherein "the web is the office". People collaborate across geographies using digital tools that fit the job at hand.

Parse.ly runs a fully distributed & asynchronous team, and this talk describes the history and culture that drive its norms. We learn how the open source Debian project and Joel Spolsky's Fog Creek Software served as an inspiration in the early 2000's for a model that respects developer autonomy, private offices, and mission-driven flow on high-impact projects. We learn how distributed teams are somewhat like distributed systems -- their communication patterns are complex, and involve a series of trade-offs. In particular, we dig in how the CAP Theorem could be used as an analogy for distributed teams, and how overcoming Brooks's Law for scaling engineering teams might be a tradeoff similar to the one made in distributed databases. In the end, we learn that "eventually-coordinated" teams that ship frequently might create just the right mix of communication, autonomy, and cadence. More pragmatically, we discuss how to retain humanity even as the team eliminates face-to-face meetings as a primary management tool.

36988ea18935a2bd1278a97c6ba03707?s=128

Andrew Montalenti

December 19, 2018
Tweet

Transcript

  1. Fully Distributed & Asynchronous: Building Eventually-Coordinated Teams That Ship Andrew

    Montalenti Co-Founder & CTO Parse.ly @amontalenti
  2. + hundreds of other companies who run thousands of high-traffic

    sites. + others. Premium content sites Platforms So, what’s Parse.ly?
  3. 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.
  4. • Over 1 billion monthly unique visitors in the Parse.ly

    data network. • Over 2 million page views per minute at peak time. • Over 400 enterprises, with hundreds (or, thousands) of user seats in each. • Over 3,000 site integrations, 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.
  5. A philosophy… about data that’s accessible and essential.

  6. A team… that’s fully distributed & asynchronous.

  7. None
  8. None
  9. But first, let’s go back in time… to 1999.

  10. “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)
  11. “[…] 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)
  12. 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
  13. “Hire smart people, and they will produce good stuff that

    you can sell and make money off. Then everything else follows.” - Joel Spolsky (2000)
  14. “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)
  15. 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
  16. 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?
  17. 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.
  18. 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 (70+).
  19. 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.
  20. 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.”
  21. What’s the ‘CAP Theorem’ of teams? I’d say Brooks’s Law

    gets close. • “Adding manpower 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 women are assigned.” • Communication-centered: “an added burden of communication with two parts, training and intercommunication.” • Ill-defined: “the hardest single part of building a software system is deciding what to build.”
  22. None
  23. Takeaway: It’s 10X more difficult to communicate even though the

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

    company is only 3X bigger. (Ugh!)
  25. None
  26. Takeaway: A 4-person surgical team communicates 10X more efficiently than

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

    the 16-person group of which it is a part. (Yes!)
  28. 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.
  29. 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!”
  30. Key Insight: If everyone is coordinating, no one is acting.

    Coordination is necessary, but not for every action.
  31. None
  32. None
  33. 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.)
  34. And… we make sure to write things down!

  35. The coolest part about the fully distributed model?

  36. It scales.

  37. 2010 2018

  38. Thanks for being awesome. Happy hacking!

  39. Fully Distributed & Asynchronous: Building Eventually-Coordinated Teams That Ship Andrew

    Montalenti Co-Founder & CTO Parse.ly @amontalenti ~ Questions? ~ https://bit.ly/fully-distributed-teams