The hard-cast roles I often see in a newly-turned-agile organization tend to drive some unproductive ideas about how people should communicate. Specifically, regarding what not to communicate.
Sure, you don't want to bore a freshly-minted product owner with technical details but the goal is nothing to do with boredom. Instead, it's about signal-to-noise ratio.
Technical details are the purview of an engineer but the outcomes of technical choices have ramifications that are unquestionably business-facing.
Consider the following (made-up) report from an engineer to a product owner.
I did it the right way. I noticed there was a Strategy pattern indicated by the problem. So I took care to properly-encapsulate the variation and extract the common part away. I made sure I wrote a full suite of tests because I'm a test-driven developer.Here's an alternative way of saying the same thing.
I did it the right way. There are currently several options and I made sure adding or subtracting choices won't have an undue cost, later. I also made sure that nobody will be able to break this functionality without us finding out immediately and fixing it before it has a chance to become a real problem.Imagine you are a product owner with no technical knowledge. Which of those sounds better to you?
The answer should be "the latter".
For one thing, there's nothing technical in it. For another, the first report sounds like it's about a developer's sense of pride. The latter is a clear delineation of the real costs and benefits involved in doing things the right way. It's information that is useful to the product owner.
That's the key. It's okay to talk about technical matters with nontechnical people. If you have the impulse to do so, there's probably a good reason. There's something you are trying to communicate that is actionable or meaningful to them.
Just make sure the message is focused on the part that will be interesting to its recipient instead of expressed in the way you find most appealing or convenient.
