How we work as a distributed product team
A couple years ago I wrote about why we decided to be a distributed team when we founded Talko. I didn’t say much about how to be good at it. That left some readers unsatisfied. I’ll take the bait, but must first stipulate:
- There’s no one way.
- Context matters much. Your people, your history, your project, your team size, etc. are all unique to your environment and must be accounted for.
- So, your mileage may vary with anything I say here.
Peace and love. Now let’s go.
It’s possible to decide to be distributed for all the right reasons, but to screw it up royally with the wrong tactics and tools. The more a team is distributed, the more potential for people to move fast and get many things done, but for those things to not necessarily be the right things.
Why does this happen? Because communications is really, really hard. It’s hard when everyone is together in the same room. It’s harder when people are separated by time and distance. In both work and life, there’s one thing I’ve learned about problems:
All problems are people problems, and all people problems are communication problems.
Doing distributed team projects well requires that the organization and its people, tools and processes all facilitate open communications and access to information at the lowest possible “cost”.
Scheduling a bunch of meetings is high cost. It’s not the answer. You need to set things up so that, as much as possible, great communications happens naturally, serendipitously — by accident if you will.
At Talko, where we are split between Boston, Seattle and San Francisco, we’ve benefited from having previously worked together. We knew each other, we respected each other, we’d built software together before. That’s a huge running start that many don’t have. But it didn’t eliminate the need to be intentional about distributed team practices and processes.
This is not all-inclusive, but here are several things we do to help us communicate effectively without ever being together in one place.
There is no hub. There are no spokes. We are a constellation.
People often ask “Where is Talko ‘based’?” Many assume we’re based in Boston because we have more people there than in Seattle or San Francisco. I say Talko is based in Talko (the app).
Sure, we have an official company address for the purposes of incorporation. But we don’t think of our team as being based in any one location. We give equal weight to our presence in all three cities, regardless of how many people are in each.
We refer to our team as distributed, not “remote”. The word remote infers that some aspect of the team is centralized and others are remote. “Us” and “them”. “The core” and “the others”. Watch the toxicity take over once people start thinking and acting like this.
We model our company as a constellation, not as a hub with spokes.
This isn’t the only model that works for distributed teams. Arguably, it’s not possible for a much larger organization. But I believe it’s best for any small team that chooses to be distributed.
This sounds ethereal when talking about it as an abstract model. But the model, the words used to describe it and the way it’s drawn on a napkin matter a lot. These things shape the team’s mindset, how people relate to one another, and how individuals perceive and act their role on the team. They also inform the tactics necessary for the organization to be true to what it wants to be.
For example, at Talko we encourage people to work from home 2–3 days per week. We do this even though we have office space in all three cities. It’s a tactic that helps our people empathize and relate to one another as equals, always, regardless of how many team members live in one city versus another. It’s how we avoid situations where several people huddle in a room to tackle big problems and make important decisions, then later realize that ‘elsewhere others’ needed to be part of the conversation. Tactics like this help avoid obvious sources of misunderstanding within a distributed team.
We have a clear set of top-level projects.
A project is substantive enough to be sustained beyond any particular sprint or milestone.
It has a well-defined team of people working on it. Unless you have a 1 project operation, which may be likely in the early days, a project team is a subset of the overall team. It’s essential that everyone in the organization knows who’s on each project.
A project has well-defined goals, stories and designs, milestones and timelines. Project team members are all deeply intimate with these things. All others in the company understand at least enough to know and support why the project is essential to the company’s mission.
We have 5 top level technical projects at Talko: iOS App, Android App, Web App, Service, and Slack Integration. These are the set of sustained technical efforts that we organize, track and report around. We adapt our tools to work for our preferences. The image to the left shows how we use Epics in Jira as the organizing model for our projects. This is not exactly true to the Agile (capital A) definition of Epic, but it works well for us right now. We’re rarely compelled to be 100% true to the dogma of the processes or methodologies we use. We do what works.
We invest in organizing our tools.
There’s virtually always some way, some how for someone to get whatever information they need to do their job. The question is — at what cost in time, attention, disruption?
Let’s say you need to come up to speed on the technical design for a feature. Do you:
- Schedule a meeting with the project team.
- Interrupt a developer to ask them directly.
- Go get the 2-page spec (because you know right where it is) and take 5 minutes to read it.
The first two options are costly. Operate like this as a distributed team and nobody will ever get anything done.
The point is that everyone needs to know exactly what tools are used for what purpose, and where to go to find what they need. Nobody should ever be uncertain of where or how to find something at the moment of need.
We use many different tools for different aspects of the business at Talko. Jira for projects, stories and bugs. Office docs, PDFs, and increasingly Quip docs for features that require specification. Github for source control and code review workflows. Amplitude for app analytics. Zendesk for support. Nagios, PagerDuty, Crittercism for error reporting. And more.
Beyond the specific tools, the important thing is that each is organized for maximum transparency and quick access to information. A simple example can be seen in the image to the left. It shows how the Product Management subfolder is organized at one point in its hierarchy in Dropbox. It takes some time and care to set up at the beginning, but it saves time in spades later on. There’s never a question from a developer about where to find, for example, the app analytics event schema spec — of course it’s in Product Managment > 01 Feature Specs > Analytics.
We operate on a cadence that naturally keeps people in sync.
We use cadence as a tool to achieve common awareness across a project team. Quick cycle times force regular communication and help people self-organize with a calendar that is near-clear of expensive meetings.
Shorter than typical sprints/milestones/releases create natural sync-ups, both planned and ad-hoc. It makes it difficult for things to slip through the cracks, and easy for a project team to shift priorities quickly when necessary.
For example, we do 1-week sprints. For co-located teams I’ve worked with in the past I’ve always preferred 2-week sprints. However, many things can change contextually over a 2-week period. One-week sprints require conversations to happen with a tempo that ensures people don’t fall out of sync about what matters most. No fancy meetings required typically, just a quick, often ad-hoc check-in as we move from one sprint to the next. Of course, for such a discussion to be quick it presumes that people have done their jobs prior, e.g. PM has prioritized stories and bugs for the next sprint and can succinctly communicate what and why to Dev.
Our work is done and ‘documented’ in our communications.
We write documents and detailed specifications for several things. A new and big feature area. Test scripts. Technical architecture. And more.
However, we produce far fewer documents relative to similarly scoped projects of several years ago. The document (or email) is no longer the primary artifact around which we do our work. There’s a flow to our communications and decision-making that is far more organic and fast-moving. It happens when we’re mobile and on-the-go as much as it does when we’re at our desks. It centers around text and voice messages, photos and screen-shares, and quick calls when we need to converge urgently.
All of this happens with very few scheduled meetings or document reviews.
The challenge is how to ensure all team members have access to the information they need to do their job, or to simply be an informed and participating team member. There’s no longer a presumption that everything is written in a document or summarized in mail. In fact there’s a preference that it’s not. Instead, there’s a presumption that key issues discussed and decisions made in the flow of conversation are “on the record” so that team members who weren’t there can be aware.
Tactically, there are several tools we use to make this real. One of them is our own. Since mid-2012 we’ve had all of our daily standups, design & architecture conversations, bug triages, all-hands meetings and 1:1 discussions in Talko. The fact that all conversations — LIVE calls or messages — are saved in Talko means that key issues or decisions are easily flagged, tagged and discoverable at any time in the future. This helps in a range of scenarios. When an engineer misses daily standup but needs to quickly know the status of another engineer who’s working on a blocking bug. Or, when a PM is trying to remember why a particular design decisions was made for a feature implemented long ago (see image).
Slack is another tool we use to support transparent, real-time access to our workflows and communications. We use many integrations — Github, Jira iDoneThis, Talko, Zendesk and several others. Essentially, the tool of choice for every aspect of the business is integrated with Slack. As such, Slack has become our hub for real-time status of any aspect of our engineering projects. A great example is our #github channel shown in the image. It provides a simple, stream view into what everyone is getting done. Like in Talko, what turns this from an activity stream to an irreplaceable productivity tool is the fact that all channels are easily searched. Anyone can find something that was said or done in the past and which may be important to recall at the moment.
Tools such as Talko and Slack won’t solve all communications problems. They can’t communicate for you! But it’s in tools like these where work is getting done and ‘documented’ these days, much more so than in files and emails. By turning conversations and activity streams into persistent, searchable objects these tools help our team avoid the lost time, misunderstanding and strained team dynamics that otherwise occur when people are moving fast and making decisions in the flow of communicating.
We treat team operations like a product.
A software product is never done. It can always be made better, simpler, more capable, more performant.
The same can be said for how a team works together. We treat our organization and its tools, processes and practices just like we treat the product we build together. We’re motivated to make things better.
We’re far from perfect. Sometimes we do things poorly. Sometimes things slip through the cracks. But we’re conscious and aware when these things happen. We talk about it. We make tactical adjustments when we’re convinced the benefit will outweigh the cost.
That is why, for example, I emphasize that using Epics to organize projects in Jira works for us “right now”. It’s why we recently made a change in how we do app analytics and the tool we use. It’s why we’re embracing an organic team shift from documents as files in Dropbox to Quip docs for many things. It’s why we’re currently contemplating changes in how we communicate client/service deployment dependencies to better support our aggressive multi-app release goals. And so on.
What works for us now as a 12-person team is not what will work for us in the future. As the team and our projects grow we will adapt the way we organize our work, how communicate, the tools we use and how we structure them to meet the needs of the business at any particular moment in time.
I hope this was useful. I’d love to hear your thoughts, feedback and questions.
