In the previous articles in this series, we discussed how to gather the needs/requirements of the organization and then translate them into measurable goals. We also discussed how to staff the development team and which competencies/experiences to focus on and how they are linked to the goals.
I also touched on the agile principles and Scrum and how to get started with using them in practice. Then, I talked a bit about communication, collaboration, and the importance of getting to know each other. After that, I delved into how you can implement the CI/CD mindset in your team and how it can contribute to keeping the team's deliveries always up-to-date. Finally, I published an article that focused on conflict management and stressful situations, what can be done to prepare for them, and how to handle them in different ways. In this article, I will instead focus on how you can inventory areas of responsibility and competencies in a simple yet effective way.
Inventory of areas of responsibility
The very first focus should be on inventorying the areas of responsibility that are actually on the team's plate. During this process, you can seek help from managers and leadership who can explain what they expect the team to handle and be responsible for. You can also study the documents and web pages that describe the team and provide some clues about its responsibilities.
After this inventory or in parallel with it, you should schedule a brainstorming meeting with the team where everyone is tasked with sharing what they are working on. From big to small tasks, the more information, the better. Do not pass judgment during this exercise; instead, simply note down everything everyone says on a long list that you can share on a large screen for everyone to see. The easiest way is to go around the team so that each person can share everything they can think of. If it's a team of about ten people, this exercise usually takes about an hour and a half. However, if you see that time is running short, I recommend booking another session with the team so that you don't have to rush through the meeting. The opposite also holds true: if you manage to complete it in an hour, that's great. There's no point in sitting longer than necessary.
After the brainstorming meeting, it is time to compile everything that was discussed and refine the list. The purpose of this compilation is to eliminate duplicates, group different tasks within areas of responsibility, and try to achieve a somewhat similar level for all areas and tasks. This is not an easy task, and it can be wise to seek help from a colleague who can assist you with the work. Expect to spend several hours before you are reasonably satisfied with the list. Make sure it becomes as good as possible; spend more time rather than too little time on refining it. Also, remember to align it with the input you received from managers, leadership, and the documentation you used in the first step. In the end, you will have a list of several areas of responsibility with associated tasks within each area. If you believe it's necessary, you can now align this list with managers and leadership, but if it corresponds to their views, this step is unnecessary.
Inventory and identification of competency areas
Once the list is compiled, it is time to align it with the team. Schedule a meeting with the entire team where you can collectively go through all areas of responsibility and competencies. The purpose of the meeting is to finalize the list, identify redundancies or overlapping items, and consider if anything needs to be added. Additionally, the team should come to an agreement on the list and support it. After all, it describes the entire team's commitments.
During the meeting, it is also important for everyone to consider the competencies needed to perform all the tasks within each area of responsibility. These competencies will require further exploration in the future. Similar to the brainstorming meeting for areas of responsibility, you can conduct a similar exercise for the required competencies.
For example, if an area of responsibility is to oversee the further development of a frontend application called "Customer Portal," it may involve tasks that require competencies in areas such as JavaScript, TypeScript, React, HTML, CSS, VS Code, responsive design, and so on. However, it is also important to consider qualities such as creativity, flexibility, proficiency in English, teaching ability, rhetoric, collaboration skills, problem-solving, and more. What I mean is that you should not focus too much on technical competencies but also consider other types of qualities that are valuable for handling a particular area.
Also, keep in mind that some competencies tend to be very general and may be beneficial across all areas of responsibility. Competencies such as collaboration skills, teaching ability, flexibility, curiosity, and others are all examples of skills that can be considered as general and therefore be included in a more overarching area that you can call "Qualities important for the entire team" or something similar, and remove them from each specific area of responsibility.
Distribution of primary and secondary areas of responsibility
Now that we have our areas of responsibility and associated competencies, it's time to focus on the individual level. By that, I mean going through all the areas and assigning them to individual team members. This is done through a combination of individual conversations and team meetings. During the individual conversations, you have an opportunity to gauge the pulse of team members and understand their desires, goals, and ambitions. Most areas of responsibility are usually straightforward to assign since these individuals are already working in those areas. However, there may also be other areas where it's not as clear-cut who should be responsible for what. Also, remember to designate at least one primary responsible person and at least one secondary responsible person for each area.
The primary responsible person is the one who possesses the most knowledge about the area and works on it the most within the team. The secondary responsible person is the one who can step in when the primary responsible person is unavailable, such as during vacations or illness. The secondary responsible person is not as deeply involved in the area as the primary responsible person but can handle simpler recurring tasks that need to be performed. It could involve basic troubleshooting, recurring support queries, or explaining how a system is interconnected and its dependencies on other systems. The secondary responsible person is not expected to engage in strategic matters regarding the system's architecture or other significant decision-making.
Think of the primary and secondary responsible persons as mutually dependent. It is in the primary responsible person's interest to ensure that the secondary responsible person learns as much as possible to avoid being bothered during their time off, for example. It's not very enjoyable to lie on a beach in Spain and still have to deal with support issues that the secondary responsible person cannot handle. Similarly, the secondary responsible person may not appreciate being expected to handle issues they have no idea how to address and being forced to interrupt the primary responsible person's vacation.
By ensuring which individuals in the team have the primary and secondary responsibility and having listed all the competencies, you have made significant progress in clarifying all the work happening within the team. The next step is to dive even deeper and assess the proficiency levels of the different competencies within the team.
