This past year, I had the fortune of forming a team from the ground up. This involved determining ahead of time what kind of folks we wanted on the team, what values we were going after and how we would detect these in the interview process.

Having been part teams of several shapes and sizes, I knew exactly what went into making a team successful. You see, building software is much like a team sport – you need players that can operate in a collaborative setting and be pleasant (tolerable, at the very least) to one another.

I wanted folks that were talented and kind. In that order. Being talented, obviously, was bare minimum. You need a certain amount of technical acumen to work the job. The challenge is in finding such folks and then filtering out anyone that wasn’t kind

What I didn’t want was having to deal with entitled jerks who are talented. This can show up in so many different ways.

1. Arrogance - people who think they are smarter than everyone else
2. Entitlement - inflated sense of investment vs return; think they deserve a promotion for simply showing up
3. Irritable - easily ticked off at the slightest inconvenience
4. Argumentative - enjoy haggling over minute (ultimately irrelevant) details
5. Attached - getting defensive in code reviews, refusing to pivot along with business decisions, always upset about the quality of code no matter how good it is

This sort of negative attitude has a very distinct effect on everyone. It affects team morale and permeates into all sorts of interactions, meetings, code reviews, debugging and handling production issues.

Nobody wants to work with an asshole.

Think about it - you spend your best hours in the day at work. You want work to be nurturing your skills, enabling your creativity and overall enriching your career. You want colleagues who appreciate what you are good at and are capable of helping you get to the next level. You don’t want to spend this time dealing with jerks and worrying about personal dynamics.

In interviewing and talking to people, I’ve realized that it is easy to find people on either sides that are exclusively talented or exclusively kind but finding the combination is tougher than you think. Kindness is hard to suss out in an interview. Behavioral questions help a bit.

Another tip that I’ve found that works well is adding in a junior member to the interview panel. Some people are really nice to peers and manage above really well but are dicks to those working for them. This is the same concept as having the front desk person weigh in on the hire / no hire decision.

If you think you can only be kind when you are in a position of giving (advice, support etc.), then you’re wrong. You can be a junior person on the team who needs help and support and still be kind. I wanted to breakdown how kindness plays across the board depending on what level you are in.

Junior engineers

Entry level and junior engineers are fantastic. What they lack in skill or experience, they make up for in passion, interest to learn and the fearless energy they bring. I’ve had some great interns, coops and entry level engineers.

What does kindness mean from a junior person? .

• Asking for help - this one is tricky. You don’t want to straight up ask for help without trying anything. You want to try a bunch of things. You want to be respectful of whoever is taking time out of their day to help you out so providing as much context as possible is ideal. Here’s a decent template - do not overshare.

I am working on X and running into an issue with Y. How do I Z? I’ve tried the following approaches (A,B and C). Can someone help me out?

• Learning to unblock yourself is one of the best ways to participate in a team as a junior engineer. Usually when you’re blocked, it becomes someone else’s responsibility to unblock you. Can you think of creative ways to unblock yourself and produce work while things are being figured out? That is a great gift to the rest of your team so people can step-in and help but without that urgency. Eg. Is the backend not ready? Can you assume some JSON and keep moving? Is the functionality unclear - can you implement one part of it and have a conversation? Is the design impossible to implement? Can you show what is possible to implement?
• Not asking for too much help - don’t be that person that always needs help. Take some time off to learn or skill up whatever is needed.
• Acknowledging who helped you out when you provide updates. I’ve seen this often - someone is stuck and they need help. But when they are unstuck and they provide an update, there will be no mention of how much help was provided. It would be really nice to give a shout out to whoever helped you out that took time from their work to step in and keep you moving.

Senior engineers

• Don’t be too attached to code - Be able to empathize with business decisions and not be too attached to the code. Sometimes businesses need to change directions and if it happens too often it can be really disrupting. But I’ve also noticed, sometimes, when engineers put in a lot of time in a project, they get attached and cannot pivot. I think being able to move on and not be too attached to code is a sign of maturity and kindness.
• Able to empathize with the user’s perspective and problem solve in any given situation. This one is tricky because I’ve seen that more engineers have a skewed perception of UX than not caring about UX. In such cases, it’s okay to have a strong opinion, but listen to reason especially when you PM backs things up with data - your opinion on what the UX should be is not that important if it is conflicting with data or what the PM wants. Ultimately, it is their job to own that and you’re welcome to share your input but also know when to back off.
• Be willing to explain technical things to non-technical people in a polite manner. This is the true test for a senior engineer. How tolerant can you be of upper managment or PMs or designers who are not tech savvy and how well can you articulate a concept to them. I’ve seen folks on both ends of the spectrum here. Some folks are so articulate in expressing technical ideas in lay person terms while others struggle or get upset when there’s a lack of understanding from the other side.
• Being willing to offer help and mentorship without being asked. This might sound controversial like I am recommending that people just thrust their advice on others. That’s not what I mean. I’ve seen some really helpful senior members walk around and talk to folks that are working and see if they need help with anything. This, of course, used to be a lot easier when everyone was in the office but you can still offer to pair with someone without being asked as it opens up venues to have folks reach out to you for help in the future.
• Learning and Sharing so everyone on the team benefits. This helps push the boundaries and get people excited about working on projects. Being able to intermingle technical endeavors with roadmap features is a great balancing act and one that makes you a desirable person to have on the team.

Managers

• Being respectful of people’s time is the #1 aspect I look for in a manager. Scheduling meetings by paying attention to time zones and people’s availability. Not bothering people outside of standup unless absolutely necessary.
• Never cancel 1:1s - a 1:1 is a serious time to talk to an engineer about their career and help them reach the next level. So canceling a 1:1 sends the wrong message. The engineer could request for it to be canceled and that’s okay if they need focus time but try and never cancel a 1:1 as it indicates that you don’t care about their personal growth. Having regular 1:1s and check-ins really help understand what’s going well and what’s not going well with your team.
• Be clear and direct. I wrote about this in detail in a differet blog post here. Ensuring you provide feedback with enough time to course correct. Being able to provide critical feedback in a polite but direct manner is a big part of being someone’s manager.
• Avoid burnout - in this day and age, there’s just a lot going on in the world. If someone seems to be firing on all cylinders, it’s a good idea to plan some downtime. This can be applied at a macro-level to the team as a whole. Did the team just finish an intense project? Let’s work on some research spikes and refactor tickets to cool off a bit before the next projects kicks off.
• Ensure engineers stay focused and not get distracted. As a manager, it is your duty to be an umbrella or a shield to the team. One that prevent politics, sideways-requests and context shifts from penetrating your team. This helps your team stay focused on the task at hand.
• Keep upper management accountable - sometimes upper management tends to make promises and it is your duty to ensure they deliver when your end of the bargain is met. Did your team member deserve a promotion after this project went live? Did the team want to go to a conference? Ensure that upper management remains accountable for any promises they made. This could be anything from time or resources or green-lighting technical endeavors or focusing on longer term investments.

What’s the takeaway?

1. Finding folks that are talented and kind is hella hard
2. Being kind works at all levels - whether you are an entry level engineer, a senior engineer or a manager
3. Being kind is cool