Business-ese 101

im_briefcase
 

This part of my site is a work in progress, but it occurred to me today to start this up...

Engineers and scientists who eventually go to work for many businesses in the US might be surprised to find out that while they were learning circuit theory, thermodynamics, programming, and English a whole lot of other people were learning an alternative dialect of the English language: Business-ese. This ongoing work will be an effort to help anyone who is trained to actually solve problems in their needs to communicate with people who—at first—seem to be determined to prevent the solution of those problems.

As of right now, I haven't done sufficient research into the subject to pose a qualified theory on the early development of this dialect. However, philologists over the next few decades will, no doubt, be working to sort out the implications this dialect has on the professional world. I truly believe effective and direct communication is key to succeeding in any profession. Therefore, I believe that obstacles to effective communication only serve to slow down progress and degrade the quality of final solutions/products/services.

Here is a very short, introductory reference of a few common terms you will encounter when entering the professional world.

Best Practice


This is a very overused term, so the precise definition (like a lot of Business-ese) can be vague and vary upon context.

Most of the time, it means "planned mediocrity."

Scott Adams illustrates this concept well in a Dilbert comic strip:
http://www.dilbert.com/strips/comic/2008-09-03/

There are certainly other uses for this phrase. You'll also encounter this phrase used when a business person or a sales person needs to express their opinion without it sounding like an opinion. Utterance of "best practices" implies there is a chain of empirical evidence and case studies to support their opinion. More often than not, this is not the case.

Reinventing the Wheel


As an engineer, I was initially compelled by this statement. I assigned a lot of effort and energy to find areas where I was reinventing the wheel. After a little while, though, I realized that no one has ever designed and implemented a wheel like mine. I'm not suggesting that every problem deserves its own, custom wheel. I am suggesting that there are plenty of problems out there where the existing wheels are just plain terrible. Examples of solutions that reinvented the wheel:

- Google search engine, online maps, email
- Youtube web video
- Intel microprocessors and architectures
- Sun Microsystems operating systems, virtual run-time environments, desktop software
- Apple/Mac portable media players, operating systems

In all cases, there were existing wheels that served the purposes of their respective industries. These guys made better wheels.

I believe a lot of the motivation for usage of this term stems from the fact that accountants can't always quantify a better wheel in a spreadsheet. This is one of the biggest challenges in engineering: producing a number (preferably in units of dollars-per-year) that is a difference between the current, awful wheels and your new, awesome wheel. You'll still find many cases where a more efficient, cleaner-running, faster wheel can't return a profit inside 6 months. In which case, business people will avoid installing your wheel because their bonus check might not be as big the first few months.

Turnkey


Where MBAs are in abundance, this word always has a positive connotation. It hints at the possibility of "instant money for no work."

Ideally, a turnkey solution happens where a problem is common, and all the solutions look nearly identical, so someone gets the idea to build a business model around solving the same problem repeatedly. The reason one would buy a turnkey solution is that no one else in your sector/market has already purchased it.

In the engineering world, however, "turnkey" translates into "deferred installation procedure." Instead of asking your technical employees to install and configure a solution for your needs, you pay an outside company to do it, then ask your technical employees import all of your information or get it to work with your existing infrastructure. In reality, the costs of a turnkey solution are equal to or double that of a custom, in-house solution.

Vendor


There are two ways of looking at a vendor.

The first is someone from which you acquire a solution to a problem you can't solve yourself, and don't want the hassle of learning how to solve that problem yourself. This is common, and often a very smart alternative to investing into solving the problem yourself. Depending on the scale and the vendor, this may save the company millions and provide a higher-quality product than you could achieve on your own.

There is, however, a Business-ese connotation. For more rare problems, a vendor is typically a way to prevent hiring and paying your own employees, and, instead, paying someone else's employees who may or may not have far less experience than your own employees. You might also be surprised to discover that, often, these vendors are either your competition, or owned by your competition. Making your competition more profitable, and allowing them to hire more valuable employees while you cut back on the number of valuable employees you employ is clearly a business strategy taught to many successful business managers.

More terms will be added as they irritate me...





Comments

There are currently no comments.

Email Address
It will not be displayed, but is required.
Name
Shown next to your comment.
Comment
Enter the characters shown.

Posted: January 12, 2010   Last Modified: January 13, 2010