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.
