How to Work Remotely and Still Be the Best


Written by Irina Papuc Topics: Self Improvement

The Remote Worker’s Tool Belt

Starting a new remote or work from home gig, be it a contract project or a full-time job, can be a little intimidating if you’re used to going into an office day after day.

But this style of employment is growing in popularity, with some very notable companies lending it their endorsements.

I’ve successfully worked remotely using these tools for years now on projects of various scales and durations. With this post, I hope to enumerate some of the best practices that I’ve picked up for working in a variety of situations. The remote and work from home guide here ranges from specific recommendations for software and hardware, to tips for hitting your team’s deadlines.

The Remote or Home Office Setup

I can’t stress enough the importance of having the right office setup. It will both make you more productive and appear more professional. For example, a headset is crucial for avoiding echo during online calls; little things like this go a long way when working as a remote.

Here are some toolsfor working remotely that I consider essential within my own home office:

  • Headset. I really like wired headsets in particular because they don’t run out of battery at critical times. You’ll be wearing it a lot, so make sure you get something comfortable. I have two iMicro headsets: one for my desk and one that I pack in my laptop bag. As a laptop bag headset, it has two great qualities: because it’s USB powered, I don’t have to worry about keeping the batteries charged, and it’s very cheap to replace if it gets broken in my bag. Actually, I find this particular headset a little uncomfortable for long conference calls; if you’re doing a lot of those, then I recommend the Corsair Vengeance 2000: a comfortable, wireless headset with battery capability, allowing you to work all day. (By the way: none of these are referral links.)
  • Quiet place to think, with a door that shuts–especially if you live with other people, and especially if you have a family.
  • Stable Internet connection, or good backup connection. For example, I have DSL and have setup tethering on my phone if the DSL goes out. If you’re constantly having Skype issues or dropping calls, you’re becoming both less reliable and less professional in the eyes of others who might be trying to manage several remote employees.
  • Skype. This is good for adhoc conference calls, instant messaging with clients, or even creating low ceremony chat rooms.
  • SkypeOut, which lets you take and make calls from your phone to Skype contacts. This is awesome, especially for times when you’re away from your computer and (you’ve miscalculated a time, client has an emergency, etc.).
  • Electric kettle. Sometimes I want hot coffee but, don’t want to disturb my flow to get some.
  • Gallon jug of water. For the kettle, or for drinking. For long coding sessions, or long conference calls.

A depiction of an ideal remote or work from home office set up.

Some of these sound obvious, but you’d be surprised at the number of remotes who don’t hit all the marks here. As developers, we need a quiet space to think, uninterrupted. And as remote workers, we need a quiet place to host conference calls, meetings, pair programming sessions, etc., uninterrupted. Just working on your couch is probably not a good long-term remote work solution.

Software Tools

There are a bunch of good software tools out there to supplement your typical development environment and help you overcome the challenges associated with remote work. Here are a few that I really like:

  • AwayFind, which is good for urgent emails, particularly last minute messanges from an attendee of a meeting, as it forwards their messages to you via SMS.
  • Time Zone Converter, for working with clients and colleagues around the world. I like Time And Date’s World Time Clock, Every Time Zone, and World Time Buddy.
  • Chat/IRC rooms for everyone on the team. This could be formal (e.g., a Campfire room) or just a Skype chat room (in Keep It Simple, Silly) style.
  • Bug tracker–this deserves its own section, so see below.

When planning meetings, always confirm both time zones. And when you get an invitation, you should always do the math backwards and make sure you come up with the same numbers. If the meeting involves multiple time zones, I like including the UTC time also. Since everyone should know their offset from UTC, this is yet another check to make sure everyone’s on the same page.

I was on a decently-sized Rails team a few years ago. Several team members worked remotely for at least part of the time, and the team culture was that much work would be done in the evenings. I proposed setting up a chat room through the offical team leader at the time, pointing to Campfire or some other paid chat service. Several weeks went by with no action and I decided to setup a Skype chatroom with just the developers, to test my theory that a chat room would be an asset for the team. This experiment proved very successful – so successful that we just kept using Skype chat instead of another solution. This Skype chat room was still in use when I left the project almost a year later. Sometimes, simple can be the best option.

Later on, during a critical deadline for the same project, we set up a Skype chatroom that included the developers, business analysists, the project managers and the client, so questions could be addressed quickly by the general group. While not as active as the developer-only chat room, it still worked really well. Skype chats can be moderated and controlled by some group chat commands, setting chat roles and setting access permissions, which allows you to really customize the chatroom to your use-case. Even a setup of such simplicity can improve remote productivity.

Remote Work Best Practices: Bug Tracking

I like to know three things from a bug tracker I’m using:

  • What am I working on right now?
  • What’s on my plate for the next release of this software?
  • What are the entire team’s deliverables for this release of the software?

Each of these has a purpose.

First, “What am I working on right now?”: When you work in a traditional office, you have background chatter–this gives you have a general idea of what everyone else is doing. An explicit marker in the bug tracker system stating, “Yes, I’m actively working on this right now”, can introduce a similar pattern and feel to remote work.

Secondly, “What’s on my plate for the next release?” means, “What bugs I’m responsible for” or “What bugs I’m handling”. There’s certainly some back-and-forth in every team, but it’s also good to know who to ask if you want to grab a bug, or need some help with finalizing your bugs for the release.

It’s also possible your team doesn’t work like this at all: for example, your workflow might be where each developer is only assigned one bug to start with and picks off the unassigned pile when their one bug is done. This can be productive as well.

The “Next release of the software” doesn’t have to be anything big–I’ve been on teams where the “next release” meant, “3 days from now, we’re going to release a new alpha build for the client”. But it’s still good for everyone to know what’s coming up in this new release. Especially if you pick off unassigned tickets when your current ticket is complete.

I’ve included some recommendations for specific bug trackers at the bottom of the post.

Remote Work Best Practices: Team Communication

For some, team communication is the most intimidating part of working remotely or from home. But this will only be an issue if you let it be.

In an office, as you stroll by everyone on the way to your seat, there’s a bit of banter, people saying “Hello”. Your coworkers know you’re at work because they see you, over there, at your desk, working.

Remote workers need to be slightly more explicit–nobody knows that you’re working unless you tell them. But if you establish the right communication practices, your colleagues will be available at the press of a button, rather than a stroll across the office, down the elevator, etc.

These tips apply more for a remotely managed employee as part of a bigger team, but may be useful if it’s just you as the sole developer.

Making Your Presence Felt: Don’t Go Invisible

I picked up several of these ideas from the Wide Teams Podcast Episode 48.

At beginning of the day, get on IRC (or whatever tool your team uses) and say “Hello”, chat about how people’s days are going, etc., etc. Even if it means getting on IRC and asking about kids, weekends, sports teams, or weekend hacking. When people know you’re currently hard at-work at home, you don’t become invisible. Build a relationship and let people know that you are there.

Chat with people on chat and make sure you stay involved with your colleagues. This is different then when you bump into people in the coffee room, etc., etc. You need to explicitly reach out and stay in touch so that when you commit code or need assistance, people are ready.

‘Starting day’, ‘Lunchtime’, and ‘Be back’ Messages

Along with making your presence felt, you should also let your remote teammates know when you’re notworking. Just like in a traditional office setting, you don’t want to disappear for the rest of the day and leave your colleagues hanging.

If you’re on a team with a number of other developers or managing remote employees, it makes sense to check in when you start your work day. A simple “Good morning, everyone” to let people know that you’re at your desk ready to start work on the project, and no longer at home or in bed.

Sending “Be back in 1 hour” messages for lunch or work breaks during the day is nice too. Remote work is great for many things, but one worrysome scenario is that you ask your colleague a question and receive no response. Are they not responding because they’re away for 30 minutes? Or because they are deep in the zone and not listening to chat? Maybe in a meeting? “Be back in…” messages can alleviate these concerns and smooth out the workflow.

When you’re done for the afternoon, let people know when you’ll be back. Maybe it’s “See you all in the morning”, or “Be back later this evening to get [x] done”. But like the “Back in 1 hour” messages, they set a certain expectation to which your team can adapt.

There’s an interesting startup called Sqwiggle that may solve some of these problems (although I haven’t tried it myself yet). In addition to taking a picture of you every few seconds, it also lets team members click on your picture to start video/audio chatting, as well as providing a text chat component. The idea behind the picture is to see, at a glance, if you’re at your computer or not. (There’s nothing worse than trying to chat with someone online and not hearing back quickly. Are they caught up with something else? Deep in the zone? Don’t see the chat notification? In the bathroom right now?). I heard about Sqwiggle on the Wide Teams Podcast Episode 83.

On Projects Where You Can Setup the Best Practices

Remote freelancing gigs are always different. (That’s part of the appeal!) Sometimes you’re brought into an existing team of developers purely as staff augmentation. Maybe this team has been together for some time and, in that case, they’ve already established communication practices.

On the other hand, sometimes you’re the only developer on the project, working with a non-technical client. You can setup your own software development best practices and have some control over how to run the operation. Below are some best practices from my decade or so of remote work experience. Mostly, these are targeted at half-week (20 hours/week) or full-week schedules (40 hours/week).

Standup Meetings

There’s something to be said about holding standup meetings to talk about the state of the project. These arevery common in traditional offices, but there’s no reason why they can’t be productive for the remote team: they’re just another way to enforce communication between the two parties: client and developer.

A traditional stand-up meeting asks what you were working on yesterday, what you’ll be working on today, and if there are any obstacles in your way. This format may or may not work given the size of your team: if it’s a single developer project, then these actual questions make no sense.

How often you should have a standup meeting is really dependent on team size and culture. However, here are my recommendations:

  • 1-3 developers: 2 standup style meetings a week
  • 4+ developers: daily standup meetings

With 1-3 developers, these questions are mostly self-evident: you know what each developer is doing because it’s easy to track their individual work as they plow through tickets: everyone knows what everyone is doing, because there’s just not that many people doing work.

With larger remote teams, there are more parts in motion: you want to make sure that nobody is stepping on anyone’s virtual toes by replicating work, or making incompatible changes.

Given Toptal’s per-week payment structure, two meetings a week gives the client enough time to express concerns about the project before they feel cheated out of a weekly rate. Just having one meeting a week could mean that the client is unhappy about the quality of work, and the developer has no time to adjust the deliverables.

Advanced remote teams may have other methods of keeping all the stakeholders on the same page without scheduling an actual meeting while they work from home. I still like getting on the phone/Skype/Hangouts with someone and having a meeting that way.

For small teams, two standup meetings a week works really well: course corrections are made quickly, but developers still have something substantial to report during each meeting.

Delivering on the Next Release Remotely

Depending on the size of the project, I like deliverables sent to the client weekly for small (1-2 developer), and bi-weekly for larger (3+ developer) projects. This rhythm gives developers enough time to complete sizable chunks of work, including an interface (or improved user experience) for the client to see.

For non-technical clients, the only metric by which they can guage progress is what they can see on the screen.

It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.

This image depicts the importance of deliverables, especially in a remote work situation.

Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.

Depending on the type of software project, not all of these client releases will be released to the public. For example, if you’re working on a Rails project, you may want to deploy approved changes immediately; on the other hand, with a mobile app, you may call a release “1.3a10”, but the current release is just part of the bigger feature set of a new 1.3 version of the software that will be deployed later.

This is where the remote bug tracker best practices come into play. With bug tracking, the client knows:

  1. What’s on the team’s plate for this deliverable
  2. If it’s been completed
  3. If the work has been approved by the client.

The client knows what to expect from this release, and developers know what work is ahead of them.

If your remote team is mature enough to use continuous deployment and/or Kanban then that’s fine. However, these are both very advanced techniques that are more suited towards organizations with a strong, developer-based culture. Most organizations, where custom software development is seen as necessary but costly, are probably not ready for either of these techniques. Why’s that? Two things I’ve seen is that the client can’t keep up with the number of changes developers want them to review, or priorities change too rapidly for development to get any one thing done.

Recommendations

If you do happen to walk into a team where you’ll be establishing the best practices, I’ve listed some tools below for managing your remote work. Keep in mind that these are just my recommendations: certainly, this guide isn’t for everyone; and if you don’t like these tools, there is probably a tool that fits your needs better.

  • Planscope.io, in weekly mode. This is a time tracker + bug tracker + project estimation tool that sends clients daily emails when you work on their project and lets them see how things are going in terms of progress and budget. This is great for projects of 1-4 developer/months in size.
  • App Trajectory is a bug tracker for small teams with a focus on estimating and breaking the project down into one-to two-week chunks (iterations). App Trajectory can tell you how much work you’re completing in an iteration, and how many iterations until all the known work is complete. This is great for projects 2-12 developer/months in size.
  • Pivotal Tracker is a bug tracker tool for clients with a focus on Agile methodologies. This is great if you are doing formal Agile iterations or have a project size measured in developer/years.
  • FlowDock for chat. Flowdock offers some advantages over plain IRC or Skype chat: in addition to integrating with popular services, it also lets you tag conversations for quick reference later. FlowDock also keeps a list of status activities (code checkins, etc.) which are separated from general chats. (I.e., in the web interface, automated status updates are on the left, while chats are on the right.)
  • Again, Campfire is also great for chat.

Conclusion

Getting started with remote or work from home can be quite an adjustment, both for you and the client. I’ve had it go very right, and very wrong. But, when it goes right, it can be an excellent way for clients or employers to solve the “talent crunch” problem, and create a wider range of opportunities for developers who live outside major technological centers or “startup” hubs. There’s a whole world of efficiency to be gained from developers working together remotely with the right best practices in-place.

This article was written by Ryan Wilcox, a Toptal Ruby developer.

Share this:

Read More

Bootstrapped: Building A Remote Company


Written by Irina Papuc Topics: Business

 

The Dream: Building A Remote Company

If you ask me, working remotely rocks. I’m currently writing from a small beach bar located on a remote island in southern Thailand. Looking up from my laptop, I see nothing but the endless ocean and its crystal clear blue waters. I’ll be enjoying this morning undisturbed and focused on my work because the rest of the team hasn’t even gotten up yet. Time zones work out really well for distributed teams.

My colleague Thomas recently talked to 11 thought leaders in project management about the impact of remote work on a company; some scrum experts argued that distributed teams could work together effectively while others came out strongly against it.

I understand the concerns; you can’t just open up the office doors and release everyone into the wild. It’s not guaranteed that you’ll end up with a thriving business. Marissa Mayer at Yahoo famously axed remote work in 2013 after feeling that some employees abused it.

So how does a tech company get this working remote thing right? Read on. The following is based on our story at Planio and how we made it work.

The author, Jan Schulz-Hofen, working remotely on an island beach.

Enter Planio, my remote company

There are a number of things which motivated me to start my current company. Breaking away from client work while retaining all the benefits of being a location independent freelancer was one of them.

In 2009, I was sitting in the shadow of a cypress grove situated in a beautiful Mediterranean-style garden overlooking the rolling hills of Tuscany, working hard on a new side project of mine: Planio.

It’s a project management tool for people like me: developers. Planio helps make client projects more organized and transparent all while reducing the number of tools and platforms needed to do the job. Planio is based on open-source Redmine (an open source Ruby on Rails-based software project), which I’ve used remotely with my own clients since its very beginnings. So, in a way, remote work is already in Planio’s DNA.

Fast forward to today, and my small side project has grown into a real company. We’re a team of 10 now, serving more than 1,500 businesses worldwide. We have an office in Berlin, but many of us work remotely.

In this article, I’ll dig into the principles, tools and lessons that have helped us along the way. After reading it, I hope you’ll be able to architect your software company so it’s remote-friendly right from the start.

“Talk is cheap. Show me the code.” – Linus Torvalds

Every Thursday we have an all-hands conference call where we discuss what we did the previous week and what’s coming up next.

At the beginning, we spent a lot of time discussing ideas before deciding on what to do, but we found that it’s a lot harder when some team members are on a poor quality telephone line and you can’t see them.

Now, we often just “build the thing” and then discuss it – we create a working prototype with a few core ideas and then discuss that. For instance, we recently hit some performance issues with our hosted Git repositories. Instead of discussing and analyzing all the possible ways in which we could potentially save a few milliseconds here and there with every request, my colleague, Holger, just built out his suggested improvements in a proof-of-concept on a staging server to which we directed some of our traffic. It turned out well and these ideas are going into production.

This method focuses everyone’s minds on action rather than talk. The time invested in writing code is paid back by less time spent talking in circles.

Use Text Communication

Real-time communication punishes clarity. Instinctively calling a colleague when you need something is very easy, but it’s not always your best course of action. I can’t remember the number of times I’ve started writing an email or a Planio ticket for a problem only to solve it myself just while writing it down.

Zach Holman, one of the first engineering hires at GitHub, agrees: “Text is explicit. By forcing communication through a textual medium, you’re forcing people to better formulate their ideas.”

Text communication also makes you more respectful of each other’s time, especially when you’re living multiple time zones away. Immediate communication can be disruptive; the person might be in the middle of figuring out why the last deployment went wrong. With an email, s/he should be able to consider your write-up at a more convenient time.

Be as Transparent as Possible

Time spent worrying about office politics isn’t conducive to shipping working software, and transparency promotes trust. It’s no coincidence that many remote-by-design companies, such as Buffer, have radical transparency. In the case of Buffer, it shares revenue information and the salaries of all its employees.

Automattic, the company behind WordPress.com, also emphasizes transparency. In his book, The Year Without Pants, Scott Berkun shares his experience working remotely for Automattic, and that all decisions and discussions are internally available to employees in its P2 discussion platform as part of its emphasis on transparency.

The chat feature in Planio works in a similar way. Discussions are open for everyone to see and chat logs are linked automatically from the issues discussed so nobody is left out; even new hires can read up on what previous decisions were made and why. When I started building the chat feature, I considered adding a feature for chatting privately with others, but when we discussed it as a team, we ended up leaving it out because we wanted to keep team communication as transparent as possible.

I think transparency is critical for remote teams. For example, imagine you’ve just joined a team of remote developers. Perhaps you’ve never met your new colleagues. You don’t know the unspoken rules of behavior. You might be worried about whether you’re doing a good job. Are your teammates actually being sarcastic or do they really mean their compliments? Is everyone privately discussing how good of an engineer you are?

Digitalize Your Systems

We choose our services based on what they offer by way of online platforms, from telephone providers to banks (many of them will even offer a small financial incentive for going paperless, plus it’s great for the environment, too). I’m lucky to have a lawyer and an accountant for Planio who are comfortable sending emails or messages with Google Hangouts instead of summoning me to their offices. (I strongly recommend you ask about this at the first meeting.) Bonus points for getting them to sign up with your project management tool and become a part of your team!

We’ve even digitized our postal mail; at Planio, we use a service called Dropscan that receives our letters, scans them and forwards the important ones to the appropriate person. You don’t want to your friend to pick up and read them out over Skype. If you cannot find a mail-scanning provider for your city or country, some coworking spaces offer virtual memberships to maintain a physical mailing address while you’re away.

For those companies sending out mail, there are services available so that you never have to visit a post office again. We use a German printing company with an API that automatically sends a letter along with stickers to each new paying Planio customer. It’s something people love, and we don’t have to print and mail a thing. International alternatives include Lob and Try Paper.

Digitalize Your Systems

Should You Have a Digital Presence Mandated?

In a co-working space on the tropical island of Koh Lanta, Thailand, I noticed that someone in a support role for a major e-commerce platform was constantly on a live video feed with the rest of the team. Sqwiggle offers a similar “presence” functionality for remote teams.

I suppose mandating that all employees are on video while working might be based out of a fear that employees abuse remote work arrangements. In my experience, that’s not the case. At the tropical co-working space, there’s a certain urgency in the air, despite the laid-back clothes and coconut drinks. People are quietly focused on their laptops; it’s as if they want to make sure remote work delivers results, so they can stay out of a fixed office for good.

We found that we don’t need a digital presence because we have a great level of trust among everyone on the team. I also think that it’s paramount to respect everyone’s privacy. If your company is moving from an all-on-site setting to remote work, a digital presence might help the more anxious managers to overcome any trust issues.

Choose Bootstrapping over Venture Capital

Most venture capitalists are looking for outsized returns, so they’ll prefer an intense short burst of 12-months’ work from a team over a more sustainable pace. Front App, a startup funded by the Silicon Valley accelerator Y Combinator, rented a house in the Bay area for their three-month stint in the Y Combinator accelerator program. The goal is to optimize for evaluating a business idea quickly.

Given the outsized return mindset, you may have a hard time convincing a venture capitalist to fund you when you’re working from a beach in Cambodia. This is why many venture-backed startups (such as Buffer or Treehouse) that use remote work built leverage first. Buffer was profitable before taking on investment while Ryan Carson, the founder of Treehouse, had already proven himself with a previous startup.

Here’s a better way than venture capitalism: bootstrapping. It means financing your company with revenue from initial customers. In my opinion, it’s by far the superior approach because it enables you to build your company on your own terms and remain in control. However, it often requires working two jobs or freelancing on the side while you get your company started. It took me about two years working on both Planio and client projects (via my software development agency LAUNCH/CO) to get going, but it was well worth it.

Bootstrapping also forces you to build a business that generates revenue from the very beginning, which I find much healthier. Hint: Building a B2B SaaS makes this much easier than creating a consumer app because businesses are far more willing to pay monthly subscriptions if it adds value. You have to sell a lot of consumer iPhone apps at $0.99 to cover monthly payroll for even the smallest of teams.

Choose Bootstrapping over Venture Capital

Bootstrapping forces you to build a business that generates revenue from the very beginning.

Price your Products Strategically

One of our first clients was a massive technology company with billions in annual revenue. Obviously, I was delighted that they’d choose us over much bigger, more established competitors. They’re still a happy customer, but we have moved away from very large enterprise accounts; I’ve found that they require a lot of hand-holding and in-person meetings before they’ll become a customer.

As Jason Lemkin points out in his article on scaling customer success for SaaS, when you have big enterprise accounts, someone will have to get on a jet to visit them twice a year. If you’re a small company of two or three people, that person is going to be you, the CEO, the CMO and the CSO all rolled into one overworked hamster.

Keeping your pricing model within the rough bounds of a $49/$99/$249 model as suggested by developer-turned-entrepreneur Patrick McKenzie means avoiding having to hire an enterprise sales team, and having to earn the massive amount of capital required for it. You, the customer, don’t expect the CEO to pop in at Christmas with a box of chocolates when you’re paying $249 a month.

Build on Open Source

A venture-backed business based on proprietary software is great when your play is a “Winner Takes All” game and own the market. When you’re a bootstrapped company, open source software can give you reach and leverage you could never have achieved, otherwise.

There’s precedence of profitable tech companies building a business around open source software; Basecamp famously open-sourced Rails, guaranteeing themselves a supply of highly qualified engineers for the rest of eternity. GitHub has become a unicorn, leveraging the open source project Git that Linus Torvalds started to manage the Linux kernel sources. Our friends at Travis-CI started as an open source project, ran a crowdfunding campaign and then turned it into a remote-focused bootstrapped business (which also campaigns for diversity in tech through its foundation).

Planio is based on Redmine and we contribute many of our features and improvements back to the community. This works great in multiple ways; our contributions and engagement in the community help advance the open source project and Planio gets exposure to potential new customers. For us, it’s the most authentic way to build a brand; by showing our code and taking part in open technical discussions, we can demonstrate that we know our stuff!

Hire Proven Professionals

Hiring a fleet of interns every year makes sense only if you’re intent on scaling up your employee count as soon as you hit the next round of funding.

Outsourcing tasks is easy if it’s copy-and-paste, but you don’t want to outsource your DevOps to someone with the lowest hourly rate when you have thousands of customers relying on your servers. You’ll want proven professionals, such as those at Toptal.

Matt Mullenweg, the founder of the popular open-source blogging platform WordPress, stated that by focusing on quality means that his company, Automattic, predominantly hires experienced candidates who can handle the unstructured working environment of a remote company.

That means it “auditions” candidates by paying them to work on a project for several weeks, then hire them based on performance. Automattic has found this method is far more effective in finding the right candidates than traditional CVs and cover letters.

Emphasize Quality of Life

Work takes up a massive amount of our time, year in and year out. It should not be something that you just do to be done with; you’d probably end up wasting a huge chunk of your life. The best source of motivation and the main ingredient for great results is a work environment that’s inspiring, enjoyable and fun. Travelling, learning and engaging with people from different cultures makes work feel less of a sacrifice or necessary evil (at least in my life) than when working a nine-to-five office job.

Emphasize Quality of Life

Work takes up a massive amount of our time, year in and year out. It should not be something that you just do to be done with.

It’s not just about travelling the world, though, there’s the personal freedom aspect. Parents get to spend more time with their kids, thanks to avoiding a two-hour commute. You don’t have to live in Silicon Valley to earn San Francisco wages. Maybe, your significant other gets a great job opportunity abroad, too. You’re not faced with the painful choice between staying at your job and continuing your career or becoming a “trailing spouse” with limited career options.

At Planio, even though many of us work remotely, we all try to meet up at least once a year in a fun location. Last year, we spent a few weeks of summer in Barcelona, and several of us met here in Koh Lanta, this year. I’m still looking for ideas for the next destination, so let me know if you have any travel tips!

What tools, ideas or techniques have you found that make working remotely easier and more effective? Leave a comment below.

This article was written by JAN SCHULZ-HOFEN, FOUNDER & CEO @ PLANIO and friend of Toptal.

 

Share this:

Read More