Desirable Team Dynamics
Intro
After working in the software industry for as long as I have, I’ve come to the understanding that engineers are more often than not complex people, and in some cases are terrifically odd. Disclaimer: I am by no means a poster-boy for normal, that would be super boring. But at the same time, I mindful to keep my weird stuff to myself.
I shared a conversation with the manager of a hair salon a while back, and as we were talking I realized it’s pretty much a 1:1 parallel between the hair style industry and the Software world. Hair styling is talent based. You don’t leave an academic institution with a PHD or something and show up to your first job knowing how to use a pair of scisors to make someone’s average head of hair look amazing. That’s an actual talent that you develop with two ingredients: personal interest in the pursuit and legitimate experience with the labor. As it turns out, that’s pretty much how software engineering works too. Don’t get me wrong, I know some great engineers who have masters degrees and all that, but the academic insitution they went to wasn’t where they built their skills, rather it was their personal work on the side and internships that helped that made them great. I’m totally digressing here…
So the manager and I were talking about how the hiring process goes in her shop, and she actually does hiring the way start-ups do. The team gets a chance to meet the candidates, and they have a chance to air any concerns they may have about working with these perspective collegues before the hiring process concludes, things get plain out of hand and talent begins to flee the disrupted atmosphere of the shop. That’s on the extreme of end of the worst case scenario spectrum but let’s face it there are hair stylists and engineers out there who are straight up bonkers who any rational human being would avoid working with. I keep taking this sharp digressive hooks… I need to brush up on my writing quite a bit…
So what are some of the cliche problems with hair stylist candidates? Drug issues, difficult personallities, and inability to do the work. That’s exactly how it works in Software, only we prefer to use the phrase “Not having a good work life balance” as a critique over blatantly calling out people’s drug habits.
IDK
So what do I look for in a team? In the right environment, I’m something of a hard worker. Naturally I don’t like to carry a bunch of people who are less skilled than me, full of crazy BS and ideas, but still share my job title (or worse, are a notch above –something that happens frequently to people like me who are lousy at the job interview process. I at least like them to not BS that they have superior ideas than me. I’m not always right about stuff, but that’s what consensus is for. I feel as though consensus is the ultimate conflict resolver, and consensus works for free.
How Consensus Works
Wikipedia described it best years ago as that defined that “Consensus is NOT voting.” I think this is the most valuable definition because the most influential component of teaching someone consus is that, no, they don’t already know what consensus is, because consensus is different from voting. Here’s my favorite, more thorough definition of consensus:
| Consensus decision-making is a group decision-making process that seeks the consent of all participants. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the favorite of each individual. Consensus is defined by Merriam-Webster as, first, general agreement, and second, group solidarity of belief or sentiment. It has its origin in the Latin word cnsnsus, which is from cnsenti meaning literally feel together. It is used to describe both the decision and the process of reaching a decision. Consensus decision-making is thus concerned with the process of deliberating and finalizing a decision, and the social and political effects of using this process. - Game Theory Applications in Network Design |
I really like this idea in theory, but it requires that the members of the team take the time to consider alternative ideas to their own, and apply their critical thinking skills to determine the merits and demerits of said ideas, put their personal feelings aside, and then communicate their professional opinions to their team mates. Each of those tasks stands on it’s own as a difficult to master activity. So ultimately, unless its explicitly written into the teams process, this kind of collaboration doesn’t just happen.
The alternative seems to be to repeat one’s self to the extent that all other’s repeating themselves are too exhaust, or until you yourself lose interest in repeating yourself. This isn’t ideal. I’d be happy to work with people capable of listening to others and willing to help build consensus.
Ownership of Code
I feel as though I do my best work when I’m giving not only tasks to do, but also responsibility over areas of code. I feel like in most shop’s there are enough repos for everyone to own something to themselves. This creates a personal ‘safe-space’ for people to try out new patterns and to see what works for them, and what doesn’t. When I work in someone else’s repo, I find myself on my psychological tip-toes. In being so especially careful with my commits, I wind up wasting extra time, and also find that I can’t always write the greatest code of my life. When it’s always someone else’s repo that I’m working with, IE when it’s “the team’s,” I find myself wishing that I had a more independent space that I could grow my skills in at my own personal coding maturity level.
To stave off siloing, I feel as though every member of the team should
- Own one’s own repo, and
- Be responsible for visiting someone else’s repo
Visiting is important so that the on-boarding aspects of the documentation can be treated as frequantly as their importance demands.
Respectfulness
The one thing I absolutely require to happy on a team is a culture of respect. I don’t want to have to come into work and have to raise my voice or figure out the best way to counter-attack someone else’s attack against either my work process. I don’t enjoy hearing other people scolded in a heavy negative tone either. Often times this behavior comes from the disrespective employee’s insecurities about their career and just being around that attitude disrupts my own attitude.
I guess it works kind of like driving. Let’s say you’re on the road, and you’re just chilling, and sure there’s traffic ahead of you, and you’re going just the speedlimit. You want to take it easy, so you leave 5 car lengths ahead of you and the next guy, and somebody cuts right in front of you. You’re being chill, so you add 5 more car lengths and a few seconds later, someone merges in front of you again. At some point, you start to realize that you’re unable to actually keep a comfortable distance away from other people because the atmosphere you’re in wants to cram ahead of you simply to get ahead by 1-2 car lengths. There becomes no reasonable way to achieve comfort due to the environment we’re in. That sucks to be in traffic all day, and then to show up at work and be in yet another uncomfortable environment.
Capability/ Independence
When I make a hiring yay/ nah, I look for people who appear capable of independent productivity. It doesn’t help me having someone on-boarded who needs me to hold their hand every step of the way. That sort of leads me to my next criteria.
Hiring capable people resolves a lot of critical propblems that can take place in the work place. People who aren’t capable of doing their work, not only won’t help the completion of a project, but out of concern for being discovered as incapable employees, they will engauge in toxic behavior, pointing fingers at other people’s imperfections, whine and complain about the project’s overall direction in the hopes that everyone they’ve spoken to will be too busy critique the people being criticised, that they themselves will not be found out until very far into the project where they will hope to have solidified their role as “The person who tells everyone else how things should be done.” You might look at that positively as fate this person who wasn’t good at anything has found a way to contribute, but honestly, you don’t want people who don’t know what they’re doing being in charge of telling others what to do, it’s just a cluster duck of charades, participating in technological make-believe, and ultimately delivering low quality, over-budget products.
Humility, Eagerness to Learn, Receptive to Feedback
When people write resumes, it seems to be very common to tack on there “fast learner”. I think it’s a handy remark to throw out there because it’s imposible to prove throughout the span of a signle on-site meeting, and ‘fast’ doesn’t really have a hard definition. But when I do work with someone, I like to see that they’re able to show humility by even being shown something they haven’t seen before, and they pick up what I’ve shown them and are able to become somewhat independently productive thereon.
Peer review is a big thing for me too. I’m always eager for feedback on my own work because it gives me an opportunity to learn new tricks that I wouldn’t be able to learn without having to stop to read a lengthy book. I don’t like books getting between me and the keyboard.