The Human Side

The process and culture have a richly human side. This shows up in how the group talks about itself, as well as in its organization and process. I explore three aspects of the human issue here. how people issues are integrated into the process, the anthropomorphizing of code, and management practices.

Engineering people issues into the process

The "high touch" flourish in this "high tech" environment became clear from the outset [BibRef-Naisbitt1984]. People invented outrageous role names to describe themselves: Mad Artichoke for the architect; Agitator; Code Police, Damage Control.
The "person-ality" of the project goes deeper. Consider the perceived responsibilities of role Agitator:

  • Keep team from getting too comfortable
  • Trigger discussions
  • Say things nobody wants to say

"Say things nobody wants to say"? Many conservative development organization cultures are loaded with "unmentionables" that plague progress by cutting off painful avenues of progress with taboos. In this organization, everything is open to criticism by anyone. As Steve Bauman (then a director at Bell Laboratories) once said, it is not "warm and fuzzy"; it is "open and productive." This behavior can be found in patterns like WiseFool and PublicCharacter. The Damage Control role has the following responsibility: "Repair inter-organizational and inter-personal damage".

The first-level manager plays a less authoritarian role in the process than in a typical corporate development setting. Most of his role is to provide support and to track project status, but "twisting arms" of people outside the team is also among his responsibilities. He sees his job as ensuring that the team has the best people possible, that they have the resources and time necessary to do a good job, and that outside interference and roadblocks are kept out of the developers' way. He also fills the Damage Control role.

Code Ownership and Programming Anthropomorphism

The project has strong code ownership that transcends release cycles. Everybody knows what everybody else is working on. Nobody changes anyone else's code, except in an emergency. If one programmer finds a bug in another's code, the person finding the bug asks the owner to make the change.

Code ownership creates an interesting project mentality that is difficult to codify, but which might be summed up in a wry comment from one developer: "We don't use ECMS or Sablime, [source management tools] so we need code ownership." Code ownership makes job responsibilities visible in the culture, rather than burying them in a tool.

Code ownership goes so deep that the project has anthropomorphized their software. Software anthropomorphizing is something taught in some analysis techniques, including the popular CRC technique for object-oriented analysis, [BibRef-Beck1991] but this project takes this to an unparalleled extreme. During scenario walk-throughs, you don't hear them saying, "the X module sends this message to the Y module," but rather, "A message comes in from Dara and goes over to Roman" or something analogous. "Now, Peter kills Pat" describes a signal sent between processes. One can go by the lab at night, and hear a programmer scream "Oh, Peter! Why did you do this?" as "Peter's" code reaches out and creates some system atrocity that makes the tester's life difficult. The code is strongly identified with the individual owning it.

Responsibility is a deep underlying value in this project. Ownership exists for its own sake, but if you own something, and you make a change, you have responsibility for it. Code ownership and the associated culture raise everybody's awareness, expectation, and assurance that such responsibility will be carried forward. It seems more powerful than having a tool to track down a change to an accountable individual: there is a mind-set that transcends the need or such version management tools in a small project. This makes site support and FOA activities easier: when a problem is found in the field, it is usually clear who needs to be brought in to fix it.

Will the project need version management as it grows? Possibly, but the market is constrained enough that multi-featurism may not become a serious problem. If they can coordinate releases for all sites (the market is believed able to bear 11 systems) then versioning may never be needed.

Growing a Garden

After the group session, I stopped by to debrief the department head on my findings. She briefly described her management philosophy, which she likened to gardening. Her main job, however, is to "keep the pests away." That, she said, is what a good project manager should do as well. Curiously enough, the role we ended up calling "project manager," we were initially going to call "smoke screen," because it distanced the development community from surrounding organizations.

On the way out, I ran into a manager from another project who in an unrelated context talked about "controlling the people who sit in the bleachers and throw rocks." Insulation appears to be an important and successful management strategy in our culture.

Rewarding Excellence

Traditional rewards like money and promotions are in short supply--but that doesn't constrain the intrinsic motivators which can be equally direct and even more effective. People enjoy their work here. Their talents are appreciated and the people are respected as individuals. The people are trusted: they are given much latitude, much responsibility, and are trusted to talk directly to customers. The issue of trust was also central to the Borland QPW team.

Their department head had this to say:

[M]uch of the reward is intangible...not something I as a manager give, but something I allow them to achieve. I give lots of personal attention to them mostly and try to create a fun, creative environment with challenging assignments. I try to personalize the whole set of interactions so that everyone thinks they are doing this to better ourselves and better our chances of getting more challenging, fun, creative work.

This approach is reminiscent of the "getting one's ticket punched" concept described in Soul of a New Machine, [BibRef-Kidder1981] a mentality common to Silicon Valley companies as well. The close coupling between influential management (in this case, a widely respected department head) and their reports is also reminiscent of the Borland environment.