Monthly Archives: November 2009

Innovation [2009-11-30]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

  • Patent Volume Isn’t the Best Innovation Gauge [BusinessWeek: Innovate]
    Patent volume isn’t necessarily a valid proxy for innovation. A study by the Patent Board, an intellectual-property consultancy, shows there are other—and better—ways to quantify innovation. Ranked by sheer volume, Honda Motor is No. 1, with 54. That’s almost twice second-place Panasonic, which has 28. Ranked by other metrics, though, Honda isn’t a leader.
  • The Downside of Seeking Common Ground [strategy+business]
    People’s tendency to find common ground in conversation by focusing on what’s familiar can stifle the most innovative thinkers.
  • Is America Losing Its Mojo? [Newsweek]
    Innovation is as American as baseball and apple pie. But some traditions can’t be trademarked.
  • Innovation relies on synthesis [Innovate on Purpose]
    We often talk about the importance of combining disparate skills or capabilities when innovating, or holding two diametrically opposing ideas and finding the happy medium. What should be obvious is that one of the most important skills from an innovation perspective is the act and insight of synthesis.

The price of regret

I learnt a new term at lunch the other day: regret cost. Apparently this is the cost incurred to re-platform or replace a tactical solution when it can no longer scale to support current demand. If we’d just built the big one in the first place, then we wouldn’t need to write of the investment in the tactical solution. An investment we now regret, apparently.

This attitude completely misses the point. The art of business is not to take the time to make a perfect decision, but to make a timely decision and make it work. Business opportunities are often only accessible in a narrow time window. If we miss the window then we can’t harvest the opportunity, and we might as well have not bothered.

Building the big, scalable perfect solution in the first place might be more efficient from an engineering point of view.  However, if we make the delivery effort so large that we miss the window of opportunity, then we’ve just killed any chance of helping the business to capitalise on the opportunity. IT has positioned itself as department that says no, which does little to support a productive relationship with the business.

Size the solution to match the business opportunity, and accept that there may need to be some rework in the future. Make the potential need for rework clear to the business so that there are no surprises. Don’t use potential rework in the future as a reason to do nothing. Or to force approval of a strategic infrastructure project which will deliver sometime in the distant future, a future which may never come.

While rework is annoying and, in an ideal world, a cost to be avoided, sometimes the right thing to do is to build tactical solution that will need to be replaced. After all, the driver to replacing it is the value it’s generating for the business. What is there to regret? That we helped the business be successful? Or that we’re about to help the business be even more successful?

Posted via email from PEG @ Posterous

The rise of task worker 2.0

Companies are delayering (again) and pushing decisions to the surface of the organisation, where there is direct contact with customers and partners, in order to be more responsive. Some companies, Zara for example, are making this into a science as they re-engineer their organisations to maximise agility. To do this companies are empowering the people working at the customer and partner interface to solve the problems in front of them, without intervention from head office or middle management.

One interesting effect of this is a shift in the coalface of Enterprise 2.0 adoption. We’ve been focused on the white collar, office bound knowledge worker as the adopter of Web 2.0 tools in the enterprise, with mobility limited to the ability to work from a local coffee shop or an executive tweeting from the airport lounge. However, with decisions devolving to the customer and partner interface we are finding that the middle layers of our organisations are being trimmed, and their responsibilities transferred to the people with direct customer or operational contact. Knowledge workers are being superseded by task workers: people focused on consuming information in the field to solve operational or customer problems.

Think about how Toyota structures production lines—the whole LEAN story—empowering the people on the shop floor (traditional task workers) to solve problems. Or the utility field worker on maintenance, who used to work under instruction from the depot but is now mobile, working remotely. Or the transactional shop assistant who’s focus is shifting from the financial transaction to customer management. And so on.

To a certain extent, Web 2.0 and Enterprise 2.0’s traditional target, the white collar knowledge worker, is being eliminated by the very technology that is intended to empower them. And their replacement, the situated task workers, has been ignored by the Enterprise 2.0 rollout. Or, even worse, we’ve deliberately locked down their computing environment to prevent them going off task.

This creates an interesting challenge. How do we move from our early adopters and use our new collaboration tools and technique to support (and not distract) these task workers, situated in a challenging operational environment?

Posted via email from PEG @ Posterous

We need a better definition for “mash-up”

Mash-up no longer seems to mean was we thought it meant. The term has been claimed by the analysts and platform vendors as short hand for the current collection of hot product features, and no longer represents the goals and benefits of those original mash-ups that drew our interest. If we want to avoid the hype, firmly tying mash-up to the benefits we saw in those first solutions, then we need to reclaim the term, basing its definition on the outcomes those first mash-up solutions delivered, rather than the (fairly) conventional means used to deliver them.

Definitions are a good thing, as they help keep us all on the same page and make conversations easier. However, what often starts our as a powerful concept—with a clear value proposition—is rapidly diluted as the original definition gets pulled in different directions.

Over time, the foundation of a term’s definition moves from the outcome it represents (and the benefits this outcome provides), taking rest on the means which the original outcome was delivered, driven by everyones’ desire to define what they are doing in relation to the current hot topic. Next, the people who consider it to be just a means, often start redefining the meaning to make it more inclusive, while continuing to claim the original benefits. We end up selling the new hype as either means or goals or any half-hearted solution in between – and missing the original outcome nearly completely

The original mash-ups were simple things. Pulling together data from two or more sources to create a new consolidated view. Think push-pins on a map. Previously I would have had to access these data sources separately—find, select, remember, find, select correlation, click. With the mash-up this multi-step, and multi-decision workflow is reduced to a single look, select, click. Many decisions became one, and I was no longer forced to remember intermediate steps or data. 

It was this elimination of unnecessary decisions that first attracted many of us to the idea of a mash-up. As TQMLEAN, et al tell us, unnecessary decisions are a source of errors. If we want to deliver high quality at a low cost (i.e. efficient and effective knowledge workers) then we need to eliminate these decisions. This helps us become more productive by spending a greater proportion of our time on the decisions that really matter, rather than on messy busy work. Fewer decisions also means fewer chances for mistakes.

Since those original mash-up solutions, our definition of mash-up evolved. Todays definitions are founded on the tools and techniques used to deliver a modern web-based GUI. These definitions focus on the technology standards, where the data is processed (client vs. server), standards and APIs, and even mention application architectures used. Rarely do they talk about the outcome delivered, or the benefits this brings.

There’s little difference, for example, between some mashups and a modern portal. We can debate the differences between aggregating data on the client vs. the server, but does it really matter if it doesn’t change the outcome, and the difference is invisible to the user? The same can be said for the use of standards, APIs used, user configuration options, differing solution architectures and so on.

The shift to a feature-function base definition has allowed the product vendors and analysts of seize control of our definition, and apply it to the next generation of products they would like us to buy. This has diluted the term to the point that it seems to cover much of what we’ve been doing for the last decade, and many of the benefits ascribed to the original mash-ups don’t apply to solutions which fit under this new, broader church.

Modern consumer home pages, such as iGoogle and NetVibes for example, do allow us to use desk and screen real estate more effectively–providing a small productivity boost–but they don’t address the root of the problem. Putting two gadgets on a page does little to fuse the data. The user is still required to scan the CRM and order management gadgets separately, fusing the data in their head.  Find, select, remember, find, select correlation, click rather than a single look, select, click.

The gadgets might be visually proximate, but we could do that with two browser windows. Or two green screens side-by-side. The user is still required to look at both, and establish the correlation themselves. The chair might not swivel as much as with old school portlets, but eyeballs still do, and we are still forcing the user to make unnecessary decisions about data correlation. They don’t deliver that eliminate unnecessary decisions outcome that first attracted us to mash-ups.

The gold standard we need to measure potential mash-ups against is the melding of data used to eliminate unnecessary decisions. This might something visual, like push-pins on a map or markup on an x-ray. Or it might cover tabular data, where different cells in the table are sourced from different back-end systems. (Single customer view generated at the user interface.) If we fuse the data, building new gadgets which pull data attributes and function into one consistent view, then we eliminate these decisions. We can even extend this to function, allowing the user to trigger a workflow or process that make sense in the view they are presented, but with no knowledge of what or where implements the workflow.

We need a definition for mash-ups is that captures this outcome. Something like:

A mash-up is a user interface, or user interface element, that melds data and function from multiple sources to create one single, seamless view of a topic, eliminating unnecessary decisions and actions.

This v0.1 definition provides a nice, terse, strong definition for mash-up which we can hang a number of concrete benefits from.

  • More productive knowledge workers. Our knowledge workers only spend time on the decisions that really matter, rather than on messy busy work, making them more productive.
  • More effective knowledge workers. Fewer decisions mean fewer chances for mistakes, reducing the cost of error recovery and rework resulting in more effective knowledge workers.

Posted via email from PEG @ Posterous

We can be our own worst enemy

The only certainties in life are death and taxes, or so we’ve been told on numerous occasions. I’d like to add “change” to the list. Change, be it business change or change in our personal lives, has accelerated to the point that we can expect the environment we inhabit to change significantly in the immediate future, let along over the length of our careers. If we want our business to remain competitive in this ever evolving landscape, then overcoming our (and our team’s) own resistance to change is our biggest challenge.

The rules we have built our careers on, rules forged back in the industrial revolution, are starting to come apart. Most folk—from the Baby Boomers through to Gen Y—expect the skills they acquired in their formative years to support them well through to retirement. How we conduct business might change radically, driven by technological and societal change, but what we did in business could be assumed to change at a slower than generational pace. We might order over the internet rather than via a physical catalogue, or call a person via a mobile rather than call a place via a landline, but skills we learnt in our formative years would still serve us well. For example, project managers manage ever increasingly complex projects over the length of their career, even though how they manage projects has migrated from paper GANTT charts to MS Project, and now onto BaseCamp.

Which is interesting, as it is this what, the doctrine, which most people use to define themselves. A project manager manages projects, and has (most likely) built their career by managing increasingly larger projects and, eventually, programs. Enterprise architects work their way toward managing ever larger transformation programs. Consultants work to become stream leads, team leaders, finally running large teams across entire sectors or geographies. An so on. The length of someones career sees them narrowing their focus to specialise in a particular doctrine, while expanding their management responsibilities. It is this doctrine which most people define themselves by, and their career is an constant investment in doctrine to enhance their skills, increasing their value with respect to the doctrine they chose to focus on.

This is fine in a world when the doctrines a business needs to operate change slower than the duration of a typical career. But what happens if the pace of change accelerates? When the length of the average career becomes significantly longer than the useful life of the doctrines the business requires.

We’ve reached an interesting technological inflection point. Information technology to date could be characterized as the race for automation. The vast bulk of enterprise applications have been focused on automating a previously manual task. This might be data management (general ledger, CRM, et al) or transforming data (SAP APO). The applications we developed were designed as bolt-ons to existing business models. Much like adding an after-market turbo charger to your faithful steed. Most (if not all) of the doctrines in the technology profession have grown to support this model: the development and deployment of large IT assets to support an existing business.

However, the role of technology in business is changing. The market of enterprise applications has matured to the point where a range of vendors can supply you with applications to automate any area of the business you care to name, making these applications ubiquitous and commoditized.The new, emerging, model has us looking beyond business technology alignment, trying and identify new business models which can exploit synergies between the two. A trend Forrester has termed, Business-Technology.

The focus has shifted from asset to outcome, changing the rules we built our careers on. Our tendency to define ourselves by the doctrine we learnt/developed yesterday has become a liability. We focus on how we do something, not why we do it, making it hard to change our habits when the assumptions they are founded on no longer apply. With our old doctrines founded on the development and management of large IT assets, we’re ill-equipped to adapt to the new engagement models Business-Technology requires.

The shift to an outcome focus is part of the acceleration of the pace of business. The winners in this environment are constantly inventing new doctrine as they look for better ways to achieve the same outcome. How we conduct business is changing so rapidly that we can’t expect to be doing the same thing in five years time, let alone for the rest of our career. What we learnt to do in our mid 20’s is no longer (entirely) relevant, and doesn’t deliver the same outcome as it used to. Isn’t the definition of insanity continuing to do something the we know doesn’t work? So why, then, do we continue to launch major transformation programmes when we know they have a low chance of success in the current business and social environment? Doctrine has become dogma.

We need to (re)define ourselves along the lines of “I solve problems”: identifying with the outcomes we deliver, at both personal and departmental levels. This allows us to consider a range of doctrines/options/alternatives and look for the best path forward. If we adopt “I am an TOGAF enterprise architect” (or SixSigma black belt, or Prince2, or …) then they will just crank the handle as the process has become more important than the goal. If we adopt “how can I effectively evolve this IT estate the with tools I have”, then we’ll be more successful.

Rolls-Royce and Craig’s List are good examples of organisations using a focus on outcomes to driver their businesses forward. Bruce Lee might even be the poster child of this problem solving mentality. He studies a wide range of fighting doctrines, and designed some of his own, in an attempt to break his habits and find a better way.

What are the benefits of a mash-up?

The original mash-ups were simple things. Solutions like the Chicago Crime and AlertMap pulled together data from two or more sources (maps and crime databases, in the case of Chicago Crime) to create one single view. Previously I would have had to access these data sources separately–find, select, remember, find, correlate, click. With the mash-up this multi-step and multi-decision workflow is reduced to a single look, select, click. Many decisions became one, and I was no longer forced to remember intermediate data.

TQM, LEAN, et al tell us that unnecessary decisions are a source of errors. If we want to deliver high quality at a low cost (i.e. efficient and effective knowledge workers) then we need to eliminate these decisions. This brings a few immediate benefits:

  • More productive knowledge workers. Our knowledge workers only spend time on the decisions that really matter, rather than on messy busy work.
  • More effective knowledge workers. Fewer decisions mean fewer chances for mistakes.
If we were to use mash-ups in this way to simplify key, call centre processes (for example) then we can can translate these two points direct into business benefits:
  • Reduced staff on-boarding costs, cutting training time, and reducing time to competency by providing a simply and more direct workflow, one which leads the call centre operator through the workflow.
  • Reduce call servicing costs, including reduced escalations and improved first call resolution by avoiding mistakes and and ensuing that the operator has all the information required to solve the customer’s problem on hand.
  • Improved staff retention, by allowing them to focus on the customer engagement, rather than soul destroying swivel chair integration.

With a typical call centre agent using six applications per call, this represents a drastic simplification of the call centre work environment.

A third benefit is the decoupling a mash-up creates between presentation and back-end applications. As all user interaction is mediated by the mash-up, there is not direct connection between the data and function provided by a single application, and the work surface the knowledge worker interacts with. This enables us to evolve the UI and back-end separately, allowing us to keep the user interface in sync with business demands while continuing to pursue a separate, and longer cycle consolidation effort to consolidate backend systems to reduce operational costs.

It’s easy to extrapolate these (potential) benefits to other solutions. My favourite is human services, where providing a case worker with the right information at the right time, and removing unnecessary distractions, will result in a material difference in the quality of life for the people under their care. However, these benefits can easily be applied to any high value knowledge work processes, such as logistics exception manager, utility field worker, sales personnel, and so on.

Posted via email from PEG @ Posterous

Innovation cultures

We take our inspiration from proven innovators, such as Pixar and 3M, trying to copy what has made them famous. But it can be hard to instil an innovation culture into an organisation—something like getting a leopard to change its spots. Better to understand the culture you have, and then tweak it in ways which will make it more innovative, than to tilt at the windmill of wholesale transformation.

What drives a organisational culture to innovation seems to be a reoccurring theme over lunchtime beers. Just as different people had different characters, so do companies, and even countries.

There’s an interesting documentary, Mondovino, put together by an Italian bloke, looking at the globalisation of the wine industry. As he travels around the world visiting different wine regions we get a peek into how each country is driven to create wine.

  • France focuses on the region and magic of the wine maker.
  • US is concerned with the market, and the challenge of making a blend that will resonate with consumers, while
  • Australia takes an unromantic but pragmatic view of wine making, focused on making the most of what we have.

At a very glib level you could say:

  • The US tends toward market (marketing) driven, trying to understand what will sell.
  • France is idea driven (academic even), interested in the ideas behind the solution.
  • Australia is pragmatic (outcome driven), wanting to create a workable solution today.

All approaches have their own strengths and weaknesses, and innovate in different ways, working with their environment to innovate, rather than against it.

All too often our best efforts to create an innovation culture—stealing ideas form the likes of Pixar or 3M—seems to stall. Or, even worse, come under attack from our own people. Just as the wine industry in different countries have different cultures, so do our companies. Taking a market driven approach to creating win in France will have limited success. Trying to impose a new innovation culture that is incompatible with your existing culture will see similar frustrations.

The challenge is to understand what drives your existing culture, and then innovate in ways that work with its natural inclinations, rather than against them.

Posted via email from PEG @ Posterous

Innovation [2009-11-16]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

  • Warren Buffett’s bet against innovation [BusinessWeek: Innovate]
    In proclaiming an “all-in wager on the economic future of the United States, Warren Buffett just paid $44 billion for a 19th century technology platform, a railroad, that carries 20th century goods—coal, agriculture, imports from Asia, petroleum. This is a vision of an America mired in the past and in economic and political decline. And Buffett just might be right. He has a great track record betting against innovation.
  • Embracing Innovation: a new methodology for feature film production in Australia [Centre for Screen Business]
    Do too many Australian films fall into a budgetary ‘no-man’s land’ – not big enough to compete with the US studios, yet too big to stand a chance of commercial viability in a market flooded with independent films? Robert Connolly’s recommendations provide us with valuable grist for the mill as we, in the IT industry, work our way through the current evolutionary phase our industry is going through, driven by the shift from large, on premises applications to a future increasingly dominated by cloud solutions. His approach to the problem is also an excellent model of how to engage with the wholesale transformation of an industry.
  • 10 examples of minimum viable products [Venture Hacks]
    Brilliant products are rarely the result of brilliant ideas. Most products start small, as minimum viable products, and then grow as the customers and developers work together to learn what the product should be.
  • What do the crowds know about innovation? [Innovate on Purpose]
    Companies use different strategies and techniques for crowdsourcing ideas. All of these approaches help gather ideas from the crowd, but they also serve as trend spotting and public relations opportunities as well, and some companies might be more interested in these secondary effects. As Henry Ford pointed out, “If I had asked my customers what they wanted, they would have said a faster horse.”

You keep using that word. I do not think it means what you think it means.

Inigo Montoya
Inigo Montoya

[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up.]
Vizzini: HE DIDN’T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what you think it means.

The Princess Bride

We keep using these words, but they don’t seem to have any meaning anymore.

Agile. It started with agile software, and seems to have spread like a virus to (agile) testing, (agile) architecture etc. At some stage we confused two ideas: agile delivery and agile outcome. One does not imply the other; while your process might be agile, being able to redeploy the team quickly does not guarantee an agile result for the business. You can make your architecture/development/testing team as agile as you like, but if the solution they are working on is a giant furball, then business agility will elude you. And by getting this wrong in the eyes of the business, we’ve made the term next to meaningless.

Architect(ure). Back when I was a lad, every geek wanted to be a grow up to be a systems analyst. None of us really knew what a system analyst did, but the title sounded good, they seemed to be senior and the pay was ok. Some time in the last few years, architect (and architecture) have replaced system analyst in the minds of aspiring software engineers. The minute we reach something like team lead we start calling ourselves “architect”. This puts software engineering in the strange position of having a surplus of architects, but very little real architecture.

Chief Technology Officer. Full disclosure, I carry the CTO title. I prefer to use the acronym rather than spell it out–to avoid confusion. With technology playing an increasingly important role in business, using technology well (or not) can have a disproportionate impact on a company’s performance. The idea behind a CTO is a good one: someone to advise how to leverage technology at a senior level. Though most CTO roles seem to be something else: head of development (nee VP Engineering) product management (Dir. Product Management), or just “big solution architect”. Using one title in so many different ways means that the title has little meaning to the business. I prefer to use the acronym, focus on helping the business solve problems, and let them make up their own mind on what it means.

Innovation. We have big innovations, and small. Industry defining disruptive innovations, and incremental innovation. There’s whole ontologies of innovation. We’re told to innovate our way out of recessions, and to innovate to remain competitive in bull markets. There’s a surplus of innovation activities, yet very little seems to happen. All this thunder without rain makes me yearn for more obliquity. Innovation should imply doing something useful, making a difference, rather than being reduced to a label for an ever growing consulting industry and a lot of talk.

Mash-up. From that first push-pins on a map solution, fusing data from a range of sources (GIS, reviews, yellow pages …), the mash-up concept seems to be growing to include an UI concept that we want to generate buzz around. iGoogle and NetVibes as mash-ups? Aren’t these just a SaaS version of the portals of old?

Synergy. Many things in the business world are done to release “synergies”. Mergers and acquisitions are driven by the quest for synergies. PowerPoint business plans are often considered incomplete unless they line up A and B, proudly announcing that synergies will make it all worthwhile. Why then, do promised synergies so rarely eventuate? We seem to use the term as a vague aspirational statement, rather than a call to action.

More terms as I find time. Send in your own and I’ll add them to the list.

Update: The Economist points out where synergy went wrong.

Update: Added “mash-up” after commenting on Enterprise Mash-Ups in Transition.

Update: You can find my attempt at a clearer and more consistent definition of mash-up over at We need a better definition for “mash-up”.

Posted via email from PEG

Distance is meaningless

Sarah Lacey has publish a interesting article over at TechCrunch: Think the Term “Supply Chain” Is Unsexy? Meet the Kinky King of Beijing. The bit I like is somewhere toward the middle of the article.

Like a lot of entrepreneurs in China, Sloan is cagey about what I can and can’t say about how the operation works. That’s not because it’s illicit—it’s because it’s so incredibly lean, flexible and outsourced that he doesn’t benefit if competitors realize exactly what he’s pulled off business-wise. But suffice to say with a small army of employees peppered around the globe, Sloan—aka the “Kinky King of Beijing”—is looking at an incredibly profitable business that’s already generating more than $1 million in revenue and growing quickly. He’s exploited what each region does best: Romanians are his programmers and SEO, Indians and Brazilians do his Web design, and China does the manufacturing and fulfillment. He hired his whole staff without leaving his living room. His next act? Finding new products and following the same playbook.

As I’ve said before, we need to get over this notion that off-shore means the third & second world manufacturing products designed in the West, and for the West. People are using technology to completely reinvent our understanding of what makes a company. It seems that The World is Flat only scratched the tip of the iceberg.

Posted via web from Business-Technology