Team Leads Responsibility
Hello friends.
In this article we will analyze the distribution of responsibility in large teams. Imagine the situation that you are a manager who has from two to N development streams under his command, but all this development is one big application or one big system, and each thread is involved in its own module or its part of the module. It is important that development flows almost do not overlap in functionality, although they may well use the code of neighbors.
So, our task is to create an organizational structure in which you, as a manager, will have the maximum probability of success. Obviously, the success of the project depends not only on the organizational structure. At the same time, the correct org. The structure is one of the components of this success.
Before we plunge into the “who, to whom, what and when” should provide, report and how communication flows will be organized, consider the “classics of the genre” - a very frequent distribution and purpose of areas of responsibility found in a large number of projects. It usually looks like in the figure below (Java and Oracle are taken for example, instead of them there can be absolutely any other technologies):
')
Job titles may, of course, differ.
Sometimes there are very peculiar combinations, like this:
I am sure many of you have come across such structures, and perhaps you are working in one of these right now. Are they all good? Do they perform their function and help us, as managers, to come to the success of the project faster, more efficiently, with the lowest possible cost of resources? If you are not yet a manager, but you plan to become one, you probably also wonder why such structures are ineffective and where exactly the error is.
Consider the examples above.
What is the goal of the project manager, program, department? In addition to making money (depending on the level of the position), the goal is only one - to make the product on time, within the allocated budget and with an agreed amount and level of functionality and quality.
Now look at the diagrams above. Will they make, say, a release, on time and with the necessary amount of functionality, and even at the agreed level of quality? Strongly doubt. Why do I have doubts? There are several reasons.
First of all, there is doubt about the blurred area of ​​responsibility. Tell me, who in the diagrams above is responsible for the timing, scope and quality of the release / project / product? As a result, the one who is at the top is responsible for everything. And this is true. And if lower? Is Team Lead responsible for the release? And at least for one ticket in JIRA (or in any other task tracking system)? Looking at the above two schemes - no, definitely not responding.
The second point in terms of doubt is throwing the ball between team leads. For example, analysts completed the requirements and transferred them to development (Analyst Lead -> Dev Lead). Developers had clarifying questions and they returned requirements to analysts for revision (Dev Lead -> Analyst Lead). Those finalized and again transferred to the developers (Analyst Lead -> Dev Lead). And again there were questions (Dev Lead -> Analyst Lead). So it can go on for a long time. But suppose, after some time, development has begun (I deliberately simplify the scheme, eliminating the transfer of the ball between different departments of developers, such as in our scheme: Java Lead <-> Oracle Lead). In parallel with the beginning of development, testers began to write test cases. At the time of the end of development, the code is transferred to testing (Dev Lead -> QA Lead). Bugs are detected (QA Lead -> Dev Lead). Bugs are repaired and the code is again transmitted to testers (Dev Lead -> QA Lead). And so in a circle.
If at some point this endless circle the manager wants to know the release status, say, the percentage of readiness, then it turns out that the release (our code) is 90% ready. And when asked why the deadlines are about to be broken, there will be a natural lack of response, because no one is to blame. Testers really honestly tested. And the developers really honestly fix all the bugs found. Everyone really wants to put a good product into life. But the ball is constantly being transferred between developers and testers, and there is no end in sight. Absolutely the same situation will be between any other divisions (analysts - developers, developers - developers).
And most importantly - no one is responsible for anything other than the highest leader, who acts as an arbitrator or coordinator between one group and another. But he cannot act as an arbitrator for a very simple reason - it is impossible to be aware of so many development flows and tasks. If it were possible - the structure would have been completely different, and team leads would simply not be needed - one most important manager and ordinary analysts + developers + testers would remain. But life tells us that it is even worse. So the problem must be solved. The key problem lies in areas of responsibility . And that is what we will discuss further.
So, we need to make sure that Team Lead becomes the real leader of the team (and this is how the name of this post is translated). Indeed, in the examples above, he was anyone, but not who he should be. He was Development Lead, QA Lead, Analyst Lead, Java Lead, etc. And he was responsible not for the full life cycle of the task, from developing a specification for it, through development, to the delivery phase after successful testing with bug fixing, but only for one of the pieces of the entire SDLC (Software Development Life Cycle) life cycle. Our task is for Team Lead to be responsible for the entire SDLC for the task - only then it will be able to ensure the delivery of this task on time, with the required amount of functionality and with the required level of quality. The cost at the Team Lead level is usually not considered, except in some conventional units, such as WU (Work Unit = 1 person-day) or some similar units.
We do not forget that in order for a person to be responsible for something he must have one important component - authority. Those. Responsibility and authority are two inseparable components. If you have authority, but there is no responsibility - the trouble for the project and we all see in the example of many countries, where it leads and how it ends. If you have a responsibility, but no authority - even more trouble, but only for you, because you are just a scapegoat upon which failure will fall. And the failure will definitely be, because you can not affect anything. The option when you have neither authority nor responsibility, I do not even consider, because in this case you are not Lead at all. And only in the case when you have the authority and responsibility, you can influence the situation and take responsibility for it, as well as receive rewards for success.
Below is a diagram illustrating the Power-Responsibility relationship:
Let's define what kind of duties Team Lead can have (have). Here they are:
1. Responsible for JIRA tickets
2. Is the owner of the resources (his subordinates)
3. Has a certain list of responsibilities within a specific team / ticket / release (for example, reporting is done in some special way)
4. Responsible for quality
5. Owner of knowledge
6. Has some responsibilities within the competence (for example, is a senior developer on Oracle and should devote some time to development)
These 6 points are very conveniently divided into two large sections:
Task Section
1. Responsible for JIRA tickets
2. Is the owner of the resources (his subordinates)
3. Has a certain list of responsibilities within a specific team / ticket / release (for example, reporting is done in some special way)
Quality and Knowledge Section
1. Responsible for quality
2. Owner of knowledge
3. Has some responsibilities within the competence (for example, is a senior developer on Oracle and should devote some time to development)
It makes sense to assign a task section to Dev Lead. And for the quality and knowledge section, you need to invent a new term. And there is such a term - Competence Lead (leader of competencies). In this way, we get non-intersecting areas of responsibility focused on clear, measurable and substantive things.
All duties from the “task zone” allow tasks to be done on time, provide tasks with the necessary resources and empower the owner of this section with the necessary authority to realize the goals. Tasks from the "quality section" provide high-quality monitoring of skills and development of employees, without affecting the implementation of specific tasks. Together they give the winnings and success that is so necessary for us in project management.
Why divide these 6 responsibilities into two groups, and why assign each group to different people? If you occupy the role of Team Lead (or similar) at the moment or occupied it in the past, then you know / understand / noticed that each of our two groups has completely different directions. And, therefore, such leads need to have different qualities in order to successfully perform both of these groups of duties. This combination of qualities is not always immediately found in one person, especially if he recently became Team Lead (TL). Yes, all the necessary skills can and should be developed, it just takes time. Often, in practice, in real projects, you can meet quite a lot of people who are interested only in one or another group of responsibilities, but not both groups together. Therefore, purely statistically, you, as a manager, may be much more profitable, faster and easier to divide these duties into such groups and assign different people responsible, and precisely those who are most suited to fulfill the first or second group of duties.
How it might look in an organization chart:
You can see that in diagram 3, a group of QA specialists is circled by a dotted line and within this group there is a person with the position “Competence Lead QA”. Please note that the QA group of this Competence Lead includes all testers present in the project. In the same way, you can mentally circle the analysts, javista, oraklistov and all who you have in the project. If the project is large and the groups are too large, divide them into several groups, following the rule of 7 + -2 (from 5 to 9 people per group). Thus, you completely close the issue of competencies, development of people, code quality checks, coaching, training, cross-review, knowledge sharing, back-up of people and many other work issues that often do not have enough time in combat projects.
What a list of responsibilities Team Lead ( TL ) and Competence Lead ( CL ) might look like.
TL Responsibility:
1. Delivery of specific JIRA tickets
2. Branches of relevant releases
3. * Filing holidays
4. * Overtime filing
5. Information about the illness or late subordinate
6. Carrying out stand-ups
7. ** L0, L1 ticket pricing
8. The distribution of tasks in the team:
- Resource load balancing
- The distribution of responsibility for the tasks
Notes:
* In points 3, 4 it is the submission that is meant, not the “primed”
** Clause 7 - with obligatory participation of CL (at least for large and medium tickets)
CL liability:
1. Responsibility for the technical and quality side of the tasks:
2. Proactive position:
Relevant CLs should also take part in:
1. Timing Shift
2. Breakdown and its change in the development, testing, ...
3. Plans for the development of people, training, trainings (together with TL and PPM )
Next steps you can take:
As soon as you update your organizational structure of the project, highlight Team Leads and Competence Leads, inform and coordinate with them their future responsibilities, give them appropriate powers, announce the new structure and new rules of the game to the team, from this point on, your life as a manager will become much easier and easier. Of course, you will encounter many other different difficulties and pitfalls (no one promised that it would be easy and simple), but at the very least issues of responsibility will be clearly resolved.
Share this article with friends.
Thank you and success to you!
In this article we will analyze the distribution of responsibility in large teams. Imagine the situation that you are a manager who has from two to N development streams under his command, but all this development is one big application or one big system, and each thread is involved in its own module or its part of the module. It is important that development flows almost do not overlap in functionality, although they may well use the code of neighbors.
So, our task is to create an organizational structure in which you, as a manager, will have the maximum probability of success. Obviously, the success of the project depends not only on the organizational structure. At the same time, the correct org. The structure is one of the components of this success.
Before we plunge into the “who, to whom, what and when” should provide, report and how communication flows will be organized, consider the “classics of the genre” - a very frequent distribution and purpose of areas of responsibility found in a large number of projects. It usually looks like in the figure below (Java and Oracle are taken for example, instead of them there can be absolutely any other technologies):
')
Job titles may, of course, differ.
Sometimes there are very peculiar combinations, like this:
I am sure many of you have come across such structures, and perhaps you are working in one of these right now. Are they all good? Do they perform their function and help us, as managers, to come to the success of the project faster, more efficiently, with the lowest possible cost of resources? If you are not yet a manager, but you plan to become one, you probably also wonder why such structures are ineffective and where exactly the error is.
Consider the examples above.
What is the goal of the project manager, program, department? In addition to making money (depending on the level of the position), the goal is only one - to make the product on time, within the allocated budget and with an agreed amount and level of functionality and quality.
Now look at the diagrams above. Will they make, say, a release, on time and with the necessary amount of functionality, and even at the agreed level of quality? Strongly doubt. Why do I have doubts? There are several reasons.
First of all, there is doubt about the blurred area of ​​responsibility. Tell me, who in the diagrams above is responsible for the timing, scope and quality of the release / project / product? As a result, the one who is at the top is responsible for everything. And this is true. And if lower? Is Team Lead responsible for the release? And at least for one ticket in JIRA (or in any other task tracking system)? Looking at the above two schemes - no, definitely not responding.
The second point in terms of doubt is throwing the ball between team leads. For example, analysts completed the requirements and transferred them to development (Analyst Lead -> Dev Lead). Developers had clarifying questions and they returned requirements to analysts for revision (Dev Lead -> Analyst Lead). Those finalized and again transferred to the developers (Analyst Lead -> Dev Lead). And again there were questions (Dev Lead -> Analyst Lead). So it can go on for a long time. But suppose, after some time, development has begun (I deliberately simplify the scheme, eliminating the transfer of the ball between different departments of developers, such as in our scheme: Java Lead <-> Oracle Lead). In parallel with the beginning of development, testers began to write test cases. At the time of the end of development, the code is transferred to testing (Dev Lead -> QA Lead). Bugs are detected (QA Lead -> Dev Lead). Bugs are repaired and the code is again transmitted to testers (Dev Lead -> QA Lead). And so in a circle.
If at some point this endless circle the manager wants to know the release status, say, the percentage of readiness, then it turns out that the release (our code) is 90% ready. And when asked why the deadlines are about to be broken, there will be a natural lack of response, because no one is to blame. Testers really honestly tested. And the developers really honestly fix all the bugs found. Everyone really wants to put a good product into life. But the ball is constantly being transferred between developers and testers, and there is no end in sight. Absolutely the same situation will be between any other divisions (analysts - developers, developers - developers).
And most importantly - no one is responsible for anything other than the highest leader, who acts as an arbitrator or coordinator between one group and another. But he cannot act as an arbitrator for a very simple reason - it is impossible to be aware of so many development flows and tasks. If it were possible - the structure would have been completely different, and team leads would simply not be needed - one most important manager and ordinary analysts + developers + testers would remain. But life tells us that it is even worse. So the problem must be solved. The key problem lies in areas of responsibility . And that is what we will discuss further.
So, we need to make sure that Team Lead becomes the real leader of the team (and this is how the name of this post is translated). Indeed, in the examples above, he was anyone, but not who he should be. He was Development Lead, QA Lead, Analyst Lead, Java Lead, etc. And he was responsible not for the full life cycle of the task, from developing a specification for it, through development, to the delivery phase after successful testing with bug fixing, but only for one of the pieces of the entire SDLC (Software Development Life Cycle) life cycle. Our task is for Team Lead to be responsible for the entire SDLC for the task - only then it will be able to ensure the delivery of this task on time, with the required amount of functionality and with the required level of quality. The cost at the Team Lead level is usually not considered, except in some conventional units, such as WU (Work Unit = 1 person-day) or some similar units.
We do not forget that in order for a person to be responsible for something he must have one important component - authority. Those. Responsibility and authority are two inseparable components. If you have authority, but there is no responsibility - the trouble for the project and we all see in the example of many countries, where it leads and how it ends. If you have a responsibility, but no authority - even more trouble, but only for you, because you are just a scapegoat upon which failure will fall. And the failure will definitely be, because you can not affect anything. The option when you have neither authority nor responsibility, I do not even consider, because in this case you are not Lead at all. And only in the case when you have the authority and responsibility, you can influence the situation and take responsibility for it, as well as receive rewards for success.
Below is a diagram illustrating the Power-Responsibility relationship:
Let's define what kind of duties Team Lead can have (have). Here they are:
1. Responsible for JIRA tickets
2. Is the owner of the resources (his subordinates)
3. Has a certain list of responsibilities within a specific team / ticket / release (for example, reporting is done in some special way)
4. Responsible for quality
5. Owner of knowledge
6. Has some responsibilities within the competence (for example, is a senior developer on Oracle and should devote some time to development)
These 6 points are very conveniently divided into two large sections:
Task Section
1. Responsible for JIRA tickets
2. Is the owner of the resources (his subordinates)
3. Has a certain list of responsibilities within a specific team / ticket / release (for example, reporting is done in some special way)
Quality and Knowledge Section
1. Responsible for quality
2. Owner of knowledge
3. Has some responsibilities within the competence (for example, is a senior developer on Oracle and should devote some time to development)
It makes sense to assign a task section to Dev Lead. And for the quality and knowledge section, you need to invent a new term. And there is such a term - Competence Lead (leader of competencies). In this way, we get non-intersecting areas of responsibility focused on clear, measurable and substantive things.
All duties from the “task zone” allow tasks to be done on time, provide tasks with the necessary resources and empower the owner of this section with the necessary authority to realize the goals. Tasks from the "quality section" provide high-quality monitoring of skills and development of employees, without affecting the implementation of specific tasks. Together they give the winnings and success that is so necessary for us in project management.
Why divide these 6 responsibilities into two groups, and why assign each group to different people? If you occupy the role of Team Lead (or similar) at the moment or occupied it in the past, then you know / understand / noticed that each of our two groups has completely different directions. And, therefore, such leads need to have different qualities in order to successfully perform both of these groups of duties. This combination of qualities is not always immediately found in one person, especially if he recently became Team Lead (TL). Yes, all the necessary skills can and should be developed, it just takes time. Often, in practice, in real projects, you can meet quite a lot of people who are interested only in one or another group of responsibilities, but not both groups together. Therefore, purely statistically, you, as a manager, may be much more profitable, faster and easier to divide these duties into such groups and assign different people responsible, and precisely those who are most suited to fulfill the first or second group of duties.
How it might look in an organization chart:
You can see that in diagram 3, a group of QA specialists is circled by a dotted line and within this group there is a person with the position “Competence Lead QA”. Please note that the QA group of this Competence Lead includes all testers present in the project. In the same way, you can mentally circle the analysts, javista, oraklistov and all who you have in the project. If the project is large and the groups are too large, divide them into several groups, following the rule of 7 + -2 (from 5 to 9 people per group). Thus, you completely close the issue of competencies, development of people, code quality checks, coaching, training, cross-review, knowledge sharing, back-up of people and many other work issues that often do not have enough time in combat projects.
What a list of responsibilities Team Lead ( TL ) and Competence Lead ( CL ) might look like.
TL Responsibility:
1. Delivery of specific JIRA tickets
2. Branches of relevant releases
3. * Filing holidays
4. * Overtime filing
5. Information about the illness or late subordinate
6. Carrying out stand-ups
7. ** L0, L1 ticket pricing
8. The distribution of tasks in the team:
- Resource load balancing
- The distribution of responsibility for the tasks
Notes:
* In points 3, 4 it is the submission that is meant, not the “primed”
** Clause 7 - with obligatory participation of CL (at least for large and medium tickets)
CL liability:
1. Responsibility for the technical and quality side of the tasks:
- Used technologies
- Use of standards
- Architectural issues
- Approaches, concepts of testing. Test plans. Review test cases
- Quality specifications. Specification Review
- Solution Compliance with Requirements and Specifications
- Quality code. Revision code
2. Proactive position:
- Coaching interns, new cameras (and not only)
- Offer technical improvements
Relevant CLs should also take part in:
1. Timing Shift
2. Breakdown and its change in the development, testing, ...
3. Plans for the development of people, training, trainings (together with TL and PPM )
Next steps you can take:
As soon as you update your organizational structure of the project, highlight Team Leads and Competence Leads, inform and coordinate with them their future responsibilities, give them appropriate powers, announce the new structure and new rules of the game to the team, from this point on, your life as a manager will become much easier and easier. Of course, you will encounter many other different difficulties and pitfalls (no one promised that it would be easy and simple), but at the very least issues of responsibility will be clearly resolved.
Share this article with friends.
Thank you and success to you!
Source: https://habr.com/ru/post/293334/
All Articles