Kartik Subbarao

Great video interviews with Carl Jung:

I recently set up accounts on Spotify and Grooveshark. Here are the playlists:

http://open.spotify.com/user/kartik_subbarao/playlist/6tOK1QcygkseS9K7Gv6cX5

http://grooveshark.com/#/kartik_subbarao/music

So far, Grooveshark seems to have a better collection of music that I like. For example, I was able to find some TV, movie, and video game soundtracks on grooveshark that were unavailable on Spotify.

I recently had the opportunity to contribute to two Hacks on the Management Innovation Exchange (MIX):

• Build a Strengths-Based Culture, by Josh Allan Dykstra
• Open the processes and the “books”, by Susan Resnick West

These are part of the Communities of Passion Hackathon Pilot being led by Chris Grams. I’ve enjoyed collaborating on this effort!

[ This article is also published on opensource.com ]

In a July 2010 post on opensource.com, Jonathan Opp wrote about the nature of giving and participating in a gift culture/economy. One point that he mentions is the benefit of giving freely, without strings attached. I’d like to expand on that, since I think there’s a lot we can learn from recognizing the hidden strings that we sometimes attach to our gifts.

For example, let’s say that I contribute some new features to an open source project. In the next newsletter from the project leader to the user community, the new features are trumpeted as a significant advancement, but without my name being mentioned. How do I feel when I read the newsletter? If I notice myself feeling strongly resentful, that’s an indication that I did attach some strings to the gift that I gave. My resentment may well be justified, and others might even agree that I was wrongly slighted. But that’s not the point — whether justified or not, I wouldn’t feel strong resentment if my gift were truly free.

Now, that doesn’t mean I have to beat myself up about being an imperfect giver. In fact, just the opposite — I can appreciate that I recognized the feeling of resentment as a barometer, right as it showed up. Because if I didn’t, I’d then be acting from that resentment. Resentment might prompt me to snidely react to the next email message from the project leader, which might provoke him to respond in kind, which could then suck me into an escalating conflict that would end up stealing a lot of my energy.

By remaining aware of the feeling, I retain more control over my next actions. Maybe I need more recognition from the project leader to motivate me to continue working on the project. So perhaps I’ll have a skillful conversation (where I may not even ask the question directly) to gauge whether the project leader can meet my needs. Or maybe there’s another project where I can give freely, and I’ll go work on that instead. Or, maybe I sense a growth opportunity to let go of the attachment, and I continue to work on the project with a clearer intent. You get the idea — any one of these approaches is a far better investment of my energy than just lashing out from resentment.

In general, when we give from a state of abundance, we can give freely. We don’t feel diminished in any way. We can enjoy the act of giving just by itself. We can welcome any future benefits that ensue, without fretting about what we were owed. Whereas when we give from a state of scarcity, there are more obstacles in the way, more opportunities for strings to get attached.

One of the places where scarcity shows up in the open source world is in the “leech” label, applied to those who use plenty of open source software without contributing much on their own. After all, the image of one’s very lifeblood being sucked away is pretty scar(ce)y! As with my recognition example above, whether the feeling of being “leeched from” is justified or not, that feeling can only be present in a giver who isn’t giving freely (if he’s giving freely, there are no strings attached, so there’s nothing to leech onto). And here too, if the giver recognizes this feeling as it arises, he can inquire into it more fully before he acts. For example, the developer might recognize that he doesn’t feel leeched from (and might even feel validated by) any number of end users who freely use the code without compensating him in any way; but he feels indignant toward a corporation that uses his code in a profitable product. He might recognize that, if he felt financially secure (abundant), his indignation might vanish. Or alternatively (or possibly even at the same time), he may feel a strong sense of obligation to contribute to open source projects as compensation for having used them extensively, and has formed an expectation that other skilled individuals should do the same. When people do not meet his expectation, he feels cheated/leeched from/etc.

Here, we have an opportunity to uncover some of the most subtle strings that we attach to our gifts. When we “give back” to an open source project out of a sense of debt (scarcity), to compensate for something that we “took” from the project, then we’re not giving freely, even if we are giving virtuously! We may even end up attaching more strings to the gifts as a recipient, than did the giver who gave them!!

This is an extremely subtle point, so I want to make sure I’m being clear. I’m not at all suggesting that any gift motivated by the natural sense of gratitude is tainted. On the contrary, gratitude is an uplifting feeling that propels us to give freely. It’s debt that weighs us down — its gifts become laden with that emotional burden. Gratitude allows us to spontaneously gift it forward; debt constrains us to pay it backward.

When we give freely, we invite others to take freely. We enable them to utilize the gift from their highest level of creativity. Whether they then give freely to us, give freely to others, or do not give freely to anyone, is out of our hands, and we’re okay with that. The better we get at giving freely, the more trust we develop in the process itself. We loosen our possessiveness towards our gifts, and shift our identity towards the source of those gifts. Instead of an idea bank with depreciating assets that we have to protect at all costs, we start to see ourselves more confidently as an idea mint capable of dynamically creating solutions.

Open Source is a wonderful way to experience this power, and I feel an abundance of gratitude towards everyone who makes it happen.

4/14/2011 UPDATE: Here are some interviews with me and other M-Prize folks:
http://www.managementexchange.com/blog/voices-mix-human-capital-m-prize-winners

2/1/2011 UPDATE: My submission has been selected as one of the semifinalists for the HCI Human Capital M-Prize:

http://www.managementexchange.com/blog/10-ways-unleash-best-and-ignite-passion-your-people

I’ve been following the Management Innovation eXchange (MIX) website for a while now, and there are a lot of great ideas that are posted and talked about. I think it’s an excellent forum to share and discuss ideas with a bunch of creative, talented people from all over the map.

I’ve been looking for a forum to share an idea that I’ve had for a while, and MIX gave me an ideal venue. It’s about empowering employees to fund their own initiatives with company-matched bonus money. Check it out:

Bonus Fund: Empower employees to fund initiatives with company-matched bonus money

In the richly symbolic world of Harry Potter, dementors are creatures which suck out all the hope and joy from life. Under their sway, people wander around aimlessly in an icy fog of depression, out of touch with their true nature and capabilities. I think the name and associated imagery they conjure are an excellent way to illustrate a category of dysfunctional interactions that go on in organizations today. (Don’t worry, there’s also a real-life analog to the Patronus charm).

A “real world” dementor is someone in a position of authority or influence who consistently asserts the priorities of one or more of the organizational dimensions in a way that conflicts with your own priorities. (More fundamentally, they assert the priorities of one or more of the underlying psychological functions in a way that conflicts with your priorities for those functions, but we’ll stick with the organizational terminology here since it’s simpler). For example, a business-centered Sales Director might encounter a dementor in the form of a Vice President who regularly throws people-centric wrenches into their interactions. The Sales Director is all set to hire a new salesperson who brings a strong reputation of closing big deals, with his colleagues concurring, and the VP raises an objection about how blunt the candidate was during the interview process. And when the Sales Director wants to design a compensation scheme for his team that focuses primarily on sales performance, the VP interjects from left field about making years of service (as a measure of company loyalty) and peer rating (as a measure of teamwork) more prominent. The VP also offers frequent, unsolicited advice to the Sales Director, phrased in generalities like how he should temper his zeal for marketshare and make personal relationships with his colleagues a higher priority. He “sagely” recounts how he too was once preoccupied with the bottom line, how he grew from that, and how he knows exactly what it’s like to be in the Sales Director’s position. The Sales Director, of course, feels exactly the opposite — that the VP has no real empathy for him at all.

The degree of a dementor’s impact depends on the intensity of one’s identification with an organizational dimension. If the Sales Director is so identified with Business that he sees any People considerations as irrelevant or even a weakness to be treated with contempt, he will be highly susceptible to the dementor’s power. Lots of his energy will be drained in his conflict with the VP. That conflict might be externalized (e.g. heated arguments), or internalized (e.g. passive aggression). Either way, he’s fighting a losing battle.

But the solution isn’t to submit to the dementor’s ways either. A business-centered person who forces himself into a predominantly people-centric approach becomes a watered-down, milquetoast version of himself, and is a far less valuable contributor. (The same logic applies conversely, of course, for people-centered persons, and for the other dimensions). In Jungian personality type terms, this is called falsification of type, or false type development. If the Sales Director sets aside his own instincts and substitutes the external “wisdom” of the VP, he will likely overcompensate by hiring salespeople who are pleasant but lack a competitive edge, and he’ll design compensation plans that reward people who are popular with their peers but who don’t sell much. He’ll suffer in the icy fog of despondency, because he’s not being true to himself and what energizes him. Organizations that allow this to happen on a large scale end up with a demotivated, demoralized workforce who may behave politically correctly and give lip service to the idea of being “well-rounded”, but who in fact can’t reach their full potential and are limited to mediocrity.

If neither constant conflict nor constant subjugation are desirable outcomes when dealing with dementors, what else can we do? This is where mentors come in. Mentors help us develop the patronus of self-awareness, which dispels the negative energy from our encounters with dementors, leaving in its place a clear-headed set of interactions with people of all dimensional affiliations. To illustrate this, let’s look at another example.

This time, let’s take someone who identifies with the technology dimension. This person lives and breathes information technology, has a keen instinct for breakthrough innovation, and is intent on driving technological changes that will have a huge positive impact on his organization. The problem is, he is beset by dementors on a regular basis. A business dementor nags him about quantifying a financial return on investment for all of his projects. A people dementor criticizes his bold approach and admonishes him to get approval from everyone before starting new initiatives. And a process dementor raises objections about how his projects don’t conform to rigid policies. Fortunately, the technologist finds a mentor who says he can help him solve his dementor problem. Let’s pick up the conversation between the technologist and the mentor, after the mentor has explained the organizational dimensions and set the context for the discussion.

Technologist: I suppose you’re going to tell me that I need to align with their “business needs”, get “buy-in” from all of them, fit into their “process” for doing things, and set aside my technology interests, right? Because –
Mentor: Heavens no!
T: — that doesn’t work at all!
M: Of course it doesn’t. Because you’re not motivated by their business needs, their interpersonal needs, or their process needs.
T: Finally, someone who understands.
M: You have your own business, people, and process interests.
T: Huh?
M: It’s true.
T: What do you mean?? I can’t STAND the suits who blather on about “walletshare”, the touchy-feely folks who want to sing Kumbaya, or the pencil pushers who need to document a process for everything.
M: And yet, how did you respond to the guy last week who was complaining about your company’s low ranking in corporate donations?
T: I told him that our company had nothing to be ashamed about, that we contribute to society in a huge way by building great products and services that make a difference in people’s lives. I also had to confess how proud I was of that accountant who found a perfectly legal tax loophole that saved us a hundred million dollars last year. Because of that, we were able to invest in a new manufacturing plant that’s so much more efficient, and pass on the savings to our customers.
M: Now who’s the “suit”? But wait, didn’t you also come down harshly on the layoffs in XYZ division?
T: Yeah, that was horrible. They barely gave any notice or severance pay. I could understand if the whole company were about to go under and we had to stop the ship from sinking. But we have plenty of cash! There are some great people in that division who would make outstanding contributors in other parts of the company. Sure, there’s some deadwood too, but some of that is the company’s fault for not managing well. In any event, we can easily afford to give people a good severance package.
M: Looks like you’re singing Kumbaya in your own key. And say, how did that server build incident turn out?
T: That was ridiculous. A couple of new hires in operations would download random operating systems from the Internet, and then build new production servers with whatever OS they were trying out that day. I first pointed them to a lab where they could experiment with any software they liked, and then, sat them down and explained to them the value of a production build p…process, oh you got me.
M: Sounds like something that a pencil pusher would approve.
T: I get it, I get it. I guess I do have interests in the business, people and process dimensions as well, even if those are largely subservient to my technology interests. But how does recognizing that help me deal with dementors?
M: Next time you see them, keep in mind your own interests in all of the dimensions, not just the areas where you disagree. When they’re speaking, center your attention on their overall presence, not just the content of what they’re saying. And see if you can identify any common goals or approaches.

After a few months, the technologist reports back to the mentor:

M: How did it go?
T: It was a different experience, that’s for sure. I heard the business dementor present at a division review meeting, and he was as irritating and dismissive as usual, describing technology as just a means to a monetary end. But then I noticed how organized his presentation was, how he illustrated his points with clear examples, and how he finished on time. I still thought he was clueless, but I wasn’t as worked up about it as I was in the past. As a result, I was able to pay better attention to the next speaker, a peer of the dementor’s who was business-centered as well, but with a much different attitude. He started off by acknowledging his limitations in keeping up with technology, talked about the core mission of the company and how it created real value for customers, and where he thought we could do an even better job. If I were still fuming at the dementor, I might have started to play buzzword bingo on this guy, because he did use a lot of big words. But I was able to pick up on the subtleties of his presentation, and saw an opening for one of my favorite technologies. I later exchanged a few emails with him and he’s agreed to sponsor a pilot project. Not once did he harass me about return on investment or anything like that! And although he’s no technologist, he seems to understand the ethos, and I find myself extending more trust towards him as well. Could be the start of a strong partnership.
M: Great! How about the other dementors?
T: Well a funny thing happened to the people dementor — he just vanished! I mean, he’s not a dementor anymore. Instead of immediately reacting to his comments, I just acknowledged them in a neutral way. After a couple rounds of this, he stopped offering me unsolicited advice. I guess he was feeding off of my comments just as much as I was reacting to his, and when I shut down the fuel line from my side, that extinguished the flames.
T: As for the process dementor, I realized how he could save a lot of licensing costs on his bean counting software, and I shared that with him, no strings attached. I was just looking for other areas where we had common interests/goals. He was so grateful that although he’s very strict about his policies, he told me he’d be willing to make an exception for my projects.
M: Looks like a resounding success!
T: Thanks, I owe it all to your advice!
M: You’re welcome, but all I did was point you to what you already had within yourself. Keep that in mind, and you’ll do just fine.

Granted, this was a summarized version of an admittedly hypothetical scenario. But it’s based on a lot of real-world experience. Mentors and dementors are, of course, just labels that we apply to people who evoke different responses in us. But the internal distinction is immensely valuable to make. We can use our natural talents to grow beyond them and develop broader self-awareness. Or we can become self-defeating and end up more fragmented.

This is especially important to keep in mind when you are in the position of advising someone. Are you behaving like a mentor or a dementor? (I know I’ve been both!) Are you blindly overlaying your own map onto them or just parroting someone else’s advice? Or, are you looking at them as a unique individual, seeing their potential, empathizing with them, and reminding them of who they are and what they can be?

Expecto Patronum!

In Transforming Your Company with Open Source (slide 9), I list some of the distinctive characteristics of four fundamental dimensions of companies:

In slide 15, I relate the nature of these dimensions to the nature of the psychological functions in Jungian personality theory (see the first few paragraphs of Personality Type and the Open Source Community for some more background information). Although the organizational dimensions aren’t as clearly orthogonal or as polar as the psychological functions, there’s enough there to generate the same kind of dynamics. I think we can go so far as to map these dimensions to their most closely affiliated function:

I’d like to clarify that I’m not trying to reduce each organizational dimension into its corresponding psychological function. We can use all of our functions when working on any of the organizational dimensions. What I am pointing out is the tendency for a function to have a characteristic association with its corresponding dimension. For example, when we talk about making Business decisions, we’re almost always talking about T decisions that need to be made impersonally and objectively. When we’re exploring Technology, it’s N that is able to make the biggest leaps with invention and innovation. The People dimension is full of complex F considerations — values and relationships. The S attention to detail is instrumental in defining and precisely executing processes that are grounded in reality.

This becomes even more evident in the simultaneously complementary and contentious interactions between the polar-opposite pairs T-F and N-S. T wants to make objective decisions and F wants to make personal decisions. S wants to look at specific experiences and N wants to look at general observations.

According to Jungian personality theory, when we develop our personalities, we develop, or differentiate, a preferred function for taking in information (either N or S) and a preferred function for making decisions (either T or F). As we gain competence with our preferred functions, we tend to identify with their ways of seeing and dealing with the world, and to disidentify with their opposites. For example, a T type might pride himself on making the “right” decisions based on objective criteria, irrespective of his personal feelings. Whereas an F type might pride himself on making the “right” decisions based on his personal values, irrespective of the circumstances. As we grow, we discover the limits of our preferred functions, and realize that they’re only giving us half the story. We then proceed to integrate the perspectives of the other two functions. We still retain our preferences, but we relax our grip on them. We recognize the value of others who are strong in areas that we are not. We can see the world more clearly, and can make wiser decisions.

Now let’s tie this back to the organizational dimensions, particularly as they are embodied in large organizations. Take a “business type” who prides himself on results like increasing market share, expanding the size of his company and maximizing financial return on investment. He may see the technology, people and process dimensions as necessary costs of doing business. He may even recognize that, when developed, they can give his business a competitive advantage. But apart from that, he doesn’t dwell on them. He’s not interested in “technology for technology’s sake”, he isn’t a “people person”, and he doesn’t “tolerate bureaucracy”.

The same kind of picture can be painted for others who identify strongly with the people, process or technology dimensions. They may see the business dimension as necessary for providing their job and paycheck. They may even recognize that, when developed, business can yield new opportunities and enriching experiences to learn and contribute, and evolve in their areas of expertise. But they’re not “business people” — they’re motivated more by other things.

It’s valuable to develop a basic level of competence with each of the dimensions. This helps us gauge where our energy, skills and interests are most aligned, and where they aren’t. We can ascertain where others can be most helpful to us and where we can help them. We can then proceed to develop mastery-level expertise in our most closely aligned dimension(s), with a minimum of distraction or second-guessing.

Just as with the psychological functions, as our awareness increases, we can integrate the perspectives of the other organizational dimensions into our thinking. Our attitude goes from seeing the other dimensions as unavoidable nuisances, or accepting them in a utilitarian, transactional kind of way, to actively recognizing their value on their own merits. We are then able to place solid trust in those with strengths in other dimensions, and work with them interdependently to achieve broader goals.

In building this awareness, I think it’s important to keep in mind this insight from personality theory: We realize our highest potential when we honor our natural preferences, not when we shortchange them. That doesn’t mean that we cling to them, but it does mean that we don’t fool ourselves into expecting great results when we adopt someone else’s preferences instead. Trying to turn a process-wonk into a technology wizard (or vice versa) is ultimately a recipe for mediocrity, not excellence.

When organizations coach people with these principles in mind, they can optimize the talents of their people and accelerate their professional and personal growth.

Update: 9/28/2009: Added slides

Here are the slides from my LinuxCon 2009 presentation on ways to transform your organization with open source. It builds on insights from Open Source and Interdependent IT and many other areas.

Make sure to browse through the notes for the slides as well. You can download the document from the slideshare.net page.

Here is the abstract below.

How do you get past incremental change to real transformation with open source? Most conventional advice focuses on just one dimension at a time: people, process, business or technology. To get breakthrough results, you need to view these dimensions as part of an integrated whole, and consciously address two or more of them simultaneously. Using examples from Enterprise IT experience, we’ll explore how you can tap your organization’s strengths in a variety of ways to achieve these goals. The audience for this session includes technical leaders as well as managers who want to drive change through open technologies, processes, communities, and business models. The session will discuss approaches that can be used by people in a variety of roles.

In The Seven Habits of Highly Effective People, Stephen Covey presents a maturity continuum that progresses from dependence, to independence, and then to interdependence.

Dependence, Independence and Interdependence

Covey concisely observes: “Dependent people need others to get what they want. Independent people can get what they want through their own effort. Interdependent people combine their own efforts with the efforts of others to achieve their greater success.”

As we develop along this continuum, it’s obvious that our level of capability expands tremendously. In the workplace, dependent employees need guidance for major work tasks; independent employees can figure out what they need to know, but they might not share that knowledge; interdependent employees, in addition to their self-sufficiency, are constantly learning from and teaching their network of peers. Interdependence is highly regarded by employers, and shows up on many statements of corporate principles and values.

So how can IT organizations actually develop interdependent thinking and behavior? Here’s where open source comes in. People need experiential learning opportunities that present themselves in day to day work. In my experience with IT organizations, open source (and more broadly, open ways of working) has the power to fundamentally improve the way that people work. In the course of doing their jobs, they can readily adopt behaviors and mental models that move them higher on the maturity continuum.

Consider the staff of a dependent IT organization whose relationship with a proprietary vendor centers around licensing and support fees. If they want a new feature added to the product and the vendor has other priorities, there’s not much they can do. They may be able to get some attention by offering to pay even more money. But even if money talks, if it’s the only thing that can talk, the conversation becomes significantly constrained. Worse, if they carry that same mindset into internal interactions, thinking that “this is the only way that business works”, they risk reducing their own position to a zero-sum game where they can win only by competing for scarce funding. They then remain largely unaware of and unable to tap into the broader resources that they already possess, both individually and collectively.

Open source can liberate IT organizations from that dependence. For starters, they no longer have to pay a licensing fee and can run as many software instances anywhere they want, anytime they want. This is especially relevant in virtualized, cloud computing environments where most traditional licensing metrics (like the number of processors) effectively stifle exploration. They’re welcome to customize products as much as they want to, since the source code is freely available. Even if they don’t have the skillset to fix bugs or make enhancements, they can choose to contract with any company that does. In all of these cases, they become more independent than they were before. As they continue to develop, their vocabulary grows to include a fuller range of their skills and capabilities. This enables them to make more granular, intelligent tradeoffs across the spectrum of buying, integrating and building. At the independent stage, IT organizations learn to control their own destiny.

IT Organizations get a taste for interdependence when they contribute code changes to an open source project. For example, let’s say they submit a simple patch to make a particular parameter configurable instead of being hardcoded. Once this change is accepted, instead of having to re-port this patch each time they download a new release, they can rely on it being maintained by the project developers. Developing trust with the project team can encourage them to make further contributions, with the immediate payoff of support and the longer-term reward of getting their most important features added. What really expands their horizons is when they see their work being built upon and extended further by the community, in ways that they could never have previously envisioned. They realize how much more they can accomplish through collaboration than they can on their own. At the interdependent stage, IT organizations can have holistic conversations that represent the capabilities of an entire ecosystem, bringing it to bear to solve their employer’s specific problems. And as they solve those problems, they can contribute their learnings to advance the capabilities of the ecosystem, fueling a virtuous cycle.

Not all of this happens automatically, of course, or by some fixed timetable where after N months of implementing activities X, Y and Z, IT organizations graduate to interdependence and experience all of its benefits immediately. But it does happen naturally, when people with sufficient baseline capability are immersed in an open environment, are given ample coaching and support, and can see examples of highly skilled behavior in action. Let’s look at some on-the-job experiences that illustrate this point.

When IT organizations are customers of a proprietary product and something goes wrong, it’s easy for them to develop a kneejerk reaction to call the vendor and complain. For starters, they’re paying for support. But what intensifies this is when they feel like they’ve hit a brick wall and can’t go any further because the product is closed. If this happens frequently, they may give up even before trying, become even more frustrated with the vendor, or adopt some other less effective behavior. With open source, nothing stands in the way of their own problem-solving skills. IT developers can browse through the code and see if something catches their eye. They can invoke a debugger and see what might be happening in real-time. They can run third-party analysis software on it, or undertake a detailed review themselves if they have the time and inclination. The more familiar they become with a particular project’s code and with reading source code in general, the more competent they become at solving similar problems in the future. Even if they contract for support on an open source project, they can submit more informed requests that enable the support provider to zone in on their problem more readily. They can also gauge the competence of that support organization based on their grasp of the code, and switch to a better provider if necessary.

Working with high-quality open source projects instructively leads IT organizations to a deeper understanding of and appreciation for open architectures and open standards. Code that reflects a broad understanding of the problem that it’s solving, addresses it in a clean way, and is as simple as possible, tends to be accepted. Whereas code that defines a problem too narrowly, introduces unnecessary kludges, or increases complexity without substantially increasing usefulness, tends to be rejected. This is an effective counterweight against a tendency in many IT organizations to rush out incomplete solutions that end up causing more problems over time. When contributing code, IT developers learn to think more globally, putting themselves in the shoes of others who share similar challenges albeit in vastly different environments.

As they succeed with contributing to open source projects with the support of their employer, they gain the respect of fellow users/developers, which directly translates into leadership and influence. Their personal brands and their employer’s brand increase both in value and in affinity with each other. Employees get public recognition for their efforts, and simultaneously are incented to continue to be affiliated with their employer’s brand. This type of synergy is a hallmark of interdependent organizations.

An important lesson learned by IT organizations on the road to interdependence is where and when they can optimally invest their resources with open source projects. Some projects are very open to input from the practical experiences of Corporate IT. Other projects are unwilling to adopt suggestions that don’t align with their strict tenets. The best projects balance purity with pragmatism, maintaining the essence of what makes them valuable as a whole. While experimenting with various approaches, IT organizations discover which problems they want to solve on their own, and which ones they don’t. They identify where they want to be treated as a customer, where they want to interact as a peer, and where they want to play a leadership role.

People who work in this kind of environment, day in and day out, can develop strong collaborative networks all over the world. These networks help to identify those relationships with customers, partners, and others that can be transformed from largely transactional relationships into ones of deeper mutual benefit. They develop instincts for and insights into what makes blogs, wikis, and other social software work best, and can be invaluable in shaping their employer’s social media strategy. On a broader level, interdependent IT professionals are powerful catalysts of outside innovation as described by Patricia Seybold, and exonovation [interview] by Michael Tiemann. They can operate from a visionary mental model of commerce and community.

Open Source is a complex, multidimensional subject that intersects and often integrates the fields of science, technology, business and psychology. By expressly choosing open source as a strategy for developing interdependent capability, IT organizations can provide a growth path for knowledge workers that engages them in a variety of ways and on many levels. Those who become adept at making the interdisciplinary connections can represent their organization to a number of audiences in ways that are directly compelling, and can create new streams of value. They help bring a unified sense of purpose, energy, and vision that inspires people to realize their potential.

I manage my bookmarks in del.icio.us, and tag the ones that are blogs with the blog tag (in addition to subject-related tags). When I want to try out a new blog reader, I can easily export my bookmarked blogs to OPML, using the additional tags as first-level subcategories. If the RSS feed for a given blog isn’t discoverable with a <link> tag on the blog URL, I add it as a line in the notes section: RSS=http://someblog.com/rssfeed.

Here’s the Perl script, delicious_blogs_opml.pl, that exports blog links in del.icio.us to OPML format:

#! /usr/bin/perl
 
# delicious_blogs_opml.pl - Export OPML blogs feed from del.icio.us
 
use Net::Delicious;
use XML::Feed;
# use XML::OPML;
# XML::OPML doesn't work as expected
 
use strict;
 
my $debug;
$ARGV[0] eq '-d' and $debug = 1, shift;
@ARGV > 0 or die "usage: $0 [-d] delicious_username:password\n";
 
my %tags;
my ($delusername, $delpasswd) = split(/:/, $ARGV[0], 2);
my $del = Net::Delicious->new(
    {user => $delusername, pswd => $delpasswd, debug => $debug});
 
# Workaround for Net::Delicious:all_posts() not supporting a tags argument:
# $del->all_posts({tag => 'blog'}) 
$del->config('delicious_posts_all.tag' => '');
# Get all blog links from del.icio.us
my $res = $del->_execute_method("delicious.posts.all", {tag => 'blog'})
    or die "Error calling posts/all\n";
my $posts = $del->_getresults($res, 'post');
foreach my $post ($del->_buildresults('Post', $posts)) {
    my $title = $post->description;
    foreach my $tag (split(' ', $post->tags)) { 
        $tags{$tag}{$title} = $post unless $tag eq 'blog';
    }
}
 
print <<EOF;
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
<head>
    <title>blogs</title>
</head>
<body>
EOF
 
foreach my $tag (sort keys %tags) {
    print qq(<outline title="$tag" text="$tag">\n);
    foreach my $blogname (sort keys %{$tags{$tag}}) {
        my $url = $tags{$tag}{$blogname}->{href};
        my ($feedurl) = XML::Feed->find_feeds($url);
        if (!$feedurl) {
            my $extended = $tags{$tag}{$blogname}->{extended};
            ($feedurl) = $extended =~ /^RSS\s*=\s*(\S+)/im;
        }
        $feedurl or die "Could not find RSS feed for $url\n";
        print qq(\t<outline title="$blogname" text="$blogname" type="rss" xmlUrl="$feedurl"/>\n);
    }
    print "</outline>\n";
}
 
print <<EOF;
</body>
</opml>
EOF