Okay, people, time to get organized! The question is: how? If you work alone, you can work any darned way you please. You don't need to coordinate what you are doing with what anyone else is doing, and you don't have to get along with anyone. You can keep everything in its exact, obsessive-compulsive place and do things in the precise sequence of a standard software development life cycle model. Or you can leave everything spread out all over the office in utter chaos and code things as you get inspired or happen to think of them. However, once you have two or more people working together, the operant word is “together.” The work they do and how they do it have to be coordinated.
This chapter begins an exploration of the organization and management of human work: how work is organized and how people who work together coordinate their activities (Constantine 1990a, 1991c, 1993c). Think of organization as the human equivalent of software architecture—with management corresponding to the dynamic control of program components. It's the old structure and dynamics thing again. Whether you are trying to organize a new software company or the next programming project, many of the same issues apply.
So how do you do it? How do you get a group of people—a project team or an entire corporation—to work together? How do you organize the group, structure the work, and manage the activity? What's the right way? Here it's time for one of those standard “consultant's answers”: it depends! Looking for the right way to organize projects is like looking for the right way to code a subroutine. It depends on what you are trying to accomplish (Constantine 1993c).
The bread-and-butter work of producing yet another set of print drivers or another variant on a conventional screen generator may require a very different model for organization and management than what is needed for a team devising a breakthrough CASE tool to support concurrent software engineering and consensus design of object-oriented software. In an excellent little book on teamwork, Larson and LaFasto (1989) identified several major variants on project teamwork, each of which is better at some things than others. Here we'll look at four distinct and very different models for project teamwork organization, each having advantages in certain areas and each having its own particular weaknesses.
So, let's get organized! The simplest and safest way to go is the tried and true of standard operating procedure. The traditional way to coordinate the work of more than one person is to put someone in charge, making them a supervisor. The function of the supervisor is to direct and oversee the work of others. This structure can be extended by recursion. The result is a hierarchy of managers in charge of others who manage still others. This is a simple, stable, and familiar form of organization: a traditional pyramid based on a hierarchy of authority. On software projects organized along this model, the hierarchy may not be many layers deep, but it is still a hierarchy. In principle, it can be amazingly efficient; in practice it can grow into a towering bureaucracy incapable of anything but sustaining its own bureaucratic inefficiency.
Such a model is more than merely a way of working; it can be a way of life. I was recently reorganizing my record collection to make room for the steadily multiplying CDs when I found a real treasure, a vintage recording of “Paean,” selections from the IBM corporate songbook.[*] Listening to the Association of British Secretaries in America (indeed!) sing their stirring rendition of “The IBM Country Club Song,” I started thinking about company culture and how the way we work shapes the way we view the world as much as the other way around.
The traditional view from the pyramid sees organization as the foundation of stable performance and sees control as the key to keeping it all together. Leadership depends on authority. Managers make decisions and subordinates are expected to implement them, to show loyalty, and to accept direction from their superiors. Predictable, reliable performance is achieved through standards and procedures, through rules of operation. Everyone has their job, their role, their responsibilities, their place in the hierarchy. Corporate or divisional or project interests come first and foremost; individuals are rewarded for faithfully carrying out their part of the larger job.
In basic form, this model is really very simple. Put somebody in charge who can start making decisions and giving orders, preferably someone who knows the ropes and has come up through the business. Decision making in traditional hierarchies is supposed to be strictly top down. It may take time for a given matter to reach the right person in charge, but once it does, decision making can be quite efficient. As fast as the leader can make up her or his mind, the decision is made. No one needs to be consulted; there is no need for discussion, debate, or exploration. Obviously, this can be a strength and a weakness. It means that a lot hinges on the one at the top. Bad decisions can be made as quickly as good ones, and a leader who is too slow or out of touch can bring the entire pyramid crumbling down in ruin.
When it comes to software projects and project teamwork, the traditional model is best at what can be called tactical work. In tactical projects, the territory is familiar and the parameters are known. The most important thing is to get the work out the door. I cut my programming teeth on tactical projects, producing routine business system applications, such as payroll, cost accounting, and personnel file maintenance. Once you have done a couple of payroll systems, they all begin to look alike. Even if they really aren't, seeing them that way helps you to simplify, making it easier to build and maintain standard ways of doing things. Eventually, you know all the steps and can do them in your sleep.
Clarity is the make-or-break issue for tactical teamwork—clear requirements, clear directions, clear roles. Within this world, development methods are more effective when they are well defined, with clear standards and guidelines. A detailed software development life cycle is specified within which successive phases are carried out. Work is expected to be accurate and efficient. The focus of the group in such a team is on the task at hand. Period. What team members need most is clear direction from project leaders and management. Team members are assigned specific portions of the well-understood work and do what they are supposed to do.
Traditional hierarchy works. Many companies in our industry and countless software projects have been organized along these lines, including some of the biggest success stories in computing. Corporate songbooks extolling fearless leaders and loyal followers are the artifacts of some of the largest and best examples.
Such a well-defined and predictable environment can be comforting, but not everyone is comfortable fitting into that world. Those who do are likely to be loyal, committed, and action-oriented. They attach a sense of importance to the work they are doing more than to themselves, and they respond well to directions from leaders. They probably prefer to pay more attention to programs than people. Tactical teams are havens for conformists and obsessive-compulsives, for salt-of-the-earth basic programmers. Tactical teams work well for those who want to know what to do and just do it.
On the downside, any group organized as a traditional hierarchy can somewhat too easily get stuck in a rut, resisting useful innovation in the interests of maintaining stable authority, and ultimately spending more energy on rigidly enforcing standards and procedures than on solving problems or producing products. At their best, they are efficient and productive but not very innovative. To the extent that they do innovate, it is likely to be incremental improvements on established technology, evolution rather than revolution. Looking at the large industry leaders who rely on traditional hierarchy, we often find that their major innovations have come from acquisitions or from small internal spin-offs.
Companies and software groups organized along these lines are likely to have particular difficulty dealing with cowboy coders (Chapters 7, 8, and 10). Independent individualists and traditional hierarchy are an immiscible combination. Those who resist or question authority, who insist on going their own way or departing from standards, are likely to find themselves passed over for raises or on the short list for downsizing.
From the top of the pyramid or buried somewhere within, it may look like there is no other way to organize and manage. After all, somebody has to be in charge, right? Either you lead, you follow, or you get out of the way. Some people still don't see any alternative to hierarchy for human organizations. But then we once thought that nested subroutines topped by a control executive were the only way to modularize programs. Now we have communities of communicating objects and peer-to-peer networks with distributed databases.
And people are ever so much more flexible than programs. At least some people.
From Software Development, Volume 1, #3, March 1993.
[*] Released as a joke for one of the major computer conferences but not without its valid insight into corporate culture and politics.