The PM Who Can Read the Code: Why Technical Literacy Changes How You Manage
There's a version of project management that is essentially coordination: meetings scheduled, tickets updated, stakeholders informed, blockers escalated. Done well, it keeps projects moving. Done poorly, it produces a layer of process overhead that engineers resent and stakeholders eventually route around.
I'm not that kind of PM. And I think the difference matters more than most PM job descriptions acknowledge.
What Technical Literacy Actually Means
I want to be precise about this, because "technical PM" can mean a lot of things.
I'm not a developer. I don't write production code. I couldn't take over an engineering sprint if the team disappeared tomorrow.
What I can do is understand system architecture well enough to know when a requirement is creating technical debt that will cost more than it's worth. I can read an API specification and understand what it's actually doing, which means I can have a real conversation with an engineer about whether a proposed approach makes sense. I can understand the difference between a bug that requires a two-hour fix and one that requires a two-week architectural change — not by guessing, but by understanding enough about the system to ask the right questions.
That's technical literacy for a PM. Not the ability to code. The ability to be a credible participant in a technical conversation.
How It Changes the Work
The practical impact shows up in small moments that compound over time.
In requirements conversations: When I can engage with the technical constraints of a requirement — not just the business need — the conversation changes. Engineers stop pattern-matching me as the person who doesn't understand why things take time. We can have a real negotiation about trade-offs, because I understand what's being traded.
At Griaule, managing the simultaneous migration of seven desktop applications to web, this was the difference between sprint planning that felt like negotiation and sprint planning that felt like decree. I understood enough about the migration complexity to know which features were genuinely risky to include in a sprint and which were straightforward. That understanding changed how I pushed back — and engineers noticed.
In client conversations: When a government agency client asked about an edge case in the ABIS processing behavior, I could engage with the technical specifics of the answer rather than simply relaying it. That's a small thing. But small things accumulate into a relationship where the client trusts that the PM actually understands the product.
In estimation: Estimation is where the technical literacy gap is most expensive. A PM who can't evaluate technical estimates has two choices: accept them uncritically, or challenge them from a position of ignorance. Neither is useful. Technical literacy gives you a third option: probe them intelligently, asking the specific questions that surface the hidden complexity or the hidden simplicity.
How I Built It
I didn't start my career as a developer. My background is IT management and project management, with significant computer science coursework — enough to give me the foundations, not enough to make me an engineer.
What built the rest was deliberate exposure over time:
Reading the code. Not to understand every line, but to build a model of the system. What are the main components? How do they interact? Where are the seams?
Sitting in technical discussions. As an observer at first, then as a participant. Not to contribute the technical solution, but to understand the shape of the conversation — what questions engineers ask each other, what signals indicate complexity, when "it depends" means "it's simple" versus when it means "we don't know yet."
Building things. The Docs-as-Code pipeline at Griaule was a technical project as much as a documentation project. I made architectural decisions, wrote configuration, debugged build failures. That hands-on experience with a real technical system gave me intuitions that I couldn't have developed by reading about it.
The Organizational Value
Here's what technical literacy does for the organization, not just for the individual PM:
It reduces the translation burden on engineers. If the PM can absorb and process technical information directly, engineers spend less time translating their work into non-technical language. That's time returned to building.
It improves requirement quality upstream. Requirements that have been validated against technical constraints before they reach engineering are better requirements. The rework rate goes down. The frustration on both sides goes down with it.
It enables honest timelines. A PM who understands technical complexity can push back on both underestimates (that create quality problems) and overestimates (that create unnecessary delay). That honesty builds credibility with both engineering and business.
The Caveat
Technical literacy for a PM is a tool, not an identity. The risk of a technically literate PM who isn't careful about it is over-involvement in technical decisions that should be the engineering team's to make. The point isn't to be a better engineer than the engineers. It's to be a better PM because you understand what engineers are actually doing.
The line I try to stay on the right side of: I can ask any technical question. I should offer technical opinions sparingly, and only when they serve the project rather than my own desire to be useful.
That discipline — knowing when to engage and when to step back — is, in the end, what separates useful technical literacy from the kind that just adds noise.