A big problem I’ve encountered in business is the widening chasm between sales, marketing and IBM-style management folks and the new group of technical experts coming up. I’ve been in rooms where the marketing people have great ideas about a product and the technical people simply cannot understand or comprehend what they are saying or, worse, why it is a good methodology to sell a product. To them, it’s the technical structure of the product, the spreadsheets and data, not the human or “mushy” interaction with the wetware on the other side.

There are times I wonder if part of the reason techies spend so much time on futurism is the hope that by removing the wetware entirely, the system becomes much simpler.

However, it goes the other way around. Techies will describe what they are doing in terms that to them are simple, but to the sales and marketing guys are essentially another language. Many smart sales and management folks will usually retort with “ok, let’s pretend I’m an idiot, please explain this to me in language I understand.” I surprisingly polite, if somewhat demeaning way to ask for clarification. The issue though is when the techie “dumbs it down,” they resort to either simpler technological terminology, defeating the whole point of why the prototype they built is cool, or they change the terminology to a different field that they have less respect for (This is more common than you’d think.)

I confess, I’ve done both of the above. I’ve put on my sales, marketing and management cap and found it excruciatingly difficult to explain to a techie why the direction they are going won’t work. Why to sell the produce we need to do something more palatable, more refined. Why, at the end of the day, we need to have a product that actually works rather than the potential for an awesome product eventually. This is something I want to fix eventually, since if I put on my techie hat, I fall into the same holes as them. (Whoo, that’s cool, do that, don’t worry if it doesn’t work…)

I’ve put on my techie hat, went into a sales meeting and found myself discussing the more complex points of software engineering on a clustered system to an individual who only wanted to know why the algorithms on mutual funds were taking longer to calculate than he wanted.

Yet, ironically I’ve found when I’m not the one communicating, it has put me into an interesting situation. I can read over a paper on advanced clustering algorithms and explain to a manager of a small company why this is useful for their primary software product. I’ve also found myself in a technical development meeting explaining to techies that the sales manager is not demanding an entire rewrite, but simply a new field on a single screen.

So, while this is important and I enjoy playing this role. I realized that this is ironically what immix has become. The internet is full of 100s of APIs and organizations have likely thousands if not millions of different systems that have their own DBs, no APIs, no clean way to link to the old database and combine it with new systems in a clean fashion.

While more standardization of APIs is useful, that doesn’t give many businesses any ROI since they don’t want to throw out all of their existing work.

immix has become for many organizations an interesting middle man. It allows the various systems to communicate to it in their own way, and then through module building communicates what is necessary to other systems (including the nefarious wetware I mentioned above.)

It makes the software and hardware talk together. It creates a social network for humans, hardware and software.

The realization I had is that over the last 5 years we’ve encapsulated in software what I’ve been doing in business for a long time. we’ve built a technical translation system that allows normally incompatible systems to understand what they are doing and make more intelligent solutions, and this is important. The internet is overwhelmed with people talking to the wind, and many of the time with good ideas when you can understand the underlying logic. Adding things to the mix will just make it even more confusing, adding noise and not signal. Not because there isn’t signal, but because the things are all communicating slightly differently.

However, by having a centralizing IoT framework that repolarizes those signals all into the same frame, you can actually start to make sense of it all.

I’ve always felt like a jack of all trades because of my varied knowledge and personally worried that it put me at a disadvantage as I needed to read so much more to get the depth I wanted in all of the fields.

However, now it gives me an advantage because I can talk the various languages needed to build good businesses, and I can see how to build a framework that does the same thing electronically.

Maybe I finally found my niche.

Some translation needed.

KJR