Twenty20 hindsight
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.
Going walkabout
“Hey, when are you going to get to your office and do some real work?” jibed Mike, as he spotted me walking past his office.
It was one of those days. I must have walked by his door at least four times that morning and the day was still young. I looked his way, just a tad irritated by his tone. He had his trademark grin on his face.
“Shouldn’t you be sorting out the problem with the web module instead of tracking me?” I retorted, continuing down the corridor.
He said something in response that I didn’t quite catch.
Despite Mike’s grin, I suspect his question was at least partially serious. So it deserves more than a flippant response.
I do spend a great deal of time away from my desk. Why?
I’ve been practising MBWA or management by wandering (or walking) around. In a nutshell, this means wandering around the office and talking to people to get a feel for how things are going.
My wanderings incorporate regular, informal, face-to-face chats with team members, to get a first hand view of their concerns and problems. There are innumerable ad-hoc tasks vying for the attention of developers in a corporate environment (2nd/3rd level support issues, just to name one). Talking to individuals regularly let’s me know if there’s something I can do to help them focus on their work. This usually boils down to helping them with non-technical tasks. Some examples include: prioritization of work; doing some admin tasks on their behalf; helping them negotiate with unreasonable customers from the business; assisting with documentation etc.
Obviously MBWA needs to be done in a non-intrusive way – the last thing one wants to do is to make people feel like they’re being spied on or micromanaged.
The technique works well with customers (end-users from the business) too. Often, when someone sends me an email requesting assistance from my team, I’ll walk over to their office and have a chat instead of responding by email or phone. Face to face communication is almost always better than a disembodied voice via a telecom device or, even worse, words on a screen.
MBWA is a great way to communicate with your team and your customers. Apart from the immediate benefit of getting a first hand view of people’s problems and needs, it helps build relationships. Which, in the end, is a large part of what management is about.
I’ll sit in my silo no more
Many organizations are structured along functional lines – i.e Sales, Marketing, IT, HR – with each department headed up by a functional manager. The well-known limitation of this organizational structure is that it is not conducive to cross-functional cooperation and communication. Work done and experience gained by a department is rarely shared across the organisation, as there’s no incentive to do so. This behaviour is well recognised. For example, as Goldratt has pointed out in his business novels on the Theory of Constraints, most organizations focus on optimising locally instead of globally. In general, a local (in this case, departmental) optimum is not a global (organization-wide) optimum.
As a concrete example, the dental hygiene division of a company may have worked on developing segmentation models for their markets. Over several years they’ve developed much expertise in the area. Now, this year, the skin products division of the same company wants to work towards developing a better understanding of their markets. They start working on this without even being aware that someone on the floor below could help them for free. Obviously, the exact same strategies may not work for both divisions. However, the experiences gained and lessons learnt by dental hygiene would certainly help skin products in the latter’s quest to understand their specific market.
“So”, I hear you ask, “what’s your point”? It is this: in IT we’re well placed to start cross-functional communication, as we’re the one department that works with just about every other one in the organization. You might, for instance, have done a lot of work with Department A over the last few years. In the course of this, you’ve built up a good understanding of their specific business. Now, this year, you’re working with Department C to develop some other applications. It is quite (very!) likely that some of the knowledge you’ve gained while working with A will be of direct use to C. Use it! Your organization will eventually thank you for it. Even if you get no thanks, you’ll have the satisfaction of knowing that you’ve done something that expensive management consultants can only prattle on about.
Eight to Late 