Episode One Hundred and Sixty Seven: How Are You?; Built It And They Will…; In The Gaps 

by danhon

0.0 Sitrep

10:12am on a Monday after what was frankly one of the weirdest things yesterday at the Oregon Renaissance Festival, that distinctly American tradition of dressing up and pretending that you haven’t died of the lurgy yet. But anyway: right now, a cool, cloudy morning, sat in Ristretto Roasters nursing an irresponsibly large mocha.

1.0 How Are You?

A new thing that many people in 2014 are experiencing, I think: the idea of knowing someone from afar without ever having heard their voice, without having seen them in the flesh, without breathing the same air as them or awkwardly laughing at the same ice-breaking joke. I wrote about this last in episode one hundred and sixty one, that feeling of a new negotiated dance where you’re not quite sure that there are missteps, but there are certainly faux pas. Or maybe not?

It’s pretty easy to think that you know me. I have a personality that is sliced and presented across multiple media, and there are some things that I elect not to control in terms of privacy. I have a public Twitter account, a public Instagram account and I can’t remember if my Foursquare, er, Swarm account is public or not. Sometimes my posts on Facebook are public. My profile on LinkedIn is public so as to, as the saying goes, “increase my surface area”, to make it easy as possible for you to figure out who it is that I am. And, of course, I write in this newsletter.

So the dance is this: it’s the social interaction and the give and take and the ums and the ahs and the micro facial expressions and the probing and the slinking back to establish some shared sort of understanding without actually come-on-out-with-it. It’s the: do I reference the fact that I know what you just said on Twitter? Do we both acknowledge that we know, kind of, that we stalked each other, if stalking is a thing? Do you say that you know that I fell off my porch and broke a tooth and suggest that perhaps we go somewhere that has nice soup today? Do I say that I’m sorry that your partner is sick?

Or, maybe now, a slightly more tentative form of: well, I’ll just expect that you know this now, and you’ll expect that I know too – at least, maybe not everything, then maybe most things, and if not, then we can negotiate around that instead.

Because how do you say “So, how are you?” when you have in your pocket a minicomputer that can access – for the right person – a stream of the minutiae of their thoughts, or at least, the ones that they wish to fire off into the ether? And how do you deal with it if you’re *good at remembering*, because that’s indistinguishable from *being super creepy*, right? The difference between having an ambient knowledge of someone so you can get to know them and say “So, what did you think of The Winter Soldier?” because you know they saw it a few days ago and liked it? Is that creepy? Or is that helping? Is that better than saying: “Seen any good movies lately?” because you want them to say “Why yes, just the other day I saw The Winter Soldier”.

It’s a dance, and there’s new music.

2.0 Build It And They Will…

Tom Loosemore was looking for things to talk about at the Code for America summit this week[1], and one of the inspired and quippy replies was the notion that if you build user-centrically, they will come[2].

We (I say we, I mean the general grouping of people-who-make-things-on-the-internet) kind of knew this for a while in that the general refrain to the other kind of people who wanted to make stuff on the internet was that they failed to realise *how* people would get to those things that were made. And so it was that we replied, invariably, with “build things where the people are”, which on reflection was only marginally better than “build things where the people aren’t,” which had been the default position.

The thing about building user-centrically is that to build centrically in the first place, you need to understand the user enough to know the centric bit. You don’t get to have a dream about building a baseball field in the middle of nowhere and hoping that some sportsball team will turn up. Instead, you have to, I don’t know, perform a whole bunch of user research to work out that there’s a genuine user need for baseball amenities in Iowa.

I mean sure, we end the film seeing that there’s enough user demand for at least ONE game of baseball in a field in Iowa, but hey, Iowa’s pretty big and did you do research on the population density lately? And they all drove there by car! That’s not sustainable!

Anyway: there’s a couple things going on here. One of them is nicely summed up in a pithy phrase coined by the wonderful John V Willshire[3], who says “Make Things People Want > Make People Want Things”[4], which is the kind of insightful thing that someone says after having spent a good amount of time in advertising and media. We end up with *better things* when we make things that people want, rather than spending time on making people want things that already happen to exist. It’s not that making people want things is necessarily bad (well, maybe it is after I just typed that out), but more that for a certain group of people who *used* to have to work in advertising and communications, the problem of making things that people want is more interesting than making people want things.

There’s probably a whole bunch of uncomfortable people thinking that if you throw away the whole Field of Dreams thing then we’ll never get any new stuff and it’s just a slippery slope step away from quantifying how people click on different shades of blue. But I don’t think that’s right: I think we still get to have new things, it’s just that we test them as we go along. It’s not like this kills off the potential for epiphany or to have some sort of intuition – it just means that we test the ideas that we have, and if they don’t work – after we’ve given them enough time, of course – then we move on.

[1] Looking for input into my Code For America keynote for tmrw – @tomskitomski
[2] Build user-centrically and they will come. – @JohnDodds
[3] John V Willshire
[4] Smithery.co

3.0 In The Gaps

So the recent stream of consciousness on awkwardly specialised connectors seems to have found a sort of resonance with people – at least, enough of you out there have replied or tweeted saying “this is me!” that it feels like I’m on to something. Or that I could embark on a fifth career writing horoscopes for people who use the internet (“You will feel a vague unease throughout the day, as if you are missing out on something”).

It definitely feels like there’s something in the connectory-ness, and also something in the innumerable soft skills many people have that provide broad understanding but not deep specialism. And at the same time, the fact that there are a bunch of people who certainly *know a little about a lot*, and can certainly have valid and useful opinions about things (ie, “directing”) but that, when it comes down to it, can’t actually *do* some of the things involved in a particular specialism because they don’t understand or are able to use the particular tools.

I suppose one other role or title that might make sense to look at is that of the architect: someone who has a sense of all the plans and how the things might fit together and the overall point of the thing, but doesn’t necessarily know what sort of timber to use where, or whether you can get the right kind of concrete. But, they may well know what properties that concrete should exhibit.

Part of this also feels like gappyness. Like, the problem with all of these specialisms is that you then don’t have a specialism for “everything that’s left over”, and someone is invariably left unofficially holding the bag. It sometimes appears like this on the outside when peering over the GDS fence, where it’s ostensibly *everyone’s* duty to care about the user experience, because otherwise, what are you doing in public service? In non-GDS organisations, where “ops” doesn’t understand that it’s not just about keeping the servers running, that user experience includes making things work *quickly* as well as reliably, whose responsibility is it that the site or experience loads quickly enough? Certainly there’s a threshold at which someone, at some high managerial or executive level declares that the site is “too slow” but other than that, who’s counting, who’s keeping track? Or who’s making sure that, apart from just moving bits of paper around, that everyone involved knows what they’re making? It’s a difficult job, to be in the gap, because organisations appear to be designed to not have gaps: they’re designed to have Perfect Communication, to exist in some kind of ethereal plane where people don’t like to have meetings because they don’t have to and five years ago, you didn’t have to *tell* people things or make sure that they understood them, because Basecamp existed and Basecamp Solved Everything. Or because you had a Trello and that Solved Everything too.

It’s perhaps a symptom of the kind of people who are excited about the *potential* of technology who aren’t necessarily also best suited to operationalise it. I was talking about this with friends in the days after XOXO, where when we were talking about Ed Catmull’s Creativity, Inc. book, it sounded like he was operationalising continuous improvement and self-reflection in the organisation, *as well* as being a CEO – or, rather, that that was his *job* as a CEO. Operationalising it means – to quote another GDS catchphrase “doing the hard work to make it easy” – which I interpret to mean as much about building the right kind of teams that can build the right kind of things. This then ends up being less about technology and, after having pulled on the thread for long enough, just being about What Happens When People Get Together To Do Things. Communication, miscommunication, understanding and misunderstanding. Are we all doing the same thing? Do you know why I’m doing what I’m doing? Do I know enough about what you’re doing? What is it, in the end, that we’re trying to achieve?

Right. I’m down in San Francisco tomorrow for the Code for America Summit – three days of being the brain sponge that I want to be in the world and learning everything I can get my hands on about civic technology and Doing Government Better.

As ever, send me notes because I love reading them, and also, a question this time: now that Apple are bringing down the inevitable axe on Aperture, should I just buy Lightroom outright, or should I now account for my monthly Adobe tithe?

Best,

Dan