cognoise

2 Culture models

There are 2 models I use in my job primarily to understand a culture and act within it. Both have different origins and language.

Hofstede’s theory comes from an anthropology background, where the construct is based on 5-6 dimensions that are found to be key in understanding a culture and hence to be considered while communication, negotiation or any other activity that involves action across groups in different cultures. I have used it in a couple of different ways, such as when specifically making case for an investment it is important to position for the listener/investor’s culture than from where the idea is coming from. So I figure from one of the existing tools to find the cultural dimensions that is important and lean on it majorly, but still make sure the other dimensions are covered as well. For example for US I lean on individualism than collectivism, for India power distance and uncertainty avoidance.

Archetype extraction comes from a narratives background, just to be clear this is not to be confused with Jungian archetypes or motifs but there exists some relationship. Relationship being about memories (typically a collection of stories / events / even pictures from the field), that triggers some reaction (in a group setting). Instead of just labeling once, you do it twice, first labeling a stereotype and then extracting attributes, and then grouping the attributes (or their extremes) and try depict them as an archetype. This way there is no one single person / character that the archetype representing, but rather every archetype represents a part of the group’s make – up. Closest example I give is from Dilbert, you see part of your manager in the pointy headed boss, part of yourself in Wally and Dilbert, etc, but never can you point the one single representative.

I have always felt that people use culture as an excuse to not doing something. So if there is one most useful thing to pick about culture and innovation, by using these models you can quickly move away from useless abstractions and perceptions about an existing (always assumed static) culture especially by the old timers and ask them questions on either the dimensions or effects the narratives have on actions now.

Advertisements
Standard
cognoise

Collaboration delineated

‘Why’ is usually more important than the how. As knowledge managers do not usually have any say in ‘why collaborate’, they are stuck with the how. And then there is the constant tradeoff between why a business does something versus why for an altruistic purpose. Again, knowledge managers are comfortable with the altruistic purpose of a community, of innovation, of knowledge sharing, of wisdom in crowds or similar such purposes. That leads me to think the why part of the equation is a red sea muddled with points and counter points, but the how part of collaboration is open for intervention.

Collaborate with its original meaning, “to work with” has to be delineated further. “Work” today is non-linear than what it used to be (even 5 years back) and “with” is very disjointed as well.

Continuity typically is on a work item (e.g. system requirement or issue). To achieve continuity within groups there has to be an overlap of function (e.g. development), identity, effort (e.g. of coding), space (a physical space, a code base). Work in Progress items are more suited for continuity, e.g. developers working together on a release (10.3.4 or R14) or version, talk abstracted or abbreviated language among them that lends continuity. End-products are not given much prominence for example the specification itself or any of the process documentation created during the process.

Coordination is for actions done by individuals in a specific time and space (e.g. check *.ini before service start up, capture log immediately after error, build after check in from all developers is complete). Within groups most understand the rules or rituals and follow them, usually there is not much to intervene here. If the number of people that need to be coordinating increases then a linear sequence with fall backs and alternate paths are developed usually by managers. That flowchart is presented in review meetings with no relevance to actual developers. I find Paul Graham’s maker manager distinction very relevant here.

Communication is often a channel decision, and people choose channels that they are most comfortable.

As in managers email, developers list, clients chat or instant message, friends SMS, and family calls

Channel is a tough choice to make specifically because

· enterprise software are aged and fragmented,

· email inbox more and more looks like somebody else’s to do list,

· managers cannot control requirement change over chat messages,

· and documents never are updated

Rule of thumb that has worked for me is take work to a channel where all the parties are already present. If there is no channel, create one and allow free access.

Metrics around velocity or work, closeness of drop dead date, progress on work items, my items (both in and out), are all derivable from most systems. This I feel one of the basic reasons why basecamp succeeds.

Coherence

· is meaning derived from the work,

· is making sense of where we are, and knowing where the effort is going,

· is relating to the bigger picture

This never comes from status meetings with a formatted ppt, most developers consider that meeting as a break and try to speak as less as possible and take back no action forget about coordinated actions. A concept map on the other hand provides a better way to look at things zoomed out or zoomed in, more clearly with relationships and dependencies.

Knowledge manager’s job gets interesting if more than one of these dimensions is handled. Just saying

Standard