Thinking about Team Structure
Distributed teams aren’t new to software engineering. It’s safe to say that those who have been in the industry for a while have worked with people who aren’t physically located with us. In my experience, the situation has nearly always been where most of the engineers are in one physical location, with a few scattered around the world.
Out of sight, out of mind.
I was in charge of a few teams that had this hub-and-spoke setup a couple of years ago when we started thinking about optimizing collaboration. We realized team collaboration is most efficient when everyone was in the same physical location. Our objective, then, was to get as close to physical presence as possible.
Microsoft did research into something they called Embodied Social Proxies a few years back, where they concluded that having a dedicated, always-on machine for video chat not only included the remote engineer in tacit conversation, but caused others to collaborate more with him.
So, our remote engineers became “floating heads” on a monitor.
Embodied social proxies work to counteract the “out of sight, out of mind” tendency we have as humans. And in the last few years, new companies have surfaced offering formal solutions to this problem. Gusto has a Double Robotics telepresence robot that we’ll be bringing online soon, for example.
With technology options like embodied social proxies (always-on video chat) and Slack, we know we can get remote engineers to collaborate effectively with their teams. So when we think about team structure, one approach is to simply attach Denver engineers to those in San Francisco so that all teams have both remote and physically present engineers. Engineering teams in San Francisco are established with deep knowledge of our codebase. New Denver-based engineers would ramp up quickly working with them.
But something about that option feels off.
Pods, man.
I’ve had a lot of conversations with engineering and product leaders here at Gusto about team structure. One line of thinking predominates — we should endeavor to create autonomous development teams in Denver.
On the surface that feels right, but why?
In The future is podular, David Gray writes:
If you want an adaptive company, you will need to unleash the creative forces in your organization, so people have the freedom to deliver value to customers and respond to their needs more dynamically. One way to do this is by enabling small, autonomous units that can act and react quickly and easily, without fear of disrupting other business activities — pods.
Imagine a world where autonomous pods existed in Denver, just as they do in San Francisco. Imagine a world where Denver-based development teams could make and execute on important, revenue-impacting decisions in isolation. Imagine a world where we could point to Denver and say something like “our mobile apps are developed there.” That’s the world we want to create. It’s aspirational, and it’s efficient.
Getting there.
I’m still the one and only engineer in Denver (although we’ve been doing a lot of interviewing). While my job is to help build out our engineering teams here, I also need to be fluent in our codebase. Unlike other companies, where engineering leaders act like baseball managers watching their players field grounders and hit doubles, ours are like cricket captains — they take to the field and still play the game well.
Code fluency creates pragmatic managers.
So, I’m working on features in our codebase just like everyone else, and am attached to our Growth team in San Francisco as per aforementioned hub-and-spoke setup.
But as more engineers start with us here in Denver, we’ll pull a pod out of “Growth” and spin it up here. We’ll learn. And, sometime in 2017, we’ll start spinning up more pods after we’ve learned from the Growth guinea pig.
Giddy up.
