Archive for the ‘Communication’ Category
Conflicts over identity: on the relationship between software developers and project managers
Introduction
The relationship between software developers and project managers is often fraught with conflict. Yet they have to get along professionally: the success of a software project depends to a large extent on whether or not they can work together. A paper entitled Stop whining, start doing! Identity conflict in project-managed software production, published in the May 2009 issue of Ephemera, delves into this issue by looking at how the two parties view themselves in relation to each other. This post is a summary and review of the paper.
A quick word or two before diving into the paper. First, identity conflict occurs when a person or a group feels that their sense of self (i.e. their identity) is threatened or denied legitimacy and respect. Second, although the title of the paper suggests that it deals with identity conflict in project-managed software production, the authors’ focus is considerably narrower: the analysis presented in the paper is based on selected Slashdot discussion threads involving software developers and project managers. In effect, the authors draw their conclusions about identity conflict in software production based on opinions expressed online forums. It is, I think, stretch to read too much into such exchanges. I’ll have more to say about this in the final section of this post.
The authors of the paper, Peter Case and Erik Pineiro, begin their analysis by noting that although project managers are usually above programmers in the organizational hierarchy, the relationship is complicated by two factors:
- Project managers usually do not need (and often lack) the educational qualifications possessed by programmers.
- Project managers usually do not have the depth of technical knowledge that programmers have.
These two conditions often lead to the view amongst programmers that they (the programmers) have a higher organizational status (or matter more) than project managers do.
The authors end their introduction with the observation that the skills of programmers are necessary for the creation of software, but equally necessary is the need to direct software building efforts using some form of project management. This observation underlines the symbiotic relationship between developers and project managers. On the other hand the differences between the two disciplines is also a source of conflict between the two parties. The main aim of the paper is to highlight how this conflict plays out in online discussions involving developers and project managers.
Research Methodology
Case and Pineiro base their research on an analysis of contributions to online discussions on Slashdot. A large number of Slashdot contributors are programmers. The discussions cover a range of topics of interest to coders – from the merits of particular technologies, to outsourcing, aesthetics and personal philosophies of programming. The authors use two ideas (or, more accurately, lenses) to interpret the data, the data being individual contributions to discussions.
First, the authors contend that contributors to Slashdot are:
… bringing about social effects through their displays of technical bravado, expressions of aesthetic preference and espousals of dissent, resistance and subversion.
In particular, when discussing the relationship between programmer and project managers, contributors – through the discussion – are creating (or confirming) a certain view of the relationship between the two parties. In doing so, they are enacting their own identities (as members of a particular guild). They do so in opposition to the other party – i.e. by setting themselves apart by negating the skills, knowledge and work of the other.
Second, the work that programmers do has a certain value in the marketplace – i.e it is created because of its (direct or indirect) commercial value. This has two consequences:
- Programmers feel that they have to compromise on quality (or aesthetics) because of time pressures and, on the other hand, project managers feel that programmers do not understand the commercial imperative to move the project forward.
- Both sides feel that their own specialized area of knowledge – technical or managerial – is the truly important one as far as the commercial aspects of the project are concerned.
The authors use excerpts from Slashdot discussions to highlight these two dynamics at work.
Data analysis and discussion
The programmers’ perspective
In Slashdot discussions, Case and Pineiro find that programmers articulate different identities depending on the audience. In some situations they express an interest in (or agree with the importance of) meeting deadlines, getting the product to market etc. Whereas, in other situations, particularly when responding to (or comparing themselves to) project managers, they might express an interest in code aesthetics – i.e. the importance of writing good, even beautiful, code. Several examples of the latter can be found in a discussion thread on software aesthetics. Many of the contributions to the discussion assert that (good) programmers have the following traits:
- Are passionate about their work
- Care deeply about quality.
- Understand of the importance of good code.
Several contributors make these points in opposition to the work-related traits of managers. That is, they set up a stereotypical manager – who doesn’t care about code quality etc. – as a foil for their rhetorical arguments.
Technical knowledge is another important way in which programmers set themselves apart from project managers. The contention here is that managers cannot really understand what a software system is because they don’t have the required knowledge; an implication being that they are not qualified to manage its construction. Case and Pineiro mention how this issue can really raise emotions when it comes to the issue of outsourcing (see this discussion thread for example).
The project manager’s perspective
Although the Slashdot community is dominated by programmers, the authors were able to find a few contributions that gave the project managers’ viewpoint. For example, a discussion on project management for programmers, gave some project managers an opportunity to articulate their views. In the discussion, project managers tended to focus on two aspects – performance (i.e. completing the project on time) and project management knowledge – both of which (they implied) programmers do not understand. See this comment for an example of the former and this one or this one for examples of the latter.
Project managers thus set themselves apart (i.e. construct their identities) as distinct from programmers. They are concerned with driving the project to successful completion and they have specialized knowledge and training to do this; both of which programmers do not possess.
The authors’ conclusions
From their analysis of selected Slashdot discussions, Pineiro and Case conclude the following:
- Software developers and project managers tend to construct their identities in opposition to each other – i.e. by setting themselves (their skills, motivations and concerns) as being different from the other. On the other hand, business imperatives require that they collaborate, so there is a symbiotic aspect to their relationship.
- Despite project managers being marginally higher up than programmers in organizational hierarchy, there is little difference in the status of the two. The reasons for this are: 1) Project managers lack the specialized technical knowledge needed to understand programmers’ work and 2) Software project managers’ are dependent on programmers – perhaps more so than project managers in other disciplines. As a consequence, the difference in status might rankle with programmers. Thus the hierarchical proximity of the two parties might also be one of the reasons for the conflict between the two.
- Both parties generally claim to have the same goal – produce quality software in reasonable time. They differ, however, in the means to achieve the goal. Programmers believe the focus should be on producing high quality code whereas project managers tend to emphasise the optimization of resources and time, whilst meeting the system requirements.
Wrapping up
The paper isn’t an easy read because of the wide use of sociological jargon, but then it is a research paper. The central idea – that online discussions can serve to construct or reinforce programmer and project manager identities – is an intriguing one. If true, it implies that one’s self (and projected) image influences, and is influenced by, how one describes oneself to others in speech or writing. For instance, does my claim that I’m a “seasoned database architect” and “experienced project manager” reinforce my professional identity? Also interesting is the idea that developer and project manager identities are often constructed in opposition to each other. That is, both parties appear to build their identities by casting the other in a negative light.
However, as interesting as all this is, I believe it misses a crucial point: that programmers and project managers, for the most part, play out roles which are defined and enforced by the organisations they work for. If organisational rules and norms require programmers (or project managers) to behave in dysfunctional ways, then that’s exactly what most of them will do. On the other hand, if an organisation encourages behaviour that fosters good working relationships between the two parties, things would be different: those working in such environments would have more positive experiences to to relate (this comment taken from one of threads analysed by the authors is a case in point). It is surprising that the authors chose not to include such (positive) comments in their analysis.
In brief: the paper presents an interesting perspective on the relationship between programmers and project managers. Even though the authors’ focus is somewhat limited, the paper is of potential interest to researchers and practitioners interested in work relationships in project environments.
Communicating risks using the Improbability Scale
It can be hard to develop an intutitive feel for a probability that is expressed in terms of a single number. The main reason for this is that a numerical probability, without anything to compare it to, may not convey a sense of how likely (or unlikely) an event is. For example, the NSW Road Transport Authority tells us that 0.97% of the registered vehicles on the road in NSW in 2008 were involved in at least one accident. Based on this, the probability that a randomly chosen vehicle will be involved in an accident over a period of one year is 0.0097. Although this number suggests the risk is small, it begs the question: how small? How does it compare to the probability of other, known events? In a short paper entitled, The Improbability Scale, David Ritchie outlines how to make this comparison in an inituitively appealing way.
Ritchie defines the Improbability Scale, 
where 
By definition, 
Let’s look at the improbability of some events expressed in terms of
- Rolling a six on the throw of a die.
- Picking a specific card (say the 10 of diamonds) from a pack (wildcards excluded).
- A (particular) vehicle being involved in at least one accident in the Australian state of NSW over a period of one year (the example quoted in the in the first paragraph).
- One’s birthday occurring on a randomly picked day of the year.
- Probability of getting 10 heads in 10 consecutive coin tosses.
(or 0.00098 );
- Drawing 5 sequential cards of the same suit from a complete deck (a straight flush).
- Being struck by lightning in Australia.
- Winning the Oz Lotto Jackpot.
;
Apart from clarifying the risk of a traffic accident, this tells me (quite unambiguously!) that I must stop buying lottery tickets.
A side benefit of the improbability scale is that it eases the tasks of calculating the probability of combined events. If two events are independent, the probability that they will occur together is given by the product of their individual probabilities of occurrence. Since the logarithm of a product of two number equals the sum of the numbers,
In short: the improbability scale offers a nice way to understand the likelihood of an event occuring in comparison to other events. In particular, the examples discussed above show how it can be used to illustrate and communicate the likelihood of risks in a vivid and intuitive manner.
Cooperation versus self-interest: the theory of collective action and its relevance to project management
Introduction
Conventional wisdom deems that any organizational activity involving several people has to be closely supervised to prevent it from dissolving into chaos and anarchy. The assumption underlying this view is that individuals involved in the activity will, if left unsupervised, make decisions based on self interest rather than the common good, and hence will invariably make the wrong decision as far as the collective enterprise is concerned. This assumption finds justification in rational choice theory, which predicts that individuals will act in ways that maximize their personal benefit without any regard to the common good. This view is exemplified in the so-called Tragedy of the Commons, where individuals who have access to a common resource over-exploit it in their pursuit of personal gain, and thus end up depleting the resource completely. Fortunately, this view is demonstrably incorrect: the work of Elinor Ostrom, one of the 2009 Nobel prize winners for Economics, shows that, given the right conditions, groups can work towards the common good even if it means forgoing personal gains. This post is a brief look into Ostrom’s work and the insights it offers into the theory and practice of project management.
Background: rationality, bounded rationality and theories of choice
Classical economics assumes that individuals’ actions are driven by rational self-interest – i.e. the well-known “what’s in it for me” factor (this is one of the assumptions of rational choice theory). So, in a situation where an individual has access to a resource that is also available to others, classical economics predicts that the individual will aim to maximize his or her benefit without any regard to the common good. Clearly, the group will achieve much better results as a whole if it were to exploit the resource in a cooperative way. There are several real-world examples where such cooperative behaviour has been successful in achieving outcomes for the common good (see this paper for some). However, according to classical economic theory, such cooperative behaviour is simply not possible.
So, what’s wrong with rational choice theory?
A couple of things, at least:
Firstly, implicit in rational choice theory is the assumption that individuals can figure out the best choice in any given situation. This is obviously incorrect. As Ostrom has stated in one of her papers:
Because individuals are boundedly rational, they do not calculate a complete set of strategies for every situation they face. Few situations in life generate information about all potential actions that one can take, all outcomes that can be obtained, and all strategies that others can take.
Instead, they use heuristics (experienced-based methods), norms (value-based techniques) and rules (mutually agreed regulations) to arrive at “good enough” decisions. Note that Ostrom makes a distinction between norms and rules, the former being implicit (unstated) rules, which are determined by the cultural attitudes and values)
Secondly, rational choice theory assumes that humans behave as self-centered, short-term maximisers. Such theories – which assume that humans act solely out of self interest – work in competitive situations (such as the stock-market) but do not work in situations in which collective action is called for.
Ostrom’s work essentially addresses the shortcomings of rational choice theory.
A behavioural approach
Ostrom’s work looks at how groups act collectively to solve social dilemmas such as the one implicit in the tragedy of the commons. To quote from this post by Umair Haque:
…Ostrom’s work is concerned, fundamentally, with challenging Garret Hardin’s famous, Tragedy of the Commons [Note: Hardin’s article can be accessed here], itself a living expression of neoclassical thinking. Ostrom suggests that far from a tragedy, the commons can be managed from the bottom-up for a shared prosperity — given the right institutions….
In a paper entitled, A Behavioral Approach to the Rational Choice Theory of Collective Action, published in 1998, Ostrom states that:
…much of our current public policy analysis is based on an assumption that rational individuals are helplessly trapped in social dilemmas from which they cannot extract themselves without inducement or sanctions applied from the outside. Many policies based on this assumption have been subject to major failure and have exacerbated the very problems they were in-tended to ameliorate. Policies based on the assumptions that individuals can learn how to devise well-tailored rules and cooperate conditionally when they participate in the design of institutions affecting them are more successful in the field…[Note: see this book by Baland and Platteau, for example]
Rational choice works well in highly competitive situations such as the stock market, where personal gain is the whole aim of the game. However, it does not work in situations that demand collective action – and Ostrom presents some very general evidence to back this claim.
More interesting than the refutation of rational choice theory, though, is Ostrom’s discussion of the ways in which individuals “trapped” in social dilemmas end up making the right choices. In particular she singles out two empirically grounded ways in which individuals work towards outcomes that are much better than those offered by rational choice theory. These are:
Communication: In the rational view, communication makes no difference to the outcome. That is, even if individuals make promises and commitments to each other (through communication), they will invariably break these for the sake of personal gain …or so the theory goes. In real life, however, it has been found that opportunities for communication significantly raise the cooperation rate in collective efforts (see this paper abstract or this one, for example). Moreover, research shows that face-to-face is far superior to any other form of communication, and that the main benefit achieved through communication is exchanging mutual commitment (“I promise to do this if you’ll promise to do that”) and increasing trust between individuals. It is interesting that the main role of communication is to enhance the relationship between individuals rather than to transfer information.
Innovative Governance: Communication by itself may not be enough; there must be consequences for those who break promises and commitments. Accordingly, cooperation can be encouraged by implementing mutually accepted rules for individual conduct, and imposing sanctions on those who violate them. This effectively amounts to designing and implementing novel governance structures for the activity. Note that this must be done by the group; rules thrust upon the group by an external authority are unlikely to work.
Ostrom also identifies three core relationships that promote cooperation. These are:
Reciprocity: this refers to a family of strategies that are based on the expectation that people will respond to each other in kind – i.e. that they will do unto others as others do unto them. In group situations, reciprocity can be a very effective means to promote and sustain cooperative behaviour.
Reputation: This refers to the general view of others towards a person. As such, reputation is a part of how others perceive a person, so it forms a part of the identity of the person in question. In situations demanding collective action, people might make judgements on a person’s reliability and trustworthiness based on his or her reputation.
Trust: Trust refers to expectations regarding others’ responses in situations where one has to act before others. Clearly, trust is an important factor in situations where others have to rely on others to do the right thing.
She describes reciprocity, reputation and trust as being central to a behavioural explanation of collective action:
…Thus, at the core of a behavioral explanation (of cooperative action) are the links between the trust that individuals have in others, the investment others make in trustworthy reputations, and the probability that participants will use reciprocity norms…
According to Ostrom, face-to-face communication and innovative governance can change the structure of dysfunctional collective situations by providing those involved with opportunities to enhance these core relationships. On the flip side, heavy-handed interventions and increased competition between individuals will to reduce them.
Implications for the practice of project management
Projects are temporary organisations set up in order to achieve specified objectives. Achieving these objectives typically requires collective and coordinated action. Although project team members work within more or less structured (and often rigid) environments, how individuals work and interact with others on the team is still largely a matter of personal choice. It is thus reasonable to expect that some aspects of theories of choice will be relevant to project situations.
The importance of communication in projects cannot be overstated. Many project failures can be attributed to a breakdown of communication, particularly at project interfaces (see my post on obstacles to project communication for more on this), Ostrom’s work reiterates the importance of communication, specifically emphasizing the need for face-to-face interactions. From experience I can vouch for the efficacy of face-to-face communication in defusing crises and clearing up misunderstandings.
In most project environments, governance is imposed by management. Most organisations have follow methodologies which have excruciatingly detailed prescriptions on how projects should be controlled and managed. Ostrom’s work suggests that a “light hand on the tiller” may work better. Such a view is supported by research in organisational theory (see my post on project management in post-bureaucratic organisations for example). If a particular project control doesn’t work well or is too intrusive, change it. Better yet, seek the team’s input on what changes should be made. In fact, most methodologies give practitioners the latitude to customize processes to suit their environments. Unfortunately many organisations fail to take advantage of this flexibility, and consequently many project managers come to believe that control-oriented governance is the be all and end all of their job descriptions. Is it any wonder that project teams often complain about unnecessary bureaucracy getting in the way of work?
Finally, it isn’t hard to argue that the core relationships of reciprocity, reputation and trust would serve project teams just as well as they do other collectives. Teams in which individuals help each other (reciprocity), are aware of each others’ strengths (reputation) and know that they can rely on others if they need to (trust), not only have a better chance of success, but also make for a less stressful work environment. Unfortunately these relationships have long been dismissed by project rationalists as “warm and fuzzy” fluff, but perhaps the recognition of these in mainstream economic thought will change that.
Concluding remarks
Classical theories of choice are based on the assumption that those making choices are rational and that they make decisions based on narrow self interest. These theories, which assume the best (rationality) and worst (self-interest) in humans, invariably yield pessimistic predictions when applied to situations that demand collective action. This is often used to justify external interventions aimed at imposing rules and enforcing cooperation, thus perpetuating a pessimistic view of the rational but selfish individual. Ostrom’s work – which uses a mix of fieldwork, experiment, model building and theorizing – highlights the flaws in theory of rational choice, and shows how cooperative action is indeed possible, providing certain important relationships are fostered through internal communication and governance. Externally imposed edicts, rules and structures are largely unnecessary, and may even be counterproductive.
Projects are essentially cooperative endeavours. Given this, it is reasonable to expect that many of Ostrom’s insights into the conditions required for individuals to cooperate should apply to project environments. My main aim in this post was to describe some elements of Ostrom’s prize-winning work and how they apply to project management. I hope that the points I’ve made are plausible, if not wholly convincing. And even if they aren’t, I hope this post has got you thinking about ways to increase cooperation within your project team.
Eight to Late 