In this article I would like to dwell on an approach of IT teams structure. It works well on departments consisting of from 20-25 to 60 people, moreover, the results can be reproduced in different teams. Lets look into nuance, responsibility division and teams hierarchy.
In my opinion, the departments should have a strict hierarchy and everyone should be responsible for their own scope of tasks. Here are several steps one should undertake dividing the roles in a team:
Every person in your team should understand what he or she is expected to do along with further responsibility. They should know, who they manage and who they are accountable to. They should also realize how to behave in different situations and who is there to help them with the unscripted issues. In order to achieve the clear understanding of all these, you need to understand completely the reason why you hire an employee and his/her further tasks.
You give people enough freedom and power to complete the tasks you give. If you have a team lead, he/she should be your representative in a team with the full passing and controlling function in terms of processes and rules. This person should be able to conduct their day-to-day duties without your interference (even if you have time to help an employee at the moment). The only way for this team member to come to you is when you both have agreed on that or he/she cannot deal with it by themselves.
You should have regular synchs with your employee – the closer you are with them, the more often you need to work with them. Your task is to grow your -1 and teach them to do the same with their subordinates. I am going to tell you more about synchs in our people management course.
To sum up the most important, the crucial things are the following. You need to explain people their area of responsibility and delegate enough authority to deal with their job effectively.
The roles in this case should be divided not just in accordance with employees’ wish, but with their abilities as well. Do not rely on self-organization, it’s hit and miss game. Thus, you can loose it to chance. Judging from my experience, self-organization is frequently used when a manager does not want (or is not able) to organize a team.
The scheme bellow depicts a generalized scheme of the IT team organizational structure I describe in this article. It’s a conceptual illustration for the best preliminary understanding of an issue. Surely, there are a lot of variations we are going to deal with in real life, but this scheme is the best way to start the discussion.
In order to facilitate the understanding of the scheme, let’s divide the team issues into two categories – tech and organizational. Tech issues include architecture, engineering, technical implementation of complex tasks, employees’ hard-skills development - in other words everything regarding the IT side of the process. Organizational issues include tasks prioritization and division, planning, employees’ soft-skills development, people’s promotion and transferring questions, and so on. This picture shows how each of the questions should be addressed in terms of decision-makers.
The tech team may include developers, DevOps, designers, architectures, technical writers – all people who are part of product creation. Team Lead and Tech Lead are also a part of the team. Further we are going to look into details regarding all roles mentioned in the scheme.
The first you need to arrange is your deputy (even two, ideally). A deputy is a person you can leave the main organizational tasks without any damage to the production process. You need to describe person’s day-to-day area of responsibility, including the times he/she substitutes you. It should be clear which steps should be coordinated with you and which steps are fully up to your deputy. Then you need to delegate a part of your responsibilities for the tasks completion. Moreover, you need to make it official so your team and all the people involved understand that you actually have a deputy (and his/her scope of responsibilities). Only in this case your deputy can work effectively and independently. Another crucial moment is your relationships with your deputy. Your deputy has to realize you have the last word and act in accordance with it during all the meetings. However, you should respect and listen to your deputy (otherwise why do you even need a deputy?). In case of ambiguous situations you need to decide on it together first and then transmit the position to the team. In your collaboration you should not to undermine the authority of each other. If the interaction is quite clear in “boss-employee” relationship, the authority of yor deputy should never be undermined (because you want the team to respect and listen to your deputy). Your deputy should be a lot like you in terms of values when talking about goals orientation and definition of quality. However, it’s okay when he/she is a bit different in ways of achieving things or of different vision. Surely the compatibility is important, so you can set a common strategy meanwhile your differences are going to compensate each others’ weaknesses.
Later on we need to consider how many competences are united in your team (for example, in developing it’s frontend, backend, data science and so on). After this you need to find a leader of each competence. Their job and role titles are not of high importance, however, it’s better you find people out of tech teams (and a grade upper). Those people are going to help you in high-profile recruitment, project architecture, tech decision-making and employees’ upbringing (and sometimes even soft-skills development). The search routine is the same – you need to find a person with similar views who is going to complete you. If you think you can be a competence leader yourself, good for you. Nonetheless, I would suggest you find a person for this position. You will not be able to focus on this when the whole team is growing, along with the amount of your other tasks. And again, don’t forget to set an area of responsibilities and reach out to competence leaders daily.
The next step of building up your department is appointing a Team Lead. Those are the people who are going to help you with organizational tasks, business department demands and are going to monitor meeting all the agreements and following the rules. There can be only one Team Lead in your team, no matter how many competences there are. You don’t need to look for a know-it-all/can-do-it-all – that is competence leader or Tech Lead’s task. Team Lead should be a leader, perfect planner and attentive to the team and general processes. Ideally, Team Leads are masterminds of all the previous agreements and arrangements. If they can’t deal with a situation, they should be able to tell you about it. You should remember that this role is although inferior to you but still a leading one. It should be also clear to the rest of the team. Lower productivity in code-writing processes should be expected (and not be perceived as an issue). Otherwise you are going to cause an enormous overtime or team leading responsibilities annihilation. The rules and approaches for such employees should be fully scripted, as their position is extremely important. Unfortunately, you won’t be able to be constantly in touch with them. Try to schedule regular one-to-ones at least weekly.
The last element of our department puzzle is Tech Leads. You will also need to hold your hand on pulse constantly with them. Tech Leads are technically skilled employees who, unlike the competence leaders, can be a part of the team. They normally do the cornerstone of the job by themselves or take part in engineering of the solution. It’s important you don’t give them all the crucial parts of the project, as you also need to grow other specialists in your team. You need to “feel” your Tech Lead, know their worries and state of mind. Thus I would suggest scheduling regular meeting biweekly.
Now the core of your team is established. We have discussed the kernel, which will pull up the rest of the team. This kernel is the most important part of the department. You will need to work hard not to loose those employees. Moreover, you can motivate the rest of the team by promising them one of these positions (however, the external current of employees can also be useful).
The next steps of IT team building should fulfill the criteria below:
your definition of minimal acceptance criteria toward the candidates;
competence leader requirements;
compatibility with you Team Lead and the rest of the team you are going to allocate a person.
You can’t be far from your team in this case. You should open to your employees, encourage their wish to talk to you directly even if you can’t do it at the moment, try not to forget to talk to your employee later, otherwise you risk being neglected by them. The amount of synchs with your employees depends on the number of team members. However, I would suggest regular personal talks at least once a quarter. We are going to look into the people management in details later in our course.
If you have any questions or comments, you can use the feedback form to contact us: