1. 8
  1.  

  2. 8

    If you don’t trust your team, no amount of reading “101” articles, or even actual technical expertise, will suffice as a stand-in. There’s not a technical manager in the world I could not sneak pretty much anything I wanted past if they weren’t solely devoted to monitoring my output, and I am certainly no multiple-year IOCCC-winning master of obfuscation. Trust is mandatory. In the absence of trust, there’s no point doing anything else.

    This article itself is pretty bad in the specifics. For example, the “translations” of the “red flag” phrases all assume the team is trying to pull one over on the manager, that is, there’s no trust already, in which case it doesn’t matter what phrases the team uses—the lack of trust is the red flag and the “bullshit” will be literally anything they say. If there is trust between the team and manager, then all of those phrases have specific, non-red-flag meanings which are important to consider.

    If you’re worried about bullshit coming from your team, the real answer is to figure out why they don’t trust you and rectify that. (Though in my experience, once trust is lost, or if it never existed in the first place, it can’t usually be regained and the only option is for you or them to quit. Engineers mostly don’t like having to bullshit their managers to get anything done and they mostly have pretty good job prospects, so it will probably be them. I’ve seen this happen multiple times.) Trying to catch them out will only amplify the lack of trust and lead to subtler, harder-to-detect bullshitting.

    edit: I forgot another point: if you’re a non-technical manager trying to manage a team of junior engineers, who might reasonably be expected to do as mistakes everything the article calls out as bullshit, there’s nothing you personally can do to keep them from learning by trial and error. Memorizing a big checklist of common errors (like this one) will have a minimal impact, as the universe of possible mistakes of inexperience is exceedingly vast. Get a strong technical lead who can keep the team in check, or cede them to a technical manager who can do the same (or be prepared for them to do a whole lot of very expensive learning on your dime).