close this bookManaging in the Corporate Interest
(ebookmgttestedok.html)
View the documentMetadata
View the documentAcknowledgments
View the documentChapter 1
View the documentChapter 2
View the documentChapter 3
View the documentChapter 4
View the documentChapter 5
View the documentChapter 6
View the documentChapter 7
View the documentAppendix
View the documentGlossary
View the documentBibliography

Chapter-5
SystemsGroup:
The Leading Edge

Whereas the branch system was the object of radical downgrading processes, SystemsGroup was the source of many of those changes. When it was first organized in 1984, SystemsGroup was hailed not only as a state-of-the-art division because of its technology and its skilled employees but also as the division that would help American Security Bank gain a competitive edge in a new banking climate. SystemsGroup, a high-technology division comprising over 3,000 engineers, programmers, systems analysts, and staff, was systematically to unleash its scientific expertise onto numerous functions throughout the bank and find ways of automating or eliminating them. Its research groups developed information-management systems across the bank (linking and centralizing them through common data bases and technologies), designed systems for capturing and continually updating electronic data, and explored ways to gain greater control over bank information.

SystemsGroup was not only a cause of centralization, however; from its inception, this division was organized on a model of centralized bureaucracy. Before SystemsGroup, programmers and systems analysts were affiliated with functionally specific divisions spread over fifteen locations. In 1983, American Security hired an outsider as the bank's "technology czar," to consolidate the technology and information-management functions. In a five-year plan that cost the bank nearly $5 billion-over 40 percent of which was personnel expenses-the new czar brought SystemsGroup employees together into a sleek postmodern complex of buildings, creating a division that would "manage the application of technology as a strategic resource and as an integral part of American Security Bank's many businesses" (management literature).

The new centralized organization afforded greater control over the employment conditions and total wage package of SystemsGroup. The process of physical and organizational centralization forced SystemsGroup middle managers into a closer working relationship with the human resources staff who were to assist the bank in gaining control over wage costs. In early 1983 the president of corporate human resources announced a new organizational arrangement of the corporate personnel division. The human resources staff formerly had been concentrated in bank headquarters. That centralized personnel group was broken up, its members sent to each of the bank's nine major divisions (the retail, or branch, division, international banking, SystemsGroup, and so forth).

Although strategic management touted this change as decentralizing the human resources function and bringing "day-to-day personnel decision making closer to the divisional level," the implantation of smaller human resources groups within the major divisions was actually a more organizationally effective version of centralized personnel management. "Diffusion-centralization" more accurately describes this organizational arrangement, since it extended control by locating centralized power closer to the line.[1] Through organizational innovation, the executive-level personnel division gained direct access to its operatives at operation levels. Thus strategic management used the human resources group to gain control over management's discretion in matters pertaining to employment conditions and the total wage bill of SystemsGroup. Much like branch managers before the bank reorganized, systems managers before the formation of SystemsGroup had almost complete autonomy in hiring, initiating new projects, and approving "out-of-guideline" raises and promotions.

That autonomy was the direct object of restructuring in the newly centralized SystemsGroup division. The human resources people, physically located within the division, rationalized and standardized procedures by which SystemsGroup managers would hire, fire, and reward. They gained a new position of authority in the management circuit by creating centralized data bases for recruiting and hiring, redeploying systems workers on completion of projects, and requiring that middle managers consult with senior human resources representatives about wage packages for new employees and raises and promotions for others.

Strategic management, in mapping out SystemsGroup operations, laid the organizational bases for centralizing its key features. But the organizational future of SystemsGroup differed from that of the branch system in two important respects. First, unlike the downgrading of branch operations and employees, the "production" processes of SystemsGroup's programmers and analysts were not directly subject to rationalization (in the dynamic sense suggested by writers such as Kraft [1977] and Greenbaum [1979]), and SystemsGroup's projects were expanding rather than contracting.[2]Second, strategic management was not intent on systematically displacing middle-level management in SystemsGroup, as they were middle management in the branches. SystemsGroup faced a unique future. The management process itself was an object of rationalization and centralization. The concerted effort to control yet retain managers in SystemsGroup reflects a configuration of production, labor market, and skill factors that differs significantly from that of the branch system.

The Project Group

The typical production unit in SystemsGroup, the project group , shaped the role of middle managers in this extremely male-dominated "high-tech" division.[3] The expertise of the project group, its collaboration as a team, and the labor market position of its members explain project-group autonomy and the subsequent demands placed on middle managers. These factors also cast light on managers' oppositions to arbitrarily defined management techniques.

Each project group consisted of a project manager (first-line management) and four to ten programmers and systems analysts (associate systems engineers, systems engineers, advisory systems engineers, and senior consultants) who analyzed user needs, conceptualized how those information or technological needs could be met, and executed the project collectively.

These projects operated in cycles with lives of three months to three years. A group developed new products and services and maintained or modified them. Projects were undertaken at the request of users throughout the bank; requests numbered in the hundreds each year. First-level or project managers were both co-workers and supervisors, conferring with systems people about the distribution of the various pieces of the entire project. They loosely supervised the group's activities in close conjunction with group members themselves, performed technical work on the project, and evaluated each group member, writing their performance plans and recommending promotions and raises.

Group systems managers (second-level or middle managers) managed from two to six of these group projects, directly supervising each group's project manager. The cyclical and variable aspects of project life meant that middle managers managed several projects at different stages of a cycle: as one project ended another could be in its beginning or middle stage. Middle managers acted as a liaison between the project group (the vendor) and the future product user. These managers also had to approve project managers' recommendations on raises, promotions, and firings before the recommendations were sent to human resources and divisional-level management for final authorization.

The project group exercised a good deal of control over their own pace and product. Through group consultation, and with one member acting as group leader to work closely with first-level managers-usually a senior programming consultant (Kraft calls this group hierarchy the "Chief Programmer Team" [1977, pp. 59–60])-the group designed the pieces of the project, determined appropriate staffing needs, and adjusted the distribution of the work project among themselves.

For these reasons project and group systems managers regularly reported that their role in setting quotas for those they managed was minimal. As Frank Cosgrove, a group systems manager, commented, the groups he managed consisted of "professionals who don't really need to be stretched," because they collectively designed the project, building into it individual objectives. Its collective nature was really a check on each and every member involved. Rhonda, a project manager, pointed out that her project members collectively generated and agreed on the objectives that would be written into their PPCEs. As first-line manager her job was to coordinate the project, working on it directly and coordinating its output with that of the other groups reporting to her group systems manager.

That autonomy also gave project groups room to reject demands for work intensification and speed-up. Rhonda was understaffed by two people, one employee on leave and one recently promoted. Rhonda and her manager had had difficulty hiring the additional NOMAD programmers she needed for her group.[4] With a new manager several levels above her pressuring her unit, not only for more reports, but for reports that stratified statistical information in new and more complex ways (with different time and function parameters), Rhonda's manager had to negotiate between the four project managers he managed and management above him. Using information she generated about her own group's current project and skills, Rhonda assigned priorities to work at hand, with the assistance of the project's group leader, and gave her manager a list of what they could and could not finish. He then had to negotiate upward with divisional-level management about not increasing the production of reports.

The autonomy of these nonmanagerial systems analysts and programmers was further enhanced by their comparatively strong labor market positions. Middle-level managers continually acknowledged the constraints they felt when dealing with systems employees. The fact that engineers, programmers, and systems analysts had many alternatives to employment at American Security Bank gave them another degree of leverage against centralization and rationalization. Perhaps these were the features of SystemsGroup employees-the relative autonomy, the critical role of their projects, and their advantaged labor market position-that provoked Jeremy Downs, the manager of staffing within the human resources function, to comment, "'Manager' is a misleading term. People think that managers control employees. Employees really control managers and employees can wreak havoc on a department through sabotage."

The team-project basis of production, the specialized expertise of programmers and systems people, and their labor market position all explain a high degree of autonomy and leverage on the line in SystemsGroup.[5] Kraft (1977, chap. 4) and Greenbaum (1979, pp. 116–127) confirm this analysis of group autonomy and the consequent dependence of management on group expertise. Whalley argues that this autonomy creates a fundamental tension between technical staff and capital-accumulation processes. Technical professionals "possess knowledge critical to technological development," but at the same time this knowledge "has to be harnessed to profitable production" (Whalley 1986, p. 223). Dependence on technical workers' knowledge poses an ongoing uncertainty in employers' control over the labor process. The expanding organizational environment, a result of strategic management's commitment to developing the bank's technological competitiveness, also explains a lack of pressure to rationalize work processes.[6]

Although SystemsGroup fared well compared with the branch system in the overall division of labor of the bank, it was not immune to the influences of contraction and cutting common to other sectors of the bank. An important point through which strategic management attempted to exert control over the wage package was the enforcement of the new management methodologies. In contrast to the employees in the comparatively defenseless branch system, computer operations employees possessed a significant degree of autonomy and bargaining power on the line (not in the sense of the formal bargaining power held by unionized workers, but in the sense of labor market leverage) that shaped SystemsGroup managers' responses to the new corporate agenda.

Playing with the Ranking Rules

One of the principal ways of managing the division's wage bill was to monitor salary increases and promotions by enforcing the ranking scheme. And in this task area group managers were not only subject to constraints but were also the agents of the new climate of austerity and centralization. In SystemsGroup, divisional-level management and human resources compensation personnel were pushing managers to use the ranking procedure as a tool for keeping salaries within guidelines and for managing out project-group employees at the lower end of a normal curve.

The group systems, or middle manager, was therefore at a pressure point between project groups and their output, on the one hand, and strategic management's new restructuring agenda with its potentially disruptive micro-level management techniques, on the other. Managers at the group systems level negotiated between project managers and corporate policies transmitted by the human resources staff.

Project managers pressured group systems managers against using strict ranking curves to evaluate and compensate employees. They felt that reasonably high rankings and eventual merit increases, which depended on high rankings, were critical for sustaining commitment to and integrity of the ongoing research or development project. The allegedly meritocratic purposes to which ranking (on a normal curve) was applied would, in project managers' opinions, have the opposite effect. The ranking system could not take account of important but often unmeasurable distinctions and hierarchies that were a natural "property" of these programming groups.

Project managers met quarterly with their group systems manager to participate in the process of ranking SystemsGroup employees. Group systems and project managers described the lengthy, acrimonious meetings in which project managers argued to maintain relatively high rankings for their project workers. The difficulties were confounded by the fact that ranking was not applied only to one project group; all employees of the groups that one middle-level systems manager managed were merged and ranked together in one pool. Group systems managers could end by ranking dozens of employees into a bell curve if all their project-group members were consolidated.

That was one of the disruptive consequences of leaving gaps at the group-systems-management level. When more project managers were lumped under the jurisdiction of fewer group systems managers, the conflicts between different projects to be ranked increased exponentially. A wider span of control for managers intensified the politics of downsizing and contraction, which were the antecedents of ranking procedures.

One by one, each employee was ranked within his or her grade after group discussion and comparison. An employee's status might be clear, but frequently it was not; that employee would become the subject of further evaluation.[7] Stuart Milton described the process:

I meet with the other project managers and our boss. I don't even know all the other people. It's very hard to rank; the jobs in each project group are real different.

 

The problem is in the merging process: each manager tends to fight for their people. The second level manager has to act as a referee and come up with an equitable distribution. For pay raises or promotions, ranking makes a big difference and the bottom 15 percent are theoretically supposed to be managed out.

Hugh MacDonald's description of the merging and ranking procedure as being "like comparing apples and oranges" aptly summarized the difficulty, for both project and group systems managers, in finding adequate bases of comparison for project employees.

Another set of concerns shaped group systems managers' actions in those situations. Because they were to contain the total wage package, group managers were under pressure to get project managers to downrank or depress the mobility of their employees. Divisional-level management was evaluating middle managers on their ability, in one group manager's words, to "slow down the process of advancing people's salaries," referring not only to total dollar amounts but to numbers of promotions.

Ben Maxwell, who managed three project groups, reflected on strategic management's intentions behind the emphasis on merging and ranking. He argued that

Top management has been telling us that we're over-bloated with "unnecessary" employees, that some people don't belong here in the bank anymore. They want to force the issue by getting employees to perform better or to leave the bank. They're trying to do this by getting us to whack at the bottom of our people. So they make us throw all our people into one big pool and rank them with their peers.

Group systems managers, then, had to steer the course between two opposing forces within SystemsGroup. They were pressured from the upper ranks of the division to pull wage costs into line using methods that reduced project managers' room for maneuvering and controlling project groups; methods for determining compensation that gave little credit to the particular work processes, assignments, and efforts of the many different project groups. And from below, they faced project managers' opposition to the ranking procedures of the new regime of austerity.

The opposition to ranking was a result not of innate managerial goodwill but of managers' awareness of the everpresent opportunities for mobility available to programmers and systems analysts. Why should programmers and analysts stick around when they were assured of higher salaries and regular promotions at other companies? That situation, in managers' eyes, limited their ability to use arbitrary management methods. In other words, ranking strictly on a normal curve had potentially severe consequences when it came to sustaining employees' willingness to stick with projects and the bank itself.

There was yet another way in which the new climate of decreased mobility shaped the struggle over ranking. The compensation personnel encouraged group managers to substitute one-time-only "excellence awards" for permanent wage increases or promotions. These awards had been instituted by Wedgewood as part of the new "pay-for-performance" ethic. Generous financial awards were periodically given to employees who had made significant progress in their jobs, who formulated cost-saving reorganization ideas, or who were consistently top performers.

Excellence awards could be an important motivator and indeed were viewed by nonmanagerial employees as desirable and prestigious. Project managers agreed that the awards were useful as motivators, but they also felt that in some cases the emphasis on distributing one-time-only awards was an attempt to displace the more fundamental and enduring incentive of an increased wage package. The award was an attempt to placate employees, to offset the absence of the regular and significant compensation of wage increases and job mobility.

Thus during the ranking process managers were often in the position of bargaining against the relatively cosmetic performance award and for an improved position on the ranking list. As one project manager commented, the "performance award throws good money after a bad idea" rather than encouraging long-term outstanding work performance.

The tension in the process led group systems managers to organize an activity in which managers circumvented ranking by "playing games with the ranking numbers" and "marketing promotions." In this activity middle managers stayed within the terrain of austerity, but they reworked it in such a way that they did not force a crisis of control and consent in the production environment of SystemsGroup. Reranking games allowed middle managers to maximize the possibilities for ongoing consent to SystemsGroup goals and to juggle the competing and often contradictory demands facing them. Middle managers also protected their managerial jurisdiction by employing "management judgment," which emerged as an active ideological ingredient in strategic management's corporate culture recipe.

Playing with the ranking numbers involved two levels of activity. After determining where employees currently fell on a normal curve, group systems and project managers evaluated the previous ranking session: Who received what raises, promotions, and positions on the curve? Past positions on the curve were then weighed against present positions. Case by case, managers would redistribute employees along the curve: for example, they would shift to a higher position employees who technically were not eligible for a pay increase because of a lower position on the ranked curve but whom managers felt should receive a motivational pay increase. This maneuver entailed depressing the position of others who had received pay increases at the last evaluation session. Managers thus ranked down valuable employees, but not far enough to penalize them.

Reranking served not only to motivate employees who failed to come in at the top of the curve but also to upgrade employees, so that they were not continually categorized as poor performers. If an employee fell on the bottom 15 percent of the curve in the current evaluation period but had a higher position on the curve in the last period, managers used the positive indicator from past work performance as leverage for not managing the employee out.

By playing with the ranking rules, managers shifted employees across evaluation periods and across project groups to achieve a more equitable distribution of raises and promotions. The reranking game protected project managers from having to manage out those in a disadvantaged position on the normal curve. It was based on intense negotiations between first and second levels of management to bring the ranking system into line with the practical constraints of SystemsGroup production.

Reranking, then, allowed middle managers more room for maneuvering with project group managers; within the steadily rationalizing terrain of their jobs, they conformed to the new rules for controlling wage costs. Moreover, acting on the logic of maintaining commitments to productivity and output, middle managers refrained from shortsighted disciplinary action that would, in their eyes, have irreparable long-term costs and consequences.

In the systematic reranking process, group systems managers were working against the newly constructed and comparatively arbitrary definition of poor performers. The normalizing tool of the curve meant that any manager would always, in all circumstances, have employees who should technically be managed out. Reranking allowed managers to re-create the record on employee performance to avoid managing out.

Reranking clearly had its own set of tensions. For one thing, it often had the effect of playing project managers off one another. The ascendancy of one project manager's employee was obviously purchased with the demotion of another manager's employee. In addition, the criteria for redistributing people along the curve were frequently subjective and murky, requiring extensive discussions of dynamics and qualifications that were highly unique to individual groups. Ben Maxwell claimed:

It often boils down to what managers can argue more persuasively. It hits an area of real subjectivity for managers and forces managers to deal very intensely with each and every employee, and with their peer and super-ordinate managers. But at the same time we really have to fight because ranking feeds into the reward process.

Group systems managers ran into further conflict with their managers. Frank Cosgrove had to convince his superior that particular employees were critical in project groups even if they had been ranked down. Ranking down could not become the basis for future downranking; the curve became something to guard and justify, to manipulate at the next evaluation session. Frank felt that it was the responsibility of the division manager to figure out why ranking procedures might be out of line-why no real norm had emerged from this supposedly standardized process. About his manager's reaction to the ranking sessions, Frank said, "My manager has to convince senior managers that all people are key even if they are ranked down. We all know there is a formal and an informal organization, and the senior people have to respect the limitations of our informal organization. At my level (the group systems level) complaints trickle up."

Lynn Yee went further in defending her prerogative in the ranking process. When challenged by her manager on the way she ranked her two project groups, Lynn defended her decision-making processes and insisted that he spend some time with the project groups to acquire a fuller sense of group work, project members' contributions to it, and the problems of punitive ranking in that context. She wanted him to have to confront the consequences of the ranking procedure for her employees.

Playing with the rules of ranking was a reaction against the potentially demoralizing effects of the ranking system. It is important to note that group managers were able to foster this activity because no one was challenging the ranking process in a more systematic way. Playing games with ranking served the ultimate purpose of legitimating the new regime of diminishing mobility and salary opportunities. Group and project managers' collaboration in alternating the employees who would receive raises forced them to justify and preserve the new, allegedly meritorious, arrangement.

Group managers actually used the ranking curve as a source of control over project managers, inducing their participation in reranking by suggesting the threat of a worse outcome if project managers did not go along with the game. Implicitly, if project managers refused to play, the consequences for their employees could be severe. In turn, project managers' consent to this "strategy of control" stemmed from the fact that group systems managers protected the project manager and the project group whose existence was the lifeblood of the project manager. By organizing ranking games, group systems managers created an uneasy web of interdependence between themselves and their project groups.

Because the production processes of SystemsGroup were not characterized by a systematic and extensive course of centralization and rationalization (compared with the branch system), and because of the critical function of SystemsGroup in the reconfiguration of American Security Bank, group systems managers possessed more latitude for maneuvering against the rigid implementation of new management methodologies. Group systems managers were in a better position to negotiate the employment conditions of employees whose turnover would have great costs to project life and thus to the mission of the division.

That relative autonomy may explain the nature of efforts to control middle management in this sector. Whereas in the branch system the middle management position was in the process of being eliminated, in SystemsGroup the effort to restructure management was more fragmented. It did not dismantle the middle managerial position; rather it aimed to circumscribe the autonomy of certain aspects of middle managers' jobs.

In a very different production setting, examined in the next chapter, middle-level managers were actually extended greater discretion to conduct and carry out the operations of their division. The middle managers in American Security's credit card division used this discretion not only to defend their managerial prerogatives but to redefine new productivity objectives.

to previous section to next section