Most of the tensions described in the article are things that I believe can be modeled in terms of debts. It depends on which kinds of debt your team willingly takes on. Most teams take on at least one or two types routinely, no matter how religiously they avoid the others:
Technical Debt:
- build it fast by any means necessary
- use whatever pre-packaged library exists, and duct tape it into your existing system.
Analytics Debt:
- build it without any prior UX experimentation on the design.
- build it without any way to measure key interactions
- have no data about the status quo before you build something new, this will insure that your new feature is a success because the before numbers are unknown.
Marketing Debt:
- build it without knowing whether users want it (or what they want)
- build it without talking to users about their problems.
Spec Debt:
- build it without creating a detailed spec, leaving many important decisions up to the developer, who may not know the full reasoning for what she is building.
- have a print designer do the UX, so that many subtle areas of interaction, animation, and behavior are unspecified.
Mental Model Debt:
- build it without having a hypothesis about why it is helpful and what might need to be changed next. This helps your engineers make choices that speed up this feature but add significant complexity for the next step.
- do not worry about the statistical significance of numbers. Just focus on the direction the numbers are going and be sure your CEO knows how smart you are.
Credibility Debt:
- Don't acknowledge things that have gone wrong (with planning or execution) before. The pretense of infallibility is helpful to creating resentment and mistrust among different divisions of your team.
Kool Aid Debt:
- Whatever you do, be sure it is "agile" or "scrum" because then you have done everything right and you didn't need to worry about any of the above forms of debt.
Technical Debt:
- build it fast by any means necessary
- use whatever pre-packaged library exists, and duct tape it into your existing system.
Analytics Debt:
- build it without any prior UX experimentation on the design.
- build it without any way to measure key interactions
- have no data about the status quo before you build something new, this will insure that your new feature is a success because the before numbers are unknown.
Marketing Debt:
- build it without knowing whether users want it (or what they want)
- build it without talking to users about their problems.
Spec Debt:
- build it without creating a detailed spec, leaving many important decisions up to the developer, who may not know the full reasoning for what she is building.
- have a print designer do the UX, so that many subtle areas of interaction, animation, and behavior are unspecified.
Mental Model Debt:
- build it without having a hypothesis about why it is helpful and what might need to be changed next. This helps your engineers make choices that speed up this feature but add significant complexity for the next step.
- do not worry about the statistical significance of numbers. Just focus on the direction the numbers are going and be sure your CEO knows how smart you are.
Credibility Debt:
- Don't acknowledge things that have gone wrong (with planning or execution) before. The pretense of infallibility is helpful to creating resentment and mistrust among different divisions of your team.
Kool Aid Debt:
- Whatever you do, be sure it is "agile" or "scrum" because then you have done everything right and you didn't need to worry about any of the above forms of debt.