Questions to anticipate when asking your manager if you can start working remotely

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.

Their concerns

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.

Prepare

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.



 

How long do new developers need to work at an office job before going remote?

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:

  1. Managing tasks on your own, without a lot of help from other developers
  2. Proactively identifying what to work on, without being told what to work on
  3. 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.

Don’t miss my next post!

* indicates required



 

How to determine if that remote developer job will throw you in the deep end or not

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.

Don’t miss my next post!

* indicates required



 

Easy way to make Angular 2 services configurable

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:

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.

 

How to use your on-site trips strategically as a remote employee

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 on-site

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:

  1. 5 weeks out in advance of your next trip – brainstorm your list
  2. 4 weeks out – talk to your manager about your upcoming trip
  3. 3 weeks out – reach out to your list to setup time on their calendars
  4. 2 weeks out – prepare for presentation or outing
  5. 1 week out – prepare for the chats you set up
  6. While on-site – have your 1×1’s, presentation, outing, etc.
  7. Few days after trip – follow ups
  8. 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.

There are plenty of more remote work posts coming, sign up so you don’t miss out on the next one

* indicates required



 

Closing connections and returning results using node-oracledb

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.

 

Remote Work As Innovation

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.

Adopting remote work is innovation too.

 

10 Observations after Working Remote for 6 Months

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.

 

Calm Technology – CTA train tracker


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.

Design considerations

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.

 

Monopoly on Empathy

Look through any User Experience (UX) conference presentation description, UX profile on Linkedin, or go to any UX meetup and the word you will hear most often is “empathy.” As UX has become more formalized as a discipline over the last few years this word has been a rallying cry for the industry. “We fight for the user!” and “We bring empathy to software applications!” are commonly heard. But this word is problematic for many reasons and it’s a massive oversight by the profession that it continues to be used. It is not so much because of the word itself but moreso because of its application and implications. While “empathy” is the most commonly used, it’s certainly not the only one in this tale of poor language choices. A pass at slaughtering these sacred cows will be made too. I aim to point out how this language problem is ultimately counter to the goals of UX (both the end user’s experience, as well as UX as a profession). For want of avoiding making this seem like a fastidious excursion into semantics, I will also tie this into how it impacts UX’s standing within the corporation at large.

The foremost problem of using “empathy” to define your profession’s existence is that you are essentially stating that you as a UX professional have a monopoly on empathy. You are implying that developers, marketers, business people, and anyone else peripheral to the UX craft are apathetic, indeed the opposite of empathetic. It is implied that without you, there would be no empathy for the user, as if the rest of the project team would, whether through menace or ignorance, create and deliver an application that confuses and demoralizes the user. Of course, this is absurd; no one will argue with you that wanting to ensure your users can easily use your application and accomplish their goals is a positive thing. And it should be made clear that UX as a group does not have a monopoly on empathy, just as it does not have a monopoly on the user. Other groups are perfectly capable of wanting to ensure the application works well and easily for users. This is all without even mentioning that “empathy” is a very presumptuous term altogether.

Perhaps the second-most offensive word in our UX existentialist vocabulary is “delight”. Within an application measuring delight is subjective at best, and I can guarantee that no user study that utilizes the encroaching practice of video recording will be able to suss out or give any reliable data whatsoever regarding delight. The misguided pursuit of delight has led to unnecessary animations, uncalibrated and perhaps even overly personal/conversational help text and copywriting, among other things. While delight might be nice in video games or entertainment, I would argue it is not something that is even needed in all applications. Do users even want or need to be delighted? Delight should mean they accomplished their goal or task with the application, not that they saw some pretty colors and slick button animations (…Material Design). Or receiving confirmation emails like “you’re totally awesome for signing up dude, surf’s up!”

The final piece of language we will pick apart is certainly the easiest to do so, due in part to its lesser frequency compared to the prior, but also due to the extremity of its claims – “changing the user’s life.” If “empathy” or “delight” were pretentious or presumptuous, laying claim to “changing the user’s life” through designing experiences is mega-pretentious. Too often this language is a mask for signalling of the offending UX professional’s importance, not the user’s. “We are changing the user’s life” is how this is most often heard. The language has become self-serving, ironic given that UX is meant to not be about the designers themselves but about the user.

Why are we seeing such language be used, and used so boisterously? As mentioned in the opening paragraph, UX has only recently become an “official” group within most companies. While UX has been around for a long time, it’s acknowledgment by the corporation is more recent. Thus the profession has had to utilize language that displays confidence in an effort to establish and formalize itself as part of its entry into the corporate landscape. There is without question a degree of pretentiousness and egoism exhibited by some in the design and UX professions. Is the self-righteous language we are examining the brainchild of those offenders? Perhaps, but the more plausible cause is this birth-stage of the UX profession.

Any discipline at early stages is both burdened and liberated by being able to define themselves. Software engineering is a couple decades ahead of UX and thus has had to work to establish itself within the corporation for much longer, so observing the software engineering profession can serve as a cautionary tale for UX as I believe the isolating language that developers often use has resulted in the profession shooting itself in the foot time and again with regards to its standing within the corporate hierarchy.

A common attribute of the language discussed above is moralism (or even self-aggrandizing). Whether or not this is intended, what we can see is a two-fold effect: through moralizing, you start to create a division between you and other groups (them below, you above); through using this language to establish a jargon of its own for UX, you start to become other. Creating barriers between you and other groups – isolation – is existential death within the corporation. Don’t follow the mistakes that the software engineering profession has made by rattling off technical jargon and buzzwords, feeling shocked at the business’ lack of understanding (or more accurately, caring). UX does NOT want to get the same treatment while making remarks like “yeah we just need to boost the level of empathy with this onboarding flow so that we can delight our customers a little bit more and the user’s life will be forever changed.” Do this and UX becomes “those guys creating experiences and delight for our customers… or something like that, I don’t know but they’re in the basement somewhere” rather than a partner of the business.

Furthermore, empathy and delight are not easily understand in business terms. Something like “helping remove roadblocks for users so that our products are better and get more people through the funnel” – now that is something that the business can understand AND it works in service of the user. Hopefully it is evident that vague and vacuous terms like empathy and delight are terrible word choices for a profession that is working to establish more respect for itself within an organization. The reality is that sometimes business goals cannot be ignored, and designers unfortunately cannot always make the decision that is in the best interest of the user. They can “fight for it!” sure, but it can’t always happen and this is ok.

My recommendation: get rid of the moralizing and self-aggrandizing attitude and use language that puts you on equal footing with the business while explaining the importance of paying attention to user needs. Language puffed up to display a confident attitude may have helped when UX was working to establish itself within the corporation, but it can only do a disservice now. Language plays a larger role in business than many of us wish to acknowledge, so change this before it’s too late. Before UX becomes a group that is relegated to lower rungs of the organization, rather than seen as a business partner. Understand whether users actually need empathy or delight. Dispensing with this language can only help UX in its goal of being seen as a crucial element of the business. Developers have their own self-alienating language they use, and have suffered for it. UX professionals should stop now and avoid it before it’s too late. Take a more research-driven approach to design and gather metrics (where you can). Focus less on capital UX and more on lowercase ux, that is focus less on the profession and its existentialism and more on user experience. And if you truly believe that a software application can be “life-changing,” then it is ultimately the application itself, that is to say, the product, that affects this change. That product is everybody’s job, not just UX’s.