Dan Sugalski, of Parrot fame, has written a post mortem regarding his experiences running that project. Some of what he says struck a chord with me, so I thought I’d elaborate on it from my own perspective.

Professional courtesy: Good
One of the things I insisted on was that people behave professionally. (Not, mind, as adults — I know plenty of adults who behave badly, and some of the kids (and yes, Brent, you and Zach counted at the time :P) involved with parrot behaved better than some of the older adults) I wasn’t looking for the sort of cult of personality that pervades the perl, python, and ruby development camps — I find that rather distasteful, both as the potential target and as a general participant. I also remembered the perl5-porters mailing list when it was more a shark tank than a development mailing list, and I did not want that.

All-volunteer or not, I viewed parrot as a professional engineering project, and I wanted people to behave accordingly. For the most part everyone did, and I was happy about that.

Not telling people to shut the fsck up and cope: Bad
Professional courtesy is fine and all, but if you’re running a project, with volunteer labor or not, sometimes you need to tell people to suck it up and deal. More importantly, there’s nothing wrong with a judicious exercise of authority, especially if the exercise of authority is part of the job you hold. I was the architect for the project and it was my responsibility to design the system and get that design implemented. Part of that meant that yes, I should have told people to cope. Shying away from confrontation doesn’t do anyone any good — I did, and the project suffered for it.

This is the part that I also found most difficult about being the product architect at Revivio, and is to a large degree why I’m not in that role any more. A lot of people have this idea that being an architect means you call all the shots, which sounds pretty cool. I used to think that myself, but the reality is quite different. The fact is that everyone’s much more willing to share responsibility with the architect, but not control, so the architect ends up being held responsible for a lot of decisions he did not in fact make. Nobody has the time to review every line of code that gets written by every developer on any non-trivial project, and if you’re not writing or reviewing the code you don’t really have control over how it’s implemented. I can’t count the number of times I worked my butt off to secure some kind of compromise on how something should work, only to have the developers go off and implement something distinctly inferior to what had been agreed upon. Sometimes the exact problems we had anticipated and tried to avoid in the design phase came back and bit us as last minute bugs because of that. To this day, the same person responsible for one particular piece of brokenness is now lobbying for permission to rewrite his pet subsystem for about the fourth time because of flaws that he had been told about well over a year ago. It’s pretty frustrating.

The worst variant of this problem is what I call guerilla warfare. We used to have our own “Leo” here, and if contributing to his departure had been the only thing I ever did as architect it still would have been worth it. His specialty was to try to undo every decision he didn’t like. Sometimes he’d simply go off and do something different, as described above. Sometimes he’d lie about having received permission or agreement for it. Most often, though, he’d just take every opportunity to question both the original decision and the authority/competence of the person who made it. I’m sure everyone else is familiar with this phenomenon. Every single bug, no matter how minor, in a component that was once the subject of controversy becomes an excuse to reopen the controversy. “There’s a typo in an error message? Oh, well, that’s proof positive that we should have done it my way. Never mind how far we are into the project; let’s rewrite it now.” Insert eye-roll here. Fortunately, management eventually wised up to these tricks and demanded that they stop…not before enormous damage had been done both to the code and to morale, but nonetheless.

It’s easy to say that some of these problems might have been less severe if I had put my foot down earlier, but there’s only so much you can do even in a professional environment without harming morale and productivity even more. If you’re not responsible for assigning someone’s priorities or writing their review, you actually have very little control over what they do. If the director of development resists giving you authority to reject checkins on the basis of technical inconsistency or insufficiency, another means of ensuring technical quality is lost. There’s nothing quite like being relegated to a purely advisory capacity, where others can pretty much choose to ignore your advice, and then being held accountable for the consequences when they do. This is but one instance of what I generally consider Management Mistake #1, particularly at startups: failing to associate authority with accountability. The only thing worse than blaming someone for something they couldn’t control is giving someone (usually senior management) control over something for which they’ll never be held accountable. If you’re going to let a VP make technical decisions, they have to be held accountable for any bugs or schedule slips attributable to those decisions. If you’re going to have one person as the “one neck to wring” for all technical aspects of a project, you have to give them some way to make that project reflect their vision and not somebody (or everybody) else’s. Some day I’ll be at another company, whether things go well or poorly where I am now. Whatever role I’m looking for, you’d better believe I’m going to ask a lot of questions about how authority and responsibility are distributed and whether the two match.