Tag Archives: management

Working Remotely

A bit of conversation has been going on around the web first because of Yahoo’s decision to axe telecommuting, and today because of a nicely written article from Jeff Robbins, CEO of Lullabot, the Drupal company. Bob McWhirter who I worked with a long time ago on JDOM, had a very similar spin on this back in 2010 where he talked about how Twine changed from being a distributed team to a co-located team leaving him as a remote worker.

I have worked a lot with off shore remote workers and I am currently working remotely most days of the week. This really can work, but as these articles point out, you must do this very consciously, taking time to think about your communication patterns that (sometimes) are just natural when you share a work location. Based on the number of management seminars, consultants, books and boot camps on leadership, teamwork and communication out there, I have to think “comes natural” is probably overstated. Taking some care to understand how your coworkers feel connected, included, with contributions encouraged and welcomed is important to all teams, but people seldom do this. The result is worse then for remote workers who lack the physical interactions with all their cultural norms to at least partially help people get on the same page.

For the me the key things that are absolutely essential are these:

  • A group chat tool everybody is in all day. Currently I like skype for this
  • A group video conference tool with good screen sharing capabilities.  Currently I like gotomeeting and join.me. Google hangouts are too slow and two fuzzy. So is Skype for the most part which is too bad.
  • IM with presence actively maintained,
  • equal attention to IM conversations that you would give somebody walking up to your desk.
  • Daily “stand up” phone conversations to talk about progress, plans, open (but don’t solve) questions and problems
  • willingness to jump into short, focused phone calls, individually or in small groups when needed
  • A propensity to CC email to more rather than less people. 
  • inclusion in the non-work conversations, babies, cars, trips, bands, all the good stuff
  • face to face get togethers, more often at first as you get to know people, but at least once per month after. I personally like to meet once per week face to face
  • very limited restrictions on what you can actually do remotely. This means distributed source code systems, accessible systems, vpns, whatever it takes to be equally productive remotely. Don’t make the office work 100% better than the remote worker.

I find this works for me, and found it worked with remote teams in other countries as well, at least to the extent that time zones are an issue. If language is an issue, most people can read and write much better than they can speak and hear a second language, so emphasize IM and chat over the phone call.

Mostly, actively include the remote people and you will be fine. Anything else and you will be one of the many people that have failed to incorporate a distributed work force. And too bad for you!

Are you conceptual or detail oriented?

Trajan's Column

Do you see the scenes or the spiral more?

I have spent a lot of time looking at how developers fit into the culture of the businesses that employ them. The disconnect that often exists is legendary and while there are many myths and opinions about the reasons, the disconnect continues. I often really connect with the business people I work and see their frustration, but also have experienced the frustration many developers feel. It comes down to communication but in this case, the communication needs to be between people who genuinely think differently.

Business people, particularly executives and leaders, are often conceptual thinkers in the sense that they see the goals to put in front of them, and hopefully align the right people and (sometimes) the systems needed to reach those goals without a lot of specifics as to how. Often times they believe something is possible because of a combination of their past interactions with the people and processes in place and sense that new requests of the team will be predictably similar. It is driven by their model of the system and their experience which leads them to believe it will react more or less predictably despite a definition of most of the details. Of course, these predictions are based on nothing rock solid if you look at the details and all manner of devils and dragons may still need to be found and slayed. On a bad day, somebody who lives purely in the conceptual frame of mind may resent having to muddy the concept with mind numbing details that can be contradictory and even force the concepts to change. Sound familiar?

Developers are usually very detailed oriented and are by necessity good at building precise sequences of repeatable actions with those details. People who are very detail oriented are invaluable on a team as projects work towards completion making sure every t is crossed and every i dotted. They eliminate uncertainty from outcomes to the degree possible and to the degree time allows. Without detail oriented people able to grasp and wrangle all the details to actually move work through to completion, your system may well *not work at all* or worse appear to be working, but actually be making major mistakes. A detail oriented person sweats this stuff and gets it right. On a bad day though, detail oriented people can be seen wasting tons of time chasing dead ends because they like to see things get completed or do things a certain way. They may over emphasize unimportant tasks because they don’t grasp the concepts that provide the context for prioritization and may avoid alternate or otherwise more appropriate solutions. At the worst case, they may produce a system that executes without errors but fails to solve the problem or opportunity originally envisioned. Sound familiar?

For a system to work all the way from imagination to completion, I think we can call agree that both conceptual and detail thinking is required. But if people can’t communicate well enough, what can be done? I think every participant in the process needs to possess a share of and appreciation of both conceptual and detail skills or you are in trouble. Everyone should exercise both their conceptual and detail skills. If you can’t deepen your sense of details, or step back to understand the driving concepts of your work you really risk delays or complete failure to deliver your projects.

Here is an example from my own life. I really like troubleshooting. Before I can do any sort of repair or troubleshooting, I have to have a model of how I think the thing works. Against this model, I create a hypothesis of problems that could produce the symptoms I am facing. Then I try to prove the hypothesis with various tests, observations and solutions. If the problem wasn’t solved, a couple of things need to happen.

  1. examine why the hypothesis was not correct
  2. improve my conceptual model to incorporate what I’d learned
  3. create more than one additional hypothesis of the next possible solutions
  4. pick the most likely hypothesis to try based on my improved conceptual model
  5. repeat until goal met, problem solved or solution determined

As a troubleshooter, you are often wrong. The way you thought things worked is often confounded by many variables, conflicting bits of evidence and sometimes incomplete vision of the inner workings of the system. Details! Yet, you have to get the thing working. A naive troubleshooter uses only trial and error to go through a list of mostly predetermined courses of action until hopefully the problem goes away. Case in point, “having a problem with your computer, rebuild it”. Results are limited.

It is the deep conceptual model that enables you to think of more possibilities and more accurately dispense with irrelevant details. It is attention to details that allows you to try a hypothesis and really understand what worked and what didn’t and from this improve the conceptual model in your head. These go hand in hand with neither working well without the other. Nearly all projects have the quality of a largely unknown solution to a project request at the beginning, and ever increasing understanding as the project progresses. It really takes your whole brain!

Where are you strong, being able to grasp lots of details, or in being able to think about a system in abstract conceptual terms? There is no right answer, but there is an outcome for you. Work on the one you are weaker in.