timothy falconer's semantic weblog
Big Fractal Tangle


RDF
 
leading by example

How often have you worked on projects where your company first re-evaluated its project infrastructure and development plan? “I think the task priorities should be Hairy, Ignorable, and Pointless.” “We need to change our source-control system to MultiMegaMerge.” “Let’s create a worldwide distributed automatic build like Seti@Home, only more secure.” Everyone’s got their own opinions about project management, which is why there’s so many products in this space, most of them homegrown.

Around the time I decided to quit Lotus, they had an all-day, all-hands meeting at a local conference center to “discuss” our new development process. Sitting in the audience, watching our higher-ups describe their pretty graphs, I slowly shook my head and tried to guess how much money all this cost the company. Looking back, I think the biggest problem was that they had non-developers telling developers how to do their job. Even if they were right, even if their official plans were born of hard-won experience from their lowly days as code-monkeys, it’s still an all-around bone-headed move to have higher-ups dictate their doctrine from a stage while their well-paid audience is half-asleep, waiting for lunch. Guess how much buy-in their plan got? The parts we followed were usually after-the-fact, just to satisfy management.

The way I see it, the only way to build great software is with project managers who know the tech inside-out, who could do the job of everyone on the team if needed. Great project managers are the first to volunteer for crap tasks when everyone else is knee-deep in other work. They have passion for the smallest details, but they know when to relax their grip and let people do their jobs. They’re the people running from cubicle to cubicle just before the demo, putting out fires and helping people solve problems. They make software, not reports.

In the mini-series “Band of Brothers”, the most effective, most inspiring, leaders were the ones that ran in front of their men, straight into enemy lines. Some could say, “Now that’s just dumb. Why risk a captain like that? He’s more important behind the scenes, directing the action.” Such a view misses the point of being a leader. Leaders that inspire don’t draw diagrams, they get their hands dirty. Leaders take chances. They do whatever they can to get everyone moving in the same direction.

Software isn’t war, but there’s casualties just the same: lost revenue, lost respect, lost opportunity. Layers of middle-management may seem necessary, but in the end, they just bog things down. Putting procedure before people is the quickest way to kill off creativity, which is probably why it’s small companies that make the coolest stuff.

Comments are closed.