Friday, August 14, 2009

An excellent bit of humor

http://uncyclopedia.wikia.com/wiki/Cowbell

The Philosophy of Engineering (part 2)

What does it take to motivate engineers? (Or anyone, for that matter)

I.e., what can I do to motivate engineers?

Will it take an Advanced Degree (TM) to figure this out?

Let's start with: what motivates me?

Me: interesting problems to solve. I like solving problems, I like making things. Things I like making have included some of my furniture (actually quite a few pieces), computer programs, electronics, model railroad stuff...there have been other things as well (deck outside house in Dallas).

I got started down the engineering path by about age six because I watched my dad fix things, and I was intrigued at the insides of things. At age 14, I found out that engineering pays better than most other jobs, which certainly clinched that.

So let's speculate that most engineers are motivated by having interesting problems to solve. A good team has an interesting large problem to solve, and many smaller ones that can be handled on an individual basis. A problem that *can* be understood, and a solution that *can* be found without it taking forever, materials and tools to go from the beginning to the end, and the satisfaction of having succeeded and producing a final widget--one that people actually use and like.

What of other folks, for whom the challenge of the problem is not sufficient? Do they need a $ incentive? What other incentives might there be? Formal recognition?

Here's a reference that covers similar territory. Actually, it *really* covers the same territory, except they left out problem challenge (unless you say challenge=creativity, then it's "internal"). Here's the detail.

Another link HERE has a really good first comment:

"People also get motivated when they are working for a leader who has the following traits:

1. Good memory
2. Genuine interest in people
3. Integrity
4. The ability to communicate effectively
5. Decisiveness
6. The ability to relax
7. Genuine enthusiasm."


This is about teamwork and good leadership. Good management. I can't argue with that, having had both good and bad (which is separate from experience, although there is a correlation). More detail can be found HERE.

There are probably some other ones...More are listed HERE.

Why do you/I/we care?

"Employees who are motivated are willing to invest discretionary effort to go above and beyond the call of duty." (HERE)

That's something you want.

But different people have different motivations, and need different incentives. From some recent reading on this (related to above links), money appears to be one that doesn't work too well. I can't say that a tiny amount of money would get my attention...you'd have to offer at least $50k to even get my attention, and more like $100k to get my participation. Maybe if I had some debt issues...but $1000 doesn't do it for me.

Getting one's paycheck is a motivator, of course, but you really need to like your work to go beyond that. What makes that happen?

Probably you want a suite of incentives, to get folks going. Recognition for performance. Influence over what gets done. Money. "Internal" reasons (see that first link above; this includes a number of factors, I think, good mgmt, good team, creative challenge...).

So how to do you define those incentives? Recognition could be as simple as a thank-you from the boss...but that could be pretty hollow, too. A private thank you for something that no one else even knows about, and then nothing...why bother? I want something a little more serious than that.

The Philosophy of Engineering (part 1)

A year or two after I joined my current employer, I became interested in what I now call the "Philosophy of Engineering".

What is that exactly? Let me offer an example...

In 1992/3, I worked on a health-care project. It was 10-20 years ahead of its time then, and still is, although the concepts behind a little of it are now being talked about, and some of the associated hardware has come to exist since then...

That project was a team effort--the best team I have worked in ever.

Immediately upon joining my current employer, I was in a new team. One which I have since described as "five guys with the same charge number"; not really a *team*, as I had just experienced it. I was the latecomer, and I ended up with the largest responsibility: integration and delivery and support...

I don't recall that this second team ate lunch together more than 3 times over 20 months. I don't recall that we ever held anything resembling a design meeting/discussion, or really anything I associate with a good team. So that was the worst team I've ever worked on.

I've been on various in-between ones since then, or solo. All have their little problems, none are perfect.

So what is it that makes for a good team? Does it take an Advanced Degree (TM) to figure this out?

Crucial elements:

You need someone (at least one, but not very many) who is the keeper of the vision. That person is often (around here) known as a "Principal Investigator", which is not necessarily the same as a System Engineer, although it could be the same person. The PI should do things like define the concept being attempted, create/locate/define/refine examples like "use cases", make presentations to existing/potential customers, and could offer implementation suggestions. I've never quite had exactly that kind of PI, yet.

You need a System Engineer, who can figure out exactly how to implement the vision. This has often been my role.

You need an implementation team. These folks are not keepers of the vision, and they are not decision makers about system block diagram kinds of things (although they might be); these folks are the ones who create what the SE decides should be created. I've been this person too, although most commonly I am a combination of SE and implementor.

You need a good Program Manager. This guy deals with the financial aspects, meetings with customers, marketing, personnel...all that mgmt jazz. The PM should not be the SE, probably should not be the PI (although that is common).

The last actual team I worked on (2004/5) had a decent PM, a not-so-great PI (only did about half the job), myself as SE, and one implementor guy (so of course I did a lot of implementation). That was actually going well until the PM found himself unable to continue in that role (he commuted in from a ways off, and then his wife got pregnant with triplets). The new PM was a jerk, really unsuited to the role, not interested in the project, obnoxious in meetings. I had tried to get someone else to take the role, but that person was not yet interested/ready to do that. My involvement faded out, and the project died within a year after I wasn't working it any more.

Mind you, that really cool health-care project got killed, too, although that was because too many managers wanted control of it, not because it wasn't going anywhere.

So I'm thinking next time I'm in at the beginning, I'm going to specify exactly who/what I get on my team, else I'm not getting on it myself.