Hello everyone! I am reaching deeper into my bag of made-up-things-to-talk-about. This week I want to severely abuse the english language and the notion of metaphors to talk about imperfect teams.
Throughout the course of your leadership career you will find that you have individuals on your team that are not quite perfect for their existing role. I find that figuring out what to do in those situations is one of the biggest challenges in team management.
It reminds me sometimes of this.
I have found that it is worth it to spend a little extra time making sure that everyone has the best possible role on a team, even if it is not perfect. I wanted to talk about a small handful of specific individual types I run into pretty regularly.
The obscure specialist
As systems mature and evolve you might find that you will have one or two people with an indispensable skill set. They are very good at one specific thing, and not so great at many other tasks. If this person was not employed here, and a specific piece of technology broke, your customers or your partners are going to have a bad time. A long time ago I worked at a startup where we needed to have a Flash developer around for emergency fixes for a legacy piece of software. This was not a full time job. The individual in question was a decent developer, but was not really suited for delivering back-end software, which was primarily what the rest of the team was working on.
So what do we do here? I find that I have to do a little calculus when this situation appears. The first thing you should do is to figure out the potential frequency of issues and the resulting dollar impact to your business. In this case it was used by a large percentage of our customers. An incident happening once a year would approximately cause enough of a cost to the business that would justify a year’s salary. Flash updates or security issues happened at that frequency year over year. So even if he did nothing all day but put out fires, it was a good return on investment.
That being said, I am not a fan of keeping team members on the bench and I know that most people who love making software dislike sitting around too. So the next thing to figure out is what they should do when they are not dealing with urgent software issues. Sometimes you can give them low-hanging-fruit tasks that they may not be terribly excited about. This is risky because it distracts other team members who may be needed to help train them or spend time improving code that may be sub-optimal. Alternatively you can make up some projects that better align with their skill-set on the legacy feature they are currently supporting. There is no perfect answer here. In the end you will likely experience a regrettable loss to your team and need to figure out how to find a contractor to deal with emergencies. Unfortunately this is not very cost effective.
The butterfly programmer
Engineers love shiny. Golang, rust, kotlin, there is a new flavor of amazing technology coming out every year and it is super important to learn the latest and greatest thing. Since everything ultimately resolves down to zeroes and ones in binary, what is the downside to staying current on leading-edge software development practices? The answer is “plenty”. There is a fine line between leading edge and bleeding edge. Early on in my career I indulged far too many people in letting them play around with new technology in production environments. They come in, get everyone using new tools and suddenly learn that sometimes the technology is not quite a good fit, or it is not production ready. This is when you discover if you have a butterfly programmer on your hands. A butterfly programmer will suddenly vanish at this moment, off to the next project or company, like a delicate butterfly going daintily from flower to flower sipping only the most delicious of nectars.
When someone wants to use a brand new technology on a project I stare at them real hard before saying “yes”. I want to make sure that if they inflict a new technology on the team they will be the sort to take it over the finish line and ship it. If I am not convinced that they will get it to 100%, I will likely refuse them their request the first time. If they are a butterfly programmer they will likely leave the team before they ask me again.
The squirrel chaser
This is another variant of an easily distractible engineer. The squirrel chaser cannot stay on task. Especially if it is something they do not love to do. Sometimes you will task someone with a two hour project and five days later it is not done. It is probably because they saw a squirrel, and who does not love chasing squirrels? This is a dangerous behavior. If you have something important that needs to be done, you have to be careful about giving it to a squirrel chaser. They are masters of coming up with reasons why they should ignore their clearly-assigned task and why this other thing is more important at the moment.
Sometimes you cannot fix your squirrel chasers. It is worth it to try. Quite often reactive live operations people are squirrel chasers. They love the thrill of fixing things more than the fulfilment of creating new things. I have found that the best thing to do for squirrel chasers in the long term is a role adjustment, especially if they are amazing squirrel chasers and there is a great need for their skills.
A dog named cat
In the process of making your teams you are likely hiring people. You only have a finite number of time and tools in the hiring process to bring people in. Sometimes you may wind up hiring someone unsuitable. Despite advertising “looking for a cat”, and counting legs, checking if it has fur, and seeing if it has a tail, you might actually hire the wrong animal. Welcome to having a dog named cat. So now what do you do?
In some places, employment law gives you a thirty-day window to evaluate an employee. Unfortunately that is a horrible and cruel way to solve a problem. If you were trying to hire a cat and wound up with a dog, that is clearly a misfire on your internal tools and processes. What I prefer to do in this situation is to see why exactly we hired this person in the first place and what can they contribute effectively on a day-to-day basis. I have had great success in bringing people into teams where I discovered that they were not perfect for the position, and were a better fit in a different role.
Sometimes I have also been successful in helping transform their skillset. You originally looked for a cat and now you have a dog. That is okay! I have successfully turned dogs into cats and I am convinced that it is worth it for you to try if you are in this situation. Even if you are not successful it is a valuable leadership exercise.
The leaky tire
Finally I want to talk to you about one of the more difficult edge cases in team management: The leaky tire.
Sometimes you will have an individual on your team who has variable output week over week. You might discover eventually that their performance is directly correlated to the level of praise or visibility on their projects. A car with a leaky tire will require you to stop moving forward, get off of the road, pump it up as much as you can, and then get back to moving forward. A leaky tire employee is the same thing.
I struggle with this one because it is hard for me to relate to leaky tires. I always have intrinsic motivations for everything I do. I will invest a few months of time into a leaky tire and see what the ratio of time invested to output looks like. I still do not have a one-size-fits-all answer for what to do with a leaky tire. If I have to spend five hours a week with a leaky tire, that does not scale well. If I have to spend thirty minutes a week pumping them up, I can keep that up for a considerable window of time.
A leaky tire will sometimes maintain a steady pace. Other times, they will subconsciously realize you are giving them a steady amount of positive feedback and start to require more pumping up without realizing it. When I find that someone is an unstable leaky tire, the best thing I have done is to instill gradual self-awareness of the issue. If you tell someone directly they are a leaky tire, they are apt to blow out nearly immediately. The best thing to do is to introduce them to the notion by giving them an example and saying “Hey look at that person, they are a leaky tire” and wait for self-awareness to hit. Half of them will react positively to the indirect coaching, the other half will get mad. If you think you have the latter case on your hands, it is best to be surprised and then say “I never thought of you that way before but let’s work together to understand this better”.
I tend to spend a lot of time trying to address this one because leaky tires tend to be high performers when they are “on”. If you can make them aware of their leaky tire issue and get them to correct it, then you have helped to transform them. This will accelerate their professional development tremendously!
So there you have five archetypes to watch out for on your teams. While not exhaustive, this is a list of engineering types that I have had the pleasure of helping over the years.
As always, thank you for reading. If you are struggling with managing some individuals and want to reach out to ask particular questions, I am always happy to help!
