The PM Who Reads the Code

The Misconception

There is a widespread belief in product circles that a PM's job is to stay out of the engineering team's way. Write the spec. Review the design. Accept the ticket. Ship the feature.

I think this is wrong. Not because PMs should write code — they should not. But because a PM who cannot read code is flying partially blind.

What Reading Code Actually Means

I am not talking about reviewing a PR for style or suggesting variable names. I mean three specific things:

1. Reading a diff to understand scope. When an engineer says "this is a 2-day change," you should be able to look at the affected files and have a rough intuition for whether that is plausible. Not to audit them — to have a real conversation about tradeoffs instead of just nodding.

2. Understanding a stack trace. When a production incident happens, the engineer will show you logs. A PM who can follow a stack trace to the rough area of failure will ask better questions in the war room. "Is this the payment service or the notification service?" is a much more useful question than "how long will it take to fix?"

3. Knowing what a schema change costs. Adding a column to a database table sounds trivial. On a table with 50 million rows, it is a migration that requires a maintenance window or a careful zero-downtime strategy. A PM who knows this will never casually add "just add a notes field" to a ticket.

How I Developed This

At Infosys, I wrote production automation scripts. I was an engineer before I was a PM. That background is not a prerequisite — but the habit of reading code is.

What actually built the habit was reviewing PRs not to approve them, but to ask questions. "What happens if this API call times out?" "Why is this cached for 5 minutes and not 1?" The engineers I worked with appreciated the engagement. The questions made the code better.

The Practical Test

If you want to know whether you read code well enough, try this: pull the last significant PR your team shipped. Read the diff. Write down three questions you would have asked before it merged.

If you cannot write three questions, you are not reading the code — you are scanning it.

What This Changes

A PM who reads code ships fewer bugs, writes tighter specs, and earns engineering trust faster. That trust is not soft. It translates directly into velocity — because engineers stop padding estimates for the "PM surprises" they know are coming.

The best compliment I have received from an engineering team: "You ask the same questions we ask ourselves."

That is the goal. Not to be an engineer. To think like one, for the 20 minutes a day it matters.