By Priya Shankar

You Can't Read Code. Here's What to Do About It.

You've been asked to evaluate a technical proposal. Two engineers have different opinions on the architecture. One says the refactoring will take 2 weeks. The other says 6 weeks. You're a PM. You can't code. How do you decide who's right?

This is the fundamental problem most PMs face: critical technical decisions are being made by people who don't understand the code, and the engineers who do understand it might have conflicting interests.

This guide is for PMs who recognize they can't read code and want to make better decisions anyway.

Why PMs Can't (and Don't Need to) Read Code

Time

You could spend 6 months learning to code. Or you could spend 30 minutes asking the right questions.

Your time is better spent on product direction.

Context

Code is context-dependent. Understanding a 50,000-line codebase requires months of deep learning. Even engineers who wrote it take weeks to remember what they did.

ROI

A PM learning to code has low ROI. You'll never code as well as someone dedicated to it. Your value is in product thinking, not code writing.

The good news: You don't need to read code to make good technical decisions. You need to ask the right questions.

How to Evaluate Technical Decisions

Question 1: What Problem Are We Solving?

Start here. Many technical decisions are proposed without clear problem statements.

"We need to refactor the payment system."

Why? What problem?

Good answers:

• "Current system can't scale beyond 1000 transactions per second"
• "Adding new payment methods requires changes in 5 places"
• "New engineers take 3 months to understand payment logic"

Bad answers:

• "The code is messy"
• "It's old code"
• "We should use a modern framework"

If they can't articulate the problem clearly, the proposal isn't ready.

Question 2: What's the Cost?

Every technical decision has a cost. What is it?

"Refactoring the payment system will take 6 weeks."

What does that cost?

Calculate:

• 6 weeks = 1.5 sprints
• 1.5 sprints of engineering time = 6 engineers * 1.5 weeks = 9 engineer-weeks
• Cost = 9 engineer-weeks * $3K per week = $27K
• Opportunity cost = 6 features not built

Is it worth it?

Question 3: What's the Benefit?

Does the benefit justify the cost?

Quantifiable benefits:

• "New payment methods will take 2 days instead of 3 days" (9 features/quarter instead of 4)
• "Onboarding will be 2 weeks instead of 6 weeks" (save $60K when hiring)
• "System will support 10,000 TPS instead of 1,000" (can serve 10x more customers)

Vague benefits:

• "Code quality will improve"
• "It will be easier to maintain"

If the benefit can't be quantified, you can't evaluate the trade-off.

Question 4: What Are the Alternatives?

Refactoring isn't the only way to solve the problem.

Alternative 1: Patch the current system

• Cost: 1 week
• Benefit: Quick fix
• Downside: Doesn't solve the root problem

Alternative 2: Refactor payment processing only

• Cost: 2 weeks
• Benefit: Solves most of the problem
• Downside: Doesn't refactor the full system

Alternative 3: Full rewrite

• Cost: 10 weeks
• Benefit: Clean slate
• Downside: Very high risk, might break existing functionality

Alternative 4: Complete refactor of system

• Cost: 6 weeks
• Benefit: Solves root problem
• Downside: Highest cost

Evaluate options on a cost/benefit matrix. What's the sweet spot?

Question 5: What Are the Risks?

Every technical decision carries risk. What could go wrong?

Technical risks:

• "Refactoring could introduce bugs in payment logic"
• "Migration could cause data loss"
• "We might break integrations with external payment processors"

Mitigation:

• "We have comprehensive tests for payment logic"
• "We've practiced migration in staging"
• "We have contracts with payment processors and their support team is on standby"

If risks can't be articulated or mitigated, don't proceed.

Question 6: How Do We Know It Worked?

After the refactoring, how will you measure success?

Good metrics:

• "Onboarding time drops from 6 weeks to 2 weeks"
• "Time to add new payment method drops from 3 days to 4 hours"
• "Production incidents drop from 2 per quarter to 0.5 per quarter"

Bad metrics:

• "Code looks cleaner"
• "It's easier to understand"

If you can't measure success, you can't evaluate whether the decision was right.

When Engineers Disagree

Two engineers have different estimates for the same work.

Engineer A: "2 weeks" Engineer B: "6 weeks"

How do you decide who's right?

Investigate the Difference

1. Ask them to explain their estimate. What are they accounting for?

Engineer A:

• "Direct refactoring work is ~1 week"
• "Testing is ~1 week"
• "Total: 2 weeks"

Engineer B:

• "Refactoring work is 2 weeks"
• "Understanding dependencies is 1 week"
• "Updating integrations with 3 payment processors is 1 week"
• "Testing edge cases is 1 week"
• "Total: 6 weeks"

Engineer B identified things Engineer A missed.

1. Validate the differences. Are B's concerns real?

• "How many payment processor integrations exist?" (3 or 47?)
• "How many edge cases?"
• "What are the actual dependencies?"

1. Adjust the estimate. If B's concerns are valid, A's estimate is wrong.

2. Ask about confidence. How confident are they in the estimate?

• "A: 90% confident it's 2 weeks"
• "B: 40% confident it's 6 weeks"

Who do you trust?

Red Flags for Bad Estimates

1. Estimates that are round numbers: "3 weeks" is suspiciously round. Reality is messier.

2. Estimates without breakdown: If they can't explain where the time goes, they're guessing.

3. Estimates that don't account for unknowns: Refactoring always encounters surprises.

4. Estimates that ignore integrations: Payment processing has lots of integrations.

5. Estimates that assume everything goes right: Add 25% for unexpected issues.

Making the Decision

After asking all the questions, you have data:

• What problem are we solving?
• What's the cost?
• What's the benefit?
• What are the alternatives?
• What's the risk?
• How do we measure success?
• Are the estimates credible?

Now you can make a decision. It might be:

• "Let's do the refactoring. The benefit justifies the cost."
• "Let's try the patch first. If it works, we save 6 weeks. If it fails, we refactor."
• "The risk is too high. Let's wait and do this when we have more capacity."
• "The cost is too high relative to the benefit. Let's defer this."

Building Trust with Engineers

When you ask these questions, engineers might feel defensive.

Frame it right:

• "Help me understand why this matters"
• "I want to make sure this is the best use of our time"
• "Walk me through your thinking"

Avoid:

• "Why is this taking so long?"
• "Can't you just do it faster?"
• "That seems like a long time"

Good engineers respect PMs who ask good questions. Bad engineers resent PMs who ask any questions.

Workwith good engineers.

Getting Started

1. When a technical proposal comes to you, ask the 6 questions
2. Document the answers (helps with future decisions)
3. Quantify where possible (use data, not intuition)
4. Get engineer buy-in (they're the experts)
5. Measure outcomes (did the refactoring actually help?)

You don't need to read code. You need to understand trade-offs and make decisions based on evidence, not faith.

---

Frequently Asked Questions

Q: What if engineers give me vague answers to these questions? A: Keep asking. "Code quality will improve" isn't specific enough. Push for concrete metrics. If they can't articulate them, the proposal might not be well-thought-out.

Q: Should I ever override engineer estimates? A: Rarely. Engineers are usually right about technical complexity. If you override their estimates and the work overruns, you've created a trust problem. Better to understand their estimate and make a decision based on it.

Q: How do I know if an engineer is trying to inflate estimates? A: Ask them to break it down. Padded estimates usually fall apart when you ask for details. Also, get estimates from multiple people. Consensus is usually more reliable.