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?
For the developer, this matrix makes a good way to track their progress in their role. For a manager, it makes a useful tool for justifying promotions to the next level. If a developer wants to go from Entry level to Developer level we would expect them to have all the Knowledge, Skill and Behavior attributes from the Entry Level Developer sheet and maybe a quarter of the Developer sheet. This helps to demonstrate that the person in question is operating at their new level already at the time of promotion.
Using a matrix like this makes the promotion process fairer. It is a useful tool to be used by both a member of staff and their management. This doesn’t replace the normal appraisal process though. You should still be setting objectives for your staff and appraising them in line with your company’s staff development process but the matrix is another tool you can use to compliment the process.
Each level of the matrix also has a standard reading list. We don’t force developers to read these books, but we recommend it. They are standard industry texts that we feel match to each level of the skills matrix.
Measuring an Entry Level Developer
The first level we have in our development matrix is for an entry level developer. Here the focus is on basic knowledge, skills, and behavior for entry into the department. Here for a developer’s knowledge we are focusing on understanding the basics of source control including branching and merging, basic object oriented design skills, basic resources for self-development, business knowledge and code modelling and design.
For an entry levels skills we build up on the knowledge section. The entry level should be able to check code in and out of TFS and be able to do simple branch management. Work with existing code, debug code to resolve defects, and basic error handling and logging. The behavior section covers checking in code frequently, keeping code clean and tidy so it can be reviewed at any time, keeping builds running, self-develops regularly and writes basic unit tests in a test first style (this is a practice we actively encourage).
Once an entry level has started to master all these points they can start tackling some from the next level of Developer. Once they start doing these you can think about putting them forward for promotion if they are also succeeding on their projects and objectives.
Measuring a Mid-Level Developer
The Developer section of the skills matrix builds on from the Entry Level section. Under Knowledge we expect a developer to understand aspects of good application design, know more patterns for covering code in unit tests, have a basic knowledge of security (authentication and authorisation) and know what constitutes poorly written code.
Under Skills, we expect them to be fully conversant in branching and merging, advanced debugging skills, Object Oriented design and design patterns, conducting code reviews, configuring the build and continuous integration pipeline, advanced error handling.
For behavior section covers creating and maintaining projects in existing projects and code organisation, test first development as a habit, designing for test-ability, using visual studio code quality metrics to assess the quality of code, building their own technical library, and is the build owner for at least one project. This ownership also constitutes accountability.
Once a developer has started to master all these points they can start tackling some from the next level of Senior Developer. Once they start doing these you can think about putting them forward for promotion if they are also succeeding on their projects and objectives.
Measuring a Senior Developer
The Senior Developer section builds upon the Developer section of the matrix but starts to add more emphasis on architectural awareness, people skills and communication. The Knowledge section covers best practices of application design, an understanding of new and future technologies on the horizon, awareness of architectural methods and patterns, presents different architectural options and knows their pros and cons, and more effective use of modelling tools to present to technical and non-technical audiences.
The skills section emphasizes reviewing code, authorizing releases alongside QA, creating development plans for lower grade developers, being able to select reference architectures, communicating with technical and non-technical audiences, identifying performance problems using profilers, and coaching/mentoring skills for other developers.
For Behavior we have more around branching and merging policies, solution structure design, advanced debugging, patterns, evaluating trade-offs in design options, re-factoring to patterns, directing more juniors team members, influencing people, mentoring and coaching.
As you can see the further up the developer ladder you go, the more people skills you are required to practice.
In this article I have described a system we use at my company for guiding developers through the ranks from entry lever, to standard developer and through to senior developer. This tool is useful on many levels:
- It sets the expectations to the development staff for where they need to be at each position.
- It helps guide the developers progression by giving them a set of criteria to mark them self against.
- It helps a manager, as part of the appraisal process, gauge whether a developer is ready to progress to the next level.
The specific examples provided in this article are written specifically for our teams at the company I work at. These may not apply to everyone, but it should give you an idea of how to structure a skills matrix for your own needs. Of course, this doesn’t just have to be used for software developers. It can be used for any type of position, be it QA, Business Analysts, Project Management etc. It is worth giving this a try and fitting it into your department. It is important that once you and your management team have done an initial draft that you give the recipients an opportunity to feed into the process and help develop the matrix. This isn’t a onetime exercise; you should treat it as a living document and amend it for the start of each review period. By getting your teams to feed into the document it makes it feel less like management dictation by letting people get involved.