(7 votes, average: 4.29 out of 5)
Loading...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.
In spite of the optimistic view that enterprises can develop internal skills to provide their own technical support for Open Source Software packages, few actually do develop and maintain those skills. Where an enterprise lacks the internal skills to provide its own professional technical support, they need to turn to support providers just as they turned to the proprietary software developers’ support teams. The Open Source Software technical support market is consistently less expensive than comparable cost of support for proprietary products but it remains a legitimate cost that most enterprises need to budget … either in a commitment of internal resources or in a contract with an external provider. Using Open Source Software without a support plan is self-insurance with a potentially large deductible as it can be quite difficult for qualified technical support staff to suddenly get engaged and come to grips with Open Source Software integrated by the enterprise. Furthermore, enterprises need to qualify their support vendors to make sure those providers actually have team members capable of supporting mission-critical software (MySQL, Apache httpd, OpenLDAP, etc.). We agree that enterprises that become internally competent achieve the benefits you suggest but most are unwilling to make the financial commitment to sustain such a capability year on year in the face of business pressures. The technical support specialists will continue to be a valuable service pool for Open Source Software much as they are for proprietary software.
One point that I hope doesn’t get lost here is that even IT organizations that develop internal competence can contract effectively with open source technical support specialists. As I mention:
“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.”
Compared to dependent IT organizations, interdependent IT organizations can make better use of the talents of technical support specialists, since they have a deeper understanding of the value that those companies provide.
Well-put, Kartik! Marty offers a realistic, pragmatic reply. However, I’m seeing my employer dabble with the model that Kartik describes. Our Open Source & Linux Profession (OSLP) runs several development services that benefit our corporation. None of us doing this for the OSLP are IT workers, but we have had conversations with IT. Let’s say that they’re “intrigued” at this point. Could take years. Developing…
Great article Kartik. I think this is a great model. I have seen the power of open and collaborative IT development in my own experience. Unfortunately, I have also seen the difficulty in getting organizations to change their mindset and be open to this kind of approach. It can be done though, it just takes time and some level of trust building. I think the key is to just give it a shot and use small successes to pave the way forward.
[…] Open source leads to interdependent employees (as opposed to dependent or indep) http://kartiksubbarao.com/open-source-and-interdependent-it […]
Kartik – I like the use of Covey’s model as a way of describing the effect on behaviors (or perhaps the required behaviors) of those that participate in Open Source Software development. Many of the points made here, as you suggest, apply well to the concepts of Open Innovation and may result in similar beneficial outcomes. Nice work.
Likewise, Open Innovation and Open Source share many challenges. In particular, if the decision makers sitting higher up in the food chain are not themselves interdependent, then the ability for folks in lower levels to participate in open models is significantly constrained. In my mind, a key catalyst to moving IT organizations (and others) into a more open mindset is through a top-down approach. There needs to be active encouragement, rewards, and a clear support structure (e.g. support for experimentation, failures, etc.) for folks to “participate” and embrace open principles. Otherwise, the reward system is not aligned with the model presented here and interdependence remains remains relegated to corporate statements.
Great connection to Covey! There is a growing attention in the open source field for the human factor in decision making on open source applications in enterprises. Which is good. Because it is complex to get a yes for Open Source in situations where it can add value. As an Open Innovation Ambassador I have to admit that there is lots of organisations where Open Source Application and its services suppliers network (if any) is not suitable at present.
In cases that we do have a great Open alternative to Closed Environments we have to be patient indeed. We can tell them, we can show them, they will see it, they will hear it, but in the end it is what people believe that makes the difference. Open Source has not yet come to the point that decision makers and IT directors feel backed by the currently available software, the infrastructure and services suppliers. System integration in Open Source sucks big time, if I may be so blunt. There is more. If all the worldwide available Open Source service suppliers would have to service 1% of the enterprises worldwide, we would run short on capacity quickly. It is no use blaming decision makers as long as we ourselves (the Open minded) focus only on the positive effects of Open Innovation.
But we are getting there! Let us shift our attention more towards customers concerns about Open Source. These issues go way beyond software features, staffing and hiring suppliers: e.g. Total Cost of Operation, how to sell it to the boss, smooth integration, network of suppliers, training, and … building trust.
Using open source software is becomming an industry standard, however the most basic questions remain. That is compatibility of various open source licenses, and this is a very big legal issue. Let’s take for example an IT organisation, downloaded a sourcecode with a GPL component or licensed with GNU GPL. Now to make the required innovation it requires an EPL component or licensed using Eclipse Foundation’s EPL. The innovation will not be possible since EPL and GPL are not compatible licenses, meaning that the GPL license conditions are breached and that the originator of the GPL license can sue your organisation.
It made me cry. So many dreams, so many failures, is there really a company out there that can get past the crud and collaborate successfully? If so, hire me.
[…] I Interdependent ? By brunocornec Reading the brilliant article that Kartik Subbarao wrote recently on Open Source and Interdependent IT , I was questioning myself […]
Very interesting Kartik, as usual. And always inspiring: http://brunocornec.wordpress.com/2009/09/12/am-i-interdependent/
Well written, well developed, well presented thesis, Kartik. As some of my peers on the HP Open Source and Linux Profession leadership team (past and present) have already mentioned, this resonates with our own experience. I experienced a particular moment of recognition in reading your description of the limitations we place on ourselves by reducing all decisions to monetary ones. Many of us in business will identify with the general Catch-22 mindset that says “We can’t develop this capability for the marketplace because there’s no demand, hence, no business justification, no future revenue stream”. (The obvious Catch-22 here is there’s no market because we haven’t developed the products(s) that would helpcreate, or at least grow the market.)
I hadn’t considered the Open Source model from this point of view (interdependence) before, but like so many other ideas that weave the fabric of this development model it seems intuitively obvious in retrospect. I suppose another aspect of this I find personally appealing, if occasionally frustrating, is that it reinforces the notion that this is a marathon, not a sprint. It’s a continuum that individuals and IT organizations alike can position themselves along at any given point in time, and change only infrequently appears to happen quickly. But change is the only true constant, and it’s inevitable given sufficient time. We’re making inroads with our own IT organization that will bear fruit, and I suspect we are approaching a tipping point. I’ll keep my fingers crossed.
A good model indeed! … Looking at your Dependent-Independent-Interdependent model, it reminds me of a line… “We are taking apart each task and sending it…to whomever can do it best… and then we are reassembling all the pieces.” – from Thomas Friedman’s ‘The World is Flat’. I’m trying to related it to the “Bottom Up” approach this book talks about. Having said that, I worry how so many versions and licences of a open source software (OSS) is maintained and integrated as rightly pointed out by Ian Vernon in his comments. What’s your take on that? What should be any IT organization’s considerations (benefits and losses) before thinking about OSS as a long term strategy if not immediate? Will you agree that any big organization (already having vendor relationship) should not go for OSS in entirety but only where required as this may take some time to mature?
> Looking at your Dependent-Independent-Interdependent
> model, it reminds me of a line… “We are taking apart
> each task and sending it…to whomever can do it
> best…and then we are reassembling all the pieces.”
> – from Thomas Friedman’s “The World is Flat”. I’m
> trying to related it to the “Bottom Up” approach this
> book talks about.
Yes, I agree that Tom Friedman does an excellent job of
explaining the emerging realities and possibilities of
the flat world. In fact, this same
delegation/specialization model is very common to Unix,
Linux and many other other open source projects. Good
interfaces defined by open standards, with each component
focused on its particular job, integrated effectively
across the board.
>Will you agree that any big organization (already having
>vendor relationship) should not go for OSS in entirety
>but only where required as this may take some time to
>mature?
I don’t think that open source is an all-or-nothing
proposition, and can certainly be implemented as a phased
approach. Adopting interdependent, open ways of working
throughout the areas of people, process, technology and
business is the broader goal. That will naturally
translate into a strategy of preferring (and contributing
to) open source software, but proprietary software can be
part of the mix too, if its value is well-understood.
Hi Kartik,
Nice attempt, but I am not able rel;ate it well since I am not attuned to to the IT processes and jargon. Can you make an attempt to tailor / model it to the industry in general?
One of the resources that I mention in the article is Patty Seybold’s blog on Outside Innovation:
http://outsideinnovation.blogs.com/
Check it out and I think you’ll get a good appreciation for the kinds of collaboration that are possible between employees of a company and its customers.