thingamy

cycling, leadership and France

Hehe, I'm glad this is not a Cycling blog, otherwise I would tread more carefully, and to my friendly French hosts, please accept my apologies up front. But here goes:

Samuel Abt at International Herald Tribune had another excellent article the other day - "French trail in races but leads in finger-pointing".

To be honest, he's too careful in his description of L'Equipe, the leading French sports paper. Every time the French does badly in cycling, which they tend to do these days, they suggest without proof and no remorse whatsoever that the "foreigners" must be doped.

Quotes by French team leaders follows the same pattern, pointing fingers. Adding lack of training, not enough competitions locally and other "the riders are not good enough" excuses.

What I'm missing is a word or two about the team leaders.

You got teams with Belgian, Swiss, German and Danish leaders that do very well, even with riders that came from French teams - now doing better.

In a failing business the leadership takes the blame, or is blamed. In French cycling the riders and the foreigners gets the blame. Huh.

Photo by Daily Peloton

Now a small digression:

As you might have seen earlier - I question any successful co-existence between the task of managing and true leadership, and I suggest that managing is a key component of hierarchies, the command-and-control structures.

Now, I have never lived in a country where hierarchies are as strong as in France, in every level of the society. The respect that titles and grand ecoles diplomas commands baffles me all the time.

With a strong hierarchical system you'll get more managing and, if I'm half right, less leadership.

Could that have spread to French cycling teams I wonder...

Let me humbly suggest, let the French riders (who I am sure are good enough) move to teams with leaders, then see what happens :)

business model innovation (more again on what the heck is that thingamy?)

Enterprise software promises good ROIs. Good, good. But ask yourself, what is easy to measure?

Efficiency. 15% less time spent, 7% less electricity used, six percentage points better use of capacity - all easy to translate to the bottom line. Easy is the word.

Difficult is the word when you want to measure business model innovation. Perhaps even not doable.

Amazon was never a brick and mortar bookstore, eBay was never a village mart, Dell never sold through resellers - so what change of "what" could you measure here? Anybody venture a method to calculate the ROI on those business model innovations?

And, for the established firm, does that mean that Business Model Innovation requires a complete restart? Totally new business, unrecognisable even? Not an inviting thought indeed...

A quick revisit to what a Business Model is: "How do you use your resources to deliver value and keep some of that for yourself".

Ford did some Business Model Innovation in 1913, changed the way he used his resources and went from 70 hours per car in the spring to 7 hours per car in the fall. A factor of ten, that is what Business Model Innovation could attain, no mere 7 or 12 percent efficiency gain.

That is what the thingamy is about - business model building - create, run, play and recreate. Thus a tool for innovation.

That's our goal - make it easy to innovate that business model, heck, even spur that innovation if you ask me. :)

no trees (even more on what the heck is that thingamy?)

Left, right, right, left, right... right? Nope, I'm lost... lemme see... left, right left, left...

Ever "lost" a file only a week after having created it? It's in Documents > Clients > UK > nah, not there, click, click... in UK > Clients > Correspondence... not... let's try Spotlight... hmm, what was that file name again?

Pretty useless those tree structures. That's why the thingamy does away with them altogether.

And the alternative? Multiple tags filtering.

Tags everywhere representing anything adding up to a real knowledge-bearing-name-space.

Choose "UK GAAP, P&L, Expenses, Production cost" and see only the accounts for that. De-highlight UK and highlight US and see the corresponding selection now for US GAAP.

Invoke a report and choose "Contacts, US, Suppliers" and see Mike, Bob and Ted, de-highlight US and highlight France and immediately get Pierre, François and Michel on your screen.

In a task to choose co-worker set task to give operator / assignee all employees - select the tags "C++, German speaking, Beer drinker" and see the list shrink.

No hierarchy, tree structures, no folders. Efficient browsing of all data when navigating, reporting, working, selecting...

Why not go all the way and do an operating system with no file structure and no applications?

Next step, a bit later, just have to refine this stuff a bit first... :)

no hierarchies (more on what the heck is that thingamy?)

Again, humbly suggesting and open for rebuffs, but here goes:

Sorry folks, but hierarchies really have only one task - to keep the processes more or less structured.

If you have an alternative way of structuring the processes and workflows you really have no need for hierarchies.

Thus the thingamy requires no hierarchy.

(Sure it can virtually represent one if you want to keep it for sentimental reasons.)

Sorry folks, positions and titles are a solely a part of the hierarchy - no hierarchy, no positions. Sorry.

(Sure the thingamy can virtually represent positions if you want to keep them for... ehh... whatever reasons. Ah yes, ladder-climbing as a motivator... as if that's the best one...)

what the heck is that thingamy?

Inspired by a kick-in-the-butt by John to further crystallise and "put words" to what the thingamy "is".

Perhaps it'll become a mini-series - leaning heavily on what "not" it is. Here's the first one.

Lemme humbly compare with middleware / SOA / BPxx - even risking mockery for being superficial and not even "getting" those others... :)

Here are the players in the game of getting some structure to the business processes,

on Blue Team we have:

Middleware: Middleware consists of software agents acting as an intermediary between different application components. It is used most often to support complex, distributed applications. The software agents involved may be one or many.
BPEL, BPMS, BPQL, BPMN, BPxx: Software tools to implement Business Process Management that encompasses either the design or capture of existing processes. Execution of a complete business process can also be achieved by using a patchwork of interfacing software with human intervention needed where applications are not able to automatically interface. In addition there is reporting.
SOA: Service-Oriented Architecture, comprise loosely coupled, highly interoperable application services.

For reasons further described below I group these to be on the same "team".

On the Red Team we have (oops, only one there):

Thingamy: An enigmatic, unproved, bugger-me-if-I-have-any-respect for the current status run-your-business software entity.

Some core differences table:

	Blue Team	Red Team
Applications:	Use existing applications, bridging the processes back and forth as the applications still have the traits of being "workstations" enabled to do many different tasks used anywhere.	Disentangles the tasks from the current applications and puts them directly into the right place in the proper sequence (workflow / process).
Development / implementation:	Top-down, waterfall, much methodology.	No methodology, follow any natural flow of events, can start anywhere limited to anything and grow from there in both directions if and when appropriate. Play instead of plan.
Data and logic:	Holds and handles manipulated data (logic applied to raw data), removes that logic and applies other logic as the flow progresses.	Holds only raw data, applies all kind of logic to same raw data sets when needed. All raw data captures metadata like when, what and who did something to it for true history.
Systems maintenance and requirements:	Use many different applications and core systems with even multiple databases / data repositories.	One single 35 MB small executable running on any server. Add browser at client.

I'll gladly update and / or correct any misunderstandings regarding Blue Team!

Any inclination as to which ones could entail more complexity, which one is more nimble, which one being closer to reality? I will not venture an view on that until the game has started :)

wildly agile business

(The great web 2.0 bear trap thingie)

Great times for start-ups indeed.

Use low cost and easy to use web apps and communication tools and all you need is a laptop and money for a cup of coffee at Starbucks... (OK, add some for a muffin or two to survive ;)

Cool. Interesting times etc.

But - one laptop and money for a muffin, start-up threshold approaching zero - that translates to a new and wildly agile business world!

And it has just started.

In a wildly agile reality - the ones already there better be extremely agile as well. They even have to be pre-emptively agile!

(And if you're just starting up, remember you'll be one of the "established" ones soon, better start preparing now :)

Focus laser-like on the product and technology and forget innovating the business model for a second - oops, who passed me with a whoosh?

[Update: Based on the notion that currently there is an equality between your product and the best-user-value - then somebody else delivers a different solution/product with a better user-value for the same issue your product addresses, then that equality evaporates.]

Use the head-start and the knowledge and relationships you have gathered to rethink, rebuild and tweak your business model - and that promptly.

But that is not as much fun to tinker with as with that neat technology, and definitely a tad more challenging, hard work, frustrating etc.

Do you really have a choice?

[Inspired by Niko and our discussion here.]

long live the apps... no, not really

Application: "A piece of software designed and written to fulfill a particular purpose of the user."
(Oxford American Dictionaries)

What now if that "particular purpose" grew out of former restrictions imposed by available technology, basically an old habit?

Will not the "application" in question, even if better than the last one, never really attain the core underlying "purpose of the user"?

Long distance communication once had only one technology available - pen and paper.

Then technology arrived - and fulfilled the purpose of the user, the good old habit - to write letters. Long distance communication long forgotten as the underlying purpose. Thus we see word processing applications coming out in new and fancy forms - last as a web based service - still requiring a revisit for all kind of tasks belonging to different processes, effectively complicating any effort to create proper flows.

The technology have given us some glimmer of hope - e-mail, chat, wikis, blogs - so why is the word processor still alive and kicking?

Ditto for accounting - modeled upon paper based ledgers - disentangling accountable events from the flow - again. The accountable event (procuring a part) on it's own, the entering of the invoice in a completely different and separate process - inefficiency come to mind, error prone and open to fraud necessitating more fun processes like the SOX. Hmpf.

And CRMs, and ERP... did I mention Calendars and it's leather-bound father?

That's why I suggest reading between the line - or ask "what for?" more often. "I need a CRM!" sounds to me like "My office is a mess, things are forgotten, process is less than good, I've heard that a CRM can fix that!"

Or, "we need a word-processor!" which in my ears sounds close to "hey, do not mess with my habits!"

But that may be my dubious mind playing me a trick...

Nevertheless, old habits are not necessarily good, why not stop a second and question this fulfilment of old habits? Cannot hurt.

Go look for the core purpose of an organisation I would suggest, humbly of course.

That's why I question the wisdom of "solving a problem" as a business leading light - the user sees a problem as a result of bad... eh, old... habits, the real core issue long forgotten.

That's why I question middleware and most takes on SOA - it only cements the use of "applications" designed by old habits and makes life more complicated.

Rethink the applications - long live the applications. That's better.

Paris-Roubaix

Spent the last few hours if front of the TV - another amazing Paris Roubaix (that's the one with all the cobblestone, usually spectacular and quite different from most other races).

(Note to those who think I'm just a couch potato on a Sunday, done my four hours of cycling already...)

The only spectacular, but not-so-fun episode was when the US hope - George Hincapie - suddenly rose from his low down position with his handlebars above his head - not the place to have them, and less than efficient steering-wise. A neat over-the-bars flip was the result, but George seemed OK, albeit a tad miffed, no more cycling for him today.

With about 20 km to go Fabian Cancellera, the young Swiss of the Danish CSC team simply powered away from amazing riders like Boonen, Flecha, Hoste and 10 more - and he just kept going.. going.. going.  Beautiful to see, a real efficient rouleur as the French would put it.
(First Swiss victory here since 1923!)

That hashed up the leader group, soon Hoste, van Petegem and Gusev tried their best a few seconds behind while Boonen, Flecha and Ballan fell behind.

That SNCF (the French railroads) found it opportune to send a freight train crossing the race at the exact moment the last three arrived was not planned for I think (hey, what about a strike on race days guys?). A few minutes rest might have done them well, but luckily had no real bearing on final results.

Now, why would I bother all you non-cyclist with this?

If you want to study an amazing leader in the true meaning - check out Fabian's teamleader, the Dane Bjarne Riis of Team CSC.

His attitude and his methods are quite different from most other I've seen - and the results have been spectacular.

You may have to find a friend with a stack of cycling magazines to read more about him and his methods - but it's worth it!
(And of course the ususal suspect like HBR and others have not found him yet... as far as I know).

epicentre or ripple software design

Niko led me to an article at 37signals about Epicenter Software Design:

"But, what’s the epicenter? It’s the events themselves. Without those you don’t have a calendar. You can have a calendar without color coding. You can have a calendar without alarms. You can have a calendar without dragging and dropping. You can have a calendar without displaying a mini calendar of the next three months. You can have a calendar without a lot of things. But you can’t have a calendar without being able to add events. That’s where you start."

I beg to differ to the specific example.

No event - calendar event, letter written, invoice added to the accounts stands alone - all are direct results of some other event.

And more, most of them will lead to more events.

For me these events are the ripples, the epicentre is far earlier.

I think that the true "epicentres" in most organisations are few and easy to see - like a potential customer calling or walking in the door.

When that happens stuff (things, objects, information) starts to flow, through event after event, nicely in a long thread (with loops and branches) all the way to a happy customer.

Those "first" events, that's where you start. Calendar events and word processing and transactions and procurement and everything else follows.

That of course is how the thingamy "thinks" :D

blogging, return and agile business

Just have to add a snippet as "everybody" (latest is Dennis and James) discuss the ROI of blogging.

Agree heartily guys, and using my own experience it boils down to... cannot do without it.

Out-of-pocket investment is par with a good lunch, one lunch, then some time goes into it.

Time that I would have to spend anyway: Wonder, dream, analyse, discuss, try, test - I only choose to do it aloud - thus I get hundreds of co-creators pitching in ideas, criticism, suggestions, even testing. Could not do without it. Thank you all!

Allow me a quote from a quote (by Tom, and I do not even know his last name!) I got in a mail the other day looking from the outside at what I'm up to here:

"...the differentiator is that he is advocating and using something similar to an agile development method both for the software and the process. Whilst this is familiar to developers, I suspect that his business background means that he has independently realised that it is possible to develop processes or systems without great big top-down processes..."

Now, that's my return! A chap I never met puts it better than I could myself - just have to love it, thanks Tom, whoever you are.

In fact, blogging is the core of "agile business".

And as a nucleus is something you cannot do without - ROI becomes moot.

Unless "stiff business" is the preferred model :)