For the past decade of my career, I have sat in on more than my fair share of vendor evaluations. I recall during one of these evaluations something didn’t look right to me. I asked the presenter to repeat part of the demo with slightly different input. This uncovered the fact that he had been using a cleverly scripted slideshow. The product was not as far along as the vendor had represented. This changed the entire tone for the rest of the time with that vendor. My role in these demos has long been to provide technical input and architecture governance. I am not typically the one making the decision. I help uncover information that enables decision makers to make a better-informed choice.
A governance function can identify potential problems at almost any point in a project. However, the ability to influence decisions changes considerably as the project progresses. At the beginning of a project changing direction may only take a conversation. After months of development the same shift may require rework, create delays, or even force compromise that isn’t ideal. When governance arrives that late, it is no longer governing the decision, it is governing the consequences.
Governance creates value when it can still influence the decision. When it gets involved too early or too late, teams stop seeing it as a source of useful input and start seeing it as another gate to get through. The latter is how I viewed governance as a lead developer. That view was formed when the organization introduced a new governance function shortly before I was to deploy a small change. I believed that it was a low-risk change and the reviews would unnecessarily delay the launch. Cybersecurity found a couple of small vulnerabilities that we had to fix. Architecture tried to block the deployment because they started pushing for a new service-oriented architecture pattern which was never communicated with the team.
The reaction from the department was predictable and admittedly a bit juvenile. We started asking for reviews on every trivial change. We’d frequently ignore their findings. And of course, we’d push to production without waiting for the reviews to complete. The governance function became something that the development teams worked around rather than something that we wanted involved in the work.
The result is a reinforcing loop. The governance functions discover issues late, creating rework or simply uncovering operational risks. This causes the organization to add more controls to try to prevent it. Those controls create friction and delays for the development teams. The dev teams look for more ways to avoid governance, which leads to more late discoveries… Voluntary engagement keeps becoming less and less attractive. What I have seen happen is the project ends with some heavy governance gates just before production.
That makes me question if that is where governance creates value. Governance should scale with the value at risk. A decision carrying substantial consequences may warrant governance when there is still time to act on the findings. The right mechanisms will vary by organization. Decision rights may be different. The amount of judgment required will likely be different.
When your governance function finds something, how much is it going to cost to change the decision?