I have seen the same story play out several times: the organisation suffers a major incident or security breach, and it is decided that to prevent it happening again, all systems must check a list of boxes that are considered good. A few unlucky employees are then tasked with reaching out to everyone else to ensure that their software adheres to the established dogma. A dead giveaway of checkbox engineering is the dreaded spreadsheet with systems on one axis and desired behaviour on the other.
Teams start receiving questions like “are you multi-region?”, “what’s your service level objective?” and “do you have a technical recovery plan?”. While these questions are no doubt driven by positive intent, my experience is that they rarely lead to improvements in practice. Capable teams will have already considered them, and less capable teams will not magically gain the expertise to address them simply because the organisation demands it. What’s worse: neither side of the conversation is incentivised to make genuine improvements. The person holding the spreadsheet is concerned primarily with getting boxes checked fast, so they can show their manager how much progress is taking place. The team on the receiving end mostly wants the inquisitor off their back so it can resume its planned work. A team without the motivation or expertise to engage can easily implement a half-assed solution that achieves little beyond checking the box.
Checkbox engineering makes suspect assumptions about the problems that systems have. Rather than prescribing a list of solutions, I want to understand what issues occur in practice. Instead of asking “are you multi-region?”, I would ask things like “what failure modes do you frequently suffer?”, “how do you detect user-facing regressions?” and “what is your most precious data, and how do you protect it?”. The answers will be nuanced and complex, and will not lend themselves well to a binary spreadsheet, but they may yield the information necessary to make actual improvements.
Checkbox engineering is harmful both because it encourages the introduction of complexity - like an active-active multi-region setup - that solves problems the system might not have, and because it shifts focus away from the problems that the system does have. There is nothing inherently wrong with the tenets frequently found in these spreadsheets, but teams must be free to adopt or discard them based on a discussion that starts at the problem rather than a decreed solution.