Cogs, know when to fall off your wheels

Much has been written about the matter of trying to hire good people and
build good teams. One of my favorite books about software project
management is
The Mythical Man-Month.
Even though it's been around since 1975, it's still hard to find people
who know about it. I'm not even necessarily worried about whether they
agree with what is said in that book, but rather that people are
familiar with the concepts from it.

Still, these books and web log posts and seminars all seem to be about
how you build a team and get a bunch of superstars. I'm going to guess
that most people who read this kind of stuff do not have the power to
control who's on their team. They probably can't fire anyone, and they
probably have only the weakest influence on the hiring process. If they
work at a big enough software sweat shop, nobody really knows where a
candidate will end up if they do get hired.

So I'm more concerned about what individuals can do to make things
better. If you can't hire and fire people to build a better team, then
all you can really do is look out for yourself. Sometimes, that might
include deliberately being the cog who slips off the wheel in order to
stop the whole machine. The machine may grind to a halt, but the cog
(that's you) gets away. If you're lucky, you might even keep some of
your enthusiasm for this kind of work and manage to join another
project.

I'll share a few things from my own life which might be useful signals
in deciding when you should cut and run. Most of them are observations
I could only make in hindsight. Hopefully some of them will be useful
to people who haven't encountered them yet.

If you're the only person on a team who actually understands something
fundamental about what you're all there to do, and you aren't being
compensated accordingly, you might have a problem. When there are three
MCSE "network engineers" who don't really "get" TCP/IP, and they're each
being paid three times what the lowly Unix admin (who does) makes, you
should worry. If those three guys are charged with running a big IP
network, but all of the actual magic is figured out by the Unix admin
"just because", there's definitely a problem. Get out and let them
twist in the wind.

If nobody else on the team ever seems to get excited about your project,
you might have a problem. Have you ever been at work and had some flash
of insight about some way to reach your latest milestone? Did you
immediately turn off your phone, put on your headphones, turn on the
music and start cranking? Did you fill up whiteboards with scribbles
and then use caffeine and carbs to turn those scribbles into code?

I did that a few times in the past. Different things would come up and
I'd find myself excited by it. Finally, I had a clear definition of a
problem, and the solution had already gelled in my head, and I just had
to get it out of my head and into the computer. More than once, I
called in a phone order for some take-out food, ran and got it, brought
it back to my office, and proceeded to do my thing while everyone else
split for the night.

Those were fun times. For a few hours, I could forget about the general
sense of apathy which surrounded me by virtue of having teammates who
really didn't care if the project succeeded or not. It didn't have any
impact on their lives, really. They were there to turn the crank on
whatever you put in front of them, and flavor A vs. flavor P didn't
change things either way.

The problem is that nobody else cared about the project the way I did.
If you've done that kind of "evening sprint" thing and nobody else on
your team has, you certainly have a problem. Their lack of enthusiasm
for the project when compared with your obvious deep-seated caring for
the project will eventually destroy you. Bail out and let them see how
far a bunch of lifeless blobs can go by themselves.

Perhaps you find yourself in a situation where you are unable to give
useful direction to a project. Your positions are correct, but it's
always understood too late, after the alternate road is taken and things
fail. For whatever reason, they aren't hearing you, or they are
choosing to ignore you. They might even be purposely discounting the
idea because it came from you if you have some real psychopaths on your
team. At any rate, you're winning your own internal "I told you so"
metric, but things are going to hell in the meantime. You can stick
around to wait for all of those things to run their course and hope the
bad people leave, or you can pull your eject handle. Pull it. Let them
ride that flaming ball of wreckage into the mountainside while you float
down on a parachute.

Really, if you can't change things for the better in a technical sense
or a personnel sense, then the project is effectively stuck in the
groove where it is right now. You can either shut up, kill some brain
cells with your vice of choice and try to fit in, or you can walk.

Yes, you can be really good and still be the wrong person for a team.
A team which wants to boldly go nowhere while warming some chairs has no
use for someone with the fires of creation burning within. They
might think they want you, but they really don't.

Forget about "can you code". The new question I want answered is
this: can you care?