Just because it's always been done that way, doesn't mean it can't be changed.
Personally there is nothing I can do about the way corporates work. There are a lot of people involved and possibly a plethora of reasons for why they do things the way they do - that I can't see right now.
It doesn't mean that I have to always agree with every decision that is made. Just because it's always been done that way, doesn't mean it can't be changed. Right?
I know people working at corporates are doing the best that they can and that things can get pretty messy when a lot of people are involved. Some things end up cumbersome and bloated or go completely overlooked. Here's what I would focus on to make a happier space for developers.
When a developer starts at a corporate, they are going to be overwhelmed. This is guaranteed. It doesn't matter how many years experience they have, they need to learn everything about the business, products and the people from the ground up. This takes a lot of time.
We shouldn't just throw people into the deep end with everything. "Bend a tree while it is still growing."
Give them a solid welcome pack with important HR and company familiarity documents. It should act like a map with a "you are here" in this business.
Access cards, user accounts and all technical requirements need to be available on the start date. Someone joining a company is eager and excited. Idle time is going to be frustrating.
Orientation needs to be ongoing for a few months. One day is too overwhelming in large companies and not everyone is going to retain all that knowledge that is crammed into their minds.
Assign a mentor for the next year so they have a dedicated person to guide and help them along.
Don't assign them to a team straight away. Sure you may desperately need professionals in some teams but this is only going to slow down the delivery and cause unnecessary frustrations within a team.
Instead let them join a team of their choice and pair on bite-sized chunks of work. Perhaps they could be rotated every sprint up to about four sprints. This should be less invasive and give them more exposure to teams, products, people and technology. By pairing, they don't have the pressures of setting up their environments fully but as they have their machines they can start exploring codebases and read up where they can.
After the rotation period is up, let the person choose from a list of priority teams - teams who need developers. Let the team have an informal interview with the candidate to identify a possible fit. Forced placements don't encourage a sense of autonomy within the team and if the person doesn't fit well in the team, everyone is left discouraged.
The customer is very important but without your staff there will be no customer. I would get my managers to focus on keeping their staff happy while the staff can focus on keeping the customers happy.
If someone is frustrated in a team and it cannot be resolved, perhaps they are not suited for the team. If the person needs to be relocated, I'd have a conversation with the team to find out who they think will be better suited for their team.
Market-related salaries pay the person what other companies are willing to pay. What is the person worth to the company? If creative minds are constantly worried about money, quality will suffer and the person will eventually leave the company.
I don't think slapping everyone with fat salaries is the answer but people need to be happy with what they are earning so that they don't look for opportunities elsewhere.
If the pay scale is right money is not an issue. Bonuses are great but if they are driving poor decisions or cannot be met then why do we offer a reward? Value is more important and how it is measured is up to the division and role I guess. Isn't it better to receive a bonus based on the value you add to the company within your role?
Money aside, people want to grow in their craft. Perhaps offering a reward to go to popular conferences local and abroad to upskill and network could be an incentive. Arranging a workshop with "developer celebrities" could be another.
Not only should it be encouraged but allow it to be practiced. Managers can provide guidance and business direction but the product teams as a whole should be able to make decisions. They need to talk to the right people and teams so that everything aligns to the bigger picture.
By have autonomous teams, management can focus on managing and alleviates decision making bottlenecks that can be faced.
Maybe this will all result in failure. Who knows? I've only been at a corporate for two years now and perhaps I am being ambitious or over-looking something. I do feel that there is a mindset from very high up in the corporate chain that needs to be aligned with the advances in the technology space. Whatever that adjustment is, I can still speculate.