A while ago I was asked by Jens Coldewey to give an interview on intellectual capital. An interview that runs electronically, in a written form. It was a very interesting experience, I must admit. As for the result, judge yourself!
Jens: You are researching knowledge in outsourcing and offshoring relationships. What is the basic model you’re using?
Darja: So, the main focus of my latest research has been related to intellectual capital, and primarily the human and the social sides of it. We find that many organizational improvement programs and basic university education as well have paid a lot of attention to the organizational capital, how to document knowledge and how to maintain these knowledge assets, while our research finds little evidence that it helps software engineers in their job. What we find is that competence, experience, and ability to cooperate and share knowledge is what is needed, especially when dealing with complex projects and legacy system maintenance.
Jens: So the stereotype of a socially challenged genius as a programmer is not what organizations should look for?
Darja: Definitely not! I truly believe that software engineering has moved away from individual geniuses working in cubicles alone to software development emerging from cross-functional “cross-competent” teamwork.
Jens: You were talking about organizational capital and personal skills. Is there more an organization has to build than well-thought processes and hiring bright people?
Darja: Well, let me just state that hiring bright people is super important. I am all for a good hiring process. Organizational processes are also important, perhaps more in the form of culture than documented routines and procedures that we thought were important some 10-20 years ago. What I think makes a difference today is the focus on organizational transparency, autonomy, and engagement, where the focus is not on people following the rules, but rules emerging from bright people who find what is needed now, and what shall be changed tomorrow.
Jens: There the concept of “Social Intellectual Capital”. Is this what you’re referring to?
Darja: The right wording would be “Social capital”, which is one part of Intellectual Capital. Although I don’t link autonomy and engagement to the social capital per se, socialization is surely needed when you put more responsibility on the engineer level. The difference today, as I see it, is that The Brightest Guy or a group of these guys, who will tell how software shall be developed does not exist. We deal with complex problems, primarily because of the scale – the scale of the legacy, scale of the development organization, the number of teams involved and even locations. To make engineers in teams responsible for something, they need to be deeply integrated into the knowledge networks, receive the information needed to make decisions, receive feedback to reflect on what has worked and what has not, and so on. This is where the importance of social capital emerges – the ability of people to get the right knowledge and information when needed. Because with the scale no single individual can actually possess all that knowledge.
Jens: When I was starting my career, the answer to this challenge – get the right knowledge in time – was Knowledge databases and probably Lotus Notes. But this does not seem to be the thing you’re referring to here?
Darja: Ha ha, ironically, I have developed a Knowledge database in Lotus Notes when I was doing my Ph.D. It was never used. Or maybe a few times. But no, that is definitely not what I mean here. That would be a common way to transform the tacit knowledge into the organizational capital. Unfortunately, that does not work. Not because of Lotus Notes technologies, which today are probably replaced by a Wiki or a Microsoft Sharepoint, but because of scale and speed. Even the best documentation ages fast, and the investment into documentation seems therefore unreasonable. This is why, I see more value in investments into socialization activities and rituals, while documenting the core principles that are unlikely to change. One would probably argue that networking doesn’t bring much value for organizations. I would still argue that the value is simply not always obvious. The more people are familiar with each other, with what they are doing, and especially with what they know – the better is their performance, assuming, of course, that many know something.
Jens: As a researcher: Do you have any hard data or research results that back these claims?
Darja: Absolutely. First, I would like to point to the study, in which we have measured social networks of teams involved in super-large projects. We asked team members to report their connections – who and how often do they share or receive the knowledge from. We also asked team managers to evaluate their overall team performance. The results show that teams with larger networks outperform those with smaller. In fact, although in our sample the small networks were possessed by junior teams therefore dealing with not so familiar tasks, even experienced teams challenged by unfamiliar tasks had to capitalize on their knowledge networks, which were also larger than the average network of an experienced team. So, we do see that networking helps.
Second, we also see an acceleration of learning with the help of networking. Recently I have been following a number of outsourcing cases, in which the client companies are not satisfied with the performance of the offshoring vendors. To understand the core problem we compared performance in the client companies, and at their vendors, and found that presence of expertise and co-location (ability to network effectively) mattered. Offshore sites typically suffered from high levels of employee turnover and struggled to accumulate human capital. The newly onboarded engineers could not get the help locally and would not reach out for help to the client organization, and thus learned slowly. In contrast, client sites who had experts present, would onboard new engineers faster, because of the positive effect of networking.
Jens: So reducing turn-over is an important part of preserving social capital. Are there any other “building blocks” you frequently see in organizations that do a good job in managing their social capital?
Darja: Good question. We have recently started studying communities of practice in Ericsson and guilds in Spotify. These are parallel organizational structures to the formal ones, that bring people from across the organization together to improve a certain practice. Many of these communities are inherently built on socialization, democracy and volunteering. And although not all companies successfully implement such communities, we see that there are benefits on the organizational level, as well as on the unit level and the individual level.
Jens: I’ll go with the devil’s advocate for a moment: If I bring 20 highly paid engineers together for two hours, no agenda, no goal, no result, this raises the cost of a full week. If I do this on a weekly base, it’s a full headcount. Where is my RoI? The cost is pretty obvious…
Darja: I am definitely with you on this. I would never support a community of practice without agenda, with 2 hour-long meetings, no goals or results. In fact, our research shows that engineers don’t want it either. Such communities would never sustain. Not because of managers, but because highly paid engineers, as you put it, would never show up!!!
Successful communities have a mission that clarifies the value they are expected to provide. It can be the value in terms of improved ways of working, where the return on investment could still be arguable. But if there is a strong need for improvements, let engineers come up with a plan together. When that is done, a community will stop, and you will get happy and engaged engineers following “Their process” and not pretending to follow “The boss’s process”. There are other examples with more value for the company, such as standardization-oriented committees. For example, if your company develops 5 different products for the same group of customers/users, and the UI in each of them looks different, then you are doing something wrong. This is an excellent task for a company-wide UI community. And the return is a happier customer.
Jens: Why do we need a community of practice for this? Why not just a UI expert who authors the new style guide (been there, done that, got that T-Shirt…)
Darja: I guess I am becoming very Swedish 🙂 Swedish engineers don’t like following someone else’s directives. Maybe 20 years ago that would be a perfectly OK solution. But I would guess that today engineers from each product would argue that their product environment is unique, that they cannot do something. Or am I naive? I have seen big and successful companies struggle with this. Why haven’t they gotten a UI expert?
Jens: I had done some UI research at that time… The problem was it was outdated before it was published – just what you wrote before.
Do you think this is just an attitude of Swedish engineers (and German ones too by the way) or is there some deeper truth hiding in the success of communities of practice as opposed to centralized standardization?
Darja: I think that as software engineering as a field matures, we have several generations of great engineers with lots and lots of experience. While it is easy to instruct a junior developer to follow directives, directing experts is no longer an option. Experts want to be heard, some just to talk, but I want to believe that the majority because by discussing the different alternative solutions to the same problem we come out of the meeting with the best option. Perhaps even junior engineers today want to know the purpose of why they are doing something. Their engagement in a community ultimately gives them an opportunity to have a dialog and ask their questions too.
Jens: Agreed. But let’s go back to how organizations are set up and how that affects their social capital: Many organizations today keep a “pool of resources” – meaning engineers – and then project leads can “pull resources” from that pool to staff their projects. Do you have any insights on how this affects their abilities?
Darja: I just want to say that I hate when people are called “resources”. As long as organizations see people as resources, nothing will change. I am more comfortable with the word “asset” 🙂 But on a serious note, yes, pulling resources from a pool might be a problem for the social capital. I would rather prefer pools of teams in this respect. Teams develop a strong internal network, that from a theoretical point of view is often referred to as a transactive memory system. This is a system, which is maintained by a joint effort of team members in storing information to be able to retrieve knowledge when needed. If you pull someone out of that system, the system is destroyed.
Jens: Is it really destroyed or just thrown back some steps?
Darja: Well, you might think so. But the team does not always realize what they have lost, because these processes are not always conscious. Moreover, the team members might assume that the substitute member will replace the gap, but how should the new engineer know what he or she has to know? That knowledge might be no longer present in the team.
The question of moving people around has surely two sides of the coin. One is when you create a gap, and the other is the positive one – when you move someone with the knowledge and a strong network to a team that has little of both. You basically move both the human capital and social capital together. So, what is bad on a team level, could have a positive impact on an organizational level.
Jens: Are there any research, rules of thumb, or other insights about how much change is good and when bad things start to happen? Or a formula perhaps….?
Darja: If I had that formula, I would be probably rich 🙂 I am not sure whether a formula may exist in this context, because organizations and the state of their social, organizational and human capitals are so different. A few general observations I can still derive from my research. Companies that are new to the business, that employ junior developers directly from the universities will require time to mature. This is obvious. But what happens when a relatively mature organization shall grow? That is an interesting question. If many new developers are onboarded, they need to go through a process of assimilation. If social capital, which is also responsible for maintaining an organizational culture, is low, then the organization after scaling might have a completely different identity.
Jens: ok, I’ve seen things like that happen several times – and it wasn’t always a good experience.
By now we have only talked about the engineering level where the actual work gets done. What about managers? Do they also need to care for their social capital?
Darja: Let me ask you a question back. What managers are we talking about? And why do we assume that we need managers at all?
Jens: Fair question.
Darja: The most successful and surprising organization I have just visited in Croatia had no non-technical managers. The key developers were Scrum masters, agile coaches and line managers at the same time. And they were naturally deeply integrated in the social network of engineers.
Jens: Personally I have never seen a successful no-management organization, but I’ve seen very different types of managers. So the background of my question was the assumption that a social network develops easier and surer if it is not left to self-organization only, but if there is a group of people who care for it. And I’d call this group – managers. Does that make sense?
Darja: I don’t fully agree with you here. I also think that networking culture and the successful implementation of parallel organizational structures such as communities of practice requires leadership. But that might not necessarily be management. I guess I am just a bit allergic to the label “management”. I think that self-organization does not require to be managed, but leadership is definitely one of the keys to success. That we also see in our research.
Jens: I’m fine with replacing “management” with “leadership” in my questions (“leader” just translates awfully into German, that’s why we don’t like to use it …). So to what extent is social capital important for the leadership of an organization?
Darja: I see your point. Too bad that there is no good name for leadership in the German language. You should definitely ask someone to fix it! But back to the question. To me, leadership is not disconnected from engineering. And if it is for some reason, then it has to be reconnected. A connected society is hyping now, and organizations that want to develop a networking culture, cannot simply rely on and wait that the culture will eventually emerge from the engineering level. It should definitely start from the … well, I have to use the word “top” or “head” here, since traditionally that would be a more understandable metaphor for the management.
Jens: So the leaders should also be connected in teams and with the engineering teams?
Darja: In short, yes. I still think that the disconnect from engineering is a less successful setup. Furthermore, many companies have too many levels of management, especially in cultures with promotion-seeking behavior, where engineers are not as respected as managers. In many Swedish organizations, an engineer can stay in the same role for 20-30 years, have a higher salary than his/her manager, and be very happy and proud to be an engineer. That’s where the knowledge is. That’s where the intellectual capital is. So, management or leadership shall definitely be connected to the engineering teams, in my humble opinion.
Jens: That makes a lot of sense. One final question: Projects are by definition temporary organizations and many especially IT organizations are built around projects. How would that fit to your approach of stable teams to build social capital?
Darja: Very good question. In my view, when a company makes an investment into building a team within one project, it is reasonable to harvest that investment in future projects. So, I don’t really see the need to not use the same team elsewhere, in other words, and organization can move the whole team together. I know there are many different circumstances, and teams are doomed to change members. But it does not necessarily have to be associated with the project lifecycle. I know consultancy companies that “sell” teams and emphasize that the teams they offer have had a long history of working together. Isn’t that evidence that social capital is important?
. 
Leave a comment