If your ARB consistently rejects or significantly changes proposals, does that mean the board is doing its job protecting the organization—or does it reveal that your engineering teams fundamentally don't understand or trust your architecture principles, suggesting the real problem is upstream in how you communicate and embed standards?
Great question, and I completely agree with the spirit of it. If an ARB is consistently rejecting or heavily reworking proposals, that’s a signal, but the meaning of that signal depends on what happens next.
If the board is truly catching risky designs and preventing real problems, then it’s doing its job. But if the same types of issues keep coming up, that’s not just “protection”, it’s a sign that something is broken further upstream (or downstream depending on a few things). Either the architecture principles aren’t clear, they’re not embedded in day-to-day engineering, or there’s a disconnect in how standards are communicated and taught.
The real value of an ARB isn’t just in saying “no,” but in turning rejections into lessons learned. If teams walk away understanding how to improve next time, and those lessons are fed back into better documentation, onboarding, or reusable patterns, then the process is working. If not, and the same issues keep cropping up, then the board has become a bottleneck rather than a catalyst for better systems.
On the flip side, if the ARB rarely pushes back, that could mean teams are well-aligned and standards are clear, or it could mean the board is rubber-stamping everything and not adding value. The key is to look for feedback loops: Are we learning from rejections? Are we evolving our standards and communication? If so, everyone gets better over time. If not, it’s time to ask why.
In short: high rejection rates aren’t inherently bad, but they should always lead to a conversation about root causes and continuous improvement, not just more process.
Good points so far, but
If your ARB consistently rejects or significantly changes proposals, does that mean the board is doing its job protecting the organization—or does it reveal that your engineering teams fundamentally don't understand or trust your architecture principles, suggesting the real problem is upstream in how you communicate and embed standards?
Great question, and I completely agree with the spirit of it. If an ARB is consistently rejecting or heavily reworking proposals, that’s a signal, but the meaning of that signal depends on what happens next.
If the board is truly catching risky designs and preventing real problems, then it’s doing its job. But if the same types of issues keep coming up, that’s not just “protection”, it’s a sign that something is broken further upstream (or downstream depending on a few things). Either the architecture principles aren’t clear, they’re not embedded in day-to-day engineering, or there’s a disconnect in how standards are communicated and taught.
The real value of an ARB isn’t just in saying “no,” but in turning rejections into lessons learned. If teams walk away understanding how to improve next time, and those lessons are fed back into better documentation, onboarding, or reusable patterns, then the process is working. If not, and the same issues keep cropping up, then the board has become a bottleneck rather than a catalyst for better systems.
On the flip side, if the ARB rarely pushes back, that could mean teams are well-aligned and standards are clear, or it could mean the board is rubber-stamping everything and not adding value. The key is to look for feedback loops: Are we learning from rejections? Are we evolving our standards and communication? If so, everyone gets better over time. If not, it’s time to ask why.
In short: high rejection rates aren’t inherently bad, but they should always lead to a conversation about root causes and continuous improvement, not just more process.