Skip to content

DEO checks

Our standard pipeline is

  • Brief -> Draft -> QA -> Edit -> Deliver -> Revise -> Deliver

In some cases, we want earlier feedback from the customer and we use a shortened pipeline to show an early draft. We don't want to go through full QA and editing, but we also don't want to show the customer anything that would embarrass Ritza. Therefore we do "Don't Embarrass Ourselves" (DEO) checks, either from a technical perspective or a language perspective or both.

Therefore the pipeline might become

  • Brief -> Draft -> DEO (Technical) -> DEO (Editing) -> Deliver -> Revise -> QA -> Edit -> Deliver

Which gives us a point for the customer to give earlier feedback without wasting the time of doing a full QA and edit on stuff that might need to be cut or drastically changed.

Another time we do DEO (Technical) checks is in cases where we have a lead writer for a customer who is supplemented by another writer who is not as experienced with the core technology in that customer's field and when the field is complicated enough that some technical misconceptions or mistakes might not be picked up during QA. In this case we do

  • Brief -> Draft -> DEO (Technical) -> [Draft] -> QA -> Edit -> Deliver

What we need from a DEO (Technical) check

For a Technical DEO check, done by a writer with experience in the field that the article covers, we want to

  • Ensure that the article passes a basic sniff test for being correct and valuable. We want to answer the question "Does the writer understand this topic to be able to create valuable content in this space, or should we throw out this article and find another writer". Usually this happens during writer assessments at the hiring stage, but in some cases when our customers work in very niche fields, a writer might a) be competent, b) think they're competent in the niche field, and c) not actually have a good grasp of the niche field. In this case, we want to catch this during the Technical DEO check.
  • Flag anything that is obviously technically wrong. Sometimes a writer might have an overall grasp of the field and be producing content that is valuable, but still have some gaps in their knowledge of the niche. Maybe they use terminology incorrectly, or misunderstand a smaller concept within the field that is explained incorrectly in the article.

In the first case, we should usually scrap the article and start over with another writer.

In the second case, the writer doing a Technical DEO should do one of the following

  • Fix the mistake(s)
  • Give feedback to the original writer to fix the mistake(s)
  • Give some feedback and context in their ritza- channel to Gareth and Sarah

The best course of action is probably clear to the writer doing the Technical DEO. Some rules of thumb are

  • If the issues can be fixed in under 30 minutes, they should just be fixed
  • If it would take some research and/or bigger changes to fix, they should be given as feedback to the original writer
  • If it's not clear how bad the issue is without further research, then it should be discussed in the ritza- channel.

Remember that the point of a DEO is not to overlap with either editing or QA, so Technical DEO checks should ignore language issues like grammar and structure, and also ignore general QA issues like code checking code samples, linting, screenshots, etc. While there might be some overlap, we don't want DEOs to delay the production of an article, so it's better to err on the side of pragmaticism rather than getting caught up in too many smaller issues.