Sipping from the Firehose: The next Challenge for Social Media?

firehoseDespite my often tempestuous relationship with it, I love social media. Everyone’s a publisher; individuals and businesses alike.

If you want a platform to say something, you’ve got it. With the click of a button, your content is out there. The potential reach is tantalising, and we all religiously know how many friends and followers we have. Publishing is certainly cathartic and feels productive.

But there’s a problem we’re overlooking: Social media is ineffective for finding and consuming content.

Even when it reaches our devices and screens, there is simply too much to consume or it is unstructured, often interwoven with irrelevant and sponsored content. It is well known that a tweet has a very short lifespan, after which it is almost entirely unlikely to be read, hence a plethora of tools to help us schedule tweets to increase their audience. Due to the way they are presented to us, Facebook posts last longer, but our news feeds have grown exponentially and we seem less willing to scroll through it all.

Worse still, we no-longer even see everything that’s published with us in mind as the audience, because algorithmic filtering is now common, particularly on Facebook.

What does this mean? No-one’s really listening. Well, certainly not the size of audience we expected. The tantalising reach of social media — which basically means your content reached a device or screen — is misleading at best. We aren’t focussing on genuine reach; meaningful consumption of that content.

Even when content reaches its intended audience… their attention span is often scattered, knackered, insufficient by that point to absorb it, because they are drowning in other content. A page view means nothing if it lasted 2 seconds, or they scrolled on by the summary and didn’t even click. A “like” or a “favourite” may not mean they actually read the content, which is surely what we really wanted?

Attempting to sip from a firehose probably isn’t the best way to consume content, and surely publishing on social media is intended as a two-sided affair? We’ve focussed so-far almost exclusively on publishing itself, because it’s by far the easiest angle to tackle. We’ve constructed the firehose.

Isn’t it about time we did something for the consumers of all that content? After all, we spent time crafting it, so we want it to find the right audience and have an impact on them when it reaches them?

Is making social media consumable again its next great challenge?

Software Teams: One Vital Missing Question?

questionmarkBuilding software as a team may appear to be mainly about writing and releasing code. But it is underpinned by something much more fundamental: An ability to define and share information and complexity within the team.

It’s about making sure the ways in which we each model that complexity in our head match those of other team members. Unfortunately this doesn’t just happen magically, despite our best hopes and intentions.

If we aren’t all in possession of the relevant information and a similar view of the complexity we’re faced with, we’re forever building products that no-one wants (disconnected requirements and use cases), wasting time repeating development effort (wrong design / architecture / decisions), or building things that just don’t work (badly integrated, installed or deployed).

I’ve found that encouraging everyone to ask themselves one deceptively simple question, regularly and about almost everything they do, may provide the missing perspective that’s vital in keeping everyone on the same page: “Who else might need to know this?”  Yes, rather simplistic and, of-course, you have to act on the answer, but I think just remembering to ask that question about everything is the key change required.

What kinds of complexity and information are we needing to share as a team? For even the simplest of software projects:

  • Domain knowledge – Every business / sector has its own concepts. People arrive in the team with different backgrounds and therefore with a different need to familiarise with that domain knowledge. Without this, a fair portion of the thousands of little domain decisions an engineer needs to make each day will be inappropriate or wrong;
  • Terminology – For the domain and product, we’d better all be using the same words, right?! I’ve seen projects, where key terminology wasn’t nailed down early, go horribly wrong;
  • Research & Decisions – What we looked into (tech, architecture, anything), the decisions we made based upon our findings and the things we’ve learned. Recording these prevents us from revisiting prior decisions or mistakes unnecessarily, but also allows us to choose to revisit them, pick them apart and change our minds;
  • Architecture & Design – What we think we’re building, and how we’re breaking that down into components, infrastructure, etc;
  • Plans & Tasks – How we’ll build it, the individual chunks of work, sprint-by-sprint planning, agile boards… plus bugs as they arise;
  • Milestones – Points by which we’ll measure our progress. These should be in terms of usable chunks of the deliverable product itself, not just “sprint 1”, “sprint 2”;
  • Progress – Where we actually are versus the plan, and what else has happened on the way (because the plan always changes);
  • Product specifics – Usage, configuration, installation, etc. These arise throughout the project, and need capturing somewhere so the product is installable, releasable, usable, etc;
  • Product – The actual deliverable; probably many different versions of it and details of what went into each of them.

When it comes to sharing this complexity and information, most teams work on the basis that people will always ask what they need to know, at the time they discover the need. This is on-demand sharing. In an increasingly agile world, perhaps it feels like the right approach.

I’d assert that anyone missing a piece of information will often (though not always) ask what they know they need to know, but that may be incomplete. Even if they do in-fact ask, it will probably be for a very restricted fragment of information they know they are missing. What they will be without is context, background, and the top-down structure that would make the fragments more easily digestible by them. Context would also allow them to retain the information and to see the links — the bigger picture — rather than building their own mental picture iteratively from scratch, bottom-up, and perhaps by trial and error.

I’d say we should sharing all of this information much more keenly, and certainly before we think someone else may need it.

But isn’t keen sharing wasteful? Certainly not as wasteful as all those missed connections, delayed understanding, repeated work and the constant need to chase clarity. I’m not advocating writing lengthy documents, just capturing information, making it discoverable and keeping it up-to-date. Once captured, it can always be further structured at a later date.

For some of the information we need to share, there are already great tools out there, particularly task management and agile planning. But what are the best ways to share other information and complexity, and what are the pitfalls?

  • Online docs / wiki (lowest impact, longest-term retention, most transferable) – This is by far the best way to share to allow people to seek out information long-term and efficiently, but it comes with a health warning and an obligation: Wiki contents should be regularly reorganised for easiest navigation and digestion. They should also be updated, or marked as obsolete or, better still, archived when no-longer relevant. If a new hire needs the wiki explaining to them, it isn’t a wiki, it’s a dumping ground! The general rule is to encourage people to leave the wiki in a better state than when they found it. Besides the code base itself, the wiki represents shared team knowledge in its most accessible form;
  • Email – Whenever you email something, the need for which may go beyond a few days or a week, ask yourself the question “How will someone who isn’t on the receiving end of that email get the info?”. To retain the email benefit of highlighting the info to people right now, you may wish to email a link to a Wiki page instead, and this avoids the next new hire being unable to find it. Never email anything that doesn’t need drawing to the team’s attention now. If it simply needs to be available somewhere (a logical “somewhere”, preferably), put it on the wiki. Email inboxes are not a good repository for information;
  • Verbally / Whiteboard (highest impact, shortest-term retention, not transferable) – For the highest impact, nothing beats verbal communication; a stand-up, huddle round someone’s desk or a whiteboard, a meeting or presentation. Much of what was said may be lost beyond the occasion itself though, and it certainly isn’t available to anyone who wasn’t in the room (unless you recorded and uploaded it). Anything shared verbally or on a whiteboard should also be available on the wiki, either as a presentation / image, or by being absorbed into existing content after the meeting. Even just chronologically capturing whiteboard contents can help, and the structure can be rearranged later. Ask yourself if you’ve had to explain the same concept more than a few times. If so, it probably deserves to be documented somewhere.

Building software is about managing and sharing complexity. It may sound rather remedial, but encouraging people to regularly ask themselves “Who else might need to know this?” can affect a powerful change in the way a team works together and shares information. The answer usually prompts keen sharing and, if we also encourage the most appropriate methods and levels of sharing, it means that others will have access to the information when they need it, more often than not. Far from being cumbersome or time-consuming, keen sharing greases the wheels that lead to good teamwork… and perhaps even to better software.

In 2015, Tech Will Continue To Be the Enabler, Not the Whole Story


“The Year of Big Data”

“The Year of the Cloud”

“The Year of the Internet of Things”

These are snippets of New Year headlines predicting the year ahead… but from previous years, some as far back as 2011, not just from this January.

These technologies have been around, in some form, for a number of years and are inevitably constantly evolving. As with all reasonably new technologies, we have a habit, in January, of hailing this to be the year that they will make their mark. I’d argue all of these have already made their mark in some way, and will continue to do so as the relevant tech improves. But the real story — the real mark — is when organisations commit to and make genuine use of these technologies in business and human contexts.

The real Big Data story isn’t Hadoop, or Apache Spark (though they are the tech enablers)… it’s when a business consumes and makes use of petabytes of incoming and historical customer data to make timely decisions that optimise and improve (and, of-course, monetise) the experience of each customer. Just warehousing large amounts of data and, theoretically, being able to perform distributed computations against it isn’t really a Big Data story; we need to make use of it, in ways that impact and have the buy-in of the wider business. Many businesses have begun doing this in recent years, and that  is the real story.

The real Cloud story isn’t Heroku or Amazon Web Services (AWS), or SaaS, Paas or anything else ending “aas” (though they will continue to be the tech enablers)… it was the point at which businesses could make real deployments of their apps & services, beyond physically renting rack space or buying their own hardware, and could scale those deployments up and down at will to suit their ever-changing needs. It was the point at which budding entrepreneurs could use it to do the same, and bootstrap a startup from almost nothing.

The real story of the Internet of Things (IoT) probably isn’t any of the tech-based articles we’ve read so-far (though those early devices are examples of tech enablers), but will probably be when we actually monitor and respond to our environmental impact, manage infrastructure, optimise energy usage and diagnose or treat medical patients… on a large scale, via the use of connected devices. Some of the devices we’ve seen so far are heading in this direction, but they seem to be more about proofs of concept and novelty, and less about genuine benefit at this stage. So perhaps these are still early days for IoT and we’ve yet to see it make its real mark or write its real story, which will involve way more than the devices themselves.

So whilst it’s great to hail this year (and previous years) as the one in which certain technologies will make their mark, it’s worth remembering that they are merely the tech enablers in a wider business & human story, which is where their true mark will be made. Or else, what is technology really for?

The Great Offline

yorkshire-landscapeWell, not entirely offline. I didn’t actually spend New Year in a cave. But I did decide to spend the last two weeks of 2014 away from most forms of social media: Facebook, Instagram, Twitter. Basically anything I felt I was over-using and could do with a break from.

It seemed a good time, from 18th December until 1st January, to remind myself what the world is like without those sites and that minute-by-minute urge to “contribute”. Aside from the usual seasonal socialising and some much-needed down time, I planned to focus on other projects and prepare — at a more leisurely pace — a few lengthier blog posts.

After the first two days of the self-imposed social media break went by, it became clear that I needed to widen the scope. The first sign was the recruiter who messaged me on LinkedIn but who then took three replies from me to convince that I really, really only wanted to talk to him in January. Then there were the emails from folks wanting to arrange work-related drinks in the final week before Xmas. So, whilst I still checked my email once a day, and promised myself I’d reply if anything urgent came up, I decided to leave the rest there in my inbox, unread other than their subject line, until 1st January.

The relief at dropping the social media frenzy for a while and letting email pile up was rather unexpected, palpable and amazing. I rediscovered a slightly-less-connected world and, strangely, one in which I felt more deeply connected to real things: Face-to-face encounters weren’t interrupted by Facebook’ing, phone calls had my full attention, meals cooked at home didn’t get uploaded pictorially to Instagram. They just got eaten. I know, how refreshingly retro!

There were also other benefits: This blog post, to my delight, is easier to write without the constant distraction of inbound social media. I also drafted a longer software-related post for LinkedIn next week, the flow of which seemed to have eluded me until then but which came easily during the break from the constant notifications. I got my head around a new product idea that I’d been failing to define beforehand, and which I now found the focus to think deeply and easily about.

By unplugging from the distractions, and yet still remaining online in other ways, I regained a degree of that longer-term focus required to cultivate ideas, respond at-length, react appropriately and digest the articles and news that I was still choosing to read. Regaining that focus, albeit briefly, gave me a real sense of what social media and always-on email is doing to us. It’s somewhat scary what we’ve lost without even noticing, and how short-term and reactionary we — and hence our lives — have become.

Of-course, now the two weeks are over, I’m back in the social media world and my inbox has been tamed again, I realise I must have missed things whilst I was away: The constant commentary on every news story. The social status bingo of everyone else’s Xmas and holiday pics. The reactions and counter-reactions to every domestic stress and strain of the season. Minute, by minute,… by online minute.

Yeah, on second thoughts… perhaps I didn’t miss that much really.

Happy New Year!