While catching up on my backlog of technical journals over the holidays, I found an interesting set of articles that are very relevant to our work and business. Some of these include:
In this commentary I will look a an issue that seems to be plaguing projects: the lack of continuity of senior engineers and architects as the organizations focuses, as one vice president spoke of a project, "an opportunity to be promoted or fired".
Phillip Armour noted in the CACM articles:
"...the kinds of knowledge that must be gained will vary from system to systems. The degree to which the knowledge is unknown will pretty much determine how long it takes us to acquire it." CACM, Dec 2000, pg 15
He then proceeds to follow up on the definitions of ignorance, he brought forward in the October edition:
In two related Commentaries:
During the second half of 1999 and the first half of 2000, there was a folk lure in the Bay Area that this "internet thing" could only be understood by "brash, young entrepreneurs who could break the ties with the past and grab the new models of business."
From the perspective of the Orders of Ignorance", it is (now) easy to analyze this phenomena and easily draw the conclusions:
The end result is actually potentially very useful: the Darwian Natural Selection will take care of the "unfit" and the results of the internet based parallel to the "Cambrian Explosion" of life forms has generated knowledge and skills that willing be carried by the individuals into their next positions.
I would note that the massive amounts of Angel and VC funding expended on this burst of innovation was probably a bit on the over kill side. The groupthink made it very expensive to do this exploration. I am concerned that VCs and Angels as well as the participants will learn "too much" and walk away with superstitions and scars that inhibit them form taking what could be successful innovative paths in the future. But that's a topic for other Mocha Expresses. :-)
There is a maxim in operating system design that only after designing 2 operating systems is the architect or design really skilled enough to achieve a satisfactory result. The observation is that:
The rule is that only by having the hard won, hands on experience can an engineer have the training to create sophisticated, business oriented technology tradeoffs.
I have seen managers who thought that gung ho charging of the ramparts will, through sheer momentum and motion, achieve the business goals - such as the "promoted or fired" quote. I view this approach as wishful thinking by managers who really don't have a clue in the classic Dilbert sense. Maybe if there is enough motion something good would happen and they can move on to their next position before it falls apart.
The key learning that should be drawn from "the grand internet business experiment" is that even in the presence of new directions, it is important to find and empower the people to try new directions but to keep a strong hand on the business reality.
In this context, processes are very useful for codifying the organization learnings. Newcomers to the organization need to both bring in new ideas and also learn the BKMs from the past. Processes represent a way to investigate areas and find out what is not known and to develop the strategies and skills for addressing the problems encountered.
It is not acceptable to continually repeat the same mistakes: people should be skilled and experienced enough to make new mistakes to achieve new learnings from the baptism of fire that is the front line of business activity and product development.