A time management observation

Have you ever noticed how critical decision meetings have a tendency to be scheduled at the end of the day? I have noticed this as a trend recently in several of the streams that I am working on.

My first thought was that this was due to the need to work through the day to get the information together in preparation for that meeting. Anecdotally (meaning stuff I have seen, done or messed up myself but may not be statistically significant to the world at large) this seems to be the case in 20-40% of the high criticality meetings that get scheduled. This leaves a gap of 60-80% that could happen at other times in the day.

At the end of the day you are tired. At least (anecdotally) I am since the day has been spent making decisions, digging into problems and hopefully doing real work. So my next thought was why do we push these important meetings to late in the day if we are actually going to be less well equipped to handle them?

The answer (or at least my version of it) came to me as I thought about the tasks list and task list management that I do. Each day I follow the process below.

1. Review a list of tasks. I assign each one an A, B, or C. This roughly amounts to A - MUST DO, B - Good to do, C - No chance I am getting to this, I could schedule it forward now but then that would take time from getting to the A and B stuff.
2. Assign a number to each task starting at 1 for each letter category. (Yes, I never even bother with C)

Now when I do this I can say A1 is more important and I should work on it first. Great! Only my human nature kicks in (chances are if you are reading this you have one of those as well. We tend to keep them in closets and they can get dusty but they do peak out at the worst of times) and suddenly I find myself drifting down the list to item A4 or (say it isn't so) a B1... because it's easier. My little human nature side lives for that little endorphin rush of the check mark so... hmmm... off I go.

With meetings I think we do the same thing. We schedule some simple meetings up front. Easy discussions, standing team meetings etc etc. Then we postpone some of those really important, hard meetings and conversations to later in the day.

So I am going to try to move my important meetings earlier. When I find myself setting up one of these meetings I will catch myself and ask the question "would this be better in the AM? Or now?"

Am I nuts? Is this just how business is supposed to work? Have you seen this? In a global economy with companies getting more global in audience as well as employee base these types of behaviors become not only self-pain inflicting but they don't even make sense given global time zones and the fact that the sunlight moves.

Ignorance more frequently begets confidence than does knowledge - Darwin

Have you ever watched on tv or listened on the radio to one of the spots on Stupid Criminals? The premise is those criminals that get caught because the things they do are just plain dumb. For example, here in Texas a man convicted of robbery worked out a deal to pay $9600 in damages rather than serve a prison sentence. For payment, he provided the court a check... a forged check. He got 10 years. If you have time... do an internet search... and laugh.

A research paper pubished in 1999 is very relevant to this topic and I thought I would share. The postulation of the paper is that in cases where one is ignorant, that same ignorance keeps you from realizing your ignorance. The graphs in the paper are very telling regarding people's regard of their own abilities. Even after tests were administered people still felt they were in the quadrants that they were not.

So... why is this relevant in a technically focused blog? I bring this up because if you consider the rate at which technology moves it requires a near constant diligence and research to stay current. So far Moore's law that processor speeds will double and halve in cost every 24 months has tracked fairly close. Software architectures seem to have an average lifespan of 2-4 years. As processors get quicker more and more levels of abstraction are able to be added and new algorithms are enabled. Bill Gates has often been attributed with saying "640k aught to be enough for anybody"? (He denies having actually said that BTW) Now we have services that handle thousands of transactions per second with message payloads of well over 10x that.

The meaning in all of this is that work in technology needs to be one of constant improvement. Both in ourselves as well as our systems. We need to be constantly learning, innovating and expanding. We can't let ourselves individually or as a company become complacent and be ignorant of the fact that we are ignorant. We need to be blissful because we love what we are doing and are growing as part of something larger than ourselves... not because ignorance is bliss.

Assume that your skills need to be refreshed every two years... and act accordingly.

Are you an Egghead?

Having something of a sick interest in the meaning of words, origin of words and their use had me wondering this morning where the word Egghead came from and what the history of it's use would be.

Turning to the Internet source of all random knowledge: Wikipedia, I asked. Egghead has origins starting in the 1950s and is a slang anti-intellectual epithet directed at people considered to be out of touch with reality due to their own intellectual interests. What fun.

It was even used by Richard Nixon in the 1952 presidential campaign to describe his opponent. So it also has a political connotation to it. No real originating source was quoted. The article also mentions a potential start of the description of an Egg shaped head referring to a Bald head. (something near and dear to my heart) Also no mention of Egghead software who changed to newegg some time ago though apparently now egghead.com goes off to Amazon. Not that this is completely relevant but it's my random chain of thought.

Ain't the Internet cool?

Friday Link Day

Oracle offers to buy BEA for $6.66 billion. Outside of the immediate 666 references to evil this does have several interesting implications to the software world. It has been no secret that Oracle has been trying to buy RedHat and JBoss and this puts yet another point of pressure in that series of events and the two worlds of Open Source software versus Corporate Sold software.

Airlines agree on check-in by cell phone. The headline alone on this one caught my attention. There are many implications to this possibility. I have long been jealous of the fact that non-US based cell technology is farther ahead and this is yet another item that will drive the laggard gap.

And last links but not least links, here are a few fun links that were shared with me from my JanaRSS feed. Google Smackdown, a query tool to see which phrase or words appears more across the web. Soople - an easy expert search, with a collection of tools in easy format also built on Google tech.

Yay Friday!

WARNING... FOR YOUR SAFETY...

Most home invasions come in through Windows...

Saw this come accross the wire on the Ubuntu site and laughed out loud after watching it. I thought it ranked up there with the Ruby Commercials. Of course it's a little simplistic since we all know there are vulnerabilities in Linux as well as Windows. Though the frequent target is certainly Windows due to the ABM (Anything But Microsoft) cooalition's distaste for the "evil empire".

A case for the Designated Scapegoat

Have you ever considered why it is that when we consider systems we assign it attributes such as he or she or "misbehaving" or otherwise letting us down? I have. Why you ask.... darned if I know, I have a lot of random things float through my head and some of them are actually are entertaining. Hopefully this is one of those.

It seems that we as humans have a fundamental psychological need to explain things. So in order to explain them we put attributes either internal or external to explain why things happen. Maybe it is because from the age of "really small" we ask why? (and those of us who have children know the number of times we answer that question becomes numbing.) In psychology this is referred to Attribution Theory.

External attribution is things like "the devil possessed the machine and crashed it" or the ever popular "the data center is on a burial ground of some kind and it causes the servers to crash". It may not be true, but it helps us to deal. Or certainly to laugh at our misfortune.

Internal attribution is, in essence, blaming yourself. The easy example is things like "I am a sinner, please forgive me." We see this a little less in technology though it does pop up as well with the occasional person who perpetually places blame on themselves.

This fundamental psychological need is why I am suggesting the role of Designated Scapegoat on all projects. If a designated scapegoat is assigned at the beginning of any project we can simply move on to the fixing of problems since don't have to waste time in meetings deciding who or what is at fault. All of the posturing, political planning, set up, stonewalling, denial etc can cease and we can simply move forward. All blame can preemptively be assigned to the Designated Scapegoat and productive work can begin immediately. My experience with this role suggests that your Designated Scapegoat should be someone who is generally a good natured, understanding and who everyone knows in their hearts is beyond reproach.

Imagine how instead of a two hour meeting where people discuss why it is not their problem you start the meeting off with "Gee Chris, that was a mess up, I can't believe that you crashed the servers across the globe all at the same time." Chris then responds "Yeah, you know in Project Manager school we learned that the best way to crash a system is to push the button really hard, right in the middle." Then blame and attribution discussions are done and conversation can move to actual observed behaviors and problem resolution. What a time saver!!

So as a productivity aid for your next project assign a Designated Scapegoat up front, save yourself from Attribution Theory and all those unnecessary meetings. Focus on fixing problems, root cause analysis and long term fixes. Jump right past the blame game with this easy step.

A quick snip on testing

I have recently had two different offline topics end up with the same point so I figured I would pass it on here as well. Testing and why it is important to test to failure and not just test. To stick to the intuitive reason, it is because then you know when your system will break and what will happen when it does. It is naive to believe that your system will be 100% problem free, it is a far more realistic expectation to accept that you just don't know when.

One of the fundamental race conditions of the universe is that as soon as you build a better, more idiot-proof system, the world will build a better idiot. Similarly in a system which is successful and experiencing growth, you will eventually hit a point that exposes problems that didn't show themselves under lesser pressure or lesser load. In aircraft they X-Ray and image things like propellers not because they want to ensure that it is perfect, but so that they know what quality it is. Under the right conditions a very tiny bubble can cause a propeller to literally fly apart. Better to know these things up front.

My Jana RSS feed recently (inside joke) recently came across with these two links, one for example, one for humor that are relevant to this topic. Check out this Ultimate Failure test... and fly with a little better feeling in your heart because you know that they care enough to do this. Then check out Monkey Testing at it's best. (I am trying very hard to resist the 1000 monkeys and Shakespeare sonnet reference... darn... I failed.)

In conclusion remember, it's ALWAYS better that you know where things will blow up than for someone else to tell you.

It works on my machine...

It's been a while since I have done a Friday Link Day so I wanted to throw together a quick one and pop a few of my favorites out for this week.

It works on my machine. What technologist has ever existed who has not used these words? Well now you can stamp that application with all of the recognition that a single threaded one time test deserves. By following the criteria outlined in this Blog post you can use the logo below and show the quality of your app.

Next, in the news of the truly cynical at heart, check out this article on Job Cuts for Fun and Profit. Short Circuiting Circuit City decided that 3,400 of it's workers were making just over 50 cents more an hour than their own determined average acceptable salary for a sales associate... so they are laying them off to hire cheaper people. So the next time you are looking for help and wondering why you can't find anyone who knows as much as your 7 year old you can remember how saving 50 cents an hour in employee costs got you an extra 25 cents off a computer. The article, one pulled together as part of the Knowledge at Wharton effort from U Penn Wharton School of Management, actually makes many good points on a number of topics and is worth a read if you get a chance.