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.
There are several ways to make configurable components and services in Angular 2 / 4 – APP_INITIALIZER, providers, dependency injection, etc.
But these can sometimes be confusing to use. An easy way to make your services configurable is to simply use a class setter in your service. An example can be found in the library I recently built ng-idle-timeout. (There are a couple libraries that do something similar, but were overkill for the most part)
This service is used to set the idle timeout (user has not moved mouse, typed, clicked etc for a length of time) for the UI. But obviously all consumers of the service will have different business requirements for what this length of time should be. In my library, the default is set for 20 minutes, but let’s look at how to override this.
The ‘setIdleTime’ method allows consumers to override the default timeout. Consuming this is very easy. To use this service, import it at the root module of your app (usually app.module.ts) and in your root component (usually app.component.ts) subscribe to the observer, like so:
this.timeoutService.setIdleTime(300000);// call this method if you want to override default 20 minute timeout
// some action here
You can implement this on an individual component if you wish, but as the root component is instantiated only once, it’s recommended to place it here.
The nice thing about this way of configuring services is the configuration method is contained and located within the service itself. There is no magic happening that is abstracted away by the framework.
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.
If you’re using the npm module node-oracledb to connect to an Oracle database from Node, consider using this Promise-based and cursor-based wrapper/utility to return results from your queries and close connections: https://github.com/coreyc/oracledb-promise
This wrapper provides the following:
Only one function to call – executeSQL()
Pass in your SQL or stored procedure and any connection parameters
Promise-based, so chain off executeSQL() to return your execution results or catch any errors
Automatically closes the connection to Oracle and the result set returned from the database so no need to worry about memory leaks
I wrote this for a few reasons, the primary being a separation of concerns. Instead of the calling code having to worry about getting the database rows from the cursor, checking for empty sets, closing the result set, and closing the connection to the database, this is all wrapped up in one nice function that handles this automatically for you. Your code won’t be littered with node-oracledb module-specific code when all you want to do is get results back from the database. Also, it’s very easy and common to get memory leaks when your result sets and connections aren’t closed so this prevents that.
The recent obsession with capital “I” Innovation that has been rapidly gaining momentum the last couple of years has permeated across a majority of large, traditional companies with business models, technologies, and processes seemingly stuck in the past. Fear of competition and thus declining profits and stock prices appears to be the primary motivator behind this obsession, with many of these companies desiring to be more nimble and forward-thinking. This has given rise to the so-called Innovation Group within large organizations, corporate partnerships with startups, and hiring of expensive consultants and consultancies to come in and tell these companies “you should emphatically embrace our way.” These actions, often made very publicly as to cast off any prior signifier of “old,” seem to be a race to avoid being last to adoption. Through looking to startups (or more nimble companies), these old titans hope to bathe in the fountain of youth and emerge automatically renewed.
This post is prefaced with skepticism not out of discouragement; quite the opposite. I think it’s a great thing that companies, whether they’re “old school” or not, are acknowledging that they can’t keep doing things the way they always have been lest they be eaten alive in today’s market. These innovation initiatives are essentially a self-reflection exercise. However, I question these initiatives because they so often seem to miss an opportunity ripe for innovation.
While the idea so far has been to follow what the startups are doing to create innovative services and products (or what the consultants are telling you to do), I posit a new theory – both types of organizations are overlooking a major area to innovate on: their working model.
Too many companies require the same, century old working model of showing up at 9 in the same office location or handful of different office locations, communicating in real-time throughout the day, then going home at 5.
Remote work changes this. It’s an innovation on the old model and a ride into the future. And for companies that are already investing so much into self-reflection in the hopes of finding new ways to gain market share, they might as well examine all aspects of the company while the body is already cut open before it’s sewn back up.
The obvious should be stated that not all roles and not all companies will be a good fit for remote work. But if you are a software company – which most companies are nowadays, even if it’s not the company’s primary product – it’s worth considering adoption.
Smart companies will realize that many, many developers want to work remotely (more than just work-from-home every Thursday or Friday) if they aren’t already. Smart companies will dispense with the micro-managerial mandates of heavily synchronous, remote-unfriendly practices such as full-time pair programming, only using [insert tool here], and “always-on” Slack/IM/whatever. And smart companies will understand that developing more flexible environments for their employees will attract the best ones.
The way we’ve worked for the last century is ripe for change as it no longer makes sense in a globalized and techno-superfluous world. All the product, business, and technology innovation will be all for naught if your employee model is not updated as well to match that of the current working world, indeed if it inhibits working in such a world. Remote work policies, thoughtfully considered and adopted, are not just ends unto themselves but can be an opportunity to inspect and improve upon the rest of the working experience.
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.
This is the first in a series of projects that will be developed around the idea of applying “calm technology” to product design. Coined by Mark Weiser and John Seely Brown at Xerox PARC in 1995, calm technology can de defined at a high level by the following:
First, by placing things in the periphery we are able to attune to many more things than we could if everything had to be at the center. Things in the periphery are attuned to by the large portion of our brains devoted to peripheral (sensory) processing. Thus the periphery is informing without overburdening.
Second, by recentering something formerly in the periphery we take control of it. Peripherally we may become aware that something is not quite right, as when awkward sentences leave a reader tired and discomforted without knowing why. By moving sentence construction from periphery to center we are empowered to act, either by finding better literature or accepting the source of the unease and continuing. Without centering the periphery might be a source of frantic following of fashion; with centering the periphery is a fundamental enabler of calm through increased awareness and power. – Designing Calm Technology
The goal of calm technology is to have technology serve humans, not the other way around. In today’s world of being bombarded by ads, smartphone distractions, and apps that compete for our attention, it should be a goal to reduce technology to its essentials and push it to the background, while also allowing it to come to the foreground when it needs to. I think this is going to be a big thing in the coming years, partly as a reaction to the poorly designed technology experiences we are forced to deal with today.
Building a better train tracker
One area I lose a lot of time to technology is in figuring out when the next CTA (Chicago Transit Authority) train will be arriving. The timetables are not real-time so do not account for delays and having to pull out my phone to see when the next train is arriving and when I should leave in order to catch it inevitably leads to being distracted by the gateway of information a smartphone provides. This project was built so that I could easily and almost sub-consciously check when I should leave from my home to catch my next train.
The device is built using an Arduino MKR1000 powered externally and a single WS2812B LED, so these were the hardware parameters that were designed around.
Several considerations were given to solutioning for this design:
How many trains should this track? From which station, and in which direction?
How should the notification system operate? At what frequency?
How should this be designed so it operates at the periphery?
What technology choices should be made so that this device is a good “technical citizen”?
In order to quickly get this built and test its efficacy, the decision was made to just track one train line, station, and direction for now (the nearest line and station to my residence, and the direction I am most often heading in).
As for the notification system light and color were chosen due to their ambient, peripheral qualities. Obviously having an additional or alternative notification system that relies on a different medium (color choices, sound, etc.) would be necessary for those that are blind or color-blind.
Now there were several considerations given to frequency (times) of the light being displayed and which colors to use. The decision was made to calculate time based on travel time from my residence to the station, thereby reducing one more cognitive step (addition of travel time to station plus arrival time). A train tracker will tell you when the next train is arriving but does not usually include the buffer time you need to give yourself to leave from your location. It was a very conscious decision to avoid using red, yellow, and green as these colors already have meaning in relation to transportation and time. If the LED was set to red would that mean the train was delayed? Stopped on the tracks? Would it mean I should stop? If it was green would that mean I should leave? Would it mean the train is going and has already passed my target station? Note here that as the station is about a 6 minute walk away and I don’t want to wait at the station for that long, any train that will be arriving within the next 6-8 minutes will be “time to leave,” with 5-6 minutes being “I might make it in time” and less than 5 minutes being “too late”. The LED used is programmable, so there is only one light source and the colors settled on were blue (neutral) for “time to leave,” purple (neutral, but with enough red in the hue that it suggests importance or urgency) and nothing (LED off). The original design had the LED turn on to a brownish yellow if I had missed the time to leave for the train, but in order to reduce the cognitive processing needed by the user and to not distract, it was changed to just turn the LED off. The LED stays on and at its current color until a change in state of the train’s arrival time. So the design ends up looking as below:
Don’t leave yet
Time to leave
Might make it if you leave now
While periphery choices have already been discussed, it is important to note that as this device is designed to be running in the background all the time when it is turned on, sound as a notification was decided against. It would get annoying very quickly hearing even pleasant “time to leave” sounds due to the frequency at which trains arrive and leave the station. Light is more ambient and less disruptive. Also, the LED used is just small enough to not stand out, but bright enough to be noticed when you want to check if it’s time to leave.
In order to provide timely estimates, the Arduino fetches arrival time data from the CTA Arrivals API every 10 seconds. This seemed like the right balance between betwork bandwidth with getting timely data. Bandwidth used is already tiny (data is returned in JSON format in a few bytes) and the code is optimized to account for small Arduino RAM and storage size. And to turn off the device when it’s not needed, the on-board Arduino power button is used. It can also be unplugged from power and will restart automatically when it’s plugged back in.
Next steps/future improvements
As this is the first iteration of this product, several ideas may be implemented in the future. A priority is designing a physical case for this device to be housed in, removing wires from the user’s view and further reducing it to its bare essentials aesthetically. There might be several devices that a user has in their home/office/wherever this device might be installed that similarly rely solely on light as notifications, so some differentiation would be required here. Whether this is done through changing the light patterns, or probably more effectively, adding some simple signifier to the physical design of the housing, it should be obvious to the user what the purpose of this device is while still remaining on the periphery. Another improvement would be around power, as the device currently runs while plugged into AC. Moving to a long-lasting battery would make it easier for the user to move the device to another location while also further hiding the technology itself (wires) from view.
Lastly, getting this in the hands of real users and doing user testing would be valuable for product improvements. I’ve got some ideas for adding sensors to this to have some internal metrics running for product feedback too.