Skip to main content

Don't Push the Fish!

Yes, I realize that's probably the strangest title for a business-related blog post that you've ever read (or that I've ever written).  You'll see the relevance by the end of this article - I promise.

During my years as a Computer Science undergrad at Clemson University (go Tigers!), I was taking a class on algorithms when the following statement (paraphrased) was made:  a well-designed algorithm will always trump computing power (assuming, of course, there isn't a huge difference between the CPU speed on the former versus the latter).  This means that you could have a slower CPU but with a better algorithm it would always outperform the faster CPU when various benchmarks were run on both processors.  In business, a similar concept exists:  you can have the best technology, but it's the company with the best "everything else" that will always win.

What is the "everything else," you ask?  Taking a page from the Organizational Change Management (OCM) playbook, we see that there are typically five stages to any company that's doing well, listed in order of execution.

Strategy.  This defines the overall corporate goals.  This is not a mission statement, which I've always found useless since they are often filled with "feel good" terms that really have no real weight behind them.  And it isn't filled with unqualified statements like "become the leader in our industry" either.  This is one or more quantifiable items that describe the desired end state for the entire company.

Structure.  Based on the strategic goals, the business will have to be structured in such a way that you can focus on those goals with little distraction.  The "one general manager, one toy" rule comes to mind, i.e. be able to be the best at your toy.  Don't lose focus by taking on other responsibilities that have little or no bearing on your toy.

People.  Either hire the best people to lead the business segments or spend the time and money to invest in your top employees so that they are able to do the same.

Process.  How are you going to achieve your segment's goals?  If every segment is a business unto itself, what's the operational model look like?  How are your day-to-day responsibilities being fulfilled?  What about exception handling, i.e. how do you handle out of band events that can have a material impact to your segment's bottom line?

Technology.  Finally, what technical capabilities (note that I did not say "what technology solutions") will you need to achieve your goals?

The pitfall that I've seen several organizations fall into is that they execute the first three in the correct order but the last two will be reversed.  In essence, they buy solutions based on whatever the latest trends are that they find in the trade publications and then they try to reverse engineer their processes around the features and functionality in the solutions that they purchase.  This is wrong, however, because it results in gaps that need to be filled via manually executed processes or other such shenanigans.

As a child, did you ever help your parents do a large jigsaw puzzle (1,000 or more pieces)?  If so, you probably found an interior piece that looked like it fit in a particular spot but it didn't really even though you spent a few minutes trying to close that millimeter gap at the bottom edge.  Your parent eventually had to dissuade you of further attempts before finding the correct piece to place there.  Buying technology without having the process well defined is similar to this.  It looks like it'll work, but there are always gaps that prevent things from executing as smoothly as they should.

Now we come to the title of the blog.  I'm a huge fan of the show Forged in Fire (on the History Channel), which isn't surprising to anyone who knows me since I'm also a huge fan of the fantasy/adventure genre of fiction (Lord of the Rings, Wheel of Time, Riftwar Saga, etc.).  Last year, a new series debuted after this show called Knife or Death, which was a timed "obstacle course" (loosely used term there) where contestants could bring their edged weapon of choice in an attempt to hack-and-slash through a variety of things in the quickest time possible.

At one point in the course they get to "sudden death," which is where they have one attempt to completely cut through 3 items, one at a time.  One of those items is a large fish, hanging from the ceiling via a rope attached to its tail.  The correct way to cut through the fish is to slice through its spine at a slightly downward angle so that the blade prevents the fish from moving away, but invariably 90% of the contestants try to slide through the side of the fish, which only pushes the fish away from the blade.  This is similar to the process-vs-technology point I was making above: you can attempt to figure out the process after you've acquired the technology, but you're simply pushing the fish, i.e. you may make some progress toward your goals but ultimately it's a failing proposition because you aren't approaching the problem correctly.

To put it another way, buying technology first is akin to the tail wagging the dog.  Figure out first what the best method is to reach the end state that you desire and then find the best means to execute afterward.  You may end up buying solutions where you use only 50% of the capabilities, but if that means your business is able to execute like a finely tuned watch then the investment is still worth every penny you spend.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ