Working with Engineers

When you first join a team, you have no built-in credibility with engineers — you have to earn it. Do that by learning voraciously from the most influential people around you, staying close to real customer problems, and never acting as a telephone between engineers and stakeholders. Show engineers you trust their ideas and they will trust your judgment.

As a new PM, your job is to define the shape of what you're building clearly enough that an engineer can hold it in their head and start working — not a full spec, not just a user story, but a concrete description of the key screens, flows, and interactions. If engineers keep coming back to ask what you actually meant, you haven't gone deep enough. You don't need to know how the code works; you need to know what the thing does.

Think of your job as drawing a box: you define the edges clearly enough that the team knows what's inside and what's out, but everything inside the box is theirs to solve. A vague user story leaves engineers guessing; a finished wireframe steals their job. A shaped sketch — key screens, key flows, key constraints — hits the sweet spot where engineers can be creative and fast at the same time.

When engineering wants to do a rewrite and you want to ship a new feature, it feels like a fight. But both sides usually have real reasons. Instead of trying to win, ask: what outcomes would make each option obviously correct? Then figure out which of those outcomes is actually true right now.

As a new PM, your instinct might be to present the work, own the narrative, and push engineers to just tell you when things will be done. That instinct will cost you everything. Engineers notice when you take credit, when you dismiss complexity, and when you treat them as hands instead of minds. Start by sharing the spotlight, asking genuine questions about technical tradeoffs, and letting engineers speak for their own work.