"In the years immediately following the dot-com meltdown, there was more tech labor than there were tech jobs. That didn’t last long. By 2005, the tech economy had bounced back on its own. After that, the emergence of mobile (a new and lucrative category of tech) plus low interest rate policy by central banks fueled demand for tech. Before the first decade of the century was out, “tech labor scarcity” became an accepted norm."
I'll just add if you lived through that time it did NOT feel like a short amount of time. It felt like a really, reallllly lonnng time.
Yep! And even if you did manage to have a decent job, the effort of keeping it led to extra long hours and stress. I was entering early career right after the dotcom bust and it was very rough going.
>For years, tech firms were fighting a war for talent. Now they are waging war on talent.
I this this could be better translated into "For years, tech firms were fighting a war on wages. Now they are waging war on talent because good talent costs more.".
>When labor is difficult to replace, management is hostage to labor
Fully true, salaries went up a lot during COVID and management had to do something. So they get rid of people.
This is kind of similar to what IBM did in the early 80s. Programmers at the time could demand and get any wage if they became individual contractors. IBM lobbied Congress and got a law pass making that illegal just for programmers. That law is still on the books. I was just starting to look into that based upon what people at work where telling me, but the law was passed.
People with better memories from that era could expand or correct me :)
>Introduced by Senator Daniel Patrick Moynihan, Section 1706 added a subsection (d) to Section 530 of the Revenue Act of 1978, which removed "safe harbor" exception for independent contractor classification (which at the time avoided payroll taxes) for workers such as engineers, designers, drafters, computer professionals, and "similarly skilled" workers.
This was backed by IBM and lots of programmers had to change their classification. Many people lost income due to it.
>In one report in 2010, Moynihan's initiative was labeled "a favor to IBM."[19] A suicide note by software professional Joseph Stack, who flew his airplane into a building housing IRS offices in February 2010, blamed his problems on many factors, including the Section 1706 change in the tax law while even mentioning Senator Moynihan by name, though no intermediary firm is mentioned, and failure to file a return was admitted.
Correct, but the people I know caught by this lost a decent amount of income. Most of them ended up working for a contracting firm or converted to employees.
Some people I know lost 50% of their pay, it all had to do with taxes.
> Standardizing roles, skills and training makes the individual laborer interchangeable. Every employee can be assessed uniformly against a cohort, where the retention calculus is relative performance versus salary. This takes all uncertainty out of future restructuring decisions
When someone wonders why the company creates BS levels with arbitrary requirements that don't map to the way engineering works - it is because of this reason. They want an easy way to stack rank and restructure in perpetuity.
As an example, even though a lot of engineering work is collaborative aka work together else it won't happen, corporate decision-makers detest thinking about employees like this. They want to think that EVERY individual can be stacked against others at a similar role - and they can just pull the bottom x% for their margins and FCF. And that this will have ZERO impact on the production. They sincerely believe this and consultants make out like bandits peddling this exact model.
If this is still difficult to wrap your head around, imagine a basketball team where every player has a different role and they all work together to achieve the mission. Except the CEO has ordered the HR department to stack rank all the players based on points scored - which obviously is going to be different in different positions. It has also suddenly set up the team to not pass the ball even if passing the ball would yield a better outcome for the team.
This is quite a pessimistic article with some sweeping generalizations across tech… it may be true in some places but I disagree that software engineering is at its core fungible (yet)
> Standardizing roles, skills and training makes the individual laborer interchangeable. Every employee can be assessed uniformly against a cohort, where the retention calculus is relative performance versus salary.
The article frames this as a bad thing, but a shift towards standardizing and commoditizing roles isn't necessarily anti-labor—this is one of the major things that unions do, after all.
A workforce where every employee is a snowflake who falls or prospers based on subjective 'feel' of their superiors is one where divide and conquer tactics work well for employers and one where nepotism thrives and meritocracy is effectively impossible.
If roles are defined and standardized and salary bands are known and predictable, that can actually create an environment that is as much easier for employees to navigate as it is for employers. What starts out to benefit one party can actually level the field for everyone.
Your comment reminded me of Jo Freeman's THE TYRANNY of STRUCTURELESSNESS [1], which uncovers important group dynamics which, I think, are applicable here.
> The article frames this as a bad thing, but a shift towards standardizing and commoditizing roles isn't necessarily anti-labor—this is one of the major things that unions do, after all.
All of this is fine as a theoretical argument where every individual being commodities is doing the exact same job with the exact same level of complexity.
Is software engineering like that or is there a large element of creativity, exploration, and differing complexity? The answer to this question will inform how lazy standardization and commoditization of tech is.
You're assuming that you can't standardize expectations and comp for creative roles. I'm not sure if that's true or not, just pointing out that it's an assumption.
I do know from experience that the existing system where roles are fuzzy and people get promoted based on gut is not fair or effective.
> You're assuming that you can't standardize expectations and comp for creative roles. I'm not sure if that's true or not, just pointing out that it's an assumption.
I am asking you to present a worksheet that describes engineering activities and to explain how they can be standardized. If you can, great. If you present something as broken as FAANG companies, then maybe we don't have a way to standardize yet.
> I do know from experience that the existing system where roles are fuzzy and people get promoted based on gut is not fair or effective.
And this is a problem only because of pyramid org structures. Is a promo-driven culture necessary for tech work?
Very interesting. I'm glad I'm not the only one who thinks that measures like "return to work" and things like that are basically methods of "soft layoffs" where they basically put up a giant filter that they know will ensure a certain percentage of people will have to quit, or will quit for some convenience reason.
This has a good side. Tech companies were taking most of the talented people from other jobs, making it very hard for those fields. I have taught about six people from different jobs how to do software development. Now I hear about software developers moving into construction or other work. In the past, this would have been hard to imagine.
It’ll be weird to see what happens to all these companies that are mandating returning to office during the next round of lockdowns. I imagine a lot of these companies won’t exist by then.
