Why Platform Teams Should Measure Complexity, Not Just Delivery

[Abhijeet Upadh2]

Most ServiceNow organisations are good at measuring delivery. They track releases completed, stories delivered, projects implemented, and business outcomes achieved. These metrics help demonstrate progress and provide visibility into team performance. However, they only tell part of the story.

What many organisations fail to measure is platform complexity.

Complexity does not appear suddenly. It accumulates gradually through years of delivery decisions. A custom table created to meet a unique requirement, an additional integration added for a specific business unit, or a workflow copied rather than reused may seem reasonable in isolation. Over time, these decisions create layers of dependencies, customisations, and exceptions that make the platform increasingly difficult to manage.

The impact is often felt long after the original project has been completed. Enhancements take longer because teams must understand existing configurations before making changes. Upgrades become more challenging due to custom code and skipped records. Troubleshooting requires specialist knowledge, and onboarding new team members becomes increasingly difficult as platform complexity grows.

This is why platform teams should monitor indicators of complexity alongside traditional delivery metrics. Measures such as customisation levels, number of integrations, duplicate capabilities, skipped upgrade records, and components without clear ownership can provide valuable insight into the long-term health of the platform.

A mature platform strategy focuses not only on how quickly new functionality can be delivered today, but also on how easily the platform can evolve tomorrow. Delivery metrics measure productivity. Complexity metrics measure sustainability.

The most successful ServiceNow platforms understand that both are equally important for long-term success.

[rahulswami]

This really resonates. I have seen the same thing happen many times. Delivery numbers look great in the sprint review. Then two years later, a simple field change takes three days because nobody remembers why five business rules fire on the same table.

I want to add one thing : platform teams do not need to build complexity tracking from scratch. Instance Scan already flags a lot of this, skipped records, deprecated APIs, unused customizations and it only takes minutes to run. Add a periodic check of duplicate tables or workflows against CSDM standards, and you catch most of the drift early.

The harder part is getting these numbers in front of leadership. Delivery gets reported every sprint. Complexity debt usually only comes up once an upgrade runs way over estimate, and by then it is a far more expensive conversation.