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.

Project mismanagers – some stereotypes

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.