Chapter 8: Working with Engineers and Designers

You are a senior product manager leading a cross-functional squad responsible for a core user journey. Your team consists of five talented engineers and one senior designer. On paper the structure looks perfect. In reality the gears are grinding. You notice that your engineers are starting to over-engineer simple tasks. They are obsessing over architectural frameworks that do not seem to serve the user. When you ask why they are doing this they give vague answers about technical debt. Your designer sits in a separate room for weeks at a time. They produce high-fidelity mocks that are beautiful but technically impossible to implement. You feel like a team secretary. You spend your days herding cats and running from one meeting to another to provide approvals. You find yourself playing a game of telephone between the executive team and your engineers. Information is lost in translation. Trust is eroding. You are at a crossroads where you must decide how to rebuild the culture of your team. The tension lies between your desire for control and the team's need for autonomy and respect. You face a world where the lines between roles are blurring. If you do not learn how to collaborate effectively across disciplines you will continue to ship mediocre software. You must either master the art of cross-functional partnership or watch your team become a dysfunctional feature factory.

CORE SKILL OR PRINCIPLE

The core principle of effective collaboration is the transition from a hub-and-spoke model to a full-stack building culture. You must stop acting as a middleman between stakeholders and builders. Product management is a team sport that requires deep competency and mutual respect. You do not own the product. The team owns the product. Your primary value is providing clarity and conviction regarding the problem you are solving. You must move from being a bricklayer who manages tasks to an architect who manages outcomes. Success depends on your ability to facilitate a value exchange between the business and the customer. This requires you to earn the trust of your engineering and design partners by demonstrating deep knowledge of the customer and the data. You must embrace the murky overlaps between disciplines rather than drawing rigid swim lanes. In the AI era the stack is collapsing and anyone can be a builder. Your role is to convert the potential energy of your team into realised value for the user.

EVIDENCE FROM THE CONVERSATION

Evidence from experienced engineering leaders shows that product managers often irritate engineers by hoarding credit for successful initiatives. Engineers feel erased when the product manager becomes the sole front-facing person for a project. Another common friction point is a lack of empathy for technical details. When you act as if technical constraints do not matter it shows a fundamental lack of respect for the engineering craft. Managers of all types also fall into the trap of playing telephone. You become a bottleneck when you act as a filter for questions that only engineers can answer. This results in lost fidelity and wasted time. Furthermore engineers often over-engineer systems when they feel excluded from the creative process. They seek a creative outlet through code because they were denied a voice in the product direction.

A radical but effective organisational shift involves design reporting to engineering rather than product. Experience at companies like Apple under Steve Jobs showed that this structure ensures design is treated as phase zero of the engineering process. It prevents designers from creating concepts that are technically unreachable. When designers and engineers report to a single technical leader they align on what can actually be built. This structure encourages the rise of creative technologists who are comfortable with the ambiguity of conceptual design and the rigor of code.

Building strong relationships requires an understanding of incentives. Many conflicts between engineering managers and product managers arise from misaligned goals. For example an engineering manager may feel pressured to provide team members with interesting work while the product manager focuses on rapid experiments. High-performing teams often solve this by giving peer managers the same performance rating to ensure they win or lose together. At companies like Slack the team structure evolved from a triad to five legs of a stool including insights and marketing. This ensures that every viewpoint is incorporated from the beginning of the project.

Counterintuitive evidence suggests that you should wait as long as possible to draw a picture or create a prototype. Once you make a primal mark or a sketch you bias the entire team toward that specific solution. The hardest part of product building is the heavy lifting of thinking about what you are trying to do rather than producing the high-resolution comps. Jumping straight to vibe coding or AI-generated mocks often leads to unmaintainable systems because the team skipped the intentional planning phase.

Major system rewrites are frequently a trap that product teams must avoid. Engineers often underestimate the time required to migrate users and data to a new system. Legacy systems contain undocumented logic and complex business rules that are difficult to replicate. You are better off taking an evolutionary approach by uplifting specific components and cleaning up technical debt incrementally.

Platform teams require a distinct product mindset to be successful. Companies often fail to hire product managers for internal tools and leave engineers to build whatever they think is right. This results in incoherent offerings that do not improve company productivity. Effective platform PMs focus on outcome-based metrics like reducing cycle time or solving scaling problems for other application teams. Pair programming is another lever for high-velocity teams. It leads to higher rates of learning and prevents knowledge silos. Although you write less code the solution is often more elegant and easier to maintain.

PRACTICAL BREAKDOWN

You must stop hoarding credit for your team's work immediately. Start by letting your engineers and designers present their own work to executives and at all-hands meetings. Your job is to be the keeper of the vision and the facilitator of the decision. If you are the one doing all the talking you are failing to lead. Share the glory and you will find that your team is more willing to share the burden of difficult projects.

You must develop deep empathy for the technical details of your product. You do not need to be an expert coder but you must respect the complexity of the work. Ask your engineers to explain the architecture of a feature to you. Listen more than you speak. If you act as if the details do not matter you will lose the respect of your partners. Stop playing telephone by connecting people directly when a question requires technical depth.

You must involve your engineers and designers in the ideation phase from day zero. Do not hand them a finished spec and expect them to be order takers. If you exclude them from the creative process they will find outlets elsewhere through over-engineering or unnecessary refactoring. Use collaborative rituals like shaping sessions where you whiteboard the moving parts of a solution together. Use fat marker sketches to keep the fidelity low so everyone feels they can contribute to the logic.

You must resist the urge to draw prototypes too quickly. Force your team to sit in the ambiguity of the problem space for longer than is comfortable. Write down the requirements and the intended user journey in prose before you open Figma. This ensures that the heavy lifting of thinking is done before you lock in a visual direction. When you eventually prototype do so with the intention of breaking the idea rather than confirming it.

You must advocate for your platform teams. If you are a product leader ensure your platform teams have dedicated product managers who can define the strategy and manage stakeholders. Treat your internal developers as your customers. Build a findings database to aggregate internal research and avoid duplicating work. Focus on reducing the friction in the developer experience to increase the overall metabolism of the company.

You must adopt pair programming as a cultural norm rather than just a technical practice. Pairing should extend to leaders pairing with crafters to unblock difficult strategic problems. Encourage your engineers to switch pairs at a regular cadence to build knowledge redundancy. This creates a safety net so that no single person is a tower of knowledge that can cause a setback if they leave the company.

SKILL APPLICATION

Apply these collaboration skills to your daily product discovery process. When starting a new initiative form a strategy working group consisting of engineering, design, and data. Use the note-and-vote tactic to ensure that every voice is heard before a decision is made. This prevents the loudest person in the room from dominating the direction.

Implement the walk-the-store review method with your engineering and design leads. Experiencing the product together as a user allows you to notice friction points that look fine in a mock but feel janky in reality. Use these sessions to calibrate your quality bar and ensure everyone is aligned on what constitutes a great experience.

Manage technical debt like financial debt. Take on debt intentionally to buy progress you cannot afford but have a clear plan to pay it back. Before agreeing to a rewrite ask the team if the system could be evolved incrementally. If you must do a rewrite factor in a massive buffer for migration and user education.

Use your product review forums to make the product better rather than to act as a firing squad. Focus the conversation on high-risk decisions and tradeoffs. Bring working prototypes or interactive demos to these meetings so people can feel the product rather than reading about it. This high-bandwidth communication reduces the need for long requirement documents.

If you are a leader practice selective micromanagement. If a project is off course dive into the details to help the team understand the first principles. Do not do this to control them but to teach them how to think through the problem. Pull back once the team demonstrates they have the correct framework for making decisions.

ACTION CHECKLIST

• Ask your lead engineer this week what is one thing you can do to make their team more successful.
• Let an engineer or designer present the next product update to the executive team.
• Identify a recurring meeting where you are playing telephone and replace it with a direct Slack channel or sync for the builders.
• Block out a four-hour window for a shaping session with your design and engineering leads for your next project.
• Create a roles-and-responsibilities document where each team member writes what they expect from their counterparts.
• Schedule a walk-the-store review where you and your triad experience your most critical user journey.
• Audit your current project list and identify any major rewrite that should be converted into a staged evolution.
• Recruit a braintrust of three peers to give you raw feedback on how annoying you are as a PM.
• Replace your next high-fidelity design review with a fat-marker whiteboard session to focus on logic.
• Assign a single-threaded owner to every major work stream in your group.
• Ask your engineers which parts of the codebase represent strategic technical debt you can leverage for speed.
• Set a personal SLA to respond to all engineering blockers within four hours.
• Identify one platform task that is currently managed via a spreadsheet and assign a PM to automate it.
• Eliminate one low-leverage process from your team's workflow such as detailed Jira ticket writing for senior engineers.
• Conduct a pre-mortem for your next launch with representatives from sales, engineering, and support.
• Interview one customer who recently stopped using your product and share the raw recording with your engineers.
• Write a three-page strategy document that includes a clear diagnosis of the technical and business challenges you face.
• Set a deadline for a pending product decision and stay in the room until it is resolved.
• Define who your product is NOT for and share that guardrail with your designer today.
• Ask your lead engineer what the most technically elegant part of the product is that customers do not care about.
• Commit to a six-week cycle for your next major initiative and use the nine-box implementation framework to manage scope.