MTTI, RGE, and other off-the-books IT initialisms

If IT departments had their own Urban Dictionary, these would be early entries.

I've worked in IT for almost 25 years, but it wasn't until recently that I heard the phrase "mean time to innocence" or its initialism, MTTI. I giggled and compared other IT-centric funnies like error code ID-10-T or PEBKAC (problem exists between keyboard and chair).

I heard it in a statement made by an IT leader to his networking team. "The faster we can prove it’s not the network, the faster they'll stop bothering us." Though tongue-in-cheek, I quickly realized the relevance and seriousness of the sentiment in the cloud-first world. The services our companies increasingly depend on are outsourced. What other sayings have evolved from a bit of fun to serious business today?

Before taking a look at other sayings that have taken on an increased seriousness, let's explore MTTI a little further.

Mean Time to Innocence

Proving MTTI between IT groups within a business is just part of the troubleshooting process when things go awry. Cloud means outsourced, and achieving a low MTTI is critical when dealing with outsourced IT services and functions, especially so when very little is directly under an IT department’s control.

Establishing an MTTI means asking:

• Is it the user’s poor home WiFi, slow router or high bandwidth issues?
• Is it an ISP issue or a wider transit carrier problem?
• Is the cloud infrastructure oversubscribed? 
• Are there problems with the middleware layer?
• Is there truly a problem with the application?

Proving one’s innocence doesn’t just mean your own, but everyone’s in the supply chain so a culprit can be identified and an action taken. With some vendors servicing millions of customers, providing direct evidence of failure is a good way to get attention quickly. 

Another aspect of outsourcing (or the cloud effect) is the consolidation of different services down to a limited set of platforms to reduce costs and complexity. Some argue about this approach, using the metaphor “placing all of your eggs in one basket” to describe the risks.

Whichever side of the fence you are on, the change in toolsets from self-managed, on-premise networks to outsourced, cloud-based applications requires a change in tools to keep that MTTI low. You must know each individual’s application experience and use monitoring tools developed for the cloud to quickly determine where issues lie. 

This is an RGE (resume generating event)

I’ve performed my fair share of “RGEs” in my career through mis-clicks, typos, or simply plugging in the wrong cable (Ethernet loop anyone?). Back then, this was somewhat okay. Many incidents were simply considered learning opportunities. Most tasks were manual, processes were lax, recovery time for most simple mistakes was negligible and the blast radius was usually small due to the separation of systems.

Today, everything is remote and consolidated in the cloud, where the smallest mistakes can take down an entire business. Or an entire social media platform. Many enterprises have highly regulated processes and procedures, and with DevSecOps automation and blue/green deployment scenarios, there is little chance for error without negligence. 

I feel a little sorry for today’s new IT employees where mistakes more easily generate an RGE as opposed to a career-defining lesson learned. With many more contractors and outsourced services in use today, keeping someone because “they’ll have learned from it” is rare.

OSI Layers 8, 9, 10…

Though this one is a little less serious, unofficial OSI extensions correlate to the increasing complexity support engineers face as the outsourcing of services continues. Any IT engineer should be familiar with the seven layers of the OSI model, or the four-layer TCP/IP model, which characterizes and standardizes the communication functions of a computing system.

Humorous sendups of the OSI model include additional layers, like:

• Layer 0: Funding layer 
• Layer 8: The individual person layer
• Layer 9: The organization layer
• Layer 10: Government or legal compliance layer

How about adding these into the mix to cater for cloud and telework being the new norm?

• Layer 11: Cloud provider layer
• Layer 12: Middleware/PaaS/sub-cloud provider layer
• Layer 13: Home WiFi with a router in the basement competing with the kids watching Netflix layer
• Layer 14: ISP & transit carrier who just got dug up with a backhoe layer

Outsourcing applications to cloud providers trades off responsibility with extra support challenges. I’d argue that after all the improvements in technology, support roles were less complicated 20 years ago. Go figure.

Have you tried turning it off and on again?

While slightly off-topic, this one’s humorous to everyone that works with technology, thanks to Chris O’Dowd in The IT Crowd.

But there are real reasons why turning it off and on again really does something. It can be performed to reset power in chips and capacitors to “jumpstart” a failed component. It can be to kill a memory leak in a low-level process or something in the OS that the user has no control over.

Our cloudy, outsourced, super-tech world today is blurring these basic realities we previously took for granted. It’s questionable whether you really can turn your phone off today. Will rebooting your car become part of general auto troubleshooting? Will restarting a cloud VM clear the problems caused by a stuck cap?

This relates back to our first saying, MTTI: Gone are the days when you could just restart a service forlornly hoping it comes back. With everything being outsourced, consolidated, or integrated these days, it is vitally important to be able to point the finger quickly and hold the vendor accountable to ensure productivity.

Otherwise, you could be looking to shorten your own MTTI to avoid a potential RGE. 

What to read next

How not to treat digital transformation like a buzzword