{"id":1739,"date":"2024-02-20T16:14:48","date_gmt":"2024-02-20T16:14:48","guid":{"rendered":"https:\/\/quantiv.com\/?p=1739"},"modified":"2024-02-21T09:32:30","modified_gmt":"2024-02-21T09:32:30","slug":"is-it-time-to-kill-your-operational-darlings","status":"publish","type":"post","link":"https:\/\/quantiv.com\/is-it-time-to-kill-your-operational-darlings\/","title":{"rendered":"Is it time to \u2018kill\u2019 your operational darlings?"},"content":{"rendered":"

<\/div>
<\/div><\/div><\/div><\/div>

\"ChrisChris Conway
\nChief Architect, Quantiv<\/p>\n<\/div>

Last month\u2019s blog about reimagining IT systems<\/a> started out with a slightly different introduction from the version eventually published.<\/p>\n

Instead of focusing on the central point, I got sidetracked by explaining what triggered my idea in the first place (perhaps like I\u2019m doing now with this article).<\/p>\n

This thought process was interesting to me but not central to the topic, as a colleague gently pointed out.<\/p>\n

\u2018Kill\u2019 your darlings<\/h3>\n

But even though I could see the need for the change, I was still slightly disappointed at having to let go of my initial inspiration. When I said this, my colleague mentioned this was an example of the old writer\u2019s adage: \u2018kill your darlings\u2019.<\/p>\n

I\u2019d not heard the description before but once she explained it, the concept seemed all too familiar. In effect, a thing can feel essential because it\u2019s been around forever, but when looked at anew could actually prove to be a barrier to other changes.<\/p>\n

I\u2019ve had experience of this in other areas:<\/p>\n