Archive for October 2007
In many organisations, innovative ideas have a much better chance of acceptance if they are proposed by (external) consultants rather than (internal) employees. In the course of assorted stints at various companies, I’ve seen several employees frustrated by the rejection of their ideas by management. Chances are this has happened to you at one time or another. In this post I’d like to discuss a few strategies for getting those “way out” ideas off the ground. I’ll leave out the most obvious strategy- which is to attempt to sell the idea yourself. I’m assuming you’ve tried this and it doesn’t work or isn’t going to. OK, so here are a few other things to try:
Invoke the “fat accomplice”: If you are convinced of the value of your idea, you could just do it, much as the popular purveyor of footwear exhorts. Implement the idea or get moving on it without waiting for official sanction. Once the wheels are set in motion, present management with a fait accompli, or “fat accomplice” as my four year old calls it. I quite like the imagery evoked by the aforementioned cross-lingual confusion (or False Friend) – a fat partner in crime who can take the rap if something goes wrong. One caveat though, if you are going to call on a fat accomplice, you’d better be sure your idea is going to work. Else be prepared for consequences.
Sell by proxy: Discuss the idea informally with people who have influence in the organisation. These folks aren’t necessarily managers. They could, for instance, be people who have built up personal credibility through their contribution to the business. Although not managers themselves, they generally have more access to decision makers, and thus might be able to do a better job selling the idea.
Give it away: If you discuss the idea with enough people, someone may appropriate it and sell it as their own. They might have better luck selling it to management. This is a viable option if you don’t mind someone else getting the bouquets (or brickbats) for the outcomes. A common variant of this case is when a manager appropriates the idea as his or her own. Although it is natural to feel a little cheated if the boss takes the credit, you should really be quite pleased. The sneaky strategy has worked – the idea made it through without people being aware of its real origin.
I’ve tried each of the above at various times with varying degrees of success. You’ll need to figure out which is the best one for your particular situation, factoring in things such as work environment, politics and corporate culture. There’s no guarantee that any of them will work for you. The only sure thing is that if you don’t take the responsibility for selling your ideas, they’ll never to get off the ground.
One of my favourite essays on software development is Joel Spolsky’s article on Fire and Motion. In the piece he discusses how large software companies “pin down” their competitors by continually “firing volleys” of new technologies- OSs, databases or whatever – into the market. Competitors are thus compelled to spend time enabling their existing software to work with the new technology, which forces them to take time off from developing new products. With the competitors immobilised playing catch-up, the software behemoths are able to cover new ground unhindered, much as an infantry group advances under covering fire.
The most successful small companies, according to Joel, ignore the distractions of new technologies (as interesting as they may be) and, instead, focus on their customer’s needs.
The key point is: the new technology is used only if it makes business sense to do so.
The Fire and Motion analogy holds a lesson for those who manage technical teams in corporate environments – project managers, development managers et. al. It is all too easy for such folks to distract their teams by involving them in tasks that are, at best, peripheral to the primary goals of the group. An example might be a manager who reads about some cool new technology and then, with no regard for actual need, insists that a key team member evaluate it for future use. Such managerial behaviour is akin to “friendly fire”, where a manager “pins down” his own team by “firing volleys” of initiatives which do not add any value to the organization.
As in the case of friendly fire, the net result is an unfortunate one.
The costs of multitasking are well known. Firstly, it takes time for the human brain to switch from one task to another. This is analogous to the overhead of context switching in computers (the term “multitasking” itself originated in computer science). Secondly, multitasking delays the delivery of all tasks simply because a given task is not finished in a single go.
The evils of multitasking have been commented on in the popular press, with CNN, Time and even the occasional newspaper article warning against it. Despite the general awareness that it is counterproductive, developers working in corporate IT departments are routinely expected to juggle several tasks in the course of their day-to-day work. Furthermore, I often find that the “ability to multitask” is stated as a requirement in job advertisements. For example, here are excerpts from a few IT development job ads that appeared recently in seek.com:
Software engineer in Auckland: …Must have the ability to multi task and prioritise…
Web designer / Applications engineer in Sydney: … Must be able to multi-task…
Systems implementation specialist in Sydney: …Should be able to multitask and work on multiple projects…
The expectation is that employees must be able to juggle tasks and even projects (!) as required. Given this, are there things a frontline technical / project manager can do to alleviate multitasking-stress on their teams? Yes there are, and here are a few that’ve worked for me:
Prioritise work: You’re never going to get everything done concurrently. Given the workload on your team, some things may never get done at all. It is, therefore, paramount that work be done in order of business priority. Obviously the prioritisation needs to be decided in consultation with the business. Under no circumstance should it be based on technology (I’ve seen this happen) or developer preference (seriously – I’ve seen this too!).
Get a high-level view of everyone’s workload: As a part of the weekly routine, get each team member to send you a rolling workplan for the next month or two (I go with 4 weeks). The plan should list tasks that the person anticipates doing each week, along with a time estimate per task. The estimate should be at a granularity of no less than 0.5 days or, ideally, 1 day (see next point). This gives you a high level view of each person’s workload, and alerts you to potential multitasking problems.
Align task switches with the end of the day or week: Encourage people to work on a single task per day, or whole multiple of a day (unless it’s a shorter duration task, of course). This way, task switches happen at the end of a work day, thereby allowing time for the mind to orient itself to working on another task.
Plan on a four day week for development work: Assume that programmers have only four dev days – i.e. days for development work. Keep a whole day aside for other stuff such as ad-hoc requests, support, meetings and administrative work. Depending on the situation in your shop, you may even have to reduce the number of dev days to three.
Insist on decent work hours: It is OK to work overtime once in a way – when a project deadline approaches, for instance. However, it is definitely not OK to expect the team to sustain unreasonable work hours over an indefinite period.
Minimise Distractors : Don’t clutter developer work weeks with distractors like unnecessary (or unnecessarily long!) meetings. Your job is to remove distractors, not add to them.
Provide Support :As Joel Spolsky mentions in an interview – “I always think of it” (i.e. management) as more of a support role – like moving furniture out of the way so they can get things done – than an actual leadership role.” Specifics on how one might do this will vary from situation to situation. In some cases you may need to act as a gatekeeper – filtering requests from the business. In others, you may need to answer high-level questions and provide guidance. In a nutshell – do whatever it takes to help your team do their job.
…But don’t interfere: I don’t think I need to elaborate on this. You don’t want to give people the impression that you aren’t confident in their ability to handle their work. Such behaviour is tantamount to micromanagement which, as I’ve mentioned in an earlier post, is a definite no-no.
Know when to push back on your managers: Take a stand when your management makes unreasonable demands. Explain why it won’t work, and suggest alternatives. This is a an opportunity to earn your stripes as a manager (and your team’s respect).
Given the increasing workload and resource constraints that corporate IT works under, there’s often no option but to multitask. This can have negative consequences on team performance and morale. Some of the techniques discussed here may help avoid and/or manage these consequences.
Since project management, as a discipline, originated in a Western culture, incompatibilities between project management values / beliefs and those of traditional Asian cultures are to be expected. Most readers who have worked both in Western and Asian organisations will be well aware of these differences. A recent paper entitled Cultural barriers to the use of Western project management in Chinese enterprises: Some empirical evidence from Yunnan province explores these differences in the context of Chinese organisations (see reference at the end of this post). Specifically, the authors look at four contrasting value/belief pairs, which cover the major differences between the two cultures:
- Integration management vs. doctrine of the mean: This refers to the contrast between project management practices – which generally emphasise integrating opinions, resolving conflicts and confronting risks – as opposed to traditional Chinese (and dare I say, Asian) practices in which confrontations and risks are avoided as far as possible.
- Horizontal management vs. strong hierarchy: This refers to the incompatibility between project management, which works best in a flat (or project-oriented) hierarchy, and the strong vertical hierarchies prevalent in Chinese organisations. The latter organisational structure tends to emphasise superior-subordinate relationships in which “questioning the boss” is not encouraged.
- Team consciousness vs. family consciousness Project teams are generally temporary, and tend to emphasise collaborative work across functions and merit-oriented performance evaluations. On the other hand, Chinese culture values long-term family and kinship relationships. These are not always compatible with cross-functional (or even intra-functional!) collaboration or performance-based recognition.
- Task orientation vs. boss orientation In project management getting the job done is paramount, whereas in Chinese culture the emphasis is on keeping the boss happy.
The authors developed a questionnaire to explore the relative importance of each of the above value/belief pairs. Based on the questionnaire, they conducted a survey involving respondents from a wide variety of industries in Yunnan province.
The analysis of the results revealed that the major cultural barriers to project management in Chinese organisations are the last three items: i.e. strong hierarchy, family consciousness and boss orientation. It is interesting that a majority of the respondents thought that the doctrine of the mean was consistent the integrative nature of project management.
The authors also find that the barriers tend to be larger in state owned organisations than in private or joint ventures. Further, within state-owned organisations, older ones tended to have larger barriers than younger ones.
Also interesting is the find that project management training has a critical effect on lowering cultural barriers: As more individuals in an organisation received relevant training, the organisation became more supportive of project management practices.
The authors end with the caveat that their conclusions are based on the result of a single (yet representative) survey, and must therefore be treated as a pilot study.
I found this paper worth reading because it articulates and explores some of the contrasts I have noticed in my own work with organisations in India, Australia and the US. In my experience, many of the observations made regarding cultural barriers to PM practices apply to (non-Chinese) Asian cultures as well. Those of you who work with cross-cultural project teams – particularly those across Asian and Western cultures – may find this paper a worthwhile read.
Wang, X. and Liu, L., Cultural barriers to the use of Western project management in Chinese enterprises: Some empirical evidence from Yunnan province, Project Management Journal, 38(3), 61-73 (2007).
Many of my readers living in cricket-playing countries would be aware that India recently won the inaugural World Twenty20 cricket title. The win was somewhat surprising because India fielded a young and inexperienced team – minus their established stars and with no coach. Further, many players on the team had had no prior experience of playing a Twenty20 international.
In retrospect, the absence of star players was a good thing for at least a couple of reasons:
- The team had to play as a team without relying on a few individuals. They did this well; several specialist players contributed to the team’s eventual success, as is borne out by the batting and bowling averages .
- The young, and relatively inexperienced, captain, Mahendra Dhoni, could make decisions unconstrained by the presence and opinions of so-called stars. Many analysts, including India’s ex-coach Greg Chappell agree that Dhoni’s leadership was one of the reasons for India’s success. One of the more striking aspects of Dhoni’s captaincy during the tournament was his ability to draw outstanding performances from fringe players .
The last point is the one that interests me here. Project teams are generally made up of individuals with a range of (professional) skills and (personal) attributes, brought together with the common goal of seeing the project through to completion. As is the case with groups in general, a small number of these individuals – those with strong personalities – tend to dominate decision-making forums such as team meetings. It is up to the project manager to control these alpha male (or female) types, and draw out the quieter folks who, presumably, are just as important to the success of the project (if they aren’t, why are they on the team at all?).
Letting big egos interfere with calm and considered decision making is a recipe for failure – both on the cricket field and in project work. Dhoni was lucky not to have to deal with star sized egos in the tournament. A project manager will seldom be so fortunate.