cbillowes/curious-programmer-oxygen

View on GitHub
content/posts/2016/2016-05-11-adjusting-the-corporate-mindset/index.md

Summary

Maintainability
Test Coverage
---
title: "Adjusting the corporate mindset"
cover: "https://picsum.photos/1600/800/?image=983"
date:   2016-05-11 23:16:23 +0200
category: "tech"
tags:
    - Productivity
---

> 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.

## Solid onboarding process

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](/blog/time-is-precious).

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.

## Focus on staff retention

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.

## Adjust the pay scale

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.

## Adjust KPIs

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.

## Encourage autonomy

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.

## My final thoughts

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.