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.
Deciding that you’re going to ask your manager if you can transition from your in-office software developer job to moving to a new city and working 100% remotely can be a big decision. There are likely tons of concerns you have about how to approach this. You’ve probably practiced your pitch hundreds of times, thought through all kinds of details and prepared for every scenario you could think of.
A different approach
First off, a story. When I brought up the idea of moving and switching to a remote arrangement with my manager, I had been planning the conversation for days, maybe even weeks. I had played out every internal dialogue in my mind, imagining every scenario I could think of, what my “pitch” would be, why I was proposing this. When it came time to have the conversation I spoke for several minutes straight, basically vomiting out all my thoughts in what probably seemed like a well-reasoned but slightly incoherent ramble.
In short, the conversation started out one-sided. It wasn’t until I stopped talking that my manager asked me a simple question, one that was so simple I hadn’t thought to discuss – “So when are you thinking of moving?”
Assuming you have a good manager and have established a good relationship with them, they likely want you to succeed just as much as you do. They want to help you out.
This is not to say that you shouldn’t think through things ahead of time, but is to say that it can be incredibly easy to focus only on what’s in your own head and not what will be going through your manager’s.
This is the wrong mindset to be in.
When you approach them about this, the dream would be you’re so prepared and able to sell it so well that they can’t say no. In order to do this, you want to get out of your head a bit and into your manager’s.
When you’re stuck in your head it becomes easy to make assumptions and miss obvious things. You lose a bit of the bigger picture and more importantly, context.
You might assume your manager is thinking what you’re thinking… they’re not. They likely want to say yes, but there will be a lot going through their head too.
In order to better anticipate the questions you may get asked, consider the following concerns your manager will likely have:
Costs – Managers typically have some sort of budget they oversee, one that they also need to report on to whoever they report to, even if it’s just to the rest of their colleagues. Concerns with you working remotely may be how much it will cost the company (you may need to travel back to the main office once in a while, get setup with home office equipment, etc.) and affect the budget they manage.
Logistics – Logistics can get complicated quickly and concerns can range from bigger items such as how you will re-integrate with the team and how you will mentor others to more mundane things like desktop support. It is their job to keep things running smoothly so they won’t want this change in work arrangement to affect day-to-day operations.
Legality – Fairly self-explanatory, will you legally be able to work in the city (or cities, if you plan on moving around) you are moving to, especially if it’s in another country?
Politics – Another item that can get complicated quickly, but thoughts might be how will the organization and your team react to you working remotely, especially if the majority of the company works in-office and is HR going to present any hurdles.
Retention – If your manager is considering a remote work arrangement, they likely want to keep you at the company. Moving to another city where there will be new companies and a new network for you may introduce thoughts of a potential flight risk. Developers are a hot commodity and in short supply, so a move to a new city (especially if it’s a big city or tech hub) may cause this concern.
With these concerns in mind, use the below questions as a checklist to prepare yourself for the conversation. And don’t forget that it’s exactly that – a conversation. Between two people who will have overlapping and differing points of view and concerns.
How long will this arrangement last?
Is this a short term thing, then you move back? Or more permanent?
When exactly are you thinking of making this move?
This falls under logistics – your manager will probably have to get approvals from their boss if they have one and from HR, communicate it to the team, etc. They will also need a timeline to plan for this. And those concerns listed above – your manager will need time to think through them and get answers.
There is an office in “X city” you are moving to – why not work from there?
Are you expecting the company to pay for the move?
Will you be willing and able to fly back for occasional important meetings, planning sessions, software version releases, team building events?
For those with some sort of leadership responsibilities, how do you plan on transitioning those responsibilities either to someone else on the team or maintaining them in your remote role?
Remember that this does not necessarily need to even by a “leader” in title, but can be things like leading a small team or mentoring a team member.
What will the timezone overlap look like?
Will you work the same hours as the main office? Will there be “core hours” where you overlap with the main office for several hours?
Do you have the right communications and tools in place?
Do you have a laptop? Does it have VPN setup? Who can support you if the laptop crashes? Will the company need to provide you a cell phone? Do you have a video calling/conferencing solution in place for that visual connection?
Is there a documentation solution in place? All developers hate documentation, but it becomes ever more important to those working remotely.
Are you going to forget to check in your code?
A concern for any developer, but even more so when you live in another city or are traveling, making it harder to get important code or documents off your computer should you fall ill or disappear.
Are you going to jump ship as soon as you land?
This probably won’t be asked out right, but you may get some form of this question.
If you’re a new or less-experienced developer that wants to eventually work remotely full-time, you may already be wondering how long you need to stay at your current on-site job (or future job if you’re still looking for one) before you have the skills to go remote.
New programmers face the daunting task of drinking from the firehose when first learning how to “do” real world software development. As a new programmer you might assume that you’ll flounder without having someone there to provide support and hold your hand as needed. You might already feel like you’re in over your head. This is fine and to be expected. Assuming your company either has processes in place or a culture that supports mentoring and working alongside more advanced coworkers, working in an office does give you the benefits of being able to learn from these coworkers and get help when you’re stuck.
Note: it’s possible to get similar benefits working remotely, which begs the question of whether or not you should work in an office vs. remotely when starting out, a question that is too large to discuss here. This post is addressed to new developers who are either already working at an office job or who feel more comfortable starting off in an office while they ramp up their knowledge and skill-set. Those that want to cross one hurdle before tackling the challenges that come with working remotely.
The short answer to the original question posed is: however long you need to feel comfortable taking on more intermediate/advanced functionality and to work without much supervision.
But this answer alone is not quite helpful enough to be actionable.
What you need is a guideline to follow. Use the below as a barometer to assess when you’re ready.
When you feel comfortable with the following:
Managing tasks on your own, without a lot of help from other developers
Proactively identifying what to work on, without being told what to work on
Communicating synchronously and asynchronously within your team and the organization
Let’s take a look at each of these in more detail…
Manage tasks on your own
Being able to manage tasks of increasing complexity on your own is a great sign you’re ready to work more independently. This complexity will vary from project to project and from company to company, and as such there is not a steadfast way to gauge this, but a general rule is that you’re able to take a piece of non-trivial functionality or user story, understand the tasks involved, and implement it without constantly having to ask the senior and lead devs on your team for guidance. For example maybe you implement a piece of an internal API or refactor some critical piece of the application.
If you find you’re consistently getting stuck on tasks due to lack of development knowledge, don’t let it bother you. Just give it more time. Understand the gaps you have and keep practicing.
It should be noted that remote developer roles require a lot of self-managing, but that doesn’t mean you can or should work without having support from managers and other developers. Even when you reach more senior roles, you’re always going to be requesting help from others whether that’s talking through an architecture or taking a look at some piece of code you’re stuck on.
Proactively identify things to work on
When you’re able to take on more complex work the next step is being able to identify things that need to be worked on, things that have not already been identified. This may take many different forms – some part of the codebase that is in dire need of refactoring, some usability improvement that will greatly help your customers/users, or an internal tool you can build that will save your team loads of time. It could even be project red flags that need to be raised to your manager.
Being able to identify such things really might seem unrelated to working remotely. But if you’re figuring out what needs to be worked out without passively being assigned tasks, it shows two things: 1) – you understand the “big picture” – the larger context – enough to be able to identify weak spots, a skill that comes with experience and understanding of development and the problem domain, and 2) – you’ve built up the leadership and “self-leadership” required to be able to work more independently, a critical skills in working remotely.
Know how to communicate synchronously and asynchronously
A bulk of the communication within in-office/on-site companies happens synchronously – meetings, people interrupting you at your desk, phone calls, etc. Distributed teams need to communicate in a more asynchronous fashion – email, Slack, GitHub threads, etc. Certainly not every on-site company operates majority synchronously and not every remote company operates majority asynchronously, but in general they do.
It’s more than just knowing the tools – plenty of people use email in a synchronous way. It’s about purposefully structuring your communication to be read and replied to several hours or even days later, while allowing for the rest of the work to continue to happen. This takes practice.
Work towards achieving the items on the above list and you’ll be more prepared to take on the challenges of remote work without having to worry about also taking on the challenges of being new to the field at the same time.
So you’re looking for your first remote software developer job but all the job postings list requirements beyond your current knowledge.
“I’m looking for a position where I can LEARN, but most remote positions ask for things I can’t learn on my own”
Maybe you’re a junior developer looking to enter the industry. Or maybe you’re seasoned but looking to learn some new technology, business domain, or how to solve some technical problem not readily available to you.
This can be even more daunting if you’re thinking about working remotely where you won’t have someone right next to you you can easily ask for help.
Whatever the case may be, your goal is to be able to advance your skillset with help from the team.
Fortunately, there is a way you can figure out if the company you’re interested in working for will throw you in the deep end without a life vest or if they’ll help you while you pick up speed.
And the way of doing this is rather simple – look at the company’s current engineering team makeup. A team that will provide support will have a mix of junior and senior developers. Any company committed to leveling up its employees’ skillsets and knowledge will seed a team with varying skillsets and knowledge levels. Senior devs teach the junior devs the art of software, junior devs – through asking questions – teach senior devs how to explain complex concepts, and both teach each other things they maybe should know but might now have ever encountered, like how to solve a particular problem.
It is in companies’ best interest to have all employees grow so that each employee’s individual value to the company increases. And companies that have a mix of skillsets will be more open to applicants and new employees who might not hit all their “required” checkboxes.
“This is great to know, but how do you find the makeup of the engineering team if you’re not actually on the team?” you might ask. Again, simple. Browse the company’s Linkedin profile, looking for current developers employed there and look through their titles. If this doesn’t provide much of a result, you can see if the company has a GitHub, Twitter, Facebook, etc. presence and browse there. If all else fails, you can resort to old-fashioned email and politely inquire there.
In organizations that aren’t fully remote, remote employees can sometimes be forgotten about, seen as black sheep or as separate from the group. To your colleagues, you can be seen as that weird cousin people only see for the yearly family gathering and who people sort of know but not really. If you’re a remote worker you probably have had that feeling of being excluded from the group, or showing up and people forgetting who you are. Even if you’ve had plenty of interactions with your colleagues in the past (maybe you worked on-site for a couple years), you’re not on people’s minds as much.
Have you ever visited the office, walked into a meeting, and had someone introduce themselves as if you’re new to the company? Have you gotten that blank stare from a coworker you just talked to over the phone last week about a deliverable, as if they don’t recall the conversation? Or maybe you wanted to be put on a high-value new project but were passed over for consideration.
The on-site trip (especially for those out of the state or the country) can be a great antidote to this, but only if approached with purpose. The on-site visit should not be seen as simply “working from headquarters for a week”, but instead a strategic opportunity to maintain existing relationships with colleagues, build new ones, and advance your career. And with only having so much “face time” as a remote employee, it’s important to make the trip count.
NB: this post assumes you take regular (of whatever cadence) trips to the company’s office on-site. If you don’t, there will be a separate post detailing why you should be.
In advance of the trip
I mentioned that it is not enough to simply show up when you travel on-site, but instead to be deliberate and strategic about the trip. That might sound abstract up until now, so let’s shine some light on how you go about that. Doing the work up front to identify opportunities for yourself as part of your next trip is the most important work you can do. These opportunities can take the form of any of the following (and any more you might think of):
colleagues to meet with
— existing ones
— ones you don’t know
— ones new to the company
— someone junior to you (possible to mentor them)
— someone at your level
— someone who is a level above you (possible to be your mentor)
— hiring managers for open jobs within the company
— your manager (grabbing lunch is usually a good idea to reconnect)
— your manager’s manager, if possible
a presentation on a company-relevant topic you could give with your team members
organize a group outing
Note that it’s important to be strategic but also genuine. The list above is purposefully diverse in that it provides for opportunities that are not just beneficial to you, but to your colleagues and the company as well. Don’t express interest in projects or people just because you think they could benefit you or just for the sake of expressing interest. Have genuine interest in projects and people, and this will go very far in establishing positive relationships within the company.
Once you have a list of people, reach out to them to set up individual chats. Let them know why you’re reaching out (if it’s someone you don’t know or don’t know well). Obviously if these are coworkers you already know and have a good working relationship with, these chats can be super informal and can probably happen more organically as opposed to being scheduled. For those you don’t know as well, email is usually the communication method you want.
While the content of these emails is enough to cover a whole new post, be sure to let those you’re reaching out to know you work remotely and will be in town for so-and-so dates. This is important in non-fully remote companies as sometimes people will need to reschedule and might reschedule to a date when you won’t be in town, not knowing that you wouldn’t be able to attend.
After doing your reach outs, talk to your manager to review your upcoming trip. Hopefully your manager is already identifying opportunities for you, but it’s important to be more proactive when remote. Review your list of brainstormed people and opportunities to see if he/she might be able to help you with any introductions or ideas you might not have thought of. Obviously if you’re going to be meeting with any hiring managers in the hopes of transferring within the company, it’s probably best not to discuss this with your manager, but of course I don’t know your company’s HR policies so proceed with discretion.
Make sure your manager and your team members know you’ve got this “connecting time” booked into your schedule and that, while you’ll attend all mandatory meetings, you won’t have full availability while you’re in the office. Hopefully the trust element is already there and they’ll totally understand this, but if not make the case for how these “connecting times” are a way to make sure you’re not missing out on anything by being remote that could hurt your work and connection to the team. Few organizations will reject collaboration and anything that inhibits it, so this argument should help you in case of any pushback.
Lastly, depending on your standing within the company, you might identify a meeting you normally wouldn’t get invited to or hear about and ask your manager to get you looped in. This should be something just enough above your pay grade that it will be beneficial to you, yet not high enough that your being there will raise eyebrows. Do research ahead of time so you can have context and contribute to the discussion during the meeting.
While you’re on-site, just because you already have a list of people to meet with doesn’t mean that you shouldn’t make an extra effort to introduce yourself to people you don’t recognize.
Be sure you’re prepared for your one-on-one chats ahead of time, taking into consideration the person you’re meeting with and the context of the conversation. It will be up to you to drive the conversation, so have questions prepared, be able to articulate what you do in your current role, etc.
Towards the end of your chats, let your new contact know you’ll be back in town in “X” number of weeks. This not only provides an opportunity for follow up but also suggests these on-site visits are a regular thing for you and you’re important enough to travel back regularly.
Depending on how the conversations go, if you think both parties are open to establishing a mentoring arrangement then feel free to setup more regular one-on-ones. Just be aware, usually these can take a couple times of meeting in person to establish enough of a working relationship to pursue something like mentoring, especially remote mentoring. So just be sure to use discretion here as to avoid coming off as socially tone-deaf.
One of the opportunities I listed was giving a presentation on some subject with your colleagues. This is a great way to gain more visibility for both yourself and your team, as long as – and this is important – the topic selected is one that is of interest and value to the company. This shouldn’t be a topic on some niche part of some design or development framework, or some obscure marketing technique, but something both meaty enough and general enough that you can present to an audience of individual contributors as well as more senior leaders. This is the strategic way to go about it if you are interested in career advancement as a remote employee. While you’re not going to get a promotion out of it, it at least raises your visibility among peers and leaders in the company.
This is something to talk to your manager ahead of time about so that he/she can help promote it. Doing the presentation with a group is also a great way of not putting all the focus on yourself as “that remote employee”. This way others will not see you as separate from the group but instead an integral part of it and you’re just doing what you would normally do if you were always on-site.
In general, when you’re on-site you want to make it seem like you’re always on-site. In meetings you’re not the “remote guy”, you’re “Dave, working on the re-platforming project” or whatever. Part of overcoming the “black sheep” hurdle is in actively contributing to conversations and meetings while you’re on-site. Don’t over-dominate the conversations, but also don’t shy away from speaking up often. Your colleagues don’t hear from you in the hallway and water cooler conversations, so consider this as making up for that (I’m partly serious and partly joking here). Speaking up will help deter any notions that you’re separate from the group or that remote inhibits or affects communication.
Another opportunity mentioned was to be on-point for organizing a group social outing. In keeping with the goal of not standing out as separate from your company, such an outing should not be for the express purpose of seeing you while you’re in town, but instead for the general enjoyment of the group.
A few days after the trip
When you get back home, follow up with your manager to discuss the trip. The reason to discuss the trip before and after with your manager is for more than just administrative reasons – instead it is to provide him/her with context for career development. Discuss what you got out of it, your plans for next steps, projects you might want to be involved with, opportunities for improvement, etc. Don’t be afraid to go into detail. Your manager will likely value any over-communication over just a “yeah it was a good trip”. Your company pays a lot for travel/accommodations so it’s important they know it wasn’t all for naught. Your manager may even get clued into “goings-on” within the company that he/she wasn’t even aware of, that might be of benefit to themselves to pursue.
Perhaps most importantly there might be projects or mentorships you pursued while on-site that are a bit of a reach for you now – be sure to discuss this with your manager to see if he/she can help push things from their end. Assuming you have a good relationship with your manager – and if you’re trusted enough to work remotely you probably do – he/she should be going to bat for you. It’s often forgotten that that’s what the “HR” component of management entails. And job expectations or not, good managers enjoy being involved in their reports’ growth.
Based on the context of your individual conversations, it’s good to follow up on these as well. People can get busy, so it’s good to follow up usually a couple days after you get back home. This helps you stay “present” even though you’re not physically there.
If you’re looking for an actionable timeline, the following is one I’ve come up with having taken several on-site trips in the last few months myself and have seen positive results from:
5 weeks out in advance of your next trip – brainstorm your list
4 weeks out – talk to your manager about your upcoming trip
3 weeks out – reach out to your list to setup time on their calendars
2 weeks out – prepare for presentation or outing
1 week out – prepare for the chats you set up
While on-site – have your 1×1’s, presentation, outing, etc.
Few days after trip – follow ups
Few days after trip – follow up with manager
A side note
Before ending this post, it should be noted that if you’re not that confident in your communication skills, or are still very early on in your career or time with the company, it’s fine to take a gradual approach to this. Don’t bite off more than you can chew. You’ll have to take the advice and action plan here and measure it against your own unique scenario. You might have to skip “X” or maybe only reach out to “Y”, but the general idea and execution still stands. Maybe one trip you introduce yourself to one person, then two to three trips later you lead a meeting or go after a new job posting, etc.
I turned my “on-premise” job into a remote one 6 months ago. Here are ten observations from the experience so far, with the goal that these assist others transitioning or thinking about transitioning to remote work:
1. Able to eat a lot healthier
This was the most unexpected benefit of working remote. It’s been much easier to cook (almost) all meals at home while remote. When commuting to and working from an office it was always difficult to prep meals the night before, but working from home it’s easy to cook while working. Rather than paying for expensive cafeteria or restaurant food that is lacking in nutrition, cooking meals at home with good food from grocery stores or markets is easy.
2. Need to plan out work locations
It’s been easy to fall into a pattern of working from home and not going out to coffee shops, libraries, coworking spaces, etc. to do work. Planning out the day in terms of which locations I’m going to start or end the day at has been helpful in avoiding this trap. Usually a change of scenery has greatly helped critical thinking when stuck on a problem.
3. Easy to forget timezones
If you’re working with a distributed team, chances are there is still a home office for your company that several of your team members work from. Usually the home office time zone becomes the de facto time within which meetings are scheduled. This was a slight adjustment at first, and planning things like trying to eat lunch an hour earlier took some getting used to. Even now it’s still easy to forget this time difference sometimes.
4. Able to get more done, more effectively
Productivity is often one of the biggest concerns companies have when considering a move to a remote work model. It may be accurate to say that doubts around effectiveness are the main factor behind this concern around productivity. First, it should be noted that if you’re hiring employees you don’t trust to get work done in any location, then you’re hiring the wrong people to begin with. Second, and most importantly, the transition to a remote model is certainly no easy effort but if it’s done right and team members have proper support, productivity can actually receive quite a boost. Speaking anecdotally, I’m working with a team now that is entirely distributed across several states and continents. I’ve noticed my personal output has greatly increased, with this increase mostly coming in quality (but quantity as well). Our team has consistently completed work on time and even sometimes ahead of schedule, helping assuage any doubts our company might have head about productivity in the remote model.
5. Being the first truly remote employee has its pros/cons
Being the first truly remote employee within my organization, it’s been something of a pioneering experience. The organization within which I work has had offshore contractors for many years but no employees who work remotely full-time (from another state entirely). The biggest advantage of this for me has been that I’ve gotten to prove that the model works and move the organization ahead. “Innovation” is incessantly paid lip service to by any and all companies these days, and while many of them may be pursuing legitimate innovations in product or processes, innovation around work itself is often neglected. Remote work is the future and is slowly but surely gaining adoption. Being able to help guide my company into this new frontier has provided both myself and the company with a lot of benefits.
Of course being the first has its downsides, the main being that the organization is still adapting to this kind of work. Fortunately I’ve received support for it at high levels within the organization.
6. Can feel singled out, but this can be a positive thing
Continuing from the last observation, it can be easy to feel like the “remote guy” when you’re the only one. Now that I’ve proven the model though, others within my organization are starting to join the ranks of the remote workforce. Done right, you might find that others within your company respect you more for it as you’re essentially setting yourself apart from your coworkers. Others will see that you’re trusted and respected enough to be granted this privilege.
7. Work is still work
The stereotypical image for remote work is some guy on a laptop working from the beach, but it’s not in any way that idyllic or cinematic. Work is still work and if you’re on a tight deadline or putting out some fire, no grandiose scenery is going to change that.
8. Whiteboarding suffers
Depending on the type of work you do, not having a whiteboard can seem debilitating. It’s a highly effective and quick tool for communication. Similarly, being in meetings and not seeing what is being drawn on the whiteboard contributes to the communication gap. An easy solution for this is to setup a video conference (either through Skype on someone’s laptop or a room VC if you have one) and point the camera at the whiteboard.
9. Having more frequent 1×1’s is helpful
I’ve had more frequent 1×1’s with coworkers. This has helped fill the place of hallway conversations that you don’t get not being in the office.
10. A lot of other remote workers are out there
Working from coffee shops and coworking spaces I’ve seen a lot of other people in these spaces that are also working remotely. These people have all varied in age, so it’s not just old or young employees pursuing this working model. I suspect more and more spaces will open up, and existing ones catering to the remote worker as this becomes the future of work.