Red Hat forced to hire cheaper, less senior engineers amid budget freeze(theregister.com)
theregister.com
Red Hat forced to hire cheaper, less senior engineers amid budget freeze
https://www.theregister.com/2021/11/05/red_hat_jobs/
44 comments
At this point IBM is only around because it takes a while to die. IBM's leadership are truly incompetent and I do not expect to see them around in another 10 years. It's a pity that they acquired RedHat, as it will now be driven into the ground like everything else IBM touches.
I read this comment every decade.
I'm sympathetic to the view that "IBM is failing" lacks evidence, but trying to look at the evidence objectively, IBM doesn't seem to be doing well relative to the tech industry broadly. Their stock price is flat since 2000, while the SPY is up 5x. Their revenue is flat/decreasing since 2005 (as far back as I can find).
It's possible IBM never dies, or even never shrinks, but stays the same as the world grows around it. That seems like the same thing.
It's possible IBM never dies, or even never shrinks, but stays the same as the world grows around it. That seems like the same thing.
yep, they are so large they can easily buy successful businesses like redhat and the cycle continues.
IBM fulfills a particular niche: when you need to have a contract with a company the will take the fall contractually.
There are plenty of too-big-to-fail companies that at the end of the day don't care if the project succeeds, just that if somethings goes wrong you have some definition of legal recourse. You buy IBM because you write in your contract "we agree to buy the necessary computers systems and software as require per our vender (IBM) and the vender will be responsible for ensuring compliance."
Sounds great to both parties, except the loophole doesn't say that the requirements need to be correct. If things go great, fine. If things go wrong, customer gets to argue with IBM. Good luck with that. IBM isn't known for their hardware and software in the computer world, they're known for their lawyers.
There are plenty of too-big-to-fail companies that at the end of the day don't care if the project succeeds, just that if somethings goes wrong you have some definition of legal recourse. You buy IBM because you write in your contract "we agree to buy the necessary computers systems and software as require per our vender (IBM) and the vender will be responsible for ensuring compliance."
Sounds great to both parties, except the loophole doesn't say that the requirements need to be correct. If things go great, fine. If things go wrong, customer gets to argue with IBM. Good luck with that. IBM isn't known for their hardware and software in the computer world, they're known for their lawyers.
Operating in a Too-Big-To-Fail world is more about deferring liability than succeeding. If you fail, you get to keep your job, but if you fail you get fired. If you succeed you get to keep your job, and maybe a bit more, but not equal to the negative of job loss.
IBM has seen unicorns come and go, and will keep doing so for decades to come.
Incompetence is rarely a factor in downfall nowadays.
I've worked at places that are loaded with senior engineers/developers. It can be awkward from a business sense because: a) Most of your developers are too expensive, so you put very few of them on any project, b) Senior engineers usually have a lot of ongoing efforts that require their attention, while a mid-level or junior might be able to to focus more on your current spring, c) Senior engineers can (but not always) be more set in their ways on technology or methods and be resistant to embrace newer/riskier approaches, and d) There's no room in the org to promote your mid-level engineers, so they leave and become senior devs elsewhere.
At my first full-time development job, we had only entry-level and senior devs with no mid-level folks. As one of the entry-level folks, let me tell you-- what a mass of confusion that was. Hopefully Red Hat's targeting more of a well-rounded or balanced organization, rather than purely cost-cutting measures.
At my first full-time development job, we had only entry-level and senior devs with no mid-level folks. As one of the entry-level folks, let me tell you-- what a mass of confusion that was. Hopefully Red Hat's targeting more of a well-rounded or balanced organization, rather than purely cost-cutting measures.
On one hand, this seems positive. It felt impossible for me to get into the sw development field because companies only wanted experienced devs. Not having a degree, I got hired for a non-tech entry level role at a software company and worked my way up while paying my bills with a second job.
But on the other hand as an older, experienced developer, decisions like this can be interpreted to mean no old people. Later in my career I remember a software director saying "we're not looking for gray beards right now" when describing how he wanted to build out the engineering org.
It's great to see change that will allow more people in. But it's a bad idea to have decrees from the top dictating (by implication) that only young people should be hired. Surely there is a middle ground that can be found.
But on the other hand as an older, experienced developer, decisions like this can be interpreted to mean no old people. Later in my career I remember a software director saying "we're not looking for gray beards right now" when describing how he wanted to build out the engineering org.
It's great to see change that will allow more people in. But it's a bad idea to have decrees from the top dictating (by implication) that only young people should be hired. Surely there is a middle ground that can be found.
I think one of the key things that everyone fails to notice is that there are a whole host of tasks involved in creating and maintaining an operating system (particularly older versions) that will bore a seasoned developer. Hiring less experienced developers not only benefits less experienced developers, it benefits the more senior folks by allowing them to offload uninteresting tasks to those who will find them interesting, and learn from them.
People are being overly cynical. People are not born as senior engineers. You must start somewhere.
No, but a career typically lasts 40 years, and the "Senior" title is acquired from 5-15 years in - generously. Just given a bell curve distribution, even weighted, IBM should be hiring >50% "Senior" engineers.
How long does it take, on average, for someone to have the title of senior engineer?
IBM, if you want Oracle to take the mantle, I am sure that they will.
"There is no license cost associated with Oracle Linux. Pricing reflects $0 for license, and all charges are related to services."
"There is no license cost associated with Oracle Linux. Pricing reflects $0 for license, and all charges are related to services."
I think this just makes sense. Going forward, companies, especially those that are remote, are going to have to figure out how to support less-senior engineers. I think the hotness of the market from the pandemic made it easy to only hire senior and staff+ engineers, but now it’s time to return to growing the industry from the bottom up.
Besides, as a senior or staff engineer, you should welcome this change because it gives you new opportunities to mentor and educate less-senior engineers, which is usually a prerequisite to promoting beyond staff.
Besides, as a senior or staff engineer, you should welcome this change because it gives you new opportunities to mentor and educate less-senior engineers, which is usually a prerequisite to promoting beyond staff.
heaven forbid you give younger people a chance
I don't think that is a problem. The tech industry needs jobs filled. Tech companies have found (or at least believe) that much of their work doesn't require much knowledge. Most code doesn't require much knowledge to write. It's basic plumbing.
Also look at startups. Startup code is often garbage. But it's good enough to get clients and get investors. Most software is pretty mediocre, but the selection threshold is low to begin with for most of it, so it's good enough.
RedHat here is assuming no doubt that senior engineers aren't leaving fast enough to cause issues. You won't have a company staffed with just newbies. And if someone vacates a senior position, I presume that position would be filled with someone already at the company. They can always back off on this hiring policy.
Also look at startups. Startup code is often garbage. But it's good enough to get clients and get investors. Most software is pretty mediocre, but the selection threshold is low to begin with for most of it, so it's good enough.
RedHat here is assuming no doubt that senior engineers aren't leaving fast enough to cause issues. You won't have a company staffed with just newbies. And if someone vacates a senior position, I presume that position would be filled with someone already at the company. They can always back off on this hiring policy.
I grew up in a factory town in the middle of nowhere. It was unwritten policy on the engineering team to never hire students with GPAs over 3.0 and to avoid anyone with a history of big jobs at major companies.
That policy existed because, based on past experience, the company knew that it would lose those people quickly. That was in the days when people often stayed with a company for life.
That policy existed because, based on past experience, the company knew that it would lose those people quickly. That was in the days when people often stayed with a company for life.
whats so terribly wrong about this? a shop can get too senior. and senior people have a tendency to do what they want and not what the business thinks it needs.
unless RedHat is getting into quantum computing or cpu design, i expect they can probably save alot of money and may in fact end up with a better functioning org.
unless RedHat is getting into quantum computing or cpu design, i expect they can probably save alot of money and may in fact end up with a better functioning org.
RedHat isn't a startup banging out MVP products and hoping for the best.
A lot of businesses rely on RedHat being the last line of support for thier systems, and if they're losing or unable to hire genuinely senior engineers, that's a serious problem for everyone involved.
A lot of businesses rely on RedHat being the last line of support for thier systems, and if they're losing or unable to hire genuinely senior engineers, that's a serious problem for everyone involved.
Great, a good way to get fresh new ideas and perspectives from newbies who inject ideas that sound outlandish. These ideas can bake in peoples' minds who can produce it. Other than that, spreading knowledge from seniors to newbies creates broader layer of transferrable experience and knowledge.
> We recognize that this will mean we need to plan for training and mentoring, promotions, and internal mobility as well, and we are here to support you in that.
This makes me believe they are trying to do it right and not just cutting costs for its own sake.
This makes me believe they are trying to do it right and not just cutting costs for its own sake.
Mentoring someone can result in you yourself being fired. You train someone to be able to do what you can do, and now you have a person who has the skills and costs the company a lower salary than yours. If the company decides to reduce the workforce guess who gets fired? You do! Happened to me, company I worked for lost $2M due to poor management, I had just trained a new young worker, they kept him and fired me. It turned out to be one of the best things that ever happened to me since it led to my getting much more interesting and higher paid work. It was however distressing and felt very unfair. So be careful, think about your particular situation and whether the mentoring you are doing is fully sufficient to replace you. It is painful to have to compete with the people you work with, and in some situations unnecessary, but stay aware it may be necessary sometimes. Keep an eye on how well the company you work for is doing, if sales go down, get cautious. If RedHat is trying to cut costs be leery of mentoring anyone to the extent they could replace you because reducing the workforce is the easiest way to cut costs and having you train someone could be a sneaky way to keep the skills but lower the salaries. Mentor new hires to only do a subset of what you do, or better still to do something very different than what you do. If management insists you teach them everything you do, start looking for a new employer.
If you can transfer the entirety of your skills to a junior developer over a few weeks of mentoring you probably deserve to get fired.
Something missing in the comments here is that redhat was not a random SW company or consulting firm like IBM but was hiring open source contributors for their knowledge/experience to ensure the evolution and control of the os stacks that they are using(/selling).
This was their core asset, the total experience of its engineers.
Now, if you go on the way to take any unexperienced and cheap random dude to reduce costs. With the promise that it will have a hard time becoming senior for cost reasons. To do whatever software a ibm-like management decide. Then, Redhat as we know it will be a ghost of itself in a few years!
This was their core asset, the total experience of its engineers.
Now, if you go on the way to take any unexperienced and cheap random dude to reduce costs. With the promise that it will have a hard time becoming senior for cost reasons. To do whatever software a ibm-like management decide. Then, Redhat as we know it will be a ghost of itself in a few years!
I wouldn't believe the "many engineers at senior level" part without further evidence. When I was there for eight years, there was a consistent pattern of people being stuck below their proper level because any given manager could only promote so many per year and people had to "wait their turn" no matter how much they deserved the change. That was all before the IBM acquisition, but not by that much and even in context I'd be surprised if things had changed that drastically.
Lunduke is part of the anti-systemd cult. It's important to understand this article is not about the trade-offs of different hiring strategies at all - it's a hit piece on Red Hat.
There's still anti-systemd people out there? Why?
Does anyone know what type of development they do at redhat?
I assume you need really good people for things like kernel development but IBM-style enterprise development is a different story.
I assume you need really good people for things like kernel development but IBM-style enterprise development is a different story.
I know people in RH IT and even they aren't doing IBM-style enterprise development. There's little if any respect for that inside RH.
Theres some info about that on the RH jobs site:
https://www.redhat.com/en/jobs/departments
https://www.redhat.com/en/jobs/departments
Yup, those 10x developers are so good and so valuable that we feel they're not worth their money so we'll dispense with their services. As people knowing that we're replacing them with less-experienced developers or even newbies doesn't impact the bottom line, I guess we should not have hired them in the first place...
Personal ancedata but Avery one I knew who was maintaining a Red Hat fleet switched to CentOS or others.
So you're telling me there's a chance...
I graduated college in 2007, into the recession.
Back then, no one wanted to take a chance on someone who was inexperienced, which created an ugly dynamic where recent grads would be out of work for long periods of time, and it only got worse as time went on in unemployment, making for a negative feedback loop. A grad with 6 months to a year without post graduate experience was basically damaged goods.
At the same time, the millennial generation was in the news a lot, where the media were saying we were entitled, selfish, etc etc.
So it was like you were unlucky and disliked at the same time.
One time, I had some feedback that I thought would have helped the team I was working with - I was dismissed and told by my baby boomer boss that I needed to "pay my dues" before acting like I knew what I was doing. I had 6 years of experience at the time, though about 9 months at that company (though he had less than a year at the company). There were a couple of instances like that.
I think since the recession, the generations that were hiring after the recession (baby boomers and generation x) have been been conditioned to not trust less experienced (read: younger) people, and that attitude never changed. That's why you see articles like this - author seems to be from gen-x and is worried about pay for senior engineers in his cohort, but I am happy that less-experienced (younger) people will get the opportunity to work at a company like red hat.
Nowadays, it doesn't feel like companies want to take the on the "risk" or inconvenience of training inexperienced people, excluding Bay Area tech companies where the average age is in the 20s. Interestingly, those are the companies that are doing really well right now.
This feels like a dynamic unique to this time - legacy orgs are basically content with getting older [1]. There's a sense pessimism too nowadays, that it makes me wonder if the generations older than mine are afraid of the younger generation taking their jobs and / or driving down wages.
[1] https://twitter.com/uberfacts/status/1348723228924108808
Back then, no one wanted to take a chance on someone who was inexperienced, which created an ugly dynamic where recent grads would be out of work for long periods of time, and it only got worse as time went on in unemployment, making for a negative feedback loop. A grad with 6 months to a year without post graduate experience was basically damaged goods.
At the same time, the millennial generation was in the news a lot, where the media were saying we were entitled, selfish, etc etc.
So it was like you were unlucky and disliked at the same time.
One time, I had some feedback that I thought would have helped the team I was working with - I was dismissed and told by my baby boomer boss that I needed to "pay my dues" before acting like I knew what I was doing. I had 6 years of experience at the time, though about 9 months at that company (though he had less than a year at the company). There were a couple of instances like that.
I think since the recession, the generations that were hiring after the recession (baby boomers and generation x) have been been conditioned to not trust less experienced (read: younger) people, and that attitude never changed. That's why you see articles like this - author seems to be from gen-x and is worried about pay for senior engineers in his cohort, but I am happy that less-experienced (younger) people will get the opportunity to work at a company like red hat.
Nowadays, it doesn't feel like companies want to take the on the "risk" or inconvenience of training inexperienced people, excluding Bay Area tech companies where the average age is in the 20s. Interestingly, those are the companies that are doing really well right now.
This feels like a dynamic unique to this time - legacy orgs are basically content with getting older [1]. There's a sense pessimism too nowadays, that it makes me wonder if the generations older than mine are afraid of the younger generation taking their jobs and / or driving down wages.
[1] https://twitter.com/uberfacts/status/1348723228924108808
Companies like IBM can survive by doing tricks with mergers and acquisitions.
In particular IBM seems to survive by reputation mining to sell consulting services. As their original reputation is pretty mined out, they occasionally need to buy new blood like Red Hat.
Lots of businesses and industries are doing this. Credentials are rapidly losing value.
What if we never saw the memo. How would we have known?
please submit the original source if an article primarily quotes what another outlet reported.