How Psychological Wellbeing Impacts High-Performing Engineering Teams

Diana and Constantine Grishel are Agile Delivery Coordinators at Godel Technologies. They are both certified SCRUM experts and have years of management experience, which has equipped them with a perspective on software engineering teams from a psychological perspective. In their respective careers, they have experienced many circumstances of how psychological wellbeing impacts software engineering teams. From this, they have identified three central categories occurring at an individual level that inhibit team performance.

Fear of Failure

Bugs are an unavoidable part of software engineering. Things break in production, unexpected errors happen and often catastrophe occurs at the worst possible time, usually Christmas morning or the day before your holiday. On another level, there can be a lot of pressure on software engineers to know everything about their domain. If a problem has no clear answer, it’s on the engineer’s shoulders to work it out. Fear of being perceived as inadequate or unprofessional by peers leads to engineers going above and beyond their formal duties to prove themselves as experts.

Directly, this seems like a positive trait. Dedication to the role, a strong work ethic and a clear passion for success? These are all desirable qualities in any employee. It’s not these characteristics, but the motivators behind them, that need to be closely scrutinised. One software engineer should not shoulder more responsibilities than they can reasonably handle – this circumstance will inevitably lead to human error (bad for business) and burnout (bad for the individual). If their reason for doing this is a fear of asking for help since they don’t want to be seen as incapable, then there is a wider problem in collaboration.

Asking for help should be encouraged, not inhibited. Perceiving this as a weakness stifles knowledge transfer and learning opportunities, which limits the whole team. It also slows things down – a team can deliver more quickly than an individual if they are working together properly. SCRUM methodology counteracts this issue by encouraging constructive feedback and prioritising communication. Each member of a SCRUM team is responsible for recognising the workload of their teammates, and each must share their tasks in a specific manner regularly.

It takes trust, first and foremost, to truly collaborate as a team. Making trust and communication an open topic of discussion is a great way to encourage this. For example: running team sessions and workshops that directly tackles these topics shows that they are concepts to strive for, not just a “given” that we should assume is working. This can open teams up to sharing emotions – something which can also be perceived as a failing by engineers that hold themselves to high standards. Expressing frustration, fear, embarrassment and other feelings to the team in a safe environment promotes confidence that their experience within the company matters, which is what builds a great team culture.

Isolation

Business goals are often decided by the company’s leadership team and filtered down to employees through translation into specific tasks. A missing link can easily occur when this translation eliminates the original message behind the goal. For example, if a business needs to enter a new market and achieve 20% market share by next year, it might come down to the software engineering team building a new feature for this market. Without sharing the true potential impact of this feature upon the business and the market, does the team know the value of their work?

For smaller companies it can be easier to achieve this shared vision, but since companies usually aim to grow, layers of management can quickly cloud vision and goals. Add in the newer challenge of remote working, and software engineering teams can fall into the trap of isolation from the wider company.

This can be seriously demotivating – it’s hard for a software engineer to find passion in work that they can’t see the value of. This is a symptom of a wider issue in the team – if just one employee feels detached from the vision of the company, it is likely they will affect the mood of their co-workers. The natural outcome of this is attrition – if a software engineer doesn’t feel “bought into” their work then they are likely to leave for a more exciting opportunity.

Counteracting isolation starts at the top. The people responsible for setting the company direction are also responsible for making sure each employee understands it and is on board with getting there. Communication is of course central to this – it should always be made clear what direction the software engineering team needs to head toward and what the impact of their work is. 

In the example we used earlier, once the software engineers deliver that new feature which helps the company achieve market share, it is critical that this is recognised, and the team members involved are rewarded for their achievement. This makes it clear that their work is important, not just to the technology function, but the whole company.

Inside the team, empathy is the not-so-secret ingredient to collaboration. Software engineering teams are made up of very different roles, but each member should seek to understand that they aren’t all that different – they are working toward one vision. Conversations need to be had on this. For example, learning sessions where team members can share their challenges with one another in both tech and non-tech roles, to get a broad scope of perspectives and new solutions. It shows that we are never really alone in our problems when it comes to software engineering and encourages empathy for different jobs.

Burnout

We have talked about understanding the company’s direction as important for software team wellbeing, but just as important is how the team gets there. Making great advances in software engineering requires a high bar of knowledge and out-of-the-box thinking. This doesn’t come naturally – especially innovation, we all know the feeling of trying to capture new ideas without result. Burnout is an issue that workers in many corporate fields can experience. It combines fear of failure, isolation and external factors in the individual’s life, and simply leads to a crash in productivity and quality.

Despite over a year of remote work for many software engineers, we still need to consider its impact upon mental health. At home, separation between work and life is reduced. It is simply too easy to overwork – the line between a “flow” of productivity going into late nights and imbalanced responsibilities adding too many hours in front of the desktop is too fine. Furthermore, company pressures are on the rise – with the fragile economy and increasing competition, achieving results is very high-stakes.

Avoiding burnout cannot be achieved simply by getting all the work done. In software engineering, there’s always “one more thing” on the board. Instead, the first step is setting clear boundaries between work and life. It is something we all know as important, but do we actively prioritise it enough? Taking real, complete breaks is the other side of the coin of productivity – no one can work relentlessly without rest.

At a management level burnout levels should be monitored in teams – again, it is common for managers to become caught up in delivery without considering what goes into that – productivity. Building relationships with each team member and understanding the signs of when someone needs a change of pace is essential.

Further, productivity itself must be rewarded. Without recognition for individual achievement, it will quickly seem that there is no value in achievement at all. There are countless ways to do this, from perks to a simple “well done”, but the overall message is that efforts and contributions toward adding value to the company should be rewarded.

Conclusion

Both successes and failures in software engineering teams need to be recognised appropriately. For managers, this requires going from viewing software engineering teams as a resource, to as humans with individual needs. A good approach to this can be summarised as agile management practices, with a constant emphasis on communication at every possible level and instance.