--- title: "Step #1 – Claim Your Territory, Own your team" url: "https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.md" canonical: "https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.html" published: "2009-09-05T15:54:31+00:00" updated: "2009-09-13T22:04:24.001000+00:00" tags: ["First Steps during chaos", "Shu"] author: "Roy Osherove" description: "Many dev leads don’t seem to easily see that their territory is constantly compromised by people from the outside. Compromising territory can be in many simple forms, but they all hurt the leadership and ownership aspect you have as a…" 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/" --- # Step \#1 – Claim Your Territory, Own your team Many dev leads don’t seem to easily see that their territory is constantly compromised by people from the outside. Compromising territory can be in many simple forms, but they all hurt the leadership and ownership aspect you have as a lead. as yourself these questions: - **Do you get to choose the way you implement the features requested by customers, or do you get told how to implement them?** > Internal team implementation decisions that weren’t specifically asked by a customer or have nothing to do with a feature’s integration with other technologies usually should stay fully internal to the dev team. Things like _what technology or language to use_, _what type of database to use_ and others are things the dev team needs to figure out for themselves. > > It’s up to you to go up to whoever is doing this and say “The way we implement features is not your problem. Just tell us _what_ you need, don’t tell us _how to build it”._ > > A good technique to see why this is happening is to ask yourself and whoever is telling you this, _why_ they feel compelled to tell you how to do your job. you’ll find that most times there is a deeper issue underneath that needs to be solved. > > this is where [the five whys](http://en.wikipedia.org/wiki/5_Whys) technique helps a lot. - **Do people feel the need to come by and tell specific team members what to do instead of going through you?** > You should be the only entry point to your team. Your team depends **on you** to make sure they get as least distractions as possible from the outside. > > Go up to whoever keeps asking them things find a way to make sure you are the one asking people to do things, and not anyone else. In fact, if you are using [some sort of a kanban system](http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html), such a thing will not even be necessary. The key takeaway is that you must be in charge of the boundaries that your team operates within, or you quickly lose control of what is really going on, and find yourself mostly running around trying to see what people are actually doing instead of making sure that the right things get done. --- ## 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/