Losing Agility — Buried treasure

The second example on my mind is a company which tackled an ambitious product, embodying brilliant innovations in how technology can be applied to a business context.

The original development was funded by income from existing products, and involved a large team following a service-oriented team structure. Teams were allowed to develop and deploy their own silos of functionality using the tools and technologies which they wished to employ. Inspiration was, in part, drawn from Spotify’s model of software development.

After several years, a highly ambitious web application was delivered. Many new and interesting technologies were employed behind the scenes, and the user interface had pushed the web platform to the boundaries of which it was capable. Engineers enjoyed working with new and innovative technology stacks, despite the struggles inherent in using emerging tooling.

The product started to sell, and exceeded expectations for revenue generation. However, the business model was incapable of generating the revenue needed to support the original size of team allocated to its development. The elegant service-oriented team model was scaled back, silos of functionality were combined together again as best they could. A small team of engineers was retained to keep the product going.

The original model of service-oriented development, once scaled back, left a legacy of once loosely-coupled, but now tightly-coupled software components, no longer enjoying the benefits of loosely coupled “micro-service” deployment and development, but still paying the overheads of the original architectural boundaries.

Signs of something amazing were easy to find

Truly brilliant ideas at the core of this product got lost in the implementation. Because the product concept was original, some truly innovative engineering was justified in bringing it to market. But a large amount of the structure was either unnecessary, or detrimental to the key business objectives. Critical engineering tasks were neglected as the team lost sight of the overall goal.

Movements such as Lean Development identify problems like this as waste. But in this scenario, the problem was more insidious than just wasted effort. The bigger issue was that key parts of the innovative concept got smothered and were never fully realised.

The agility this company needed was the ability to properly expose their idea to the market place. Because there was no clear technology strategy built into the business model, necessary engineering accumulated unnecessary baggage. This is one of the most basic types of agility —I think of it as the ability of a product to shine.

Shine:

  1. (of the sun or another source of light) give out a bright light.

Business and technology in the software engineering space

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store