Archive for September 2007
“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.
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.
Poor project management practices abound. Many projects are mismanaged in one or more ways ( clarification: this obviously does not apply to any of the projects I’ve managed). Rather than catalogue poor PM practices, I thought it might be more fun to illustrate some of these through a bunch of stereotypically incompetent project managers. You might recognise aspects of project managers you’ve encountered in the following caricatures:
Barry Bureaucrat: Barry has a form for everything. He won’t move until all the paperwork is completed and signed. If you want action from him, you have no choice but to play along. A warning: Barry is a master of fine print – beware of sneaky small print caveats and disclaimers within each of his forms.
Clarence Clueless: Clarry is easy to identify – he’s a project manager with a vacuously vacant (repeated redundancy used for emphasis) look on his face. He looks like he doesn’t know what’s going on, and it’s not an act. He really doesn’t have a clue.
Conroy Cowboy: Con is a cool guy, with a strictly shoot-from-the-hip approach. He believes in reacting fast to events, even if that means there’s no thought preceding the action. Watch out for Con, as his aim isn’t so hot – be sure to duck before the shooting starts.
Igor Inflexible: Igor’s inflexible. Once he has an opinion, he’s congenitally incapable of changing it. If you’re charged with convincing him about something that he disagrees with – good luck, you’ll need it.
Mac Machiavelli: Mac’s a schemer. Plotting and planning come naturally to him. Unfortunately all his planning efforts are geared towards implementing nefarious plots to further his career. To him the project and team are important only to the extent that they serve his relentless pursuit of fame and glory.
Norman No-decision: Norm enjoys discussing issues and analysing them. He’s spent many enjoyable hours (days, months!) analysing, re-analysing and re-reanalysing things, ad nauseum. However, he finds it impossible to make any decisions. He’s elevated Analysis Paralysis to a fine art.
Sally Shifter: Sally has an unblemished record as a project manager. This is mainly because she’s a a master (mistress?) at shifting the blame for mess-ups on to other people (generally her team members). Remember this when you’re stuck with Sally: always document your actions (through email etc.). This will serve as insurance if (when!) she starts playing the blame game.
There are several more of these characters lurking in corporate project management offices. I’ll cover a few more of them in a future post.
My mate Raj used to cut database code for a large corporate IT shop. He was one of a team of several super-specialised database dudes at The Contemporary Bank. Raj’s job at Con Bank (as the fine financial institution is referred to by certain cynics) was developing data interfaces. In fact, he’d done so many of these, that he was the indisputable imperator of interfaces at Con Bank . Raj was a reluctant rajah, however. He’d rather not have had anything further to do with interfaces. So fed up was he, that he didn’t want to hear about another interface until at least the midnight of Friday, December 31 9999. [Incidentally, when queried as to why that specific date he told me to go and look it up in the online documentation for DB2. As is evident, he’s a true database devotee.]
Anyway, unwilling to wait until the end of time, Raj teed up a meeting with his manager to discuss the unhappy state of affairs, and what might be done to redress it. The manager – call him Franz – gave Raj a patient hearing. He proferred platitudes (“Oh, I understand how you must feel”) and promises (“We’ll move you to the DBA group in a few months”) in plenty, and for a while the promise of change was enough to keep Raj going. Nothing changed. Three months later, thinking that three months certainly qualified as “a few”, he approached Franz for another chat. Franz, guessing what the subject of the chat might be, continually made excuses to postpone it. Finally when cornered, he admitted that it wouldn’t really be possible to move Raj to another group (who would do the interfaces then?).
The sorry state of affairs finally led to the inevitable conclusion; one that is played out again and again in countless organizations the world over: Raj started to look for another job. He found one within a few weeks and put in his resignation. Franz tried to persuade Raj to reconsider, but Raj wouldn’t.
Con Bank’s still looking for another data interface specialist. They might have saved themselves the trouble had they offered Raj a little more variety on the job.
Don’t know about you, but I’ve wasted way too much time in meetings that have meandered on and on. I have nothing against a well managed meeting. But I’ve run out of patience with the other, seemingly more common, confabulation that may be familiar to some of you: a meeting that goes on and on, in total disregard of the allotted time. The discussion somehow strays off the agenda, and the meeting chair doesn’t bring it back on track. If you sit through many such meetings (as I, unfortunately, have) you’ll begin to recognise stereotypical personalities who are responsible for the majority of “over-time offences”. As with all steroptypes, they’re one-dimensional characters. However, based on experience, I believe that close approximations of them exist in all corporate environments. Here are some that I’ve encountered. Recognise and neutralise them before they take control of your meetings:
William Windbag (aka Oscar Opinion): Will’s vice is his voice: he loves the sound of it, and exercises it at every opportunity. Give Will a chance to hold forth, and he will. Do yourself a favour and don’t let him get started. This is harder said than done because he has an Important Opinion on everything.
Tim Tangent: Tim is the master of irrelevance. He will take your meeting off in directions unintended, unexplored and totally unnecessary. Stop him before he gets started. Better yet, leave him off your invitee list.
Nate Naysayer: Nate’s first reaction to any idea is: “it wont’t work”. Your first reaction will be to start debating the point. Don’t do it. Thank Nate for his input and move on. Else you’re in for a long and pointless argument.
Sid Smalltalk: Sid delays the start of every meeting by at least 15 minutes by indulging in banalities. He absolutely must know how everyone, their families and their pet rhinos are doing. An authoritative “let’s get started” usually stops Sid in his tracks.
I look forward to hearing about your over-time offender stereotypes.