The PM and engineering relationship

15 tips on how to build great working relationships with your engineering partners

👋 Hi, I'm Jaryd. Welcome to this weeks Slice— the free weekly newsletter for PMs and founders about product and startups.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice


To a large degree, how succesful you are at a company depends on how good your relationships are with other people on the team.

Everything you do involves working and partnering successfully with other people — product management is one of the least siloed roles at an organization. And I say partnering because it's the healthiest way to think about building mutual relationships with people, and creating a team culture where people feel respected and want to do the best work they can for each other. 

PMs sit at the intersection between Business (executive & other departments), UX (design) and Technology (engineering) — you're working within that all day. This means if you want to be productive and get your job done well, it's essential to work with people the right way — because there definitely is a wrong way, and that way sours relationships, affects the culture, and can drastically hinder the quality and speed of your [teams] work, which has a ripple effect across the company.

I was recently asked by my manager to put together some onboarding documentation for PMs at our company and create a more formal onboarding process.
Part of that included an overview of the different teams, people on them, and best practices for how to partner with them successfully. Based off my experience, speaking with engineers on the team, and further digging online — I’ve put 15 points together that I think pretty well encapsulates how PMs can build successful working relationships with your engineering partners.

In the coming weeks, I’ll do the same for working with designers as well as some insights into working with marketing and the executive team. 

Let’s jump in! 👇

Working with engineers

PMs lead the product, and engineers build it — right?

Well, not quite —  both roles have unique expertise which come with their own opinions about how to improve and grow the product, especially when working with product engineers who are very familiar with the customers and use-cases (which is extremely useful!). And things can become more confusing if the PM starts weighing in too heavily on technical direction, or if an engineer starts deciding on features the product needs. 

A healthy relationship with your engineering partners sets you up for collaboration where you can push each other to think more critically, and explore new approaches to solving problems together. When done right this process is really enjoyable.

It's important to remember — engineers will often have experience working on a team just fine without a product manager. PMs are a role that often only gets hired for later, and engineers will have worked with designers before to do largely what they see as the same value you're adding.

This means your goal should be to have engineers who actually want a PM.

So let's dive into some tips on how to do that:

1. Establish empathy.  

The better you can understand your engineers, the better your relationship will be. This goes way beyond just understanding that they are a critical function on the team. What you want understand is where they're coming from, ideally personally and as an engineering function -- what are their motivations  concerns, pains, ideas, perspectives, etc? 

Just like you need to have customer and business context to make decisions – having engineering context is also extremely helpful and important as you approach tradeoffs

So, how do you establish empathy? Much like when speaking to customers, its' pretty simple – actually care enough to be curious, ask questions, and listen with intention. 
You can start by asking each engineer what they'd like from a product manager in the first place, I find this is a great starting point to ask more questions around, and I always get insightful perspectives (hence, this list!) 
 

2. Treat them like partners.

Engineers are absolutely not code monkeys. They're not there just waiting for requirements and tickets to come from you. They're extremely talented people with lots of value to add during the product lifecycle beyond writing code – especially when you involve them early and provide the right context to them.

Some ways to do this are looping engineers into customer research calls, bringing them into early workshops and brainstorming sessions, collaborating during scoping, and including them in product decisions.. The balance you have to find here is not to overburden them with your job.
 

3. Communicate strategy and the roadmap.

Your job as a PM is to  evangelize what your product strategy and roadmap is as often as you can. When you're working with engineering, explain the context of how what you're discussing fits into the overarching goals of the company and product. People care to know that what they're doing actually matters.

And beyond that – having everyone aligned on the big picture stuff first makes working on the details a lot easier and more productive.
 

4. Communicate the goal and context. 

The more context you can provide people on any team, the more engaged they'll be and more value they can contribute to the process.

Sharing stuff like customer, market, business, and other stakeholder context – focusing on what outcome or goal you're trying to achieve – and sharing insights from your research into the problems and use cases a specific audience has, really sets other people up for success.

It helps create a shared understanding about what you're all working towards together, and gives clear reasoning behind the work. 

Some ways to do this (as with point 3 above), are:
- Share a 1-pager or a project deck
- Write context-rich tickets
- Bring engineers into workshops/brainstorming sessions
- Include them in product decisions
- Meet with engineering to talk through this stuff
- Repeat it frequently in project checkins


This means (in most cases), avoid handing overly-prescriptive requirements to engineers. Always put the problem before the solution and keep room for flexibility so they can also do creative work and contribute ideas.
 

5. Prioritize and communicate your framework.

When working with engineers and planning tasks, you need to be able to make clear decisions about what's important, and what's nice to have. If the priorities are ambiguous or non-existent, you're going to lose rapport with engineering. 

As you prioritize, you should discuss your rationale behind your decisions – this is really important – as it allows others to understand why,  and then share their feedback if they have different opinions. 

Engineers also care about what's being prioritized at a personal level, because the stuff they build ultimately goes on their resume. If they don’t believe that what they’re working on will have a real impact, it may reflect in their motivation to do the work (and work with you). 
 

6. Don't overuse process.

One of the most annoying things a PM can do is overly rely on processes and frameworks to do stuff. This can be tempting, especially for new PMs (I did this, 100%), but can really slow things down and frustrate engineering and others on the team.

There isn't a right way to build products — applying templates from books, blogs, videos, etc without knowing or understanding the context that they're really used within sets you up to miss the nuance that's specific to your business, market, and team.

Learning about them is awesome and extremely helpful – but be cautious about applying them blindly and dragging your team through the motions of using them. 

A good approach is to find areas of improvement, and test aspects of a framework or process you believe can improve that after discussing it with the team and getting their feedback. 
 

7. Write clear docs/tickets.

The tickets you write are essentially the blocks of executable work you're setting up for engineers.

You write a ticket --> an engineer picks it up --> they build it.

A ticket that's unclear, unstructured, or has conflicting information can create a lot of confusion for engineering. This reflect badly on you, and you should take a lot of pride in the documents and tickets you prepare.  

When docs are well presented, are rich in context, and make it clear about what needs to be done and why – you're making the life of designers, engineers, and QA much easier. 

Tickets should also be treated as the source of truth for the work to be done, because that's what the engineers are using to build against. That means it's important to keep tickets up to date with the latest information and decisions. 
 

8. Be available to respond to questions and unblock them.

An important part of your relationship with engineering is to keep them unblocked. When an engineer is blocked – something valuable isn't getting worked on.

That could mean being responsive to asynchronous communication (like Slacks or emails) and getting back to people with answers as quick as you can – or making time to meet with them and hop on calls, even if unscheduled. 
 

9. Stay on top of project details and update them on changes.

It goes without saying that you need to always be on-top of your projects. However, sometimes changes in details don't always get communicated as well as they should to engineers who are busy working on something.

For example — if during the development of a milestone there's a design or scope change, it's not enough to just update the design file and the tickets. That's necessary, but you should also let them know directly about the change and what drove it, as they could very well have engineering plans in place already based off the original scope. 
 

10. Avoid wasting their work. 

One of the quickest ways to ruin your relationships with engineering and lose credibility is to be known as a PM who wastes their time and work. 

When focusing on a solution build instead of focusing on the problem/context/job-to-be-done — that's a scenario that can easily happen. Validate as much as you can before passing work to engineering. Do the research, iterate on designs, test what you can – then move onto writing code. 

Building against too many assumptions (which can happen when over-scoping) increases the risk that you build stuff that needs to be taken away.  That affects customers, and wastes time that could have been spent improving.

It's easy to go forwards, it's much harder to go backwards. That's incremental product development — that's how you avoid wasting engineering work.
 

11. Protect their time.

The point above relates to protecting the valuable time of engineers, but beyond that, you should also protect their time from meetings and other teams.

This doesn't just apply to engineers, but when you're scheduling necessary meetings, be sensitive to peoples times and only bring in people who need to be there. 

Also, if you're invited to a meeting and see a bunch of engineers on the attendee list - look at the agenda and see if that's really necessary. If it's not obvious why 3 engineers are on a call marketing has setup, just politely ask the meeting owner why they're needed, and explain where you're coming from.

 

12. Don't commit to dates for engineers. 

Your job is to find out how long it's going to take to build something by asking engineering — not to determine that for them.

Even if you're technical and have a good sense of the build time — do not be the PM who takes dates to stakeholders without agreement from engineering. This is extremely annoying and can create sour working relationships. 

Sometimes there are hard deadlines driven by business needs , or market/seasonal timings (i.e Black Friday). Even in that case — the dynamics of committing to dates for engineers is different. Here, you should take your hard requirements to the engineering team, be clear why this target date is so important, and work with them to figure out feasibility, scope, or the case for brining in more resources.

The point here is collaborate with engineers on dates before brining them to stakeholders. 
 

13. Don't expect everything to be quick.

Things take time to build — mostly longer that you expect. And showing a respect and appreciation for the development process is a crucial part of having good work relationships. 

Sometimes even something seemingly trivial to do affects many other parts of the system and requires more time to build than you'd guess – then there's QA, code review, organizing a production release. That's process and time. 

Approach anything to do with “times” when working with engineers with a beginners mindset. Ask, and let them speak first.
 

14. Respect technical constraints and their push-back on things.

Similarly to the above point, things sometimes have hidden complexities and technical dependencies in order to be done that you are not aware of. 

If an engineer questions if the outcome is going to be worth the effort — take it very seriously. At this point, you should have already equipped them with the context and goal, so dig into what the complexities are, realign on priorities if needed, or think about another approach that will take less time to build and still achieve the same goal.

Ignoring push-back, especially based on technical issues, comes off as if you're not really concerned about the work they need to do in order to achieve something, and just the end-result — and ironically ignoring their push back can easily lead to a worse outcome.
 

15. Share credit.

One of the best things you can do as a PM, not just for engineers, is to amplify the success of others and surface the work people did, sharing as much credit as you can. 

Share credit for who was involved in achieving outcomes, and amplify the details contributed by others. If an engineer pushed back on something and suggested a new approach — let other people know!

If you have any additional advice to add to this, I’d love to hear in the comments below! 🤔

Leave a comment

Otherwise, next week I’ll be doing the same for working with design partners. If you’re in the US and celebrating Thanksgiving — enjoy and be safe! 🦃


The Product Slice is the free weekly newsletter for PMs and founders about product and startups.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice