Being efficient....

Dien -

> From talking with my brother Thomas, I've
> started to realize the incredible importance
> of efficiency. I realize this is kind of a
> vague question, but does anyone have any
> tips on improving your efficiency, in
> general?

Efficiency is great but we need to keep one other thing in mind. Being efficient and being effective are not necessarily the same thing. IOW, it doesn't matter how fast I can climb the ladder if I discover the ladder was leaning against the wrong wall! (I borrowed this concept from Stephen Covey but it's true.) Simon said pretty much the same thing in his post on the use of your mission to make yourself strong and efficient. So you not only want to do the thing right, (efficient), but you want to do the right thing, (effective).

Rick Smith, "The Net Guerrilla"

Thanks Rick,

That's a very good point!

You're right, it's no good doing something fantastically well if it's not the right thing to be doing at the time!

However... it may seem incredible to some (now, looking back, it seems incredible to me), but all this efficiency stuff really is like a revelation to me.... Especially the fact that it seems you can do so well by making a process more efficient (a la Henry Ford).

I've recently been looking around me, trying to spot inefficient processes I can improve.... It's kind of fun (and challenging) to do.... :)

Thanks Rick, that was a great point.... :)

- Dien

Hi Dien --

This is what really got me interested in computers. I can take a process, get it down, then automate it. The other fellows I work with on The Naked PC do the same and we work very efficiently and effectively in most cases.

There has been some discussion recently of NLP. One of the core themes in NLP is finding the "patterns". Sometimes it's to change the patterns other times it's to model the patterns. But in each case you must recognize the pattern first. This gets to be habitual very quickly.

What does this have to do with efficiency and effectiveness? Take a process (pattern of actions) - then start eliminating the unneccessary actions (ineffective and inefficient parts). Automate as much as possible the places where errors creep in. Be happy with the result.

Just throwing out some thoughts.

-- Dan Butler

The Naked PC newsletter

> Thanks Rick,

> That's a very good point!

> You're right, it's no good doing something
> fantastically well if it's not the right
> thing to be doing at the time!

> However... it may seem incredible to some
> (now, looking back, it seems incredible to
> me), but all this efficiency stuff really is
> like a revelation to me.... Especially the
> fact that it seems you can do so well by
> making a process more efficient (a la Henry
> Ford).

> I've recently been looking around me, trying
> to spot inefficient processes I can
> improve.... It's kind of fun (and
> challenging) to do.... :)

> Thanks Rick, that was a great point.... :)

> - Dien




Don't leave home without them!

Dan -

> What does this have to do with efficiency
> and effectiveness? Take a process (pattern
> of actions) - then start eliminating the
> unneccessary actions (ineffective and
> inefficient parts). Automate as much as
> possible the places where errors creep in.
> Be happy with the result.

I'm going introduce a little bit of thread drift here. *g* This is what started the craze of "business process re-engineering" in the late 80's and early 90's. I think this might have some foundation on Deming's work as well. Unfortunately, I think a lot of companies used this as an excuse to flatten organizations which was often used as a smokescreen to eliminate positions. While they said they were committed to the concepts, it was mostly lip service. This was certainly the case at the power company where I worked until 1994.

Beyond all that, there has since been discussion that these changes often did not bring the hoped for changes in efficiency or effectiveness. Part of the problem was the fact that *everybody* was jumping on the bandwagon. Companies didn't bother to look to see if the model would apply to their situations or not. For example; manufacturing, warehousing, distribution, industries like this usually saw the greatest gains because their processes were so antiquated in many cases. But if you're writing custom software, how much more efficient can you make that? I mean there's only so much you can do with code re-use, libraries, etc. The trick there was usually to make sure the ladder was against the right wall.

Believe it or not, we had one manager back then who thought if you weren't writing X lines of code per day, you weren't being productive. Well, there's a huge whole in that theory. What if it was your week to work on testing and bug fixes? (We had a group that did that. The developers rotated weeks.) Not ones to be outdone, the developers created a code meter and stuck it on the wall! *g* Depending on how they felt productivity-wise, they moved the needle to high, medium, low, or off the scale. *g*

BTW, I got a chuckle out of your last line - "be happy with the result." *g*

Rick Smith, "The Net Guerrilla"