If we ignore the big flaming dumpster fire that is COVID for a moment driving almost all technology companies to go 100% remote, in the digital age more and more software development is being done by geographically distributed teams. For example, I work as a Product Manager for Nordstrom based out of Chicago IL. I currently have the honor of working with 10 total software engineers. 7 of them are based in Seattle, and 3 of them are based all the way in the Ukraine.
Working with a geographically diverse group of engineers is awesome. It brings new perspectives, and new team dynamics that on the whole build towards a stronger product. Geographically diverse teams result in individuals bringing different ways of thinking about problems and solutions to the table. Of course it is not all rainbows and butterflies. There can be challenges, especially for teams as they are forming. For example, you need to adjust meeting cadence to if possible so the time works for all team members.
Oftentimes, cultural differences can cause significantly separate needs for how feedback can be delivered or received. For example, I find that for many engineers based out of European countries, their preference is blunt and overly direct feedback. Part of this is a language thing, if teams don’t primarily speak the same language, sometimes flowery style adjectives that people tend to use (*cough* me) to try to better describe the sentiment behind a piece of feedback can get lost. However I personally attribute the majority of this preference in feedback delivery to just different cultural norms. Some folks and / or cultures bias towards the most direct feedback possible, while others take a little more finesse.
Time is not your friend with geographically diverse engineers; it impacts feedback loops, which impacts value to the customer.
One of the biggest drivers of behavior change when moving from a team of engineers all working from one location to geographic distribution can be of course differences in time zone. At Nordstrom we have about 2-3 hours of overlap with our Kyiv engineers. That means that for an engineer based in the same time zone as you, you have a whole 8 hours where you can talk through a feature, time for the engineer make changes, and time for design and product provide feedback about those changes. THEN, the developer has time to react to those changes and get a second version stood up and ready to go before the day ends. As a result, if you have an engineer, a product manager, and a designer all in the same time zone, you have 8 total working hours all overlapping where feedback, changes, and iterations can be produced. HOWEVER if you have an engineer based in a different time zone, you’ve got significantly less hours of overlap.
So instead of having multiple opportunities to ideate, build, get feedback, and ideate again most days you can only have one feedback cycle if your team has an overlap of 2 working hours. Feedback cycles are important, check out this article on the difference between Kanban and Scrum to see some examples of how this comes to life.
This is in no way saying that less overlap in hours means less gets done. That engineer based in another time zone still works a full 8 hours, and is still an awesome engineer with a great skill set. It just means that the active time you have for feedback loops is condensed significantly.
Not only that, but you also need to think about the quality of your feedback and the amount of data you can convey in each round. With an in person engineering team, you get to talk directly, convey not only the data and information around the feature you’re implementing, but also emotional reactions to different things that are said.
Not all feedback formats are created equal.
Now, in the time of COVID, a bunch of teams are working remotely. So we receive a little less data than you would get in person, but you can still see peoples reactions, can still talk through problems and share your screen.
However when you are working in off hours (I.E. the time when you are working but your engineering team is not because it is their nighttime), many people rely on text to convey feedback about a feature or idea.
This is the big mistake
Most of the time this comes in the form of Jira ticket comments, or slack messages. If you think about the amount of data or information you can convey at a time, the highest quality of data delivery is in person. Next would be over video chat, and the very last form would be forms of text based communication. It is just so much less efficient. Showing what something looks like is much more impactful than telling someone what it looks like. Think about presenting anything; instead of having a slide full of text, show a picture or video and speak to what is happening. I don’t need to ask you to consider which is more impactful.
So we have established that the faster your feedback loop, the more value you will deliver to the customer. And the more time you have working the same daylight hours as your team, the more opportunities you will have to provide feedback. The more feedback and the faster the frequency of delivery, the more value delivered to the end customer. And thus, if you are working with a team in a different time zone, you have less overlap in working hours, and as a result less total time that you can give and receive feedback on features your team is working on.
Not great, but there has got to be some sort of a solution to help!
There is!!
Screen recordings.
Video recordings do take just a little bit more time to make than something like a comment on a Jira ticket, but not much more, and the impact this can have in terms of how much is conveyed for feedback is incredible.
All you need to do is get a basic screen recorder and a microphone (which of course you already have if you’re working from home). I use a chrome extension literally called “Screen Recorder”. It is free, and I can quickly record my screen, include the cursor, and add my voiceover.
So now, I am trying to build the habit when working with an engineer in another time zone on any sort of feature, of making a screen recording and walking through specific points of feedback. It conveys so much more, walking through, pointing out specific features, points of confusion, etc. This provides the engineer with a ton more context on changes you are asking for, or updates needed. The end result is that using screen recordings and a voice over is a pretty good attempt at trying to fit the information that would normally be contained in multiple rounds of feedback into one rich method of information delivery.
Does this solve the problem of just not having as much working hour overlap with offshore engineers? No. But what screen recordings do is they significantly deepen the level of feedback normally provided so that you can convey more in a shorter amount of time.
It takes no money, takes almost no additional time, and I would highly recommend anyone working with any engineering team at all try this out and see how it goes.
About the author:
Ben Staples has over 7 years of product management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com
I do product management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Want even more book recommendations?! Contact me!
Comments