This is a simple little note I wrote down when talking to another company owner on the topic of moving a fully distributed team (with some folks in the same city) to a mostly-distributed team with an HQ office in a single city. It's not necessarily useful as general advice beyond that
I often advise clients that are actively focused on improving their teams to either embrace a fully-distributed team or a fully-colocated one, and to avoid other permutations of organization. Patterns that I see a lot:
- small satellite offices off a large HQ
- a handful of remote folk off a large HQ
nsimilarly-sized engineering offices- separate locations for engineering and business/product leaders
On reflection, there are two main reasons I tend to recommend that a company either completely colocate or completely disperse:
As I alluded to above, a lot of my work has been with established companies trying to improve in many ways at once. In order for any changes to stick, it's really important to carefully craft bidirectional feedback loops so that new ideas can be equitably & efficiently disseminated and evaluated. How humans are physically arranged often dooms the implementation of any changes at all before they're even attempted.
This point often gets lost, but when the physical organization is changed in tandem with other practices, the success or failure of the physical distribution of team members is rarely able to be determined.
Meanwhile, if you have a high-performing team that is unlikely to require significant changes in the near future (e.g. healthy working relationships, high productivity, no major staffing changes), then the physical arrangement of people matters quite a bit less than it otherwise might.
Sidebar: If companies want to run good experiments, it's important they change only one variable at a time if they hope to draw useful conclusions. Probably 80% of the business advice that I receive is worthless—drawn from too limited of experience to be conclusive or the result of transformational experiences in which numerous changes were implemented simultaneously and therefore can't be reliably repeated.
No matter how awesome you are at management, if there are multiple communication pathways available to solve a given problem, most people will take the lower-cost pathway most of the time. "Communication cost" in this sense could refer to innumerable sorts of interpersonal issues: time & effort required to convey information and receive responses; emotional discomfort working with particular people; or perceived career risk associated with sending critical feedback upstream to management.
As it pertains to engineering teams' physical arrangement, many decisions tend to be made ad hoc by whoever happens to be in the room or among whomever one communicates with most regularly. Many problems are solved in collaboration with the person seated next to someone or with whomever one is in the habit of working with.
A few things I've found based on this:
- Satellite offices that end up fostering mild resentment toward the HQ, in part because it's much cheaper to vent frustration internally than to directly communicate problems to a distant group
- Distributed teams that form an HQ and then accidentally become more centralized and less transparent in their decision-making, simply because it's suddenly cheaper to do so (as it turns out a lot of distributed teams are only incidentally transparent, because some amount of formality or process is necessary to make decisions over a distance)
- Teams that develop a quiet culture of complicity in inadvisably pair-programming with the same person for very long stretches of time, because of both the social discomfort of making yourself vulnerable to someone else as well as the physical discomfort of moving to a different desk
- That there's a treasure trove of stark but not-altogether-unfortunate examples from the mid-twentieth century wherein administrative assistants shaped major companies simply by being in close proximity to their leadership (regardless of their relative insignificance in the org chart)
In my rubyconf keynote last month, I cut a section about almost exactly this issue. By all means, I hope you might enjoy the talk, but I'm saddened I had to cut the most salient part to this discussion.
Good distributed teams that go about adding an HQ typically already have the culture and tools to address a lot of the potential downsides. Everyone will necessarily already know how to work with remote people and groups. Moreover, everyone should already be able to empathize with how it feels to be physically isolated from others.
If I were to establish a physical HQ office tomorrow, a few things I'd try to keep in mind:
- That the shared experience and empathy of what it's like to be remote will probably fade more quickly than I'd expect
- That remote groups will develop tighter relationships with each other and, along with it, their own norms and culture; if that's unavoidable it may as well be embraced and taken advantage of (e.g. perhaps one pod of folks will develop a speciality in a new competency like design or building mobile apps)
- That it's convenient to make decisions in the privacy of a physical HQ but that I'd want to actively foster a sense of fairness with non-HQ-residing team members (I like the idea of establishing very clear and transparent processes for how decisions are made, even when the data that flows through those processes needs to be kept private)
- That forming an HQ represents a kind of organizational optimization—helping the team better do what it already does—and that if the team ever wanted to substantively change how it worked in the future, "deoptimizing" by switching back to a fully distributed model first might be appropriate (if expensive) step