Letting Go Of The Past

A president of a technology organization has been very successful in satisfying a rather narrow vertical in a niche market. Under his guidance, a custom-crafted data warehouse and reporting engine developed over three years has been successfully deployed to his highest profile clients. This reporting engine was the result of a decade of this president's experience and development in this vertical.

The president, seizing on a new but potentially lucrative revenue stream, now wants to apply this data warehouse and reporting engine to a new domain, but one using a new report query methodology with frequent use of highly cross-tabulated data. The president brings in an experienced professional outside the technology team to lead the construction of software to support this new report query methodology.

After a review of the problem domain and the current data warehouse architecture, the team lead demonstrates that the current architecture will not store the data effectively, or quickly execute the queries in the new lucrative domain. The new team lead reports on the expected size and structure of data, and a potential architecture to support storing and executing the new report queries.

The president, disturbed by the team lead's negativity towards the older engine and data model, declares that this is not what he wants. The president tells the team lead to take the current engine and "fix it, make it better, but we can't redo it otherwise we're deviating from our platform. I don't want two platforms. We spent three years building this platform and we must use it."

The team lead, seeing the incompatibility of the current data model, asserts that a new data model and reporting query engine would need to be constructed, and that a new architecture could be backwards-compatible with the reporting queries from the president's current niche market. The team lead provides a working engine and database to demonstrate the new architecture's viability, integration with features of the current platform, and ease of construction to satisfy this new domain.

The president, after conferring with the older members of the team, is more disappointed than ever. But the other members do not have a strong alternative to the new team lead's solution. Not being technical but always willing to contribute technically, the president makes a few technical short-cut style suggestions. One suggestion is plausible to the new team lead, but the others have no connection to the new reporting query engine requirements.

A few of the technical team members take a look at the team lead's work and begin to agree with the team lead. But the president still does not come to an agreement with the team lead's assessment. Soon after, the team lead is off the project, while the president continues to search for a solution.

Should the president expect a custom data warehouse that took three years to construct, and that was fully paid for by the company, to be usable towards every revenue stream the president wishes to tap? Or does the president need to let this go and move forward?

Should the team lead reference the technical knowledge and experience accrued over time to make an assessment? Or, because of the new domain, should the team lead let this go and move forward?

Who is right in this situation? The president? The team lead? Keep in mind that what is most wrong with this situation is that the lucrative revenue stream remains untapped.

It can be difficult for us to let go of our past ideas and our creations in order to move forward, but in some cases this is actually what is needed to make the best of our present state and lead us to our future successes. If faced with a similar decision, do you think you could let go?