Why do you Smoke?

“Why do you smoke?” is one of the most ridiculous questions to ask any smoker. I have dodged this for more than 15 years now, with some frowns or attitude statements or some such non sense for e.g. economics is irrational so is smoking or simply because I have the right to smoke or it is the fault of marketing to our generation from the multi-national corporations or it is a man thing or it is genetic.

Time has come now to answer and at least avoid the question from whoever reads this.

1. It is a part of me, as my identity, my daily pattern, my external appearance, my presence, my voice (notice that deep S and H and the occasional coughs), without it I feel incomplete. And it is nothing extra also. It also nicely fits into most routines unless you keep going around the world on back to back flights.

2. It is a great accompaniment to boredom, action, reflection, reading and suits well for most places

3. Smoker conversations are better than non-smokers especially if you have found your gang, and your times match. It is as if a level of meaning gets added to the conversation that you some times get suggestions to do a back to back smoke just to continue the conversation. Typically there are no fillers in smoker conversations, the smoke is the filler, if you don’t have anything to say simply smoke. Unlike the non-smoker conversations that goes on with endless slow fillers like “So…”, “Interesting…”, “Cool, Cool…”

4. Without doing anything you get a sense of accomplishment, this is I think unique to smoking. Wally’s coffee comes close to what I am saying here.

5. A ritual that I feel people associate me with, at least I assume this and use the chance to smoke, when meeting, even the advice each one gives to stop/reduce becomes part of it. For them to keep doing what they are doing, I have to continue smoking.

6. It is death personified and it is so around us everyday, it feels good to relate with it, yeah I am taking it too far. From what Camus says about suicide as “one truly serious philosophical problem”, it makes sense to ask it a couple of times daily.

Still burning…

Alt: Quitters don’t smoke and smokers don’t quit


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.


· 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