Seriously, you think this is a dev/team issue? You never once question the incentives at play here? I'd have not been surprised by the standard "throw the engineers under the bus" response from someone outside tech, but if you work in the space, I would have expected better.
You nail it in sentence two. THE COMPANY chose to use azure. You do not. As VPs/Directors have told me on multiple occasions "we sell to the decision makers." And with how short-term decision making is for most companies, ESPECIALLY large/public ones, it's very easy to make that sale via "no one ever got fired for..."/bundle deals/incentives/etc.
I have seen MANY very capable and well intentioned devs damage their careers trying to fight this. I fully agree there should be accountability, and I wish more customers cared about this dimension, but at the end of the day it's going to be a heads-we-win tails-you-lose situation for devs so at least try to be empathetic in that respect, and ideally hold the RIGHT people accountable, ala upper leadership/corporate buyers/investors, which I doubt will happen because of MS's scale/market power. (To be clear, it's lose-lose for us in that when something bubbles up enough that it actually hits MS in the wallet they flip on a dime from refusing to staff anything that isn't feature work and force devs to do MASSIVE amounts of makework to show that they're "investing in that area" without actually lessening other obligations; see the recent 'security push'. That's honestly why you see tickets don't move, no one has spare cycles to spend on anything that isn't a leadership priority or something we're going to get in trouble for if we don't do; we're all largely overworked just with that, ESPECIALLY given the return of stack-ranking and the culture that entails.)
I could write another whole essay about the kafkaesque support agent situation, your statement of "eager but unhelpful" is correct on the first part and _far too kind_ to the latter part, but my main thought is well-contained enough that I'd like to not muddy it outside of noting that "yes, that is a disaster, and you're only seeing the tip of the iceberg."
You’re making an assumption that teams having control over their work will lead to better quality of product (which i agree) and then (I assume you predict), in return, will result in better financial performance.
But is that true? I am not so sure. I worked in some banks and it is very easy to come up with better products for consumers… that will make less revenue to the banks. I also worked in big tech, and so how prioritizing UX over paying customer requests is virtually impossible.
Oh… i also observed teams ACTIVELY not wanting to take steps to improve products because it would lead to taking risks, and most corporations incentivize you to he risk-averse.
This is a very interesting topic, with few clear answers beyond “culture has to be very good to build good products”
Also.. most people want to do their job well, very few people are aligned in what “doing job well” means when it comes to large corporations.
Improvements you wanted were not prioritized not because dev teams disagree, because their leadership needs to hit sales targets, and that probably means catering to some very specific requirements of very large orgs.
There is no malicious intent, and no unprofessional behavior. This IS big corpa working AS INTENDED. Everyone stuck in some sort of local maxima, no one is happy and business is growing.
tylersuard•6mo ago