Author: Brandon Pearman

The views expressed here are mine alone and do not reflect the view of my employer.

There are certain software issues which many medium to large companies face. In my experience all of them lacked very specific elements to their culture, which I argue got them into that situtation. Therefore by actively changing the culture of a company, the teams improve and the software improves.

You want to look at your culture if your software/company suffers from the following:

Elements of an effective culture

Corporations normally erroneously focus on what they want as an end result, for example they may verbalize a culture of accountability, innovation, responsiblity, creativity, leadership, punctuality, etc.

It would be great if every team member had all these qualities but thats not reality. Secondly, trying to force these behaviours will only lead to damage the environment and culture. When these qualities do not naturally emerge, then individuals fakes it/lie/burn out/etc. and you simple don't get the benefits. Also if you do manage to get some of these good qualities from some of your members, if they are too junior you may not get the benefits anyway. For example innovation which comes from junior may not be that beneficial due to inexperience.

In order to create an effective culture, I focus on creating:

Culture is often influenced by leaders. I say this because it is how I would define a leader. A leader may not necessarily have a leadership title at the company but is capable of leading others.

Culture must not be forced on individuals of the team, but instead must be adopted by the leaders promising and committing to serve the team. If the leader is a good leader which is respected, then the rest of the team will follow the lead. As a leader, instead of telling the team what you expect from them, tell them what they should expect from you. There is a number of reasons why this works, but to name a few: law of reciprication, social norms/policing/pressure, the power of transference, conformity, etc.

Over time leaders should cultivate an environment where individuals choose to take up roles and responsibilies and their natural benefical qualities emerge. Chances are that benefical qualities will NOT emerge from every single person, and thats fine. The few which do step will increase effectivness 10 fold and they should be rewarded accordingly. Remember great talent is rare but can be transformative when utilized well.

If a few individuals do not do well under a more open culture then those individuals need to be handled differently, but let the open culture work for everyone else and don't cut it for everyone. NOTE: you might have to consider tighter micro-management for junior teams or individual cases where necessary.

Don’t point fingers

Take responsibility as a team

Learn from mistakes

Allow others to feel comfortable to speak and disagree

Give opportunities to team mates

Share Knowledge

Take action

Give independence

Problems with monitoring individual devs

When a company tracks an individuals performance based on story points or success/failure rate, it has a number of negative side effects.

  1. Reduced team work: An individual does not want to help others because it means that they may not complete their own work.
  2. Reduced knowledge sharing: This model provides no incentive to share knowledge, and inherently causes reduced sharing due to an individual working on tickets in isolation to maximize their own output.
  3. Blaming others and a lack responsibility: Since individuals are being tracked they try to escape blame by blaming others and not taking responsiblity for issues.

It would be better to create a structure which incentivises the team to work together, communicate, self-organize and self-regulate.

  1. Track the teams performance as a whole: How much working software did this TEAM produce?
  2. Address tickets not individuals: Never say "how is YOUR ticket going" rather say "how is THIS ticket going"
  3. Reward the team as a whole: With regards to work done, reward the whole team instead of individuals. This promotes stronger members to help weaker members in order to improve the overall performance. Note: individuals should still be recognized for creating a good environment, innovating, supporting others, taking initiative, etc. (but not for work done)
  4. Punish the team as a whole: The team must take blame as a whole, which prevents any individuals trying to escape the blame. This makes conversations around the issues a lot easier. Note: individuals underperforming within the team should be addressed privately by the teams leadership (not higher company management).

Problems with shared code base and strict rules/processes

When multiple teams work on the same code base or are forced to follow strict processes it has a number of negative effects.

  1. Reduced ownership and responsibility: When a team shares code/processes with other teams, they don't own their work and therefore feel reduced ownership and responsibility.
  2. Less productive: Any changes being made to code that you don't own usually requires agreement or permission from other teams. The added process of having to acquire permissions, perform checks or come to a unanimous agreement slows the team down.
  3. Reduced code quality: People are more likely to fix a small issue when they feel fully responsible for it. With shared code everyone thinks someone else will do it and the code gets messier. With strict rules devs don't get to question the norm causing obvious problems to go unattended for years. A single bug amongst prestine code sticks out but the messier the code gets the less people want to fix that small bug and the more they feel that they can get away with poor code quality.
  4. Reduced innovation: strict rules leads to people not questioning anything which reduces the diversity of thought.
  5. More hacked solutions: When there is red tape devs try to jippo the system to make their lives eaiser and these "hacks" hurt the company. eg strict deployment rules may cause devs to bundled deploys and squeeze functionality where it shouldnt be; Story point monitoring may lead to fake estimations; etc.

It would be better to create a structure where teams have full ownership over their work so that they take pride in it and take full responsiblity for it

  1. Code Seperation: Create as much seperations between the code as possible to give teams more ownership over their code. eg seperate version control repos with micro-services, seperate teams code into different projects/folders.
  2. Clear boundaries: By having clear boundaries between the teams code, teams have clear ownership and responsiblity. eg teams shouldn't share ownership of a single microservice/class/module etc.
  3. Allow teams to manage their own processes: If teams don't have corporate red tape in their way they can do whats best for a given situation. The red tape may be good for certain situations but teams need to be agile in their approach to software, meaning they must be able to do things differently in different situations.
  4. Strong leadership: In order for this to work the team must have strong leaders/devs within the team. This strategy does not work if the team is made up of junior or incompetent devs. But if you stick with strict control just note that strong compentent devs/leaders don't want to work in that environment, which curses the company to forever be stuck in this situation.

Problems with overpowering leaders

Often leaders are in the position they are in because they are good at what they do but not utilizing the talents within the team is a waste.

  1. Reduced innovation: When leaders command every fine detail without listening to others or they punish others with harsh language/tone, then great ideas or average ideas which spark great idea get lost.
  2. Reduced initiative: When team members feel that they can not do anything without approval from their lead they tend to do nothing extra.
  3. Reduced sharing: Often overpowering leaders always take the spot light which prevents others from sharing. ie why would one share when the leader knows everything
  4. Reduced learning: Know it all leaders often promote their team to listen to them instead of going oout and learning.

It would be better if leaders were able to bring out the best of everyone within the team.

  1. Leaders should be learners: If the leader is constantly learning, it creates a good example for the rest of the team. When talking about new things learnt the team gets motivated to join in the conversation with things they have learnt.
  2. Leaders should hear everyone: Leaders which are open to ideas and open to feedback are able to maximize the usuage of the talent within the team. The improves code quality and innovation.
  3. Leaders should create opportunites for others to lead: When team members take the hot seat they grow, they share, they take initiative, they innovate and their overall motivation, pride and happiness increase.
  4. Leaders should manage the tone of conversations: By making everyone feel that there are no consequences or judgement for speaking up then more people will speak up, allowing leaders to increase the diversity of ideas as well as hear the truth of the situation.