In the past, I’ve blogged about my experiences with project managers. If you’ve read my thoughts, there will likely be little new content here (with the exception of the Obi-wan clip at the very end…). Most of my thinking is included in a post titled IT Coaching – Software Done Well, Part 1, written almost 12 years ago.
It is my policy to wait at least one year between negative occurrences and writing about them. I wait one year because:
- One year often gives perspective that the-heat-of-the-moment does not.
- I’ve often moved on and I would never want current (or even recent) clients to suspect I am referring to them.
- Most often, the negative occurrence was such a small part of an engagement as to be insignificant when considered in the larger context of the engagement.
14 Years or So Ago…
Back in 2007, I wrote a post titled Bad IT Project Management. In it, I shared some thoughts on project managers. This post happens to include one of my all-time favorite lines about things PMs say:
“’Do we need to add more resources?‘ This question in and of itself is harmless. It’s actually the way project managers greet each other and has no more meaning to ordinary folk than ‘How are you doing today?’ or ‘How about this weather?’”
I first used the phrase “punching developers in the brain” in the post titled IT Coaching – Software Done Well, Part 1. If you are a software developer, you probably can probably – and sadly – infer the meaning from personal experience. If not, you can learn more about what I mean by reading that post.
“Punching developers in the brain” is related to the unasked question in this way.
At the end of the project, no project manager who has engaged in punching developers in the brain ever asks:
“So, did that little pep talk help?”
Why is this question never asked? Because the project manager and the developers and, very likely, the customer all know the truth about the (brain-punching) “pep talk,” which is that it in no way helped.
Did the pep talk impact the course, duration, and quality of the project? Most definitely.
The pep talk did not help, though. Instead, the pep talk most likely resulted in shortcuts which drove poorer results, reduced the quality of the deliverable, increased the cost of maintaining the deliverable (perhaps by an order of magnitude), and resulted in a later and more clunky delivery.
At the end of the project, everyone wants to glad hand the developers for their awesome work and tell them just how much they are appreciated and how the project could not have been successful without them. Blah, blah, and blah.
(image from Tractor Supply, in case you need a grease gun…)
When the project schedule is slipping and the project leadership is pointing at the development team in high-level meetings with the customer – meetings that most often do not include a representative of the development team – it’s too common for leadership to be passing out grease guns so developers can take care of a little preventive maintenance while they’re under the bus.
The pep talk does not help.
And that is why no project managers ask the question, “Did the pep talk help?”
It’s a rhetorical question.
When the project timeline is suffering:
- Own your estimates, project manager. Did you have a date in mind when you asked the developers for an estimate? Did the client have a solid business reason for proposing a deadline at the beginning of the project? Communicate this fact to the development team at the outset.
- Don’t throw developers under the bus. Throwing developers under the bus will only make the project later and the deliverables of less value.
- Support the developers instead. Support the development team in the middle of the crisis. Like Obi-wan, the developers are your only hope.