Abstract
Keywords
1. Introduction
Acquisition is one of the two basic strategies available to a firm seeking to grow, the other being organic growth [1]. Although it is a common growth strategy, it is often burdened by subsequent unsatisfactory performance [2–4]. One problem said to afflict growth is the management of knowledge [5], and especially the sharing of it [6–8]. This is the case although it has been argued that sharing of knowledge plays a crucial role in companies [9] and further in specific company situations, such as acquisitions [3].
Relatively few companies have successfully employed knowledge management procedures to support growth [10]. It also has been stated that there are not enough empirical studies on the challenges of knowledge sharing. While the positive issues of knowledge sharing have been quite widely studied, the challenging issues and risk factors remain less studied. [11] This remains the case despite the fact that unrestrained knowledge sharing can provide important support for acquisitioned growth. Without effective knowledge sharing the knowledge is likely to have a limited impact on the effectiveness of organization, as new knowledge combinations, learning and value creation may remain unrealized [2, 9]. Furthermore, if knowledge sharing processes are not functioning, the creation of new knowledge for future business opportunities may stagnate [12]. That makes it important to specify the barriers hindering or preventing knowledge sharing in acquisitioned growth. To that end, this study aims to determine the potentially most restrictive knowledge sharing barriers to acquisitioned growth.
Software companies are characterized as knowledge-intensive companies [13], where the role of effective knowledge sharing can be assumed to be crucial. The software business itself is also a business of rapid growth rates [13–15], and hence, offers an interesting field in which to examine knowledge sharing barriers to acquisitioned growth.
This paper should be relevant to companies with an intention to grow through acquisitions, as its findings can help prepare for the challenging task of managing growth by pre-empting knowledge sharing barriers, and perhaps offering ideas to overcome them when they are unavoidable. The paper also contributes to the literature on knowledge management by defining knowledge sharing barriers in the context of the acquisitioned growth of a software company, and to the literature on growth by touching on the issue of management of acquisitions from the perspective of knowledge management, and within it, especially knowledge sharing.
The following section presents the theoretical background of the study. In the third section, the method of data collection and analysis are explained. A case study on a software company then offers empirical evidence. Finally the paper closes with discussion and conclusion sections.
2. Theoretical background
We start by explaining the software business and the role of acquisitioned growth so as to set a context for the study. Subsequently, we review knowledge sharing barriers as they function in that context so as to prepare the ground for our empirical study.
2.1 The software business and acquisitioned growth
The software business is known as a knowledge-intensive business field. The software development and production process and also the results of the process, software and programs, are knowledge-intensive and often abstract. [13] The work is done by independent, competent and creative people [16, 17] who possess highly developed professional knowledge [18].
The software business largely drives and facilitates today's economy. The growth rate of a business is one factor that reflects its significance in the modern economy, and the rapid growth of software companies has become a typical feature of the business. The growth in the number of jobs has been far more rapid in the software business than in most other business fields. [13–15] This has also led to the emergence of larger companies in the field, which had largely been occupied by a multitude of small or medium-sized companies [19].
The software business is also portrayed as a turbulent and competitive environment [20]. That highly competitive environment is what makes it very difficult for a firm to gather and retain all the resources needed to compete effectively [21, 22]. Expanding firms therefore often face a resource gap, and one way for them to bridge it is through acquisitions, that can offer rapid access to new knowledge and resources [2, 23].
Acquisitions and organic growth are stated to be the two fundamental growth options for firms [1, 2]. As the name suggests, acquisitioned growth entails generating growth by acquiring an existing company: by acquiring external resources [1, 2, 4]. Hence, acquisitions simultaneously bring a company new personnel, new products and services, new processes etc. This will typically lead to a large-scale growth of resources and knowledge, which also often increases diversity [4, 24], reshapes the resource and knowledge base of a company [25], and leads to the enrichment of knowledge base and learning, and also to the rigidities and routines of the company being broken down [2, 23]. Consequently, a firm typically also absorbs new non-path dependent resources [24].
Success is, however, dependent on the differences between the acquiring and acquired companies not being so great that they prevent synergies, new resource combinations, learning and value creation [2], which typically leads to growth of knowledge [26]. New combinations increase new growth opportunities [24]. However, if resources are not shared throughout the expanded company, new combinations and opportunities might never emerge.
Acquisitions often revitalize the acquiring company and enhance its long-term survival by adding to its ability to react to changing circumstances [2]. However, acquisitions typically involve major change and that brings its own challenges. Following acquisitions there might for example, be different structures, different processes, and different cultures in place [27] that senior management must try to unite in one and the same company.
Acquisitioned growth is more typical of larger than of smaller companies. Acquisitions demand more capital and management resources than organic growth does. [28] Resource and effort are further absorbed in integrating the acquired companies with the acquiring company [2], and managers will probably face considerable demands on their time and attention required to push that integration through [24]. Despite the high expectations that accompany them, acquisitions are in fact often associated with implementation problems and unsatisfactory post-acquisition performance. The issues are often caused by the differences between the companies involved. [2, 3] Those differences may for example lie in organizational cultures, structures, systems and management styles [27] and in fact cultural clashes and tensions are quite typical of acquisitions [29].
The typical characteristics of the software business and acquisitioned growth are listed in Table 1 below.
The typical characteristics of software business and acquisitioned growth
In the following paragraphs, we will connect the typical characteristics of a software business and acquisitioned growth with the various knowledge sharing barriers.
2.2 Knowledge sharing barriers in the acquisitioned growth of a software business
The barriers to knowledge sharing can be categorized at three levels: the individual, organizational, and technological levels. This categorization is a useful tool to contemplate knowledge sharing barriers, as it encompasses all the integral elements of knowledge management: the level where knowledge resides (the individual level), the level where knowledge attains its economic and competitive value (the organizational level) [30], and the level which provides integral tools for knowledge sharing (the technological level) [31]. The categorization also makes it easier to understand the whole.
2.2.1 Individual level knowledge sharing barriers
Acquisitions can be seen as a one way for a software company to realize its aspirations of rapid growth. Acquisitions typically bring about a rapid increase in personnel numbers [2, 23]. Hence,
As staff in the software business are characterized as being competent [16, 17] and possessing high levels of professional knowledge [18], it can be assumed that they are well aware of the value of their own knowledge. However, that might not be true of their knowledge of others, especially those from newly acquired companies. Employees who do not know each other well, naturally struggle to be aware of others' knowledge, let alone the value of such knowledge. Hence,
The acquisition of a company may also raise the issue of a
Incorporation of the companies involved in acquisitions usually demands considerable effort and change [2]. The acquiring company is often quite large [1, 28] making it particularly challenging for management to define a common culture, structures, and processes that can be adopted by the expanded company going forward [27]. Hence, there is also a risk of overlapping jobs. This may lead to uncertainties which may manifest as “power games” [21, 41, 42], between employees competing for positions and trying to establish their places in the new structure of the company. It is a situation that encourages the view of knowledge as power and the concomitant choice of which knowledge to share and which not to [21, 41–43]. Hence,
As the number of employees often grows quite dramatically in acquisitions [24], and more employees should produce some synergies and time saving [24], one might assume that there are relatively few problems related to time as a knowledge sharing barrier [32, 35]. Employees should potentially gain time to share and internalize knowledge [35], however, the opposite may also be the case. If distance between people grows, it may take more time than it did previously to find the right person and the right knowledge, leading to
We might also assume that language problems [9, 35] are unlikely to feature in the acquired growth of a software company, as companies typically acquire others with similar resources [2, 23] and an argot is shared by all staff. However, as acquisitions often increase the diversity of the resource and knowledge base [24], there may be a danger of
2.2.2 Organizational level knowledge sharing barriers
Acquisitions in the software business usually cause a rapid increase in personnel numbers for the acquiring company [2, 14, 15, 23]. Furthermore, the characteristics of the industry mean that the employees involved may continue working in their existing premises. Thus, the
Companies that have grown through acquisitions may also face challenges regarding the adjustment of their respective infrastructures to share knowledge originating in the different companies [32]. That there are potential
In companies that have grown through acquisitions,
Acquisitions also typically increase the
Since the purpose of acquisitions is typically to gain benefits and synergies in the form of utilization of the competencies of two or more companies [2, 24, 26], it might be assumed that there are no major issues integrating the knowledge sharing purpose with the organizational goals [32]. If the purpose of acquisitions is to bring all the competencies that formerly resided in separate companies into use in the expanded company, the integration of the knowledge sharing purpose with the organizational goals should have been built-in to the strategy. The benefits of knowledge sharing should also be properly communicated to employees by management. However, we know that acquisitions demand a lot of time and attention from managers [24, 28], and prior research indicates that not all companies are able to utilize knowledge management related activities to support growth [10], and that gives rise to a danger that
Examination of the role of
2.2.3 Technological level knowledge sharing barriers
At the technological level, the potentially most damaging knowledge sharing barriers in acquisitioned growth may arise as a consequence of
To overcome these challenges, the benefits of the chosen technology should be communicated properly. This is a task for management. We have noted that an acquisition demands a lot of time and effort of managers [24, 28], and it may be
Acquisitions can also be assumed to generate some synergies [2]. This fact tends to lead to the assumption that employees would be able to find time to learn and absorb technologies new to them. It follows that
As a rule, however, it can be assumed that technology-related barriers to knowledge sharing are not so very restrictive in software companies. At least, as the subjects are software companies and people acquainted with working with technology who possess relevant expertise [16–18], it can be assumed that there are no unrealistic expectations of the technology, something previously cited as a knowledge sharing barrier [32].
The knowledge sharing barriers suggested by the literature review to be most relevant to a software company growing through acquisitions are presented in Figure 1 below. The barriers have been categorized at individual, organizational or technological levels as suggested by the literature.

The potential knowledge sharing barriers facing a software company growing through acquisitions based on the analysis of the existing literature
The barriers summarized in Figure 1 will be used as a framework to study the issues empirically. In the next section, the research methods of the study are outlined and details of the case organization presented. This is followed by the empirical study itself.
3. Research methods and the case company
The presentation of methodological choices starts the chapter. After this, the context of the study is presented by introducing the case company.
3.1 Methodological choices
A qualitative case study was chosen as the research method to ensure an in-depth and holistic understanding of the research phenomenon, which is strongly tied to its context [50], specifically that of a software company that has grown through acquisition. The data were gathered in forty-two semi-structured, themed, interviews. The central subject matters, or themes, were specified beforehand [51, 52]. Themed interviews were chosen to ensure that the same sets of themes were addressed in all the interviews, while allowing space for the order and form of questions to be flexed, and also for follow-up questions to be asked. These techniques were applied to provide a comprehensive picture of the phenomenon under study [52]. The interviews varied in length between an hour and an hour and a half.
In order to get the most comprehensive and reliable picture of the phenomenon under study, personnel from different hierarchical levels were interviewed (see Table 2). These levels were management and the support level (managers, members of the architect group), the middle management level (team leaders, unit leaders) and the operational level (software developers, sales people). The interviewees were selected by purposeful sampling [53–55]. The view of managers and “internal knowledge brokers” were taken into account in the selection of the interviewees, so as to acquire a broad perspective on the phenomena under study. The interviewees also were from different sites (basically from different acquired companies). To strengthen the reliability of the answers, the interviewees were guaranteed anonymity.
Empirical data
All of the interviews were recorded and transcribed as detailed interview memos. The data was analyzed qualitatively. The analysis process included the following main phases: reading the data, key word identification, thematization and grouping [51, 56]. The interview texts were read several times to obtain a sense of the whole and to get to know the data. Then the parts of the data that related in some sense to knowledge sharing were marked as interesting [57]. The intention was to extract all the data that were related to knowledge sharing and its possible barriers and enablers.
After that step, the data were coded, or classified which some regard as a better term when speaking of qualitative research [57, 58]. The classification used codes such as “time”, “organizational culture”, “compatibility of technologies” etc. The codes were selected to be “neutral” in tone; so without a positive or negative charge assigned to an issue supporting or preventing knowledge sharing. Following classification, the data was structured under larger analytical categories of “individual level barriers”, “organizational level barriers”, and “technological barriers”. In the next phase, we assessed whether the classified issues related positively or negatively to knowledge sharing. In other words, we asked whether the issues appeared as knowledge sharing barriers or as knowledge sharing enablers. In short, the analysis included reduction and classification/coding of the data, which were followed by combination and interpretation of the data [52]. In addition to the interview data, the authors attended three internal meetings of the organization. The meetings provided background data on the case company.
3.2 The case company
[53] The case company is a large software company doing business-to-business trade by providing large and complex ICT (information and communication technology) systems for its organizational clients. The company has been engaged in rapid acquisitioned growth for some years. The aim has been to create a “united” company of the acquiring and acquired firms. The reality is, however, that the acquisitions have caused the company to become quite dispersed. The operations of the acquiring company have typically been based on working with separate teams/units. In addition, the operations of the company are geographically dispersed across several sites. The result is a company with many different teams. The teams differ in terms of their organizational backgrounds, technologies and products in use, and also have very different compositions. The physical distance between the teams is in many cases also rather large.
By the time of the study, the company had decided to move to a more productized—or in fact a “componentized “—way of working intending to improve knowledge sharing throughout the organization by reducing redundant information, improving cooperation between teams and increasing productivity. In practice, this component based software engineering meant that in addition of doing their daily tasks as before the employees had to try to identify potential components, i.e. software products, subparts or features that could also be used elsewhere in the company. The components were decided to be entered into the common component library to be available for the others in the organization. This component-based production was launched throughout the whole organization. The case organization had decided to take advantage of using a single shared technology, that is, just one programming environment and language deployed across the whole organization. This technology was already in use in a few teams, but was new to most.
4. Empirical findings
4.1 Individual level knowledge sharing barriers identified in a software company grown through acquisitions
In the case organization, there was a widespread understanding that organization-wide knowledge sharing would at least be important, if not essential for survival in a fiercely competitive market, and that the idea of software componentization was to share existing knowledge throughout the organization, bridging team and unit boundaries. The alternative would have been for each unit to continue working in isolation from the start to the finish of their project tasks rather than recycling existing ideas. Consequently, the overall idea of componentization was welcomed.
The interviewees felt that in the long run componentization would save time. However, especially in the beginning of the componentization initiative, it was thought that it would require too much time to apply. Developing a software component requires considerable time, because one must think of its universal applicability. However, no extra resources were allocated to the componentization process, and the employees were too busy performing their daily tasks to assign time to componentization as well. Even so, interviewees thought that there would have been enough time for the componentization initiative, if management had prioritized it and allocated sufficient resources. That would have ensured the staff were absolutely clear that it was something to be prioritized and would have found time to implement the componentization initiative.
Trust was noted as an interesting issue. It was said that there might initially be some suspicion towards components. However, it was assumed that when viable components are identified from the component library, they would be warmly welcomed and suspicions would evaporate. It also was believed that nobody would add components to the component library before they are viable. The software developers saw delivering high quality components as a question of honor, and quality was seen as the key to trust. That said, unviable components would eradicate trust, and earning it back would be very difficult. The informants did therefore confirm a high correlation between quality and trust.
The interviewees did not see problems arising from any lack of awareness of knowledge and its value within their own teams. The team members were so well known to each other that everybody was quite aware of the knowledge they possessed. However, informants admitted to having little or no awareness of the knowledge held by the members of other teams, or of its value. The issue relates to the social networks in the company. There were social networks in place between employees who used to work in the same (acquired) companies, but not between employees of different acquired companies. There was hope that the boundaries between former companies/social networks would disappear little by little and everybody would feel like a member of a single united company. The roles of team leaders and superiors were seen as an important enabler of that unity. They were seen as network weavers, who would support the birth of social networks throughout the different teams and units. It was understood that social networks could prove invaluable to sharing knowledge, and be more effective than formal knowledge sharing channels.
Regarding language, it was stated that a software developer usually knows one programming language well and is expert in only that one. Nevertheless, it was stated that learning a new language is not an onerous task for a competent software developer. Hence, it was believed that technical argot was widely understood by everybody. Overall, it was found that the terms and concepts used in the company were common, understood, and capable of use by all.
4.2 Organizational level knowledge sharing barriers identified in a software company grown through acquisitions
As mentioned above, there was essentially a good attitude towards componentization and knowledge sharing throughout the company. Some interviewees did, however, admit that software developers tended to have an attitude that the software code they had developed themselves was superior to any other. Despite this situation being acknowledged, it did not overly jeopardize knowledge sharing, because developers were willing to offer their own code for others to use. Employees also understood that everything that was developed was the company's intellectual property, and therefore that things developed inside the company should be shared and utilized throughout the company.
Nevertheless, the recent acquisitions had provoked some cultural clashes. There was some evidence of personality clashes, and attitudes to knowledge sharing differed according to which company an individual originally came from. Differences were particularly noticeable between people who had formerly worked for competing companies. Hence, the componentization initiative was welcomed, but there were some challenges to get it working on a larger scale throughout the company.
It was widely understood that componentization would support the success of the whole organization. Componentization was seen as a more effective way to use resources, and that was understood to connect to company success. However, management was unable to communicate the importance of componentization at a practical level and connect it to strategic goals of the company. Some employees did not even seem to recognize that componentization was a relevant issue for them, and some felt that their roles and responsibilities were unclear.
One further issue raised was the feeling that acquisitions had caused the company to grow so much that it was impossible to know everybody. Most employees continued to work mainly in their former locations, something that contributed to problems with getting to know new people and the knowledge they possessed. Informants reported that it was harder to share knowledge between people across large distances. One unit had people from different teams situated in the same premises; something considered a good approach to enhancing knowledge sharing between different teams. It was believed that componentization would increase knowledge sharing between teams in different locations, whether near to or far from each other.
Apart from the difficulty of sharing knowledge caused by distance, major infrastructural issues were not advanced as a cause of problems in knowledge sharing. The interviewees felt that there were for example the proper technological tools for componentization, but they did report having to make an effort to get used to the way of sharing knowledge in a bigger company. One example was the necessary use of the company intranet that was viewed as a useful tool, albeit rather illogical and laborious to use.
Some informants asserted that for componentization to really take off, some kind of reward would be needed. Creating components available and suitable for everyone to use required the developers to be motivated and have an incentive to create them. At the same time, some interviewees saw that motivation and incentive to create components would be driven by their appearance in the component library, when their usefulness and acceptable quality standard would be established. Another case made for having rewards was based on the fact that making components required a considerable investment of time and resources from a team. Respondents considered that the absence of rewards would mean that making components would only make the outcome of individual teams worse; one team would sacrifice time and efforts making components for others to use and save time, without gaining any benefits to the team itself. Some respondents believed that if management were to clarify that componentization was a part of everyone's job, they should all implement it without requiring any special rewards, because they were getting their salary from doing the tasks they are assigned to do. Others thought that the workforce might be motivated by the creation of a positive attitude towards componentization, if that were done by persons who were highly appreciated inside the company.
There was evidence of some rivalry between teams hindering the production of components destined to be commonly shared. Teams were under considerable pressure to get results, and that led to some questioning of why one team should “waste” its time and resources to make components for the common good, or to make the work of some other team easier, especially if they received no financial benefit from it. Hence, making a universal component was kind of a “power tool”, as the employees were pondering, was it better for the team to make a universal component or not to make one.
The interviewees saw the organization to be quite dispersed. However, this was not viewed as causing major problems in sharing knowledge and components within a team; it was though identified as an issue affecting knowledge and component sharing between teams. It was felt quite unrealistic to expect everyone to know everyone else in different teams. This difficulty created both knowledge sharing challenges, and made establishing network connections across the whole organization problematical. The staff of the organization had grown to such an extent that it was hard to recognize where the most useful network connections would come from.
4.3 Technological level knowledge sharing barriers identified in a software company grown through acquisitions
Technological tools that were planned for knowledge sharing (e.g., the intranet and component library) were seen as fit for purpose. However, there were challenges relating to the compatibility of different technologies. The aim was to make components that would be compatible throughout the company, but the problem was that there were so many different technologies in use that creation of universal components was very difficult. Hence, there was a considerable expectation placed on new technological solutions, and new common technologies were supposed to solve most of the incompatibility problems. There was also a belief that the employees were so skilled that they would quickly learn to apply the new technologies.
In practice, however, it was not possible to implement the use of new technologies throughout the company, because in some departments the practice of employing other technology was too well established. The situation led to some suspicion that the new technologies were not suitable for use throughout the company and therefore component sharing was not feasible throughout the whole company either. Hence, it can be said that the software professionals were adopting a realistic view of componentization.
The new technologies were welcomed by most. It was seen as a wise way to work and was expected to ultimately make everyone's work easier. However, there were also some that were not enthusiastic about the new technologies and would have preferred to work with the technologies in place prior to the acquisitions. Nevertheless, it was acknowledged that if there were enough training on the new technologies, people would start to use them. Learning to use new technology was not seen as a major issue, because the employees were so highly skilled. However, there were some concerns that insufficient time had been allocated for training. Some respondents were concerned that there was an expectation that employees learned about the required new technologies in their own time, and that was not seen as the best possible solution. It was, however, recognized that if an employee highlighted a need for training, the training opportunity would be offered. Rather than technical training, the bigger issue was seen as acquiring training on the componentization process, in terms of who does what and with which tools. A common complaint was that management had not only not communicated the process or benefits of componentization adequately, but neither had it found time to communicate adequately about its new preferred technologies.
5. Results and discussion
This study suggests that it is possible to identify knowledge sharing barriers associated with the acquisitioned growth of a software company. The empirical study confirmed the presence of most, but not all, of the knowledge sharing barriers that the literature anticipated would affect a software company growing through acquisitions. These issues are illustrated in Figure 2 below.

The barriers potentially affecting knowledge sharing of a software company growing through acquisitions
Rather surprisingly, the empirical study indicated that trust did not play a large part in any knowledge sharing problems. Producing good quality software components was something that every good software developer would aspire to. Hence, it was taken as read that the components would be of good quality and trust would be built on that. Hence, there was no lack of trust creating knowledge sharing barriers.
The literature review indicated that awareness of the knowledge held by members of different teams, and of its value, would be relatively low. This is quite natural, as it is quite unrealistic to expect that large numbers of new employees joining a firm in the midst of rapid expansion could become acquainted with each other's aptitudes and knowledge immediately. Hence, it is also quite natural that, as the literature review implied, there would be an absence of social networks, and that would present knowledge sharing challenges. The idea of power relationships acting as a knowledge sharing barrier also gained support from the empirical study. However, this came out more from a team level perspective than an individual level perspective, as there was concern over how componentization would affect team results and whether the team would benefit from sharing components it had developed.
Extant literature would suggest the lack of time creates a knowledge sharing barrier in a software company growing through acquisitions. This was also supported by the empirical study. The main reason for this was that management did not really reserve time for employees to build components and to share them with others. The extant literature also suggested that language issues could cause knowledge sharing problems, but that was not the case in the empirical study. Evidently, the argot of the software business is sufficiently common that it militates against knowledge sharing challenges arising.
The empirical study supported the suggestion of the literature review that distance would be a knowledge sharing barrier in the acquisitioned growth of a software company. It is quite natural that since acquisitions tend to lead to relatively large growth in a short timescale, they would in turn tend to increase distances and greatly increase complexity within the organization. In this situation the establishment of network connections also becomes problematical, making it harder to share knowledge, especially face-to-face. However, the case study, perhaps surprisingly, revealed the employees to be quite satisfied with the infrastructure in place to share knowledge, and they revealed no desire for any immediate improvement in that area.
The literature review also suggested that a positive knowledge sharing culture and climate in the expanded company would reduce knowledge sharing challenges, and that the opposite would apply too. This assertion did not gain empirical support. All the formerly separate companies seemed to have had a good knowledge sharing culture and attitude. However, in the expanded firm there did not seem to be a common knowledge sharing culture and attitude, but instead some rivalry was observed between personnel who originally worked for different companies that prompted some knowledge sharing challenges.
As the literature review suggested it would, the management was able to make the connection between knowledge sharing, i.e. componentization, and organizational goals clear. However, communication of the benefits of knowledge sharing at the practical level was neglected by the management, as the literature review had predicted it might be.
The empirical study did not support the argument that there would be issues arising from the unsuitability of technology leading to knowledge sharing deterioration. However, the argument about incompatible technologies proved to be very real. This is quite natural, as the software business operates in big markets with many different technological solutions, so it would be rather surprising if a company acquired only other companies using very similar technologies.
The suggestion of reluctance on the part of employees to use new technologies was not unambiguously supported in the empirical study. It seems that, generally, software experts are willing to accept the challenges presented by new technology but there were individual exceptions. In contrast to the argument arising from the literature, the empirical study suggests that time on the technology level is not a very relevant knowledge sharing barrier. Obtaining the time to learn new technologies seemed to be more of a question of employees acting to flag up to their superiors the need for time to be dedicated to learning.
At many points of this empirical case study the different challenges related to knowledge sharing were entangled. Furthermore, the sheer scale of the growth occasioned by acquisitions seemed to present many challenges to knowledge sharing. The role of management also seemed to be crucial in terms of promoting unrestrained knowledge sharing in the midst of the acquisitioned growth of a software company. Hence, it can be argued that the knowledge sharing barriers to the acquisitioned growth of a software company are interlinked and highly related to the role of management and to the extent of the relevant growth strategy.
6. Conclusions
The aim of this study was to create further understanding of the potentially most restrictive knowledge sharing barriers in an acquisitioned growth context. The current research has presented a case study examining the relevant potential knowledge sharing barriers for a software company growing through acquisition. The findings of the study will help companies sharing an aspiration to grow through acquisition to better prepare for the challenging task of managing growth. The paper also contributes to the literature on knowledge management by defining knowledge sharing barriers in the context of acquisitioned growth in the software business. It makes a further contribution to the growth literature by touching on the issue of the management of acquisitions from the perspective of knowledge management, and especially knowledge sharing.
Based on the literature review and empirical evidence gained from our case study, we suggest that there are some knowledge sharing barriers that can afflict a software company that has grown through acquisition that are more potentially restrictive than others. For managers leading an acquisitioned growth strategy, it will be useful to know which knowledge sharing barriers have the most potential to derail the strategy, so that they might steer resources toward preempting or dismantling those barriers. The results of the current study suggest that there are a few fundamental issues that demand management attention. One seems to be the attention and effort management assigns to knowledge sharing. First, management should prioritize knowledge sharing. Then it should ensure it communicates its importance well. However, the understanding of the importance of knowledge sharing by management and its subsequent communication seems not to be enough. Management should ensure that the implementation is also conducted properly. The staff of our case firm demonstrated a generally positive attitude towards knowledge sharing. However, to successfully implement knowledge sharing that crosses the boundaries of practice within individual companies, management intervention and resource allocation will be required. This is a need magnified by the often large-scale growth occasioned by acquisitions.
As the current research revolves around a single-case study, further studies would be needed to obtain more generalizable results. A survey would serve that purpose. As an acquisition strategy is but one of the available growth options, it would be interesting to compare the knowledge sharing barriers associated with it and the knowledge sharing barriers arising within firms pursuing organic and networked growth. This comparison is in fact already underway, as this study is a part of a larger study incorporating scrutiny of organic and networked growth. As the role of the management seems to be crucial, it would also be interesting to conduct research on the relationship of leadership and management styles to knowledge sharing barriers.
