I think in CX we're often told we're going to cause more problems when we try to offer suggestions that are in the product or engineering "domain". I know whenever users would write in with bugs that were obviously tied to a particular release and I was able to find the actual PR that caused the issue I'd feel like I was stepping on toes to say so. It took many years to believe that I could build things myself! But now there's this this unlearning of that self imposed stigma that what I do won't be as good.
THIS! I find myself going down the rabbit hole and figuring things out that is beyond my job scope. That's not just with eng but also with risk, compliance, etc. I find most teams are really receptive to help if you acknowledge their expertise. Starting with a DM like, “hey, I’m seeing X and I checked ABC. I believe the cause is DEF and wanted to check with you to be sure I'm understanding this correctly. Are you cool if I just make the tweak and fix it?” Something that shows you know your stuff and demonstrates that you understand that this is their area. It helps build trust that you know what you’re doing too.
I’ve run into this a few times in my career and I’ve found that teams usually purposely add “bureaucracy” to create boundaries between functions. For instance, in the early days of my first startup, I made all the “builds”, learned how to fix API bugs, even extending the external API wrapper, etc. I wasn’t a developer, rather I worked in support but we all agreed that it was everyone’s job to deliver value to customers and that we didn’t have time to worry about who fixes what. Interestingly, as we got bigger, the walls went up. You could no longer just “fix” things, you had to get approval, then eventually a “sponsor” (I.e. another dev checking in your changes), finally, they asked you to just file a dev ticket and it would be prioritized (which was code for: this won’t get done any time soon). I don’t know how to explain this, but it became a pattern at other companies as well.
