Some nice points for action and the basics of interoffice communication. The article/blog misses a key item for 'web-workers' aka Developers where there is oft

Some nice points for action and the basics of interoffice communication. The article/blog misses a key item for 'web-workers' aka Developers where there is often a breakdown/non-existence of the understanding of development, testing, releasing especially around time costs. In my experience, it's the engagement of both the developer/development team with the wider business around a deep understanding of the solution and technologies involved. Where I have experience conflict is when, for example, management/Product owner thinks (often misguidedly) that changing a service/web page can be done in an afternoon. However, this is not only the fault of the product owner. If he/she is unwilling to understand the details of what is going on, yes there will always be conflict. However, it is also the responsibility of the developer/dev team to take the product owner on the journey. Share all the details, show what is being done: taking the complex and making it simple. In many cases, I have experience a dev team that wasn't willing to share the details, the 'I know best' position. In a principal/agent relationship with a short term delivery this is fine. In a long term relationship this engenders a lack of trust on both sides and is likely to undo any of the methods mentioned in the article.