In the 1991 song, “Learning to Fly,” Tom Petty and the Heartbreakers sang:
“I’m learning to fly,
But I ain’t got wings,
Is the hardest thing.”
In addition to serving as some inspiration in these harrowing times, Petty and his cadre of virtuosos nicely captured the essence of what it’s like to be dropped into a difficult environment that's uncomfortable, brimming with adversity and packed with challenges that appear to be insurmountable.
If you’re like many engineering managers, product managers, or agile coaches, this might be your first foray into working with virtual and distributed development teams. Or, you may already have arrows on your back from being fully remote, and understand the gig.
The good news is, there is no better time than now to break free from the bondage of the copious amount of pains that virtual and distributed engineering teams face. You’re now able to arm yourself with a stronger bow, ready for the battlefield ahead, and primed to continue to deliver value to your customers.
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.
There are obvious challenges you’re dealing with in a distributed environment: they’re sitting in their homes, 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 customers.
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, stickers, etc), put them through some form of the company onboarding and live stream all-hands meetings for them. Keep them updated on big company events or milestones. You’re all part of a team. They should also wake up feeling excited and ready to build an amazing user experience. Invest in the team, and the rest will follow.
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, many data silos, 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 Q2 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 traditionally went 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.
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 development process, ship, and then quickly move onto the next item in your backlog. It’s beneficial 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 there are certain engineering metrics that you’re tracking to try and catch bottlenecks before they result in more schedule slippages. If you’re taking inventory on why you’re not delivering what you said you would in each sprint and if your project milestones are being hit 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.
There’s a sense of discipline that needs to be instilled, so that your overall development is crisp, efficient and productive. If you have a front-end development team who’s paired with a back-end team in another time zone, 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.
When you’re working with a virtual and distributed engineering setup, it makes it a lot harder to gain visibility on your teams, projects and outcomes. Given that engineering teams generate an immense amount of data on a daily basis (everything from Jira, GitHub, CircleCI, New Relic, to SonarCube), there’s no easy way to aggregate, correlate and analyze disparate data needed for useful insights around helping you reduce bottlenecks and being more responsive to your customers. As a starting point, introduce more metrics throughout your value chain, like pull request lifetime, deploy times, average lines per commit or average bug resolution time.
We use Kiro internally so that we have more visibility across the value chain, and it’s a fantastic way to understand at a granular level how you’re working as a team. It’s vital to be able to take inventory on how things are progressing, and if they’re not, you can triage and take action. The more visibility you can get, the better it will be for your team in the long run. Now’s the time to grab some wings, and learn to fly.