Beware the Silent T

 Something really strange is happening to the English language in the United States.  I first noticed it a little over a year ago.  At first I thought it was just one person who needed to go back to kindergarten for reprogramming, but now it is widespread.  It is in the news, TV shows, movies, and in daily face-to-face conversations.  I hear it more in the under 40 age group so us older people may be less likely to contract it.  You might be wondering if I'm describing a new virus or food-born illness, but I'm not.  It is even more insidious.

I'm talking about improperly placed silent Ts.  "What is that?" you may ask.  It happens when someone speaks and uses a word with the letter T as the first letter of the second (or sometimes the third or fourth) syllable and does not speak the T.  They just treat the venerable T as if it didn't even exist.

Let me give you a couple of examples so you'll know what to listen for.  We'll use the name of the college I attended since I hear this one all the time here in Omaha.  I went to Creighton University.  People with this affliction do not say the T that is the first letter of the second syllable in Creighton.  In real English, you would pronounce this as "CRAY-tun" (forgive the pronunciation notation if it's not correct, but you get the idea).  When pronounced properly, the second syllable would sound the same as when you say the word "ton."  They pronounce Creighton like "CRAY-un" and the second syllable sounds like the first syllable in the word "underwear."  "CRAY-un."  Like "CRAY-on" with a U instead of the O.

The strange thing is that between the syllables they still insert some kind of hard stop that allows the listener to clearly differentiate the two syllables rather than letting them run together.  "CRAY-un."  I can feel my face turn red with anger every time I hear that one.

The other example is the word "water."  These sick minds make the mouths connected to them say "WAH-urr."  Again, it makes my blood boil (no pun intended).  What was wrong with "WAH-tur?" When I hear one of the local news anchors speaking like this for the entire duration of a 30 minute news show I leave the room, go to my computer, and try to locate a local anger management class that I can immediately attend.

You might be wondering why this bugs me enough to write an entire blog post about it and, to be honest with you, I just don't know but it does.  You can't just change the English language because you're too fucking lazy to use it correctly.  It doesn't mean you're one of the cool kids.  It means you're fucking lazy and you need to repeat elementary school so you can get the basic things right.

Ok, that's enough of that for now.  I'm done ranting, but I'm still mad about the whole situation and if you speak to me like this during a conversation you can be sure I'm not listening to anything you say.  I'll be thinking about the fact that you deserve to have projectile diarrhea until you learn to speak properly again.

On another note, I hope everyone had a great holiday season...

The Mythical "Single Pane of Glass"

Since my very first days in IT almost 35 years ago I've heard people talk about something called "a single pane of glass."  It was said that somewhere an application must exist that would let IT people manage all the components of their hardware, data storage, backups, software deployment, licensing, performance management, capacity planning, and availability monitoring into a single application that an engineer or manager could use to manage the entire IT environment from one place.  Theoretically it would consist of a single screen showing the status of everything IT is responsible for and allow the user to drill down into any of them for more detailed information or to make changes to something without ever leaving the application.

The reason I'm dredging this up again is that I heard it again in our staff meeting last week when our new manager was talking about our team's upcoming initiatives.  This is an interesting concept, but it raises a couple of questions:  1) Does it actually exist, and 2) Should it actually exist?  Let's think about this for a minute.

All of those things listed above are important parts of my world in IT because I deal mostly with hardware and its deployment and operation.  All of those capabilities are available to me, but I have to go to a different application for each one of them.  The goal of "a single pane of glass" would be for me to see and manage all this stuff in one place.  

The Holy Grail would be for all these functions to be integrated and automatic.  For example, a performance management function might detect that a particular application is running slowly and automatically look at disk space consumption and memory/CPU utilization and determine that the performance problem is being caused by the disk containing the operating system being critically low on free space.  It would automatically respond by using its storage function to allocate a little more space to get the system running correctly again and then fire off an email to me advising me of the situation, how it was fixed, and that follow up would be needed to find out why it happened.  That would be pretty cool, especially if it was all done automatically without the need to wake me up at 2:00AM.  Let's pick this situation apart for a second and create a rough design of the "Single Pane of Glass" system.  That's a long name so we'll just call our new system Big Pane.

To get to Holy Grail status, this system would need to detect the problem, gather performance data from all the possible sources of the problem, sift through the data to determine the most likely cause, devise a solution or two, and then implement a possible fix.  We'll throw one more wrench into the works here and say that the system is running on Windows Server, so if storage was added then it would somehow need to notify the Windows operating system that the extra storage  resources were available for it to begin using.  

Detecting the problem would be easy.  We currently have very expensive software that can reach into another software system, perform various functions, measure how long it took, compare it to previous results, and determine if something isn't running as expected.  The challenge here is that software systems are not created equally so you have to check them all in different ways to get the true picture of how they're performing.  We have about 60 of these software systems and each one works only for a single software package.  There is no common denominator determining how performance is measured across all of them.  For this reason our new system would need different testing capabilities for each system.  Just for parity with my company's existing situation, we'll just say it would need 60 different testing functions.  If it actually worked, our management would require that it be expanded to accommodate our other 1440 application systems.

Next it would need to gather some data from all the possible sources of the problem.  Not a really big deal because just about everything has some kind of API (Application Programming Interface) and you can usually query them for the data you want using their API.  The problem is that they are all different so our system would need to know how to understand all of them.

Assuming we've gotten this far, Big Pane would need to determine the actual cause.  AI hasn't come far enough for a software system to think like an engineer with 30 years of experience, so it would most likely need to get this information from a knowledgebase somewhere.  Knowledgebases are not created equal, so you would probably do better creating your own, possibly from problems and solutions  you've seen before firsthand.  The solution could also be included in the knowledgebase so Big Pane wouldn't have to figure it out from scratch every time.  Each system would almost surely need its own knowledgebase entries.

Now that Big Pane knows how to fix the problem, it will have to implement the fix.  These days you can change almost anything in software so our Holy Grail system could make whatever changes are necessary just by going through the API of the problematic system.  Big Pane would need to contact our SAN management module in the SAN Director System and tell it to allocate some more disk to our system.  Luckily almost all of our systems use the same SAN for storage so this wouldn't be too difficult.  You'd just need to tell it what kind of storage is needed, how much you want, and what system it goes to.  

Now, you'd think that was all we needed to do but you'd be wrong.  You see, even the newest operating systems don't automatically recognize all changes, especially hardware changes like added disk space, memory, or CPU.  You have to restart them or notify them somehow that they can begin using these new resources.  The notification process is different for every operating system and sometimes different between different versions of the same operating system.  This part might not be a problem if a system is unusable due to a performance problem and will need to be rebooted anyway, but what about really specialized systems that are just running a little slowly?

One of the systems I support is used during open heart surgery.  A patient is hooked up to a bunch of probes, sensors, and cameras that collect various pieces of data the surgeon uses during procedures and then displays them for him in the operating room.  Some of these sensors are snaked up through an incision in the leg all the way to the heart.  If the system stops working during a procedure then the surgery has to pause until it is restarted.  In that case you have a bunch of doctors standing there as motionless as possible over a patient laying unconscious on the table with his/her heart fully exposed and several wires running through his veins.  You don't want this to happen for obvious reasons.  

The last task for Big Pane would be to send me a politely worded email advising me of the problem and how it was fixed.  This is always done the same way so it would be very easy.

Now that we have an idea of what this would take, imagine implementing it for 1500 different software systems simultaneously.  And imagine what it would take to keep  it up to date with all the regular changes in software, hardware, and configurations for all those applications.  Even with a huge investment in development, you'd end up with something of limited usability and it would never be truly complete.  And remember, the example we've discussed here is just for one scenario on a single system.  Most actual situations are much more complex than this one.

I'm not lazy and I'm not stupid either.  The effort and subsequent cost would be much larger than any reward from doing it could ever be.  The logical alternative to building this behemoth would be to hire a few good engineers and managers and just pay them well to use several different systems and be proactive in their daily work.  This is what we do today.  Now I would ask the second question "Should it exist," but you probably already know the answer to that by now.  Unfortunately, every time an IT executive goes to an industry conference he/she reads about some proposed Holy Grail system in a SkyMall magazine at the airport and we start this quest all over again.  If you're an IT executive and you're reading this, please stop.  SkyMall is not the place where you should get ideas for how you're going to spend your organization's IT budget.

Lean Development Methodology

 If you've decided to read this post then you probably recognize Lean Development Methodology as a development project methodology commonly practiced in IT organizations.  If you already know all about it then you might find this very boring and my feelings won't be hurt if you just skip to another article or go browse Amazon.

Assuming you're mildly interested, I'll tell you what I know about it.  The idea of the Lean Development Methodology is for a team to work feverishly on a project and bring it to market very quickly, often before it's completely finished.  This seems like a no brainer, but there's a little more to it than that.

Lean has a thing called Minimum Viable Product, or MVP.  Basically the idea of an MVP is that the system barely does what it is supposed to do in order to sell it, but not necessarily very well.  The idea if that if a company is producing a software product, then they want to start getting customers to pay for it as soon as possible.  If they can honestly say that it somehow performs the function it was designed for and they can get someone to buy it, then it is an MVP.

An MVP is almost certainly rough around the edges and may have a number of features that are not fully implemented yet.  It may have a ton of menu items that display "Not Yet Implemented" when you select them or maybe the whole system  needs to be restarted every 20 minutes.  It barely performs the function that it is being sold for but very little else.  The idea is that if the company can get customers to pay for it then they can use the money to finance finishing all the other parts that yet don't work and they can solicit feedback from the customers to help determine which features should be developed next.  Also, the theory is that if a customer invests money and time in buying an MVP, then they will be more likely to put up with some amount of deficiency and stick with it in order to protect their investment.

Let's look at an example.  This one doesn't involve developing software, but it illustrates the idea of Lean.  Suppose a company wants to add a rack of new servers to their data center.  There are a lot of things to consider, but let's focus on electrical power here.  A standard data center rack has a capacity of 42U in space for the servers.  This of a "U" as a slot in the rack.  You can fill 42 slots with servers and whatever else you need to put in there, but they all require electrical power and each one will have at least one power plug that needs to be plugged in.  Data center racks have these big surge strip things called Power Distribution Units, or PDUs.  It runs from top to bottom on both sides of the rack and has a bunch of electrical sockets on it.  Most PDUs can actually do much more than that, but we're just concerned about power capacity for this exercise.

Each rack probably has more than one electrical source running to its PDUs and there's a maximum capacity that those circuits will safely support.  Each device you put in the rack uses a chunk of this available capacity and it's really important not to exceed it.  For our example, the Data Center Manager has told us that the power capacity for the rack is 40,000 watts.  

So now we need to figure out how many watts each server consumes to get to how many servers we can safely put in the rack.  Those numbers are readily available from the manufacturers of each piece of equipment.  They are almost always in the products specs on the manufacturer's web site and it takes all of 2 minutes to click around and find them.  This is where we get to the Lean part.

Management, in it's vast collective wisdom, has decided that figuring out the total power requirement and determining how many servers can go in the rack should be a full-blown project rather than a 5 minute task involving adding up the numbers using the calculator built into someone's iPhone.  So next they assign a project manager, a system engineer, and four programmers to accomplish this seemingly monumental task.

After four weeks of meeting diligently on the project to develop a project mission statement, a charter, define deliverables, establish a schedule of status meetings and a reporting hierarchy to keep management informed of the team's progress, the programmers start coding the solution.  Immediately they discover that they have neglected to establish a SharePoint site and Microsoft Teams chat room for the project, so development stops for a couple of weeks and those pressing items are addressed.

The design that the team has chosen consists of a python program that reads an input file containing the wattages of each server, one per line, and adds those amounts together to produce a result.  The result is written as a single line to an output file where the user can go retrieve it.  The input file contains 42 lines, one for each slot in the rack.  If a slot is empty then there must be a zero on the line.  

After some minimal testing, the team decides that it has an MVP and decides to release it.  After a few more weeks it clears the Change Management process and a thorough review by Information Security and is moved onto a production system.  Users are notified that it is ready and where they can find it.

Now here is where the Lean Methodology MVP thing comes into play.  Despite the programmers' best efforts, they have only been able to get their creation to add up the first two numbers listed in the input file.  It simply ignores the rest of the rest of the file.  You might ask "Why did they release it?" and that would be a great question.  They released it because the project's requirements stated that it needed to add up some numbers and that requirement was met since it actually did successfully add the first two numbers.  They had an MVP.  

After a little feedback from the users they came up with a workaround for this obvious deficiency and this was it:

The user was to populate all 42 lines of the input file with either wattages of each device or a zero if the slot was empty.  When the program ran it would add the first two numbers and produce the output file.  The user was to take the result from the output file and copy it to the first line of the input file.  Then they would take the third line of the input file and move it to the second line and run the program again.  They would repeat this process for the fourth line, fifth line, and so forth until they had completed all 42 lines.  A future release of the program would address this issue if funding was approved for more development work, but for now it achieved it's intended purpose using a combination of less than clever coding and a lot of user intervention.  There you have it.  An MVP.

Sounds ridiculous, doesn't it?  Well that's because it is.  Software developed today using Lean often lacks the key features that would make it valuable to the customer.  The thought is to get customers to pay for it by selling them a rough draft of what the product will eventually become.  It's great for startups at first because it starts bringing income into the company sooner.  Using traditional development methodologies a company might have to lay out a year's worth of staff salaries before they ever see a single cent from selling a solid finished product.  By the time the customer realizes that they've been duped the software company is working hard to add the missing features or fix the stuff that doesn't work.  If they can get the customer to stick with them through that process then they will retain paying (but now not-so-trusting) customers and keep generating income.

I got to see this whole process in play when I worked briefly for a restaurant point of sale company.  They had a solid product but it was dated and didn't have the features of newer point of sale systems, so they decided to create a whole new one that kept customer data in the cloud and had a much friendlier color touch screen interface.  Some of the senior engineers figured out what it should look like and produced a mostly non-functional mock-up that the executives could show to our investors in order to get them to fund development of the new system.  The investors liked it and poured money into the company like crazy.

Next came the Lean part.  Some of the senior engineers decided that the mock-up, which was for show only and never intended to actually function, was a good enough starting place and they could get the new POS to market much sooner if they used it as the foundation and just added some features to it.  It was developed for presentation purposes only and consisted of random, half-functional chunks of javascript code cobbled together to run inside the user's Google Chrome browser.  They decided that it would be good enough to use as a foundation for building a new product.

As you can imagine, the developers struggled with this for months.  They discovered the limits of javascript running in a browser and found ways to work around most of them by adding yet another freeware code module or simply putting various point of sale features in their "parking lot" to be considered at some future date.  The final result was a house of cards built on a very shaky foundation.

Those of you who have ever developed anything in javascript probably know that javascript programs in a browser are usually run briefly just once or twice before the user moves along to something else, so efficient memory management / reclamation and variable scoping are not strengths of javascript.  You might also know that restaurant point of sale systems sometimes run for days, weeks, and even months before they are restarted.  You probably see where I'm going with this, but just in case you don't, I'll tell you that javascript programs can become less and less stable the longer you run them.  Javascript is not a good choice as the environment for a restaurant point of sale system.

With this in mind, our programmers forged ahead and developed the new POS in javascript anyway so they could get it to market sooner.  They released the new version in a few months and the reviews from customers were less than stellar.  If you've ever worked in the dining room of a restaurant as a server, bartender, or manager, you know that the ability to split checks is critical to the restaurant's workflow.  Unfortunately, this capability was one of the many "parking lot" items identified early in the development of the POS and it was not available in the initial release.  To make matters worse, the Split Ticket button was displayed, but when the user pressed it they would be presented with a small pop-up message advising them that this feature was not yet implemented.  The workaround that the developers advised was to void the ticket and then ring it in as separate  tickets.  As you can imagine, this was not well-received, especially by restaurants that had already replaced an exiting POS system with this one before noticing this deficiency.

Over the next nine months we lost a lot of customers and it became apparent that developing and selling a system way before it was completely finished was a bad idea.  I was happy the day my phone rang and found my manager and a Human Resources person on the line waiting to tell me that, due to an effort to streamline operations, they had decided to abandon doing business in the territory I covered and I had two weeks to wrap up any unfinished items before my last day of work.  This wasn't unexpected and I was glad to get out gracefully before the whole house of cards finished its inevitable collapse.

So, to sum up the Lean development methodology, it basically consists of building just enough functionality into a product to start getting people to pay you for it and then, once you are generating some sales, go back and finish the development tasks that should have been done in the first place.  As you have probably guessed by now, I'm not a fan.  I think it generates an element of distrust between the customer and the vendor.  Once that trust is lost it takes an extraordinary effort from the vendor to repair it and the relationship will never be as robust and collaborative as if the vendor had never broken that trust in the first place.

Warming Up for the 2024 Elections

 I saw something quite frightening when I was driving somewhere this morning.  It was a nice, new full-sized SUV with a "Trump 2024" bumper sticker.  If you've been reading my blog for any length of time you know I'm not a Trump fan.  For some reason I have a problem with the leader of the free world brazenly telling lies every time he opens his mouth.  For some reason there are a substantial number of people who think he should be elected President again.

Trump's only accomplishment as President was to normalize being mean and dishonest.  Other than that the only thing he did was systematically dismantle all the things that made the United States the best country in the world.  It was sad to watch what transpired over those four years.  When he lost the 2020 election I breathed a sigh of relief for about a week until I realized that he wasn't going to just go away quietly and disappear.  I soon realized that he would continue to dig his hooks into the soul of the country long after he was out of office and might well come back for a second shot at it in 2024.

The thing I want to write about here is that there are still many, many people who believe that Trump should be elected to another term as President.  The perplexing thing about this is that you know they heard all the lies during his first term and have chosen to just pretend he never even spewed them out to the world.  Many times we saw stories on the evening news where they showed video of him saying something and then followed it with another video saying something that directly contradicted what he said in the first one.  When he was challenged on the obvious contradiction he told the interviewer "That never happened."  Seriously.  We just saw it and heard it.  Knowing this, he just continued to say "That never happened."

Trump supporters ignored what they saw and heard themselves and swallowed up Trump's denials as if the heavens opened up and God spoke those corrupt words directly to them.  Classic example of gaslighting -- you didn't see or hear what you saw or heard.  At first I thought that these people were a special brand of stupid, but then I began to wonder if there was something more to it.  There were even people I knew to be very intelligent and aware of what's going on in the world around them who also bought into it.  Eventually I decided that Trump must have a special type of charisma that makes otherwise rational people become blind to factual information and makes it impossible for them to weigh facts against fiction.

Anyway, what has me worried today is that people are starting to do crazy things prior to 2024.  They're hoarding food and supplies, planning escape routes to get them out of the cities where they live, buying as many guns and as much ammunition as they can find, and learning survival skills.  Recently I've started to hear people talking about impending social unrest and possibly even civil war.  I even saw a news story from a major network (not Fox) where over 50% of people surveyed believed at least one state would secede during their lifetime.  What. The. Fuck.

It just seems like the country is dividing into one part where people are embracing the changes happening all over the world and another part where people are working hard to return us to the type of life we had in the 1950's.  If the country is basically split each way along geographical boundaries then maybe it really is time to consider splitting it into two entities.  Things change over time and sometimes it's better to just embrace the change and let everyone move on to whatever they believe will be better.  I don't know the answer to this.

I could ramble on about this stuff for a long time, but my greatest fear is that 2024 will bring a resurgence of extreme Trumpism and the ruthless cruelty that comes with it.  This will undoubtedly bring friction between both sides and I think the greatest losers will be ordinary Americans.  We stand to lose a lot while we are fighting the battles of our political leaders and I'm afraid many of us won't even understand what's happening because of Donald Trump's special type of charisma.  Hopefully we'll be able to survive as a country, but if not then we need to make whatever changes are necessary and move on.

Want to Open a Restaurant?

I started this post in February of 2017 and for some reason I decided to finish it today. I guess it was just one of those things that has been silently hanging around in the back of my head and today it decided to come out.

So if you're reading this then you may have been thinking that you'd like to quit your corporate job and do something completely different. I get it. I've thought about that many, many times and I still think about it every day. Maybe you love to cook and entertain and think about how great it would be if you could just do that all the time and make a living doing it. Or maybe you've been sitting in a crowded restaurant and thought about how much money the place is going to take in when all those people pay for the food and drinks they're consuming. I've done that too. Or maybe you worked as a cook or server when you were in high school and you remember how much fun that was. Wouldn't it be great to do something that was really fun again and rake in a ton of money in the process?

These are all reasons why people decide to go into the restaurant business. After all, how hard could it be to open a place and serve food and booze and have people throw money at you all day? Sounds like a great business idea and a great way to work until you're ready to retire, doesn't it? Well, I'm going to tell you the cold, hard truth and you can decide for yourself whether it sounds right for you.

First of all, everything I'm going to tell you was learned through my experiences in restaurant ownership. I didn't learn this in restaurant school or from a book. I've owned and operated two restaurants and I'm out of that business now, but every day I still think about opening another one. Once you've done it you'll find it's very hard to get it out of your head.

The first place I owned was one that was operating when I bought it. I had been thinking about quitting my corporate job and doing a restaurant for several years when this opportunity came along. To make sure I was really ready to do it I had gotten a part time job working with a well known local chef and was already spending time in the kitchen and loving every second of it. 

I felt certain that I wanted to make this change so I bought the place at a price that was way more than it was worth. It was a neighborhood Italian restaurant that had been in business for over 50 years and was well established. For several years it had been struggling due to the owner's cocaine habit and extreme burnout. The transaction was pretty easy.  I handed over a huge amount of money and he quickly scurried away as fast as he could. This should have been a red flag, but I was crazy happy at the thought of now owning a restaurant so I didn't pay any attention to it. All of the vendors, banks, utility companies, and the landlord were eager to set up terms with someone who was actually going to pay them so it took only a day or two to get all that finalized.

The problems started to surface almost immediately. I had agreed to retain all of the employees and I quickly found out that they were stealing liquor, food, and cash as fast as they could get their hands on it. They had apparently been doing this for some time and figured it was a benefit of their employment because they didn't seem too concerned when I caught them red handed. I fired a few and a few others quit and were quickly replaced.

About 2 weeks into this adventure I had a meeting with the accountant. He had been doing the books for years and I was trying to decide whether I wanted to keep using him or find a new one. When I questioned him on the previous owner's Profit and Loss Statements and Balance Sheet for the last year he told me that he had never seen those numbers before and they didn't come from him. The P&L showed  monthly profits between $3,000 and $4,000 for the previous 12 months, but the reality was that the business was losing about $5,000 per month.  The previous owner had falsified the numbers to make the restaurant look better to potential buyers.

Then came the invoices from the previous month before I bought the place. The terms on everything were Net 30, so the previous owner spent like a drunken sailor right before the sale so the condition of the business would look better and then stuck me with all the bills for it. Perfect. The stage was now set.

Over the next three years we managed to quadruple sales and show a decent profit on paper, but the theft problems continued and costs began to go up on food and liquor.  On paper we looked great, but the bank account never seemed to get better. There was plenty of resistance as I slowly edged prices up to try and keep up with rising costs and I actually had threats of physical violence when I raised the price of a meal-sized bowl of spaghetti and meatballs to $7.00.  Think about that for a second.  A whopper at the Burger King drive through was over $5, but customers were upset at the thought of paying $7.00 for a bowl of spaghetti large enough to feed two people and having it served to them at a table with all the bread and butter they wanted, plus free refills on beverages.

The theft continued.  Bartenders would start a tab for a customer and serve them a dozen drinks.  When it was time to settle the $80 tab, the bartender would tell them the total was $20 and the customer, thinking the bartender was doing them a favor, would leave a $40 tip that went right to the bartender. Only $20 went into the register instead of $80.  They would do this when they knew I was working in the kitchen and wouldn't be around to watch them.  Putting up cameras helped quite a bit until they realized that I couldn't review 15 hours of video every day.  On top of that there were the free drinks to friends and friends of friends, employees and friends of employees.

The servers also had their bag of dirty tricks.  The best one was the ticket voiding process.  Our point of sale was very old and the ticket void password couldn't be changed.  Servers would ring up everything correctly, but if the table happened to pay in cash then they would simply void the ticket and pocket the cash.  When I saw that a server had $1200 in sales and $300 in voids I would challenge them and get some fabricated excuse that was then confirmed by another server.  I later learned that a relative of mine (by marriage) who was working in the restaurant had regularly employed this method of theft and had actually taught every new employee how to do it for themselves.  She later became an attorney where she no doubt currently uses the skills she perfected at my restaurant.  Go figure.

The real kicker was my partner.  She considered the restaurant as her personal playground and anything she wanted was free to her.  It would start with a few bottles of premium wine with friends in the afternoon, progress through dinner with those friends, and wind up with cocktails in the bar.  Her tab was routinely over $300, which would cost the business roughly about $125.  That doesn't seem like a lot until you realize that it happened 3 or 4 nights each week.  A well run restaurant has a profit margin of only about 4%, so the sales needed to finance her playground would come to upwards of $40,000 per month.  And that's not including all the free events for local non-profits and political candidates that we hosted at no charge.  It was out of hand, but she continued to spend money faster than I could make it.

So you get the picture. The place was a shit show and I couldn't get control of everything to get it stabilized.  I had a ton of restaurant experience, but non of it was in the business side of the business, so failure was inevitable and I just didn't know how to turn it around or how to get help to turn it around. The final nail in the coffin was when a friend of the landlord decided that he didn't want to be a lawyer anymore and wanted a restaurant. They decided to push me out so he could have the location and they wouldn't renew my lease. By that time I was behind on rent so we just closed down.  I spent the next few years getting divorced and paying off debts.

You would think that living a nightmare like that place would have made me want to avoid opening my own restaurant forever, but it didn't.  A small restaurant near our home became available after the previous tenant passed away.  The landlord was eager to have another restaurant in the building and worked with me to prepare it for a small Italian place which I opened on a shoestring budget in less than a month.

By applying everything I learned at the first place and not making the same stupid mistakes, we did very well.  We made money from the very first week.  We had a very small staff and they became like family.  There were a few rotten apples, but we got rid of them right away.  Customers loved the place and we were having a lot of fun, but working about 100 hours per week.  There were some slow times where cash flow was tough, but they were offset by periods of extraordinary sales.  The best part of this was that I didn't have to take on any new debt and we were able to stay current with suppliers and the landlord.

After a year we were at a place where we just couldn't increase our sales any more. We were making enough money to survive, but just barely.  The only way I could see to increase sales would be to either re-tool the restaurant to serve a higher end clientele or move the restaurant to a part of town that was nearer our customer base.  Our location was in a very old part of town and the perception of our customers was that it was in a dangerous neighborhood.  Our customer base was primarily from West Omaha and we were in extreme East Omaha so it was a long drive, especially in winter months when the snow was deep and the roads were slippery.  

After a little over a year we decided that it just wasn't worth keeping the place open because our standard of living really wasn't very good for the time and effort we were putting in each week.  We closed with only a few outstanding vendor obligations which we paid off over the next few months.

So that's my story.  Of course there's a lot more to it.  There's no way to put 5 years in a reasonably short blog post because a lot more happened.  Some of it was  great and some of it wasn't so great.  Would I do it again?  You bet I would, but I wouldn't make those same mistakes.

All that being said, you might ask "Should I open a restaurant?"  My answer would be yes, but only if you have already managed one and know the front of the house, the kitchen, and the business office like the back of your hand.  If you don't know how these areas function (in great detail) and how they relate to each other then you would be wasting your time and throwing away your money.  You might as well build a bonfire in your back yard and go shovel your money into it.  The odds of succeeding are probably less than 1 in 1,000.

If you can honestly say that you are already an expert in these three areas, then before you commit to it go find a restaurant veteran in a market where you won't be competing and have them review your business plan with you.  Develop a business model and an operating plan for your finances and have them do a sanity check on it.  Your numbers might look great, but if your sales projections are inflated just to make your business model work then you are making a grave mistake.  Be realistic and plan for the worst case, not the best.  If you can operate with limited sales and still make money then you might be on the right track.

If you can't honestly say that you have real expertise in these three areas, then find a partner who does.  Not an employee or a consultant.  Find a real partner so he/she has some skin in the game and won't walk away leaving you high and dry.  You can quickly become an expert if you partner with someone who already is.

If you can't find a good partner with restaurant experience and you are tempted to do it alone and learn as you go, then my advice would be for you to walk away and find something else to do.  You may have expertise in another type of business, but restaurants are different animals altogether and almost nothing you learned in another business is going to help you.  Just don't do it.  Step back and regroup.

There are tons of other things you should think about, but there are too many to list here.  If you are seriously thinking about doing a restaurant and have questions that I may be able to answer, then send me an email at jccamp60@gmail.com and I'll either tell you what I know or I'll try to point you to someone who knows.  Failure has been a good teacher and I'll be glad to share what it taught me so you don't have to experience it for yourself.

 

Toppy

This is a story that is better told in person in order to get the full flavor, but several of the people closest to me asked me to post in on my blog so here we go...

I hope you like it.

Throughout the course of our lives we encounter special people who help make us who we are.  These people are usually our parents, friends, favorite teachers, co-workers, and world leaders.  Everyone has a few of them even if they don't know it.  I have a number of them too, but the one I want to tell you about today is a waitress named Toppy.

First of all, I want to tell you that I did not go to culinary school.  I elected to do a chef apprenticeship instead. During a stint at a restaurant in Seattle I met Toppy.

Toppy was a server and long time employee of the restaurant.  The place was very busy and the cuisine and service were upscale but not exactly fine dining.  Toppy was older than the other servers -- maybe in her mid-forties -- and sported a beehive hair style.  Not one of the super tall ones, but tall enough that you would know it was a beehive.  The customers and management loved Toppy because somehow she was really good at serving customers, always showed up for work,  and always did everything she was asked to do.  

Everyone has a favorite thing.  Sometimes it's a spouse, a child, a car, a pair of jeans, or a pet.  A favorite thing is something that's more important to you than anything else.  The thought of losing that thing makes you wonder if life would even be worth living if it disappeared from your life.  Toppy had one too.  Her favorite thing was valium.  She loved valium, and she loved a lot of it.

At this point you might be thinking that there's no way Toppy could take valium while on her shift at a busy restaurant and still be a model employee, but you would be wrong.  In the two weeks I worked on the floor with her I never saw her sober.  In fact, in the five or six months that I worked at that restaurant I never saw Toppy sober.  Don't get me wrong.  I don't have any problems with recreational drug use as long as it's done safely and doesn't harm others.  Just don't show up to work high as a kite and then wonder why you just cut off your thumb on a meat saw.

If you looked at Toppy you would have to be stupid not to know immediately know that she was high as fuck.  Her eyes would only open about a quarter of the way.  This caused her to have to tilt her head back so she could see you standing in front of her.  Her mouth was hanging open most of the time.  It wasn't smiling.  It was just hanging there open so you could see all her dental work and even count her teeth if you wanted to.  Toppy moved very slowly.  She took tiny steps, obviously having to give each one of them some deep consideration before committing to raising or lowering a foot.  You didn't want to get behind Toppy when coming out of the kitchen toward the dining room.  If you happened to be carrying a tray of food then you could be guaranteed that it would be ice cold by the time you got it to the table unless she veered off her chosen path and miraculously got out of your way.

Toppy was also a slow talker.  When you think of the term slow talker you think of someone who speaks sentences very slowly and takes a long time to get their point across.  Toppy did this, but she was also a slow answerer.  If you asked her a question it would take her an incredibly long time to begin giving you her answer.  It was like the verbal communication between you had to travel all the way to the moon and back and then required some intense processing before a response could be sent back over the same route.  It usually took her 5-10 seconds to respond to a question and start slowly giving her answer.  This doesn't seem like a long time, but the next time you're having a conversation with someone think about it and you'll understand how long that really is.  To make this even better, she was also too stoned to speak loudly enough to hear her unless you were standing very close.

On the first night of my time in the dining room the management, in their infinite wisdom, paired me with Toppy.  I was supposed to follow her all night and learn how service worked.  When I showed up about 30 minutes before my shift I was waiting in the service area for Toppy to show up and I introduced myself to the other servers.  They were generally very friendly, but all of them rolled their eyes or slowly shook their head when I told them I was following Toppy all night.  I was beginning to develop a feeling of impending doom.  On top of that, the manager had failed to inform Toppy that I would be working with her, so when she showed up and I told her she just squinted at me for a good long time while she processed that information and then just said "Ok" without even moving her lips and walked away.

If you've ever worked in a restaurant you know that there's more involved to opening for the evening than just unlocking the doors and letting people start coming in.  By opening time the kitchen has spent all day getting things ready.  The servers have opening duties as well.  They have to make sure the service area is well-stocked, there are enough napkins folded, coffee and tea are made, lemons are cut, and condiments are full.  There's a lot more to it than that, but you get the idea -- it's a lot of work to get set up and it all has to be completed by opening time.

Knowing this, I asked Toppy what we needed to do to get set up.  She thought for a very long time and then finally just said "You know, just the usual stuff."  I decided to watch the other servers and just do whatever they were doing.  That seemed to work because a couple of the other servers commented that our section looked pretty good.  One of them loaned me their extra wine opener so I would have one in case I got lucky and someone ordered a bottle of wine.  I felt like I was part of the team.

The restaurant wasn't super busy that night so the first part of the evening went well.  I very slowly learned where everything was kept, how to ring in orders, how to get drinks from the bar, and how to collect payment from the customers.  When I say I learned these things very slowly, it wasn't because I'm a slow learner.  It was because it took Toppy and exceptionally long time to explain them to me and most of them couldn't be explained without a short intermission part way through for a cigarette or restroom break.  

After a couple of hours she let me help carry food to the tables and serve it.  This place didn't use trays so we had to carry plates without them.  Servers were permitted to carry as many plates as they could balance as long as they didn't ever drop one.  This was out of my comfort zone, so I self-limited my capacity to three  plates.  Toppy, on the other hand, would balance half a dozen plates on her arms and still swing by the bar to pick up a few drinks on her way to the table.  The food was almost certainly cold when it reached the table due to the time it took her to make the trip, but it eventually got there safely.

Think about this for a minute.  If you've ever stumbled home after a long night of drinking with friends and tried to unlock your front door, you know it can sometimes be a challenge to get the key in the hole and turn it.  Imagine being twice that impaired and having to balance 4 or 5 plates of hot food on your forearms and carry them through a busy dining room without dropping or spilling anything.  Toppy was way more than impaired but she did it over and over and over again without incident.  Amazing.

So at one point during the night one of Toppy's orders came up while she was at the point-of-sale ringing in a new order.  The expeditor was screaming for her to pick it up because there were a couple of orders coming up right behind it and her food was in the way.  She told me (very slowly) "Take the first three to table 14 and I'll follow with the other three."  I grabbed them and told the expeditor that Toppy would be coming to get the rest.  I maneuvered through the dining room and successfully delivered the plates to the table.  When I turned around Toppy was nowhere to be seen so I went back to the kitchen hoping to either meet her carrying the remaining three plates or get them myself.

When I went through the service area Toppy was not there, but I could see her back in the salad area calmly eating sliced radishes.  She saw me and slowly walked back to the service area.  I asked if she wanted me to serve the rest of the order and she thought for what seemed like ten minutes and finally said "No, I'll do it."  She grabbed the plates and headed out to the table.  I stayed in the service area to ring in some drinks and after a few minutes she came back without the plates and went over to the expeditor stand.  She headed back over to me and said that the kitchen had only cooked half the order so they would need to prepare three more plates.  When I reminded her that I had already taken three plates out she asked "What table?"  I told her that I had taken them to table 14.  She went back out to the dining room to look.  

When she came back she very slowly said "There are only six plates on the table."  When I reminded her that there were only six people at the table she stopped for a while so she could process that bit of information and do the complex math involved in figuring out that each of the six people at the table had a plate of food.  Eventually she said "Ok.  Don't do that again" and dug around in her pocket until she found a valium.  She put it in her mouth and washed it down with a swig of non-dairy coffee creamer.  She offered me one but I decided it would be better to stay awake for the rest of the shift and politely declined.

By this time we only had about an hour of service remaining and things were starting to calm down a little bit.  That's about the time the incident happened.  It was a table of four and their dinner service had gone fine.  Super friendly people and not overly demanding.  When we picked up the plates, Toppy asked them if they were interested in dessert.  They all said they wanted this flaming fruit thing on the menu.  It was kind of like a Bananas Foster but had a bunch of other stuff in it in addition to bananas.  I can't remember the name and I have never seen it again since then.  It was prepared and served tableside on a gueridon that the server wheels up next to the table for cooking and serving the dessert.

If you're not familiar with a gueridon, technically it's a small four legged table, but in a restaurant it's a small portable cart with one or two burners built into it.  The idea is that the server or maitre' d wheels it up to the table and cooks something right there in front of the customers.  It is used mostly in fine dining ala carte restaurants, but occasionally you see them used in a not-so-fine restaurant, mostly for flaming desserts or chateau briand.

A genuine gueridon is a beautiful piece of cooking and serving equipment and is treated with reverence and respect by both the service staff and the kitchen.  It is meticulously cleaned, polished, and maintained after every shift.  As you have probably guessed, we didn't have a genuine gueridon.  We had a rickety beat-up metal cart with a single burner portable camping stove on it.  After all, why pay upwards of $2,000 for a real gueridon when you can buy a utility cart at Wal Mart, throw a tablecloth over it, and place a portable camping stove on top for less than $50?  You get the picture.

Now, this particular dessert had several ingredients and was easy to prepare.  At least it was easy to prepare if you weren't high as a fucking kite.  One of the ingredients was Bacardi 151 rum.  If you're familiar with 151, you know it's basically jet fuel in a bottle.  They use it in some exotic tropical cocktails to increase the alcohol content to the point where most places limit you to only 2 drinks.  Other than that the only place it's used in cooking is to produce a big flame when you're cooking in front of a bunch of customers.  When it's used in Bananas Foster it only takes about half an ounce to produce a flame that gets the customers all excited and impressed.  It usually helps earn the server a bigger tip, but otherwise doesn't do much except maybe set off the restaurant's smoke detector for a minute or two.

The problem that night was with the 151.  For some reason when the kitchen set up the cart for Toppy they gave her a small wine carafe full of 151 instead of about an ounce in a soup cup.  They probably saw that the order was for four servings and thought a 12 ounce carafe would be the equivalent of four 1/2 ounce portions.  Anyway, they put a full 12 ounces in a small carafe and threw it on the cart along with everything else.

She slowly wheeled the cart out to the table and got it situated.  She told me to stand behind her and to the side so I could watch but wouldn't be in her way.  With that she proceeded to make the dessert.  She got all the ingredients in and it was time for the 151.  It was at this point that I noticed that there was enough 151 in the carafe to get 10 sailors drunk.  I started to say something but she squinted at me and shook her head.  Toppy fearlessly started to pour all of the 151 into the screaming hot pan with everything else.

It wouldn't have been disastrous except for two things:  First, Toppy moved very slowly and poured the 151 from directly above the pan.  She was not able to move her hand out of the way in time to keep it out of the fireball that immediately erupted from the pan.  Second, she did not stop pouring even when the fireball engulfed most of her right arm and the now empty carafe.  In a reflex move she pulled the pan away from the burner with her other hand and flaming 151 poured out all over our makeshift gueridon, the customer's tablecloth, and her apron.  Toppy looked down and realized that she and everything around her was on fire.  It took her a minute to process the gravity of the situation and then she slowly took a couple of steps backward.

By this time the customers had jumped out of their chairs and were standing against the wall behind the table.  I had reached over to an adjacent table and grabbed a nearly full water pitcher so I could attempt to put Toppy out.  I managed to get some water on her sleeve and put that out and then smothered her burning apron until it was mostly out.  She looked down at the apron as if she was having a hard time understanding that she had very recently been on fire.  After a full 30 seconds of careful consideration she very slowly said "Wow" and then looked around the dining room to see if any of the other 200 people in there had noticed the smoke and flames.  The place was silent.

Next Toppy jumped into action.  She turned to the burning tablecloth and picked up a napkin.  I thought she would spread it out and throw it over the fire to smother it, but instead she folded it neatly and started slowly wiping the fire like you would wipe a baby's chin after feeding him a spoonful of pureed beets.  This continued for some time.  I realized that she wasn't making any headway at putting out the fire and retrieved another pitcher of water from the service area.  By this time all of the 151 had burned up and the fire was consuming the polyester tablecloth.  The smell was stifling.  There was enough water in the pitcher to put out the fire so everyone was out of danger.

The Assistant Manager had made it to the table by now and was doing his best to calm the customers to the point where they would just leave and not sue the the place into bankruptcy.  In the middle of this, Toppy joined the conversation and offered to move them to a fresh table and try the dessert again.  She told them she might even be able to get the Assistant Manager to comp the dessert so they wouldn't have to pay for it.  They just stared at her like they had been stunned with a cattle prod.  

Eventually they realized that no one had been hurt and none of their clothing or stylish accessories had been damaged and began joking about it being an evening they would remember for a long time.  They assured us they would be  back in the future but they would probably request a different table and would certainly avoid that particular dessert.  As they were leaving Toppy squinted at me while trying to remain standing and said "I think I used too much butter."

Later that night we were all in the party room while the servers did their banks and prepared for their check-outs.  They started to talk about how much they had made in tips that night.  Today servers don't share that information with everyone, but back then they did.  They went around the table and I heard numbers like "35," "42," "51," "18," and "26."  That doesn't seem like a lot of money for a busy shift of working your ass off, but back then it was pretty good money.  Today good servers make a lot more than that, but the cost of living is much higher.  They eventually got to Toppy and everyone went silent waiting for her to respond.  She was just finishing up counting her money and eventually she said "170."  I didn't believe that, but later one of the other servers told me that Toppy usually made two or three times what everyone else made.  I still don't really understand it, but I'm wondering if the valium actually helped.

That's pretty much the end of the story of Toppy.  I finished out my two weeks with her without any additional incidents and went back in the kitchen to spend a month shucking oysters and cutting up fish.  Once we were there very late for a party and Toppy asked me if I wanted a ride home.  I thought about how much valium I had seen her consume during the shift and politely declined.  

I lost track of Toppy after I moved on to the next place, but I still think of her occasionally because she's one of those really special people we encounter during our journey through life.

  

The Elusive Process Library

A couple of years ago I ran into an interesting situation at work.  It was one of those surreal things that kind of felt like it should have been in the movie "Office Space."  You run into this kind of stuff occasionally if you decide to sell your soul and work for a large organization.

I'm a Senior IT Engineer at a large healthcare organization in Nebraska.  For those of you who are surprised by this, yes there are actually large healthcare organizations in Nebraska.  Anyway, I was working on a project that required moving a medium-sized piece of equipment from one data center to another  data center across town.  By medium-sized I mean it was too big for one guy to move by himself, but not big enough to require a moving crew or any special equipment.

You would think that moving this thing would have been as simple as going into the data center, unhooking all the cables, removing it from its rack, and wheeling it out to a waiting Subaru to be transported to its new home.  Once at the destination the whole removal process would simply be done in reverse and the equipment would be in its new home whirring away and waiting to be called into action.  You would think this but you would be wrong.

The first problem with this assumption lies in the fact that we, as Senior Engineers responsible for installing, configuring, and operating these miracles of technology do not have access to the data centers where they are kept.  We have to get approval from Management and make arrangements with Operations to escort us to the device we need to work on.  If we bring someone to help us, they must do the same thing.  This is a security precaution implemented to prevent a rogue engineer from entering the data center and dismantling a production system before the Operations staff can wrestle him/her to the floor and secure the offender's wrists with cable ties behind his/her back while waiting for the authorities to arrive.  Instead, we manage these devices remotely. 

Think about that for a minute.  I can't walk into the data center with bad intent and a crowbar in hand, but I can sit undetected in the comfort of my home office at 2:00AM and slowly delete all the company data and render all the computing infrastructure useless with just a few mouse clicks.  Ok.

There are a number of other steps we must take that are security-related but I can't share them here.  Let's just say they are complex, take a lot of time, and some of them even involve biometrics.  They really want to make sure that the person they've worked with for the last 5 years is actually who they say they are. Being an astute reader, you have probably already guessed that most engineers really don't have the patience for much of this.  Management, in their ultimate wisdom, knew this and decided to boil it all down to one form for the engineer to fill out.  

This is how it works:  Once you answer about a page of questions, the online  form is routed to all the necessary approvers and eventually back to the Operations staff, who then contacts the engineer to schedule the activity.  All the engineer has to do is remotely shut down the equipment and Operations does the rest.  After the work is completed, Operations notifies the engineer that it is all done.  In the rare case that the engineer is required to be present while the work is done, he/she is notified again anyway.  This process works relatively well, although running cable for a new install or removing cable when a system is taken out of service can take some time.  That's an overview of the process for deploying something new or removing something from the data center.  Bear with me a little longer and soon we'll get to the Process Library part of the post.

With all this in mind, I decided to leverage the form and install/remove process  to get my system moved from one data center to the other one.  After all, it was basically just using the removal process and then immediately executing the installation process to achieve my objective of moving the system.  You would think the story ends there, but it's really only beginning.  This is where the Process Library part comes in.

I submitted my request on the appropriate form detailing what I wanted removed from one data center and where I wanted it to be reinstalled in the other data center.  It was immediately rejected.  Apparently it was too much information to go on one form and the person who receives the forms and then assigns the work thought it was confusing.  He said I should split it into two forms since it was actually two separate things I was asking Operations to do.  I complied and submitted two separate forms, both of which were immediately rejected.

The reason given was that two forms would generate two work tickets in their ticketing system and, although they were closely related, there was no way to tie the two work streams together to make sure they were done in the right sequence.  I asked if it would be possible to assign the two tasks to the same team and tell them something like "Do this one first and then immediately do the other one."  He told me that there was no way in their system to make sure the tasks would be assigned to the same team so there was no way to guarantee that they would be done in the correct order, which caused both forms to be rejected automatically.  After some discussion he eventually said "So what you really want is just to move the system from one data center to the other?"  I said "Yes, please.  I just need it moved.  Can we do that?"  I thought we were starting to get somewhere until he answered  "No, we don't have a process in our Process Library for that."

I asked him where the Process Library was kept and if it would be possible for me to write a process for them detailing the steps involved in the moving a system.  He informed me that I could certainly document the move process in the same format as the other processes in the Library, but it would have to be reviewed by the Process Engineering Committee and then approved by management before it could be placed in the library.

At this point I knew that documenting a new process would take less than an hour, but getting it reviewed and approved would likely take many years and I might not live long enough to finally celebrate its adoption.  As a point of reference, I’m 61 and in good health so my expiration date is well into the future.

I asked him again where I could find the Process Library so I could use a previously approved process as a template for my new one.  I really had no intention of writing a new process and then going through the long and grueling steps to get it approved, but by now I was curious about this Process Library thing and wanted to see it for myself.  By now I had decided that the best way to get my system moved would be to buy pizza and beer for the Operations staff and skip the form altogether.  I asked again where I could find the Process Library. 

Eventually I wore him down enough for him to admit that he’d never actually seen the process library himself but he had heard about it from others.  The perceptive readers are probably asking now that if he’s never actually seen the Process Library and didn’t know where it was kept, then how did he know that what I was requesting was not already in the Process Library?  I diplomatically asked that very question and he told me that he had a spreadsheet listing all of the processes in the Library.  I asked if I could see the spreadsheet and he told me that it was password protected and he was prohibited from sharing the password with me because it would be in violation of an Information Security policy. Ok. 

I decided that my best chance for locating the Process Library would be to ask one of the other IT employees who had been around longer than me.  I decided to ask Emily because she had been on the job for many years and used the word “process” in meetings more than anyone else.  If anyone knew the location of the Process Library it would be Emily.  I messaged her on Microsoft Teams and she immediately responded that she was in a meeting and she’d get back to me when her meeting was over.  I wondered who Emily was meeting with because no one really even knows what Emily does.  It must be important because she’s been doing it for a very long time, but no one really knows what function she performs. 

I decided to ask some other senior team members while I was waiting for Emily to call.  My next stop was Joe.  When I asked him about the Process Library he said that it was developed when management hired a consultant about twenty years ago and that person told management that they should have one.  Everyone was required to document what they did and how they did it and all of that information was eventually combined to build a Process Library.  That sounded plausible so I asked Joe where I could find it.  He told me that he didn’t know where it was kept and he had never actually seen it for himself, but he had once overheard some other employees secretly talking about it.  This didn’t help me but at least now I knew the history of the Process Library.

About the time I realized that I wasn’t making any headway with Joe, my phone rang. It was Emily. We exchanged the usual pleasantries and then I asked her where the Process Library is kept.  There was silence on the other end of the line for about 10 seconds as she recovered from the initial shock of hearing that question.  As she began to speak I noticed that the cordial tone of her voice was gone.  She was so uncomfortable with the direction of the conversation that I might as well have asked her what color lingerie she was wearing at the moment or if she was interested in coming over later and drinking mohitos naked with me in the hot tub.

Her voice got very soft and she spoke for quite some time, but I don’t think she actually said anything.  After a while she asked if there was anything else she could do for me.  I wasn’t interested in asking her about the hot tub thing so I thanked her and ended the call.  Back to square one.

My next stop was a Senior Analyst on our Application Development team.  I had worked with her several times and she had always been a good source of information.  I figured that most of our processes ultimately have something to do with applications at some point so someone from that team might know where to find the Process Library.  I reached her right away on Teams and asked her where I could find it.  She told me that she had asked the same question about a year earlier and was told to fill out a form requesting access to the Process Library.  She filled out the form but could never find out where to submit it.  She said everyone knew about the request form, but no one knew where to submit it.  I suggested that detailed instructions for requesting access to the Process Library are probably outlined in a process within the Library but no one could figure out how to get those instructions because no one actually has access to the Library.  It’s sort of like when you lock your only set of keys in your car.  All you really need to do to get them is to unlock the car and grab them and then you would be able to unlock your car.  She suggested that Judy, our Administrative Assistant, would certainly know how to gain access and that I should probably just ask her about it.  I thanked her and moved on.

Now you should know that Judy and I have a “history” and it involves a red Swingline stapler.  When I first started this job my wife bought me a red Swingline stapler like the one Milton had in the movie Office Space.  It was kind of an inside joke about me going to work for a very large corporate entity.  About a year into my employment, Judy came around to everyone and replaced their staplers with identical black ones.  I wanted to keep my red Swingline but Judy wasn’t going to stand for it.  Over the next couple of years she made many attempts to covertly replace my beloved red Swingline with a smaller generic black stapler so that everyone in the building would have exactly the same type of stapler. 

I wouldn’t have really cared if it wasn’t for the fact that my beautiful wife had given me the red Swingline.  In fact, I hardly ever use a stapler.  I’ve probably used less than 20 staples since I got the Swingline.  But it has sentimental value and I don’t want it to end up in a box of unused staplers stacked in some remote part of the basement storage area.  To protect it from Judy I usually locked it in a drawer or put it in my computer bag if I was going to be away from my desk for more than a few minutes.  This kept it out of Judy’s clutches and it was always available in case I happened to encounter some paper that was begging for a staple or two.

One afternoon Judy came by and demanded that I hand over the red Swingline.  I refused and Judy stormed off muttering something about a disciplinary action.  At this point the smart choice would have been for me to just take the stapler home and leave it there, but instead I decided to super glue it to my desk where Judy could see it anytime she was nearby.  My co-workers enjoyed this immensely because they got to watch Judy try to pry it loose several times until I finally removed it with a little acetone and took it home.

Ok, so back to the Process Library.  I went to Judy’s desk and asked for a request form for Process Library access and also how I should submit it once I filled it out.  I figured that once access was granted then someone would tell me its actual location.  Judy informed me that we were out of Process Library Access Request Forms and triumphantly handed me a Printed Form Request Form that I could use to request more of them.

I took it back to my desk and filled out both sides and had one of the other engineers initial the “Witnessed By” section.  After we both inspected it thoroughly for spelling and grammatical errors I took it back to Judy.  She looked it over and immediately rejected it and handed it back to me.  Judy then informed me that we no longer use Section R and I would have to do it over again, this time leaving Section R blank.

I made my way back to my desk and filled out the form again.  In the Quantity Requested field I specified 50 copies of the Process Library Access Request form and returned it to Judy.  She immediately rejected it, telling me that we have to order forms in increments of 100.  I went back to my desk again and filled out a third Printed Form Request Form, this time asking for a quantity of 100 copies of the elusive Process Library Access Request Form.  Miraculously it was accepted.  Judy said she would let me know when the forms arrived in 6-8 weeks.

At that point I went back to the Operations Control Center and simply asked the Operations staff if they would just move the system in question for me and afterwards I would buy them all the pizza and beer they could consume.  This approach worked and the system was moved by the end of the next day.  I fulfilled my end of the deal by taking them to a local pizza place and buying a couple of large pizzas and an insane number of PBR tall boys.

This is almost the end of the post, but I will say that the new forms eventually arrived and they had been printed on the wrong paper so they were returned.  After another 10 weeks the replacements arrived, but it was determined that the print shop had used the wrong version of the form and it contained incorrect contact information.  On the third try they were perfect so I filled one out and submitted it to Judy.  This time she accepted it and sent it on to the person who processes that particular form and then I never heard any more about it.  After almost 2 years I still have no idea where the elusive Process Library is located or what it contains. 

Later, I did run into a consultant working in our building who said he was retained as a Process Architect.  I asked him if he was working on the Process Library and he said “Not yet.  I just requested access to it.”  I think I will check with him in a few years and see how it’s going.

That’s the end of this post.  I think if there is a lesson to be learned here it would be that sometimes organizations become so focused on implementing and following processes that they become process bound and are unable to execute the basic things necessary to succeed in their primary mission.  I think there’s a sweet spot hiding somewhere in between the chaos of lean development/implementation methodologies and being process bound.  Very few organizations find this sweet spot and ours certainly isn’t one of them.

 Thanks for taking the time to read this exceptionally long post.  I promise to make the next one shorter.

Kitchen vs. Servers

 I chose Kitchen vs. Servers as the title for this post because I knew it would draw your attention.  If you’re taking the time to read this, you’re probably working in the hospitality industry.  As far back as I can remember there’s always been some kind of animosity between the kitchen staff and the front of house staff.  I’m not going to try and solve that problem for you, but I hope to show you how to think about it a little differently.

I have never been able to figure out how this rivalry started.  Maybe one side did something to the other side during the middle ages and the fight began and is still ongoing today.  Maybe it’s been passed down for generations and generations until we all just thought was part of restaurant life.  Maybe it’s like a dog and cat thing and we’re genetically wired to dislike the other side.  I don’t know, but whatever it is, we can change it and you can help figure out how.

In the spirit of full disclosure, I’m a retired chef.  I’ve worked in many kitchens all over the place and have seen this rivalry everywhere and even participated in it a few times.  I’ve also worked as a food server and have participated in it from that side of the fence.

I’ll speak to the kitchen side of it first.  If you’re a cook or chef, the whole process of selling food is not all about you.  You play an important part, but not the only part.  You don't sell food.  You are overhead.  Those servers that you constantly harass or demean have to go to the table and convince the customer to order the food and then after it's served and eaten  they have to get money for it.  In essence that’s the function of a restaurant – to buy, prepare, serve and get paid for food.  Your primary role ends when the server takes it to the table.  From there it’s up to them to do everything else.

As a cook or chef, you have to realize that the restaurant owner doesn’t have a magic money tree growing somewhere that he harvests every other Friday to give you a paycheck.  The money for your check comes from the entire process of buying food, cooking food, serving food, and then getting the customer to fork over some money to pay for it.  That money will go toward your paycheck.  In the simplest terms possible this means that if the restaurant can’t collect money from the customer, then you don’t get a paycheck.  It’s a super simple concept when you think about it.  No sales, no paycheck.  The easier it is for the servers to sell, the more money there is.

Where this becomes important is when you think about how all this happens.  You cook the food, but the server takes it to the customer and makes sure he/she’s happy enough to pay for it.  Like it or not, you are dependent on the server for your paycheck.  With that in mind, you can see that anything you do to make their job easier is also good for you.  On the other hand, anything you do to make their life harder is not good for either of you.

Keep this in mind the next time you have the urge to throw a ripping hot dish up under the heat lamps and choose not to warn them that it’s hotter than the Earth’s molten core.  Or when you berate them for making an error on an order.  People make mistakes and making one shouldn’t result in a punishment from the Dark Ages.  Just give them what they need to make the customer happy and then move on.  You can get with them at the end of the shift and straighten out the point-of-sale or discuss what went wrong.  You can work together to figure out how to prevent it from happening again.  After all, it’s not you vs. them.  You’re on the same team.

On the other side of the coin, if you are a server then the kitchen is probably not really out to get you even if it sometimes seems that way.  They’re most likely not even thinking about you, much less plotting against you.  They’ve probably been back there sweating their balls off all day and they’re tired, stressed out, and maybe even a little hungover.  When they get behind they get frustrated just like you.  Help them out a little bit by slowing down service if you can to help them catch up.  They’re not behind because they hate you.  They’re behind because something probably went wrong back there and they’re trying to recover from it.  A good cook’s worst nightmare is to get behind on orders.  Do what you can to help, even if that’s just staying out of the kitchen for a little while to help ease the noise and confusion.

Look, I can write these little pearls of wisdom all day and there are hundreds of them, but you should get the idea by now.  The point of all this is that servers and the kitchen are working for the same thing and fighting among each other holds everyone back.  A little care and cooperation goes a long way toward a successful restaurant and makes for lifelong friendships.  I decided a long time ago that helping the servers whenever I got the chance made my life better too.  And guess what?  The servers started doing the same for me.  When we all started collaborating before, during, and after the shift everyone had fun at work again.  Sales went way up and we all started making more money.  You see, we’re on the same team.