You’ve heard of “design smells” when talking about design patterns and software architecture. If you’ve got the nose for them, it’s a way to detect antipatterns or just bad practices that might be latent or nascent in your code base. Yet I’m loathe to use the team “team smells” in what I want to discuss in this post because this implicates real humans (not just their code), and I’ve been in too many conference rooms that smell like locker rooms by the end of the day. . . But maybe you see (or smell) where I’m going . . .
One of the things (“smells”) you might want to be watching for in your team is a heavy use of the word “they.” They are another team or another group in your company exposing some API, database, security service, or whatever. “They didn’t give us the API early enough.” “They changed the spec on us.” “They did it again.” “Their service crashes all the time.” “They don’t know what they’re doing.”
Steven Covey explored the circle of concern versus the circle of influence. The circle of concern contains the things you or your team are worried or fretting about. Maybe it’s the shitty documentation they produced. Maybe it’s their buggy code. Maybe they don’t know what they’re doing.
By contrast, Covey’s circle of influence is usually smaller. It’s what we, as a team, can do. The defensive code we can write. The ways we can help them solve the problem. They ways we can code around it.
Too often, the developers I’ve managed (and coded with) stray outside their circle of influence into their circle of concern and much too often. It’s usually disastrous. In a worst case, it paralyzes the team. In a best case, it plants the seeds of cynicism and distress. As a team lead, it’s tempting to drop into that war mentality, but when the team ventures outside their center of influence into their circle of concern, their effectiveness and their agile velocity plummets — and it’s insidious.