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.