For those of you who don’t know the name Brian Clough, let me introduce him: Clough was the manager of the football team I support – Nottingham Forest – from 1975 to 1993. He guided Forest to the League Championship for the first and only time in their history in 1978. He then led them to the pinnacle of European football, as they won and subsequently retained the European Cup in 1979 and 1980. These achievements, with a relatively unsuccessful club from a provincial city, are rated amongst the greatest in English football history.
“Rome wasn’t built in a day. But I wasn’t on that particular job” , Brian Clough
Clough was charismatic, outspoken, often controversial and is considered one of the great managers of the game. He could be an autocrat and a bully. Despite the title of this post, his management techniques would probably not be well suited to the software development industry. However, I believe Clough’s beliefs do offer some inspiration for team leaders. So, here are the five things Brian Clough taught us about leading software development teams.
1. It’s all about the people
“Players lose you games, not tactics. There’s so much crap talked about tactics by people who barely know how to win at dominoes”, Brian Clough
Clough helped shaped the careers of some of the most important figures in the English game – such as Peter Shilton, Stuart Pearce, Roy Keane and Martin O’Neill. His concern for these ‘workers’ stemmed from a deep belief that it was his staff that delivered him the results, not insightful tactics or the manager’s pitch side gesticulations. Professor Stefan Szymanski, of the Cass Business School, wrote of Clough on the bbc website that his “focus was on the needs of his players. These were his frontline staff – they’re the ones under the pressure, they’re the ones who deliver, so you need to meet their needs whatever it takes”. It’s this focus on his ‘people’ that software team leaders should emulate.
Team leaders should focus on the needs and well-being of team members before they worry about applying ground-breaking agile processes or introducing whizzy new software tools. If you haven’t already, read Tom DeMarco and Timothy Lister’s excellent book Peopleware: Productive Projects and Teams for further evidence that people should be put first.
2. Teams can be successful and principled
”If God had wanted us to play football in the clouds, he’d have put grass up there”, Clough on the importance of passing to feet
Clough’s achievements didn’t come at the expense of entertainment or integrity. He developed teams that were noted for playing attractive football and for their good sportsmanship. He was consistent throughout his career in his commitment to these principles. He deliberately focussed his players on the style of football they were expected to play and he didn’t step-back from that in times of trouble. His players knew that he would not tolerate them showing the match officials any dissent, so they accepted their decisions – no matter how questionable – and got on with the game. Essentially, his teams had class.
Software development teams are assembled to deliver software – that’s how they get results. Teams should be encouraged if they want to go about doing that in what they consider to be the ‘right way’. This might be focussing on automated testing, the reduction of technical debt or ensuring continuous improvement. Those principles don’t have to go out of the window when the going gets tough. In fact, being in a team that does work you are proud of can help you get through those times.
3. Set clear goals and expectations for your team
“Stand up straight, get your shoulders back and get your hair cut” Clough’s advice for a young John McGovern
Clough set clear goals for his players and his teams. He left them in no doubt that he expected them to play the game in a certain way, for each of them to perform the role assigned to them and to be disciplined. Although his dictatorial approach in enforcing adherence to these directives would make most of us baulk in our work environments, setting clear expectations and targets for teams and team members is something all leaders should be concerned with.
4. Don’t ignore dissenting voices in the team
Interviewer: “How do you react when someone from your playing staff comes and says, ‘boss, I think you’re doing this wrongly’”
Clough: “Well, then I ask him which way he thinks it should be done. We get down to it, and talk about it for 20 minutes and then we decide I was right.”
The above quote from early in his managerial career is probably my favourite from Clough’s extensive vault of soundbites. In addition to showing off his sense of humour, his answer underlines the importance of tackling, not ignoring, dissenting voices in a team. Although the implication of Clough’s comment is that at the end of the fictional conversation he dictates to the player how things should be done, note that he does not say “I’d just tell him to get lost”. Instead, he recognises that he should hear the player out, have a discussion and reach a consensus.
A disagreement in a software development team can be about something as benign as whether or not to fix a low-priority bug, or as caustic as whether retrospective meetings are a valuable use of someone’s time. Team leaders can feel unable or ill-equipped to challenge a strong individual’s dissenting opinion. They may be tempted to sit-back, hoping that they quieten down or that the team’s consensus wins out. However, that kind of procrastination can lead to problems snowballing, a lowering of team morale and divisions forming within the team. For the good of the team, dissenting opinions should be noted and addressed as soon as possible.
5. Be confident
“I wouldn’t say I was the best manager in the business. But I was in the top one”, Brian Clough
Clough was a self proclaimed ‘big head’ and although I wouldn’t recommend calling yourself ‘number 1’ in the business, I think it’s vital that team leaders believe in their ability to do the job. It’s important that they are confident. If they aren’t, it can seep through everything that they do. This can be especially problematic when they are talking to the team as a group. Team members are not going to feel assured about what you are telling them if you clearly aren’t either. So, take some advice from Cloughie, and believe in yourself.