Category Archives: Ounce of Perception

Original, sometimes long(ish) writing

Technology – required but not sufficient for digital transformation

Digital technology is a necessary component of digital transformation. In fact, digital transformation is only possible because of digital technology. And not only possible, but inevitable. Digital transformation isn’t something you do, it’s something that happens to you.

Digital transformation isn’t about getting better or more efficient at what you already know how to do. Yet, many organizations want exactly that, to simply “automate” the processes they already have, using these digital technologies to keep doing the same things they’ve always done in basically the same way. Online forms instead of paper forms, for example. Thinking in atoms, not bits. They think that the technology is sufficient to make them better; it helps the organization achieve some efficiencies of scale in getting done the things they’ve always gotten done. But this is not transformation.

At the same time, many employees of these organizations are concerned – and rightfully so – about what all these digital tools will mean for them. They are used to working on what is essentially an assembly line: a task passes from someone up the line to them, they do their piece of the task according to some predetermined set of rules or procedures, and then pass it down the line to the next person. Their job is to execute tasks when they’re told, in the manner in which they’re told to execute them. Input – black box – output, where the employee is a figurative black box in very real danger of being replaced by a literal black box of technology.

Digital technology is a necessary component of digital transformation, but is not sufficient to achieve transformation. Digital transformation is about becoming better and more effective at identifying and executing outcomes you didn’t even know were possible, and that requires a change in mindset, a change in culture. Dare I say, a change in purpose. From “we’re going to be the best at doing this thing thought up in the past” to “we’re going to come up with the best ideas and products ever.”

Otherwise your organization, like its employees, runs the very real risk of becoming a commodity itself, that figurative blackbox that is eventually, and inevitably, replaced by a literal black box.

Straight lines and sharp edges

I’m sitting on a plane as it boards, wanted to jot down some quick thoughts. I’ll come back in later to clean it up, add some links (that you are going to want to check out) and make it a bit more coherent.

In a blog post earlier today, Jim McGee discussed the boundary between strategy and tactics, how it used to be “well defined” – some people did strategy, some did tactics, and the two didn’t really overlap. But how it never really was so cut and dried and how we are realizing that. But we aren’t the first.

I’m currently reading Walter Isaacson’s new bio of Leonardo da Vinci, and one of the things that marked him as different in his time (and any time before him) was his realization that there are no straight lines or sharp edges in nature, and his incorporation of this knowledge into his art.

Then of course fractals and complexity.

Speaking of which, Dave Snowden recently wrote about the liminal spaces between the different sections of Cynefin. For example, the boundary between complexity and the complicated; going from one to the other is not a straight line boundary, there is an overlap.

My Service Design origin story

My background is more technical than what is traditionally considered “creative”, having received my B.S. in Electrical Engineering and spent the bulk of my career as an Army communications officer or a systems engineer designing comms and network systems. What you could call “old school high tech.” Most of my work was in text or technical system diagrams; the most visual aspect of my work and thought processes were expressed through mind maps. I had never heard of journey maps or service blueprints, but I have come to realize that I was using mind maps to serve a similar purpose.

I learned to program with FORTRAN (on punch cards no less) and learned HTML in the late ’90s, but didn’t get involved with modern software development until 2014 when I participated in the inaugural Launchcode class with my son, Zeke. Which led me into my first hackathon (which we won :-), then a couple of start up weekends and a couple more hackathons. All of which coincided with my introduction to service design.

It was the fall of 2014 when a friend sent me an invitation to attend the kick-off meeting of the St. Louis Chapter of the Service Design Network (aka SDN). I had never heard of “service design”, much less the SDN, but the invitation came from someone whom I knew would not send me something frivolous or not worth my time. So I checked it out.

My first reaction when I read the definition of Service Design on the SDN site was, “That’s what I do.” Or, a bit more accurately, “That’s how I work.” Needless to say I was intrigued and hooked. (Unfortunately that definition is no longer on the SDN site, and I don’t believe I have it written down anywhere – I’ll dig through my notebook archives later and see if I can find it.) I don’t know that I consciously realized it at the time, but as I read that description of Service Design I had alternating thoughts of “that’s how I work” and “that sounds a lot like making a movie”. Which very quickly led me to that understanding that, even though I don’t make movies, I have brought approach of a film production to just about every major thing I’ve done. End-to-end, top-to-bottom.

If you had asked the teenage me, “What do you want to do when you grow up,” the most likely answer you would have received would have been along the lines of, “Make movies.” That’s a whole ‘nother blog post in itself (several probably), the tl;dr being that my understanding of the film making process – from preproduction through production and on to postproduction – greatly influenced my approach to the various jobs I have had through the year.

So, at that kick-off meeting of SDNSTL, when Sean Walsh asked everyone to introduce themselves and their experience with Service Design, I basically told the assembled crowd the story I recounted above.

IEP - A Service Design approach: a talk for World Usability Day 2017

And what a great crowd it was. In addition to Dave Gray, who had invited me, it was at this kickoff event that I first met Sean Walsh, Martha Valenta, Nathan Lucy, and many more. All of these people have continued to influence my learning and enhance my understanding of Service Design, along with Human Centered Design and UX design in general. I have also become more involved with the SD and UX community here in St. Louis, where I have met many more incredible people and have the opportunity to participate in several different events and activities.

As I have been learning more of the language, tools, and methods of service design I have started sketching out some journey maps and service blueprints from some of my past projects. Partly as a way to gain more fluency with the language and artifacts of Service Design, and partly as a way to build a portfolio to go along with my more traditional resume. I am also starting to incorporate service design more explicitly into the work I do now, partly as a way to improve what I create but also to start spreading the word among my teammates and customers about the value of this approach to developing solutions.

This is the first of what I plan to be a series of posts about my service design journey, including some about specific projects from my past and some documenting my current adventures in reading, learning, and doing service design. I hope you’ll join me.

Layers of abstraction, the cost of convenience, and the commoditization of experience

The story of progress is one of abstraction, of increased convenience, and the taming of novel experience into the everyday.

An obvious example that comes to mind is in programming, and in fact this is the context in which the seed of this idea first came to me. In my first digital electronics lab at UMR we learned how to program the 8088 processor using machine language (or maybe it was assembly language). I have no memory of either language, but what did stick with me was the idea all higher level languages are simply abstractions of those languages that humans can understand and write. The farther away from machine / assembly you get, the easier (more convenient) it is to get the machine to do what you want it to do, but at the cost of understanding what exactly you are telling the machine to do. And as things get more convenient, you don’t even need the experience of understanding: writing a block of code to do something in a given context becomes nothing more than a copy/paste from Stack Overflow or some other place where someone (or something) else has already had the experience of creation.

A very different example, but one still close to my heart, is the sport of rock climbing. I learned to climb when I was in high school, in the early ’80s, when it was still a novelty. Before we could actually start climbing we had to learn basic rope management, the various knots, how to belay. And the gear, though effective, was by today’s standards, very rudimentary; if you needed your gear to do something, you figured out how to make it work. Today if you want to climb, you just go to the local rock gym, rent a harness and some shoes, get a quick lesson on how the auto-belay works, and away you go. Not saying this is a bad thing, I love that so many people are being introduced to the sport, even if they only climbing they ever do is in the gym. But that commoditization of the experience, that extreme convenience, abstracts them away from the joys of adventure climbing. And turns the experience of climbing, in many ways, into just another workout.

Of course, these examples are important, but they aren’t life and death. Like, say, knowing how to hunt, kill, clean, and prepare your own food. Or how to clear some land and build your own shelter. Or so many other aspects of simply surviving that we (in the so-called developed part of the world) no longer need to worry about. Or, perhaps more accurately, don’t need to worry about at the moment.

One last example for now: When I first heard Dave Gray talking about his latest book, Liminal Thinking, I wrote down “layers of abstraction” among my notes. Though different from the other examples here, I couldn’t help but see that connection. That the more we commoditize our thinking – the more we are on auto-pilot – the more abstracted we are from an understanding of where our beliefs come from, and the harder it is to understand where others are coming from.

The many layers of abstraction, the incredible conveniences we have today, and the commoditization of experience are not, in and of themselves, bad things. As I mentioned at the start, this is the story of progress. It’s when we forget that this is happening, when we start to believe that this is the way things have always been without understanding how we got here, that we run the risk of losing our ability to progress.

A year in books – my 2017 reading list

I have started on my 2018 reading adventure with Walter Isaacson’s new biography of Leonardo da Vinci (who, as readers of this blog will know, is a bit of a role model for me). I hope to do better this year at sharing my thoughts as I go. Because last year I barely did that at all, I thought I would go ahead and just share my list from 2017. It is a shorter list than some years, longer than others, surprisingly light on fiction this year. This does not, of course, include any of my “short form” readings online and elsewhere.

Would love to hear your thoughts on any of these books, and any recommendations from your own 2017 list that you think I should add to my 2018 list.

Non-Fiction

George Lucas: A Life by Brian Jay Jones

The Card Catalog: Books, Cards, and Literary Treasures by Library of Congress

Reformations: The Early Modern World, 1450-1650 by Carlos M.N. Eire

Some Remarks: Essays and Other Writings by Neal Stephenson

The Glass Cage: Automation and Us by Nicholas Carr

Faraday, Maxwell, and the Electromagnetic Field by Nancy Forbes

Alone on the Wall by Alex Honnold, with David Roberts

Reinventing the Sacred: A new view of science, reason, and religion by Stuart Kauffman

The Employee Experience Advantage: How to Win the War for Talent by Giving Employees the Workspace They Want, the Tools They Need, and a Culture They Can Celebrate by Jacob Morgan

Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Scale: The Universal Laws of Growth, Innovation, Sustainability, and the Pace of Live in Organisms, Cities, Economies, and Companies by Geoffrey West

The 7 Habits of Highly Effective People : Power Lessons in Personal Change by Steven R. Covey

Small Arcs of Larger Circles: Framing through other patterns by Nora Bateson

Hymns for the Fallen: Combat Movie Music and Sound after Vietnam by Todd R. Decker

Exponential Organizations: Why new organizations are ten times better, faster, and cheaper than yours by Salim Ismail

Fiction

Anathem by Neal Stephenson

Returning to Zero (Mick O’Malley #2) by Alan B. Johnston

Tinker, Tailor, Soldier, Spy by John le Carre

The Spy Who Came In From the Cold by John le Carre

The Tomorrow Code by Brian Falkner

The Rise and Fall of D.O.D.O by Neal Stephenson, Nicole Galland

(Note: the links to books on this page point to Amazon so that you can buy them if you’d like; if you do purchase a book by following one of these links, I will get a small percentage of the transaction. This will not increase your cost for the book, but will let me take Julie out for a nice meal once in a while.)

Shared understanding – two stories

Here are a couple of stories I’d like to share on the idea of shared understanding. The first, a conversation between me and my son, Zeke, highlights the importance of being aware of and understanding the context of a situation from different people’s perspective. The second, a story about a friend of mine, shows the importance of ensuring shared understanding in a shared context and how easy it can be to not have it.

You know the way home, right?

My son, Zeke, and I were in Milwaukee for the Midwest Gaming Classic. As we were walking from the hotel to the car getting ready to head home on Sunday morning, Zeke asked me, “You know the way home, right?” A reasonable question, and one that I could honestly answer with yes. Which was the right answer, though as it turns out that was not the question he was actually asking.  What Zeke was really asking was, “Can we listen to the radio on the way home?”  A little background may be in order.

map

On the drive up to Milwaukee I used Google maps on my phone, connected to the car audio system, as a navigator to get us from home to the hotel. Because I wanted the navigation to come through the audio system, we were limited to listening to music or podcasts (or other apps) from my phone and couldn’t listen to the radio. So when Zeke asked if I knew the way home, he was really wondering if I needed to use Google maps to get us home. If I had said, “No, I don’t know the way”, then he would have known that we wouldn’t be able to listen to the radio, and if I said “Yes” then we could listen to the radio. (If you’re wondering, we listened to a couple Premier League soccer matches and the first half of the Cardinals / Braves game.)

Because of our long history (nearly 25 years) together, I knew that he didn’t care whether or not I knew the way home. He knew that if I didn’t, I would simply use Google maps as my navigator. I did know that he cares about what we listen to in the car, that he prefers to listen to talk (usually NPR) or sports over music, and that he usually watches Premier League soccer on TV on Sunday mornings. So understanding where he was coming from allowed me to answer the question he was actually wanting an answer for. It’s probably worth noting at this point that Zeke is autistic and, while able to communicate verbally, has some unique challenges and methods in his communications. Developing this shared understanding has been critical for both of us to understand each other.

DO NOT LET GO, YOU ARE NOT ON BELAY!

Some friends were out rock climbing. It was an especially nice weekend, so there were a lot of people out taking advantage. There was one route my friends wanted to attempt so they waited while another pair were climbing. While most of my group of friends were relaxing and just generally hanging out, one friend – we’ll call him Dave – was watching the other pair climb. And good thing he was.

nwaHCR

When a climber reaches the top of a route on lead, he will typically clip directly into the anchors and go off belay so that he can fix a rappel to get back down. Sometimes, though, he will set some gear and run the rope through the gear so he can be lowered down and the next climber can then top rope the route. In this case, the climber did neither; instead, he down climbed to the last piece of protection he had placed on the way up, apparently with the expectation that his belayer would then lower him from that point. The belayer, however, was not aware of any of this, having expected that the climber had gone off belay at the anchor. (I think you can see where this is going.)

Dave, my friend, was watching all of this and saw that 1) the belayer had taken the climber off belay and 2) the climber was getting ready to let go of the rock and lean back to be lowered to the ground, which meant that 3) the climber was just about to plunge to his death. At which point Dave shouted at the top of his lungs, “DO NOT LET GO, YOU ARE NOT ON BELAY!

The route this pair was climbing was an overhanging 5.11c, meaning that this was an experienced pair of climbers (5.11c is hard) and that when the climber is on the top half of the route the climber and belayer cannot see each other. The typical exchange when the climber gets to the top and clips into the anchor would be for the climber to shout down, “Off belay” (to let the belayer know that they can take him off belay) and the belayer shouting back up, “Belay is off” to make sure that the climber knows he is on his own. In this case, the climber shouted something down, the belayer thought it was “Off belay”.  The pair thought they had a shared understanding of the situation, but they obviously did not. The climber had broken from the routine, while the belayer was following the routine because she didn’t know of the climber’s change.

Fortunately for this pair, and everyone at the crag that day, Dave’s warning was in time and successful in stopping the climber from letting go and leaning back.

The point?

There is no real definition of what “shared understanding” entails; it’s more of a “know it when you see it” kind of thing. These two stories, hopefully, show what shared understanding might mean in different situations; one being a situation where two people are coming from a different context and one where they are coming from the same context.

Would love to hear some of your stories about shared understanding, or the lack thereof.

 

Top-down vs. Bottom-up KM: Insights from the Katrina response

“The messiness of the web often deals with the messiness of disasters better than centralised systems which can fall over under pressure!”

A Facebook friend posted this today, reminded me of these early thoughts I had back in the aftermath of Katrina along similar lines. But back then we didn’t have Twitter, we didn’t have Facebook and Instagram and … and … and….

And just now on the TV news feed: “People are resorting to Twitter and Facebook because the 911 system is overwhelmed.” Not just to connect with the centralized authorities, but to connect with – and help – each other.

The Standard You Walk Past

This was one of the very first lessons I was taught as a young Army officer, many year ago, and I’ve never forgotten it.

“No tired eyes in this unit, Lieutentant. If you see someone doing something wrong, correct them. If you see something out of place or improper, fix it or tell someone who can. If you see a piece of trash on the ground in the parking lot at the Commissary, pick it up and put it in the trash can.”

Over time I learned that it was the smallest things, the things that no one would ever know you did, that had the most impact when someone did see you doing it.