Resolving Engineering Disagreements

Owned by Daniel Puratich
Last updated: 2023-10-03
2 min read

Engineering disagreements come up all the time, this document sets out how we can resolve engineering disagreements with respect (aka maintaining ). First of all, engineering disagreements will always come at some cost. That cost should be made up of the following categories:

  • quality of the product

    • You can lose on quality of the product if you let people make incorrect engineering decisions.

    • You can get away with this on non-critical systems, you cannot get away with this on critical decisions.

    • This is fast and keeps member engagement high because their decision is used.

    • This loss also assumes you’re correct, sometimes you aren’t!

      • Nobody learns from this because oftentimes, especially for non-critical things, will not result in noticeable failures. And even so we will not see how the alternative would’ve performed.

  • time to produce the product

    • time for people to validate / prove something.

    • You can lose on people's time if you ask people to:

      • make a decision matrix

      • do more engineering analysis

      • document their engineering analysis

      • explain their reasoning to each other

      • perform a side by side comparison between options in a real world test

    • All of these take engineering time will push back the products timeline, however, this will promote team engagement as everyone will fully understand and agree on a decision.

    • This promotes learning as well because people can directly see why they’re wrong or right.

    • This is generally considered as the best thing to lose on. If the time you’re losing is minimal and the scenario permits, this option is generally considered the best.

  • team engagement

    • You can lose on team engagement if you as Director, lead, or any position of power command what design decision we will be doing.

    • This hurts team engagement because people feel like their engineering opinion isn't being valued (because it isn’t).

    • This is good because it is extremely fast.

    • Please note

There is one final way engineering disagreements can be resolved, but this should be avoided in all cases. This comes at the cost of:

  • respect and human decency

    • You can lose respect by making an engineering disagreement a personal/social disagreement.

    • This can be avoided by separating the person from their actions

      • i.e. not making comments regarding anyone’s character

      • i.e. comparing people’s credibility based on previous decisions

    • This is never good trivially. There are no advantages of this approach. It may occur inadvertently due to the emotions of us humans.

    • If this happens accidentally please do your best to reconcile. We all make mistakes, see .

    • Examples of attributes regarding any individual that will not be tolerated as valid comments are: (in case this wasn’t obvious…. and of course this isn’t an all encompassing list):

      • voice

      • age

      • professional experience

      • amateur experience

This document came from a director discussion in Discord Convo. This conversation is not public as it cites a variety of specific instances with people’s names though if you are a current or past WARG director this should be visible.

 

 

 

 

 

 

Â