Blaming Engineering

In this episode, Dave and Jamison answer these questions:

1. Listener Casey asks,

   My team has built an internal framework for continuous delivery that enabled a key product release last year. The tooling has gained widespread adoption and popularity throughout the org, to the point that some leaders are requiring teams to use the framework for any new services. Things are generally going great, except that “my team” consists of only 2 people including myself, and we have so much work that the soonest we can look at new features is ~18 months from now. Some individuals, who are being required to use our framework, are frustrated and protesting loudly about how the framework doesn’t work exactly the way they think it should. How can I shelter my team from the outbursts of unhappy users? Or bolster their resolve so they don’t take on the anxiety of growing pains?

   P.S. We’re all remote so this happens 99% in chat channels and DMs.

2. If something goes right, product takes credit. If something goes wrong, engineering takes the blame. How do you change that organizational dynamic? (Other than your usual answer.)