Leadership – Page 3 – Stephen Haunts { Freelance Trainer and Writer }

Motivating Developers

When I started planning this series, I was mainly going to cover how to get the developers in your team to innovate in a safe and controlled way. Then I came across an article called “What research on happiness and motivation can tell us about finding meaning in our work.” By Edmond Lau.

Motivation – Getting in the Zone

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.

Training for Software Developers : Knowledge, Skills, Behavior

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?