Marketing demands review of all technical documents, programmer creates a fake protocol to mess with them: '[It was] called the "TP Protocol." [I]t could be implemented as a 2 or 3-layer network, each layer called a "ply"'

Author image for Brad Dickson
Brad Dickson • Managing Editor
Jun 7, 2025 6:00 PM EDT

The interplay between departments and their personalities is one of the more fascinating dynamics in any workplace; undoubtedly, there is no greater discrepancy—no contrast more glaring—in personality and presentation than between the technical department and sales or marketing. It's pretty much a "Yin and Yang" situation, except without much harmonious existence and more of a quiet standoff of incompatible values. The charisma and peacocking personalities of sales, prioritizing smoke and mirrors, and grand gestures clash with the quiet, logical precision of the technical workers. 

Expectations are never going to meet the reality of what is technically possible, and when sales/marketing overpromise, it becomes hard to deliver a product that is going to keep clients happy. And when it comes to finalizing a project together and shipping it to clients, there's always going to be disagreements as the two values collide. 

When this marketing department demanded a review of all technical documents that a client might possibly see, it prompted this programmer to implement a satirical protocol, proving that marketing was not capable of properly reviewing technical documents anyway, due to their inability to piece together the hidden message in the protocol's operation.

Add as a preferred
source on Google
Advertisement
  • 01

    "Co-worker creates fake document to prove rule is stupid"

    Back in the mid-1980s, I worked for a company that made manufacturing equipment that ran on an internal network. I had to learn it to support it. They had recently re-written the interface from the ground up, but the documentation was the earlier version, so I was kinda lost. I turned out to be proficient at writing documentation so I volunteered to rewrite the doc as I was learning the system. In doing so I discovered a strange appendix to the doc that got me incredulous, and then got me cracki
    via arkaycee
  • 02
    HOM
    via Sigmund
  • 03
    There was a rule that had been handed down a couple of years before, that any document that a customer might ever see, even a highly technical document, had to be read and approved by the Marketing department. A co-worker wanted to test this, so they wrote this appendix, that was purporting to describe the networking protocol involved in the system. It was approved with no changes by Marketing.
    via arkaycee
  • 04
    What did it describe? A protocol called the "TP Protocol." Rather than being a 7-layer network, it could be implemented as a 2- or 3-layer network, each layer called a "ply." So 2-ply or 3-ply. The messages were identical sized, and the end-of-message was called a perf. There was a potential issue to be fixed later, that a CANcel character could cause it to pause until manually cleared, this was called "sitting on the CAN." It went on from there similarly for several pages. I wish I could rememb
    via arkaycee
  • 05
    I left the appendix in with my version-2 manual after checking with my manager and him forwarding my doc to Marketing.
    via arkaycee
  • 06
    SugarCookie197 I used to do tech support for customers, which involved. retrieving their system data to figure out bugs. We had a "scan point" where if the scan point was triggered, an error message would print. For example a door opening would cause a scan point to print "door open" Or a fire would cause" overheating"
    via arkaycee
  • 07
    Tbis customer had one message "only 3 beers left in fridge" as one of their error messages. It was wonderful. It was a major billion dollar baby bell customer, gotta love those. grunt guys, finding joy where they could
    via arkaycee
  • 08
    HS_HowCan_That... A programmer I knew had coded an error message that displayed if a user had a large number of errors during data entry. The message read "Take your mittens off, dearie". No one caught it in code review. Unfortunately, the message did get triggered in production and the user was not amused and complained. That resulted in a reprimand.
    via arkaycee
  • 09
    djdaedalus42 Reminds me of the woman who asked for leave to carry out a project with the acronym C.H.I.L.D.
    via arkaycee
  • 10
    avid-learner-bot That's brilliant, Marketing probably approved it because they thought it was a real protocol, not realizing it was a satire of their own bureaucracy... how do you ensure a department that doesn't understand tech ever actually reviews technical documents?
    via arkaycee
  • 11
    Nu-Hir I do this all the time when I make documentation. Any user termination documentation I make the user is always John Conner. The date of termination is always Aug 29, 1997. No one has caught that one.
    via arkaycee
  • 12
    via... I work pretty closely with my company's marketing team and typically what they're checking for is horrible typos, weird off-brand design choices, and obvious content errors. Think "you cannot make our logo pink", "you spelled the CEO's name wrong", "I'm sure you meant to write 'ducks' not 'f s' here", just to give a few recent examples.
    via arkaycee
  • 13
    They're not checking for content correctness (though at my job as of three months ago there are new "do not send it to communications without getting written approval from your director that is also sent to communications" protocols in place because of a mass email that went out with wrong info).
    via arkaycee
  • 14
    Vampire Slayer20... Love it. Back in the 80s, the company I worked for had standardized development documents, of which about 80% of the sections were boilerplate or very nearly boilerplate. And about 3 levels plus of management had to approve before work could begin.
    via arkaycee
  • 15
    One section involved travel requirements, which were needed very seldom for what we did. A great friend decided to essentially see if mgmt actually read these boilerplate sections. So he added words to the effect that 2 weeks in Hawaii (flight, hotel on the beach, car, etc) were needed to "humidity test the software component" of the product to ensure it could function in humid environments. Mind, this product was all software...
    via arkaycee
  • 16
    Yup, all signed off. (I think he fessed up to it after he made his point...no repercussions other than having to remove his additions and get it re- signed with much laughter.)
    via arkaycee

Want More? Follow Us and Add Us as a Preferred Source on Google.

Tags

workplace discussion tales from tech support workplace-stories programming jobs tech support employee talesfromtechsupport job malicious compliance technical difficulties work technology programmers workplace Tech developers workplace malicious compliance employment in the workplace
Scroll Down For The Next Article