I was reading a good article the other day in INC magazine by Aaron Skonnard, who is the CEO of Pluralsight, who I have recently started Freelancing for. The article is called How to Build a Kick-Ass Exec Team, and talks about 8 leadership traits company heads / CEOs can use to create a good working culture within their organisations.
The article is aimed at people who run their own companies, but I thought the leadership traits Aaron talks about also apply to other leaders and managers lower in an organisation. From my point of view I am thinking as a Development Manager running a software team in a healthcare organisation.
In this article I want to covers the original 8 leadership traits and say how they apply to managers and leaders of a software team in an organisation, as I feel there is a direct correlation. I recommend reading Aaron’s original article first.
Leaders Help Their Teams
The team I leade, I try to run agile using Scrum. I say, try, because the project I am currently running is part of a larger program of work that is very much waterfall. We are one of the donor projects in a larger agile transformation plan. As part of the running of this team I want to avoid being the guy at the top dishing out orders or even worse, Micro Managing. I believe a team should be self organising in their workload with inputs from the product owners and business who guide our direction. My role is very much about removing barriers and blockers that get in their way so they can concentrate on doing what they do best, developing software. I feel it is much better to be a servant leader as opposed to a more traditional autocratic leader who controls a strict hierarchy whilst leading from the top.
Leaders act as Coach and Counsel, not Judge
Things go wrong on a project and in a team. It is an inevitable fact of life. A team leader needs to understand the problems and help the team overcome them and more importantly learn from the problem so it doesn’t happen again. If it is a code issue then you can guard against it with unit / integration tests. If it is a process issue, then you need to update internal processes. What you have to avoid is turning an issue into a finger pointing exercise. If there is a problem then the team will probably be stressed enough trying to deal with it without having someone playing a blame game.
If it is a persistent issue with a team member then you need to have a coaching conversation with them, or if more severe a performance conversation, but this is really in an extreme case, you should see your role as helping the team overcome problems.
Leaders Focus on Intrinsic Motivation
Good software developers have a thirst for learning an developing their skills. To motivate your team you need to understand this and make sure there are opportunities for your team to develop and grow whilst still delivering what they have been tasked to deliver. There are a number of things you can do. You can make great training resources available to your team. I would highly recommend offering pluralsight licenses (I may seem a little biased here as I am now a new Pluralsight author, but I was a Pluralsight customer for 3 years before becoming an author), and a safari books license.
These resources are fantastic for self directed study. I firmly believe developers learn best when given self paced training resources and time to learn by tinkering. Personally I don’t see the value in classroom courses for learning programming subjects, they are expensive and cumbersome. They are ideal for personal skills development though, just not technical courses imho.
Another great motivator is group study. Why not organise lunch and learn talks where people take it in turn to talk about something they are interested in. It doesn’t even have to be relevant to your project. Another great technique is a coding Dojo where you work on a group programming exercise to learn new skills. This way everyone can learn off of each other. Which is great because people always have different ways of solving a problem.
What I don’t think are good motivators are pay rewards and bonuses. Sure, everyone should be paid a fair rate or their work. But if a developer comes to you and thinks a pay rise will motivate them, I would seriously think about the reasons first. An incremental pay rise may motivate for a couple of months, but then the extra pay just feels normal. Then what? Demotivated again? Very likely. You should treat this on a case by case basis though as you may have someone who is paid much lower than they should be so their concerns may be genuine. You will need to assess their performance and then benchmark them appropriately.
Leaders Give Autonomy
As I mentioned previously an effective team, especially in an agile environment should be allowed to be self directing and the manager helps guide them through to delivery. The last thing you want to do is be a micro manager. This is very demotivating and tends to breed a culture of distrust with your directs. Trust your teams judgement. You have employed them because they are experts in their area. I have found that a good self directing team is formed of people with different personality types, from nit picky details people, creative innovators, completer finishers etc. By having a good mix of people you can pretty much guarantee that any problem, task or issue will be tackled from multiple perspectives. You may need to step into make decisions and priority calls, but this will be on the information provided by your team. If you get this right, you should have a good autonomous and self directed team.
Leaders Develop People Through Education
Above, when I discussed intrinsic motivation I talked about how education is important to good developers. This point, in my mind, is so important I feel I need to mention it again. If you give your developers access to good training resources like Pluralsight and Safari Books and also run workshops, lunch and learns and Programming Dojo’s you will have a pretty motivated development team. Developers love learning new technology and development tricks. It is even better if they can learn and discuss it between themselves on a team. The cost of getting your team Pluralsight and Safari Books is marginal compared to that of sending people on classroom based training courses.
I must add at this point that I mention Pluralsight and Safari Books mainly as they have been my online learning resources for over 3 years, but you are not limited to these, there are other options too, like Learn Dev Now.
Leaders Hire People They can Learn From
This one is for the Manager / Leader. As a person running a team it is great when you learn from your developers. From my own point of view, I am not really a web developer, my enterprise .NET background has been more with WCF web services and high availability service architectures, but my team is building a pretty advanced internal website that uses MVC 5, AngularJS and Foundation CSS. I have been learning a lot from them about modern web development, and whilst it has not been a discipline that I have been that interested in before, I have started playing around with it a lot more based on what my team has been showing me. I have also been learning lots about the healthcare and clinical domains from my team as although I am the team lead, this is the first time I have worked in healthcare.
So the moral here is hire smart people who you can learn from. Don’t be afraid to hire people smarter than you. You should actively seek them out.
Leaders Drive out Fear
Aaron sums this one up perfectly in his original article, so I am going to quote him.
Employees can’t act like A-players if they spend the day watching their backs. Kick-ass leaders take the time to imagine themselves in their team members’ shoes on a regular basis, and then seek to eliminate their team’s sources of fear. Fear dissipates through team empowerment.
As a manager of a software team, you need to remove any barriers that will cause your team to worry about anything other than the job at hand. This is why I say above that it is important to work with the team on problem instead of looking for who to blame. Another particularly toxic thing for a team is corporate politics and rumours. Nothing can be more destructive than the rumour mill, especially if the rumours are about restructuring and job losses. The best approach is to get all the facts from the source and be transparent with your team (as best you can without infringing any company information that is not to be divulged as that will land you in hot water.
Leaders Model Company Values
In the original article Aaron states that leaders should lead by example instead of just talking the walk, and how this will result in a higher performing team. The same is true with your development teams. I am not saying you should grab the keyboard and start hammering out lots of code as that is what you hire developers for, but by portraying a professional attitude and really getting involved with your team, their problems and their successes then you will end up with a high performing team with trust that flows both ways. Allowing and encouraging your team to learn and research problems properly will also play into this as-well as your team will feel as though they are allowed to do a good job.
I am pleased I wrote this article. Aaron’s original article was aimed at company heads and people generally very high up in an organisation, but it has been an interesting exercise mapping the original 8 points to someone who has to manage and lead a software development team as there are definite parallels between the 2 worlds. I recommend, if you are a manager, to write these 8 leadership trait headings down and post them on the wall near you computer so you can constantly refer to them when things get tough.