Common traits of the best teammates I had

I've recently transitioned into a management position and was reflecting on the best managers I had and some of their traits, then that prompted me to think about the best teammates. That seemed like a more diverse set of people across roles, and felt like something I should explore more before thinking about the specific management ones.

These are not necessarily traits that I have today, but are definitely some that I am looking to develop further. Also, these are biased towards my perception of the those teammates and also how well did they do at an org. Either through getting things done or progressing on their career faster than others around them. So, take this with a grain of salt and don't feel like you need to do all of these. We are all learning and the org you are currently in might have a different appetite for different intensity levels of each trait.

Also, there is no particular order here. Other than I was writing as I remembered the people that had a lot of impact on me personally. I will also explore some of the anti-patterns related to each trait and how they could blow up, so that we understand these as a spread rather than a fixed point.

. High Agency

The folks that embodied this had an attitude of taking responsibility for an outcome. Sounds simple, but requires commitment. What is interesting is that they did not know everything about a subject and they were willing to say that out loud. They were willing to be vulnerable in front of others and to chart/discover/propose the path forward. You might have worked with folks like this before and heard things like "I will figure it out, I will make it work".

Then the anti-pattern to be aware here would be mixing project phases, or "jumping the gun" and starting to build something without understanding it first. Again, it feels simplistic. However, when you take into account competing priorities and "dude, but AI" it is easy to start working on something without understanding its parts in detail.

. Deep understanding of the business rules

And here, the ones that fully grasped how things worked on the "real world" were able to put put together superior software solutions. It was like night and day. Those actually came from their ability to comprehend the basic building blocks of a complex problem. I immediately recognized that the way they approached the problem, the way they explained the solution, and the solution itself, was actually a good model of how it worked on the real world.

Now the anti-pattern here is not understanding what kind of solution do you need. Focus on having a comprehensive solution before building something for the future. Most likely the solution you are building is not the best one, but thriving until will get you the opportunity to improve it. Superior understanding of business rules serving zero customers gets you nowhere.

. Clear communication

As these folks went deeper into the subjects they were working on, they would teach others about it too. Yes, sometimes they were wrong. Yes, sometimes people corrected what they were saying. They thanked, adjusted and continued. They would make sure working patterns were recognized and that common traits across different projects were understood as one. They did not carry the whole team in their head. To learn how the system was supposed to work, you just went to read what they put together without needing to ask them.

On the other hand the trap here is not understanding your audience. If you are creating some documentation for technical and non technical people, you should constrain references to technical terms to a minimum. Whereas, if you are putting together a material for technical people you must describe the subject with the appropriate level of detail. Failing here just creates a lot of confusion.

. Cheap to disagree with

The folks I have in mind here were easy to bring bad news to. You could tell them their design had a hole in it and nothing happened. No tension, no long thread, no follow up message later that day. They would ask what you saw, and usually they asked that before saying anything about their own position. When someone found a bug in their code they said thank you in the same channel where the bug was found, in front of everyone. I noticed that I would go to these people first when I had a half formed concern, because it was cheap to be wrong in front of them.

The anti-pattern here is a slightly defensive reply on a question. It is explaining why the concern is not really a concern before actually understanding it. Do that a few times and people stop flagging things to you. Then they stop asking you things. Then they route around you, and you start finding out about problems when they are already expensive. It gets hard to find out because nobody tells you this is happening.

. Made people visible

These people helped people get the visibility they deserved. When something shipped they named who did what, specifically, making sure leadership was reading. They said "this worked because X figured out the business logic," never just "thanks to the team." They did it in meetings where that person was not present, which is the part that actually matters. They also did it for the work that is not shiny, like the person who spent two weeks making the test suite reliable again. I remember being surprised the first time someone did that for me, because I did not think that piece of work was visible to anyone.

Now the anti-pattern is not holding people accountable. Of course we should not be burning people for making mistakes and we still need to make sure people understand decisions have consequences. Shipping fast without care has a cost with a team on it. Over the years I've seen the same bugs get "fixed" separate times, each time credited to "the team" until the eventually it took down a customer demo and the room finally asked whose service it was.

. Understood team safety

The ones who got this understood that their performance didn't stop with them. It affected the whole team. They were aware of the way they performed had an impact on people's perception of our team, and that impact never stayed with just them. So they made sure they were always on their best because other people were directly affected by how they showed up everyday. It might seem like a burden, but rather is an opportunity to influence how people interact with your entire team. The more you go up the ladder on your career the more important this becomes.

The anti-pattern here is only ever doing it for the team and never for yourself. You take the on-call nobody wants, you make the whole team look good in front of leadership, and at review time none of that work has your name attached to anything you can point at. I watched someone do this for years, always the one smoothing things over for the team, and when promotion time came the feedback was that nobody could describe what they, specifically, had done. They'd made the team safe and made themselves invisible in the same motion.

. Before you leave

Hopefully this gives you a little bit of insight about I think 😂, or some patterns that could help you in your career. Or maybe just understand how others are approaching growth. Regardless, none of it here is prescriptive but rather instructive. Stay safe out there.