Effective Culture For High Performance Teams
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:
- No innovation
- Slow to change/adapt
- Losing staff means huge loss of IP and/or productivity ie single man dependencies
- Little to no participation
- Poor team work and poor communication
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:
- Fail safe culture: Being able to fail means you can innovate and move faster. It is also great for individuals because it reduces stress and forsters a comfortable environment for everyone.
- Open culture: Promotes diverse thought which provides more ideas in the pool of ideas, resulting in improved innovation and quality.
- Learning culture: Keeps everyone sharp and motivated.
- Sharing culture: Maintains team stability by removing any single man dependencies.
- Ownership culture: Effectivness increases when everyone has a leader mentality and are able to make decisions and take initiative.
How to change culture
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
- I will accept my mistakes and never blame you for them
- I will not allow others to blame you for their mistakes
- I do NOT care whos fault it is
Take responsibility as a team
- I will help you fix mistakes/issues even if I was never involved in the first place.
- I will acknowledge the whole team for it's achievements, and I will not steal the glory.
Learn from mistakes
- I will treat failures as a lesson and an opportunity to grow.
- I will not hide my failures and share the lessons with the team.
Allow others to feel comfortable to speak and disagree
- I will always listen to your ideas, thoughts, concerns, opinions.
- I will not attack anyone personally for their input (regardless of what I think of it)
- I will always protect your right to disagree with anyone on anything
- I will not get angry over input I disagree with
- I will always break down input logically and not emotionally.
- I will always give logical rationale reasoning, and not just say “it feels wrong” or "it's an anti-pattern" or "it's hacky".
- I will not take criticism personally because I know that criticism of an idea is not a criticism of me
- I will focus on diversify ideas.
- I will present ideas but will not attach my ego to it.
Give opportunities to team mates
- I will involve everyone and make sure everyone has a chance to be heard
- I will invite others to participate in my work/idea/converstaion
- I will provide opportunities for others to step up and take the lead
- I will review completed work with the team (functionality and code)
- I will give oppotunities for anyone to share their technical knowledge
- I will share my technical knowledge
- I will give feedback on your work, questions, etc.
- I will ask for your feedback on my work
- I will do my best to understand the company goals, our team's goals and each individuals personal goals so that I can take action which help reach those goals
- I will find ways to provide value to the team
- I will recognize an individuals autonomy, and trust they will do what they believe is best within the bounds of the company or team alignment
- I will help enforce the boundaries of the team and of inividuals, so that you have a high degree of control over your own work
- I will offer guidance and vision but not commands
- If consensus can not be reached, I will still commit to the decision made by SME/leader/senior.
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.
- Reduced team work: An individual does not want to help others because it means that they may not complete their own work.
- 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.
- 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.
- Track the teams performance as a whole: How much working software did this TEAM produce?
- Address tickets not individuals: Never say "how is YOUR ticket going" rather say "how is THIS ticket going"
- 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)
- 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.
- 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.
- 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.
- 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.
- Reduced innovation: strict rules leads to people not questioning anything which reduces the diversity of thought.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- Reduced initiative: When team members feel that they can not do anything without approval from their lead they tend to do nothing extra.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.