Why call the blog 'One Less Cut in a Thousand' ?

Is there anything more dully self important than writing a post on why you called your blog a certain thing?

However, I was asked, so here's the answer.

You may have heard the expression 'death by a thousand cuts'; it derives from a barbaric method of execution used until 1905 in China but generally the phrase is used to describe 'creeping normalcy', or negative change which happens slowly in unnoticed increments.

My career so far has been spent on the inside of enterprises of all size. In my experience the most inspiring visions, innovative ideas and game changing technology fails to be adopted not because of a considered architectural or strategic decision to reject it but because of 'creeping normalcy'; the organisation fails to improve because there is inertia and apathy. Great ideas simply fail to find fertile ground - or, worse, we drift, apathetic, into creating terrible, unethical organisations.

Likewise, improvement projects fail not because of a considered decision to close them down - in fact, this is a successful scenario - but because lots of small negative actions chip away at the business case, or reduce uptake, or invalidate assumptions.

There are thousands of negative actions that reduce an organisations capacity to change, to improve. When I started the blog, my aim was simple; every post should have something positive a reader can take away that helps them to change their organisation; something positive to counteract the thousands of possible negatives.

Every post should be one less cut in a thousand. Perhaps one day we'll never make the first cut at all.

Real world enterprise social networks; why quality trumps quantity

I think the uptake of social media within the enterprise is really interesting. There are few independent studies (and lots of sponsored ones) so it was interesting to see the adoption of an experimental, completely unsupported and unpublicised enterprise Yammer implementation – it would be inappropriate to say when, where or how.

What happened was that following an initial burst of activity where the recruitment of new users went viral, it then went silent for about 9 months. There were very few messages, very few new users. Then the activity picked up again of its own accord; users would put up more messages and the join activity started to rapidly increase.

I must admit that having read about the Twitter new user ‘9 month bounce’ last year I was expecting it – basically, users go quiet after joining and then come back. This resonated because it’s exactly what I did with Twitter.

Of course, Twitter’s new user activity is obscured by the continuous near vertical (but linear, apparently) user number growth. In a limited environment any slow down in growth is much easier to see.

So why the dip? Why the pickup?

I think the dip was down to a few things;

1. Public nature of posting – people were a bit shy/wary.
2. Users unsure what to post, or why.
3. Insufficient followers – you post more when you have followers. Probably it's something to do with 9mths being the amount of time it takes to get enough followers as a new user in order for it to be worth tweeting.
4. Growth by spam; it was pointed out that on joining the platform spammed you to invite new users. These users might join but weren’t necessarily engaged.

Why the pickup?

Just my thoughts but:

1. It took 9 months to find the right users; a couple of users popped up out of nowhere and began posting on a regular basis, making the community active and therefore:
1. Useful
2. Accepted behaviour (cf.Gladwell’s ‘The Tipping Point’, particularly sections about ‘permission’.)
2. Personal social media penetration; users are relaxing about posting stuff. Without doubt enterprise users will get burned by posting inappropriate comments – and learn from it.
3. Viable network size; one of the reasons that Yammer wants to drive network growth (see 4 above) is that they’re aware that a big network is more likely to be robust and active, hence useful, hence endorsed by the enterprise.

Now, fascinatingly the relationship between the size of a network in the early stages of development and it’s activity was almost (could be?) mathematical: they correlated precisely. It was almost as if every single new post added a user, even though that user wasn’t addressed.

In fact, the number of messages was far below what we might expect; perhaps the quality of the network and network activity didn’t match the growth; perhaps quality drives quality, as growth drives growth.

The take away for me is that to build a quality network is more difficult and rewarding building a big one.

Where I've been going wrong with IT strategy

I love strategy. I love the idea. But it's only recently that I've come to realise where I've been going wrong all these years.

I've yet to see a company who has a non-IT core business define and execute a successful IT strategy.

By 'define' I mean clearly describe the vision, the goals/objectives,

By 'execute', I mean delivery of the strategic platforms and the solutions that sit on them; effective communication; mass adoption; proven benefit; everything defined delivered.
  

Sure, we see organisations deliver components of a successful strategy but never the whole hog.

Why?

Well, I don't think strategies are sufficiently agile. Certainly small, modern, agile enterprises seem to express themselves in terms that make big, mature, static organisations wince. Which is a bit strange seeing as they're both reliant on the same species to function.

Often, strategies don't actually mean anything. As soon as someone says the word, 'strategy', it seems to be the green light for academic techniques that don't actually resolve in anything a user would recognise. It's like even the communication of the strategy is FUD driven and scared of someone deconstructing the buzzwords.

Because they don't mean anything, they don't engage users. The guys on the ground floor don't care. The guys in the middle are busy being squeezed by the guys at the top and the guys on the ground floor. Vague, long range planning is your enemy. It doesn't translate into the real world.

Often, an the people within an organisation doesn't know what it cares about; what it stands for; what it's principles are. Think this is outlandish? Check out John Oliver, Grow Your Own Heroes.

So, strategists:
1. Make your strategy agile.
2. Eliminate buzzwords, be simple.
3. Engage users with tangible objectives.
4. Know what you care about.

As I said at the start, I love strategic thinking and know what a well chosen strategy can do. It's only now  I'm at Sabisu that the importance of it - and the way to make it really work - is becoming a little clearer to me. Here at Sabisu we're working up a bit of a guide on how we think strategy should be done and over the next few weeks we'll get round to putting up some ideas.

Why self-service BI is falling short

Having spent some time over the last couple of weeks introducing companies to Sabisu, it's clear that 'self-service' is seen as a big win - though the precise definition of what that means differs.

Every enterprise appears to have the same problems; complex business processes, a wide variety of often proprietary data sources, heavy use of IT expertise in integrating systems so that end users have the data where they want it. These problems result in duplication of data and a dependency on IT that destroys agility. How can you respond to incipient situations when you have to wait on an IT release schedule?

Everyone we've spoken to sees the answer in shifting capability out to the masses; empowering the end users by providing pre-configured reports or cubes where an end user can build report on-demand with recent data. Limited menu, often reheated data, but hot all the same - like fast food. This works to a degree, particularly in a slow moving environment, because you can schedule report generation or cube maintenance and the data will be 'recent enough'.

But it's not quite self-service. There's a long tail of requirements that the pre-built cubes aren't going to satisfy; all the IT department can do is invest more time, money and effort in building ever larger cubes as each new requirement is uncovered. Before you know it the costs associated with BI are spiralling, so the likelihood of tackling non-relational data or proprietary format manufacturing data is slight.

The end-user experience is often not great. User queries get invalidated as cubes are rebuilt (usually for IT reasons). Reports generated by different users don't tie up because different fields from different systems are confused - and implementing a data dictionary is often not viable, even if you can get cross-department agreement on a single version of the 'truth'. End users have to become proficient in what is, in effect, a development environment for building reports.

All this points to partial adoption at best on the grounds that the service just isn't great. It's got to be better.

I'm looking for:

• End user driven platforms, so no IT involvement - particularly none that could invalidate a trusted, end-user designed report
• Genuine end-user driven data access without needing to train everyone first - it's got to be built around modern UX principles
• Real-time, or as near as makes no difference
• Direct access to source data - if we're going to have a debate about the data, let's at least be clear on what we're looking at
• Some way to action BI; curate it for a community, make it actionable, collaborate on it
• Controllable expense - there's no way the enterprise should be penalised with increased expense or complexity for a user wanting to extract or share data