6

Cogs, know when to fall off your wheels

 3 years ago
source link: http://rachelbythebay.com/w/2012/11/09/wrong/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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?


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK