I’ve got interested in corporate network analysis and read an article called “Managing 21 Century Organizations” by Valdis Krebs. In his article he says:
If the knowledge that you seek is not within your network horizon (one or two steps), then you assume it is not available in your organization and you reinvent it, or pay for it on the outside.
The natural response in many organizations is to throw technology at the problem. A very poor, yet quite common, solution is to attempt to mine knowledge from employees, codify it, and store it in a large database. Many large consulting firms tried this approach in the 1990s with usually sub-par results. They found that people were not always willing to make public their best knowledge and that codifying tacit knowledge was like trying to nail jelly to the wall. It did not work, and just left a mess.
I can picture employees not willing to formalize their knowledge and fill in a corporate wiki, as it requires extra effort. But it can be the case that the tools people use to collaborate with each other already require some kind of a formalism, that allows to mine knowledge.
Take a corporate task of determining different people’s impact on the advancement of the project. If the project is about writing code, people use GIT and the formalism it introduces to the workflow is enough to draw this kinds of conclusions. It is possible to analyze code commits from an employee and determine whether it is cruicial/useful for the project. If you have a issue tracker, you can easily see what people solve what kind of tasks, which parts of project cause more problems, etc.
Having a collaboration tool with a useful formalism allows us to understand the project dynamics better. One problem to solve is to get this idea outside of the coding world - this I described in a (russian) mission statement about a year ago. Ways to do it something that interests me the most.
Some people say sooner or later any kind of a qualified employee will need to know how to code - computer technologies made their way to all kinds of applications. First, corporate IT people would just develop a system for a specific industry, then, to make a system more adjustable, introduce ways for industry people to fine-tune it, like clumsy XML specification files. Then, DSLs would come about, bringing domain-aware people closer to programming. It makes me think that the more we use computers in any type of work, the more successful the attempts to find a proper formalizm would be.
Another thing that came about after Mr. Krebs wrote his article (2007) is those huge social networks we’re all on now. If people are using computer tools to exchange purely emotional, non-constuctive information about their daily life, there is surely a way to make them use something more sophisticated than email in their work.
We need to build a new GitHub for biomedical people, a new Bitbucket for chemical engineers and a new JIRA for architects, the sooner the better. Pretty sure it’s gonna work this time.