Project Managers are not “Ticket Jockeys”

An Ode to Project Management

Project Managers ride the dev train while laying the track.

Trouble in Project Management Land

I was hanging out at a barbecue with a fellow digital native over the weekend, and he said his tech company had been experiencing explosive growth. 30 to 85 people in the past year. Sales skyrocketing. Devs all over the US, punching out code. The C-suite making good decisions that pushed them over the hump and into the green hills of profitability.

The only department that had been causing trouble was Project Management. As a Product Manager (PM) myself who has done significant project management in the past, my ears perked up and I carefully — oh, so carefully — asked my next really thoughtful question: “Why?”

The Culture Behind the Why

He started with the list of apparent problems in Project Management at his company:

  • Turnover — 2.5x turnover in the last year
  • No leadership — the head of the department was removed and not replaced
  • Negative culture — he mentioned at least one PM who was a “bad egg”
  • Lack of domain-specific knowledge — new PMs didn’t know the lingo or concepts surrounding their core business

As I listened, none of these reasons answered the question for me. They are all symptoms, not causes. Let me show you an honest reading of each of these from a PM’s point of view:

  • Turnover → PMs are not respected.
  • No leadership → No standards for success, no guidance.
  • Negative culture → Pretty obvious why the culture is negative considering the above two points.
  • Lack of domain-specific knowledge → A fault in hiring, on-boarding, and the above-mentioned lack of guidance and leadership. PMs are largely facilitators, but they need to know foundational concepts to get a handle on what they’re facilitating.

It became obvious to me that there’s a culture behind the why that was leading their PMs to fail. The nature of that culture was not fully apparent to me until the guy said:

I don’t know why it’s so hard. Project Managers are just ticket jockeys [between the client and devs].

The term “ticket jockey” expresses a fundamental lack of respect for the job and suggests a company-wide misunderstanding of what a good PM can and should do.

Good Project Managers Deliver “Good Projects”

Despite my emotional reaction to the term “ticket jockey,” I am hard-pressed to immediately respond with specifics to why PMs are not ticket jockeys.

A list of deliverables by department at a tech company makes the situation a bit more obvious:

  • Dev delivers Code
  • Design delivers Product Design
  • C-suite delivers Vision
  • Sales delivers Clients
  • Project Management delivers Good Projects

You might replace “Good Projects” with the more specific “Well-executed, well-perceived, and profitable projects,” but even this deliverable is a bit vague when you dig into it. PMs generally do not get their hands on the code to ensure execution; they don’t contribute directly to lots of processes that make the project well-perceived like design; and they usually don’t close sales or make final resourcing decisions, limiting how much they can affect profit margins.

So why are PMs not ticket jockeys? What do they do?

The Core Purpose of a Project Manager

On time, on budget, and as expected.

Because of its vague borders, the PM role is different at every tech company, but Frederick Brooks, Jr. sums up the PM’s core purpose well in his book, The Mythical Man-Month:

The investment of a modest amount of skilled effort in a Plans and Controls function is very rewarding. It makes far more difference in project accomplishment than if these people worked directly on building the product programs. For the Plans and Controls group is the watchdog who renders the imperceptible delays visible and who points up the critical elements. It is the early warning system against losing a year, one day at a time.

Without a good PM, it’s quite easy to lose “a year, one day at a time” on a big project. A good PM makes everything clear that would have otherwise been “imperceptible.”

How precisely to provide that clarity is a topic for many more tactical articles, but let it be known that it’s possible (see Ryan Singer’s Managing Product Development by Integrating Around Concerns for a peek into a method that really works).

The Technical Project Manager

The foundations of our digital world.

I have a personal bias towards appreciating “technical” PMs who understand code and the technologies surrounding it at some level. Because we create digital products, having some technical knowledge increases your ability to swim natively in those waters.

You don’t have to be able to code everything yourself. Rather, technical PMs facilitate intelligent conversations about digital products at all levels: clients, devs/designers, the C-suite, and users. You don’t need to know code, but it adds value and expands the types of projects you can confidently tackle.

How to Value Project Management

PMs feel appreciated throughout the company and by their own department when they have clear:

  • Roles and responsibilities
  • Definitions of success
  • Paths to learning more

The tactics for each of the strategies above will not be the same for all companies, but by valuing PMs you will ensure that you create beautiful products on time, on budget, and with full appreciation of your product across the board from dev to client and ultimately to the user, which is why we do what we do.

If I see the guy who called PMs “ticket jockeys” at another barbecue, I’ll politely let him know.