Visual versus Textual Interfaces

We humans are visual animals.  We don't know how to read when we're born, instead we learn by observing others, video, and kids books.  This visual approach has been part of our learning foundation for thousands of years from cavemen to modern day babies.  From drawings on cave walls to comic strips, visualization is the foundation of communication.

Our right brain thinks in pictures, and the left side of the brain thinks in words.  Using words to describe something supposedly stalls the right brain.  This stalling is called Verbal Overshadowing.  Verbal Overshadowing is a belief that memory performance is impaired if a memory is described verbally.  

This phenomenon is believed to hinder, or impair, memory and recognition.  For example, a person would be asked to describe the suspect if they had witnessed a crime.  The witness's ability to describe the suspect would have a difficult time doing so; however, the witness could more easily identify the suspect in a photo or identify them in a crowd.

I've heard people comment on McDonald's registers which have moved to an icon approach and away from text and numbers.  I'm guessing McDonald's figured out that new employees could more easily pick up the checkout flow by using icons (visuals) instead of a text and numeral based checkout register.  This means that no matter what language or education level the employees have, they will be able to easily transition into working the front counter of any McDonald's no matter where in the world they are located. 

Why then, do we see software systems that are text-centric?  Is that less effective?  Would it not be better if we had a visualization focus instead?  This would seem especially effective in time sensitive environments in which seconds and minutes shaved off decision making can save a life.

So, what do you think?

One Piece at a Time

Putting together a system slowly, one piece at a time is never an envious position.  But, just like Johnny Cash sang in his song One Piece at a Time, it is sometimes required.  My reason was due to funding.  A cut in funding was coming, but the customer was also wanting us to migrate their current UNIX / Windows system to that of a SOA-based architecture.  It was a tall order to fill that neither I nor the customer were truly understanding how we were going to do it.

After the normal strategic planning, arguments, and updating of my resume, we were able to identify a way ahead.  The plan was to begin a slow migration of functionality which would likely require a number of years to finalize the migration.  I felt we should begin with the backend, server-side architecture pieces.   Wow, never would I have imagined the fight against an idea.  The problem was that it was not a sexy idea.  My peers and customer wanted something they could touch, something they could brag about, something they could show the user community.  However, just as I stated in a recent blog about the architecture should always be built first, I felt it was important to build the foundation of the new system.  If done correctly, that new system could carry the customer many years into the future.  Inversely, building the things that one can touch first means the architecture is not accounted for in the touchable pieces design.  It is my opinion that will never end well.  Never.

Through a handful of meetings, the customer was finally convinced that the architecture should go first.  They bought into it as my partner and I laid out a bullet proof plan that detailed how we could leverage the architecture being in place first, but also each piece could leverage upon what was already in place.  This is similar to the Lego analogy I used in a previous blog, in that Lego blocks build upon what is already in place allowing one to piece together an infinite amount of objects all without having to completely tear down the object and starting over.

A second piece to me not wanting to build the touchable pieces of the system first was that people are typically resistant to new ideas, new techniques...basically new anything.  I knew introducing a new system which in this case was going to be looked at as a step sideways and not a step forward and would not be as accepted as a slow-roll upgrade.  So, my thought was that we could introduce the new SOA methodology to our user community one piece at a time.  One piece at a time moving the user community and the legacy systems was a good method, and I firmly believe it is applicable across any system migration.  It should neither overwhelm or isolate anyone within the team.  Ideally, one hopes the migration is transparent to users until the system updates get to the point in which the touchable pieces are affected.  I believe we did do that to the best extent possible.

The system migration was not pain free, but it was also not a huge effort.  The initial plan had accounted for everything, and only became better because the "round table" of discussions included everyone from the customer, engineers, developers, testers, trainers, installers, to the user community.  No way could I have planned this out on my own, as it required everyone to get onboard with the idea.

So, what do you think?  Would you do it the same way?

After Action Reviews

Why is it that a simple process of After Action Reviews (AAR) are ignored and considered pointless?  I've been on teams that have performed them and we've always discovered things that went well, outright failures, and items that were not so obvious failures, maybe weaknesses is a better way to state it.  However, I was on one team that did not perform AARs...at all.  When I asked if we could use them when I joined the team, I was told "They don't work, never have and never will."  I was surprised to hear this coming from someone that had been in the industry for so long.

Perhaps people like that manager were doing it wrong, or maybe they were focused on the wrong things.  It's not always about trying to find the failures and weak links.  It is also about finding what worked and trying to make those positive aspects repeatable processes.  This was not a hard thing for me to grasp on to when I became an engineer, as I had spent 14 years in the Navy in which we were always reviewing what happened to find the positives and negatives; this was especially important in the Navy, as people's lives were at stake.  So, you can imagine the look on my face when someone tells me that AARs don't work.  They do, when approached correctly.

It is important to begin the artifact collection from the beginning of the project, otherwise it will be a fruitless effort.  One cannot go on memory when holding the final review.  There must be facts, not guesses.  It must be black and white info, not based on someone's great memory.  To help frame the AARs and the data collection during the project, I suggest using a list similar to one below.

1. What were our actual goals?
2. What actually happened?
3. Why did those things happen in #2?
4. What can we do next time?

Yes, it is a simple list.  It should be simple, so as to not overburden your team with a huge checklist.  This simple list is just enough to capture the issue (good or bad), and then use it to kick off a discussion.  It is important to have a representative from each stakeholder.  This is important since each individual, or groups, cannot see the whole elephant.  They see only their piece of it.  Once the entire group begins to review the AARs, the individual entities may realize where the failure actually occurred and it may be in an area that had not been considered the culprit.  Only the entire team can touch the entire elephant.  Sure, there will be give and take on the real problem, but there should be a cooperative environment since from the onset you established that the meeting requires no finger-pointing.  Right?

One last step which I guess would be called the Final Action Review is to compare completed projects and the associated AAR analysis to other projects within the same organization.  The objective of this review is to find the best of breed processes so they can be possibly be replicated across all teams.  This also applies to the negative aspects, as there may be a cultural problem that needs to be addressed such as poor integration testing or poor requirements development.

There are enough examples of After Action Reviews being successful, that it is ridiculous for anyone to believe "They don't work, never have and never will".  That's thinking like a dinosaur and one can only hope that the thinking will eventually go the way of the dinosaur.  We can always find things that we can do better, but one must have an open mind and acknowledge there are better ways to perform.  The only way to find those better methods is to be willing to honestly and completely review how one is currently doing business.  It is a simple thing to do that takes a good amount of effort to get better.

So, what do you think?

Open minds and success

How successful do you think Henry Ford would have been if he would not had an open mind?  What about Albert Einstein or Thomas Edison?  Just as tenacity and a willingness to fail, one must also have an open mind.  It seems one must have an open mind before they could even begin to embark on a journey to solve a problem, but that's usually not the case, as a lot of people will have a preconceived notion...an answer to the question even before exploring possibilities.

In recent blog updates, I've posted about the HiPPO in the Middle of the Room, The Problem with Why, and most recently The Art of the Possible.  It dawned on me last night that I see an obvious connection between those three postings.  I'm sure you've guessed already that the connection is an open mind.  I'm also sure my blog title gave it away.  I wonder how many teams don't realize that they have already arrived at an answer when presented with a new system challenge, as the customer may have led them down that path by asking leading questions or presenting leading notions.

If I was to create a list of do's and don'ts to ensure one keeps an open mind, it would look like this -

Don't have any expectations.

Don't allow leading questions from you or the customer.

Don't ever come to a conclusion based on initial thoughts.

Don't listen to just one person (read my HiPPO blog).

Do remove any preconceived thoughts.

Do collect data to support thoughts and decisions.

Do observe.

Do actively listen.

Do listen to more than one person.

Do ask why.

Only then can one begin to grasp what you don't know.  Only then can you help the customer begin to understand what they don't know.  It's the unknown that you don't know about that will ultimately be the most expensive piece of information and it will eventually appear too late or will be discovered by a competitor.  I read recently of people that maintain an anti-library.  They keep a library of books they've never read to remind them that they do not know everything to help them keep an open mind and accepting of new and novel ideas.  I like the idea of an anti-library, but I'm not sure if I can convince my wife of it, so instead I visit our local library to remind that there is quite a bit I do not know.

Just like my five year old son, one must always ask questions.  Always.  Without instructions, he builds lots of things with his Legos and Lincoln Logs; young children can do that because they have no preconceived notions as they are still learning about the world.  The only way to ask questions that are not leading is to keep an open mind.  The uncluttered, open mind can help you deliver better products.

So, what do you think?

The Art of the Possible

Sometime ago I was supporting a program in which one of my responsibilities was helping evaluate Navy SBIR proposals.  For those that don't know, the SBIR program is a Navy initiative called Small Business Innovation Research which allows the Navy, and all of the DoD, to work with small businesses in research and development of very cutting edge technologies at low risk to the government; the Navy does not call this R&D, instead it is called Science and Technology (S&T) .  While low risk to the government, it is a helping hand to small businesses to help them break into the DoD acquisition arena by providing seed money.  It becomes a win win for both sides, as the Navy, with minimal financial risk, fund a small company to develop an idea which in turn helps the small company grow and potentially become successful with the idea using Navy money.

One particular project had us looking for novel storage technology.  A couple of proposals came back with very dense storage discs; think Blu-Ray but much more dense.  Another was suggesting using nanotubes, while another was proposing holographic storage.  I'm only writing about the holographic proposal today.

For some reason, a portion of the evaluation team found the notion of holographic storage as too outlandish...too crazy...just a bunch of smoke and mirrors...not achievable.  However, this was my second year in working with S&T projects, that I knew I had to have an open mind.  I had to think  like a child would when imagining how something could work.  It was not exactly easy to make that transition since as an engineer I had been programmed to think about requirements that were testable...provable.  From day one of joining the program, my S&T customer was always telling me to "Think about the art of the possible".  I had tasted the kool-aid and I liked it.

My customer agreed the holographic proposal was worth pursuing, while a large majority of the team disagreed it was not worth the time.  Just like I wrote in a recent blog, the nay-sayers were unable to ask why, to think differently.  Why wouldn't it work?  There was nothing to back up their negative thoughts.  It was only their inability to think without the constraints of what they already know.  What this team had learned through their life stopped them from seeing the Art of the Possible.  The Art of the Possible mindset helped all of the well-known and not-so-well known inventors throughout history.  These inventors also had to to listen to the non-believers that something was impossible, too outlandish and not achievable.

What happened with the holographic project?  Several months later, the company presented their prototype.  They had grown a crystal in their laboratory and installed it in their computer.  Using mirrors and the crystal, the lead engineer demonstrated saving a GIF file of the CIA logo into the crystal and then he demonstrated displaying the saved logo onto the projection screen.  It was a perfect demonstration of the Art of the Possible.  It was thrilling to see so much progress made in such a short time.  The last I heard was that company and a well-known large corporation were in discussions to establish a partnership to continue to development.  Yep, just a bunch of smoke and mirrors.

It's too bad that a great majority of the world never consider the Art of the Possible.  I'm thankful I am not a lemming.  I'm happy I see the imaginations of my children and their interpretations of their drawings and crafts.  Life would be pretty dull if I didn't have an imagination.

So, what do you think?

Your system development goals

What do you want your final system to look like?  How many active users do you anticipate?  How much bandwidth will be needed?  Lot of questions that need to be answered, or at least understand the questions that cannot be answered in the beginning.

One cannot simply begin developing a system without having a system goal in mind.  Well, actually you can, but I'm sure it won't end well.  One cannot achieve a final system without a starting point of a clear vision of the future system.  It almost seems contradictory to consider the end point is actually the first step to success.

The first question one should ask is "What do you envision your system to be?"  You'll likely receive a blank stare in response.  If it is a blank stare, the next thing one must do is to begin asking questions and walking the customer to their requirements.  Their true requirements, not the wish list, but what they really require from the system.  As one of my previous blogs stated (http://j.mp/GKfjAU) one should not enhance a system before the architecture is laid down is a perfect example of the customer and the development team not understanding or knowing the requirements.

Once you and the customer have identified the future system, you begin walking backwards from the there to organize the plans, resources, strategies, test scenarios, etc that will be required to achieve the customer vision.  Sure a person could have a concept for a new game and will likely end up with some sort of system.  However, one that has envisioned the future system will achieve the optimal desired system.  Doing otherwise compromises your success.

Only Yogi Bera could state it so clearly, "You've got to be very careful if you don't know where you're going, because you might not get there."


So, what do you think?

Diffusion of Innovation

The Diffusion of Innovation is a theory that attempts to describe why, how and the rate that something takes hold and spreads through a population.   Malcolm Gladwell's book The Tipping Point spoke to this issue in which "the tipping point is the magic moment when an idea, trend, or social behavior crosses a threshold, tips, and spreads like wildfire".  Everett Rogers's work titled Diffusion of Innovations is the most often work cited when discussing diffusion.  

In Mr. Rogers's Diffusion of Innovations, he states there are five stages for the adoption process - Knowledge, Persuasion, Decision, Implementation, and Confirmation.  He then identifies the Adopter categories - Innovators, Early Adopters, Early Majority, Late Majority, and Laggards.

This graph provides a visual as to how the adopter phases are typically gauged.

The reason I wanted to discuss this today is the fact that these Diffusion of Innovation phases seem to be overlapping more than any other time in history.  Consider the mobile phone industry.  Just 7 years ago, the typical consumer carried a clamshell or candybar style phone.  It didn't matter if it was a low or high end phone, there were only two styles.  The BlackBerry was around, but was considered a business only tool, except for the diehard geeks like me, but that was changing as non-business types were beginning to use the Blackberry.  Enter the iPhone.  The iPhone changed the game completely.

Not only did the iPhone change the industry, it essentially disrupted the industry.  The innovators and early adopters jumped at the chance to use the new phone.  The existing Blackberry folks believed they had the best phone.  However, that left a significant portion of the population in the middle, as they had not tasted the Blackberry or iPhone kool-aid.  This innovative disruption known as the iPhone destroyed the Blackberry's Diffusion of Innovation before it could hit the curve's peak.

But it's not just Apple that is introducing new innovations that's hurting legacy industries, but that company has certainly done its fair share of damage.  We've also witnessed Tivo in the television industry.  Tivo did have a good run, and will likely be around a little while longer (especially if the company is successful in partnering with a media distribution company like Comcast or Verizon), but we're now witnessing that company taking a backseat to NetFlix, Roku, and a little company called Apple (Apple TV).  There are other examples, such as tablets and eReaders, or the early portable digital music players and now cloud-based music such as Spotify and Pandora.

If you consider Mr. Rogers's work which for a long was appropriate as the innovative technology had not attained the speeds in which we are witnessing today.  Now, it seems the Diffusion of Innovation bell curve is becoming an antiquity, or maybe less of a measuring mechanism?  At the rate technology trends are evolving, one can imagine that what is taking hold today will live a short life due to the fact that there's team working somewhere to replace a just introduced widget.

We are not yet living in the age of the Jetsons, but it certainly doesn't feel like it is too far away from us now...

So, what do you think?

The social media help line

What I'm learning is that very few companies are using social media to engage customers as social media was meant to be. There are far too many that have taken their toll free hotline approach and are trying to force it to work on social media.  It is unbelievable that so many just don't get it.  It is quite shameful to witness this in a world so technology driven.

How many corporate social media accounts for one company is too many?  Bank of America has six different Twitter accounts.  It makes sense to them, but does it makes sense to the customers?  Which one am I to use? I don't want to think about which ones I have to contact.  I just want an answer.

Why not only one account that filters the incoming content to the appropriate team?  It's really not difficult.  Set up a single account such as @NoFunRich (my future company which ensures there's no fun for you...similar to Seinfeld's Soup Nazi), and then create standing searches for keywords and hashtags.

Social media should not replicate the toll free hotline mentality!  It is not a replacement, it is a customer engagement platform.

Today, I solved this problem...tomorrow I solve...?

Future Proof Systems: The big fat lie

Instead of chasing the albatross of a system that is Future Proof, one should instead have the goal that their system be Future Ready.  Future Proof is a lie.  For a very long time, I even believed it to be THE desired goal.

Future Proof is simply not sustainable in the world we live in today.  Technology is evolving too fast.  One can no longer continue to believe any vendor that tells you they have a plan to future proof your company. Unless, of course, future proofing is to only fix bugs; if it is, then you are most certainly future proof!

One should believe in the fact that change is inevitable.  Having the mindset of delivering a system that is future ready is the golden egg for today, tomorrow, and the future.  A Future ready system is extendable, resilient...change ready.

The chart below shows four reasons why change is inevitable.

Today, and into the future, customers, consumers and employees are demanding more of our technology.  Developing a future ready system will help you keep up with the changing requirements of that audience.

Empowered Health

We are seeing a greater discussion of eHealth and mHealth in the medical and technology fields, and these are the items I believe should be the goal of enabling one to not only receive better care, but to help patients and medical teams better understand what is happening in the patient's world.  I realize this may be a naive view of the world, but I believe these are the requirements that must be satisfied to enable the marriage of technology and medical information.  I imagine I could replace Empowered Health with Empowered Patient in the diagram center...

Empowered Health

The Boy Scout motto

Great speakers aren't made, they're born.  They have that magic touch to be able spin a yarn about anything and everything.  Now imagine that mastery matched up with a person who has to give a handful of presentations a couple times a month.  Yes, the skill is honed to a sharp edge like a very sharp knife.

A person like this can craft a story...shape a story so that it brings the audience in.  It makes them feel like they are part of the story.  If this person kicks it just right, the rest of the presentation is cake since the audience has already made a connection with him.  For example, watch this great speech - Jim Belushi's in Animal House.  Who wouldn't want to follow him?  (caution some language is NSFW)

Now imagine attending a conference with an audience of about three hundred.  The speaker walks on stage, introduces himself...background, where he's from...blah blah blah.  The audience has heard it all day.  Wait!  Why is he taking off his shirt?  Oh, that would be so he could put his Boy Scout shirt on...

He then raises his right hand and asks everyone to stand and to repeat after him.  The audience follows his lead.  Everyone actually stands and repeats everything he says which is a bastardized version of the Boy Scout motto in which the audience was promising not to report him to his boss about this stunt.  Yes, it was corny.  But he had everyone's attention for his entire presentation.  He grabbed them from the beginning and every word he spoke was heard by everyone in the audience because nobody wanted to miss the show.  One can only hope to witness a master demonstrate his skill, and a lot of us witnessed it that day. 

This episode was important to me, as we were in a time of budget cuts and his skill of storytelling kept the budget reduction wolves at bay so I could keep the team moving.  Behind every great development team is someone telling the story, evangelizing to keep the money flowing.

When should a new system be enhanced?

You don't drive a car before it's completely built?  You also don't live in a house until it's completely built.  So, why then, are products pushed out the door so quickly before they're ready for prime time?  I'm this is what leads to a lot of software bugs and customer frustration.  

It's funny, actually its sad, how once a software delivery date has been set on a calendar becomes an unmovable mountain.  What once started as an arbitrary planning date becomes the unmovable milestone...as unmovable as the Democrats and Republicans with their political views.  Time and again, one can observe that product in development is already being enhanced.  Huh?  You want to enhance version 1.0 before it has been released?  Really?  Just like roofing a house before the foundation is completed, one should not be enhancing software before the framework is completed.

Architecture first.

Typically, in a thinking organization, one would see the development plan go something like:

Plan - establish the need,

Define - design the approach,

Enable - put the it into action,

Measure - monitor and manage the progress.

Ideally, one should focus on the underlying architecture before introducing new functionality.  There are many features and functionality that can come later, but they will not be as fruitful if the keystone work is not completed before hand.  Introducing new and/or modified functionality while establishing the architecture will more than likely cause unnecessary re-work.  Getting the architecture right should be the only priority to ensure success; the rest can come later once the architecture has proven itself to be robust, resilient, and extensible. 

Many initiatives have failed because of the lack of strong architecture management throughout the development life cycle.  Organizations must promote development and management environments, which provide governing mechanisms to ride herd on bad ideas like introducing early enhancements.

Where's the problem - users, training, design?

I took my 5 year old son to a birthday party this past weekend.  The birthday boy's dad is a policeman and he told me about a new software system that his department was using.  Lots of unhappy users and no time for training.

The necessary training was estimated to be around two weeks, yet the patrolmen were receiving less than forty hours.  The associated document was described as a training manual, but it was really a combination of a training manual and a help manual.  It is 500 pages.  500 pages is not providing help or training.  Imagine being handed new software and the 500 page training manual at the same time.  I would immediately think OH CRAP, and a mental hurdle would be placed in my way of being open minded to the new software.

In further discussions, I learned that the document also contained instructions for other divisions such as animal control, as well as every form the patrolman were required to fill out even if it was not part of the new software.  There is always a mountain to overcome when introducing new software to your community, so I'm confused as to why anyone would believe a 500 page document would not be seen as overwhelming and how that sentiment would spill over into the software as well.  Instead, I would have broken up the manual into bite size chunks for each division, and I would have separated the training section and made it a standalone document.  Secondly, I would have not allowed the non-related forms to be included in the document.  It just seems crazy that someone thought that was good idea.

Now reconsider my thoughts above, the introduction of new software, the training timeline, and the two sets of documents that should have been delivered instead of one.  One can probably guess that the required two weeks training will be drastically cut.  Its normal that a percentage of the unhappy users will still remain a part of the community; however, that number will drop significantly as the perception of the software being difficult to learn and use will be in direct correlation to the training and help manuals not appearing to be as large as Tolstoy's epic novel War and Peace.

New product introductions require as much thought, if not more, on the tail end of the product as it does in the design and development.  Unfortunately, we see many examples of what could be a good user experience turn into a nightmare since no one considered the end user during the design and development.

Software development and the New Guy

The best time to receive the best input from new employees is in the first sixty days of their joining your team.  They have a clear view of everything from processes to communications, as they have not yet been tainted by the culture and office politics.  Smart companies seek out the new employee's opinions before they adopt new habits inherited from their new teammates.  Why then are new users ignored during software design and development?  Could be a number of reason such as the organization's HiPPO that I wrote about in my blog recently (you can read the HiPPO blog entry here) or could it be a lack of respect for the new employee's view since they've "not paid their dues".

Certainly, one should not ignore those members that have been there since the beginning, but one should also not ignore the newest members.  The new teammate bring a fresh perspective. Their perspective has not been muddied by past decisions.  They can still ask Why, which was another topic I touched on recently (you can read the blog entry about Why here).  They can poke and prod because they don't know what they don't know.  Not knowing is a great thing, because it allows one to ask what some would perceive the question to be so obvious it shouldn't be asked.

Consider the Orville and Wilbur Wright story.  They were bicycle guys without the hallowed degree.  They didn't know what they didn't know which allowed them to ask dumb questions, make bad assumptions, and do things wrong.  On the the other hand, Samuel P. Langley did understand the technology.  He successfully flew powered model planes between 1896 and 1903, but he was never able to successfully do what the Wright brothers did.  Langley was successful in receiving financial backing to support his endeavor, as he was perceived to be a knowledgeable person in aeronautics.  The Wright brothers received no backing, as they were bicycle repair shop owners.  History shows it was the guys that could ask the dumb questions and make bad assumptions that were the first to flight.

The next time you're asked a question, listen with an open mind.  You may learn something you had never considered.

The rule of Five Percent

There have been times I've been left confused as to why an idea I had presented didn't receive the standing ovation I thought it deserved.  Why has there been push back on ideas I've presented that I thought would be crystal clear to everyone in the audience, but the idea fell short.  This let-down hasn't always occurred, as I have been mostly successful in my career so far; it's just those ideas that are considered "bleeding edge" that have been the most problematic.  Could it be I didn't get enough buy-in on the idea before discussing with a larger group?

This morning, after my meditation time, I was reading Nick Bilton's book "I live in the future & here's how it works".  In the chapter "Suggestions and Swarms", he describes an experiment focused on "swarm logic".  In that chapter, he provides details about a social experiment in Germany in which 200 volunteers were directed to not talk to each other and to move in any direction with the conference hall without bumping into each other and that they must all remain within an arms length of those around them.  The first round showed that the 200 individuals organized into two different circles; this happened in follow on tests, too.  However, in later tests, the scientist instructed random individuals to walk to specific locations; numerous folks were told to do the same thing without knowing others had received the same directions.  These individuals did not impact the larger groups until the assigned "leaders" had reached 5% of the 200 test subjects.  At 5%, the entire 200 all moved in the same directions.  The scientist learned that any number above 5% could control a crowd.

This certainly applies to introducing new ideas to a customer or one's team.  Presenting an idea no one has heard of is probably always going to end bad, unless of course you own the company.  While Bilton's thoughts were focused only on individual and group online experiences, his thoughts directly convey to adopting and developing a new idea.

I presented an aggressive technology road map several years ago that was well received, yet a very small percentage of the ideas were added to the technology roadmap.  My assumption, as always, was that I was dealing with luddites who did not understand what these ideas could do for them.  Today, in hindsight and my 20/20 vision, I believe it is because I did not socialize the idea to a larger percentage of the group.  Instead, I kept the tweaks and drafts to my inner circle.  I believe I may have been more successful in achieving the functional goals I presented had I chatted up the ideas with more people.

Another life lesson for me to carry forward.

My InfoNet

Without mentioning the book I was reading, my father told me of a story which had recently spread on FaceBook about a friend had been taken to the hospital because she had had a heart attack.  The story ended up not being true, it was really bad indigestion from really Good Mexican food.  My dad went on to tell me that the husband was receiving phone calls from concerned family and friends even before they had arrived at the hospital.  All of this happened in less than an hour due to one person posting "please pray" on FaceBook.

Today, News travels fast.  News is instantaneous.  News is immediate.  Why?  How?  Social media networks, my friend.  In the past year, I've learned of Osama bin Laden's killing, the attack by allied forces on Libya, Steve Job's passing, the recent tornadoes in the mid-western United States all via social networks.  My Information Network (InfoNet) passed these news stories to me well before the major networks reported the events.  I no longer watch the news, as I get all of the news I need from My InfoNet via my Android phone.

Just as Nick Bilton wrote in his book "I Live in the future & here's how it works", I trust my InfoNet.  I trust it because it has been consistently correct and lightning fast.  Both of those attributes are all that matter to me and my generation.  I do not need to hear my news from a talking head that receives an annual salary of millions of dollars simply reading the news to me.  I do not need a five minute excerpt read to me, or that news organization's edited video.  I can use YouTube if I'm interested in a video clip and it will be what I want to see not what someone thinks I need to see.  I want my news quickly and correct, nothing more.

You will notice earlier in this blog that I struck media from "Social media network".  It has occurred to me that the media is not in the center of my social network, hence my use of InfoNet.  Certainly, the news and entertainment media are in my circle, but they no longer influence my news or my entertainment.  This is my InfoNet, and one is allowed in only by invitation.  Please step behind the velvet rope as I decide your worthiness.

The rise of a Nation, aka The Social Media Baseball Bat

Social media has brought back a small town feel to the world, but the large corporations, politicians, and old media companies haven't figured that out.  Social media is exactly like the small town I grew up in Texas.  Everyone seemed to know when I did something wrong - skip school or speed in my car.  Whatever it was, my family knew before I got home.  What we are living in today is no different, as everyone is connected and transgressions are easily seen and blasted back out to the rest of the world as quickly as the family and friends network in my hometown of Detroit, TX.

Bank of America...

Susan G Komen fund...

FaceBook...

Politicians...

Verizon...

and the latest is Rush Limbaugh...

It still amazes me to see companies and individuals so badly flub.  Gone are the days that a company or individual can change a policy or strategy, or say or do something ridiculous without incurring the wrath of the public - their customers and supporters.  The speed in which a revolt can develop is mind boggling, yet we continue to see it happen.

Everyone (individuals and corporations) are products of their information source, yet we continue to witness that the source is so wrong.  Not just wrong in a sort of gray area, but just wrong.  The thing is that these so-called wrongdoers probably have a good idea as to why they plan to make a change or state something that may not be in agreement with everyone.  But why do they bungle it so badly in the delivery?  It is my belief that they are ignorant in their understanding of the societies they live in.  They lack empathy or, perhaps more disturbingly, they ignore that empathetic signal in their brain telling them to rethink their approach and delivery.  

One must be aware that today a mistake will be uncovered before the mistake has even lived a few moments.  The spotlight's quickness is due to social media and ability of individuals and groups to rally support against a wrong - be it perceived or correct.  We've seen Bank of America, Verizon, and the Susan G Komen group back peddle very quickly when a new pricing scheme or funding decisions come to light.  Could be there was justification, but their delivery made them look foolish when they retracted their decision.

Maybe it is time for those entities listed at the beginning of my blog and many more I've left off this list to attend a mandatory Social Media 101 class.  Social media presence means more than just having a presence, it also means being responsive, and just as importantly, responsible.  Responsible behavior and decisions will be covered in lesson one and on the final test.

The similarities between 1920's radio & today's social media

Although radio had been around since the early 1900s, it was not until the 1920s that radio became a prominent media within the United States.  In 1920, there were only thirty broadcasting licenses issued but in 1923 nearly six hundred were issued.  Except for a couple of large radio stations, these radio stations from 1920 to 1925 were mostly run by individuals, colleges, and non-profits.  Their listening audience will have been very small, as the broadcast strength was a fraction of what we experience today.

Eventually, radio stations numbers reached the thousands, but the broadcast times were inconsistent and the topics were unique.  For example, some stations only broadcast for two hours one a week, and played the same music every time.  Others were better funded and played a larger variety.  Essentially, the programming was what the owner thought (guessed?) thought people wanted to hear.  The positive side to this experimentation and guessing is that there was a variety one could listen to if within range of different stations.  Just as important during this time, is that 60% of American households owned a radio in the mid to late 1920s.  We know large businesses saw radio as an opportunity and began taking control of the radio waves and pushing the individuals and smaller companies out of the larger markets, and eventually took over a large majority of the radio waves.  

Now, fast forward to 2012.  Despite social media outlets such as FaceBook and Twitter having been around for more than a few years, we are beginning to see more corporations attempting to profit from this latest evolution of the interwebz.  Social media and the 1920's radio boom are very similar.  Today, just as in the 1920s, the new medium is adopted by the tinkerers and visionaries, in other words the early adopters. It that group that has always paved the way with new technologies which eventually becomes beneficial to the larger group.  It is being repeated today with social media.  The early adopters and inventors began playing with the notion of a social web and little sites like FaceBook popped up in 2004 and Twitter in 2006, yet it wasn't until recently that businesses began using this "new" medium as a means to grow their customer base.

The difference this time is that large corporations cannot squeeze out the smaller companies or the enthusiasts and non-profits.  The other difference is the enthusiasts like Mark Zuckerberg were able to capture a large share of the market because a large portion of corporate America is still operated by a generation that still doesn't quite understand the power of the internet.  The Zuckerbergs and Biz Stones of the new generation do understand - build your audience at the social level with an engaging medium, and then build your business around it.  The takeovers of any medium as demonstrated by AT&T in the early days of radio broadcasting will likely never happen again as the internet has leveled the playing field in how ideas can move rapidly from idea to creation to implementation in a flash.

This really is one of the greatest times in our history to be alive.

It has always been about the data

In an interview years ago, I was asked to describe SOA as if I was talking with a non-technical customer.  My response was, "It's about the data.  If we can get the data right, in the right place, then we are nearly there."  Yes, it was simplifying a big challenge, but I did not then, and do not now, believe I oversimplified the SOA challenge.

What's interesting is that the answer to any business question such as the one I was asked is that it has always been about the data.

Big data is about the data...

Data analytics is about the data...

Everything we're doing is usually about the data - SEO, mapping, databases, geospatial, photogrammetry, semantics, and metrics (yes, even including social metrics) are all about the data.  So, then, why is it there is a belief that Big data and data analytics are the new buzzwords?  One could argue that successful businesses such as Amazon have been focused on data for years.  Otherwise, the personalized landing page would be blank when arriving at the website.

There was a recent article describing the retail chain Target and how it could very accurately predict which of its female customers were pregnant based on their shopping habits.  That should not have been a surprise for anyone, as this kind of data-mining has been persistent in the retail markets for years.  Another example, Wal-Mart, using data analyses, discovered that the breakfast pastry Pop Tarts was selling out when hurricanes were predicted; Pop Tarts were favored because they are easy to eat and can be stored for long periods of time.  Because of this insight, Wal-Mart now begins stocking up on that item when a hurricane is threatening a region.  Data and analyses helped keep customers in their store.

Certainly the technology that can extract information from the data is getting much better.  Technology such as Hadoop, and IBM's Watson are making headway to allow almost real time information extraction.  And, yes, that may be what is driving the fervor around data, big data, and data analytics.  However, as my previous paragraph touched on, any business that is successful already understands customer data and habits.  Why else would sodas and candy be in the checkout line?  The big not-so-secret data about the lowly customer is that a large percentage of us will buy something on impulse.  BAM, data got you again.

I've preached for years to my customers that one must focus on data before anything else, otherwise they end up paying their developer far more later to fix the mistake of ignoring the data.  The best analogy for me is that one does not build a house without a good, solid foundation.  Data is the foundation for rock-solid architecture and should not ever play second in design ideas.

What are your thoughts?  Have you encountered systems in which there was a mentality of build first, and worry about the data later?  How'd that work out for you?  Let me know using the comments section below.