The Product and Engineering Relationship

As a software business grows, product and engineering may find themselves drifting further apart. Product teams grow larger, engineering splits into smaller specialist teams, and communication can start to break down. Only through a strong connection between these 2 departments can the company goals be achieved and move the company forward.

Department Juggling

As a product manager you will find yourself pulled in many directions by stakeholders in all departments with their own goals for where the business is heading. A lesser heard voice can be found in the engineering world where stakeholders can feel bound by the decisions from product or other areas.

Your Engineering Counterpart

Enter your best interdepartmental friend, the engineering manager. They might be the head of an agile team, squad, tribe, or any other organisational group you can think of.

While all other parts of the business are humming along selling subscriptions and finding customers, this engineering manager (EM) is working closely with their team on the product with their tight knit group of engineers. They might be introverted, extroverted, strong willed, indecisive. Whoever they are, their participation in the product process is key to building great products.

Building a relationship with this individual and them team as early as possible is a pathway towards success. You don’t want to be months down the line with a team that sees product as an interference to the build instead of an ally.

Fostering The Relationship

Depending on the personality type of your EM counterpart, building this relationship will require different steps. Here are some of the key points I have focused on in my endeavours:

  • Learn about their “why”
    Product lie on the foundation of “why” for everything we research and implement. What are the driving factors to the engineering team and what bring them to work every day? Are they truely invested into the product’s future and how they impact the business? Do changes in features and the upwards (hopefully) graph help show them they are important?
  • Establishing trust
    Trust is the most important part in any relationship. Engineering need to know that when they are building a feature, timelines are provided by their estimates and may be wrong. They won’t be thrown under the bus by product with “he said, she said” mentality, but rather openly discussed with shared accountability and a path cultivated to move forward. When product is bringing forward an idea, engineering trust the data that is shown to them and how it will impact the customer. Without boundaries and trust on each department putting their best foot forward, there will never be a developed relationship and autonomy.
  • How to communicate effectively
    “Let’s have a meeting about that, ill book an hour into your calendar” can sound like a dream to some, and a death sentence to others. How and when to communicate can be paramount to effective team. Some may prefer to keep chats brief and to the point so they can move forward with what they need to do, while others might want to bring the other through the full journey towards a decision. This will vary from stakeholder to stakeholder, but the balance between these 2 approaches are important to estabilish to restrict resentment on being a hindrance to the process. Open feedback and listening to their concerns is healthy for any relationship

Engineering Feedback

Sales needs a new feature for their imminant deal.

Marketing needs a new feature for the next segment they have been asked to target.

Customer success needs these 12 features to keep customers engaged.

What does engineering need?

Some may believe that only the customer facing staff have any idea on what the product needs. This couldn’t be further from the truth. You will find the engineering team who know all the ins and outs about the product are much more vocal than previously thought. This could be in the form of feature enhancements, but can also be seen in the changes needed to work effectively, technical debt.

Technical debt will often be the item on your roadmap put to the end of the list. It’s value can be murky to other departments, its hidden from the customer in many situations, and the complaints from engineering often fall on deaf ears. This is where your relationship with the EM can really thrive.

A strong team needs to hear the concerns and find a way forward that works for all stakeholders involved. If the engineering team has trust that their problems will be resolved, a stronger bond can be formed. Value in fixing technical debt should be calculated just as any feature. Time spent fixing debt is time saved for future development and happiness and engagement with the engineering team, which can be priceless.

The Product Journey

Product is all about leading without influence. These engineering managers and their teams aren’t direct reports to yourself, but are you biggest allies in providing value to your customers. So what can you do to ensure they are invested in the mission?

  • Bring them in early
    Discussing a new feature? Bring the team in early to discuss the feature and you will get quick feedback on how it impacts them and any ideas they bring to the table. Show the value it will bring to the customer, show the metrics and data supporting your decisions, trust will be established.
  • Share the limelight
    Engineering can sometimes be left in the dark when it comes to releases. Sales can get attention for that awesome new client that came in, marketing can be praised for the thousands of new signups in their segment, product can be seen through their blog or newsletter post about their brilliant idea. Engineering can feel deflated and underappreciated, though massive effort was placed on their behalf. Ensure to share the successes and give credit where it is due. This will make the team much more invested into the outcomes rather than just moving onto the next feature. Metrics and data are a great way to visualise the impact they make.
  • Share the failures
    Failures are inevitable. Ownership of failures helps bring the teams closer together and feel less alone. “Engineering didn’t meet their deadline”, “Engineering released those bugs”. These kinds of conversations break apart the established trust and harm the relationship long team. If you are sharing the credit, you should also be sharing the failures.

Empowerment

Establishing these boundaries, building trust, and having the team invested in the mission isn’t something you can check off the list. It’s an ongoing and collaborative process which pays dividends a little more every day. Having a truely empowered team will take the time and effort to build, but is priceless in the long term.