SoylentNews is people
SoylentNews
Arthur T Knackerbracket has processed the following story:
Some Microsoft organizations are looking to increase their span of control, defined as the number of direct reports or subordinates a manager or supervisor oversees. It also wants to increase the number of coders compared to non-coders on projects,
According to anonymous people familiar with the matter who spoke to Business Insider, Microsoft has yet to decide how many jobs will be cut, though one person said it could be a significant portion of their team.
Other companies such as Amazon and Google are also reducing the number of managers and executives in their drive for efficiency.
Microsoft wants to decrease the ratio of product/program managers (PMs) to engineers. Microsoft security boss Charlie Bell's division has a ratio of around 5.5 engineers to one PM, but he wants that to reach 10:1.
News that Microsoft is targeting non-coders in these cuts is in contrast to the many stories about generative AI replacing the need for programmers. Microsoft CTO Kevin Scott made the startling prediction last week that 95% of all code will be generated by AI by 2030. He added that humans would still be involved in the process, though it's easy to imagine that there will be fewer of them.
At the start of the year, Microsoft confirmed it was implementing performance-based layoffs, though it said those let go would be replaced with new hires. Microsoft rates employees on a scale of 0 to 200 and bases their stock awards and bonuses on this rating. Anyone in the 60 to 80 range – 100 is average – is rated as a low performer.
Soon after those performance cuts were revealed, the company said it was making more job cuts across its business, impacting employees in the gaming, experience & devices, sales, and security divisions.
(Score: 2, Flamebait) by Username on Monday April 14, @02:53PM (5 children)
I don't understand the process software companies are using. So do they have small teams maintaining or developing each aspect of Windows? Like some guy redoing a 32b legacy app into 64bit, and a separate person testing it, another making the msi, with a dedicated manager for this team?
(Score: 3, Informative) by JoeMerchant on Monday April 14, @03:48PM
There's a pattern to the process at our company: whatever the process is, if you don't like it just wait a few months, it will change.
I exaggerate, slightly. I've been on the same project for 10 years, it launched under "the new" PDP (that used to stand for Product Development Process, but what we refer to the process as changes a little more often than the process itself.) Long before the product launched, there was a new "unification" of our PDP with a wider portion of the larger company, so we can all use the same process across timezones and countries. Not a bad goal, but... our project was excused from the change since we were "near launch" so we stayed in the legacy process. Sometime after product launch, yet another process was adopted and this time we did say that we were "on the new process" but basically shifted from post-launch of the old process to post-launch of the new process. The 1.x revisions rolled on. 2.0 has been "under development" for 6+ years - longer if you count all the features that were being developed for 1.x that got punted to 2.0. It's not totally clear what process 2.0 development is under, in theory it's not "in development" it's more "investigational, proof of concept" though we do try to build our requirements definitions along with the code of the bigger investigations. So, instead of a maintenance release, 2.0 is now a shaping up to be handled as a whole new project - and guess what? No, there's not a new PDP, but there is an all new tool that we will be managing the project trace matrix in - lucky me, having ignored the previous tool which replaced the god-awful we just can't get anything done in this systems engineering tool that was mandated for 1.0 (yeah, we did what we could with that, but actually used another tool to do the real work because "the server is down" gets to be a really lame excuse the 100th time you use it.) So, that "backup tool" that 1.0 really got done in, yeah... 2.0 will be using that too, but like we did for 1.0 we'll be translating our tool "important points" into the new company wide mandated management tool, and I hear there's a new process being developed specifically with that tool in mind...
So, yeah, I try to focus on making things that actually work and leave all of the process stuff to the people who seem to enjoy it. If they ever work up the nerve to tell me I'm "not doing the process correctly" I patiently ask them how it should be done, then follow that pattern until the next person tells me I'm doing it wrong. Last year that got into a loop where two different "process owners" had contradictory opinions of how things should be done, so when I made full circle from A-B-A I informed A: "So, here it is, I'm doing this A way, but you need to talk with B..." about a month later I heard from A that I should do B...
I think our work item tracker on the tool we actually use is about to pass 30,000 items - anytime that has happened with a tool I used in the past it was replaced with another soon thereafter, but this one is rented to us by M$, I suspect they can keep it going well past 100,000.
🌻🌻🌻 [google.com]
(Score: 3, Funny) by turgid on Monday April 14, @05:38PM (1 child)
It's a widely known fact in this industry that you need at least three managers to empower, encourage and coach a single Software Developer and to make sure that s/he's going to use ZeroMQ at all times.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Touché) by Unixnut on Tuesday April 15, @07:39AM
And here I thought it was just my company that had that. We on average have 3 managers per employee (i.e. someone who actually does the work), I beat the average by being blessed with 4 of them, most of which give me contradicting instructions as part of some internal power struggle.
Needless to say getting anything done is a very long/slow process, with lots of re-doing and re-starting of projects depending on which manager temporarily gets the upper hand and insists on things being done "their way".
Not to mention 4 sets of 1-1's and performance reviews, and of course I am marked as an average to poor performer for "not listening to instructions" and "not finishing projects within given ETAs". which of course is impossible to do with you have four sets of instruction, the requirements keep changing and you have four sets of admin/meetings/report writing, for each manager.
I don't understand how a company can be so management heavy yet not go bankrupt, it is basically impossible to get anything done yet the company carries on existing and getting income. It is like its being levitated against the gravity of dysfunction somehow.
(Score: 2) by Thexalon on Monday April 14, @06:46PM
Don't fret - as far as I can tell, nobody else does either, including the people who are supposed to be using it!
At least, at my large company jobs, the official process was always in flux as managers tried to put their stamp on things for internal-political reasons, and the real process amounted to:
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 2) by gnuman on Monday April 14, @08:21PM
You know, there are reviews. You generally do not want 1 person responsible for all the code or shit will hit the fan sooner or later. As an example, as soon as they leave. Secondly, you can divide tasks and features for different people. The reason why you have teams of maybe 6 people is that is the number of people that can be managed effectively. So if an org has 600 people working in it, and generally you have 6-10 people teams, that org is 3 managers level deep.
Your statement is kind of naive, like if nothing else happens except "1 person responsible for MSI" -- if you release MSI, that's an automated process anyway.