Figure 1: Maslow's Hierarchy of Needs
There are plenty of critics for Maslow’s hypothesis, but this is largely due to the difficulty in getting any two people to agree on motivational theory and further to that, social sciences are impossible to prove definitively. All of which is completely understandable given the variables in all of our lives from personal to professional successes and difficulties.
Much of the issue taken with Maslow is the lack of complexity alongside the absence of social interaction and collaboration which, when considered in our current age of social media and collaboration tools such as Slack, means we need to dig a little deeper.
Although he didn’t acknowledge it at the time, American psychologist Frederick Herzberg hit the jackpot way back in 1964 for our peek at motivation by basing his two-factor theory (sometimes known as Motivation-Hygiene Theory) research towards engineers. Whilst this is often cited as a criticism of the theory, and we should be conscious of potential confirmation-bias, it applies effectively in our industry.
Herzberg argued that not only did employees require direct Motivators (e.g. recognition, responsibility, personal growth) to be satisfied, but further that Hygiene factors (e.g. salary, working conditions, co-worker relations) are implicitly likely only to demotivate, i.e. your salary, amongst other things, is not likely to provide motivation, but is implicit in demotivating you should you deem it insufficient.
Figure 2: Herzberg's Two-Factor Theory
That last point is understandably contentious and doesn’t fit all job roles. If, for example, you are a salesperson whose salary is part-derived from commission, clearly Pay is going to be a factor in your implicit motivation. However, as eluded to earlier, for our purposes the basis of Herzberg’s research fits quite nicely. It is also absurd to assume people in engineering roles don’t need to be adequately compensated for their highly skilled input, but it certainly isn’t the be all and end all of what makes us tick.
Towards the ticking sound
Anyone who has been around an engineering project that has gone well (and possibly even on time!) will attest to the positive feel-good environment and the immediate uplift in further efforts required from the team for the next phase. The trend towards Agile and DevOps practises leverages heavily on the proposals of Herzberg by encouraging self-organising teams that are accountable within themselves above all else, and Herzberg got there many years earlier.
Experience also shows us that teams which get their cohesion and interoperability right outperform other teams. Experiments of splitting a working team to try and create multiple effective teams often fail, all supporting the two-factor approach.
In the above, we’ve started to answer our first question, that of what can inspire our teams to achieve their best. Moving away from autocratic management, in particular micro-management, is a great starting point.
Whilst great employees are always looking to self-improve, management have a huge role to play in allowing the best built-in traits of teams to flourish; leadership is largely about assisting everyone to be a little bit better. At the core of successful testing are great engineers with a focus on quality.
Whether that engineer is a developer looking at his own code, a specialist test engineer or a team running true in a truly DevOps continuous release cycle, that motivation to provide the best and be accountable (and duly rewarded) is key. Agile, with its end-of-sprint celebrations and demonstrations, allow a great opportunity to see this in action. Often the most conservative team member can be seen to come out of their shell simply based on the appreciation of their peers.
Testers are often considered to take delight in finding a show-stopping defect, even though the potential fallout could result in a delay to the project. This is conjecture however, especially when seen through the eyes of Herzberg again. Rather it is simply pride in doing a job well, and if our hypothesis is to be believed, the great defect provides an amazing source of motivation to keep doing their role effectively.
Again, building a team with a basis of cohesion and trust will mitigate any fallout, since there will be appreciation that everyone in the team needs to be in this together. Those in a position of managing teams therefore need to promote such a culture at all times. Further, in counterpoint, testers need to be considerate to developers when raising and championing defects. Developers are similarly proud and motivated of their work, and testing their efforts can be considered destructive if an honest and open environment is not maintained.
The lines blur even further as development practises evolve. For example, the creation of the SDET (Software Development Engineer in Test) role in recent years shows the blurring of lines between the two activities alongside the desire for progressive automation in development projects. These roles alter the perception and motivations from both sides of the development realm, and alongside the huge potential for either testers with development skills or developers with testing skills, those entering the space require a new challenge to be relevant.
We now move towards the motivation to continually improve ourselves and our processes, not only for personal development, but also to maintain relevance in the business sense. We’ve all heard and probably used some valid reasons, from being tired after work to family commitments and everything in-between.
A work-life balance is essential and modern working practises largely support the endeavour, but we cannot discount that sometimes we all just need to put in some of our own time to keep developing. However, there is definitely space to approach this delicate task within our teams. To not do so would only leave us at risk of becoming irrelevant and send us further down a spiral of motivational loss.
Thus, teams can promote building activities within their structures. Simply having a team which considers all members to be of value will help. In this way the individual strengths of people can be used whilst allowing them to develop skills not yet obtained in a collaborative and conducive environment.
For example, a tester who has some intermediate scripting ability can attempt to transfer that knowledge into another coding language and fix minor bugs, or conversely a developer creating unit tests within their code can peer-review his approach with a tester to ensure a robust approach is taken. Although these seem obvious, experience shows it seldom happens, sometimes due to a lack of willingness from parts of the team or quite simply time constraints.
However, the bigger picture of the effectiveness of the team in the future should be carefully considered against a moveable milestone in the near-term. Occasionally there is even the option of Innovation Days which require the business to carve out some time to ensure their teams are always looking to improve and learn skills.
Even events such as Hackathons, in which people are asked to give up some of their own time and work in a very progressive and free environment towards a common, ambitious goal in a short timeframe, offer a window into allowing a positive frame in which to realise genuine motivation. Teams able to find participants for this type of events inevitably are teams which succeed often.