Often, the programming project ends up with its own culture, different from the national or corporate cultures in which it is imbedded. People on the project find this useful, because they have a greater need to trade information about what is working and what is about to break.
Sometimes, the wider organization tolerates this different culture, and sometimes it fights back. One person who had experienced the resistance wrote, "Watch out for the organizational antibodies!"
Figure 3-19. Four organizational paradigms.
There are many ways to characterize cultures and their values. In one (Constantine 1995), sociologists name four culture types by their communication, power and decision-making habits (Figure 3-19).
Hierarchical cultures have the traditional top-down chain of command. Typically, older, larger corporations have a hierarchical culture. Many people internalize this as the dominant or natural or default corporate culture as they grow up, and have to be trained away from it.
Random is the opposite of hierarchical. It indicates a group in which there is little or no central control. Many startup companies work this way.
Some people consider random a fun way to work, and regret the loss of the small, informal group when the company grows. Others find it stressful, since there are no clear points of control.
Collaborative groups work by consensus. I had the opportunity to encounter a collaborative group in action at Lucent Technology: Consensus Culture at Work
Someone in the organization decided that use cases would be a good way to capture requirements, and asked me to teach a course to the people on a project.
I met the team leads (who are actually called coaches, because in a collaborative culture they don't lead, of course, they coach).
About a month later, I was called to teach it again, for more of the group. Several months after that, I was asked to lecture one last time, for the entire department. Even though the coach had decided that use cases were good, the group was not going to use them until they had all had a chance to see and understand them. The behavior of the coach in the final meeting was interesting: He programmed on his laptop while I taught. He was physically present in the room, but only just barely. Far from insulting, I found this fully appropriate in the light of the value systems in play around his situation. As a senior developer, he demonstrated that he was still contributing directly to the team's work. As a coach, he demonstrated support for the material being presented, which he was hearing for the third time. Thus, his behavior was a natural expression of his place in two professional societies: developer, and coach.
Synchronous, or "silent," groups are the opposite of collaborative. They coordinate action without verbal communication, people performing their roles without attempting to affect the other roles' work styles.
Constantine gives two examples of synchronous teamwork. The first comes from a scene in the movie, "Witness," the Amish community raises a new barn in a single day, scarcely uttering a word. The second comes from an accident that happened inside a hospital, when a heavy table fell on a person's leg. Without speaking to each other, the people in the room took coordinated action: two lifted the table, one held the person's hand, one went to call for an x-ray, and one went to get a gurney.
In both cases, the people involved knew the rules of the situation, the goals and the roles involved, and could simply step into a needed role. Constantine highlights that "team members are aligned with the direction established by a shared vision and common values."
It may turn out, in an odd twist, that programmers operate a silent or synchronous culture. If this is true, it will be interesting to see how the cooperative game gets reshaped to fit that cultural pattern. Certainly, the current wave of development methodologies, including XP and Crystal, require much more conversation than previous ones. Either the programmers will shift their culture, or the methodologies will have to adapt.
In many organizations, programmers are expected to work massive overtime. It was a great shock to me to move from one such to the Central Bank of Norway, where personal life was strongly valued and overtime discouraged: Overtime Lights at Norges Bank
At the Central Bank of Norway, the official work day ended at 3:30. On a typical day, that is the time I suddenly waken from whatever else I am doing, and ask myself what I really want to get done that day. As a result, I found myself wandering the halls at 3:45, trying to "really get some work completed before the end of the day," and unable to send faxes, get signatures on paper, or get questions answered. The staff really did go home at 3:30!
Then, at 5:00, the lights automatically turned off! I learned how to turn on the "overtime lights," but got a second shock when the light turned off again 7:00 p.m. ("You really, really ought to go home, now.").
Cultures also differ by their attitude toward frankness and politeness in speech. The Japanese are renowned for working to preserve face, while Americans are considered frank. Frankness is taken to extremes at places like M.I.T., Stanford, and Israel. An Israeli friend was coaching me in direct speaking: When I saw him after he had to miss a review meeting, I said, "We missed you at the meeting." He replied, "In Israel, we would say, 'Why weren't you there?'"
In other cultures, such as the church organization described earlier, even disagreeing mildly or taking initiative are considered slightly negative behaviors, signs of a person having excessive ego.
As a result of differences around frankness in speach, people coming from different cultures can have difficulty working together. The overly frank person strikes the other as rash and abrasive, while the overly polite person strikes the other as not forthcoming, not contributing.
Professional Subcultures
Each profession also builds its own culture, with its own cultural values and norms. Project managers have theirs, as do experienced object-oriented developers, relational database designers, COBOL programmers, sales people, users, and so on. Even novices in each group have their own values and norms, distinct from the experts. Here are a few: · Project managers need an orderly attitude to sort out predict delivery dates and costs, and the complex dependencies within the project.
· OO programmers need quiet time, abstract thinking ability and the ability to deal with the uncertainty of simultaneously evolving programming interfaces.
· Requirements analysts rely on thorough thinking, going through the requirements and the interfaces one line at a time, looking for mistakes.
· Marketing people benefit from strong imaginations and people skills, and dealing with the constant surprises the market (and the programmers) throw at them.
Let's consider programmers' "non-communicative and anti-social" behavior for a moment. Actually, as a number of them wrote me, they do like to talk ... about technical things. They just don't like talking about things they consider uninteresting (baseball games and birthday parties, perhaps). What they really detest is being interrupted during their work. It turns out there is a good for that.
Software consists of tying together complex threads of thought. The programmer spends a great deal of time lifting and holding together a set of ideas. She starts typing, holding in her head this tangled construct, tracing the mental links as she types.
If she gets called to a meeting at this point, her thought structure falls to the ground, and she must rebuild it after the meeting. It can take 20 minutes to build this structure, and an hour to make progress. Therefore, any phone call, discussion, or meeting, distracting her for longer than a few minutes, causes her to lose up to an hour of work and an immense amount of energy. It is little wonder that programmers hate meetings. Anti-social behavior, meeting-avoidance in particular, is a protective part of their profession.
Thus, the values of each group contribute to their proper functioning, and the differences are necessary for the proper functioning of the total organization, even though they clash.
It would be nice to say that all of the values and norms are constructive. Not all are, though.
An example we saw earlier is the Invent-Here-Now imperative. It is developed as a cultural value and norm all the way through college. In most organizations, however, inventing new solutions where old ones already exist is counterproductive to the aims of the organization. The ideal norm would be to scavenge existing solutions wherever possible, to invent only where it leads the organization past its competitors.
Adapting to Subcultures
Most people's initial reaction is to force one group's values on the other groups.
· Researchers in formal development techniques want more math taught in school.
· Managers uncomfortable with iterative development want their programmers to get the design right the first time.
· The programmers, frustrated with not being able to communicate with their managers, want the managers to learn object-oriented programming prior to managing a project.
There are two problems with the make-them-change approach:
· The less serious problem is that it is really, really hard to get people to change their habits and approaches.
· The more serious problem is that we don't yet understand the subcultures. To force them to change their values is a bit like prescribing
A software project sets up a small ecosystem made of personalities from diverse cultures. We have seen some elements of the ecosystem, including
· Walls acting as barriers, open spaces acting as conduits medicine without understanding the defense mechanisms of the body.
In the face of this situation, there are things that the industry can do, things that a few individuals can do, and things that everyone can do. As an industry, we can
· Encourage more ethnographic studies of software development groups, as Grinder (199?) and Hovenden (2000) have done
· Identify and understand norms in play, showing the contribution of each to the organization
· Experiment with cultural changes Every consulting company would benefit from employing a social anthropologist or ethnographer. That person will help the consulting team understand the social forces in play on their projects, which will enhance the team's effectiveness.
People who are fluent in several specialties, such as programming and database design, programming and project management, or teaching and designing, can act as translators. These people help by converting statements phrased in one normative value set into sentences meaningful within a different value set. A number of people who perform this function have written to me, describing the difficulty, and necessity, of this role.
Finally, everyone can practice patience and goodwill in listening. Pretend that the other person's sentences, however crazy, make sense in the other culture's value system. Listen that way first, and then decide if you still need to disagree.