when my company said they'd start selling Teams service, and the associated hardware-based phones, I knew exactly what the experience would be like, and I wasn't the least bit disappointed
you are nothing to microsoft. you don't exist. and what's interesting about that statement is that it would be true even if I wasn't saying it inside this very limited social circle. I could say that at any convention, of any size. i could announce it on TV, and it would still be true, because microsoft has the entire world as its customer.
to microsoft, it is simply a matter of time until you need to use their product. there's no "if," only "when." it's true for every product they make - if you gave me enough details about your life, I would be able to prove that you are paying a few cents of the monthly cost of an MS-SQL server somewhere. and, without question, dozens or hundreds of Windows servers. this is not even including your job, if you work at any place that owns more than one computer, or does business with someone who owns computers.
microsoft is the great convergence point of all cashflow, and that means nobody at the company has any incentive to do anything. customers do not matter to them; "KPIs" matter, and those are all defined as massive, ten-thousand-foot statistical analyses.
if you are using a Teams phone, you are one extension out of literally millions, and that's only because this is a relatively young product (well, not if you trace it back to Lync and so on, but let's not go there.) Eventually it will be hundreds of millions. no business ever thinks in terms of "we have 500 customers who can't operate their business because we fucked up." they think in terms of "what percentage of our userbase is unhappy," and if that number is "1%", the managers all slap each other on the back and hoot and holler and pop bottles, even though that means literally hundreds of thousands of people are unhappy.
microsoft handles you with a scoop and a scale. they don't have users, they have pounds of users. you are aggregate. they pour you from vessel to vessel. a farmer doesn't look at a load of 50,000 oranges, see a single moldy one, and go "ah, we have a problem." that's to be dealt with way down the line; the little people will do it.
and so, to microsoft, it doesn't matter if your phone doesn't work for an hour. they think in terms of "uptime-availability-phone-days" or whatever, some number that's aggregated across an entire business, or more likely, an entire business region, over weeks or months.
that also means that everything is done in bulk, and everything is done very slowly. you change a config in the teams portal. it doesn't appear on the phone. you reboot the phone. nothing changes. is it broken? no. the task is queued. it'll complete. eventually.
there's a button in the teams admin portal that says "Restart phone." if you click it, it literally says "Task queued. Check back if task does not complete after 7 days."
name a scenario where an IT admin - where anyone - would click restart on a hardware device and be okay with it happening up to a week later.
and yeah, i know, i know - this is just typical modern microsoft shit where a developer's raw implementation details have leaked out into a customer-facing UI. obviously they don't expect it to take that long, this is just a "max_timeout" value that's set stupidly high behind the scenes and, as is typical for MS these days, nobody gave it a PR pass before releasing it to the public
except, I mean. it doesn't actually restart the phone. the phone never restarted. and, in fact, the changes i made to my user - altering the phone number and extension - didn't appear for three days.
there is simply no reason for this. i have personally operated systems that can update tens of thousands of (far more complex) phone configurations in a matter of seconds. even if 500,000 users are simultaneously making the same requests i am, we're talking a few megabytes of changes. it's chump change. it's nothing.
the reason this is like this is not because it's hard to do. it's because microsoft is so big that they are utterly and completely divorced from what their products actually look like to users, and that has led to their software development practices crystallizing into this incredibly dry, incredibly stale, incredibly plodding one-foot-in-front-of-the-other death march to the beat of a Best Practices drum that is causing them to write user-facing software as if it's a fucking bank transaction processor. these people cannot tell the difference between "a button you press that turns on a light" and "invoice processor that ingests 50,000,000 customer records, then spits out a pile of bills six days later." the sludge machine sees all tasks the same, they all go into the pot and get slowly stirred and stewed and broken down until they become Eventually Consistent.
i didn't need to see any of this to know about it. i predicted these specific problems, exactly what I wrote above, the same day that i learned this product existed. it's the default outcome of a company being this fucking big.
I find it fascinating that once a corporation becomes big enough that it's dealing with state-scale levels of people, it ends up independently evolving state-like bureaucratic inefficiencies... but in the technology layer rather than the regulatory layer
