If you’re one of the few remote developers on your team and you’re new to the company or working with people you’ve never worked with before, you may have experienced the pain of relying on people who are unresponsive. This is easier to do when you are remote and they don’t have a face to match the name or much of a relationship built up. Instead of familiar faces in the office, they (and you) are just names on a screen. And unlike being in the office you can’t just walk over to their desk to get what you need.
This can be a pain for any kind of team, but being distributed amplifies this tenfold. This always seems to pop up at the worst times…
- you’re stuck and need an answer now
- your project deadline is rapidly approaching
- the client or stakeholder is pushing for an update
- there is a lack of accountability for the right team members on the project
- it’s a team that is not officially on the project
…and if this is putting your project at risk, all the programming skills in the world won’t make one bit of difference.
In an ideal world, any company with virtual employees should have processes in place to make sure this never happens. But it’s not an ideal world and distributed teams are still new to a lot of companies. Problems with remote work tend to rear their heads when it’s almost too late.
So you need a quick solution for the short term: a “man on the ground”. This person should be someone in the office who you ideally already have rapport with that can fill the role of support for any issues that are holding you back and someone who can speak for you and put in a good word. Having someone who is physically there in the office who knows the players involved can help resolve these issues much more quickly. And finding someone to help you out in a pinch is going to be a lot faster than building up a relationship with everyone on the team you’ve never worked with before.
“Isn’t this the Project Manager’s job?”
It’s important to note that this person does not necessarily need to be your Project Manager, if one even exists on the project at all. It’s no secret that developers sometimes tune out the PM on a project due to being so focused on the code and trying to prevent a break in concentration. The PM might even be remote too. Having another “individual contributor” that has an “in” with the people you need help from can help clear those hurdles that sometimes pop up when cutting across business/PM/developer lines. In-group dynamics being what they are, helping a fellow developer out is often taken with more consideration. Now, if your PM has great rapport established with the team you need answers from, then great. But looking at others in the office who can help fill this support role is a good place to start.
Finding a designated point-person will greatly help you out in the short-term, but you don’t want to put your project and potentially career in jeopardy by not building up those necessary relationships. In the long term there are lots of things you can personally do to establish rapport with people you haven’t worked with before so that you don’t always have to rely on this point-person. If you have regular trips scheduled or any upcoming trips scheduled to the office, check out this other post I wrote about how to make the most of these on-site trips, which require you to be more deliberate than just showing up, doing your work, then flying back home at the end of the week.
Operating in remote and distributed teams can feel strange sometimes. If you liked this content, sign up for more like it below. I’ll send an email to you around twice a month with similar content.