Syndication, democratisation and curation of data within the enterprise; killer combination

Syndication

If we take syndication to mean making content available to other sites/subscribers (e.g., web syndication)  then although enterprises seem to be happy with the idea of syndicating public facing content such as press releases, articles or white papers via social media, the idea of syndicating enterprise data isn't yet mainstream. 

So the definition of data syndication would be that data is published simultaneously in a number of other channels - those channels could be outside, or inside the enterprise.

If you're inside the enterprise it makes it more likely that whatever channel is preferred by a user, the user gets the exposed to the data. Perhaps more importantly, it ensures that whatever the data source is, there's a common way to access it. By syndicating the data into multiple channels, the data can be event driven to the user, who can then take control it - it's there on demand as opposed to needing to be found. So the benefit is speed; awareness; engagement.

The case for syndicating data externally is potent. Firstly, it's transparent, so it builds partnership and trust; for instance, the near instant visibility of customer demand down the supply chain can reduce the 'bullwhip effect'. In addition, real-time situational awareness speeds up vendor response. Perhaps organisations will want to bring customers into the product/service development process even earlier than they already are. Or customers could take a complete, cradle to grave view of product quality.

Democratisation

Democratisation concerns the spread of knowledge amongst end-users as opposed to a hierarchical broadcast mechanism. Kevin Rose (@kevinrose) makes some interesting points about the sheer volume of data on the internet and how democratisation is the masses deciding what's important or relevant.

Users in the enterprise face the same challenges as users on the internet; the volume of data is huge and increasing. (This is why enterprise search is big business - HP are buying Autonomy, Google are pushing their search appliance and Microsoft are working their FAST acquisition/Bing into the enterprise where they can). The enterprise needs the same democratisation capability as the internet. Users need to be able to find and through sharing 'vote up' those key trends and issues that need attention, whether it's the trend of data from a manufacturing plant instrument or an unresolved safety audit finding.

Democratisation means the right attention can be given to the right issues at the right time.

Of course, this is a tough thing to do; the nature of data in the enterprise is different - the historical lack of enterprise-wide search means metadata is lacking or inaccurate and vendors have spent years implementing protected, proprietary, and closed systems. But with intelligent design we can overcome this.

Curation

And so to curation. Buzzword du jour. There's a definite move away from the academic definition to curation as a development of the democratisation of internet content, usually via social media. The key factor is that content is filtered and organised by a human for a community of people with common interests, rather than aggregated by an algorithm designed to respond to a single query.

This is a logical step; faced with huge quantities of available data, there's just got to be some way to make sense of it all; what's worth reading and what's worth keeping? An algorithm can't answer those questions because it doesn't appreciate the nuances of the community and those shared interests. You need a curator to take the step from the personalisation around their interests (dealt with in Web 2.0) to the relevance of content or data to the wider community built around shared interests. 

As I write this in August 2011, there are few content curation solutions out there - most are in private beta and all are aimed squarely at the internet and socialising content.

Just as it's the next logical step for the internet, it's the next logical step for the enterprise. The enterprise is full of communities, from those with a shared interest in cycling to those with a shared interest in energy and sustainability, or safety. Communities are reliable, robust and inclusive; they lead to better decisions and by their very nature engage users and ensure that the relevant data gets to interested parties. A well curated community kills a reliance on email, or any other form of serial information delivery. Developing the idea of curating syndicated data mentioned above opens the door for expert third parties to be consulted or offer services. 

Altogether now…

Simply put, I believe that democratising syndicated enterprise data through user communities is a good thing. Each enterprise and each employee that works within it can be more autonomous, more expert and better connected. It's a killer combination.

The job of your staff is to populate your to-do list

....not the other way around.

What the hell…? The job of my staff is to do the stuff I tell them to, surely?

Well, no. The problem with a CxO/manager telling the staff what to do is that the staff are closer to the customer. Or the systems. Or the problem.

Now, this isn't intended as a recipe for corporate anarchy, or some sort of democratic leadership. The CxO has a job in terms of putting in place the structures and processes which ensure that the work gets done. (cf. 5 Rules, 8 Commandments). From that point on, the CxO/manager's job is to respond to what the customer/problem facing team is telling them - or needs from them.

So, the CxO/manager having decided that they/you want, say, an agile development team where the focus is on frequent releases at a production level of quality with low risk, it's the CxO/manager's job to get in place:

The simplest tool you can find.

The simplest, clearest, fewest guidelines necessary.

The simplest, clearest, smallest organisation structure you can define.

Then, let the guys on the ground talk to the customer, do their job, work within the tools, guidelines and org structure that's been prepared for them. The CxO/manager's job is to support them.

(You don't need someone to draw really complex processes that look great and never get followed.)

(You don't need to invest in something expensive or complex.)

(You don't - and as a former Programme Manager this pains me - need MS Project.)

For instance, managing a small development team on an agile software product development project, we have:

• Tool: Defect/issue management software TRAC (an open source solution). 
• Guideline: We flex enhancements in favour of defects for a weekly release.
• Org structure:
• One person takes responsibility for the crucial production trigger points 
• Everyone has a specialism.

Our sales team approach is looser as the team's smaller:

• Tool: Salesforce.
• Guideline: Find new & interesting people to work with.
• Org structure: One person per sector.

The beauty of this approach is that it's scalable. Want to expand the sales team to talk to more sectors? Duplicate it. Again and again. Want to scale up development? Duplicate it.

Every time you duplicate you increase the value of the information the CxO/manager supplies their teams as it can be used by each duplicated unit. Therefore you increase the value of every question that's asked of the CxO/manager.

Therefore you increase the value of every item your team places on your to do list; you increase the value of your contribution to the company.

I'll let you know how we get on.

Four things I say a lot to my team and what they really mean

Those around Sabisu are used to hearing me say;

1. 'Tell me what you need'

Nothing's worse than screwing up when it could have been avoided. I hate the phrase, 'if only'.

If we're about to lose a sale because we don't have a one page summary describing how great Sabisu is for supply-chain collaboration, then it would be nuts not to ask for it. 

Equally, if a customer needs to know why we've gone with functionality A and not B, or any other difficult question, then put them straight through to someone who can help; clear the decks.

Delegate upwards so those at the sharp end can focus on what they need to do.

2. 'Show me what you've done'

I see this as pretty close to Terry Leahy shopping in his own Tesco stores, or a chef working the pass; it's all about checking the quality. It says in Rework: everything is marketing. So everything has to be high quality.

By constantly reviewing what the team is doing, you don't need to check what the team is doing as much in the future; they'll get used to the possibility of a review and up their game to meet a higher standard.

For me, this is nothing more than the 'test first' approach of, say Extreme Programming, or the 'go to production early' approach of any agile methodology extended backwards into the pre-production lifecycle. Get it in front of the customer early to prevent defects being found expensively late in the development cycle.

3. 'Good job.'

Or 'nice one'. Or 'thanks'. 

(Or 'good stuff'. Or 'rocking'. Or 'awesome'.)

Being enthusiastic. Saying thanks a lot. It's just the right thing to do.

4. 'Riiiiiight...?'

Never smack down an idea until you're absolutely sure that (i) it's been expressed fully, (ii) you understand it, and (iii) you understand its implications. 

I suppose it's about pre-judging an idea. It's easy to do - particularly when you're tired, the kids are playing up at home and the dog has developed a horrific bowel ailment or whatever, but I try to remember that the guys in the office are great at what they do and most of the time their ideas are good.

So, 'Riiiiight?' really means 'tell me more'. They get that.