Don't blame, accept responsibility

An instructive chart in Flying Without a Net: Turn fear of change into fuel for success by Thomas J. DeLong ( >www.hbr.org ) is the ‘Problem-solving curve' with four stages, viz. deny, ignore, blame, and accept responsibility. “When we believe we have disappointed someone else and, more important, ourselves, we deny a problem exists; this is how the process starts. After we deny, we then ignore the problem for as long as possible. Once the situation is just too obvious and too painful to ignore, we transfer the problem to someone else,” the author explains. He cautions that ‘blame' is the stage in which we often become stuck for an extended period of time, finding creative ways to rationalise our behaviour and stick it on someone else, and demonising the other person to avoid seeing ourselves in a negative light.

To illustrate how this happens, DeLong introduces us to ‘Jack,' a fast-track software executive who has capitalised on his technology expertise and his business acumen to become one of the youngest vice-presidents in his large software company's history. At 35, Jack has hopped from one position to the next and turned in stellar performances consistently; and even when he has encountered problems in the past, he has found ways around them using his considerable knowledge and skills, we learn.

“Jack is assigned responsibility for the team that's introducing a new software product with tremendous market potential – it's based on a revolutionary technology that competitors lack, and Jack's company has invested heavily in it. Jack is confident in his ability to lead his team in the product's successful introduction. Things go well initially as the team formulates market and distribution strategies, marketing, and so on.”

Glitches, flaws

Just when you wished that the narrative wrapped up with the happily-ever-after phrase, we see Jack encountering the first glitch during a beta test, with a significant percentage of the products failing to perform effectively. At first, Jack adopts his typically aggressive problem-solver approach, providing motivation and technical insights to help his team deal with the design flaw, continues DeLong. “But the problem persists despite his team's tweaks to the design, and frustration sets in. Shortly thereafter, a competitor introduces a similar product based on a different technology, beating Jack's company to the market.”

As you would have predicted, Jack's bosses are furious and place tremendous pressure on him to fix the design error and get the product to market as quickly as possible; yet there are further delays. Time for a showdown? Yes; the company CEO calls Jack into his office and says that Jack has let him down. What is his response? “Jack protests that it is not his fault but that of the three designers who had primary responsibility for the product, claiming, ‘I'm only human' and ‘I believed the information they gave me.'”

DeLong draws attention to what Jack doesn't say – that he took on this project without making the effort to understand the product's technology fully; that he felt ‘dumb' when he started asking people questions about it and hated how he felt; and that he decided that he really didn't need to know the technology ‘at a grassroots level' and would just trust his people.

Own up to your role

What the author finds more alarming in the episode is that Jack's people did inform him early on that there might be a potential issue with the design and that it would be wise to consider some alternatives, but Jack was so intent on delivering the product on time that he brushed aside their concerns. “Though the team eventually got the design right and introduced the product with moderate success, Jack requested reassignment to a team that was working on a project in his sweet spot – he knew the technology and the market thoroughly. Still, for months afterward, Jack continued to blame the designers for the blemish on his record.”

Laying the case on the table, DeLong notes that like many ambitious professionals, Jack could not use his problem-solving experience to learn and grow. And that Jack could not tolerate the vulnerability he felt when things did not go according to plan – his plan. “He was unable to accept blame and the reflection and self-assessment that come with it. Instead of learning, changing, and growing as a result of the experience, Jack returned to the comfortable quadrant of doing the wrong thing well.”

The author, therefore, urges managers to recognise that it takes considerable time to move to the point in the problem-solving curve where we accept appropriate responsibility. We must be brave enough to own up to our role without personalising the problem and experiencing shame, he advises. “From this frame of mind we can move to the problem-solving stage and action focus. This is where we begin to see that this discomfort won't kill us. We start to recognise that we can and will survive our vulnerability, and that we don't have to blame others.”

Ideal material to work with, over a week-long top management retreat.

FOSS at the fringes

The success of the Free and Open Source Software (FOSS) will be measured by the extent to which FOSS-based applications make a difference in people's lives, especially those who face serious issues related to marginalisation and discrimination, says Pradip Ninan Thomas in ‘Negotiating Communication Rights: Case studies from India' ( >www.sagepublications.com ).

Adding that there is a potential for numerous applications, given the size of the population in India and the extent of poverty that affects more than 300 million people, he reminds, however, that access for all is a problematic issue not only because of the lack of connectivity but also because there is little graded information on the specific ways in which FOSS can be used for making a difference to the lives of very specific communities.

“The typical ICT solution of telecentres and silo projects favoured by governments, the private sector and NGOs have serious drawbacks given that, for all practical purposes, such projects do not differentiate between marginalised and the not-so-marginalised communities in any given area. Applications of FOSS too, given the involvement of mainly middle-class enthusiasts, favour a range of open freedoms – such as Open Publishing and Open Content such as on Wikis.”

Include marginalised communities

While acknowledging the importance of the exploration of technology-enabled creative learning, Thomas argues that it is necessary for the FOSS community to publicly identify with projects that extend the access and use of software and hardware by marginalised communities.

In his view, the most powerful use of FOSS in India is by organisations involved in advocating access for differently-enabled people. Names that find positive mention include the Thiruvananthapuram-based SPACE, the Bangalore-based Centre for Internet and Society (CIS), Inclusive Planet, and ELCOT. For instance, Thomas informs that CIS's involvement in the Right to Read Campaign is aimed primarily at amending the Copyright Law in India that prevents the sharing or copying of books by visually-impaired people, raising public awareness, and lobbying in favour of the Treaty of the Blind proposed by the World Blind Union at the World Intellectual Property Organisation (WIPO).

He observes that, at a practical level, projects such as ‘Bookbole' that allows access to books for the visually-impaired in India, and the numerous training and capacity-building programmes for the visually-impaired organised by different agencies using FOSS-based software are small measures aimed at overturning a major divide in Indian society. “The Insight project at SPACE uses FOSS to train the visually-challenged to access and use new, enabled technologies. These include the use of a screen-reader software called Orca that allows for computer navigation through the reading out of text that appears on the monitor. SPACE also has a dedicated audio programme ‘Swaram' for the visually-impaired, in Malayalam.

Open challenges

Importantly, in the author's view, a key challenge for FOSS is to become a tool for advocacy related to the Right to Information and other movements committed to the extension of human rights and democracy in India. This, apart from the difficulties in creating Unicode-based localisations of Indian language fonts by a variety of FOSS communities throughout India such as the IndLinux project and Indic versions of GNU/Linux, Mozilla, Open Office, along with numerous government agencies such as C-DAC and NRC-FOSS.

Thomas reckons that NREGA allied with the RTI offers an extraordinary opportunity for the Indian government to deal with issues related to poverty and discrimination, transparency and accountability; and that FOSS can make a difference here. Calling, therefore, for a closer synergy with RTI and other movements, he underlines the need to convince the government that in matters such as e-governance there is really no option but to use FOSS.

Insights of macro-impact that can energise communications professionals to also engage with initiatives of significance to development.

> dmurali@thehindu.co.in

Tailpiece

At the special land-grabbing cell:

“Sir, my site has been snatched!”

“What is the survey number?”

“I can give you the URL…”

COMMENT NOW