In a growth company, you constantly need to ensure you have the right people in place. Along with the rest of the company, the development department has grown steadily over the past years. But this year we reached a point where we needed to make a change.
Up until now, our CTO Anders Klintelius had been responsible for both the development process and the staff. But to give all areas the attention they required we needed to split responsibilities between several department heads. Me and Samuel Spånberger where given the responsibilities to run both development and staffing process. In other words, the day-to-day operational work of the department. And since we were at the beginning of our fiscal year, it was a good time to review our all our processes.
Inspired by Agilpodden (Swedish), we had got the idea to upgrade the format and become more target-oriented. The overall goals of the dev department should contain both the role the employee currently has or wants to strive for, as well as our goals at the organization and the department. We also wanted salary negotiations to be transparent and based on the overall dev department goals, to get a clearer connection between the employee’s development and how it contributes to the organization and the department's goals.
We believe that people in general and developers in particular are more likely to be driven by personal development and to do something meaningful.
Our first task was to re-define all roles. We needed to review our department and see which roles we were missing and create new roles based on what we think are the most relevant ones, in terms of both responsibility and career paths. After some research, we decided to use parts of "the Spotify model" i.e. guilds for transcending groupings. When the draft was completed, all employees were given the opportunity to share their opinion on their new roles before they were decided.
First and foremost, the cornerstone of any successful team is “there is no I in team”. Therefore, all roles contain a definition addressing the responsibilities of being a true team member. In short, all efforts should be focused on team effort, pushing for continuous improvement, helping remove impediments, adhering to the practices and principles the team has committed to. All roles are based on this, which means that you cannot be a developer or a product owner or any other part of the team, if you don’t accept the responsibilities of being a team member.
The different roles
Having that said, we chose to define 4 different roles. In the long term, we also see that product owners and other people might be part of the dev teams, but for now we chose to focus on the roles of the team members we were given responsibility for:
- Developer/Quality Assistance
- Senior Developer/Quality Assistance
- Lead Developer/Quality Assistance
- Guild Lead
As you may have noticed, we do not make any difference between Developers and Quality Assistance (interested in the “assistance” in Quality Assistance? I recommend you the blog post, “Moving from quality assurance to quality assistance”). This because we do not see any difference in the responsibility of a developer versus QA, according to the motto that quality is nothing to test into a product, it is something that is built into it and should therefore encourage cooperation.
In short, the developer/QA role is about adhering to the software quality standards and principles agreed on by the team, and to ensure all work is thoroughly tested before it is delivered to the customer.
To be a Senior Developer/QA you should first fulfill the responsibilities from being a team member and Developer/QA and also act as an example, be driven to take initiative to solve problems, be an experienced and skilled engineer and therefore also contribute with best practices, knowledge and experience. To be called a senior, one should simply have more experience and knowledge.
From my experience, there is a common desire for people within development to be motivated by being very skilled at their craft. As a career step this often means that you get personnel responsibility and with that many other tasks and administration, you also get less time to work with what you are passionate about, the craft. We therefore chose to define the role of Lead Developer/QA as a person who drives the technical work in the team forward, without having personnel responsibility. As a lead, your role is, in part, about being a role model, for example:
- Understand and convey the importance of principles of good software design
- Understand and be able to talk coherently about practices
- Help the developers of the team to improve their skills by sharing knowledge
- Act as a role model to all the developers on the team by being the person who most closely follows the principles and practices we have committed to
- Act as a role model for continuous learning so that the skill level of the development department continues to improve
- Act as a role model for best practices so that we continue to drive ourselves forward
A guild is a bunch of people with a shared interest, such as for example, front end, Azure or maybe security. These groups are transcending between the different teams and aim to drive the work forward in certain areas, ensuring that we are at the cutting edge and working with similar techniques and methods. The guild lead is supposed to be a field expert who is up to date on the latest trends, responsible to grow the technical expertise of the guild and responsible to ensure all teams work in the same direction.
As mentioned in Samuel’s blog creating a department mission, we came up with the following four cornerstones:
- Customer rating
During the year, we focused on these four areas because we saw them as the key to success. Since the mission is a step towards our platform vision, it’s a great opportunity to execute directly towards the vision through the mission by breaking down the mission further per employee (via the four focus areas). By using your mission in everyday work, you will get a much clearer way towards it when you can visualize what we actually do per employee to reach it, you also get a more vivid vision, and not just a vision that no one remembers.
How to combine all this into performance appraisals
So how do you combine all this into one meeting? A meeting where you together with the employee set clear goals that will then be the basis for the development during the coming year and ultimately salary? In addition to the roles, vision and mission we have produced together with our employees, we also added a section of personal development that could be used for a master thesis.
Finding new goals and linking them
During the meeting, these 4 sections (roles, vision, mission and personal development) were discussed and we set goals together in each area. Each goal was linked to either a role or one of the four priority areas, through this, you could clearly visualize exactly what would be done for each area per employee, team or whole department.
Scoring a goal
It was also intended to define when a goal was achieved. In order to determine whether the employee have achieved their goals, they will prior to the follow-up meeting set a score of 1-5 on how well they have met each goal (a unique score for each goal). The manager will do the same. If the grades differ, you will discuss why the difference has arisen, and try to agree on a grade. It is important to agree on expectations as this also forms the basis for future salary negotiations.
1 - far below expectations
2 - below expectations
3 - as expected
4 - beyond expectations
5 - far beyond expectations
To ensure that you are on track with the plan, you have follow-up occasions three times a year, where we together look at the goals and the progress. In addition to these more formal occasions, one can combine this with ongoing one-on-one meetings to handle more ongoing challenges.
The purpose of this system is to motivate while having clearly and fair set goals on employees in such a way that it benefits both them and at the same time takes us closer to our common company goals.