A comment on my last blog post, woke me up to the difference between developing within a culture, and developing from outside a culture. It took email exchanges and tweets to further develop that idea. I’ll show you what I mean in this article. And, thanks to Greg Yankelovich, who tweets as piplzchoice, for that comment.
To make sense of the within and outsider notions of culture, we need a way to visualize a culture. I’m focused on culture as containers of meaning, and hence practice, the stuff of software use.
Philosophers conceived of meaning as “The Ontology,” as if there were only one central structure of meaning. AI researchers have taken on ontologies as agent communications vocabularies. Information architects differentiate ontologies from taxonomies as well. Ontologies are about concepts. Taxonomies are about things. A thing’s place in a taxonomy is based on the decisions used to classify the thing, the taxons. Similarly, A concept’s place in an ontology are based on its definitional differences that philosophers called sortables, and that I’ve come to call ontons. You end up with decision trees. I call the leaves of these decision trees infons. I will say that this vocabulary is not mine. I found it on some Perot Systems or EDS website eons ago.
So to visualize an ontology, we will use a decision tree.
Visualizing Culture
In the figure we start with (1) the usual decision tree, a binary tree. (2) Shows a more abstract representation of the usual decision tree. (3) Moves the binary tree to a multiple branched decision tree, which leaves us with a cone. (4) Shows how a culture contains subcultures that contains subcultures.
The rightmost diagram (4) encodes a cultural terrain. This is the key visualization we need to begin mapping out the cultures within a corporation.
You have the corporate culture, the priority culture among the functional cultures that compete for the “market leading” cultural position. You might find yourself working in an engineering culture, a sales culture, an accounting culture–I hope not, or a marketing culture. That will depend on tradition and the CEO. The corporate culture would provide the shell in any representation. The corporate culture would contain the management culture, and the numerous functional cultures.
The functional cultures may contain specialist subcultures. IT would be a functional culture. Engineering might be a separate functional culture even if it is staffed with IT people. The goals and reporting structure would separate IT from Dev. Your technical writers would have their own functional subculture, since as a population they share meanings, goals, tools, practices, and processes. Their distribution into development teams wouldn’t alter their functional culture. The same goes for the developers, QA people, marketers, and whoever else may be on your team or report to you. Such is culture in a matrix. Consider the culture of your team to be your responsibility, yes, a human, soft-side management responsibility is yours.
Then, you have your boss and his boss and his boss–the line management structure organized within the management culture of your company.
But, let’s skip from where we work to where we sell, to our customer’s organizations. They look similar to your organization in terms of their cultural terrain. Your product has stakeholders all over their cultural terrain. Marketing and sales deals with all of them, and in the late market, where offer expansion is key to success against the fast following, price competitors, you will deal with all of them as well.
My prior post and last week’s discussion on the #aopmtweet chat was about how requirement elicitatin could be improved by focusing our market populations on the cultures that we usually ignore and crosscut. The above visualization provides some hints to the boundaries that statistical aggreation ignores.
Moore’s technology adoption lifecycle also hints at functional culture as a segmentation mechanism. It shows up in how one would bring a discontinuous technology to market. Moore tells us to start with a custom application. Adding stage gatting to Moore’s model, we can use the client’s vertical as our statistically aggregated population and verify the number of seats and the number of dollars available in that market. An important distinction in these custom applications is that they are products. We should already have our technology.
Our technology is the realization of our idea. We coded to our own specification. Software engineering emerged from engineers and computer scientists who coded for themselves, so they coded within the specifying culture, which enabled them to get away with ignoring culture. They didn’t have executive stakeholders or requirements volatitlity to deal with, and neither do technology developing companies. Culture intrudes when you go to market. That’s when you find yourself and your team coding from its culture for those in another culture. They are coding products.
Now, when we start a custom application gig, we might not yet have our technology platform, so we will have to develop it, as we develop the custom application. If you can, separate the technology platform from the custom application. Separate the container from the contained, the automation from the automated, the channel from the message. Deal with the bifurcated development processes: one based on engineering for engineers, another based on engineering for functional practitioners. You’ll need two teams and two different elicitation processes. One will focus on the technology platform. The other will focus on the customer application riding on top of the technology platform. Build the custom application to the last release of the technology platform, to the last API, rather than the latest API.
So we have started down the Moore’s technology adoption lifecycle (TALC), which consists of sequentially organized, risk orientation-based markets. The TALC is shown in the next figure.
TALC with each market's culture count annotated
Starting at the left, you release your technology platform to your technical enthusiasts, or geeks. You provide free betas, because they will not pay for code. They will debug it for you. They will figure out what it can be used for. They will advocate it to their IT bosses and corporate management in terms of interesting applications that solve real problems in their workplace. They help you find the early adopters that will pay for custom application development. You code for people in the same culture as yourself, when you code for the technical enthusiasts.
To make money, you need to find a paying client. You do this in the next market, the early adopter market. These people are business executives that run an organization that will be functionally oriented, or possibly line oriented. Here you will code for people unlike yourselves. You will code from your culture for use in other cultures.
In the diagram, the custom application market is divided into eight different sections that represent the eight custom apps you will need in the bowling ally, or vertical markets.
Once your client’s period of exclusion expires, you can sell that custom application to other companies in the client’s vertical. The market would actually be a particular spot in the vertical, but it would be the same one occupied by the client’s company. The programming situation is still coding in one culture for use in another. The meaning problem persists here.
Once you leave the bowling ally or vertical markets, you once again sell to the IT market, a horizontal market. You move back to programming from one culture for use by the same culture.
Then, you move into the post-tornado, price-based, fast follower competition, or red ocean, situation. This may occur before your entry into the late market. From here on, until you consume the late market, you will code for both IT and functional users, so you will need the culture facing capabilities you might have abandoned as you exited the verticals. One red ocean strategy is mass customization, which has you focusing on functional unit meaning in the various industries that comprised your vertical markets, as well as moving up and down the industry stack or tree that constituted the vertical market. Lots of cultural boundaries need to be observed here.
We need an eliciation process that is sensitive to the functional cultures that comprise our markets. We need to understand and acknowledge the cultural boundaries in our development and marketing processes. We need to move away from aggregated populations that scramble meaning and lead to increased use costs by our customers. The survival of our industry depends on the latter.
Even where we code for our own engineering culture, we do not code for people like ourselves, otherwise, they would code the application themselves, rather than download and compile, or pursue funding by their management. They use an API when it is easier to learn that roll themselves. So even within the engineering or development culture there are subcultures. We need to be aware of these as well.
Let me know what you think. Comments help a lot. Leave a comment! And, for those of you using a feedreader, email your comments to Dave44000@yahoo.com, and I’ll post them here. Thanks!
