Monthly Archives: July 2017

Remote work – some thoughts

Leave a reply

Earlier this week I saw “The Rise and Fall of Working at Home” listed in the “What people are talking about” section on the LinkedIn home page. I’ve been a remote worker for the last 10 years or so in several different positions, so I clicked through to see what people were saying.

A cursory glance gave the impression that most of the links in the #RemoteWorkers thread were about the impending fall of remote work (which is, by the way, significantly different than “working at home”), but there were some links with successes.

I have personally had great success as a remote worker. Even though I don’t physically see or interact with my team or my customers very often (almost never), the evolution of social collaboration tools over the past 10 years has made it easier than ever to connect and execute projects at a distance.

Among the many examples I could give, here’s one from this past spring. I spoke at JiveWorld17 with one of our users telling the story of how we developed a Community of Practice for a global legal practice. Jim and I had worked together off and on for nearly five years on this and other projects, and of course collaborated on crafting the talk and the slides. The kicker: Jim and I met face to face for the first time the night before the talk, after we had both arrived in Vegas.

It’s not always easy, though, when I am the only person on the team working fully remote, and the rest all come together at “the office”. Definitely requires adjustments on both sides of the “line”, and I find that I have to make a deliberate effort to stay in the know. Which isn’t all bad, because it makes me pay attention like I might not otherwise if I were always at the office. But it would be nice if everyone worked as if they were remote.

In fact, I’ve tried making exactly that case on occasion in the different positions I’ve had as a remote worker. Partly because it would make it easier for me to keep up with what is going on, but just as much because I think that the team as a whole would benefit from the transparency and the records of conversations. Here’s a quote from an article in the Wall Street Journal, Why Remote Work Can’t Be Stopped, that captures this perfectly:

The online communication required allows for radical transparency, since anyone in the company can search across all internal communications. “Most of the meetings were held behind closed doors at other places I worked at,” Julia Amosova of Automattic says. “I didn’t have the same feeling of unit and inclusion.”

Which raises one of the key challenges to successful remote work in organizations: culture. It’s easy (in this context) for individuals and the organization to be successful if everyone is a remote worker. Take, for example, Automattic and Basecamp.

On the other hand, the collection of “fall of remote work” stories are full of stories about organizations who have failed remote work programs, or who are pulling everyone back to corporate, because even though they say they support remote work, the culture is obviously hostile to the whole idea. For a whole host of reasons.

If you are interested in remote work, either as an individual or on behalf of your organization, I encourage you to read through the #RemoteWorkers thread.

Edit: As I was finishing up this article, putting some final touches on it, I saw an update come through my feeds from Jim McGee, with a link to his latest blog post, Free and Cheap Technology is Killing Organizational Effectiveness. It occurred to me as I read the post that part, a big part probably, of my success as a remote worker comes from a) my experience working on teams in many capacities before I started working remotely and b) a level of mastery with not just the tools of my trade but as importantly the tools that enable me to work remotely.

Now that I think of it, there was an article in the #RemoteWorkers thread about new members of the workforce preferring to work at the office so they can benefit and learn from the proximity of more experienced workers.

Something to explore in a future article.

Photo credit: Todd Miller

The adventure of a lifetime with the love of my life

Leave a reply

It all started off innocently enough. It was a month or so into the semester when a cute girl in the International Relations and Comparative Politics class I was taking changed seats and started sitting next to me. I’d like to think she moved because she wanted to sit by me, but the truth was she just wanted to get away from the person next to whom she had been sitting. Little did we realize the effects that would come from this seemingly un-extraordinary cause.

us

Just over 18 months after that fateful moment, and 30 years ago today, that cute girl and I launched what has become an adventure of a lifetime.

A week after tying the proverbial knot, and a few days on the beaches of the Bahamas, we hit the road for Ft. Gordon, GA where I was to report for duty as an Army Signal Officer. After that it was to Germany for three years, where I worked way too much (the Cold War was still brewing, after all) but we still made time to be with each other.

Spain, Italy, France, Belgium, Luxembourg, Austria, Yugoslavia (while it was still Yugoslavia), The Netherlands (Julie made that trip with friends, remember what I said about working too much). We spent our first anniversary in Venice. We were in Germany when the wall came down, and when we went to war in Iraq.

Climbing, camping, walking, eating, drinking the incredible beer. Even though we lived on post we made an effort to participate in local events and meet “the locals”. We added the first new member to our family, a bobtail (aka Old English Sheepdog) named Merlyn who went with us everywhere. The story of our return to the States, with Julie pregnant and Merlyn in the largest crate we could find, is an adventure tale all its own.

Our family grew again while we were again at Ft. Gordon, GA, and Zeke and Merlyn were instant buddies. We weren’t there too long (just for school) before making our way west, a bit closer to home at Ft. Riley, KS. Baloo (a Bouvier des Flandres) and Ian (a human child) joined the family. Closer to home than we’d been since we got married, we made quite a few road trips to Northwest Arkansas and St. Louis to see family. (Yeah, you guessed it, a lot of adventure tales to tell there – two babies, two dogs, are we there yet?)

fullsizeoutput_6bb.jpeg

Like every adventure, ours has had its share of challenges to overcome. It was at Ft. Riley that we learned that Zeke is autistic, which would prove to be an ongoing challenge for both of us to grow from. Not that Zeke was a challenge; he was the sweetest boy you’d ever meet and has turned into an incredible young man. No, the challenge was for us to understand and go beyond our own expectations of what parenting is and to become the parents that both Zeke and Ian needed us to be. As much as I learned from Zeke through all of this, I learned ten times more from Julie.

In addition to being autistic, Zeke was hyperlexic. It was Julie who thought to carry around a small whiteboard on which to write things. It was Julie who would write out the alphabet and words tirelessly as she helped Zeke build his communication skills. It was Julie who worked with our fantastic occupational therapist to put labels on everything in the house so that Zeke could learn the names of things. I could go on like this forever.

As in Germany, I worked entirely too much while at Ft. Riley. As a Company Commander, I was basically working all the time. But Julie was not just an incredible wife and mother during this time, she was an unbelievably awesome commander’s wife. If you’ve served in the Army, you know what I mean.

After a few months apart as I attended various schools and Julie remained at Ft. Riley, we ended up at Ft. Monmouth, NJ. Where, as you are probably expecting me to say, I worked way way too much, including a crazy amount of time away from home. As Zeke was entering school (which, by the way, the doctors said he would probably never be able to do), we found that the challenges related to autism were just beginning. I’ve written elsewhere here on the blog about some of that, so won’t hash it out again. Except to say that Julie was the driving force for making sure that Zeke got what he needed.

This gets us to just about the halfway point, about twelve years in to our adventures together. I could go on and on, but hopefully by now you know where I’m going with this.

I can’t believe it has been 30 years already, and I can’t wait to see what the next 30 bring.

 

Thinking in bits (redux)

Leave a reply

A key to any organization’s survival of the ongoing digital reformation will be their ability to break free from the deeply ingrained thinking in terms of atoms and start thinking in bits.

I first came across the idea of thinking in bits in Nicholas Negroponte‘s 1995 book Being digital. In the book, Negroponte talks about the limitations, the cost, of moving information around as atoms – paper books, CDs, DVDs, snail mail, you get the idea – and how information would soon be converted from atoms to bits. The immediately obvious implication is that it now becomes essentially free to move and share information as bits.

The less obvious, but much more important, implication is that bits change the way you can think about the information. How you can manipulate and repurpose the information. How you can do things that were impossible with the information locked up in atoms. The obvious applications have come to fruition. Email instead of snail mail. Music downloads instead of CDs, and now streaming instead of downloads. The same with video.

And yet…

And yet, the way this digitized information, these bits, is handled is still in many ways tied to the way atoms were handled. The medium has changed, but the process remains the same. Some of this, such as in the music and movie industries, is purely for commercial reasons. They are shipping in bits, but they are not thinking in bits.

Even from a creative perspective, as opposed to the commercial, this thinking in atoms prevents many from seeing new possibilities for providing engaging and individual experiences to their customers. For example, consider how labels distribute music, how they release the same tracks in the same order on both CD and on services like iTunes or Google Play. This is thinking in atoms at its finest (worst?).

Imagine if they were thinking in bits instead. They could offer an “album” that includes songs from the setlist the band played in your town, or edit the songs at the disc-breaks on multi-disc albums so they didn’t fade out / fade in. For individual song downloads from live recordings they could edit the track so you didn’t catch the introduction to the next song at the end of the song you’re listening too.

The same is true, albeit for different reasons, inside many organizations. Yes, nearly everything is in bits, stored on shared drives, in Sharepoint or email, on an enterprise social network or whatever system your organization uses to “manage” content.

And yet….

And yet most of these bits are locked up in mere digital representations of atoms. Again, working in bits but not thinking in bits.

Of course, 20+ years after Being Digital things have changed quite a bit. Many companies have leveraged thinking in bits to their advantage. Tax preparation software companies come to mind: the process of collecting the necessary information is designed to meet the needs of the person entering the information while the output of the information is in the format (atom-based) necessary for submission to the appropriate agencies. (Sadly, my guess is that those agencies still have atom-based processes to actually handle the information.)

And technology has evolved radically. Blockchain comes to mind. But even there, in a highly thinking in bits based process of transactions, most people’s attention is drawn to the most atom-based aspect of the blockchain – it’s use as a currency.

Digital transformation is not, as some people think, something you do. It is, rather, something that is happening, something that is happening to you. Whether you want it to or not. Thinking in bits is your key to not just surviving the transformation, but to leading the way.

A brief case for inclusionary accessibility in design

1 Reply

I was at a local big-box store the other day picking up some hardware for a home improvement project and had the need to visit the men’s room. It is a large store and so has a relatively spacious men’s room, with the sinks just inside the entry followed by a row of four urinals. As I walked in I was struck by the fact that the four urinals appeared to be exactly the same, except for one detail. If you can see the featured image of this post, I’m sure you know what I’m talking about.

I couldn’t help wondering, “Why didn’t they just install them all that low to the ground?”

Of course, that was a somewhat rhetorical question to myself because I can easily visualize how the design process went.

Based on the size of the store, the building codes require us to have four urinals. Let’s go ahead and put them along this wall here and install them at the standard height. Oh, except for one that needs to be lower because, well, you know, the “rules”. Left or right side? Doesn’t matter, as long as we have a short one.

And as a result only one of the urinals was installed lower to the ground, because that was all that was required.

It would be easy enough to say that “accessibility” was not considered in the design process for this men’s room, or that it wasn’t sufficiently considered. I would argue, however, that this design is very much based on a consideration of accessibility. It’s just that the accessibility considered was exclusionary and not inclusionary.

Here’s what I mean.

Back when modern urinals were first designed to be more than an open depression or slit in the ground that men stood around to, well, you know, the only people who would ever use them would most likely be adult men. There was little or no effort made to make it possible for those with physical handicaps to even get into the building, much less any thought given to how they might use the restroom. So the urinals were designed to be exclusively accessible to adult men who could stand up in front of the urinal. (To be clear, this is just an assumption, my impression based on my understanding of history in general.)

Fast forward to today when we know better and make more effort, at least on paper, to make access to spaces and facilities more inclusively accessible. The exclusionary approach is so ingrained in the culture and in design that making something accessible for the “other” is seen as something separate, something that needs to be done because someone somewhere said it had to be done.

An inclusively accessible design for this men’s room would have, in my mind anyway, had four urinals closer to the ground than the old standard (it should become an old standard, anyway). To take it even further, the design and construction standard (and building codes, to be sure) should be changed to reflect this inclusive design approach.

If one of the urinals is going to be lower to the ground than the “usual”, why not just make them all lower to the ground? In this way you are meeting the needs of all (or at least more) with one simple change.

To be sure, inclusionary accessibility is more difficult in some situations than in others. The urinal example above is relatively straightforward compared, for example, to the challenges software and website developers have. Unlike the physical example of the urinal, which can easily accommodate all users with a single configuration, software developers have to understand and contend with often competing and contrary needs.

A basic example is the user interface of a web site in a web browser. Just take a moment and consider how you use the web browser on your laptop. Now, close your eyes and think about how you would use the web browser on your laptop if you couldn’t see it.

For the person who can see the screen, visual cues are typically sufficient and they would likely not want to hear a description of the screen or the layout read to them as they navigate the page. But for the person who can’t see the screen, the actual visual design of the site is unimportant and, for all intents and purposes, of no value. They need another way with which to navigate and to consume the content.

Which gets us back, once again, to the prevalence of exclusionary accessibility in design.

Blind people aren’t going to use a web browser, how would they see it? So we’ll just design it based on people being able to see what they are doing.

I am encouraged by some recent examples of incorporating accessibility in digital design. WordPress, for example, requires that “all new and updated WordPress code must conform with the WCAG 2.0 guidelines at level AA”. The upcoming St. Louis Service Design and UX Conference has accessibility as a focus; I hope that the speakers will at least touch on this idea of inclusionary design. And I am especially encouraged by the growing (slowly growing, but growing) awareness and use of human-centered design principles.

But none of this matters if “accessibility” continues to be seen as something separate from the main design, an add-on for the “others” that can’t use the “real” version.

We need to become inclusionary not just in our design work, but in how we see the world as a whole.

 

 

You should always follow the rules (except when you shouldn’t)

Leave a reply

 

Note: This post references concepts explained in the Cynefin framework. 

The typical organizational decision making process treats most operational issues as if they are Ordered, a complicated (or obvious) problem that needs to be solved. Based on your understanding of the situation you develop several courses of action, based on rules or “good practices” that have worked to some degree in the past, and implement a course of action with the belief that you can accurately predict the outcome of implementing the course of action based on past experiences. This assumes, in general, either a relatively static (non-adaptive) situation or a situation that develops in a predictable manner.

Many situations we face today, however, fall increasingly in the complex domain. In this case, you respond to the situation without any separate and discreet analysis or planning. If your actions don’t achieve the desired results, you take what you’ve learned (sense) and respond again. You don’t know what you are going to need to do until the situation presents itself, and you don’t know if it will work until after you’ve tried.

To dip into a pop culture reference, an episode of the TV show “The Last Ship” presented a scenario in which both obvious, complicated, and complex challenges presented themselves, all as part of the same situation. This is a very condensed description tailored to fit this conversation.

The ship is hunting – and being hunted by – an enemy submarine.

The Captain is on the bridge and his staff is providing him the information he needs to decide the appropriate course of action. A well defined task, with years of training and experience, he knows exactly what he needs to do, and his staff know exactly how to respond to the Captain’s orders to achieve the desired result. Obvious.

The ship’s sonar was damaged in a previous action. The Chief Engineer have a sensor that they can adapt to act as a sonar-like device to acquire the target, but have many technical, operational, and other practical considerations they must consider to make this happen. They know the constraints they have and what they need to do to make it work. The Chief coordinates each person’s actions to bring their experience to bear to plan and achieve the predicted results based on past experience. Complicated.

A land team comes across an unexpected gun emplacement threatening the ship. They don’t know exactly how many enemy personnel are manning / guarding the guns, nor do they know the terrain beyond the cover and concealment from which they will begin their assault. When asked the plan, the team leader responds simply with, “Win.” Each member of the team then executes the plan, responding as they learn more about the number of enemy personnel, the lay of the land, etc. Complex.

Organizations tend to look at all problems as if they are obvious or complicated, that we can simply apply a known rule or process and get the predicted / desired outcome. Which is great for when the problem you face is actually obvious or complicated. Too often, though, organizations prematurely try to reduce a complex problem to the point that they are obvious so that we can standardize and automate as much as possible.

When you try to solve a complex problem as if it were obvious, you are just begging for trouble.

image credit: Dave Snowden, retrieved from Wikipedia on 10 July 2017