I really enjoyed reading this. It makes me want to call the developer for support just to make my day better. :) I’ve worked with a lot of people who don’t und

I really enjoyed reading this. It makes me want to call the developer for support just to make my day better. :) I’ve worked with a lot of people who don’t understand technical offerings and analytics well (both coworkers and customers) and have learned some similar lessons. Making oneself available for these kinds of calls seems like a distraction, but it prevents so much more unnecessary and/or misunderstood work than a more structured queue as long as it isn’t abused. (To do this, hiring needs to factor emotional intelligence, too; our talent pool defaults to slightly less polite than the older Japanese professional customers the author describes.) I try to maintain small enough connections between teams that an informal approach to balancing this kind of support can be used and most of the conversations can be directly between the person with the direct need and the person who owns the relevant service or worked on the project. Trying to scale it and introduce PMs and middlemen to save time is counterproductive because they often can’t explain the heart of the problem, so the interruption doesn’t pay for itself, and instead of bringing emotions that communicate valuable context to the developer, the middleman brings emotions related to their job, desire to please their boss, frustration at being assigned a low-context task, etc. So when that “scaling” is unavoidable it’s always better to force work into a structured process because you might as well minimize time and communication if you can’t get the right two people to connect.