Culture. The fact that it doesn't matter what the company says their culture is and that their culture is defined by the behaviors that they do and don't allow in the workplace. Culture can vary from team to team and department to department.
Deadweight. The organization is going to be full of dead weight.
Get ready to feel under-appreciated and under-valued.
We refer to the dead weight as riders. they're just riding along for the journey but they don't actually provide any actual value to the company. At a startup, those are the first people to go during layoffs or during other downturns. At a larger company they can stick around a lot longer.
Can you imagine the echo in one of those things? Plus, for the price of one of those, I'd be tempted to pick up a used storage container and renovate that.
There's no reason to be apologetic. The fact of the matter is that there are two types of employees, those who work and those who have a job. Employees who work are creating value, whereas employees who have a job are trading time for money.
When a company becomes a certain size, it's inevitable that you will hire people looking for a job.
Firing people sucks. Yes, it affects their livelihood, but having warm bodies on your roster affects your business.
The problem with people who have a job is that they affect company culture as they set the tone for acceptable and unacceptable behaviors in the workplace. It spreads like a disease and the effect can cripple those who show up to work.
Sometimes, this can lead to confusion as people who have a job might think, "I was doing what I was told. I don't understand why." Creating value is much more than simply following orders.
I have seen nothing to suggest that the people who have lost their jobs weren't working hard enough or creating enough value. The comment above merely says the jobs they were doing are no longer considered strategically valuable, and that's no fault of their own.
I interpreted it differently, like it was saying "some people are lazy, and you need to get rid of them". If I were one of the people who'd just been made redundant because a layer of management above me changed strategy, I'd find that comment really hurtful.
Many, many years ago I worked at a small company, mostly on a single project for a single client.
Out of the blue, one day the boss summoned me and told me I wasn't delivering enough value so I would be leaving. I knew he was lying (I had the numbers), and it still made me feel terrible.
If someone here is on a similar situation, let me tell you this: if you do your best and yet they tell you "you don't deliver enough value", it is the company's fault, not yours.
Really, just shrug it off and move on. Keep working hard and things will eventually work out.
PS: Four months later they wanted to hire me again, paying 50% more than before. I already had a better job ;)
I'm going to give some blind advice. I've never been laid off nor have I done consulting - I'm not speaking from personal experience here.
No matter which route you decide to go, work on some hard skills. Something. Anything. Whether or not you think you're going to use what you learn, what's important is that you're learning. If you start interviewing, you're going to eventually be asked, "What is something new you have learned?" It would be a great chance to pull out your computer and show them. Even if you land another role as a PM, it's going to be important to be relevant.
On a related note, someone I know was an IT Director. On the side, he started tinkering with Android development. I helped him learn how to use git. Eventually, he was laid off. The skills he learned helped him land a job at a decent sized company that I'm pretty sure you've heard of.
If you have absolutely no experience programming, start with Python. There are three things to learn when programming: 1) language syntax, 2) concepts (conditionals, logic gates, loops, etc.), and 3) how to solve problems.
What makes python a good choice is that you don't have to spend too much overhead learning language syntax in order to implement concepts, and you'll easily be able to keep the learning of those two items separate.
Once you have a strong foundation in concepts, you can much more easily pick up a different language. The biggest downfall there is that if you decide to later learn Ruby or JavaScript, you might approach a solution as, "This is how I would do it in Python." Don't fall into that trap. Learn the features each language provides and how to use them.
