Fostering Business Acumen in Engineering Teams Recently, I had a conversation with my ex-coworker. He told me a story about how he views the relationship between engineering leaders and product owners. He used to confront the product team often. Now, with the maturity that comes from career growth and in his role as the head of engineering, he believes it’s important to be a good partner to his product team. Earlier this year, I joined several calls with our product teams to align priorities between engineering and product. The discussions, however, quickly turned tense. In one meeting, my team faced tough questions from product owners about a delayed delivery date and its impact on business timelines. In another, we were held accountable for a bug that caused a critical feature to malfunction, disrupting users and creating frustration on both sides. On a separate call, we resisted a proposed direction from the product team, as it conflicted with our architectural goals and technical roadmap. This highlighted the gap between our priorities — technical soundness versus immediate business needs.” “The job of the product manager is to discover a product that is valuable, usable, and feasible. The job of engineering is to deliver a product that is reliable, scalable, and maintainable. These are two different jobs, and they often conflict.”
— Marty Cagan, Inspired: How to Create Products Customers Love These conversations were challenging, leaving me frustrated and disheartened. They highlighted a recurring theme: a disconnect between the priorities of engineering and product, often leading to friction rather than collaboration. The Fundamental Problems “The root cause of most of these failed efforts is that they are solution-based rather than problem-based.”
— Marty Cagan Engineers cannot deliver what the product owners want on time. Engineers do not want to do what the product owners want them to do. Stakeholders are unhappy about the fact that the engineering teams are slowing down the growth of the business. Product teams often expect engineering teams to operate as a subordinate function to the product team. Meanwhile: Engineering teams have their own ideas about product designs, especially when those designs are coupled with architectural designs. Engineering teams have engineering roadmaps for the sake of technology. Engineering team leaders want product teams to follow the engineering roadmap. Product teams face intense pressure to deliver features that directly impact business growth, often within tight deadlines. They may choose existing solutions from third parties instead of building in-house solutions, especially when misalignment happens between engineering and product. Conflicts arise from the differing perspectives and priorities of the two parties. Engineering teams often feel pressured to meet deadlines at the cost of long-term stability, while product teams focus on speed to market. This creates tension but also an opportunity for collaboration. Manage Relationship Between Engineering and Product Teams Engineering serves products, and product owners need engineering assistance to boost growth. Of course, engineering teams are not attached to the product team. But they are not enemies either. The engineering team should be a partner and advisor to the product team. If businesses always chase deadlines without proper architectural design and cleaning up technical debt, systems will eventually fall apart. Engineering teams should give technical advice to stakeholders, suggesting sustainable, cost-saving solutions so that the business can always be successful. On the other hand, if engineers focus only on technology without considering business value, there is a risk that what we build might diverge from what the business needs. Here are some suggestions for fellow engineering leaders Understand the business and how engineering can support its goals.
Be a trusted advisor to the product team.
Avoid designing tech solutions solely for technology’s sake.
Develop business acumen to better align engineering decisions with business needs. Suggested Actions Improving the relationship between engineering and product teams requires intentional effort, clear communication, and mutual understanding. Schedule recurring meetings to review and align engineering and product roadmaps. “The single biggest problem in communication is the illusion that it has taken place.”
— George Bernard Shaw
“Most software projects fail because of a lack of communication, a lack of understanding, and a lack of trust.”- Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams I started exercising my storytelling skills, and I have often explained the necessity of investing time in tech roadmap during the calls. I have always brought business values to the table when negotiating tech investments with product teams. Instead of saying, “We need to refactor this codebase,” explain, “Refactoring this codebase will improve system reliability and provide better user experiences.” “The most powerful person in the world is the storyteller. The storyteller sets the vision, values, and agenda of an entire generation that is to come.”
— Steve Jobs Always show an empathetic and supportive image of engineering teams in front of stakeholders. I often acknowledge that meeting deadlines can be challenging for the engineering team, but reassure them that we are committed to helping achieve the goal. For example, if a deadline seems unrealistic, instead of saying, ‘We can’t do this,’ propose alternative solutions like prioritizing features in phases. Focus on delivering a Minimum Viable Product (MVP) first, then move on to subsequent features. Engineering teams should actively listen to stakeholders’ concerns and seek to understand the reasoning behind their requests. Be a good listener and ask clarifying questions. I often ask ‘why’ during meetings at appropriate times to ensure the engineering team isn’t simply taking orders. We should be able to provide constructive advice. At the end of the day, it is to Build Trust across product and engineering teams. It takes time, but the investment is worthwhile. One key to success is ensuring that the entire team feels ownership and responsibility for the product’s success. They need to feel empowered to do whatever is necessary to meet their objectives.
— Marty Cagan, Inspired: How to Create Products Customers Love A Reflection If you were the owner of your company, how would you evaluate the value that your engineering team provides? What is your expectation of the engineering team? How would you balance the need for quick deliverables with the long-term health and success of the product? Fostering Business Acumen in Engineering Teams Fostering Business Acumen in Engineering Teams Recently, I had a conversation with my ex-coworker. He told me a story about how he views the relationship between engineering leaders and product owners. He used to confront the product team often. Now, with the maturity that comes from career growth and in his role as the head of engineering, he believes it’s important to be a good partner to his product team. Earlier this year, I joined several calls with our product teams to align priorities between engineering and product. The discussions, however, quickly turned tense. In one meeting, my team faced tough questions from product owners about a delayed delivery date and its impact on business timelines. In one meeting, my team faced tough questions from product owners about a delayed delivery date and its impact on business timelines. In another, we were held accountable for a bug that caused a critical feature to malfunction, disrupting users and creating frustration on both sides. In another, we were held accountable for a bug that caused a critical feature to malfunction, disrupting users and creating frustration on both sides. On a separate call, we resisted a proposed direction from the product team, as it conflicted with our architectural goals and technical roadmap. This highlighted the gap between our priorities — technical soundness versus immediate business needs.” On a separate call, we resisted a proposed direction from the product team, as it conflicted with our architectural goals and technical roadmap. This highlighted the gap between our priorities — technical soundness versus immediate business needs.” This highlighted the gap between our priorities — technical soundness versus immediate business needs.” “The job of the product manager is to discover a product that is valuable, usable, and feasible. The job of engineering is to deliver a product that is reliable, scalable, and maintainable. These are two different jobs, and they often conflict.” — Marty Cagan, Inspired: How to Create Products Customers Love “The job of the product manager is to discover a product that is valuable, usable, and feasible. The job of engineering is to deliver a product that is reliable, scalable, and maintainable. These are two different jobs, and they often conflict.” “The job of the product manager is to discover a product that is valuable, usable, and feasible. The job of engineering is to deliver a product that is reliable, scalable, and maintainable. These are two different jobs, and they often conflict.” — Marty Cagan, Inspired: How to Create Products Customers Love — Marty Cagan, Inspired: How to Create Products Customers Love These conversations were challenging, leaving me frustrated and disheartened. They highlighted a recurring theme: a disconnect between the priorities of engineering and product, often leading to friction rather than collaboration. The Fundamental Problems The Fundamental Problems “The root cause of most of these failed efforts is that they are solution-based rather than problem-based.” — Marty Cagan “The root cause of most of these failed efforts is that they are solution-based rather than problem-based.” “The root cause of most of these failed efforts is that they are solution-based rather than problem-based.” — Marty Cagan — Marty Cagan Engineers cannot deliver what the product owners want on time. Engineers cannot deliver what the product owners want on time. Engineers do not want to do what the product owners want them to do. Engineers do not want to do what the product owners want them to do. Stakeholders are unhappy about the fact that the engineering teams are slowing down the growth of the business. Stakeholders are unhappy about the fact that the engineering teams are slowing down the growth of the business. Product teams often expect engineering teams to operate as a subordinate function to the product team. Product teams often expect engineering teams to operate as a subordinate function to the product team. Meanwhile: Engineering teams have their own ideas about product designs, especially when those designs are coupled with architectural designs. Engineering teams have their own ideas about product designs, especially when those designs are coupled with architectural designs. Engineering teams have engineering roadmaps for the sake of technology. Engineering teams have engineering roadmaps for the sake of technology. Engineering team leaders want product teams to follow the engineering roadmap. Engineering team leaders want product teams to follow the engineering roadmap. Product teams face intense pressure to deliver features that directly impact business growth, often within tight deadlines. They may choose existing solutions from third parties instead of building in-house solutions, especially when misalignment happens between engineering and product. Conflicts arise from the differing perspectives and priorities of the two parties. Conflicts arise from the differing perspectives and priorities of the two parties. Engineering teams often feel pressured to meet deadlines at the cost of long-term stability, while product teams focus on speed to market. This creates tension but also an opportunity for collaboration. Manage Relationship Between Engineering and Product Teams Manage Relationship Between Engineering and Product Teams Engineering serves products, and product owners need engineering assistance to boost growth. Of course, engineering teams are not attached to the product team. But they are not enemies either. The engineering team should be a partner and advisor to the product team. If businesses always chase deadlines without proper architectural design and cleaning up technical debt, systems will eventually fall apart. Engineering teams should give technical advice to stakeholders, suggesting sustainable, cost-saving solutions so that the business can always be successful. On the other hand, if engineers focus only on technology without considering business value, there is a risk that what we build might diverge from what the business needs. Here are some suggestions for fellow engineering leaders Understand the business and how engineering can support its goals. Be a trusted advisor to the product team. Avoid designing tech solutions solely for technology’s sake. Develop business acumen to better align engineering decisions with business needs. Understand the business and how engineering can support its goals. Be a trusted advisor to the product team. Avoid designing tech solutions solely for technology’s sake. Develop business acumen to better align engineering decisions with business needs. Suggested Actions Improving the relationship between engineering and product teams requires intentional effort, clear communication, and mutual understanding. Schedule recurring meetings to review and align engineering and product roadmaps . Schedule recurring meetings to review and align engineering and product roadmaps “The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw “Most software projects fail because of a lack of communication, a lack of understanding, and a lack of trust.” - Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams “The single biggest problem in communication is the illusion that it has taken place.” “The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw — George Bernard Shaw “Most software projects fail because of a lack of communication, a lack of understanding, and a lack of trust.” “Most software projects fail because of a lack of communication, a lack of understanding, and a lack of trust.” - Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams - Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams I started exercising my storytelling skills, and I have often explained the necessity of investing time in tech roadmap during the calls. I have always brought business values to the table when negotiating tech investments with product teams. Instead of saying, “We need to refactor this codebase,” explain, “Refactoring this codebase will improve system reliability and provide better user experiences.” storytelling “The most powerful person in the world is the storyteller. The storyteller sets the vision, values, and agenda of an entire generation that is to come.” — Steve Jobs “The most powerful person in the world is the storyteller. The storyteller sets the vision, values, and agenda of an entire generation that is to come.” “The most powerful person in the world is the storyteller. The storyteller sets the vision, values, and agenda of an entire generation that is to come.” — Steve Jobs — Steve Jobs Always show an empathetic and supportive image of engineering teams in front of stakeholders . Always show an empathetic and supportive image of engineering teams in front of stakeholders I often acknowledge that meeting deadlines can be challenging for the engineering team, but reassure them that we are committed to helping achieve the goal. For example, if a deadline seems unrealistic, instead of saying, ‘We can’t do this,’ propose alternative solutions like prioritizing features in phases. Focus on delivering a Minimum Viable Product (MVP) first, then move on to subsequent features. Engineering teams should actively listen to stakeholders’ concerns and seek to understand the reasoning behind their requests. Be a good listener and ask clarifying questions . I often ask ‘why’ during meetings at appropriate times to ensure the engineering team isn’t simply taking orders. We should be able to provide constructive advice. Be a good listener and ask clarifying questions At the end of the day, it is to Build Trust across product and engineering teams. It takes time, but the investment is worthwhile. it is to Build Trust across product and engineering teams. One key to success is ensuring that the entire team feels ownership and responsibility for the product’s success. They need to feel empowered to do whatever is necessary to meet their objectives. — Marty Cagan, Inspired: How to Create Products Customers Love One key to success is ensuring that the entire team feels ownership and responsibility for the product’s success. They need to feel empowered to do whatever is necessary to meet their objectives. One key to success is ensuring that the entire team feels ownership and responsibility for the product’s success. They need to feel empowered to do whatever is necessary to meet their objectives. — Marty Cagan, Inspired: How to Create Products Customers Love — Marty Cagan, Inspired: How to Create Products Customers Love A Reflection A Reflection If you were the owner of your company, how would you evaluate the value that your engineering team provides? What is your expectation of the engineering team? How would you balance the need for quick deliverables with the long-term health and success of the product?

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Engineering and Product Teams: Are They Partners or Frenemies?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How I Super-Charged My LangChain-MySQL Agent: Part 2

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Popular Websites Built With Django

10 Best VS Code Extensions to Improve Your Productivity

11 Reasons Software Engineering Will Never Die

How I Super-Charged My LangChain-MySQL Agent: Part 2

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Popular Websites Built With Django

10 Best VS Code Extensions to Improve Your Productivity

11 Reasons Software Engineering Will Never Die

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps