[gwbas1c]

> Avoid back and forth

> Processes are expectations made explicit

Processes should avoid back-and-forth. They need to ensure that clear communication happens when work is handed off from one person to another.

Assuming you're working on tickets, do you need to ask 200 questions every time you get an incoming ticket? That's a process problem; the process should ensure that whoever created the ticket puts in the information you need to do their work; and the process should ensure that whoever created the ticket knows how to fill in the information you need.

IE: If QA is filling out a ticket, they should know how to write a bug report, steps to reproduce, and how to collect diagnostic information that's unique to the product.

If support is filling out a ticket, they should know how to clearly explain the customer's problem, and what questions to ask the customer to collect diagnostic information that's unique to the product.

[thaneross]

That sounds like a pretty siloed way to work. Conversations with the people involved is much high bandwidth and full-duplex which increases the odds of understanding the underlying problem and building what people actually want.

[gwbas1c]

> Conversations with the people involved is much high bandwidth and full-duplex

That's impossible when working with people in different timezones, or when working with customers.

Specifically, regarding support: The people in support need to know how to support their product, and that includes knowing what information to collect if they believe they will need to escalate. They just can't randomly pull engineers into a support call.

You also can't have a support organization that expects "high bandwidth" communication with a customer. (IE, support can't go back to the customer for every ^%$#^#$ question the engineer asks.)