It's absolutely common and unavoidable that certain specialists don't automatically understand each other because they use different thought patterns and terminology. Some of this can be resolved through education and training, but at some point it becomes inherent to the expertise itself—and then somebody needs to be there to bridge the gap.
Exactly Uwe! 💯 Our job is to coach and make the gap easier to close. But exposure is key for technical staff to have an opportunity to improve some communication areas.
Although there is a merit to that, most people are not notoriously bad at talking in a business environment. From my experience, it's better if I handle the non-technical discussion since my role is a product manager, while I can leave the engineering side of things to our engineering lead.
I don't need to hide the person, or push them forward unnecessarily, and although coaching can help, we shouldn't forget that they are engineering leads, not heads of engineering or engineering managers. It's expected from them to handle engineering-level conversations and people conversations within their own teams, not as much in business environment.
Thank you for your comment. Glad to have your input, which is very valuable.
I completely understand your perspective, and I see where it comes from. For me is a matter of time and complexity when business requirements or goals are tangled up with technical constraints or approaches. When these moments arrive, it is important to be pragmatic and find a solution forward.
The best methodology, at least for me, is to have different views on the table and being able to discuss them. Not having strong feedback on the technical side will hinder any solution that might be put forward in the product. That's why it is important to put the DEVs forward and have them be able to share insight while understanding what is being discussed,
I have personally been on both ends of this scenario: Putting forward DEVs and shielding them from business. In my experience, the strongest teams were the ones that had developers speaking directly with the business and were coached on how to communicate in these circles. In fact, having Dev and Biz together is one of the Agile principles.
It's absolutely common and unavoidable that certain specialists don't automatically understand each other because they use different thought patterns and terminology. Some of this can be resolved through education and training, but at some point it becomes inherent to the expertise itself—and then somebody needs to be there to bridge the gap.
Exactly Uwe! 💯 Our job is to coach and make the gap easier to close. But exposure is key for technical staff to have an opportunity to improve some communication areas.
Although there is a merit to that, most people are not notoriously bad at talking in a business environment. From my experience, it's better if I handle the non-technical discussion since my role is a product manager, while I can leave the engineering side of things to our engineering lead.
I don't need to hide the person, or push them forward unnecessarily, and although coaching can help, we shouldn't forget that they are engineering leads, not heads of engineering or engineering managers. It's expected from them to handle engineering-level conversations and people conversations within their own teams, not as much in business environment.
Hello Adrian,
Thank you for your comment. Glad to have your input, which is very valuable.
I completely understand your perspective, and I see where it comes from. For me is a matter of time and complexity when business requirements or goals are tangled up with technical constraints or approaches. When these moments arrive, it is important to be pragmatic and find a solution forward.
The best methodology, at least for me, is to have different views on the table and being able to discuss them. Not having strong feedback on the technical side will hinder any solution that might be put forward in the product. That's why it is important to put the DEVs forward and have them be able to share insight while understanding what is being discussed,
I have personally been on both ends of this scenario: Putting forward DEVs and shielding them from business. In my experience, the strongest teams were the ones that had developers speaking directly with the business and were coached on how to communicate in these circles. In fact, having Dev and Biz together is one of the Agile principles.
Love this!
Glad to hear that 💯
for sure! would love your thoughts on some of my stuff. follow me back, I can DM you?