Sunday, 19 December 2010

The Notion (Ink) of Agreements

The content of this post was inspired by reading Rohan Shravan of Notion Ink's blog post entitled "What we have learnt in the past 2 days?". Specifically, the reference to agreements and the length thereof. The original was sent as an email to Rohan, who had been somewhat battered by a rocky launch process of what promises to be the most innovative product for years, as a gesture of support. Ironically his response suggested my assumption regarding lawyerly influences was a little off the mark regarding his reference to length, but the advice stands anyway! And in the context of one of this blog's common themes, it is sound advice for CIOs too. So...

Don't have agreements whose value is measured by length; agreements (contracts) should be as long or as short as is necessary, and if on the long side should have a summary section on the front page that sets out the objectives and intentions of the agreement to serve as a reminder as to why the agreement exists, while the lengthy part is there for accuracy, for detail and for the lawyers.


Don't fall into the trap of thinking business relationships are or should be governed by agreements/contracts, or specifically not the written parts; the written parts are just there for if the relationship goes wrong. Relationships are between people, whether it is groups of people or between individuals. This is true whether the relationship is with a customer, a supplier, a partner or a possible contributor or employee. It is the relationship that is the powerful part in terms of getting things done and sorting problems out. The value of the informal part of the relationship can be made to seem insignificant if overshadowed by other things, such as relative size of the two parties in the relationship (think Rs 300,000 crore[1] Tata and a buyer of a Rs 1 lakh[1] Nano), but while an asymmetrical agreement means the larger party might not always value the relationship with the individual customer, in the end it remains more important than the written agreement, and never more so than in the era of the Internet.

The relationship with the individual is more important for an innovative startup like Notion Ink that needs goodwill to generate its marketing profile and drive sales, whose business model is dependent on the members of the Notion Ink customer family telling others about how great the product is and how great the experience is buying from Notion Ink; a positive relationship will result in further success, a negative one will, at best, not. At worst a negative relationship with a customer could be destructive. The relationship with suppliers is also an particularly important one for a start-up, where key parts of the early adopter customer experience is dependent on those suppliers e.g. hitting shipping dates, handling payments, and ensuring the product quality.

The written legal part of a contract is important, but it is essentially about recompense if all else fails, it is the safety net. Like all safety nets you don't want to end up depending on it. It is important the written contract is correct and balanced, that it protects all parties, because sometimes things go wrong and the courts are needed. But it is the relationship that can mean the law is not required, that the issue facing one party is resolved by the other going outside of the terms of the contract; it is the relationship that makes things work.

[1] Crore and Lakh are words used in India to mean 10,000,000 and 100,000 respectively (although the numerals would be written differently in India and are commonly used as shorthand. So 300,000 crore is 3,000,000,000,000 in this case Rupees (INR), or £42bn, while the Nano is priced at Rs 100,000 or £1,425.

Saturday, 4 December 2010

What we can learn from monkeys (part 1)

There are, I'm sure, many things we can learn from monkeys and in many senses. I'm not going to go anywhere near things like dietary content, the benefits of an outdoor lifestyle and biochemical realities; I'm more interested in what we can learn in terms of behaviour, individual and group and the degree to which they are interdependent, and what monkeys can teach us about real world and maths. In other words, what information leaders can learn, CIOs, IS Directors and the like, about organisations. So welcome to part one: monkeys, policies and traditions...

A friend of mine from university dropped by yesterday and we got to talking about common practices vs best practices, and how faced with many choices and a degree of uncertainty (e.g. choosing from competing and rapidly developing technologies and approaches) people tend to stick as close as possible to the way it is now, or choose a new way based on the "what most other people done" method, rather than comparing options in a rational manner and in light of long term as well as immediate consequences. This approach of choosing what you have or do, or what lots of other people have or do regardless of whether it is the best or right thing to do or choose, is so common around technology. This topic of conversation gave me the chance to air one of my favourite sayings:

"A long habit of not thinking a thing wrong gives it the superficial appearance of being right" Thomas Paine.

My friend countered by reminding me of the parallel between monkeys and many organisational policies, practices and behaviours; programmed as opposed to reasoned behaviour, all about the "thou shalt not" and more or less nothing on the "why". The parable of the cage full of monkeys and the forbidden bananas...

Take a large cage full of monkeys. Lower into the cage a large and particularly attractive bunch of bananas. The instant any monkey touches a banana let loose thunder and lightning, fire hoses of ice cold water over all the monkeys in the cage, etc.. Pretty soon, the monkeys in the cage will stop trying to reach the bunch of bananas and content themselves with other sources of nutrition provided. Now substitute a new monkey into the cage. If this monkey tries to reach for the bunch of bananas the other monkeys, not wanting all the bangs, flashes and cold water, will forcibly prevent the new monkey from reaching the bananas until the new monkey learns not to try. Then substitute another new monkey into the cage and the same thing will happen, with even the predecessor new monkey helping to prevent banana grabbing. Then substitute another. And another.

Eventually you will have substituted all of the monkeys in the cage. None of them will try to get the bananas and any new monkeys will be violently prevented from getting the bananas. And none of them will know why... Remind you of anything?

Tuesday, 16 November 2010

IS and other content coming soon...

I'm in the middle of bringing together some other blogs, reposting and reworking some of that older content, interspersed with new posts. This new single blog will mostly be about management, technology and information systems, although will inevitably, in the spirit of The Seven Day Weekend, allow some other stuff to filter through. I'd guess, for example, that motorcycles, music and miscellanea will be other tags in common use...

Wednesday, 3 November 2010

Talk Talk Text Text...

So, a few weeks ago my aunt reports to me her email is not working. As this was something I originally set up for her a few months ago I promptly arranged to drive down to London and have a look.

A quick diagnosis followed; not so much not email as not Internet. The TalkTalk branded ADSL router was not syncing up to the TalkTalk service. I delved deep into my technical archives and checked everything I could, tested the router on different phone sockets and with different microfilters. Nothing.

So I call TalkTalk for her. I quickly get bounced to 2nd line support when the answer to the question "what version of Windows do you have" got the response "Linux". The 2nd line guy was good, in that he got I was technical enough to know it was the router, promptly ran some line tests and said he would escalate it. Escalation would take 3 days to get something and up to 5. I gave them my mobile number to call if they needed any more information.


So, next day I get a text "Our engineers have tested your line and have been unable to find a fault. If a fault still persists please reply with the words NOT FIXED". I ignore it, presuming it is a mistake as the guy on the phone had said his tests found a fault.

Two more days pass. I call my aunt just to check if anyone has been in contact with her or if the Internet is now working again. Nothing. She assures me she will email the instant she gets her email back. So I call TalkTalk, to be told that the fix response time is up to 6 days...

So, next day I get a text "Our engineers have tested your line and have been unable to find a fault. If a fault still persists please reply with the words NOT FIXED". I duly respond with "NOT FIXED".

Some more time passes. Eventually, some 11 days after the report I get a happy email "Two TalkTalk men came and fixed it". Excellent. That's good. Slow, sillily slow, but good.

Two days ago, another 11 days after the problem was resolved, I get a text "Our Engineer reports that your fault is fully resolved. Please reply using the words RESOLVED or ONGOING, Thank you". Ignoring the extended delay and unnecessary capitalisations in the message, I dutifully respond "RESOLVED".

Then this morning, another text message "Following further investigation on your fault. Please reply FIXED or NOT FIXED". Mildly confused, but still willing, I respond "FIXED".

To which came the prompt response "We did not recognise the response you sent back. Please refer to our previous text for the correct response to send. Thank you". Well, the only response left to me is "NOT FIXED"...