In this series of articles I want to discuss some topics for software development leaders around motivation, innovation, and the different leadership styles you can use to support your team. When you are leading a team of software developers, or indeed any knowledge workers, you need to keep them motivated to continue getting the best out of them. There are many ways to do this, and they don’t always involve paying people more money. In the rest of these articles I am going to discuss some thoughts on motivating developers.
It is a really good article and I want to pick up on a few points and discuss them further. There are many different ways to get someone motivated, but by far the biggest for a knowledge worker is to give them meaningful and challenging work.
A little while ago I wrote an article about training for software developers. This article focused mainly on developers increasing their technical knowledge. In this article I want to expand on that and talk about a developer’s skills matrix that we use in my department. The skills matrix discussed here was originally put in place by our old development manager, Duncan, with input initially by me and the other leads at the time. Once we had the base matrix in place we gave the developers an opportunity to contribute to it.
In our company we have 3 levels of developer under the team leaders. They are Entry Level Developers, Developers and Senior Developers. The skills matrix is split into 3 sections, Knowledge, Skill and Behavior.
Knowledge is the information we expect developers at each level to know as a minimum.
Skills are what we expect a developer to be able to do, i.e. the doing.
Behavior represents the habits of a developer.
Let’s use an example of source control. For knowledge we would expect someone to have a good understanding of source control concepts. Why do we use source control? What types of source control system are out there? What is branching and merging etc? For Skills we expect someone to be able to use their tools. In our case this is Microsoft’s Team Foundation Server. Can they check in code? Can they merge conflicts? Can they go back to previous revisions? Can they create branches? Behavior is more about their day to day usage. Do they regularly check in code as a habit? Do they keep an eye on builds? Do they fix broken builds? Are they branching on release?