I am often part of interview panels to recruit applicants for various open positions, and when I interview project manager candidates, I see a crisis. We have grown our business by managing and delivering projects, and we think we understand what it takes. What we find in PM candidates is very strange.
One category of PMs are what I call Book-keepers. They keep accounts. Typically, they’ll maintain a spreadsheet with tasks, one task per row. They’ll check the status of tasks with each developer every day, and discuss the status spreadsheet with their client once a week. That’s it. They wouldn’t know how to negotiate anything, how to analyse a roadblock in a task, or evaluate which team member is a weak wicket. They will not have the slightest intuition about road-blocks which are likely to emerge in the next few weeks. This is book-keeping, not managing. This is the pedestrian kind of book-keeping, because no insights are drawn. This type of PM is commonly found leading small T&M teams in large software companies, serving some large, bureaucratic Wall Street client. Their clients too seem to be quite cool with task level delays as long as project status is discussed in the weekly review call. They expect nothing more, no drive, no urgency. Peace and good cheer all around.
The second category I find is the Postman. These PMs take the issues and objections raised by their dev team and escalate them to their client. They take spec changes, feedback, and new requests from clients and relay them to their developers. They do not negotiate with either party. They seem to have poor skills to evaluate whether these escalations and roadblocks are reasonable. They trust that the right people are in the right places in their teams and alerts will be raised when necessary. They have little understanding of the original spec and scope of the project, neither do they have much understanding of the legitimacy of the technical delays when their tech team tells them that item X is a “complex problem” and will take a month. When called upon, they create a 5-slide “status report” in PowerPoint. Basically, these PMs are message relays.
The third category I see is the Slogger. These managers work with their teams, sitting in office for 12 hours a day when needed, ties loosened, collar button undone, peering over shoulders, sometimes taking the keyboard, poring over the latest bug or other peculiarity, trying to make the software work. These chaps have harried looks on their faces most of the time, no doubt because of the late nights. They do — they don’t manage. Their techie team members like working with them, because they never haul up a developer for non-performance – they roll up their sleeves and get down to solving the technical problem.
The fourth category is what I call the Page Three Types. They are well dressed and well groomed, and know about good after-shaves. They prepare lovely Powerpoint slide decks to discuss status or progress or risks or escalations or anything else. These PowerPoint decks are not made by themselves personally, they need a team member to make the decks for them, and the more colour and graphics, the better. They come in only during client review sessions, make presentations, pepper their talks with “world class”, “class leading”, “optimal”, “mission critical”, and so on, and wave their hands in the air in wide, sweeping gestures. They do not understand a single point of detail about their projects. They usually have a trusted lieutenant in the team who actually does the day-to-day heavy lifting, but gets little credit. They do not understand or care one whit about the day-to-day challenges of their team members, and get no respect from their team. If they have clients who are glamour-struck with the hand-waving Page Three behaviour, they have an easy time with their clients. If their clients see through them, then the client typically quietly bypass them and maintain a steady dialogue with their next-level team leads. I have found these Page Three managers more in the Big Four consulting firms than in dyed-in-the-wool software companies.
Where have all the real project managers gone?
I find three common weaknesses in many project managers. First: insufficient focus on the final deliverables. Most PMs are too caught up in the micro-transactions of day-to-day execution, and tend to forget, temporarily, the final milestone deliverables. We all know that the day-to-day stuff is the reality with which projects get completed, but if the PM constantly retains a clear awareness of the final deliverables, then he or she will see the day-to-day issues very differently.
For instance, I may see a PM engaged in long, sometimes heated, arguments with his client about five file formats which the client has not yet given us. As part of the scope of the project, the delivery team is supposed to write software to process these file types. So the PM gets busy arguing with the client about the delay. A good PM with razor-sharp focus on final deliverables will not do this. She will ask the client whether the project may be delivered with the file formats received so far, and if we may be allowed to get an acceptance sign-off without these last five file types. We will deliver the last five after sign-off. In many cases, a mediocre PM would not even try this tack, though many clients may have agreed if the PM had tried.
Second: inability to re-prioritise frequently. The very raison d’etre of a PM’s role is to deliver when there are insufficient resources and time. If we always had ample budget, team size and time, we wouldn’t need a PM. Therefore, the entire focus of a PM is on juggling resources. This means he must re-prioritise every day if needed. Move one developer from module A to module B, because we need to deliver module B earlier, and we can persuade the client to accept a two-day delay in module A. Move the testing team to finish testing of some lower priority module while the developers are fixing a big bug somewhere – one cannot allow the testers to sit idle. This re-prioritising is one of the most valuable skills of the PM.
Third: weak negotiation skills. The PM needs to negotiate with the client about functionality, features, delivery sequence, and infrastructure issues, and negotiate with the dev team for faster delivery, recurring quality challenges, specs compliance, etc. Every day involves a negotiation or two, some quid pro quo.
It is often assumed that the word “negotiation” in the context of a software PM is all about negotiating with the Evil Client. Clients are dumb, clients make crazy demands, clients change their priorities on a dime, and the courageous PM rides out every morning to do battle with the Evil Client. This is such a silly stereotype. The PM has to negotiate with his own technical leads as often as with the client. It is so common for a Lead Engineer to come back and say “XYZ sub-module will take three more days.” And he will just assume that God has given him the absolute right to announce such delays, and the poor PM has to pick up the pieces and make do as best he can. This is not how it works. A good PM will negotiate with the Lead Engr, explain what can be re-shuffled or juggled or part-completed, so that deadlines can be met and the client can be satisfied in spite of a technical delay.
Without these three things in my PM, my project is dead in the water. Beyond these three, there are two qualities which I usually observe in good PMs, which makes me feel comfortable that the project is in safe hands. One: the PM has a clear intuitive feel about each team member. Two: the PM exudes empowerment.
It is sometimes said that the company must empower employees and managers; empowerment, like wheatgrass and inner peace, is a popular buzzword. I feel a good PM brings empowerment into the company in his DNA, it’s never the company which can empower a manager who does not have that gene in him already. A bad company may sometimes take away a good manager’s empowerment; a good company does not add empowerment to a weak manager. Empowerment may be a great feature of company culture for other profiles, like clerks, boffins, geeks, etc, but a good project manager does not need it. The good PM walks in with empowerment wherever he goes.
Remiges is what it is, and what it will be tomorrow, because of a small handful of good PMs. A technology company cannot do well without good technology, but if the company offers value in the form of projects, then I daresay that project management can make or break the business, however good the technology may be.
Leave a Reply