“We just pushed it live,” the release manager belts out, to a team fresh off the battlefield that is software product development. We had successfully released our new feature to hundreds of thousands of users, after what seemed like an eternity — ten sprints, copious amounts of planning sessions and retrospectives, and the quintessential grouping of stand-ups.

A huge sense of achievement filled the room, as we adjusted our postures in the sea of IKEA-cushioned office chairs. Some people have bags under their eyes, having just survived too many sleepless nights. Others sipped their coffees, or dropped tea bags into piping hot mugs of water.

The team was content, but we were also cognizant that the high we just experienced would only last so long, like a newly minted blackjack player who wins her first hand, aware that there was more ground to cover. Sooner rather than later, we’d hop back on the bus, put it in drive, and pull out onto the road to continuously delivering a great experience to our user base.

Interestingly enough, this was my first time experiencing any of this. I was fortuitously dropped into this arena, with not a hint of prior experience building and releasing products. I was new to it all, a team whose mantra was to create, build and release.

The team setup was also hard for me to grasp, because it included both an in-house development team, and an outsourced development team. In retrospect, it was probably the best place to start, given that external development teams are now more commonplace.

As I reflect on that time, there are some aspects of the experience that would have been helpful to have ahead of time, given that it was all foreign to me. In particular, how to work with, understand, and successfully manage a distributed development team. While this is not a complete list of everything you need to know, it’s a set of learnings that you might find helpful, if you happen to be swan diving into the deep-end of leading a distributed development team.

Invest in complete integration

One of the more difficult aspects of working with an external development team is figuring out how to build them into the company’s DNA. There are obvious challenges you’re dealing with: they’re sitting in a separate office, perhaps not speaking with you in their native language, or even in a completely different time zone. While keeping those in mind — and before getting into the details of what the actual development looks like — it’s crucial to get them fully invested in what you’re doing. Why are you embarking on this mission? Why is the vision important? What’s the culture you’re trying to build? Most importantly, the value you’re delivering to your users.

Even if they’re not sitting next to you, try to re-create that experience as much as possible for them. Give them swag (t-shirts, posters, etc), put them through some form of the company onboarding, live stream all-hands meetings for them. Or, if they’re only a short flight away, bring them over for big company events, parties or milestones. You’re all part of a team. They should also come into work feeling excited and ready to build an amazing user experience. Invest in the team, and the rest will follow.

Over communication

When you’re leading and managing a distributed development team, there will be lots of friction working against you that you’ll need to combat — poor assumptions will be made, team member conflicts may surface, important (and incorrect) company information might come out through rumors, etc. Once you own that and accept it, you’ll need to always put more fire power behind your communication and over do it at times. You may be getting ready to start your Q4 roadmap, and in order to successfully execute it, you may realize that you need a few extra planning meetings, a daily stand-up instead of twice a week, or even more alignment with stakeholders.

If your company is making important changes that affect the entire team, everyone needs to be aware of it right away, and understand why they’re happening. There’s plenty of both formal and informal communication that goes on internally at the office, and you need to be ready to translate that to the distributed team. Even if that means going a few steps further with your communication levels.

Share the data and customer feedback

Since you’ll already be sifting through data in your analytics tools, customer surveys, and user testing results, it’s also important to relay those insights back to the distributed team. It’s not enough to go through the develop process, ship, and then quickly move onto the next item in your backlog. It’s your duty to keep the team well informed, and let them know that whatever they’re working hard to deliver will be analyzed after release (not thrown over the wall, never to be looked at again).

For instance, you can send out a weekly report with your main KPIs, so they can get some insights on how well a certain feature is doing, or if the team is on track to meeting certain goals or milestones. If you’re tracking how much the team is completing in each sprint, and if your project release date is accurate or not, make sure that information is constantly reviewed. They should also have the chance to “get out of the building,” and sit in on some user phone calls or even participate in a user test. Everyone will be invested in trying to build the right things for your users, and your goals and metrics will have a deeper meaning than numbers on a spreadsheet.

Use your tools and processes effectively

There’s a sense of discipline that needs to be instilled, so that your overall development is crisp, efficient and productive. If you have an internal development team working on front-end development, who’s paired with the distributed team focused on the back-end, make it a point to always have them keep documentation updated and readily available. You may have negative dynamics within the team that need addressing, or have a project deadline you’re failing to hit.

Meet those head-on, sort them out as soon as possible, and don’t let them fester. As another example, if you’re using Jira to manage your sprints and releases, it’s crucial to fill out certain fields. Input your story points, write good descriptions for your stories, and add labels if necessary. Your tools and processes are a central part of what make the product development machine run smoothly, so take the time to get them right for the long run.

The adrenaline rush finally wears off, and we’re already onto the start of another retrospective before the next sprint planning session commences. Members of the team pile into a small conference room, and stare up at the large TV on the wall, as if it’s an oracle who’s ready to answer life’s burning questions. The Scrum Master opens up her computer, fires up the video conferencing, and dials in the team sitting two time zones away. Addressing the entire team, she says, “Before we discuss some of our project delays, let’s review some of the great improvements we introduced to the product. The team on Skype, how about you start us off?”

Photo above by rawpixel on Unsplash.