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.

Transcript

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

   View Slide

2. 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.
   

   View Slide

3. • 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.
   

   View Slide

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

   View Slide

5. View Slide

6. View Slide

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

   View Slide

8. “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)
   

   View Slide

9. “[…] 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)
   

   View Slide

10. 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
    

    View Slide

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

    View Slide

12. “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)
    

    View Slide

13. 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
    

    View Slide

14. 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?
    

    View Slide

15. 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.
    

    View Slide

16. 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.
    

    View Slide

17. 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.
    

    View Slide

18. 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.”
    

    View Slide

19. 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.”
    

    View Slide

20. View Slide

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

    View Slide

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

    View Slide

23. View Slide

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

    View Slide

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

    View Slide

26. 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.
    

    View Slide

27. 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!”
    

    View Slide

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

    View Slide

29. View Slide

30. View Slide

31. 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.)
    

    View Slide

32. And… we make sure to write things down!
    

    View Slide

33. The coolest part about the fully distributed model?
    

    View Slide

34. It scales.
    

    View Slide

35. View Slide

36. Thanks for being awesome. Happy hacking!
    

    View Slide

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

    View Slide