For years technology leaders have emphasized the importance of their teams working face to face, but the rise of remote and global teams is making that increasingly harder to do.
I’ve spent the last eight years working with people all around the world, and I’ve encountered many global teams that work together incredibly well and others that are a disaster.
Thanks to some wise colleagues, I’ve learned a lot that can help product teams be successful, whether they are across a table or across an ocean.
1. You need more context than you think
I once encountered a very capable team that was working on what looked like a straightforward product, an eCommerce product for home goods. But they weren’t making progress, and it was a bit of a mystery – until we realized that no one actually used those particular home goods in that country. When we took the time to help the team understand the product and how people buy it, the speed picked up a lot.
In another instance, a colleague of mine who was working with a new client asked the client about the company’s business objectives. The client’s response was about the deadlines for the next two product releases. When my colleague kept pushing, they determined that the real business objectives involved capturing a part of the market that the company had been unable to get before. Once he got the client thinking about how hitting new goals and not just meeting commitments, it changed the relationship.
At 3Pillar, we believe in the Product Mindset. Our goal is to build for outcomes for both the company and the customer. Everyone on the team needs to understand what those outcomes are, so they are thinking about them in every little decision they make.
People underinvest in context. They don’t take the time to help team members understand the business, the customers and the product. They have a roadmap, but they don’t make it simple enough so that everyone on the team – from the C-suite to the engineers – understands why they’re doing what they’re doing. Time and talent are a company’s most precious resources. Context allows team members to assess where their focus and time are best spent on a micro level. Which features do they spend a little bit longer getting right, and which ones do they say are good enough as is?
When a team understands context they can:
Using this mindset, one of our teams, for example, realized that they had created a product that involved clicking six times for the user to get a feature that should have taken one click. The team made changes so that the feature automatically loaded without additional input from the user. Was that an obvious improvement? Sure. But they did it without a ticket, discussions in sprint planning, etc.
Giving a team context is about taking the time to do onboarding, having updated documentation, giving regular updates and being willing to spend time answering questions so no one is afraid to ask them.
2. Relationships matter
I thought my first trip to Romania was going to be rough. I had just taken over from someone who was in a bitter conflict with the Romanian team leaders. What I didn’t know is that I resolved the problem long before the flight landed. It turned out that the time I spent with a Romanian senior director when he visited the U.S. had created enough trust that the conflict evaporated.
I’m writing this on the way home from my fourth trip to Romania. I’m pretty tired from tackling some big organizational challenges and staying up way past midnight most nights. I’m so grateful to work with such a brilliant, humble, dedicated and hardworking crew. They are also a whole lot of fun.
We didn’t get to this place overnight. It took time to reach a level of trust and effectiveness. The best place to start is by assuming good intent. Most people are trying to do the best they can with the information, resources and knowledge they have. Even when there is a problem, it’s best to start with the assumption that it is a misunderstanding.
We can’t just rely on a one-on-one meeting a couple times a month to know how someone is doing. Group chat messages or emails can help, but that’s still not enough. We need to have a network of people who are looking out for each other and sharing what needs to be shared. So when someone gets off a call and hangs their head in frustration or sends an angry emoji to a colleague, they get support in the moment, and the person causing their frustration knows they have a problem that needs solving.
One of the most important lessons my colleague Ritesh taught me about junior team members is that they need someone who can be with them in person, watch their body language, and understand when they need some context or perspective. If you have global offices, make the investment in strong local leaders who will tell you when you’re messing up. It’s made a huge difference for me.
3. Stop the assumptions
A European colleague of mine gets annoyed when restaurants in the U.S. put ice in her drinks. I, on the other hand, don’t love that drinks in Europe are often warm. A lesson I’ve learned from this example is that we need to ask for what we want and not simply expect someone to know what we need. Subtlety hardly works, especially when you are thousands of miles away.
I’ve seen a lot of problems on teams that are caused by wrong assumptions A leader assumes they’ve been clear, but he or she hasn’t. Leaders need to be more explicit than they think, even when it feels silly.
We’ve got to check for understanding in a very respectful way. Sometimes people don’t want to ask for clarification, for fear of looking bad. Leave a few minutes at the end of a meeting to have the team summarize what they’ve learned and who is doing what.
4. Early intervention prevents infection
My mom always likes to say bad news doesn’t get better with age. Even small things need to get discussed and resolved quickly. It’s a lot easier to jump on a call and talk something through then to have a hard conversation a few months later when things have gotten bad.
I was working with a new team and made sure to tell the Engineering leader to quickly raise any questions or concerns. He did, within the first week he told me I shared something with the team they didn’t need to know that might have confused them. We got it sorted out very quickly and learned that we could hold each other accountable.
5. Have shared standards
Tabs or spaces? In order for distributed teams to work together and resolve issues without finger pointing, it is important for them to have a shared understanding of what “good looks like.” It does not help if one team follows Test Driven Development (TDD), while the other barely writes unit tests, or if one team prefers one architecture style over what the other team prefers.
They must at least be aligned to a product design and architecture philosophy, otherwise chaos will reign. Mature global teams go further, and take a scorecard approach to make sure they are consistently hitting the same notes. We developed the Engineering Health Index (EHI) to create a shared understanding of stability, maintainability, security, performance and delivery efficiency and use this scorecard to uniformly elevate product discipline and quality.
6. Design your week
If you start early to meet with colleagues in India and have to take a late afternoon sales call, it’s easy to end up working all day long and leaving little time to take care of yourself or your family. I try to design the week so I’m using time thoughtfully. I do a block in the morning to connect with global colleagues. Then I help my husband get the kids out the door and may do a workout or some chores. I do a long block in the office with colleagues before heading out to pick up the kids. I’m a night owl and do my best writing and thinking at night so I schedule some work for myself in the evening but it’s not for everyone. The goal is to plan my time so other people don’t take it all.