In general, engineers hate to implement exceptions to business processes.
Different roles face very different trade-offs in common situations, sometimes making communication difficult. Exceptions are a perfect example.
Let’s imagine a nascent business, in which most processes are done manually by the sales team (which can be actually limited to the hustler CEO). In parallel to the CEO talking to users and making the first sales, the CTO is busy automating everything. To be more concrete, let say one such action is changing the customer’s plan. Currently, the process requires the CEO to edit the account in Stripe, while the CTO builds a user dashboard that will allow them to change their plan at will.
Their workload profile is very different. For the CEO, every customer request takes approximately 10 minutes. It doesn’t take a lot of time individually, when it becomes difficult with too many clients. For the CTO, there is a lot of work upfront, let say 3 days, but when it’s done, it can handle all the requests from customers.
Now, let say a client wants a custom plan.
For the CEO, making an exception is no big deal — it might take here only 15minutes to create a custom plan. There’s almost only upside and no downside, so she’s inclined to agree.
For the CTO, making an exception means paying the upfront cost again. Depending on the flexibility of the code, and the complexity of the exception, it might mean anything from an hour to a full 3 days re-write. In addition, exceptions tend to generate bugs, degrading the experience for other users and making the engineer’s life difficult. Lastly, exceptions pile upon each other, adding to the code complexity, making future evolutions more difficult. As a result, the upside is still there (a happy customer) but the downside is much greater. She will be more inclined to refuse to make the exception, and ask the CEO to convince the customer to accept a standard plan.
The CEO and CTO may enter a conflict, even if they both have the user’s and company’s interest at heart.
The point here is not to conclude if we should make exceptions or not — each situation will be different. The point is that CEO/sales and CTO/engineering face very different trade-offs regarding making exceptions, and should ensure that they communicate them clearly to each other.