Listening to Spotify today, I start with Pink Floyd‘s classic Meddle. After the album completes, Spotify takes me off to “radio” based on the album. I love this feature, btw, I’ve discovered a lot of new music this way. Inevitably this includes more Pink Floyd, which is – of course – awesome.
On comes Brain Damage from Dark Side of the Moon. As anyone who is familiar with this particular song knows, it is actually just the first part of a two-song series that includes the album’s closing track, Eclipse. (To be sure, DSotM is really just one long song, but I digress.) So of course I’m expecting Brain Damage to seamlessly segue into Eclipse.
Some interesting, though probably not unexpected, insights from the incredible humans at BigWideSky about “digital donation errors” made by non-profits.
As part of our study, 2019 State of Nonprofit Digital Giving, we secretly donated to 100 organizations across the nonprofit spectrum from humanitarian, healthcare, environment, food, animal groups, arts & culture, youth charities and more.
I just downloaded the report and am looking forward to reading the full results of the study. Just reading the summary, though, got me thinking.
The challenges faced by many non-profits goes well beyond fund raising. My recent experiences at the Code With a Cause events put on by GlobalHack showed me that many of these organizations know there are things they could / should be doing. There are plenty of open source, “free” tools out there for non-profits to use. But non-profits often a) don’t have the in-house expertise to implement and/or b) don’t have the funding to hire an agency (or freelancer) to develop the solutions they need.
Based on my understanding (which is admittedly limited), the main donations to non-profits are either financial contributions or a contribution of time in the form of volunteering, either in the execution of the main mission or in providing support to operations. There is, as the Code With a Cause events highlight, huge potential for the “donation” of technical – and experience design – expertise.
The big question, though, is how to vet and coordinate technical volunteers. Perhaps set up a non-profit that vets and coordinates technical volunteers, a sort of “volunteer staffing agency” specializing in developers and designers?
I’m currently reading three books. As I was thinking about which one I wanted to read last night I realized that I am reading each of the books in different formats. And not just in different formats, but from different sources.
Not long ago I was sitting with my friend Valerie on the porch of a cabin at Horseshoe Canyon Ranch, AR after a great day of climbing (is there any other kind?) talking about life, the universe, everything. I had recently heard a talk at a LaunchCode event about their expansion to Miami and other places where they mentioned the importance of being in urban areas, places where there were plenty of tech talent and jobs already, and couldn’t help thinking, “What about everyone else; the people who could really benefit from something like this live in the areas where this doesn’t already exist.” Our conversation eventually made its way around to how could we get programs like that to rural areas, places where there isn’t necessarily great internet connectivity and definitely no ready made tech infrastructure. How do we more evenly distribute the future that is already here? What difference would it make for the people in those communities? The world at large?
Some related thoughts from a couple of different sources.
We are running into the conflict between people that inhabit an inherited identity with the place that they are — coal-mining country, and the work that they do as a result of the place that they are — up against people that have values and ways of perceiving the world that have shifted because they are not identified by their place and the work that they do in the same way that location and a fixed place tells you who you are and how you be in the world.
We are in this amazing moment of evolving, where the values of some of us are evolving at rates that are faster than can be taken in and integrated for peoples that are oriented by place and the work that they’ve inherited as a result of where they are.
At the end of his book will “Scale”, Geoffrey West writes:
The IT revolution… has also led to the possibility that we no longer need to live in an urban environment to participate in and benefit from the fruits of urban social networks and the dynamics of agglomeration, which are the very origin of super-linear scaling and open-ended growth. We can devolve to develop smaller, or even rural, communities that are just as plugged in as living in the heart of a great metropolis.
Does this mean that we can avoid the pitfalls that lead to an ever-accelerating pace of life, finite time singularities, and the prospect of collapse? Have we somehow stumbled upon a way to avoid the ironic quandary that the very system that led to our great socioeconomic expansion of the past two hundred years may be leading to our ultimate demise, and that we can have our cake and eat it to? This is clearly an open question.
Digital transformation isn’t about getting better or more efficient at what you already know how to do, it’s about becoming better and more effective at identifying and executing outcomes you didn’t even know were possible.
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.
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.
In which I recount the tale of my first encounter with Service Design and become a member of the St. Louis UX and Service Design community (and meet some great people).
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.
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.
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.
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.
(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.)