Establishing a Good Product Relationship with a Remote Engineering Team

Guest Post by: Stef Orzech (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Alex Berman]

So, I’ll start with this: a little while ago, I was having a difficult video call with my tech lead. We had just hired a new VP of Product who was radically (and rapidly) changing our product development process, and our engineers – based remotely, in Argentina – were struggling to keep up.

“To be honest, I think we’re still just figuring things out over here,” I told him. I didn’t speak lightly; I knew our engineers were struggling with the changes and that what they needed most of all was definite information, and fast.

But rather than pressing for answers, my tech lead simply sat back in his chair and shrugged. “Ah, well,” he said, “at least it’s better now than it was before.”

“Better?” I furrow my brow incredulously. “What do you mean?” I asked.

“Well, before, product knew what was going on and engineering didn’t.” Leaning forward again, he said, tongue-in-cheek, “Now neither of us know.”

I start with this story for two reasons. First, it illustrates (admittedly – but I’d argue necessarily – in a harsh light) the difficulty of communicating effectively with an entirely remote engineering team. Second, and more important, it shows the demotivation and binary thinking that can result from bad or nonexistent communication. In this particular instance, of course, there were some other factors at play – but even so, it seemed necessary to me to ask: How has this happened? And what can I do about it?

Over the past decade, working with remote engineers (at least in some capacity) has become increasingly likely. Due to the heavy globalization of the tech sector – a challenge at once propagated and mitigated by improvements in videoconferencing and file sharing software – product management can now involve setting priorities for developers across the world as well as around the office. Even though it’s documented as a difficult place to work, companies hire remote developers (and even entire teams) because it’s more cost-effective.

But physical distance is complicated by other distances, as well. In my last product position, my team consisted of two engineers (one of them my tech lead) on the West Coast, three engineers in New York (and one in D.C.), and one engineer in Iceland. With Iceland five hours ahead of, and the West Coast three hours behind, New York, we had as a team only 2-3 hours a day in which we were all working. In my current position, my developers aren’t far removed in terms of time, but they’re over 5,000 miles away, live in a vastly different socio-economic culture, and speak an entirely different language.

So, what can one do? Here are the three most critical things I’ve learned about working with a remote engineering team.

Regular visits are crucial

All of the companies I’ve worked for that have employed remote engineers have fortunately also believed in scheduling regular visits to or from the central office. It seems obvious (because it should be), but there is nothing that can replace face-to-face interaction. If your company brings remote workers to you, great — but it’s even better if you can arrange a trip to the remote office. This is because understanding how one of your remote engineers works and what he or she is like as a person is not the same thing as understanding the culture within they’re working. Argentinians, for example, are far more laid-back and familial in their office culture: their after work celebrations are often much more low key, and it’s common for friends and children to attend as well. People are in general more friendly with each other, whereas in New York we’re nice but also more business-focused and to-the-point. Without understanding this culture and how your business fits into it, you won’t be able to build the best team possible. Your team has to work with the culture, not against it.

Regardless of whether or not you can visit the remote office, it’s essential that, when your remote engineers visit, you use that opportunity to get to know them socially and to introduce them to different parts of the organization they might not see. Engineers are great problem-solvers, and chances are the engineers on your team are smart, dedicated people – as a product manager it’s your job to make sure they have the right information, and the best way to do that is to get them into as many in person, non-tech meetings as you can:

Contact your account management team and see if your engineer can sit in on a client call or, even better, go on a client visit.
Ask if they can sit in on a sales call so that they understand how they product is being sold.
Set up a meeting for them and your product marketing manager, so they can understand how what they’re building is being represented and packaged to the public.
Let them sit with a support represented so that they understand the hard work that’s done to triage bugs before they’re sent to engineering.

Any non-tech information or experiences you can get to your engineer while he or she is visiting is crucial for making sure he or she has the right information with which to make decisions while remote.

Team communication isn’t enough

You should already being having frequent meetings with your team, even outside of the traditional agile meetings like backlog grooming and retro – but that’s not enough to ensure that your priorities are getting across, especially if you’re working primarily though your tech lead.

One of the most important process changes I’ve put in place over the past few months is that I must meet individually with each engineer on my team at least once a month. We must meet not because I am their boss (they report to Engineering, not me), but because otherwise there is a high chance both that information will get lost and that the good ideas or talents of some individuals will go unrecognized from a business perspective. Doing these 1-1s is a small time commitment on my part (it requires between 1-2 hours each week), but the benefits far outweigh the costs.

Understanding engineers’ motivations and talents can help you flesh out work more effectively

Without a doubt one of the biggest mistakes a new product manager can make is to view all engineers as equally capable and interested in a certain type of project. Every engineer is different, and if (like me) you’re fortunate, the engineers on your team will have a wide range of motivations and interests. Some devs love open-ended research, others hate it; similarly, some devs are interested in technical projects whereas others want to work on more client-facing projects. While it would be a mistake to prioritize work based on what your engineers want to do, or to only assign certain types of work to engineers who enjoy working on those projects, knowing motivations and talents can help you to build a more engaged, collaborative team.

Understanding engineers as people, and allowing them to understand you as a person, can help you build a strong working relationship

Just as it’s not enough to hold only team meetings, it’s not enough to talk just about work during 1-1s. Especially with remote relationships, it can become dangerously easy to reach out to someone only when you need something from them. Regular 1-1s create a space to learn about who your engineers are as people, and what their lives are like. Not that you have to get too personal — I’ve found it’s useful to ask about the small things (where they may be going on vacation) as well as the big things (are they happy in their current role? What would they like to be doing in a few years?). Although it may seem small, it goes a long way to understand whether someone on your team views their job as just a job or as a role they really love, whether they see themselves climbing the ladder over their career or feel that management is the last thing they’d like to do.

Getting the relationship right is more important than getting the product details right

I think this is probably the more controversial of the three things I’ve learned recently about remote communication — and, to be clear, I’m not saying details aren’t important or that having the right communication tools doesn’t matter. But I say this because I’ve worked in product organizations that view their devs purely as resources and believe that sending extremely detailed product specifications to remote engineering teams is the best way to work. I’ve even seen this in interviews, when I’ve asked candidates how they adjust their product management style to work with a remote team; they emphasize being more detailed and precise, more calculated.

While being detailed is important, however, it shouldn’t come at the cost of your engineers’ autonomy or happiness. It is much better to focus on building a working relationship with your engineers in which everyone feels comfortable asking questions if they need help. Again, your engineers are great problem solvers — it’s far more important for you to make sure they have the right information about the problem and its context rather than to make sure they know exactly how they should build a solution. Focus on the working relationship you’re building with your team, and trust/guide them in building a great product, not only as workers but people — just make sure they’re attacking the right problem.

About Stef Orzech
Stef Orzech is a people-focused product manager who cares about building strong teams as well as great products. Originally interested in law, he decided to go into tech after learning how to code (by necessity) at a Hackathon. In his spare time, he enjoys rowing and cooking up a storm.

More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

Conducting regular 1-on-1 mentor-mentee chats
Sharing experiences with the larger Product community
Participating in live-streamed product management lessons and Q&A
Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy