Follow up article: Finding a remote job is hard. Here are 6 tips for having a better chance
Don't have time to read? Here is an auto-generated audiocast thanks to Miguel Piedrafita
It seems as if it was yesterday when I started to work remotely. It was in March 2009 though. Since then, I have had my own startup ( which failed ), I have worked as an early engineer for another startup ( which got acquired ), and now I'm working at a big corporation ( that acquired the startup ). Over these years, I have worn many hats, from self-proclaimed startup "CEO" to a principal developer, tech lead or engineering manager. I have worked with great people, and also with some others not that great. I've paired with junior people and senior people. I had the pleasure to lead and to be led by people in several continents. I think this anniversary deserves some writing and I have decided to publish it here, at dev.to.
During this time, I have benefited from uncountable articles about remote working. But all in all, I found many of the articles that are around are biased. Many are indeed still valuable, but also a good amount of these articles happen to come from remote-first companies, which of course try to lure you into their talent pools, whereas some other articles come from people who run remote working communities, or job boards. In summary, there are some interests behind these and in many cases, the articles will focus on the good parts but ignore the bad parts. On this essay, I'm attempting to be super honest with myself and with you about remote working, but still, bear in mind that this is just my experience, so take it with a pinch of salt.
This opinion is very personal and of course, maybe you disagree. I totally respect it. But my view is that if you are starting your career then you should not consider remote working unless you have very important reasons for doing it ( see next section ). Also, of course, you can ignore me if you are such a badass to go traveling the world while working, which is something I loved I would have done.
Honestly, working from an office might end up being a terrible experience, or not. It really depends on where you live and what company you end up working. But still, it is going to be an incredibly valuable learning experience that everyone should go through. Otherwise, how are you going to value working remotely at all if you never have worked on an office, right? :) And also, usually and especially at the very beginning, you will make a lot of friends that hopefully will last for your whole lifetime.
Let me even go further. If you can, then you should consider working in an office, abroad. Maybe relocating to a tech hub. In fairness, adding international experience to your resume will always be hugely positive, and so will be the enriching experience of working and living abroad. Again, if you can, I will strongly recommend the experience. I did it in the past, I only regret having not done it even earlier in my life.
Yes, think twice, thrice, and any number of times you need. Especially, if you find yourself with the main argument for going remote being "I have a friend that is working remotely, he is doing really well and it looks so much fun". Believe it or not, and despite all the fun pictures we remote workers tend to post online, the truth is that remote work is work after all, and I would say that it is way more demanding than office work.
My opinion here is that you should consider working remotely only if it is going to make a big substantial improvement in your life. Otherwise, the cost of the extra work, the cost of working off hours or the lack of social interaction might end up being too heavy. But wait, what is a substantial benefit? Well, it really depends on the person. For me, the huge benefits I've got by going remote are:
Family friendliness: Over the last 10 years my wife and I did raise two kids. Remote work here has helped a lot. It would have been almost impossible for both of us to keep our jobs if I hadn't had the flexibility that remote working gives you.
Chance to get a higher salary: A remote job might get you closer to big-city like salaries, or to salaries that in your country or region would not be even possible.
Those were the two main drivers for me. But other people might actually favor other important benefits from remote working:
- No commuting: In some places like big cities commuting can be a nightmare.
- Work for dream companies. There are some very cool companies that offer remote work and you don't need to relocate. There is some great projects to work on too. Remote working is very popular for open source contributions. If this is what you love to do then I find it a very compelling reason to go remote.
But believe me, for succeeding in remote work, then one or preferably more of the points above need to be imperative benefits. Remote working comes with many negative points that need to be weighted in. I already mentioned a lack of social interaction. But there are many others. You will find that remote friendships come in very fast but they also fade out very quickly as you will lack the real interactions that solidify relationships (yes, drinks!). Career advance is tougher too. Remote management comes with a lot of challenges and in some circumstances is almost impossible and you might find yourself stuck in your career. So, seriously, think thoroughly about what is making you want to go remote working and what are your long and short term goals, and make sure the reasons to go remote are actually strong reasons for you. Reasons, that will make you really spark joy --Marie Kondo mandatory reference these days.
Office workers get some things granted pretty easily. For example, office workers need to just show up at the office space and it seems like they are working. For remote workers this is much more challenging as the shade of doubt will always be there cast over us. Oh, is Martín really working, or is he going again mountain biking?
As a remote worker, you will have to be ready to prove not only that you are working but also that you are delivering value. For me, this has been relatively simple as I was already doing contracting work before going remote, and a contractor has pretty much the same need. A contractor needs to demonstrate every week, or month, that there is value on the work delivered. Otherwise, the contract ends. And incoming money ends flowing in too. For a remote worker, it just works the same way, the remote worker needs to prove that is providing value.
With time, you will get trust from your team, but I have always found that the skills needed to prove your work are nice skills to have. Here are things I do regularly:
Learn to communicate what you have done. Many people are over shy about this. There is some stigma around talking achievements. People that do this sometimes are being seen as if they are trying to make their way up on the corporate ladder. But, if you want to be remote, you'll have to get over this. Your manager will actually appreciate knowing what you have been up to and knowing that you might still be living thousands of miles away but you are delivering important value.
Document everything you do. At the companies I've been working, I've always been renown by writing good wikis. I don't think it's that much that I write that well but that I actually do write. It's always useful to document your last learnings, or the new technology you have learned, or the latest results for that load test that you might have run. Yes, documentation gets obsolete quickly, but so it is true that while it is up to date it is incredibly useful for newcomers and for existing employees. I always try to document everything and do the best I can to maintain up to date those docs or to deprecate them. And overall, it's been very helpful for me to prove that I deliver value. Bonus: Documentation also makes interruptions shorter as you can always refer people to the guide ;)
If you are doing software, add tests. I'm not going to defend writing tests or doing TDD, I think these are standard fundamental engineering practices these days. Being remote means only that these practices become even more important to be able to defend your work. There is no better way to defend your software than start writing tests. So if you are not doing it, and you are considering remote then it is going to be about time ;)
Demo what you have done. Any time you do some nice achievement that can be useful for someone else do not hesitate in sharing that knowledge with others via live demos. It will help other people and also you will be again providing important value. These demos are usually a part of Agile so you can use the demo-day for this, or if it is not in the scope of a particular Sprint you can simply call up for a brown bag session.
Chat, talk, collaborate. I won't go further than that on this one. Being on your own office, you will have to do some extra efforts to keep in touch with people and to collaborate. There is plenty of tools to do this. Choose your own poison.
I live in GMT+1. In my remote journey, I've moved from same-timezone work, to EST-GMT-CST timezone work, and to PST-EST-GMT-CST. As you can imagine, as the timezone availability band spreads out, so it do the times at which you might get requests for meetings or interactions. I did not control this at the beginning of my journey as it wasn't that annoying, but once I moved into collaborating with PST times, then it got really complicated for me especially when having to coordinate meetings with dinners, kids bath or go-to-sleep hours, etc.
So, my advice to you is that if you need to work in different timezones then make sure you block time in advance on your calendar for personal use. So no-one will actually try to schedule or interact with you in those hours. That way you can separate your personal life from your work life and at the same time still be flexible with working hours.
Blocking an hour at lunchtime, a couple of hours at dinner time and any time beyond 11PM is probably the best decision I've done so far.
Following on the above topic, especially when you need to work on multiple timezones, you might end up in situations as I did get into. You find yourself not leaving your computer in the mornings because you need to work on some issues with the team in Asia, then you want to spend some valuable work-time during the afternoon doing some stuff quietly, and then you start getting requests by the team in the USA timezones as they wake up, and without realising it the day is over and you have worked 12 or 14 hours. And if you don't take care of this, it will go on and on and on, until you are burnt out.
The way I solved this is planning the week in advance and to allocate flexible breaks according to how the week is going to look like. For example, if I have a lot of tasks and meetings during the morning then I may block some time in the evening for the kids. If on the other hand, I am going to have a lot of evening tasks then I block some time in the morning to doing things at home or doing some sports, etc. In summary, you will have to be very creative with your time if you work cross-timezones, making sure that you work a reasonable amount of hours ( no longer than 8), or otherwise you will get burnt out sooner than later.
I'll be crudely fair and straight here. If you are interviewing for a remote role and you are going to be the only remote person or just one of just a few remote people, then consider the offer very carefully because most likely you will suffer.
"Satellite" workers are becoming a common situation. Companies usually resort to this model when they can't find talent for a certain skill, so they resign on their efforts to hire local-only and concede on hiring remotely but only for those roles that are difficult to fill. The consequence is that you will end up being a second-class citizen within the company, no matter how hard you and they try. And it will not be because the company wants to, but just because you are and will be the exception to the rule.
There is not much you can do really about this. It's your choice. It might be worth for that substantial reason I related further above. Other than that, with time, an alternative is creating a small office around your location if the company allows it, but frankly, it would likely be difficult if the company only resorts to remote work for exceptions.
Over these 10 years, I've had the pleasure of collaborating and leading some small teams located in different continents. I've had the pleasure to work with very senior colleagues and also very junior people. Some of them are used to remote work, some of them aren't. But no matter their expertise, my experience has been reasonably constant. Whenever the team members are used to work remotely then all will flow reasonably seamlessly. On the other hand, trying to manage people that are not used to remote work or are not willing to be flexible has always been a big challenge for me.
The main challenge with this is flexibleness. When people want to have an office work lifestyle than to adapt then as you can imagine having someone trying to remotely manage the team is going to be a hell both for the lead/manager and for the team. Also, the truth is that being a manager that connects by videoconference every day to a room full of onsite people is incredibly awkward. Personally, I still don't get over this very well and I find myself much more comfortable for example when my team joins calls from their homes.
This is everything I wanted to share with you guys. I love this community and I see tons of articles about remote working which are actually very honest and far away from those "sponsored" go-and-work-remote articles that are usual to see around. I have been very honest too and hopefully, this might help someone to decide to go remote, or to decide to go to an office job.
Would I go remote again if I were back 10 years? YES Will I stay working remote for the next 10 years? I HOPE SO. Will remote work be your thing? I don't know but hopefully, my article has helped you.
In any case, good luck!
This series of posts document a high-level process to use when planning a modern web application, from project organization, collaboration considerations and tooling choices during development, all the way through deployment and performance strategies.