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