PM is not PJM

A Period of Trust and Observation#

The first six months after joining a company are critical—not just for building trust, but also for observing how you and the team work together.

I still remember those early months: back-to-back overtime.
Two marketing campaigns plus a major feature request meant 20 extra hours in my first week, then 120 hours in my second.

Can anyone really sustain that?
I know I can’t.

Burnout#

When you’re in this kind of situation, what do you do?

• A: This place is toxic—time to leave.
• B: Call out the problems and hope someone fixes them.
• C: Study what went wrong and figure out how to fix it.

I’m the kind of person who picks C.

Not every week was a 120-hour grind, but having that workload pop up semi-regularly was enough to drain hope. After recovering from the initial burnout, I took some time off, then ran a project retrospective to answer one question:

What caused this unsustainable work pattern?

Digging Deeper#

The root cause was clear: no one was managing the workload.
But whose job was that supposed to be?
The PM, right? (Here, PM means Project Manager.)

That led to another question: why weren’t the people with the PM title managing the project?

• Was it lack of knowledge or skill?
• Or was it simply not part of their deliverables, so they didn’t prioritize it?

Who Exactly Is the PM?#

I scheduled a meeting with our CTO to share my experience and analysis.

Before fixing anything, we had to clarify: was this about inability or unwillingness?

The CTO agreed with my take but said something unexpected:

“I don’t know if this helps, but I think the PMs here aren’t really PJMs.”

That surprised me.

Misaligned Expectations#

In my previous job, I worked with a Principal PM I truly admired—
someone skilled in both Product Management and Project Management.

That experience made me seriously consider what skills and mindset a PM should have.
I spent time learning both disciplines, and that knowledge proved invaluable in work and life.

If PMs here focused only on Product Management, it meant the company didn’t truly value Project Management—otherwise, it would already be resourced and tied to career growth.

So if I wanted to introduce project management, I had to make sure it didn’t conflict with others’ existing KPIs.

Building a Solution#

I started talking to engineers across the company about their delivery experiences.

Aside from the project management gap, I found many stakeholders—despite making regular requests—didn’t fully understand the end-to-end software delivery process.

If I couldn’t directly change people or their knowledge, maybe I could give them a process template they could adapt to their context.

That’s where I began.

From Observations to RFC#

I didn’t assume my own experience represented everyone.
So I drafted a comprehensive Request for Comment (RFC).

It laid out a chronological task template with detailed descriptions and reference materials. I included the background and reasoning behind the proposal and invited engineers company-wide to review it.

Over several weeks, I iterated on the draft—answering questions, adapting for different scenarios, and integrating suggestions. By the end of the three-week review, it had gone through 15 revisions.

It wasn’t perfect, and it didn’t need to be.
Its job was to start the conversation and kick off improvement.

Putting It into Practice#

Our team began using the template as a foundation for project management.

While it couldn’t replace a full-time PM’s flexibility, it made a noticeable difference:

• Before starting work, we had a checklist to ensure enough context.
• During development, discussions had clear reference points.
• When things went wrong, we updated the template instead of blaming people.

This structure kept focus on tangible improvements instead of miscommunication or finger-pointing.

From One Team to Many#

Eventually, other teams adopted the template and even submitted pull requests to improve it with new checkpoints. Each team adjusted it to their style and workflow.

The concept expanded beyond project delivery into requirement management and cross-functional collaboration. Domain experts could now express expectations more clearly, and their counterparts could execute more smoothly.

Seeing that evolution was far more rewarding than I’d expected.

Is This What You Hoped For?#

A colleague once asked:

“You’ve changed how the company approaches development. But now that the process looks different in every team—does it still match your original vision?”

I said yes.
I never wanted every team to look the same.
I wanted diversity to grow naturally—until it became part of the culture.

That’s worth far more than just fixing one uncomfortable workflow.

Final Thoughts#

It wasn’t all smooth sailing. Every hurdle still needed clearing, one at a time.

But I didn’t realize back then:
This experience shaped my future career path, influenced team culture, and became one of the key reasons I was promoted to Staff Engineer.