What do you think?
Rate this book
Notes to a software team leader
Why?
Many software team leaders today face a weird they believe in a bunch of great things that software developers should be doing but somehow can’t seem to make this work at their own team.
For example they feel that shorter iterations can be good for the team and customer, but no one seems to believe them, or no one cares when they mention it.
They believe that unit testing can save the product from its poor quality, but their team members would rather do anything but write those tests.
Team leaders everywhere seem to be hitting a wall everywhere they try to make a difference – so they give up, or they get things done half-way to the point of failure.
People.
Driving “the new stuff” into the team is usually the least of the worries of today’s software team leaders. Team leads usually have little to no idea how to handle people related issues – issues that affect how the morale, quality of work, and overall performance of the team, and of course impacts how easy or hard it is to implement “the new stuff”.
Most team leaders are clueless as to how to handle their manager giving them an impossible due date, a team member reluctant to try anything new, or another team member teaching all the other members practices from 25 years ago that today only hurt the team.
Why?
No one teaches that to software team leads. Team leads today, in the overwhelming majority of places, are just developers who worked hard and stayed with the company long enough to be promoted. But they have no people or management skills - and those are very painfully needed when you are trying to drive the things you believe in inside an organization that has very little interest in changing.
Team leadership is the next big thing that software developers need to conquer, or none of this unit testing, TDD, Agile or Lean thing is going to catch on, except in very small circles, that, by chance, happen to have the right people leading their teams.
Many software team leaders today face a weird they believe in a bunch of great things that software developers should be doing but somehow can’t seem to make this work at their own team.
For example they feel that shorter iterations can be good for the team and customer, but no one seems to believe them, or no one cares when they mention it.
They believe that unit testing can save the product from its poor quality, but their team members would rather do anything but write those tests.
Team leaders everywhere seem to be hitting a wall everywhere they try to make a difference – so they give up, or they get things done half-way to the point of failure.
People.
Driving “the new stuff” into the team is usually the least of the worries of today’s software team leaders. Team leads usually have little to no idea how to handle people related issues – issues that affect how the morale, quality of work, and overall performance of the team, and of course impacts how easy or hard it is to implement “the new stuff”.
Most team leaders are clueless as to how to handle their manager giving them an impossible due date, a team member reluctant to try anything new, or another team member teaching all the other members practices from 25 years ago that today only hurt the team.
Why?
No one teaches that to software team leads. Team leads today, in the overwhelming majority of places, are just developers who worked hard and stayed with the company long enough to be promoted. But they have no people or management skills - and those are very painfully needed when you are trying to drive the things you believe in inside an organization that has very little interest in changing.
Team leadership is the next big thing that software developers need to conquer, or none of this unit testing, TDD, Agile or Lean thing is going to catch on, except in very small circles, that, by chance, happen to have the right people leading their teams.
100 pages, ebook
First published January 1, 2012
57 people are currently reading
1354 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 73 reviews
November 21, 2016
Interesting book. Far from being a complete resource on leadership, but I loved it anyway for one particular reason: it's the only book I can recall that gives a lot of consideration to one of the most critical phenomenons in technical leadership -> getting teams out of the survival mode. I really mean it: Roy perfectly describes what SM is, what are its consequences, how hard it is to get out of it & ... how few actually manages to do so. I find it very valuable as according to my observations it's one of the key problems of modern IT, especially in Enterprises.
Another pro is a very reasonable approach to self-organizing: what are its pre-requisites, how it's supposed to happen & such. I'd recommend this chapter to all these people who are so delusional regarding the idea of self-governance & self-management.
What else?
1. Book is actually a revised version of "Notes of the technical team reader", so if you've read this version before, you won't learn too much.
2. The final section (mini-interviews focused on 1 particular issue/aspect of leadership) is interesting, but as you can easily imagine -> quite chaotic.
In the end: good stuff, recommended - even if only because of detailed description of the survival mode. But slightly overpriced & limited in general.
Another pro is a very reasonable approach to self-organizing: what are its pre-requisites, how it's supposed to happen & such. I'd recommend this chapter to all these people who are so delusional regarding the idea of self-governance & self-management.
What else?
1. Book is actually a revised version of "Notes of the technical team reader", so if you've read this version before, you won't learn too much.
2. The final section (mini-interviews focused on 1 particular issue/aspect of leadership) is interesting, but as you can easily imagine -> quite chaotic.
In the end: good stuff, recommended - even if only because of detailed description of the survival mode. But slightly overpriced & limited in general.
December 9, 2019
I really liked the content of this 'book' (particularly the commitment language idea), but hated its form. The main problem is that Elastic Leadership is not really a book, but a collection of barely connected notes (not even essays), each of which is quite self-sufficient and provides a description for one leadership-related idea, but is quite superficial, never presenting the reader with deep reasons for using the described idea or why does it matter. Examples provided in the book try to look like a real-world ones, but are actually evidently artificial in the best cases, and cringeworthy in the worst. Nearly the half of the 'book' are reactions to the 'book's content from other technical leaders/managers which don't really add anything new and actually make you think that they were added just to make the current edition bigger.
Elastic Leadership is still a good cheatsheet/reference for a new leader, but all the actual & meaningful content could have been easily fit on a couple of pages, not a full-blown book.
Elastic Leadership is still a good cheatsheet/reference for a new leader, but all the actual & meaningful content could have been easily fit on a couple of pages, not a full-blown book.
January 24, 2020
A horrible book of obvious things which should look better (also, shorter and cheaper) as a blog post.
Pages shouldn’t be wasted to discuss the positive outcomes of stand ups and retros... But the whole position of a team lead being a momma is a real problem... Grow, challenge, talk - excuse me, the team is full of adults, not three years old. Newbie team leads should not read this book - the point of view of the author can cause problems... The last chapter of the notes from different leads is more interesting than the book. But those blog posts are still the block posts...
Pages shouldn’t be wasted to discuss the positive outcomes of stand ups and retros... But the whole position of a team lead being a momma is a real problem... Grow, challenge, talk - excuse me, the team is full of adults, not three years old. Newbie team leads should not read this book - the point of view of the author can cause problems... The last chapter of the notes from different leads is more interesting than the book. But those blog posts are still the block posts...
January 29, 2017
While reading the book I had mixed feelings while some parts are brilliant and worth reading, some appeared to me far from ideal. The main idea of book that development is done is three phases thus modes:
1. survival mode
2. learning mode
3. self-organizing mode
Survival is when project is somehow endangered, needs strict control. The learning mode is something between former and the next. It is phase when there is some space for learning and making less or more controlled mistakes. The third one when team is able to work on itself without strict control, everyone knows what to do, making decisions doesn't require to control by TL, who become facilitator otherwise who would become bottleneck at that stage. Every phase requires different approach for TL. Book also describes how PM can help to develop team and hence project. It is stressed widely that good, motivated people create a good team which in turn produce brilliant projects.
Other notion which is widely described is so called bus factor. This is a person, for e.g. TL or other person who became knowledge silo to be so crucial that in case of losing such person, project is dead, or at least in big trouble. The best thing is to avoid such situations.
He also doubts in effectiveness or even counter productivity of traditional appraisal, when the former is rather focused on personal performance and results not results as team.
Last part of book consists from short excerpts from well known people in industry which describes one of facet of leading people, growing teams and so on. All are chosen by author and then shortly commented.
Author provides a lot of wisdom and hints for e.g. how to provide really valuable feedback. Not just getting at someone.
However reader can find a lot of nuggets in the book, all in all it could be better written.
Some useful quotations:
A good leader will challenge the team and the people around them to solve their own problems, instead of solving everyone’s problems for them.
Nothing beats gaining new skills. You and your team should always be getting better and going out of your comfort zone to learn new things. This is essential to what a team leader does. Becoming a team leader requires personal growth, rising to the challenge of knowing your team and what you can expect from them.
People don’t quit their jobs. They quit their managers.
Lesson: The fewer people you have who know an important part of your business, the more you will pay when they move on.
The best way to learn is to teach, and by teaching, the new person grows and learns the new task in a much deeper way than by being coached by the expert.
If someone is a bad influence on the team, for example, always pessimistic, your responsibility to the team is to remove that problem.
“My project manager won’t like me not committing to a deadline for when the bug is fixed, and committing to working on it a certain amount of time instead. She’ll think I’m just buffering.” I’ve heard this concern. I find that, with some patience, it’s easy to explain why some tasks can’t be proven to end by a specific time. Instead you can “cap” the maximum time you can “burn” on a specific commitment, and then regroup, replan, and recommit based on what you found. This is true agility.
You too will have to learn a new skill here: stop solving everyone’s problems, and begin mentoring and challenging them to solve problems themselves.
Challenge them to solve it on their own, with you as their mentor, but without you doing the work for them.
When someone brings up a problem or hindrance in the daily stand-up meeting, challenge them and ask them, “What are you going to about it?” to see where it leads. Help them figure out the problem, and don’t solve it for them. Teach them to solve the problem on their own. Most importantly, teach them the thought process that leads to the solution.
When people are challenged to solve their own problems, it’s important not to punish those who are unable to solve them. It’s their problem, and they will continue to suffer for it. The consequence is that they will keep having the problem. If they care about it enough, they’ll keep trying.
I think the best line managers are engaged in what their employees are doing, even if they aren’t in close physical proximity, and they can help by being coaches as much as being direct technical leads. It requires a bit of a mindset readjustment.
High-level managers secretly yearn for the mid-level manager who will get them out of the current messes they’re in charge of, while they take credit.
To be constructive, you need to offer a concrete suggestion for improvement, or you need to make giving feedback part of a problem-solving conversation. If you want someone to learn, create the opportunity and environment for them to discuss and contribute; otherwise, the feedback becomes more about the person giving the feedback than the person receiving it. Feedback needs purpose and it should enable purpose.
At a higher level, as a leader, conflict is an indication that the team is missing a skill: how to make a decision when there are multiple good choices. If, as a software team leader, it falls to you to make the big decisions, what does that indicate about the team?
I learned this from Jerry Weinberg, somewhere. The most difficult problems aren’t technical problems.
Robert C. Martin (Uncle Bob) One of the biggest mistakes that new software team leaders make is to consider the code written by the programmers as the private property of the author, as opposed to an asset owned by the team.
It’s the stuff you need to know in order to basically get around. Many times, the answers to these questions aren’t documented anywhere. It’s “tribal knowledge.”
I’d suggest that this is in direct conflict with the adoption and use of agile frameworks within the organization. Think about it: Agile emphasizes teamwork and cooperation in order to successfully deliver a product, with individuals being prepared to take on any task that needs doing in order to complete the iteration and get to “done.” Individual accountability, as valued by the traditional appraisal system, implies that individuals should be interested in taking the juiciest or most challenging tasks for themselves in order to prove their worth and progress within the organization. Agile emphasizes the forming of self-organizing teams that direct and manage their own work, whereas appraisals involve the setting of objectives that traditionally come from the manager. Agile processes emphasize constant process improvement. Although this can be done alongside traditional appraisals, appraisals are geared more toward making individual or process changes at review time.
Build learning and career development into individual user stories, perhaps in the form of a specific task that involves team members expanding their business domain knowledge. Alternatively, include time for learning tasks into your velocity calculations to increase the value of each team member to the organization by expanding their skillset ian a way that’s relevant to their immediate task. Let the individuals drive and organize this learning process as they would a normal development task.
Include team member feedback sessions as part of your iteration retrospective process, where you can directly discuss what people have learned. Encourage individuals, on an iteration-by-iteration basis, to maintain a body of evidence that can be directly referenced at formal appraisal time. This will reduce the time taken to plan and perform the appraisal and encourages the recording of tasks at the time they happen—when they’re most relevant.
The product will be as good as your team is.
Now I believe every little effort you make to improve your team infuses the products they create. You must be ready for that. Your behavior must change to let your people do their best.
Pay attention to people, and identify the phase your team is in and what it needs in order to evolve. Find the right leadership for that phase. Admit you can’t become the one and only leader, but you can be that person who turns mediocre teams into great teams: a great manager.
If you keep thinking about building products, these will only be as good as you’re able to manage and control your team. But if you facilitate the emergence of the full potential of your team, the product will be enhanced and enriched by many people and their synergy.
I’ve seen many team leaders, including me in my early years, give the less fun jobs to the reliables, as there’s less chance of resistance and conflict. In the short term, this strategy may work in your favor, but there are some repercussions: The team as a whole may begin to pass work off to the reliables. The reliables will eventually burn out. The reliables will become frustrated, and you’ll more than likely lose their respect. Internal conflict will arise because the reliables will separate themselves from the complainers. The solution involves sharing the load equally. If you gave a “boring” task to Member A today, give the next boring task to Member B—regardless of whether they complain. This will build up a culture of equality, with every team member having their share of learning opportunities.
If you want to become a great team leader, you need to stop being the team task dispatcher. Normally, a group of people will do a better job at this than a single person. Your job as the team leader is to allow this; make your team self-manage.
Remember that, like any new skill, mistakes will be made along the way. That’s okay. Mistakes are what people learn from. Don’t try to prevent them; just make sure the damage isn’t too bad and people learn from the mistakes.
The team should eventually grow to be a team of leaders, each of whom can ask important questions that might come from an objective perspective.
One of the most important lessons I learned is that if you keep your developers happy and motivated, they’ll consequently do some of their best work and will contribute to the betterment of the team and the organization. The tricks involved with keeping them motivated may initially seem counterintuitive to developers and/or management.
Another motivational technique can also make management cringe: you absolutely must establish that you prioritize quality over quantity.
That one statement sums up three of the common dysfunctions of a team: Absence of trust Lack of accountability Low commitment to the project
Acting as a command-and-control leader when being a coach fits the current situation brings poor results. Being “command and control” with a self-organizing team is disastrous.
Team leaders should seek critical technical debt that continually drags at the team, and look for ways to break down large chunks into smaller, more manageable chunks.
Agile development is all about shortening feedback loops.
Attempt to find a pace of change that doesn’t cause anxiety to team members. Using the discussed techniques can make change faster and smoother. Don’t become disheartened
; change takes time. Give others time, but ensure you are helping the process as much as you can
everyone needs to be heard. Then a decision can be made, even if everyone’s not on board. People who have been heard can feel committed to do things they don’t agree with, as long as they said everything they wanted to say, and they know it was considered. As long as you end up with “We considered this feedback, and we’re going to go with X anyway,” people can still follow the decision.
The advice is often presented under the Japanese name Gemba, which says the manager ought to be there where the work happens in order to understand how healthy the organization is and to help solve any problems people might have, using facts and not assumptions.
Most professionals in a field don’t understand that specialists in another field don’t speak their language. Team leaders provide translation services to ensure everyone heads in the right direction.
the value of technical leadership—to facilitate the team to the best solution, not your solution.
By establishing yourself as the sole tech lead, you become the main bottleneck for decision-making. You also turn into a bus factor. Without you, the team can’t function, which is a huge risk.
defensive and began experimenting a little. I inadvertently demonstrated that it was okay to try something and fail, which unlocked a whole new style of working.
1. survival mode
2. learning mode
3. self-organizing mode
Survival is when project is somehow endangered, needs strict control. The learning mode is something between former and the next. It is phase when there is some space for learning and making less or more controlled mistakes. The third one when team is able to work on itself without strict control, everyone knows what to do, making decisions doesn't require to control by TL, who become facilitator otherwise who would become bottleneck at that stage. Every phase requires different approach for TL. Book also describes how PM can help to develop team and hence project. It is stressed widely that good, motivated people create a good team which in turn produce brilliant projects.
Other notion which is widely described is so called bus factor. This is a person, for e.g. TL or other person who became knowledge silo to be so crucial that in case of losing such person, project is dead, or at least in big trouble. The best thing is to avoid such situations.
He also doubts in effectiveness or even counter productivity of traditional appraisal, when the former is rather focused on personal performance and results not results as team.
Last part of book consists from short excerpts from well known people in industry which describes one of facet of leading people, growing teams and so on. All are chosen by author and then shortly commented.
Author provides a lot of wisdom and hints for e.g. how to provide really valuable feedback. Not just getting at someone.
However reader can find a lot of nuggets in the book, all in all it could be better written.
Some useful quotations:
A good leader will challenge the team and the people around them to solve their own problems, instead of solving everyone’s problems for them.
Nothing beats gaining new skills. You and your team should always be getting better and going out of your comfort zone to learn new things. This is essential to what a team leader does. Becoming a team leader requires personal growth, rising to the challenge of knowing your team and what you can expect from them.
People don’t quit their jobs. They quit their managers.
Lesson: The fewer people you have who know an important part of your business, the more you will pay when they move on.
The best way to learn is to teach, and by teaching, the new person grows and learns the new task in a much deeper way than by being coached by the expert.
If someone is a bad influence on the team, for example, always pessimistic, your responsibility to the team is to remove that problem.
“My project manager won’t like me not committing to a deadline for when the bug is fixed, and committing to working on it a certain amount of time instead. She’ll think I’m just buffering.” I’ve heard this concern. I find that, with some patience, it’s easy to explain why some tasks can’t be proven to end by a specific time. Instead you can “cap” the maximum time you can “burn” on a specific commitment, and then regroup, replan, and recommit based on what you found. This is true agility.
You too will have to learn a new skill here: stop solving everyone’s problems, and begin mentoring and challenging them to solve problems themselves.
Challenge them to solve it on their own, with you as their mentor, but without you doing the work for them.
When someone brings up a problem or hindrance in the daily stand-up meeting, challenge them and ask them, “What are you going to about it?” to see where it leads. Help them figure out the problem, and don’t solve it for them. Teach them to solve the problem on their own. Most importantly, teach them the thought process that leads to the solution.
When people are challenged to solve their own problems, it’s important not to punish those who are unable to solve them. It’s their problem, and they will continue to suffer for it. The consequence is that they will keep having the problem. If they care about it enough, they’ll keep trying.
I think the best line managers are engaged in what their employees are doing, even if they aren’t in close physical proximity, and they can help by being coaches as much as being direct technical leads. It requires a bit of a mindset readjustment.
High-level managers secretly yearn for the mid-level manager who will get them out of the current messes they’re in charge of, while they take credit.
To be constructive, you need to offer a concrete suggestion for improvement, or you need to make giving feedback part of a problem-solving conversation. If you want someone to learn, create the opportunity and environment for them to discuss and contribute; otherwise, the feedback becomes more about the person giving the feedback than the person receiving it. Feedback needs purpose and it should enable purpose.
At a higher level, as a leader, conflict is an indication that the team is missing a skill: how to make a decision when there are multiple good choices. If, as a software team leader, it falls to you to make the big decisions, what does that indicate about the team?
I learned this from Jerry Weinberg, somewhere. The most difficult problems aren’t technical problems.
Robert C. Martin (Uncle Bob) One of the biggest mistakes that new software team leaders make is to consider the code written by the programmers as the private property of the author, as opposed to an asset owned by the team.
It’s the stuff you need to know in order to basically get around. Many times, the answers to these questions aren’t documented anywhere. It’s “tribal knowledge.”
I’d suggest that this is in direct conflict with the adoption and use of agile frameworks within the organization. Think about it: Agile emphasizes teamwork and cooperation in order to successfully deliver a product, with individuals being prepared to take on any task that needs doing in order to complete the iteration and get to “done.” Individual accountability, as valued by the traditional appraisal system, implies that individuals should be interested in taking the juiciest or most challenging tasks for themselves in order to prove their worth and progress within the organization. Agile emphasizes the forming of self-organizing teams that direct and manage their own work, whereas appraisals involve the setting of objectives that traditionally come from the manager. Agile processes emphasize constant process improvement. Although this can be done alongside traditional appraisals, appraisals are geared more toward making individual or process changes at review time.
Build learning and career development into individual user stories, perhaps in the form of a specific task that involves team members expanding their business domain knowledge. Alternatively, include time for learning tasks into your velocity calculations to increase the value of each team member to the organization by expanding their skillset ian a way that’s relevant to their immediate task. Let the individuals drive and organize this learning process as they would a normal development task.
Include team member feedback sessions as part of your iteration retrospective process, where you can directly discuss what people have learned. Encourage individuals, on an iteration-by-iteration basis, to maintain a body of evidence that can be directly referenced at formal appraisal time. This will reduce the time taken to plan and perform the appraisal and encourages the recording of tasks at the time they happen—when they’re most relevant.
The product will be as good as your team is.
Now I believe every little effort you make to improve your team infuses the products they create. You must be ready for that. Your behavior must change to let your people do their best.
Pay attention to people, and identify the phase your team is in and what it needs in order to evolve. Find the right leadership for that phase. Admit you can’t become the one and only leader, but you can be that person who turns mediocre teams into great teams: a great manager.
If you keep thinking about building products, these will only be as good as you’re able to manage and control your team. But if you facilitate the emergence of the full potential of your team, the product will be enhanced and enriched by many people and their synergy.
I’ve seen many team leaders, including me in my early years, give the less fun jobs to the reliables, as there’s less chance of resistance and conflict. In the short term, this strategy may work in your favor, but there are some repercussions: The team as a whole may begin to pass work off to the reliables. The reliables will eventually burn out. The reliables will become frustrated, and you’ll more than likely lose their respect. Internal conflict will arise because the reliables will separate themselves from the complainers. The solution involves sharing the load equally. If you gave a “boring” task to Member A today, give the next boring task to Member B—regardless of whether they complain. This will build up a culture of equality, with every team member having their share of learning opportunities.
If you want to become a great team leader, you need to stop being the team task dispatcher. Normally, a group of people will do a better job at this than a single person. Your job as the team leader is to allow this; make your team self-manage.
Remember that, like any new skill, mistakes will be made along the way. That’s okay. Mistakes are what people learn from. Don’t try to prevent them; just make sure the damage isn’t too bad and people learn from the mistakes.
The team should eventually grow to be a team of leaders, each of whom can ask important questions that might come from an objective perspective.
One of the most important lessons I learned is that if you keep your developers happy and motivated, they’ll consequently do some of their best work and will contribute to the betterment of the team and the organization. The tricks involved with keeping them motivated may initially seem counterintuitive to developers and/or management.
Another motivational technique can also make management cringe: you absolutely must establish that you prioritize quality over quantity.
That one statement sums up three of the common dysfunctions of a team: Absence of trust Lack of accountability Low commitment to the project
Acting as a command-and-control leader when being a coach fits the current situation brings poor results. Being “command and control” with a self-organizing team is disastrous.
Team leaders should seek critical technical debt that continually drags at the team, and look for ways to break down large chunks into smaller, more manageable chunks.
Agile development is all about shortening feedback loops.
Attempt to find a pace of change that doesn’t cause anxiety to team members. Using the discussed techniques can make change faster and smoother. Don’t become disheartened
; change takes time. Give others time, but ensure you are helping the process as much as you can
everyone needs to be heard. Then a decision can be made, even if everyone’s not on board. People who have been heard can feel committed to do things they don’t agree with, as long as they said everything they wanted to say, and they know it was considered. As long as you end up with “We considered this feedback, and we’re going to go with X anyway,” people can still follow the decision.
The advice is often presented under the Japanese name Gemba, which says the manager ought to be there where the work happens in order to understand how healthy the organization is and to help solve any problems people might have, using facts and not assumptions.
Most professionals in a field don’t understand that specialists in another field don’t speak their language. Team leaders provide translation services to ensure everyone heads in the right direction.
the value of technical leadership—to facilitate the team to the best solution, not your solution.
By establishing yourself as the sole tech lead, you become the main bottleneck for decision-making. You also turn into a bus factor. Without you, the team can’t function, which is a huge risk.
defensive and began experimenting a little. I inadvertently demonstrated that it was okay to try something and fail, which unlocked a whole new style of working.
February 13, 2022
J’ai un avis mitigé sur ce livre. A la fois il est essentiel car il met l’accent sur des points fondamentaux de la gestion d’équipe – je vais y revenir – et à la fois il se révèle extrêmement resserré et pourrait presque se résumer à quelques pages. Ce dernier point est particulièrement vrai pour le dernier chapitre consacré à la reproduction et au commentaire de courts articles d’autres contributeurs – si ce n’est pas une façon de remplir des pages et de vendre du papier qui n’apporte pas grand chose mis à part la désagréable impression de s’être fait berner. Ceci étant dit, venons-en aux parties les plus intéressantes.
La matrice du livre se concentre autour de la notion de phases dans la constitution des équipes et du style de management qui devrait évoluer en fonction de chacune de ces phases – je pense que c’est la notion d’élasticité qui a été retenue pour le titre du livre. Je reprends ces différentes phases en les détaillant dans mon article The Three Team Phases, mais en voici la liste ainsi que le type de management vers lequel tendre.
- Mode survie: Diriger en mode command-and-control.
- Phase d’apprentissage: Passer en mode coaching.
- Auto-organisation: Devenir un facilitateur.
Cette notion rejoint un peu celle des équipes soudées (Jelled teams) introduite dans le très bon Peopleware. Il est vraiment intéressant et même essentiel de garder ces phases à l’esprit pour ne pas agir à contretemps ou à contre-emploi. Utiliser ce que l’on pense être de bonnes recettes au mauvais moment ne donnera pas de bons résultats. C’est par exemple le cas si l’on emploie une posture trop command-and-control alors que l’on s’adresse à une équipe autonome, ça risque vite d’agacer tout le monde et de mal se passer. J’ai aussi trouvé particulièrement judicieuse la métaphore du flipper ou comment on commence par perdre du temps en apprenant de nouvelles techniques avant de passer un palier et de devenir meilleur. Bref, un livre qui introduit un concept clé sur la constitution et la gestion des équipes mais qui nous laisse par ailleurs sur notre faim.
Également publié sur mon blog.
La matrice du livre se concentre autour de la notion de phases dans la constitution des équipes et du style de management qui devrait évoluer en fonction de chacune de ces phases – je pense que c’est la notion d’élasticité qui a été retenue pour le titre du livre. Je reprends ces différentes phases en les détaillant dans mon article The Three Team Phases, mais en voici la liste ainsi que le type de management vers lequel tendre.
- Mode survie: Diriger en mode command-and-control.
- Phase d’apprentissage: Passer en mode coaching.
- Auto-organisation: Devenir un facilitateur.
Cette notion rejoint un peu celle des équipes soudées (Jelled teams) introduite dans le très bon Peopleware. Il est vraiment intéressant et même essentiel de garder ces phases à l’esprit pour ne pas agir à contretemps ou à contre-emploi. Utiliser ce que l’on pense être de bonnes recettes au mauvais moment ne donnera pas de bons résultats. C’est par exemple le cas si l’on emploie une posture trop command-and-control alors que l’on s’adresse à une équipe autonome, ça risque vite d’agacer tout le monde et de mal se passer. J’ai aussi trouvé particulièrement judicieuse la métaphore du flipper ou comment on commence par perdre du temps en apprenant de nouvelles techniques avant de passer un palier et de devenir meilleur. Bref, un livre qui introduit un concept clé sur la constitution et la gestion des équipes mais qui nous laisse par ailleurs sur notre faim.
Également publié sur mon blog.
December 28, 2020
I'm pretty sure the issues about software development that the author brings up will be very familiar to you if you have any experience as a team leader. But the main value of the book is not in bringing them to you attention; it's in its call to action: inviting you to do something about them instead of passively accepting the state you're not satisfied with. It leads you through the author's vision of steps required to reach the ultimate goal of a growing and learning team striving to always do their best job possible.
The second part of the book consists of contributions by other authors. Instead of being directly related to the first part, their short notes take different, often thought provoking, aspects to the job of a team leader: usually presenting a potential issue and giving a suggestion how to solve it. They are a nice extension to the core book and give a lot of value on their own as well.
I can definitely recommend reading the book to any team leader, no matter how much experience he already has in his job. Even if you don't agree with everything, I'm pretty sure the book will act as an eye opener and make you more aware of stuff you already take for granted, although there might still be opportunities for improvement. You never know, it might even make you a better leader.
The second part of the book consists of contributions by other authors. Instead of being directly related to the first part, their short notes take different, often thought provoking, aspects to the job of a team leader: usually presenting a potential issue and giving a suggestion how to solve it. They are a nice extension to the core book and give a lot of value on their own as well.
I can definitely recommend reading the book to any team leader, no matter how much experience he already has in his job. Even if you don't agree with everything, I'm pretty sure the book will act as an eye opener and make you more aware of stuff you already take for granted, although there might still be opportunities for improvement. You never know, it might even make you a better leader.
December 6, 2017
The book is OK. Some good advice for young team leaders. The main idea of the book is that a leader should adapt its leadership model, depending on the "mode" the team is in:
1. survival mode
2. learning mode
3. self-organizing mode
1. survival mode
2. learning mode
3. self-organizing mode
November 15, 2021
That was a good read. Bad things first:
- There were some obvious places (I hope that You will find it obvious as well) like learn from failures, don't be afraid of failing, spend more time with Your team, etc.
- Some repetitions. The context was mostly different but the morale was the same.
- "Roy's analysis" in the last chapters. It feeled like "I will do the thinking for You".
Good things:
- I didn't think about survival mode of the team before. I was trying to avoid command and control at all cost, always. This book changed it. Command and Control is a way to go, if You want to help the team get out of survival mode. All chapters related to survival, learning and facilitation mode were great.
- Commitment language chapter is pure gold.
- Chapter about learning is well written. I have read/heard about pushing yoursefl out of comfort zone many times, but Roy is somehow conviencing here - it feels like he really wants You to do this by describing what happened to him and how You will feel.
- The last part of the book is interesting - different great guys from IT (Uncle Bob, Dan North, ...) wrote few chapters about leadership and their expierence in the topic.
If you are somehow into leader role, You should definetely check this book out.
- There were some obvious places (I hope that You will find it obvious as well) like learn from failures, don't be afraid of failing, spend more time with Your team, etc.
- Some repetitions. The context was mostly different but the morale was the same.
- "Roy's analysis" in the last chapters. It feeled like "I will do the thinking for You".
Good things:
- I didn't think about survival mode of the team before. I was trying to avoid command and control at all cost, always. This book changed it. Command and Control is a way to go, if You want to help the team get out of survival mode. All chapters related to survival, learning and facilitation mode were great.
- Commitment language chapter is pure gold.
- Chapter about learning is well written. I have read/heard about pushing yoursefl out of comfort zone many times, but Roy is somehow conviencing here - it feels like he really wants You to do this by describing what happened to him and how You will feel.
- The last part of the book is interesting - different great guys from IT (Uncle Bob, Dan North, ...) wrote few chapters about leadership and their expierence in the topic.
If you are somehow into leader role, You should definetely check this book out.
December 3, 2015
This book is just awesome. Had read Roy Osherove's Unit testing book earlier and once I saw this book mention became very curious to explore. Spending time with this book was really worth.
It's a must read for any software technocrat or leaders (new-bee TLs, experienced TLs, architects, managers and of course the developers) who works with an organisation or team. Everybody would have something the other very important to gain from it. It shows how and why we should be pushing our bars, need of it, purpose of it and the benefit of it...
Roy speaks about what is the importance of a learning plan for every team or the individual team member(s) and how important is this to be realised by their TL/Managers and to provide the required support and encouragement. The whole book is divided into Elastic leadership, survival phase , Learning phase, Self organising phase. The 3 phases of a good team which is very much required for the survival. On top of that there are around 25+ advices with some of well known leaders/technocrats/gurus like Uncle Bob Martin, Gary Reynolds, Patrick Kua....etc.which covers up the above bold styled values and explains them still better.
It's a must read for any software technocrat or leaders (new-bee TLs, experienced TLs, architects, managers and of course the developers) who works with an organisation or team. Everybody would have something the other very important to gain from it. It shows how and why we should be pushing our bars, need of it, purpose of it and the benefit of it...
Roy speaks about what is the importance of a learning plan for every team or the individual team member(s) and how important is this to be realised by their TL/Managers and to provide the required support and encouragement. The whole book is divided into Elastic leadership, survival phase , Learning phase, Self organising phase. The 3 phases of a good team which is very much required for the survival. On top of that there are around 25+ advices with some of well known leaders/technocrats/gurus like Uncle Bob Martin, Gary Reynolds, Patrick Kua....etc.which covers up the above bold styled values and explains them still better.
February 11, 2018
"There are no experts. There is only us." - the motto from one of the first chapters is fascinating! There is a good piece of battle proven wisdom in these few words. Same true for the rest of the book, liked it very much!
Roy writes in the first place about importance of learning and growing people, which are undoubtedly essential principles in engineering teams. Maybe I am lucky, or maybe the industry has changed over the course of the last years - not least due to SW Craftsmen like Roy - but in most of the teams where I happend to work, the power of investment in professional skills was undisputed truth. Sometimes too undisputed, as the learning just for the purpose of learning could be seen now and then.
The last chapter - collection with a dozen of short essays from partially very well known Authors - feels unfitting. Altough every single advice is very valuable, I am still missing the structure of first chapters.
Roy writes in the first place about importance of learning and growing people, which are undoubtedly essential principles in engineering teams. Maybe I am lucky, or maybe the industry has changed over the course of the last years - not least due to SW Craftsmen like Roy - but in most of the teams where I happend to work, the power of investment in professional skills was undisputed truth. Sometimes too undisputed, as the learning just for the purpose of learning could be seen now and then.
The last chapter - collection with a dozen of short essays from partially very well known Authors - feels unfitting. Altough every single advice is very valuable, I am still missing the structure of first chapters.
August 11, 2016
Pretty good book. It is split into two halves. First half it written by Roy and is his advice for leading teams. Second half is a collection of short essays (1 - 3 minute reads) written by others offering their advice.
Roy's advice seems pretty good. I can see fragments of his advice in some of the better leaders I've been around.
The gist of the book is that there are three different modes that a team can live in; survival, learning, and self-organizing. Each phase requires a different leadership style.
There was also some interesting thoughts around commitment language.
One annoying aspect of this book was the numerous typos and formatting issues. If doesn't happen enough to make the book unreadable. When it did happen it was jarring.
Roy's advice seems pretty good. I can see fragments of his advice in some of the better leaders I've been around.
The gist of the book is that there are three different modes that a team can live in; survival, learning, and self-organizing. Each phase requires a different leadership style.
There was also some interesting thoughts around commitment language.
One annoying aspect of this book was the numerous typos and formatting issues. If doesn't happen enough to make the book unreadable. When it did happen it was jarring.
October 16, 2019
If you ever doubt or question yourself whether you are doing the right things on technical leadership, this book provides you with nuggets of technical leadership essentials. I myself can relate to my leadership journeys, especially during my startup days. The book is light and easy to read. I particularly like the concept of the three team phases and how each phase requires a certain leadership style and responsibilities. The notes to software team leaders are also insightful and interesting to read.
January 7, 2014
Very good! Gives a lot of of inspiration and a clear framework on how to lead software development teams.
July 28, 2023
En general, una buena lectura.
El libro describe tres tipos de "modos" (estados) en los que se puede encontrar un equipo y tres tipos de liderazgo que deberian aplicarse de acuerdo al modo:
- Modo supervivencia - Liderazgo de control y comando
- Modo aprendizaje - Liderazgo de coaching
- Modo de auto-organizacion - Liderazgo facilitador
Me hubiese gustado que el autor brindara mayor cantidad de estrategias para que un equipo en modo supervivencia pase al siguiente modo de aprendizaje, ya que me quedaron muchas dudas sin resolver:
- ¿Qué hacer cuando, a pesar que el lider motiva y brinda momentos de aprendizaje, los miembros del equipo no sienten interes de capacitarse para que el team evolucione al siguiente modo?
- ¿Qué camino tomar cuando el equipo esta cómo haciendo lo minimo indispensable y piensa de manera individualista y no en el crecimiento del equipo como un todo?
El libro describe tres tipos de "modos" (estados) en los que se puede encontrar un equipo y tres tipos de liderazgo que deberian aplicarse de acuerdo al modo:
- Modo supervivencia - Liderazgo de control y comando
- Modo aprendizaje - Liderazgo de coaching
- Modo de auto-organizacion - Liderazgo facilitador
Me hubiese gustado que el autor brindara mayor cantidad de estrategias para que un equipo en modo supervivencia pase al siguiente modo de aprendizaje, ya que me quedaron muchas dudas sin resolver:
- ¿Qué hacer cuando, a pesar que el lider motiva y brinda momentos de aprendizaje, los miembros del equipo no sienten interes de capacitarse para que el team evolucione al siguiente modo?
- ¿Qué camino tomar cuando el equipo esta cómo haciendo lo minimo indispensable y piensa de manera individualista y no en el crecimiento del equipo como un todo?
March 12, 2024
This book could have ended after the first hundred pages, cutting out the second part that is very short sections from external contributors.
The first part had two key concepts for me
1. The three phases of a team: survival, learning, self-organizing. How to match these phases, how to move between them.
2. Ownership and a language of commitment: "I will do X by Y" and "What are you gonna do about it?" when folks bring up problems.
That's what I'm getting out of this book. Still recommended reading it for the first hundred pages.
The first part had two key concepts for me
1. The three phases of a team: survival, learning, self-organizing. How to match these phases, how to move between them.
2. Ownership and a language of commitment: "I will do X by Y" and "What are you gonna do about it?" when folks bring up problems.
That's what I'm getting out of this book. Still recommended reading it for the first hundred pages.
May 22, 2022
I didn't find too much of value in the book. Basically, your #1 job is to grow your people, and not solve people's problems for them. If you find yourself in survival mode, figure out a way to get back into learning mode, where you can move slower and have people learn new techniques. But it didn't contain enough stories or specific practices to actually be valuable and have me use or even remember the techniques after finishing.
July 19, 2020
This was a pretty good, quick read, but it seemed a bit dated or for team leads who have been under a rock for the last 10 years and are still doing top-down waterfall development. It also assumed that the manager knows more than the engineers on the team, which has not been the case for any team I’ve worked on. The short essays at the end were good.
April 14, 2023
A highly practical book that I can relate with my personal experience in leadership roles, as will anyone having evolved into such a role from being a developer. But I would likewise recommend it to leaders coming from non-technical backgrounds for the insights it provides into the everlasting balancing act between quantity and quality of development.
July 8, 2024
The first of the book delivers good insights and useful tips from a seasoned team manager. The second part though is just a loose collection of articles by guest Authors that feel a bit like "throwing a lot of opinion and see what sticks". There are some interesting takes in there but they are purely built on "trust my words" and lack a proper basis.
December 22, 2018
I really liked this book: the idea behind the "elastic leadership" is something that I've never thought of and it will be something to think of going forward.
With hindsight, I recognize all the phases referenced in the book, and how I failed to deal with them.
With hindsight, I recognize all the phases referenced in the book, and how I failed to deal with them.
January 9, 2022
Good book. The main idea revolves around the three stages in which a team can be:
a) Survival mode
b) Learning mode
c) Self-organization mode
The book is easy to read, the writing is fluid, and there are a few experts providing their own experiences on ways to lead in agile workplaces.
a) Survival mode
b) Learning mode
c) Self-organization mode
The book is easy to read, the writing is fluid, and there are a few experts providing their own experiences on ways to lead in agile workplaces.
March 7, 2025
It's not often you find software books talking about the psychology of teams, offering practical advice and referencing other books and materials. This is exactly what is within this book and is useful for any new or established team lead.
June 2, 2017
3 stars as i found the book too short, found it helpful nonetheless
July 21, 2018
There are just notes. Helpful notes for a technical team leader.
December 2, 2018
Great introductory book for a new teamleader, full of non-nonsense advice.
January 27, 2019
Nice hands on examples - as the title says - notes. Would be nice with a more elaborate book an extension of the notes :)
October 31, 2019
one of the lower quality tech leadership books I have read. half the book is blog posts. the other half is poorly organized and thought out.
December 28, 2019
Book split into two parts. I liked first one (author writing about team modes and how leader should adapt to them). In second part few guest authors are presenting short articles on various aspects of software leadership).
What I remember from this book:
Three modes/phases how team operates
1. survival mode
2. learning mode
3. self-organizing mode
And three ways how leader can support the team:
1. Command and control
2. Coaching
3. Facilitator
What I remember from this book:
Three modes/phases how team operates
1. survival mode
2. learning mode
3. self-organizing mode
And three ways how leader can support the team:
1. Command and control
2. Coaching
3. Facilitator
Read
November 5, 2024Experiences from experts! I'm replicating.
April 25, 2021
2 stars - 'It was ok'
Ok, where do I start. This book is disjointed reiteration of the same (in my opinion questionable and idealistic) idea that there are survival, learning and self-management phases in software teams lifecycle.
Normally I'd give this book 3 stars because there are some sound ideas here and there and there was a very good part about the commitment language. However after reading it I can say that it has one major flaw that makes this book downright dangerous. Let me reiterate, if you are 'new' to the management of software teams do not take everything in this book for granted and do not follow everything you will find here. Take this read as any other self-help book: pick what you like, forget the rest.
The biggest downside of this book is same as it is in mediocre self help books: it is good at highlighting the issue, it is bad at providing any solution to it in many cases (yes, 'do good things to get good results' is not revolutionary enough to write a book about it).
However sometimes when it does provide a solution it can be downright harmful.
To focus on the last part, the author of the book misses the point that management is about dealing with people, up down and horizontally it is all people, who in their majority are very emotional. Author's suggestion of pushing your agenda on people until they agree and if they don't, and they hate you as a result of this, it is their problem, and you should leave the company and 'try' it again in the next one is terrible.
Second major flaw is the assumption that every single software engineer comes to work to learn something and everyone is super excited to get out of their comfort zones. Best case scenario if you follow this book you get a team where few people will learn some skills not very related to their job. (That is only possible if your team members were interested to begin with in their professional growth) Worst case scenario following advices in this book you will make enemies with your upper management and with developers who (surprise!) are adults and might (surprise!) have their own lives, world views, goals, moods and agendas that might not align with your desires for them to learn.
Ok, where do I start. This book is disjointed reiteration of the same (in my opinion questionable and idealistic) idea that there are survival, learning and self-management phases in software teams lifecycle.
Normally I'd give this book 3 stars because there are some sound ideas here and there and there was a very good part about the commitment language. However after reading it I can say that it has one major flaw that makes this book downright dangerous. Let me reiterate, if you are 'new' to the management of software teams do not take everything in this book for granted and do not follow everything you will find here. Take this read as any other self-help book: pick what you like, forget the rest.
The biggest downside of this book is same as it is in mediocre self help books: it is good at highlighting the issue, it is bad at providing any solution to it in many cases (yes, 'do good things to get good results' is not revolutionary enough to write a book about it).
However sometimes when it does provide a solution it can be downright harmful.
To focus on the last part, the author of the book misses the point that management is about dealing with people, up down and horizontally it is all people, who in their majority are very emotional. Author's suggestion of pushing your agenda on people until they agree and if they don't, and they hate you as a result of this, it is their problem, and you should leave the company and 'try' it again in the next one is terrible.
Second major flaw is the assumption that every single software engineer comes to work to learn something and everyone is super excited to get out of their comfort zones. Best case scenario if you follow this book you get a team where few people will learn some skills not very related to their job. (That is only possible if your team members were interested to begin with in their professional growth) Worst case scenario following advices in this book you will make enemies with your upper management and with developers who (surprise!) are adults and might (surprise!) have their own lives, world views, goals, moods and agendas that might not align with your desires for them to learn.
Displaying 1 - 30 of 73 reviews