Soft Asset Management

Each organization struggles to harness and manage 3 simple assets.

Ideas
The rank and file engineers have a lot of very good ideas that never see the light of day. The reason for this tends to be a layer of dead managerial weight separating any developer from any person capable and willing to make a decision. The middle management is also extremely terrified of anything that's perceived as rocking the boat or anything that causes them to stick out ( such as championing an idea). The problem is that a lot of these people are simply afraid of showing how incompetent they really are. What needs to happen is a way to send ideas directly to the senior management or some sort of governing committee that can review the ideas and has the power to fund them. I've seen one organization implement this very well. They've setup a committee consisting of senior management to review all incoming ideas. The idea is emailed directly to your regional director. (There is one regional director per continent.) The director would then take your idea to the committee for review. At the end of the year, the committee chooses a handful of ideas to pursue and those people receive awards such as trips to Paris, trophy, envelops, and recognition - due to a large assembly that you get to speak in front of.

Prior Art
"Prior Art" is a term used in patent law to describe inventions that someone has already patented. Each organization produces a lot of innovation: software, libraries, fixes, procedures, etc... The ironic thing is that each group in the organization tends to develop its own solution to a problem probably faced by every group. In a couple of places, I've seen organizations attempt to avoid some duplication, but never very successfully. At the core, the problem is that each group has no idea what the other is doing. Additionally, there is rarely a single architectural vision or a way to search for existing solutions. Basically, the proposal is to setup an internal open-source community. The community would know of all projects going on in the organization, and would manage certain projects submitted to it such as general projects like scheduling systems, or monitoring libraries. Everyone should be aware of what the other is doing. If someone in the organization is working on a security model, and I am about to start writing my own password management system, well, hopefully I know about the other initiative.

Knowledge
Each engineer accumulates a wealth of knowledge. The most relevant and long lasting learning occurs from your peers and not from a 2 day intensive class. Although, its great to miss 2 days of work and get catered lunch. What organizations struggle to do is share individually acquired knowledge. In fact, a number of organizations, because of politics discourage the practice or do it with a heavy managerial hand. For example, in one company I've worked for, the management decided that the way to share knowledge is to hold bi-weekly developer meetings. Their solution was that each manager or director would bring some of their people to the meeting. In some cases, the directors brought only managers. The end result was that the meeting consisted of 30% developers and 70% managers/directors. The funny thing is that the topics started technical and quickly moved to managerial such as billing. I spoke up in one of these meetings. I believe I said something to the degree that this is mockery, and if both my manager and my director were not sitting next to me, I wouldn't be here. Well, I am no longer with that particular company. Some ways to promote knowledge sharing is to get developers talking and debating. For example, the organization can create a developer community and hold weekly meetings. During each meeting, one of the developers can present something useful and interesting to discuss such as programming patterns, algorithms, and standards. Additionally, within a team, discussion should be encouraged. Team leaders should promote a culture of learning and challenge such as emailing logic problems. The only reward is the recognition that the person is better then everyone else. The organization should also implement code review and design review. The reviews will enforce a level of competency which is sometimes missing during coding and designing.