jump to navigation

Team Work & The Science of Slacking July 23, 2010

Posted by mwidlake in Friday Philosophy, Management, Perceptions.
Tags: , , ,
add a comment

We all know that working in a team is more efficient than working on your own (and I did say a week or two back how I was enjoying the rare privilege of working in a team of performance guys). Many of us also know about team dynamics and creating a balanced team of ideas people, completer-finishers, implementers, strategists and so forth. Those of use who have been exposed to training courses or books on team management know all these good things about teams and how we are supposed to get the most out of them.

How many of us, though, have been introduced to the work of the French Agronomist Max Ringelmann and the aspect of teams named after him, the Ringelmann Effect? In summary the Ringelmann Effect proposses that people in teams try less hard than they do when working alone. Especially if they think no one is watching them.

Back at the start of the 20th century Ringelmann tested out his ideas using a tug-of-war experiment. He would get people to pull on a rope as hard as they could and record their efforts using a strain gauge. Then he would get them to pull on the rope as part of a team, from 2 to 8 people. As soon as people were part of a team, they pulled less hard. With two people in the team, each pulled 93% as hard as on their own, with three people this dropped down to 85% and with 4 it was just 77%. By the time there were 8 people in the team, effort was down to 50%.

This idea of shirking work more and more as the team increased in size became established in modern psychology and was given Mr Ringelmann’s name. Psychologists explain that when someone is part of a group effort then the outcome is not solely down to the individual and, as such, is not totally in their control. This acts as a demotivating factor and the person tries that little bit less hard. The larger the team, the greater the demotivation and the more significant the drop in effort. Ringelmann found that effort was down to 50% in a team of 8 so how bad can the impact of the team be? I think most of us have at least witnessed, and quite possibly been in, the position of feeling like just a cog in a massive corporate team machine. Thoroughly demotivating (though, of course, we all of us still tried as hard as we could, didn’t we?).

The effect is also know under the far more entertaining title of Social Loafing.

Monsieur Ringelmann was far kinder at the time and pointed out that these chaps pulling on the rope could well have been suffering from a lack of synergy. They had not been trained together to pull as a team so that could account for the drop in effort, they were not synchronising their effort.

However, in the 1970’s Alan Ingham in Washington University revisited Ringelmanns work and he was far sneekier. Sorry, he was a more rigorous scientist. He used stooges in his team of rope-pullers, blindfolds and putting the one poor person pulling for real at the front of the team pulling the rope. Thus he could record the effort of the individual. Ingham found that there was indeed a drop in efficiency due to the team not pulling as one. But sadly, this was not the main factor. It remained that the drop in effort was mostly down to the perceived size of the rest of the team. The bottom line was proven to be the human capacity to try less hard when part of a team and that the drop in effort was directly proportional to the size of the team.

We are of course not immune to this effect in the IT world and someone has even gone to the effort of checking that out, James Suleiman and Richard T Watson.

It seems the ways to reduce this problem are:-

  • Don’t give people boring jobs.
  • Don’t give the same job to several people and let them know they all have the same job.
  • Ask people how they are getting on and give them mini-goals along the way.
  • Atually reward them for success. Like saying “thank you” and NOT giving them yet another boring, hard job to do as they did the last one so well.

I think it is also a good argument for keeping teams small {I personally think 5 or 6 people is ideal} and split up large projects such that a single team can cope. Then give tasks to individuals or pairs of people.

If you like this sort of thing you might want to check out one of my first blog post (though it is more an angry rant than a true discussion ofthe topic) which was on the Dunning-Kruger effect, where some people are unaware of their own limitations – though I did not know it was called the Dunning-Kruger effect until others told me, which only goes to show that maybe I am not aware of my own limits… Read the comments or click through to the links from there to get a better description of some people’s inability to guage their own inabilities.

Friday Philisophy – To Manage or to Not Manage March 26, 2010

Posted by mwidlake in Friday Philosophy, Management, Uncategorized.
Tags: ,
6 comments

Recently a friend of mine Graham Oaks blogged about his decision to step back from management and return to the Technical Coal Face.

I made a similar decision 3 or 4 years back, so I have a lot of empathy for his position and his decision. I found that to do the job of a manager takes up a lot more time, effort, patience and emotional effort than I had realised. Team leading is bad enough, having to coordinate the efforts of a half dozen people and sorting out the myriad issued they throw your way. Being in charge of multiple teams, responsible for strategy, dealing with staff development and moral, being a buffer against HR and having to deal with the politics created by people who WANT to be managers and wield power is more than a full-time job. Trying to hold onto a technical element as well, I found I could only manage it by doing the technical job as a “hobby”, in my own time. It was just too much to keep going year after year.

I had to chose. Give up the technical to give me enough personal resource to remain a manager and get better at it, or stop being a manager and start re-gaining my technical skills. I chose the latter.

Since I made my decision 3 years ago, I have met several people who have made the same conscious decision to step away from management and return to a more technical role. You may stand to earn more as a manager {which is something I objected to before being a manager and I still object to having been one – it should be possible to earn the same doing either} but for some of us it is not enough to make losing the hands-on work a sacrifice worth making.

One of the points Graham makes in his blog is that his spell as a manager has given him an appreciation of the challenges of management and the particular hells and stresses of the role. I think this is something that people who have never been managers have trouble really understanding.

I was working with a guy a couple of years ago and he was telling me how much of “a Moron” his boss was. In fact, he felt his current boss was even more of a moron than his previous boss. He then confessed that all of his bosses had been morons. “What, every single one of them?” I asked. Yes, absolutely all of them. That struck me as incredibly unfortunate, that every single one of these managers (and he’d had a lot as he moved between teams and positions on a regular basis), most of whom had come up through the technical ranks, were all Morons. I pointed out this unfortunate coincidence and wondered if there might actually be a common factor with all of these managers. He told me there was; They were all Morons.

He himself had never been a manager. He said he was too smart. Not smart enough to get what I was hinting at with the common factor suggestion though.

Obviously, some managers are poor at what they do; there are poor people in every job. But something I took away from my time being a manager is a lack of empathy for anyone saying all managers are a waste of time when they have never done the job themselves.

After all, I doubt there is any job where just doing it means you are an idiot.

Except Sys Admins – They are all idiots :-) (ducks behind server).

Advert for the Management and Infrastructure SIG March 24, 2010

Posted by mwidlake in Management, Meeting notes.
Tags: , ,
4 comments

I’m a bit late doing this (life is just too busy at the moment) but I want to mention the next Management and Infrastructure Special Interest Group meeting of the UKOUG next Week. Tuesday 30th, being held in Oracle’s London City office.

I get asked by people what exactly the MI SIG is? {Honest, I do, I got asked twice this month alone!}. Is it a management meeting or is it another one of the technical SIGs, like the UNIX, RDBMS and RAC/HA SIGs? I’ve struggled to come up with a single line to sum it up. Other than to say “Both”.

It might be easier to sum up the target audience. The MI SIG is for technical people who need to deal with Oracle as a component of a large IT environment. Most of the audience could knock up a PL/SQL script to create a new set of tablespaces each month, would be able to instal Oracle {if given a couple of days and the manuals to peek at} and could explain two-phase commit. Maybe.
But what they have to deal with in their working lives are things like using Grid Control to manage 500 instances, understand what options are there for providing disaster recovery {if not the exact commands to eg set up physical standby or active/passive RAC}, knowing enough about storage options to make a sensible decision on which is best for each type of Oracle system they have. So it is a technical SIG, but covering general principles and, well, Infrastructure.

And the Management? Well, when the SIG started this bit was really interesting to me. When you have a lot of IT going on, especially in large organisations, the people looking after Oracle are not the people looking after Networks, or Storage, or Backups or half a dozen other things. And you probably have a team of people doing all that Oracle stuff with/for you. So you have to hire staff and keep ‘em happy and deal with teams who you have no power over but you need them to do stuff for you. And that Management part can be a lot harder than the technology, especially if you never planned on being a manager but just woke up one day with that monkey on your back.

So with the technical aspects of Large IT Infrastructure comes the management component too. The SIG is there for that audience.

I chair this SIG, so I am more than a little bit biased, but I think it is a good line-up of talks for this up-coming meeting. We have two talks on using OEM/Grid Control, one around using it for deploying clusters, one about how you go about integrating it with the likes of LDAP, Kerbros and using the Custom Metrics, ie plugging it into the wider infrastructure.

We also have a presentation on the latest/greatest Exadata2, from some Oracle friends.

To wrap up the technical talks I am going to try and explain some of the guiding principles for gathering statistics for you oracle databases. Not the details of DBMS_STATS command syntax, but why you need good stats, how you get them and the issues we all seem to end up facing with it.

Balancing the techical side is a talk on Birkman and understanding teams and people.

So, you can see it is a line-up matching the diversity of the SIG’s purpose.

As I said earlier, I initially was very interested in the management side of the SIG and I worried I would be pretty lonely in that opinion. For various reasons, those of us on the technical side tend not to have much time for those “soft skills” we associate with management theory. However, when I took over the SIG over a year ago, I asked the audience if they would want some talks on hiring staff, dealing with people, motivation… Over 60% of the audience said “YES!”. Quite loudly. About 30% said “OK, so long as we get technical stuff as well”. 6% said “over my dead body”.

I think the reason so many wanted the management side as well is, whether we like it or have an affinity for it or not, it is part of the job. And so we need to be able to do it. Personally, I quite like the human side of IT, but my wife tells me I am strange.

If your organisation has UKOUG membership it is free to come along to the SIG (one person per membership, excluding Bronze membership) Anyone can come along for £80. You would be very welcome and I am sure you will learn new stuff. Don’t let the fact that we retire to a pub afterwards where the chair buys a round sway your decision to come along at all.

Friday Philosophy – CABs {an expensive way to get nowhere?} March 11, 2010

Posted by mwidlake in biology, development, Friday Philosophy, Management.
Tags: , ,
3 comments

A few years ago, my wife and I went to New York for a holiday. We got a cab from the airport into Manhattan. It was an expensive way to see, at great length, some of the more uninteresting automobile transit routes through New York. We arrived at our hotel a great deal later than we anticipated. And with a lot of our paper dollars no longer in our possession.

I’ve also taken cabs through London, usually at the weekend to get back to Liverpool Street Station. The trip is generally quick, painless and not too expensive, no matter what bit of London is currently being dug up. Those black-cab drivers know their stuff.

Of course, the CABs I refer to in the title of this Friday Philosophy are not private cars for hire. In this context CAB is Change Advisory Board. A term that can make grown developers weep. If you do not know, the Change Advisory Board is a group of people who look at the changes that are planed for a computer system and decide if they are fit for release. My personal experience of them has been similar to my experience of the taxi variety, though sadly more of the New York than London experience.

You might expect me to now sink into a diatribe {ie extended rant} about how I hate CABs. Well, I don’t. CABs can be a part of a valuable and highly worthwhile process control mechanism. Just as proper QA is core to any mature software development process, so CABs are important in getting informed, talented stakeholders to review proposed changes. They check for overall system impact, clashes with other proposed changes that individual development streams may be unaware of, use their own {hopefully deep and wide} experience to consider the changes and to verify Due Diligence has been invoked {that last one is a bit of a minefield and where, I believe, many CABs fail}.

Sadly, though this is often the aim, the end result is too often a bunch of uninformed and technically naive politicos trying to wield power, using the CAB meeting as an extended game of management chess.

I’ve seen CABs trade changes. “I’ll let you have X if I can have Y and Z”. I’ve seen CABs turn down changes because the form had spelling mistakes in it. I’ve seen CABs object to a change that will save the company 5 million pounds a day because it lacked one signature.

That last one just stopped me in my tracks {I’m not exaggerating either, if anything I am underplaying the cost impact of that decision. I saw the figures and I wasted a couple of days of my life checking, 5 million pounds a day was the least I felt I could prove.} We are talking about enough money every day to pay the salary of everyone on the CAB for several years. And they blocked it because the DBA team had not signed off the change. No effort was made to address the lack of the signature in any way, the change was just refused.

The DBA Team had not signed off the change because the one and only DBA Team Leader who was allowed to sign off was on holiday for two weeks. They needed that holiday too, for other but I suspect linked reasons.

Now, I knew the DBA Team Lead and he was a good bloke, he knew his stuff and he was not paid 5 million pounds a day. His deputy was paid even less but was no less talented but she was not allowed to sign off the change as she was not the DBA Team Lead.

That was a CAB gone very wrong. The process of the CAB had been allowed to over-rule good business sense. It was also overruling general and technical sense, but that really is secondary to what keeps the business making a profit.

I’ve seen the opposite of course, technical teams that just apply whatever changes they feel are fit, with no oversight or CAB. To be honest, this less controlled process seem to mess up less often than a poor CAB process as the technicians know they are the ones who will spend the weekend fixing a mess if one occurs. But that mess up will occur eventually, if control is lacking, and the bigger and more complex the IT environment, the greater the chance of the mess up.

So, I feel CABs are good, no make that Great, if you have the right people on them and you have a sensible cascade of authority so one person being away does not block the system. That is quite a bit harder to put in place than a simple “Dave A, John, Andrea, Alex, Raj, Dave P, Mal, Malcolm and Sarah have final signoff” which most CABs effecively become.

But there is one last fault of CABs I want to highlight. They tend to treat all changes in the same way and all changes are not the same. Upgrading the underlying OS is not the same as adding a cardinality hint to one Business Objects report.

If your CAB or change process treat the two above examples the same, then your CAB or change process is broken. Now, in all IT “rules of thumb” there is an exception. In this case, I am truly struggling to think of one. My feeling is that if your change process treats an OS upgrade the same as adding a hint to a report, it is not fit for purpose.

Those are my main issue with CABs. They should be of significant business importance, but nearly always they are implemented with one process to deal with all situations and then get taken over by people with an “Office Politics” agenda as opposed to a “Getting the best job we can reasonably expect done” agenda.

I’m very passionate about this and I have a way I hope can throw this issue into context, an analogy.

Ask yourself this senario.
You go to your doctor with a niggly cough you have had for a week OR you go to your doctor because you almost passed out each day you got out of bed for the last three days.
If your doctor treated you the same for both sets of symptoms, would you be happy with that doctor?

Why are all IT changes handled by most CABs in exactly the same way?

(BTW if you ever almost collapse when you get out of the bed in the morning, do NOT go to work, go instead to your doctor and ask them for a full medical and if he/she does not take blood pressure readings and order a full blood chemisty test, go find a new doctor.)

Friday Philosophy – What Was My Job Again? December 11, 2009

Posted by mwidlake in Management.
Tags: , ,
2 comments

How much control do we have over what job we are in?

I know I have mentioned this before, but I did not choose to work with Oracle – I fell into it by accident. I found myself in a job which I was no longer enjoying, for a boss who had issues with me and I had issues with a salary (mine, of course). So I decided to apply for a job with a company a friend of mine worked for:

For those of you who are not UK-born or have seen less than three decades go by, in 1990 “Oracle” was a teletext company that provided information on your TV screen for the TV company Channel 4. Basic news, entertainment, sports etc via chunky text and chunkier graphics thrown up in glorious low-res.

I honestly thought I was going for an interview with that company, as opposed to the other “Oracle”, some database company with the same name which went on to pretty much conquer the corporate database and applications world. That was a pretty lucky break for me and I made a conscious decision to stick with this database stuff.

Many years later I was on a contract doing database performance tuning. Someone, a manager, came and asked me about how they could save space, not in the database world but in the Unix filesystem world. So I made the suggestion that they check out the man page on compress. We compressed some big files and he went away happy, leaving me to get on with my database stuff. My big mistake was, when he came back a week later and asked how he could get the compressed data out, I promptly showed him. I revealed too much knowledge.

I came in to work the next Monday morning and my desk had gone. There was an oblong square of dust and hula-hoop crumbs, nothing else. Even my pile of “documents to get back to” from under the desk was gone. Had I been sacked? No, I had been put in the Unix system administration team. My desk had been picked up and physically moved across the room to the Unix Corral, along with everthing on, under or next to it.

No one has asked me, it had not been mentioned to me at all, the managers had just realised on Friday that half the existing team (contractors) had left at the end of the week and no replacements had been found. That devious manager I had helped had told the others I was a whizz at Unix and so my fate was sealed. I was not a whizz at Unix, I was barely competent at basic shell programming. But I learnt a bit before deciding I wanted to stick at the Database stuff and went off to a contract doing that again. I still kind of wish I’d done the Unix a little longer though.

The final shift I’ll mention, and is probably more commonly echoed in other people’s experience, is coming in one day to find you are a manager. This had happened to me small-scale a couple of times, taking on a contract where I ended up in charge of a team, but in this particular case I was a permanent employee managing a team of 4 DBAs and my boss left. Within the week I found that I was being treated as the manager of 5 or 6 teams, totalling about 30 people. More by them than by upper management, but upper management cottoned on and asked me to do the job. Long story cut short, I resisted the move upwards but it happened anyway. Not, at that time, what I wanted at all.

I’ve told the above story a few times when doing presentations on management-related topics and many people, a surprising number to me,  have said to me afterwards that the same sort of thing happened to them. I am also now chair of the Management and Infrastructure Special Interest Group of the UK Oracle user group. That SIG is full of people with a similar story.

What is the point of this particular Friday Philosophy? Well, these experiences have made me realise that a lot of people are probably doing jobs they just found themselves in, or in the case of managers, just got pushed into.

If you did not chose your job, you are unlikely to be a good fit, especially to start with.

I’m sure most of us have experienced this and, looking back, can see that initially we lacked the skills, the background, even the inclination for the role. But we either got on, moved on, or become morose and bitter.

This also means that we are all probably encountering a lot of people in that exact situation, all the time – People doing a job they just found themselves in. So, if someone seems to not be doing a job as well as they could, check how long they have been doing it. If it is a recent change, remember your own experience and cut them some slack. You would have appreciated it when you were them.

It also explains Morose and Bitter Geoff who manages Accounts too, doesn’t it?

Friday Philosophy – Disasters September 4, 2009

Posted by mwidlake in Perceptions.
Tags: , ,
3 comments

Some of you may be aware that I occasionally do presentations called something like:-

“5 Ways to Progress your Career Through Systems Disasters”

The intention of the presentations are to comment on things I have “been in the vicinity of” going wrong in I.T. and ways to avoid them, in a light-hearted manner. Having a bit of a laugh whilst trying to make some serious points about project management, infrastructure, teams, people and the powers of chaos.

I’ll see about putting one up on my Web Site so that you can take a look {check back this weekend if you like}

The talks usually go down well but there are two potential issues in giving the talks:

  • The disasters or problems, if in some way my fault, could make me look like an idiot or incompetent.
  • If it is known who I was working for when I “witnessed a disaster”, it could make that company look bad.

I never used to worry too much about this when I worked permanently for a company that was pretty relaxed about “stuff happens, it is good to share”. After all, if I looked like an idiot then that is fair enough and if I said anything that could be linked back to a prior (or current) employer {which, I hasten to point out, I did aim to avoid} then, well, sorry. But I only said things that were true.

However, when I returned to being self-employed, a good friend of mine took me to one side and suggested such talks could harm my career. I argued that it was not malicious and was helpful to people. My friend argued back that potential employing companies would not look so favourably on this, especially if they suspected that they may one day feature.

Hmmmm…. This was true.

So I toned down the talk…

The next time I did the presentation, the sanitised one, it was not such a hit. In fact, it was a bit rubbish.

The question is, should I have toned it down? Hands up anyone who has not personally done something unbelievably stupid at least once in their working life? Can everyone who has worked for an organisation that has not messed up at least one I.T. project please also raise their hand?

I can’t see any raised hands from here :-)

We all make mistakes.
All companies get things wrong at times.

Something you find when you start presenting or organising events is that the talks people most appreciate and learn the most from are about things going wrong.

So why can’t we all be grown-ups about admitting them, talking about them and learning? Personally, when I have interviewed people for jobs, I am always impressed by someone who will admit to the odd failure, especially if they can show what they learnt from it.

Oh, if anyone is reading this before offering me a position, I never made a mistake in my life, honest. I never deleted every patient record from a hospital information system, I was not even on-site when the incident didn’t happen. And if anyone suggest otherwise, it was a long time ago when it didn’t happen. ..

{I got all the data back, anyway. Never start work without a backup…}

Friday Philosophy – Simply Complex July 24, 2009

Posted by mwidlake in development, Management.
Tags: , ,
3 comments

Piet de Visser is an ardent champion of simple solutions within the Oracle arena – and I completely agree with his outlook on this. {Almost}.

Simple solutions usually win long-term as they are easy to understand, easy to look after and easy to change. OK, you may not be getting the absolute best performance you can, you may not be doing the job as completely as you can, but if it is a simple solution then you probably implemented it easily and quickly. This probably also means it cost you not-a-lot in person time and brain power, so you can personally afford to blow it away and do it again. In fact, with all that saved time, money and brain power you can probably afford to create a couple more simple solutions to other problems to.

Perhaps the only thing you are probably losing out on is the kudos of having been smart enough to come up with something very cunning and complicated, to impress everyone with. You’ll get over it, people don’t stay impressed for very long, especially when your mind-bendingly cunning and complicated solution melts into a heap {as a couple of mine have, ho-hum}.

Is your chosen solution simple? I give you a simple test – Explain it to someone.

  • If you can explain it to your colleagues, it is probably quite simple. If you can’t, either the solution is not so simple or your colleagues are.
  • If you can explain it to your boss then it is probably an excellent example of simplicity.
  • If you can explain it to your mum, you have blindingly clever simplicity and your work here is done.

Oh, you remembered that I said I almost agreed with Piet.

I can think of four reasons for not implementing a simple solution. I have listed them in ascending order of being a good reason (best last). And, unfortunately, also descending order of likelihood (most likely last).

  • You were sold a complex solution as complex solutions earn the vendor more money.
  • You needed to impress someone with your incredible technical skills {this could be your peers, quite often it is your boss, but for most of us it is usually ourselves, let’s be honest :-) }
  • You really do need to do something complex for a very valid business reason, like 99.999% availability {eg for that system people can ring up as they have a cough but are convinced they are dying of “swine flu”}.
  • you are creating a generic solution.

What do I mean by the last point? I mean that your one solution has to work for a lot of different situations or usages. The system has to work for a large range of inputs or do a lot of things.

The whole Oracle database  is {in my opinion} a generic solution. A vast and complex one to be sure, but it is intended to work for a little database on a desktop keeping track of the parts in your workshop, an integrated system in eg medical or scientific robots keeping track of thousands of samples, vast data stores of telephone calls so you can do your bills, huge on-line web-based shopping systems, a front end to image or video stores.., the list is a big one. You might need a little Oracle database to hold the list in.

With version 10 Oracle Corp made a big thing about the database looking after itself .  The database was a generic, self-managing, handle-anything solution and you would not need those pesky DBA types to keep the beast working for much longer.

That is why it is so complex and, not matter how much some of us complain {as I myself often do}, it has to be and it is getting more complex with every version. I’ll take my current favorite topic, stats gathering, as an example.

Back with the rule based optimiser, you had a set of rules. 15-16 I think {I’ll let you lot check – google “rule based optimizer oracle -burleson”}. You learnt the rules, understood them and you were home and dry. Except that the RBO could not cope with data-specific oddities, how different access methods were better for different table sizes and index specificity.

So Oracle added statistics and the cost based optimiser. To make use of the cost based logic a load of mathematical calculations and considerations had to be added (and continues to be added), based on statistics you had to collect at the right time and the right level and many sites did not. People complained the CBO “just did not work”, which it did not if you didn’t collect the stats {and sometimes even when you had} but it was doing a lot to cope with a wider range of systems automatically. Histogram stats now allowed skewed data to be coped with, in most situations. 

So they introduced a job to do it for you but it had to detect the right level and type of statistics to gather on all objects, be they tiny tables, massive tables, tables with skewed data, indexes, global indexes on partitioned tables… And yes, once again, it is another complexity you have to get to grips with if it does not fit your particular system demands.

I’m sure you can argue with me over the details, but I think I’m making a valid point that every time a system {be it Oracle or an O/S} is modified to cope automatically with more senarios, it becomes a more complex system. You need a DBA with several manuals welded to their brains to get the best out of this thing now, not less as claimed back at 10’s release {did they make the same claims for 11? I was too busy keeping systems running to really notice at the time}.

Maybe the answer is to stop using generic systems like Oracle and swap them out for a mixture of spreadsheets, MySQL-type simplistic databases, netezza-type systems for datawarehouses, hand cut ‘C’ applications for handling image stores, JAVA apps and flat files for web sites…Only you are going to have to learn how to use all those things to create all the systems you need to create.

You are only going to manage this if you create those dozens of systems as simple ones.

Fuggles was very simple. The lights were on but nobody was home. But that was fine as all she wanted was to sit on you and be scratched.

Fuggles was very simple. The lights were on but nobody was home. But that was fine as all she wanted was to sit on you and be scratched.

COC – The Chain of Optimistic Communication July 1, 2009

Posted by mwidlake in Management, Perceptions.
Tags: ,
3 comments

Well, after the very long, technology-based post of yesterday, a smaller one today, on a management theme.

I came up with this concept of the Chain of Optimistic Communication about a year ago, in one of my presentations on disasters. As a potential disaster, I’ve converted the relevant PowerPoint slides into a Flash movie. This is the flash movie. The second slide is an animation of what the Chain of Optimistic Communication is, the rest is some thoughts on it’s impact and how to avoid it.

{If the flash movie fails and you can read PowerPoints, you can download the
PowerPoint here}

{And another thing, It’s my first Flash attempt, I know the page numbering is duff, I know the layout is a little off, I might fix it when I have had some more sleep}.

If you can’t be bothered with the Flash movie {go on, it’s more fun than reading stuff!}, this is what the Chain of Optimistic Communication is:

  • You, the worker at the coal face are asked by your boss how the development of the new system is going. You tell your boss that it’s not going well at all and you list 3 things that have not been done, one that has been done and one that is partially done. You don’t mention that the partially done one you plan to do tonight, fuelled by coffee and whisky.
  • Your boss tells their boss that progress is being made, half the tasks are in hand but they “need to proactively re-address a resource mismatch or two”.
  • This top level boss tells the VP of development that all is in hand, resources are in place and all bases are covered, but more budget for planning would be wise. 
  • VP of Development reports to the board that the latest Agile development using cross-skilled resource pools is on track to deliver the milestone implementation. Or something.

ie all levels lie, ever so slightly optimistically as they communicate up the management chain.

As a result, the higher the manager, the more rosy the picture and the more out of touch they seem to the worker at the coal face.

When I presented this idea, I got a surprisingly positive response from the audience. It was the most common thing people talked to me about after the presentation, so I guess it struck a chord. Or else it was the point in the presentation when the sound of the caterers dropping a try outside woke them up.

Another side of the Chain of Optimistic Communication is that the higher the manger, the more they are led to believe all is OK and the more often, it seems to them, that apparently “under control” projects flip to become disasters when the rosy white lies have to be ditched when the reality becomes so grim. Often with no warning. No wonder managers get so many heart attacks and strokes.

 

{This is me just trying to get the flash movie to play with my website headers, it will disappear in a couple of hours flash movie}

The Knowledge Curtain. June 8, 2009

Posted by mwidlake in development, Management, Perceptions.
Tags: , , ,
5 comments

I came across the concept of “The Knowledge Curtain” in the late 90’s, from a man called Lee Young, who I worked with for 2 or 3 years, along with a friend Mike Cox, who was key to showing me how to peek through the curtain.

The below is taken from a powerpoint presentation I sometimes give on project disasters (how to avoid, not how to encounter!):

When systems designers talk to end users, both parties usually end up not really understanding each other

When systems designers talk to end users, both parties usually end up not really understanding each other

The basic principle is that, the knowledge of your users/customers is partly hidden from you. When you ask people for whom you are designing a computer system about their job, they don’t tell you lots of stuff.

  • Things that they assume you know.
  • Things that it does not occur to them to mention.
  • Things that they do not want to admit to doing as it sounds silly or badly managed.
  • I’ve even had people not mention parts of their job as they don’t want their manager knowing they do it.

But that is OK, when you talk about information technology and computer systems to them, they have exactly the same problems with what you say :-).

Lee’s presentation, with N. Mehandjiev, predated the all-encompasing rise of the internet and this is one of the few references to it I can find. {Among the relatively few other hits on the topic, amongst the ones about knowing how to make curtains, are references to the “Knowledge Curtain” as the concept that the Web is not as available in other areas of the world. A related but very different issue}.

So, how do you peak beyond the knowledge curtain? Systems designers and developers with experience learn how to ask the questions “what are the exceptions to what  you have just told me” and “what else do you do” in many, many ways and without giving offence. After all, you have to keep asking these two questions and people naturally get irritated with that and some feel you are suggesting they are either stupid or lying. It can be tricky. 

I think that unless you have someone who is fully IT literate and has done the job the computer system is to assist with, you will inevitably only catch a part of the requirements.

For massive projects over many months or years, I think this lack of a clear understanding of what people do is a major factor to their failures. This is made even worse when the analysis is done by one group of people and the specifications are then shipped out to an external party for the application to be developed. With all that missing knowledge, it is no wonder some systems are initially so poor.

I only know of one method that reliably allows you really see beyond the knowledge curtain. That is prototyping and user feedback. Only when you show the people who are going to use the system what you have put together to help them will they know if it works. These sessions are incredibly valuable and only in development projects where they have been key to process have I seen the project deliver something truely useful.

I now have a general way of developing anything.

  • I ask the users for 3 or 4 major things that they want the system to do.
  • I develop those 3 or 4 features as quickly as possible and show them to the users.
    • One will be almost exactly what they need.
    • One or two will be close to what they need.
    • One will be utterly useless.
    • During the above, one or two critical new needs will come up.
  • Fix the close ones, dump or redo the useless one and add the new needs to the list.

Simply cycle around the above, asking for new features when you have got less than 4 features you  are actively working on. And only polish features (add all the nice screen touches and widgets) once is is exactly what they need or pretty damned close. {You hardly ever run out of features before you run out of time and money!} You end up with an excellent system that evolves to better help the customer as time goes on.

There are lots of development methodologies that have the above principle (or a variation of it) as their core, so I am certainly not the first person to find that this method works. Which is why I find it difficult to understand why so many projects don’t use it?

BTW, I thought I would just add that one of the factors in my starting a blog was a comment by Andrew Clarke on his, several years ago before Blogging really took off. It was for a presentation I did which included the Knoweldge Curtain concept. He was very nice about my presentation and I still appreciate it. This is the link, but as it is an archive you will have to search for my name.

June Management & Infrastructure meeting June 5, 2009

Posted by mwidlake in Meeting notes, Perceptions.
Tags: , ,
add a comment

Wednesday this week saw the first UKOUG Management & Infrastructure meeting special interest group meeting (MI SIG) of the year – postponed from April due to a clash with the G20 summit. You can see details of the meeting here where {if you are a member of the UKOUG} you can download some of the papers.

I feel the MI SIG has been struggling a little over the last few meetings – too many sales pitch presentations and numbers hit by travel woes (we just fell unlucky) and then the recession – but this meeting felt better. We had a good mix of strong presentations and numbers were up. The number of expected delegates has been very variable over the last 2 weeks, at one point we were full (50 people) but then some dropped out, others registered late. We ended up with 39.

At the last meeting I asked if people wanted more on the management side and the majority did, so I pitched a presentation about how to be a Manger in IT. It would have been relevant to management in other disciplines but IT does have some unusal aspects, one being that there is a much higher percentage of introvert and logical personality traits amongst IT people. Soft Skills and considerations of personality do tend to get short change in technology environments too.

Not only did I pitch a touchy-feely topic but I also went powerpoint-naked. I put up a half dozen intro slides and then turned off the projector and just talked. I was more than a tad anxious that this could have fallen flat and ended up as me spewing random drivel from the front, but the audience took up the topic and started chipping in. It snowballed and became a general discussion. I managed to keep it flowing and mentioned most of the things I wanted to include and also took a lot of input from the audience. Maybe one or two of the links I made to add my intended points were a bit tenuous but heck, it was the first time I’d done a free-form presentation like that for years and years.

Not only was the session a success {phew} but it seemed to set the pattern for the rest of day. We had had some good questions being asked of John Nangle during his opening presentation on Exadata (I’d really like to get my hands on one of those units) but after the free-form session everyone seemed to be talking to each other more and all presenters had questions and little discussions to deal with during their sessions. They all dealt with them well.

We rounded off the meeting with a drink in a local hostelry for those who were inclined and the discussions kept going. The general feeling was that it had been an excellent day with people being a lot more interactive than normal. I know other SIGs use “speed chatting” and other things to help encourage people to talk to other delegates. They have found that such things might not initially be popular {what! you want me to talk to strangers?} but always give the meetings a greater feeling of interaction and delegate feedback is that they are {sometimes reluctanatly} recognised as helpful.

I think I’ll try and have some sort of interactive or ice-breaking aspect at future meetings as it seems to really help the day be a success.

Follow

Get every new post delivered to your Inbox.

Join 158 other followers