Scaling Distributed Engineering Teams, by Facebook Engineer Dale Harrison
•
1 like•1,903 views
Learn how to structure and manage distributed teams from the guy who led teams from both Twitter’s and Facebook’s NYC offices. Presented at the Hive engineering leadership summit at the Tumo Center in Yerevan Armenia. Learn more about hiring top tech talent: https://teamable.com
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
Similar to Scaling Distributed Engineering Teams, by Facebook Engineer Dale Harrison
Similar to Scaling Distributed Engineering Teams, by Facebook Engineer Dale Harrison (20)
Recently uploaded
Recently uploaded (20)
Scaling Distributed Engineering Teams, by Facebook Engineer Dale Harrison
- 1. Distributed
- 2. What? • Why? • Building • Running • Maintaining
- 3. Me • 18 years as a professional nerd, 10 in leadership • 1 failed startup (thanks, dotcom) • Finance, Twitter NYC, Facebook NYC
- 5. Why? • Backyard • Remote vs Distributed
- 6. Building • Cross functional teams • People people • Asymmetry bad. Hybrid bad. Critical mass good. • Rule of 3 • Autonomy
- 7. XFN • Diversity • Localise decision making • Bigger pool
- 8. People • Communicate • Communicate • Communicate
- 10. Rule of 3 • People • Teams • Groups
- 11. Autonomy • Project selection is important! • Maximise colocation* • Avoid silos
- 12. Running • Communication • Trust • Timezones • Process
- 14. Communication • Overcommunicate • Group chat • Watercooler chat
- 15. Trust • Get together regularly • Relationships matter
- 17. Process • Level the playing field • Hybrid teams are painful • Monitor the work, not the workers
- 20. Maintaining • Communication • Assume trust • Active dialog • Relationships matter • Serendipity • Apologise and forgive
- 21. For leaders… • You are a role model • Site leadership • Community engagement
- 22. Thanks! • t: @_dth • f: fb.me/dth • e: d@h6n.co
Editor's Notes
- Why distributed? Intentional vs accidental
- Why distributed? This is about distributed engineering teams, subtle difference from remote engineering. Most of these suggestions can still work This is not a solved problem I don’t have all the answers, but I do have a list of things that have worked for me
- 18 years, one failed startup, finance in Sydney and London, Morningstar CTO, running teams in SYD, BKK, SZN, CHI Twitter NYC, Facebook NY running teams in NYC, MPK, SEA.
- Hire full stack. You want decision making to be centralised as much as possible. People people may seem counter intuitive. Particularly relevant for remote workers. Asymmetry is bad. Hybrid teams are bad. Critical mass is important Rule of 3, Clusters of related projects Autonomy
- Hire full stack. You want diversity of talent. You want to allow local decision making
- Particularly relevant for remote. Notion of introverts being remote isn’t true.
- Asymmetry = one person in one location, many in another location. Hybrid = some remote, some distributed, some hq. Both = no
- Starting a team? You need three people, if not immediately, then an immediate plan Starting a project? You need a roadmap for three. Starting a group? You need three. Why 3? Smallest number that isn’t 1 or 2. Allows for leave, attrition, Why not 1? Diversity of opportunities, diversity of talent. Extending the rule of three. Create clusters of related projects. Take advantage of colocation. Colocation is fairy crack. For example: infra (messaging storage; message routing; iOS infra) Tweets, Timelines, Users.
- Hybrid teams don’t work well. Distributed team? Give them a clear charter, clear goal and let them do it. Maximise colocation, moderate cross boundary decision making. Remember, hybrid teams suck. How to avoid silos? You still need some feedback cycle into other teams. Tech leads are good for this
- Communication Trust Timezones are important. You want *some* overlap to avoid async communication becoming next-day communication. Process.
- In general: overcommunicate Force collaboration. Move in person to online for discovreability Written communication is important. How you can be more important than what you say Health of a distributed team is in my experience, highly correlated with the health of group chat. (irc, hipchat, slack) Make sure there’s a watercooler chat experience. Posting memes, gifs, etc. Seems silly, but really helps Be visible when you’re around. Be invisible when you’re not. Establish working norms.
- get together in person, regularly. social glue is important. new hires onsite to build personal relationships fb, for example, does bootcamp for 6-8 weeks, split between MPK and other office
- Need some overlap, otherwise pay the penalty of async communication becoming next-day communication. May need to adjust working hours to compensate.
- Process is a bad word. s/process/how we work/ Regular sync points How do you communicate? How do you course correct? Async Monitor the work, not the workers
- Communication Assume trust and good intent. Maintain active dialog when things go wrong. We tend to reach to those closest to us. Relationships matter. Invest the time in them. Allow for serendipity. Offsites. Open questions. Pauses. Apologise, accept apologies. Forgive, be forgiven.
- You’re the role model Site leadership Community engagement Positivity
- Thanks to @raffi, @dloft to giving me the chance to experiment with this at Twitter. Thanks to Philip Su for advice on the psychology of being apart. Contact me, I’d love to hear from you. t: t.co/dth f: fb.me/dth e: dth@h6n.co