Emergent values conflicts in formal process for managing innovation:
Organizational obstacles and affordances for design practice

Peter H. Jones, Ph.D., The Union Institute, Cincinnati, Ohio

Introduction

Innovation processes and work practices comprise numerous activities contributing to a organization’s workplace culture. Any organizational process embraces long-term commitments,  locking-in enduring approaches, values, roles, and communication styles from organizational choices, and perpetuating these approaches and values. These processes survive management change programs, reorganizations, and specific work practice changes, and manifest an organization’s values in-use in their persistence. In the large technology organizations studied, organizational history of innovation processes maintained inherent values that obstructed effective product innovation and prevented organizational learning that might improve process.

Poring through dozens of case studies and interviewing insightful participants, a story emerged of deep conflicts between individual and organizational values systems on product design teams. Further inquiry revealed these conflicts emerged as embedded in work processes for projects and product management. These processes institutionalized implicit organizational behaviors and  power roles (such as desired practices of influential actors). The implicit control of work tasks is a well-known management procedure, but instead of rote work we find these values affecting advanced intellectual practice for product design and management. While software engineers may resist being told specifically how to do their jobs, their organizational cultures maintain embedded policy through defining and controlling design and development process. By disregarding balanced participation, such processes can embrace unilateral control, manifesting in conflict with personal values and further diminishing participation.

In discussing why groupware fails to improve organizations, Zuboff (1996) explained, “the status quo eats up innovation and makes hierarchy reflected in its systems.” This research locates the affordances, or opportunities, for power and participation in organizational innovation management. It attempts to show how the hierarchy “eats up innovation” through interpreting the research stories of software projects and organizations.

Interpretive Analysis Method

To reveal the dynamics of embedded values in organizational innovation processes, we used a research method based on grounded theory case analyses, cross-case analysis, and hermeneutic interpretation. Focusing on the organization, hermeneutic interpretation informed understanding of how organizational patterns embody values and meaning in official processes, implicit social routines, and community practices.

The total body of research drew from 10 project cases, analyzed in the first phase of research, and hermeneutic analysis of the two firms contributing to the primary project research. The hermeneutic interpretations were based on 5 in-depth interviews specifically on organizational process and the transcripts from the 10 project values interviews. This approach to hermeneutic content analysis reviewed each interview for the participant’s unique voice and situation. Each of the 10 project cases were initially considered separately, and evaluated with respect to their context and experience of organizational processes. After this case analysis, claims from across the sources were clustered by theme. The analysis drew repeated themes and similar meanings from the voices, and organized them into a qualitative description for each of the organizations.

Table 1 identifies 6 types of sanctioned organizational processes discovered in the cases deployed for managing product innovation.

Table 1. Organizational innovation process types.

 The hermeneutic critique surfaced 16 unique organizational patterns found across the cases. Table 2 defines the patterns for the two case companies identified as Data Online and Autoline Data, both large information product companies, but offering substantially different products and serving dissimilar customers. Two identical categories surfaced between the two organizations, suggesting at least two themes shared between these firms.

Data Online supported 6 formal innovation processes simultaneously during the research period, all of which followed by constituents to varying degrees of fidelity. Autoline sanctioned 4 formal organizational processes for innovation, yet constituents in this firm followed their procedures faithfully, in a “cookbook” fashion. Both companies exhibited very different organizational cultures; yet both showed standard organizational processes as mechanisms for maintaining role authority and organizational values in-use.

 

Table 2. Organizational patterns for two software organizations.

Each of these patterns represents multiple occurrences of behaviors and conditions within the organization affecting product innovation. From the empirical data of the events and behaviors from the two respective organizations, these categories induced claims reflecting the pattern’s behavior. However, as theoretical instruments, these categories also enable deductive analysis on other organizations – they point to key processes underlying the dynamics of power and participation in organizational cultures.

Cross-case analysis between the firms’ innovation processes reveal how the same pattern manifests their cultural differences. Cultural integration of organizational processes embraces the issues of integrating new product or innovation management practices into the current organizational culture and values systems. This category was constituted from several claims and stories revealing the problems in cultural integration. Participants from both firms described how ignoring organizational context resulted in disuse of even well-designed processes. However, the differences reveal issues of some complexity in the organizations.

Product development organizations allow product managers substantial authority to make decisions on behalf of large-scale projects. At the same time, product managers typically recognize no “professional practice” endorsed as a discipline across the industry, as found with product designers and software engineers. Given this imbalance of authority and process guidance, organizations benefit by instituting product design and innovation management processes that all accountable staff and roles can adopt. The integration of such practices into a prevailing culture presents a politically challenging organizational design effort – the resulting practices require appropriate authority for widespread acceptance and a minimal learning and adoption rate to ensure use by multiple projects of varying skills.

Interpretations of the same pattern for the two firms are summarized briefly.

·        Practice integration - One specific case illustrates the culture’s difficulty with integrating new practices. Data Online attempted to both redesign an existing Internet product and to improve its design practices using a well-known Web design firm. However, few of the practices learned were actually retained by the design team’s process; some methods were selected and modified, but an overall integrated approach was not defined.

·        Affordance for customer access and knowledge - Knowledge of product domains also emerged as a cultural integration issue. The ability to ask questions (and being allowed to ask the questions) was seen as something afforded or disallowable by this organization’s culture. For product managers, designers and even engineers, customers and users represented the most important constituencies of domain inquiry. Access to customers for demonstration of product concepts, obtaining user feedback, and testing of prototypes was limited by the organization in three distinct ways. …

·        Power in design decisions - Three defenses identified afforded the manager maintaining unilateral decision-making over the product direction – user feedback was often considered unwelcome by product managers, since it represented perhaps the sole source of information with the power to change any of their predetermined positions. The product development and management processes defined requirements and established a projects’ scope internally, based on product market position and revenue considerations. Requirements were not defined using a process drawing from customer insights, or even features suggested from actual product use.

·        Relationship to organizational affordances - Consider further the organizational implications of these interpretations. If customer inquiry was discouraged for designing a revenue generating product, what organizational affordance existed to question the culture that disallows effective inquiry? If the culture discouraged pursuit of “the right questions” due to hierarchy or political considerations, the organization could effectively stop learning about specific domains.

·        Organizational learning defenses in innovation - This organization revealed numerous situations where researchers and designers were unable to pursue the necessary questions for design; the organization seemed to block its own knowledge gathering and customer learning. Preference was given to departmental control of product-related organizational processes, and much of the research focused on internal technical capabilities, not on specified customer needs.

Cultural integration of organizational processes

Organizational assimilation of the P3 lifecycle process was supported by instructor-led training and a team of coaches available to the product teams. People initially expressed apprehension toward using the process, as developers and others without prior experience with standard procedures expressed initial discomfort. They had no skill in the recommended methods and techniques, and were concerned for the burden of adopting such a large change in daily work. P3 gradually became used as a “process infrastructure” for product management guidance. Its enculturation as a shared system enabled organizational learning – those learning the lifecycle process became better able to plan projects and predict development consequences, made more rational date estimates, and met product goals more reliably.

Other management processes were introduced in Autoline Data, with most new processes introduced in the period from 1995-1999. This period corresponded with rapid company growth, and with it came an influx of new managers from outside the culture, bringing their own practices to the organization. Some of the new managers did not assess the culture to understand how to best fit or accommodate the practices from their experience as new processes into this organization.

Initiatives generated from outside the culture failed to take hold, since the organization was not “ready.” However, readiness should be recognized as relative to the culture. An organization will never be “ready” even for simple practices if they are not adapted to the values and organizational mythologies pre-existing in the culture. To some extent, this asserts that cultural change cannot occur from outside the culture, but only from starting with the cultural values and mythologies that people identify with already. Once accepted nominally into the culture, substantially new practices can be introduced effectively. This occurred after P3 was fully adopted – several new practices, including a complex requirements methodology were integrated into P3 and used throughout the organization.

Constituting spin-off culture – separation of norms and practices

A new software product organization had been established within Autoline Data to develop a separate product line. In effect, this organization created a separate culture, abandoning all institutionalized processes from the larger organization. The product management team instituted a local, alternative product design process. Managers and analysts developed their own specific practices, many adapted from the components of other processes. Using an organic approach, they proceeded through multiple iterations (trial and error) and refrained from formalizing the practices. Instead, they were embedded in project management and design practices used as repeatable activities by intact project teams. They experimented with process variations, joined with design expertise available from local design professionals, and evolved approaches that served the requirements of their unique project.

An illustrative example of the effectiveness of their management approach was found in the project’s approach to knowledge creation. If managers felt skill in a desired discipline was necessary, instead of attempting to gain sufficient knowledge with the current staff, they strategically hired experts in the disciplines required. They then supported the newly hired expert to develop appropriate practices that fit their organization and project. Overall, their process management approach was conducted informally, but learning and knowledge were shared throughout the group officially and informally. Design and development practices were not formally codified, but a close-knit team of product analysts, designers, and software engineers effectively followed the local practices.

Observers of this approach recognized the usefulness of developing the processes more formally following a period of intensive local use by such a project team. By leveraging an organizational affordance, such as the initial product release, a process team would serve this need by integrating the practices into a codified methodology, based on learning and usage in actual product development. This bottom-up approach would result in a custom-tailored methodology with total organizational adoption from its inception. A caution drawn from the previous findings would be to maintain an informal process committee, and not to endow it with organizational authority. In hierarchically-oriented cultures, committees can grow into power bases, effectively preventing organizational learning and expertise development.

Discussion

The interpretations reveal some common dynamics between the two case organizations. These patterns suggest that product organizations with traditional processes for innovation management may be associated with dysfunctional corporate cultures. If the purpose of a software/systems product organization may be simply stated as “to design, package, and distribute effective and usable systems as products to customers,” then the interactions described in both company’s cultures inhibit much of the innovation value available within the organizations. Certainly the business of software product development is highly competitive, requiring efficient work practices and intensive labor cycles to fulfill customer demands. However, these companies exhibited institutional disregard for known practices that could improve team coordination, organizational learning, knowledge sharing about customers and product design, effective and competitive product design, and employee retention.

The same interpretations reveal significant differences between the two organizations also, leading to recommendations applicable to either case.