working with engineering

For every 15 to 20 engineers in a company, there is one product manager. That ratio tells you something important: you are outnumbered, and you are not the one writing the code. Your authority does not come from a title. It comes from trust — earned slowly, lost instantly, and rebuilt painfully.

I have seen PMs who could write a flawless PRD but could not get a single engineer to read it. I have seen PMs with no technical background who had engineering teams bending over backwards to ship their features. The difference was never technical skill. It was how they showed up in the relationship.

Why the PM-engineer relationship breaks

The relationship breaks for one reason: misaligned expectations. Not personality conflicts. Not technical gaps. Expectations that were never set, or were assumed and never verified.

Every conflict I have seen between PMs and engineers traces back to one of three patterns:

The PM who says “just.” Just add a filter. Just change the copy. Just move this button. The word “just” tells the engineer you have already decided the work is trivial — before asking them. It dismisses their expertise before the conversation starts.

The PM who hides behind stakeholders. “The CEO wants this by Friday” is not a requirement. It is a pressure transfer. The engineer hears: “I did not push back, so now you have to absorb the unreasonable timeline.” If you cannot explain why Friday matters independent of who asked, you have not done your job.

The PM who disappears after the PRD. You write the spec, hand it over, and show up two weeks later for the demo. In those two weeks, the engineer made fifteen decisions you should have made — about error handling, about edge cases, about UX copy in error states. Some of those decisions were wrong, and now you are frustrated. But you were not in the room.

What engineers actually want from you

I have worked with hundreds of engineers across startups and large companies. I have asked them directly what they want from their PM. The answers are remarkably consistent.

Clarity on the “why.” Not business justification. The specific user problem and why solving it matters now. An engineer who understands the “why” will make better implementation decisions than one who only knows the “what.” When they hit an ambiguous edge case at 11 PM, they will choose the option that serves the user — because they understand the user’s problem.

Decisions, not options. Your job is to make product decisions. “Should we support UPI and cards, or just UPI for the MVP?” is a question the engineer should never have to ask. You should have answered it in the PRD. When you present three options to engineering and ask them to pick, you are abdicating your role.

Protection from chaos. Stakeholders change their minds. The CEO has a new idea every Monday. The sales team forwards “urgent” customer requests daily. The engineer’s job is to write code. Your job is to absorb the chaos, filter it, prioritize it, and present a stable set of requirements. If every stakeholder request lands directly on the engineering team’s plate, you are not doing your job — you are a forwarding service.

Respect for their craft. You do not tell a surgeon how to hold the scalpel. Do not tell an engineer which database to use. Define the problem, define the constraints (latency, cost, scale), and let them choose the solution. If you have a preference, frame it as a question: “I’ve seen teams use Redis for this kind of caching — would that work here, or is there a better fit?” This is collaboration. “Use Redis” is micromanagement.

Notice what Anjali did. She did not say “no” to sales. She did not say “yes” to engineering disruption. She absorbed the chaos, bought time to scope, and communicated clearly to both sides. Karthik trusts her because she protects the sprint. Meera trusts her because she did not dismiss the request.

Technical literacy: how much is enough

This is the question I get in every cohort at Pragmatic Leaders. “How technical do I need to be?”

The honest answer: technical enough to have a useful conversation. Not technical enough to write code. Not technical enough to review pull requests. Technical enough that when an engineer says “that requires a database migration,” you understand the implication — it takes time, it carries risk, it needs a rollback plan.

Here is what “technical enough” looks like in practice:

You understand your product’s tech stack at a high level. You know the frontend is React, the backend is Python, the database is PostgreSQL, and the search runs on Elasticsearch. You do not need to know how React’s virtual DOM works. You need to know that a frontend-only change ships faster than one that touches the backend.

You understand APIs. Not how to write them. How they work conceptually. A request goes out, a response comes back. If the response is slow, the user waits. If the response fails, you need an error state. When an engineer says “the third-party API has a 500ms P99 latency,” you understand that your feature will feel slow and you may need a loading state.

You understand the cost of complexity. Every feature adds code. Code needs maintenance. A “simple” feature that touches three microservices creates coupling that makes future changes harder. When you ask for something and the engineer says “it’s possible but it adds a lot of complexity,” take that seriously. Ask: “What would the simpler version look like?”

You do NOT need to pretend. The worst thing a PM can do is fake technical knowledge. Engineers detect it in thirty seconds and it destroys trust permanently. Say “I don’t fully understand that — can you explain the trade-off?” Every senior engineer I know respects that question. Nobody respects a PM who nods along and then makes a decision that proves they did not understand.

The rhythms that build trust

Trust is not built in one grand gesture. It is built in small, repeated interactions over weeks and months. Here are the rhythms that work.

Show up to standup. Not every day. But three times a week, minimum. Listen more than you talk. When an engineer mentions they are blocked, follow up within the hour. This single habit — showing up and following through — builds more trust than any amount of technical knowledge.

Do your homework before sprint planning. The PRD should be reviewed with the engineering lead before it hits the team. Edge cases should be discussed. Estimates should be sanity-checked. If the first time the team sees the requirements is in sprint planning, you have wasted everyone’s time while they parse a document in real time.

Give credit publicly. In the sprint review, in the all-hands, in the Slack channel — name the engineer who solved the hard problem. PMs get disproportionate visibility in most organizations. Redirect some of it. The engineer who spent three days debugging a race condition in the payment flow deserves to be named, not summarized under “the team shipped payments.”

Take blame privately. When a feature underperforms, when the launch has bugs, when the stakeholder is unhappy — it is your feature, your spec, your responsibility. Never say “engineering missed the edge case.” If engineering missed it, you missed it first by not specifying it.

Close the loop on decisions. When you make a product decision that changes the engineer’s work, tell them directly. Do not update a Confluence page and hope they notice. Walk over. Send a message. Say “this changed, here is why, here is what it means for your work.”

Working with engineering in Indian companies

The dynamics are different here and it is worth naming them directly.

The hierarchy problem. In many Indian organizations, the engineering manager outranks the PM. The PM cannot “direct” engineering — they have to influence. This is actually the correct dynamic for product management everywhere, but in India it is explicit rather than hidden. Learn to influence without authority. Your tools are clarity, data, and the user’s voice — not your title.

The services mindset. Many engineers in India have worked in IT services before joining product companies. The services mindset is “build what the client asks for.” The product mindset is “solve the user’s problem, which may not be what anyone asked for.” When you work with engineers transitioning from services, invest extra time in the “why.” They are not used to a PM who says “I want you to push back on my requirements.” They expect to be told what to build. Teach them that their judgment matters.

The remote and hybrid reality. Most Indian tech teams are hybrid or distributed across cities. Bangalore, Hyderabad, Pune, Gurgaon — sometimes all on one team. The rhythms I described above — showing up to standup, walking over with a decision — need to be adapted. Over-communicate in writing. Use Loom videos for context that is hard to convey in text. Be explicit about response time expectations.

The technical decision you should never make

There is one line you should never cross: do not choose the technical implementation. Define the problem. Define the constraints. Define the acceptance criteria. Then step back.

“We need response times under 200ms” is a PM statement. “Use Redis with a write-through cache” is an engineering statement. The first gives the engineer a target and the freedom to find the best path. The second tells them you think you know their job better than they do.

The exception: if you have engineering experience and the team explicitly values your technical input, offer it as a suggestion, never as a directive. “In my experience, a write-through cache worked well for this pattern — but you know this system better” is collaboration. It works when trust already exists. It backfires when it does not.

Test yourself

Where to go next

• Get the document right first: Writing PRDs That Engineers Read
• Build the habits that support execution: A PM’s Day-to-Day
• Understand where you sit in the career ladder: PM Career Ladder
• If you are coming from engineering into PM: Breaking In from Engineering