I was recently re-reading the seminal FLOW® methodology book by Ted & Andy Kallman and was reminded of one of the most powerful concepts they put forward, that is “The Language of Leadership vs The Language of Management”, and how I’ve seen that disconnect dramatically hinder efforts to implement Enterprise Information over the decades.

FLOW® is aimed at broader enterprise efficiency and profitability and unifies “…Traditional management and Agile methodologies enabling successful results…” [From the back cover of the book].  I had the privilege of working with Ted twenty years ago while some of the early concepts were being formalized and I was astounded at the difference between teams following his guidance and teams trying to barrel forward and produce “brute force” results.

The common ground between Ted and Andy’s approach and my approach centered around establishing clear communications between team members, leadership and the rest of the organization.  My focus was, is, and always will be getting clear, unambiguous, and exhaustive plain business language descriptions for every data element (at the attribute/field level)  that has value to the broader organization because it has been my experience that the lack of these descriptions has been the single biggest hindrance to development projects moving quickly (Agile), while delivering results that have both tactical (project scope) and strategic (enterprise scope) value.  A lengthy discussion of how that manifests itself is beyond the scope of this, but I’ll be happy to go into it later if there is any interest.

This distinction between “tactical value” and “strategic value” is key, for it is at the heart of why “technical debt” accumulates in enterprise data systems as the years and projects pass.  Project teams (software development, software package implementation, etc…) are rarely (approaching “never”) measured against the “quality” to the Enterprise of the data that they capture, manipulate and present.  The priority, invariably, is “Do the screens come up?”, does the application seem to perform the specific functionality that the sponsoring business unit desires?  If so, victory is declared, cake is eaten, awards are handed out, promotions given and everyone moves on.  The problem is that since expanding the discussion of the data elements in the scope of the project that might have a broader usefulness to other business units or even Enterprise-level reusability will take more time and delay the declaration of victory they are enthusiastically resisted by the project teams.  They are operating at the level of “The Language of Management” which is very functionally specific (tactical in scope) to the business unit sponsoring the project.

Fast forward to Executive Leadership wanting to have a “Quote to Cash” dashboard.  Now they are thinking in terms of the “Language of Leadership”.  While the concepts in which they think are broader, they are made up of collections of finer-grained concepts that have all been formalized in un-integrated and typically poorly defined siloed “tactical” implementations.  The process of properly identifying compatible/equivalent finer-grained data elements is excruciatingly slow and error prone.  When external data sources/clients are thrown in as well as external systems needing to be integrated due to acquisition the mountain of technical debt becomes terrifying.

Again, a detailed discussion of the path out of this quagmire is outside the scope of this piece, but at a high-level what must be done is the establishment of a “canonical” business glossary at the Language of Leadership level and then incrementally a “mapping” of those concepts to the underlying physical instantiations/representation (“Language of Management” terms).  This “mapping” and the underlying definitions work that must be done is of immeasurable value to data scientists, business analysts, development teams (new development, new implementations, integrations, etc…), compliance folks and executive leadership. The challenge is that this isn’t some “silver bullet” piece of software that can be bought and turned on.  It takes organizational understanding and executive leadership buy-in and sponsorship to create a culture of shared understanding and strategic priorities versus siloed victories.