--- title: "12 Behavior Anti Patterns You Will Face As a Software Team Leader" url: "https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.md" canonical: "https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.html" published: "2011-04-11T18:54:37+00:00" updated: "2011-04-11T20:30:10.107000+00:00" tags: ["Anti Patterns", "First Steps during chaos"] author: "Roy Osherove" description: "Twelve team member behavior anti-patterns and three outside disruptions a software team leader faces in survival mode, with how to respond to each one." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 12 Behavior Anti Patterns You Will Face As a Software Team Leader Most of these, we covered today on the 1st day of [my Lead Better course](http://osherove.com/leadership-course/)  that is [taking place in Oslo](http://www.programutvikling.no/kurskalenderoversikt.aspx?id=938475), with live simulations. The purpose was to see how a team lead deals with these anti patterns when going through **[team chaos](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)**. How the team lead might act to these behaviors when the team is in [learning mode](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html), is very different than how I'd expect them to react when in chaos, as was simulated today. ## Team Member Behavior Anti Patterns 1. Extremely shy and afraid to say when he is done with a task. can be idle and helpless if you don't notice. 1. Lead needs to give 'simple rules' to that member so they know exactly what to do in a situation when they are idle. for example _"if you see that you're not doing anything, contact me immediately. We can't afford to have anyone not working right now"_ 2. If it persists, the lead can also offer a more assertive statement such as "_If you want to continue to be part of this team, you'll have to chip into the effort. I know this is hard for you, but I expect you to rise to the challenge and contact me if you don't have anything else to do"_ 2. Lazy, who only does the simplest thing, so he can say he did what he was told 1. Lead can be direct and demand more from that person, or alternatively remove them from the team until they can spend more time understanding why this is happening. 3. Negative - constantly saying things like "I knew that would happen" or "really? that would never work" 1. Same as with lazy 4. Would only work alone. does not like working with other people 1. If they do a great job on their own, and this is usable to the team lead to get out of chaos, there's no harm in letting that person work on their own. 2. If it hurts the team, or continues chaos, see 2.1 5. Is the designated 'architect' and refuses to do anything else 1. See #4 6. Constantly multi tasking on a different task 1. Either reset expectations to mgmt about not doing that other task  2. or remove that person from ccurrent effort and reestimate effort to mgmt 7. Only comfortable working with a specific kind of work (only on the GUI, for example) 1. see #4 8. Working really SLOWLY 1. They might be perfectionists. see # 12 2. If it doesn't hurt the team during chaos, no problem 3. If it does, find work that they CAN do fast, or much better than everyone else 4. If they can't do anything fast, put them on a low risk item, because teaching them to be fast takes time you don't have right now 9. Two team members who argue without any resolution on some technical detail 1. Argument isn't bad, until it's unproductive or bottlenecks the team, so.. 2. Ask them to choose which solution they want o try _first_ 3. Give them a time box to pick one solution to go with 4. Select the solution for them (it's chaos time) 10.  One team member follows another team member blindly, even when it hurts the current effort to get rid of chaos 1. separate them form working on the same task together until chaos is over and you can handle it 2. Ask influencer to stop influencing the influenced until chaos is over 11. Working on personal projects not mandated by anyone (remember, this is during CHAOS!) 1. see #4 12. Perfectionist in a time of chaos - will make sure everything is the right color, when the wheels are not even working.  1. Explain that this is not the time for perfectionism (unless that's what's demanded!), but a time to _ship_ so that chaos can be over fires are put out. 2. Give them simple rules to follow on when to stop:"_if you see yourself matching colors, stop and go fix something that's in the bug's list. do NOT WORK ON COLOR MATCHING in the next 3 days!"_ 3. If that does not work, use authority to ask them to stop (what other anti patterns do _you_ know?) ## Outside disruptions and anti patterns - Requirements keep changing - The lead needs to keep up or set expectations correctly - Impossible Fixed time, cost, and features - what would the team lead do in this case? - Ask which of three factors can be 'moved' - "I either need more time, or more people. If I can't have either, I will need to commit to less features. Here's what we CAN do" - "I need one of your devs for X time for a customer demo" - If it doesn't hurt current team tasks, no problem - If it does, explain that the team will need to re-commit to a different time schedule, or different feature set, if other people cannot be introduced into the team (even if they were, that also takes extra time to get them into the team and project culture) Since today was all about chaos, it was interesting to see how afraid people can be to be a little assertive to get things flowing again. overall, many behaviors which would fit a team in the learning stage, were exhibited for a team in a chaotic stage.  I feel that at least one person in the course has come out of their comfort zone more than a little during this task, and for that, I am very very happy. ## Read next - [The Chaos Addiction](https://www.5whys.com/articles/the-chaos-addiction.html): How survival mode becomes a self-reinforcing addiction that cuts quality and learning time, and why a team leader must take a risk to break the cycle. - [Daily Standup Meetings - Introduction and 5 useful tips](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html): How to run a daily standup meeting with the three questions, why each question matters, and five hard-learned tips for keeping it under 15 minutes. - [Step #1 – Claim Your Territory, Own your team](https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.html): Why a dev lead must claim the team's territory: keep implementation decisions inside the team, be its single entry point, and ask why outsiders interfere. ## Topic - [Survival Mode](https://www.5whys.com/topics/survival-mode) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/