August 5, 2015 at 14:00Team Leads Responsibility
Hello friends.
In this article we will analyze the distribution of responsibility in large teams. Imagine a situation when you are a leader who subordinates from two to N development threads, but all this development is one large application or one large system, and each thread is engaged in its own module or its own part of the module. It is important that the development flows hardly overlap in functionality, although they can use the code of neighbors.
So, our task is to create an organizational structure in which you, as a leader, will have the maximum likelihood of success. Obviously, the success of a project depends not only on the organizational structure. At the same time, the correct org. structure is one of the components of this success.
Before we dive into the “who, whom, what and when” should provide, report and how the communication flows will be organized, consider the “classics of the genre” - a very frequent distribution and assignment of areas of responsibility, found in a large number of projects. It usually looks like in the figure below (Java and Oracle are taken as an example, there may be absolutely any other technologies instead):
Job titles may, of course, differ.
Sometimes there are very peculiar combinations, such as this:
I am sure many of you have come across such structures, and perhaps you are working in one of these right now. Is everything good in them? Do they fulfill their function and help us, as managers, faster, more efficiently, with the lowest possible cost of resources, achieve the success of the project? If you are not yet a leader, but plan to become one, you are probably also wondering why such structures are ineffective and where exactly the error is.
Consider the examples above.
What is the purpose of the project, program, department manager? 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 volume and level of functionality and quality.
Now look at the diagrams above. Will they allow you to make, say, a release, on time and with the right amount of functionality, and even with an agreed level of quality? I doubt it very much. Why do I have doubts? There are several reasons.
First of all, the blurred area of responsibility is causing doubt. 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 these two patterns above - no, definitely not responding.
The second point in terms of doubt is the throwing of the ball between team leads. For example, analysts completed the requirements and transferred them to development (Analyst Lead -> Dev Lead). The developers had clarifying questions and returned the requirements to analysts for revision (Dev Lead -> Analyst Lead). Those finalized and again handed over to the developers (Analyst Lead -> Dev Lead). And again questions arose (Dev Lead -> Analyst Lead). This can go on for a long time. But suppose, after some time, the development did start (I intentionally simplify the scheme by eliminating the ball being transferred between different divisions of the developers, such as in our diagram: Java Lead <-> Oracle Lead). In parallel with the beginning of development, testers began to write test cases. At the end of development, the code is transferred for testing (Dev Lead -> QA Lead). Bugs detected (QA Lead -> Dev Lead). The bugs are fixed and the code is again passed to the testers (Dev Lead -> QA Lead). And so in a circle.
If at some point in 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 to the question of why the deadlines are about to be broken, a logical absence of an answer will follow, because no one is to blame. Testers are really honestly testing. And the developers really honestly fix all the bugs found. Everyone really wants to bring a good product to life. But the ball is constantly being thrown between developers and testers, and there is no end in sight. The situation will be exactly the same between any other units (analysts - developers, developers - developers).
And most importantly - no one is responsible for anything except the highest leader, acting as an arbiter or coordinator between one group and another. And he cannot act as an arbiter for a very simple reason - it is impossible to keep abreast of so many development flows and tasks. If it were possible - the structure would be completely different and team leads would simply not be needed - there would remain one main manager and ordinary analysts + developers + testers. But life tells us that it’s even worse. So the problem must be solved. The key issue is in the areas of responsibility . And that is what we will discuss further.
So, we need to make Team Lead truly become the team leader (and this is exactly how the name of this post is translated). Indeed, in the examples above, he was anyone, but not what he should be. He was Development Lead, QA Lead, Analyst Lead, Java Lead, etc. And he was not responsible for the full life cycle of the task from developing the specification to it, through development, to the delivery stage after successful testing with bug fixing, but only for some of the pieces of this entire SDLC (Software Development Life Cycle) life cycle. Our goal is for Team Lead to be responsible for the entire SDLC.for a task - only then he will have the opportunity to ensure the delivery of this task on time, with the right amount of functionality and with the right level of quality. Cost at the Team Lead level is usually not considered, except in some arbitrary units, such as WU (Work Unit = 1 person-day) or some similar units.
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 no responsibility, it’s a disaster for the project and we all see in many countries how this leads and how it ends. If you have responsibility, but no authority, it’s even more trouble, but only for you, because you are just a scapegoatthat will fail. And there will definitely be a failure, because you cannot influence anything. The option when you have neither authority nor responsibility, I do not even consider, because in this case you are not a Lead at all. And only if you have the authority and responsibility, you can influence the situation and bear responsibility for it, as well as receive rewards for success.
Below is a diagram illustrating the relationship of Authority-Responsibility:
Let's decide what responsibilities Team Lead can have (are). Here they are:
1. Responsible for JIRA tickets
2. Owns resources (its 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 (say, is a Senior developer at Oracle and must devote part of his time to development)
These 6 items 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 a special way)
Quality and knowledge section
1. Responsible for quality
2. Knowledge owner
3. Has certain duties in competency framework (say, is a Senior developer at Oracle and should devote part of his time to development)
It makes sense to assign the task section to Dev Lead. And for the section of quality and knowledge it is necessary to come up with a new term. And there is such a term - Competence Lead (leader of competencies). Thus, we get non-overlapping areas of responsibility, focused on clear, measurable and substantive things.
All responsibilities from the “task zone” allow tasks to be completed on time, provide tasks with the necessary resources and give the owner of this section the necessary authority to achieve their 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 gain and success that we need so much in project management.
Why divide these 6 responsibilities into two groups and why assign each group to different people? If you occupy the Team Lead role (or similar) at the moment or have occupied it in the past, then you know / understand / noticed that each of our two groups has a completely different focus. And, therefore, such leads need to have different qualities in order to successfully fulfill 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 in only one or another group of duties, but not both groups together. Therefore, purely statistically, to you, as a leader,
How it may look on the organizational chart:
You can see that on chart-3 the group of QA-specialists is surrounded by a dashed line and there is a person with the position “Competence Lead QA” inside this group. Please note that the QA group of this Competence Lead includes all testers available in the project. In the same way, you can mentally circle analysts, javists, oracleists and everyone you have in the project. If the project is large and the groups are too large, break them into several, guided by the rule 7 + -2 (from 5 to 9 people per group). Thus, you completely close the issue of competencies, people development, code quality checks, coaching, training, cross-review, knowledge sharing, backing up people and many other working issues that often do not have enough time in combat projects.
What the Team Lead ( TL ) and Competence Lead ( CL ) responsibilities list might look like .
Responsibility TL :
1. Delivery of specific JIRA tickets
2. Branches of relevant releases
3. * Submission of vacations
4. * Submission of overtime
5. Information about the illness or the delay of a subordinate
6. Holding stand-ups
7. ** L0, L1 ticket evaluation
8. Distribution of tasks in the team:
- Balancing the load of resources
- Distribution of those responsible for the tasks
Notes:
* In paragraphs 3, 4, it means the flow, not the “appr"
** Point 7 - with mandatory participationCL (at least for large and medium tickets)
Responsibility of CL :
1. Responsibility for the technical and quality side of the tasks:
2. Proactive position:
Relevant CLs should also take part in the following issues:
1. Timing shift
2. Breakdown and its change in the field of development, testing, ...
3. People development plans, education, training (together with TL and PPM )
The nearest steps that can be taken:
As soon as you update your organizational structure of the project, select Team Leads and Competence Leads, report and coordinate with them their future responsibilities, give them the appropriate authority, voice the team a new structure and new rules of the game, from this moment your life as a leader It will become much simpler and easier. Of course, you will encounter many other various difficulties and pitfalls (no one promised that it would be easy and simple), but at least the issues of responsibility will be clearly resolved.
Share this article with your friends.
Thank you and good luck to you!
In this article we will analyze the distribution of responsibility in large teams. Imagine a situation when you are a leader who subordinates from two to N development threads, but all this development is one large application or one large system, and each thread is engaged in its own module or its own part of the module. It is important that the development flows hardly overlap in functionality, although they can use the code of neighbors.
So, our task is to create an organizational structure in which you, as a leader, will have the maximum likelihood of success. Obviously, the success of a project depends not only on the organizational structure. At the same time, the correct org. structure is one of the components of this success.
Before we dive into the “who, whom, what and when” should provide, report and how the communication flows will be organized, consider the “classics of the genre” - a very frequent distribution and assignment of areas of responsibility, found in a large number of projects. It usually looks like in the figure below (Java and Oracle are taken as an example, there may be absolutely any other technologies instead):
Job titles may, of course, differ.
Sometimes there are very peculiar combinations, such as this:
I am sure many of you have come across such structures, and perhaps you are working in one of these right now. Is everything good in them? Do they fulfill their function and help us, as managers, faster, more efficiently, with the lowest possible cost of resources, achieve the success of the project? If you are not yet a leader, but plan to become one, you are probably also wondering why such structures are ineffective and where exactly the error is.
Consider the examples above.
What is the purpose of the project, program, department manager? 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 volume and level of functionality and quality.
Now look at the diagrams above. Will they allow you to make, say, a release, on time and with the right amount of functionality, and even with an agreed level of quality? I doubt it very much. Why do I have doubts? There are several reasons.
First of all, the blurred area of responsibility is causing doubt. 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 these two patterns above - no, definitely not responding.
The second point in terms of doubt is the throwing of the ball between team leads. For example, analysts completed the requirements and transferred them to development (Analyst Lead -> Dev Lead). The developers had clarifying questions and returned the requirements to analysts for revision (Dev Lead -> Analyst Lead). Those finalized and again handed over to the developers (Analyst Lead -> Dev Lead). And again questions arose (Dev Lead -> Analyst Lead). This can go on for a long time. But suppose, after some time, the development did start (I intentionally simplify the scheme by eliminating the ball being transferred between different divisions of the developers, such as in our diagram: Java Lead <-> Oracle Lead). In parallel with the beginning of development, testers began to write test cases. At the end of development, the code is transferred for testing (Dev Lead -> QA Lead). Bugs detected (QA Lead -> Dev Lead). The bugs are fixed and the code is again passed to the testers (Dev Lead -> QA Lead). And so in a circle.
If at some point in 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 to the question of why the deadlines are about to be broken, a logical absence of an answer will follow, because no one is to blame. Testers are really honestly testing. And the developers really honestly fix all the bugs found. Everyone really wants to bring a good product to life. But the ball is constantly being thrown between developers and testers, and there is no end in sight. The situation will be exactly the same between any other units (analysts - developers, developers - developers).
And most importantly - no one is responsible for anything except the highest leader, acting as an arbiter or coordinator between one group and another. And he cannot act as an arbiter for a very simple reason - it is impossible to keep abreast of so many development flows and tasks. If it were possible - the structure would be completely different and team leads would simply not be needed - there would remain one main manager and ordinary analysts + developers + testers. But life tells us that it’s even worse. So the problem must be solved. The key issue is in the areas of responsibility . And that is what we will discuss further.
So, we need to make Team Lead truly become the team leader (and this is exactly how the name of this post is translated). Indeed, in the examples above, he was anyone, but not what he should be. He was Development Lead, QA Lead, Analyst Lead, Java Lead, etc. And he was not responsible for the full life cycle of the task from developing the specification to it, through development, to the delivery stage after successful testing with bug fixing, but only for some of the pieces of this entire SDLC (Software Development Life Cycle) life cycle. Our goal is for Team Lead to be responsible for the entire SDLC.for a task - only then he will have the opportunity to ensure the delivery of this task on time, with the right amount of functionality and with the right level of quality. Cost at the Team Lead level is usually not considered, except in some arbitrary units, such as WU (Work Unit = 1 person-day) or some similar units.
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 no responsibility, it’s a disaster for the project and we all see in many countries how this leads and how it ends. If you have responsibility, but no authority, it’s even more trouble, but only for you, because you are just a scapegoatthat will fail. And there will definitely be a failure, because you cannot influence anything. The option when you have neither authority nor responsibility, I do not even consider, because in this case you are not a Lead at all. And only if you have the authority and responsibility, you can influence the situation and bear responsibility for it, as well as receive rewards for success.
Below is a diagram illustrating the relationship of Authority-Responsibility:
Let's decide what responsibilities Team Lead can have (are). Here they are:
1. Responsible for JIRA tickets
2. Owns resources (its 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 (say, is a Senior developer at Oracle and must devote part of his time to development)
These 6 items 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 a special way)
Quality and knowledge section
1. Responsible for quality
2. Knowledge owner
3. Has certain duties in competency framework (say, is a Senior developer at Oracle and should devote part of his time to development)
It makes sense to assign the task section to Dev Lead. And for the section of quality and knowledge it is necessary to come up with a new term. And there is such a term - Competence Lead (leader of competencies). Thus, we get non-overlapping areas of responsibility, focused on clear, measurable and substantive things.
All responsibilities from the “task zone” allow tasks to be completed on time, provide tasks with the necessary resources and give the owner of this section the necessary authority to achieve their 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 gain and success that we need so much in project management.
Why divide these 6 responsibilities into two groups and why assign each group to different people? If you occupy the Team Lead role (or similar) at the moment or have occupied it in the past, then you know / understand / noticed that each of our two groups has a completely different focus. And, therefore, such leads need to have different qualities in order to successfully fulfill 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 in only one or another group of duties, but not both groups together. Therefore, purely statistically, to you, as a leader,
How it may look on the organizational chart:
You can see that on chart-3 the group of QA-specialists is surrounded by a dashed line and there is a person with the position “Competence Lead QA” inside this group. Please note that the QA group of this Competence Lead includes all testers available in the project. In the same way, you can mentally circle analysts, javists, oracleists and everyone you have in the project. If the project is large and the groups are too large, break them into several, guided by the rule 7 + -2 (from 5 to 9 people per group). Thus, you completely close the issue of competencies, people development, code quality checks, coaching, training, cross-review, knowledge sharing, backing up people and many other working issues that often do not have enough time in combat projects.
What the Team Lead ( TL ) and Competence Lead ( CL ) responsibilities list might look like .
Responsibility TL :
1. Delivery of specific JIRA tickets
2. Branches of relevant releases
3. * Submission of vacations
4. * Submission of overtime
5. Information about the illness or the delay of a subordinate
6. Holding stand-ups
7. ** L0, L1 ticket evaluation
8. Distribution of tasks in the team:
- Balancing the load of resources
- Distribution of those responsible for the tasks
Notes:
* In paragraphs 3, 4, it means the flow, not the “appr"
** Point 7 - with mandatory participationCL (at least for large and medium tickets)
Responsibility of CL :
1. Responsibility for the technical and quality side of the tasks:
- Used technologies
- Using Standards
- Architectural issues
- Approaches, testing concepts. Test plans. Case Study Review
- Quality specifications. Specification Review
- Compliance with requirements and specifications
- Code quality. Code review
2. Proactive position:
- Coaching interns, new cameras (and not only)
- Proposal for Technical Improvements
Relevant CLs should also take part in the following issues:
1. Timing shift
2. Breakdown and its change in the field of development, testing, ...
3. People development plans, education, training (together with TL and PPM )
The nearest steps that can be taken:
As soon as you update your organizational structure of the project, select Team Leads and Competence Leads, report and coordinate with them their future responsibilities, give them the appropriate authority, voice the team a new structure and new rules of the game, from this moment your life as a leader It will become much simpler and easier. Of course, you will encounter many other various difficulties and pitfalls (no one promised that it would be easy and simple), but at least the issues of responsibility will be clearly resolved.
Share this article with your friends.
Thank you and good luck to you!