BROADCASTS.com

b'

In this episode, Dave and Jamison answer these questions:

\\n
1. \\n

   Listener Casey asks,

   \\n\\n

   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 \\u201cmy team\\u201d 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\\u2019t 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\\u2019t take on the anxiety of growing pains?

   \\n\\n

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

   \\n
\\n
2. \\n

   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.)

   \\n
\\n