Microdynamics of Mirroring Hypothesis : When and How Organizational Structure Mirrors Product Architecture Mahdi Ebrahim, Arnaldo Camuffo Bocconi

Transcription

1 Microdynamics of Mirroring Hypothesis : When and How Organizational Structure Mirrors Product Architecture Mahdi Ebrahim, Arnaldo Camuffo Bocconi University Introduction The organization literature arguably maintains that product architecture and organizational structure (should) mirror each other. For example, a modular product with loosely coupled components are usually developed by isolated teams (or individuals). Similarly, an integral product whose constituent components are tightly interdependent are made by collaborative teams extensively communicate with one another to ensure that the developed interdependent elements work well in tandem. Nonetheless, recent studies demonstrate cases of non-mirroring in which products with highly interdependent components are developed by disconnected teams. The extant literature implies that non-mirroring might reduce the quality of the produced product, harm customers satisfaction, and eventually, undermine firm s competitive advantage. Nonetheless, the potential determinants and underlying mechanisms that lead to such irregular observations are relatively undertheorized and empirically understudied. Thus, we first hypothesize about possible sources of non-mirroring, as rooted in the organizational setting, the product architecture, and temporal dynamics of developing a new complex product. Later, to test the hypotheses we investigate our unique micro-level dataset. Our findings contribute to organization design literature by identifying dynamic contingencies of mirroring hypothesis. More generally, leveraging on our detailed dataset, we advance the debate on organizing for innovative activities in knowledge-intensive contexts. Theory & Hypotheses The mirroring hypothesis posits that a technological system and the organizational system in charge of designing it should have similar architectural properties, such as degree of modularity, and that these architectural properties should co-vary. When two product components are dependent on each other, any change in one of them during the development process affects the functioning of the other dependent component. Therefore, during the development process the two teams (or corresponding individuals) should communicate with each other to share the necessary information about the interfaces between the two components, when trying to standardize the interfaces. Moreover, the design and development process of dependent components requires lots of rework and iterations of design efforts until the two components function well with each other. Nonetheless, some recent studies have reported cases wherein contributors with none (or few) observable organizational ties make highly interdependent contributions to the design of a single technical system or sub-system (Colfer and Baldwin, 2016). At micro level, technical dependencies located across product modules are designed and accounted for by independent teams (or individuals) whose jobs or units are not organizationally interdependent. Therefore, Colfer and Baldwin s (2016) suggest that conventional views on mirroring tend to be simplistic and general, as evident also in other empirical studies spanning a range of different industries. The fact that reemphasize the need for a more nuanced theory of mirroring. It also calls for a more contingent view of the mirroring hypothesis, to examine the conditions under which it holds or fails, as well as for a better understanding of its dynamic evolution beyond current static cross-sectional studies of the phenomenon. Following these suggestions, we propose a new perspective of mirroring hypothesis that highlights task, space and time contingencies of the phenomenon. 1

2 1. Innovative nature of the tasks: the process of developing a complex product involves creating new features and incorporating new functionalities to address continuously growing demands in the market. Creating new features essentially entails generating new pieces of knowledge; a process replete with continuous experimentations of various architectural configurations. This process usually includes ex-ante planning and active supervision of manager, as well as, diligent engagement of developers in collaboration and communication to share newly developed knowledge and update cohorts to recent changes of product architecture in a real-time fashion. èh1: while performing interdependent tasks across modules, knowledge workers are more likely to collaborate accordingly when the task entails knowledge generation, rather than knowledge refinement. 2. Knowledge workers Proximity: it is well evident that physical proximity of employees facilitates the communication between colleagues, helping them to better manage their collaborations. The proximity reduces costs of search within the organization for the right colleague to contact and establish task-specific ties. Moreover, by providing more opportunities for meetings and informal chats, physical closeness helps developing a shared understanding of the product architecture, which in turn, facilitates organizing tasks through tacit coordination. èh2: while performing interdependent tasks across modules, physically proximate knowledge workers are more likely to collaborate with the corresponding colleagues. 3. Temporal Dynamics of Mirroring Hypothesis: as time passes over the development phase and upon the completion of adding new features, the product architecture has reached its maximum complexity, encompassing highest number of design components and interdependencies between them. Hence, at this stage of the development, more than ever, the bounded-rational developers struggle to accurately anticipate the propagation of modifications and changes to unintended parts of the product. The number of dependencies to be checked are numerous, the time pressure is most intense as the deadline to release the new version is approaching, and the workload is highest since many problems that emerged throughout the development process were left to be addressed later during the development phase. èh3: while performing interdependent tasks across modules, earlier during the development process knowledge workers are more likely to collaborate with the corresponding colleagues. Methodology The research setting is a software development division of an HVAC technology premium supplier. The software studied is a plant supervision package, an integrated control solution that improves energy savings in HVAC systems. In 2015, the company reported a revenue of 250 million euros with a 15% EBITDA margin, and is planning to go public soon. Our dataset captures the development of an enterprise software, going through 13 versions, over 60 months, and produced by 21 developers overall. It is composed of: 1) software architecture data, i.e. a network of dependencies (nodes = files, ties = technical dependencies between files). 2) organizational architecture data, including records of tasks performed, i.e. who (software developer), what (files), when (weekly data), by which we constructed collaboration network of developers. The quantitative data is corroborated by our field visits, interviews, and direct observation. Measures: DV: Non-mirroring: Whether both files (of the same dependency) undergo simultaneous change (=0), or not (=1), conditional upon belonging to different modules, defined according to the Louvain method. IVs: 1. Innovative nature of the development task: Adding features (creating new files =1) vs. Debugging (modifying existing files =0) 2

3 2. Knowledge workers physical proximity: Located in the company offices (=0) vs. working from outside of the company (=1) 3. Development Maturity Stage: number of weeks since the beginning of development work at which the focal file is created or modified. Controls: 1. Knowledge workers job roles: Developers (i.e. junior and senior developers, OS developers, and testers=0) vs. managerial positions (architects, consultants, and project leaders=1) 2. Knowledge workers type of contract: Being an employee of the company (=0) vs. an outsourcer (=1) 3. File level controls: number of lines, internal complexity, and total dependencies of a given file. Findings The results support our hypotheses. These findings are robust to different model specifications (Probit models, developer s fixed effects, version s fixed effects, and 2-stage Heckman selection model based on product components complexity), various subsamples, and alternative operationalization of dependent variable (different time windows). Tables in the appendix reports the results. We also benefitted from an exogenous shock to the product design after version 1.5 that divided the development of software into two parallel branches (2.X versions, as treated by the shock and 1.X versions, as control group), which provides us with a quasi-experimental research design. Three various treatment test models support our previous finding and address some of the endogeneity issues. Moreover, to better understand the mechanims that drive non-mirroring and to testify alternative explanation suggested by existing research, we have examined the interaction effects of innovative nature of the tasks. Appendices Table 1. Logistic regression results for probability of non-mirroring as explained by main hypotheses (1) (2) (3) (4) (5) Innovative Nature of the Task *** *** *** (modifying vs. creating files) (0.10) (0.10) (0.10) Maturity of Development Phase 0.071*** 0.077*** 0.062*** (# of weeks from kick-off day) (0.01) (0.01) (0.01) Developer s Proximity 0.512* 0.673* 0.734** 1.101*** (Located in company s offices vs. out of the company) (0.25) (0.26) (0.26) (0.33) Developer s Job Roles *** *** *** *** (Developers vs. Managers) (0.09) (0.10) (0.11) (0.11) Developer s Type of Work Contract *** *** *** *** (Employees vs. Outsourcers) (0.23) (0.24) (0.25) (0.25) Lines of Codes [divided by 100] *** *** 3.707** 3.231* 5.349*** (1.04) (1.16) (1.27) (1.29) (1.28) Hygiene of codes [reversely coded] 0.589*** 0.363*** 0.225*** 0.190*** (0.03) (0.04) (0.04) (0.04) (0.04) Strength of dependency Total # of dependencies of focal file *** 0.000*** 0.001*** 0.001*** 0.001*** Inverse Mill s Ratio *** - (0.18) Version s Fixed Effects N N N N Y Intercept 0.989*** 3.811*** 4.831*** 4.138*** 4.675*** 3

4 (0.04) (0.09) (0.14) (0.25) (0.15) Wald Chi *** *** *** *** *** Log pseudo-likelihood Pseudo R Number of obs Table 2. Logistic Regression Results for interaction Effect of Innovative Nature of the Tasks (1) (2) (3) (4) (5) Innovative Nature of the Task *** *** *** *** (modifying vs. creating files) (0.13) (0.15) (0.11) (0.22) Maturity of Development Phase 0.019*** 0.065*** 0.070*** 0.023*** (# of weeks from kick-off day) (0.01) (0.01) (0.01) (0.01) Developer s Type of Work Contract *** *** *** ** (Employees vs. Outsourcers) (0.16) (0.15) (0.19) (0.19) Innovative Nature of the Task 0.196*** 0.121*** Maturity of Development Phase (0.02) (0.02) Innovative Nature of the Task *** *** Developer s Job Role (0.22) (0.26) Innovative Nature of the Task 0.842** * Developer s Type of Work Contract (0.27) (0.31) Developer s Job Role *** *** *** *** (Developers vs. Managers) (0.13) (0.20) (0.10) (0.20) Lines of Codes [divided by 100] *** 4.270*** 4.338*** 3.842** 4.456*** (1.04) (1.26) (1.26) (1.26) (1.26) Hygiene of codes [reversely coded] 0.589*** 0.189*** 0.214*** 0.222*** 0.197*** (0.03) (0.04) (0.04) (0.04) (0.04) Strength of dependency * Total # of dependencies of focal file *** 0.001*** 0.001*** 0.001*** 0.001*** Intercept 0.989*** 4.825*** 3.906*** 4.944*** 4.237*** (0.04) (0.15) (0.14) (0.14) (0.16) Wald Chi *** *** *** *** *** Log pseudo-likelihood Pseudo R Number of obs Table 3. Logistic Regression Results for interaction Effect of Temporal Dynamics (1) (2) (3) (4) Innovative Nature of the Task *** *** *** (modifying vs. creating files) (0.11) (0.10) (0.14) Maturity of Development Phase 0.026*** 0.107*** 0.024* (# of weeks from kick-off day) (0.01) (0.01) (0.01) Developer s Job Role *** *** *** (Developers vs. Managers) (0.11) (0.11) (0.17) Developer s Type of Work Contract *** * *** (Employees vs. Outsourcers) (0.15) (0.20) (0.21) Maturity of Development Phase 0.125*** 0.033* Developer s Job Role (0.02) (0.02) Maturity of Development Phase *** Developer s Type of Work Contract (0.01) (0.01) Maturity of Development Phase 0.169*** Innovative Nature of the Task (0.02) 4

5 Lines of Codes [divided by 100] *** 4.136** 3.667** 4.296*** (1.04) (1.27) (1.27) (1.27) Hygiene of codes [reversely coded] 0.589*** 0.197*** 0.209*** 0.181*** (0.03) (0.04) (0.04) (0.04) Strength of dependency (0.00) (0.00) (0.00) (0.00) Total # of dependencies of focal file *** 0.001*** 0.001*** 0.001*** (0.00) (0.00) (0.00) (0.00) Intercept 0.989*** 5.025*** 4.498*** 4.760*** (0.04) (0.14) (0.15) (0.17) Wald Chi *** *** *** *** Log pseudo-likelihood Pseudo R Number of obs Table 4. Heckman 2-stage selection model estimations (1st stage: being selected for change, 2nd stage: Probability of non-mirroring) 2 nd stage dependent variables: Probability of non-mirroring (1) (2) (3) (4) (5) (6) Innovative Nature of the Task *** *** *** *** *** *** (modifying vs. creating files) ( ) ( ) ( ) ( ) ( ) ( ) Maturity of Development Phase *** *** *** *** *** *** (# of weeks from kick-off day) ( ) ( ) ( ) ( ) ( ) ( ) Developer s Type of Work Contract *** *** *** *** *** *** (Employees vs. Outsourcers) ( ) ( ) ( ) ( ) ( ) ( ) Developer s Proximity (Located in company s offices vs. out of the ( ) ( ) ( ) ( ) ( ) ( ) company) Developer s Job Role *** *** *** *** *** *** (Developers vs. Managers) ( ) ( ) ( ) ( ) ( ) ( ) Lines of Codes [divided by 100] *** *** *** *** *** *** ( ) ( ) ( ) ( ) ( ) ( ) Hygiene of codes [reversely coded] *** *** *** *** *** *** ( ) ( ) ( ) ( ) ( ) ( ) Strength of dependency -5.69e e ( ) ( ) ( ) ( ) ( ) ( ) Total # of dependencies of focal file *** *** *** *** *** *** (3.95e-06) (5.09e-06) (3.96e-06) (4.30e-06) (4.52e-06) (4.94e-06) Intercept *** *** *** *** *** *** ( ) ( ) ( ) ( ) ( ) ( ) 1 st stage selection variable: being changed (or created) Control *** *** *** *** ( ) ( ) ( ) ( ) Shared *** *** *** ( ) ( ) ( ) ( ) Core *** *** *** ( ) ( ) ( ) ( ) Strength of dependency * *** ( ) ( ) Total # of dependencies of focal file *** *** ( ) ( ) Lines of Codes [divided by 100] *** ( ) Hygiene of codes [reversely coded].17764*** ( ) Intercept *** *** *** *** *** *** ( ) ( ) ( ) ( ) ( ) (.01118) Mills Lambda ** *** *** *** *** *** 5

6 ( ) ( ) ( ) ( ) ( ) ( ) Wald Chi Number of obs Table 5. Logistic regression results for treatment effect (versions 2.X are affected by exogenous shock to design) (1) (2) (3) (4) Treated *** 2.378*** *** *** 2.155*** (2.X versions, after the exogenous shock) (0.20) (0.21) (0.17) (0.16) (0.28) Innovative Nature of the Task *** *** *** *** *** (modifying vs. creating files) (0.14) (0.11) (0.10) (0.10) (0.16) Maturity of Development Phase 0.079*** 0.582*** 0.073*** 0.087*** 0.596*** (# of weeks from kick-off day) (0.01) (0.03) (0.01) (0.01) (0.03) Developer s Proximity 1.461*** 1.301*** 1.629*** 2.431*** - (Located in company s offices vs. out of the company) (0.30) (0.29) (0.31) (0.54) Developer s Type of Work Contract *** *** *** *** *** (Employees vs. Outsourcers) (0.25) (0.25) (0.25) (0.27) (0.29) Developer s Architectural Knowledge *** *** *** *** *** (Developers vs. Managers) (0.10) (0.15) (0.12) (0.10) (0.17) Treated 1.710*** 0.810** Innovative Nature of the Task (0.24) (0.25) Treated *** 0.031*** Maturity of Development Phase (0.03) (0.01) Treated 1.275*** *** Developer s Architectural Knowledge (0.31) (0.26) Treated * ** Developer s Type of Work Contract (0.58) (0.54) Treated Innovative Nature of the Task (0.54) Lines of Codes [divided by 100] 4.277*** 6.291*** 4.239*** 4.127** 6.258*** (1.26) (1.26) (1.25) (1.26) (1.26) Hygiene of codes [reversely coded] 0.217*** 0.098* 0.237*** 0.230*** 0.093* (0.04) (0.04) (0.04) (0.04) (0.04) Strength of dependency Total # of dependencies of focal file 0.001*** 0.001*** 0.001*** 0.001*** 0.001*** Intercept 5.480*** 1.763*** 5.173*** 4.929*** 1.873*** (0.17) (0.19) (0.15) (0.14) (0.22) Wald Chi *** *** *** *** *** Log pseudo-likelihood Pseudo R Number of obs

7 References Brusoni, S., & Prencipe, A Managing Knowledge in Loosely Coupled Networks: Exploring the Links Between Product and Knowledge Dynamics. Journal of Management Studies, 38(7): Brusoni, S., & Prencipe, A Unpacking the black box of modularity: technologies, products and organizations. Industrial and Corporate Change, 10(1): Brusoni, S., & Prencipe, A Patterns of modularization: The dynamics of product architecture in complex systems. European Management Review, 8: Colfer, L., & Baldwin, C The Mirroring Hypothesis: Theory, Evidence and Exceptions. Harvard Business School working papers. Gokpinar, B., Hopp, W. J., & Iravani, S. M. R The impact of misalignment of organizational structure and product architecture on quality in complex product development. Management Science, 56(3): Hoetker, G Do modular products lead to modular organizations? Strategic Management Journal, 27(6): MacCormack, A., Baldwin, C., & Rusnak, J Exploring the duality between product and organizational architectures: A test of the mirroring hypothesis. Research Policy, 41(8): MacCormack, A., Rusnak, J., & Baldwin, C. Y Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. Management Science, 52(7): Sanchez, R., & Mahoney, J. T Modularity, flexibility and knowledge management in product and organization design. Strategic Management Journal, 17(SI): Sosa, M. E., Eppinger, S. D., & Rowles, C. M The Misalignment of Product Architecture and Organizational Structure in Complex Product Development. Management Science, 50(12): Srikanth, K., & Puranam, P Integrating distributed work: Comparing task design, communication, and tacit coordination mechanisms. Strategic Management Journal, 32(February): Staudenmayer, N., Tripsas, M., & Tucci, C. L Interfirm Modularity and Its Implications for Product Development. Journal of Product Innovation Management, 22(4): von Hippel, E Task partitioning: An innovation process variable. Research Policy. 7