How to Set Trends

IT is a very trendy industry. You might say we’re more or less slaves to fashion. The priorities which are set in company boardrooms and technology departments are quite driven by the set of 'must have' capability being hyped at any given time. We’ll forgo discussion as to whether this is a good thing or not for now and focus instead on the act of setting a trend rather than merely following one.

First of all, why would someone want to be a trendsetter in IT; well here are a few potential motivations:

1. Because inventing something is fun, exciting or at the very least represents a break from the typical routine. 
2. Because identifying a trend can result in benefits to the trendsetter. I’ll emphasize “can” here because living on the cutting edge often results in some blood loss. There are risks to being new, different or the first one out of the gate.
3. Because creating your hype is and always has been good business. Not everyone can pull it off, but many of the most successful technology companies were built (at least initially) on hype.

Now, it may sound like I’m trivializing the topic a bit or perhaps implying that there is little substance behind most trends – but I’m not really. There can be a marriage behind trend-setting and true innovation if that’s the way you wish to pursue it. Obviously, some trends involve a much higher investment threshold than others. For example, inventing the next commercial quantum computing platform is going to require a lot of capital up front to pull off. However, there are lot’s opportunities hidden with the mass of existing technologies that remain unexploited as well. For most of us, the easiest path towards that exploitation is through invention of new practices.

Who defines the road ahead?

So what does that mean exactly? Practice, any practice, is the day to day approach that a professional takes to do their job. In Medicine, practice is the application of diagnostic and prognostic algorithms (rulesets and techniques) based upon understanding of a much wider body of knowledge. Individual practice in Medicine can influence the holistic practice of medicine across an entire society (or the world) through the publication of these new techniques and insights. Those new techniques if grouped together can also be viewed as trends. Some examples from Medicine of recent trends include:

• Introduction of Electronic Healthcare Records 
• Reductions in the amount and frequency of antibiotics being prescribed
• Exploitation of genetic markers to predict, diagnose and treat a wide array of illnesses

Notice that in the above examples, two of the three trends listed were in fact technology-focused. This is an important consideration when thinking about becoming a trendsetter – nearly every industry now depends on IT to provide a significant amount of its innovation. This means that IT professionals have the opportunity to set trends not only for their own industry but every other one as well. This is exciting and extremely cool if you think about it. For the first time in perhaps forever – folks who weren't trained in specialized fields are helping to redefine those fields because of the technology being applied. It’s not uncommon for an IT consultant to move across industries from one project to the next – in each one learning the business enough to determine how best emerging technology might improve it.

Maybe the best way to describe how to become a trendsetter is through an example – so I’ll draw upon one from my own experience. In 2007, I was consulting for a firm that specialized in Business Intelligence and Data Warehousing. They asked me to determine if some of their solution offerings might be cobbled together into some sort of unified practice approach. I had worked with them before and seen their solution in action and had worked in that industry space quite a lot as well. So here’s what I did:

1. I identified all of their strengths and characterized them in depth.
2. I assessed the current practice approaches in industry (circa 2007) for BI and DW and identified a list of gaps.
3. I mapped the identified strengths of the company against the industry gaps and as I suspected there were several key areas of alignment. In other words, there were things that the company was doing that wasn't commonplace in industry yet – but really needed. 
4. I took that and expanded upon it; identifying a theme for a practice approach as well as a methodology and also identified areas where some technology gaps still existed (even within the new model). 
5. This then led to a standard solutions architecture and detailed process approach based upon the theme and high level methodology. 
6. I actualized this within the company buy presenting the findings and recommendations – many of which were focused on how to blend the new practice approach within the current business model.
7. I then launched an outreach effort – through existing customers and social media. 

The practice I created for them was coined “Agile BI.” At the time, the reception was mixed. Very few in the industry were viewing Business Intelligence or Data Warehousing as something that could be considered Agile. This was before the explosion of Big Data and NoSQL solutions. The main premise I was promoting though is very close to what the industry is defining as Agile BI now:

• That BI projects can be time-boxed into clearly defined increments (you don’t have to use Scrum per se). The key is that some capability is delivered within each increment. 
• The approach was less product-focused and more capability focused. In other words, in this practice a wider variety of tools and capabilities were considered mainly because of the recognition that most environments have a wide variety of data needs / solutions.  
• That BI and the underlying data structures needed to be engineered for performance from day 1.
• That BI and DW were not IT only efforts but required very close collaboration at all stages with key business stakeholders. 
• That new modeling or architecture techniques were needed (that extended beyond 3NF ERD) to help unify management of diverse data resources. 

I recall presenting this all in Chicago in 2007 at an industry conference and receiving a lot of blank stares. This of course is where the risk comes in; it takes years and some serious marketing to go from a kernel approach to widespread industry adoption. In this particular example – that actually has occurred - ( see The TDWI Agile BI Portal ). The company I introduced the practice to did not have the resources to wholeheartedly pursue the approach and stuck to their old business model and I moved on, but not before posting several presentations online and creating a blog that may have helped contribute to the general mindshare behind the industry premise. Granted – it was an obvious and logical progression that would have likely occurred anyway - but my contributions proved to be a worthwhile exercise none-the-less.  

One of the side benefits though of helping to shape industry-wide expectations of how technology practice ought to look like is that eventually you find yourself in projects that have adopted the trend you helped to set – which in itself is fairly satisfying – especially if you really did help to promote a better way of getting things done instead of just generating more hype.