One of the hardest things to learn about software engineering is that engineers are not all the same. If you are trying to build a team of twenty engineers, you might have five amazing engineers, ten solid ones, and five who are struggling. For the five engineers who are struggling you might have three who are doing work that they do not do well with. This is natural for large teams because sometimes the business demands do not perfectly align with your team’s skill set, and you need to absorb some discomfort to get to the finish line. If you do not believe me, try to go buy hot dogs for nine people. Big Grocery will fail you in perfectly accomplishing this task.
The remaining two engineers are probably struggling for various reasons, and need you to actively manage them in order to make them “successful”. I put “successful” in quotes because sometimes successful means “successful somewhere else”. You cannot always save everyone.
Today let’s talk about those three engineers who have the wrong task. I have found that you can largely group engineers into two buckets. There are engineers who will take any task and embrace it, either through passion for technology or an abundance of curiosity. There is also a bucket of engineers who either do not have that passion for technology, or possess just a modicum of curiosity. They may have a desire to focus on one tech stack, or merely wish to stay in their lane over the course of their career.
You might see where I am going with this.
The three engineers struggling with non-ideal tasks are likely from the latter bucket, and this is likely where your engineering managers earn their keep.
Before I go any further, I want to point out that this is not a terrible thing. Business needs will change from time to time, and you will not always have a perfectly shaped team to deliver successful outcomes. In an ideal world you have a team of technology enthusiasts who love to jump from project to project and task to task regardless of tech stack and focus. I am blessed with a team right now that has an abundance of engineers like this.
There will be times when you will manage teams where this is not the case. Either there are people on the team who have a very specific skill set, or a desire to do a very specific kind of work. In some cases it will be both. I have had people on my teams in the past who have been focused on specific technologies that are needed in urgent situations, and are not very effective in other kinds of work. Do you give them research tasks to find additional things they like to work on, or do you ask them to do low-risk business tasks with the understanding that this is not how they want to spend their day? If you think about your team like it is a baseball team, there are ids of “position players” and “bench players”. Sometimes you will have people who will be needed on the bench to come out in a specific role. “Pinch hitters” are one of these categories of players. Other times you will see, in a baseball game that is being blown out, that a team will put a “position player” on the mound to pitch in order to save pitching arms. You will find that you will make more decisions to do these activities than a baseball team manager. A baseball team manager will think outside of the box more often as the post-season approaches. For an engineering team manager, most of your software releases have the same urgency as a playoff game.
There are a lot of tools you need to develop in order to make engineers successful in places where they are not comfortable. The first is for you yourself to get uncomfortable. I have always told people that it is important to become comfortably uncomfortable. The next thing is to figure out how to teach that habit and instill it in your teams, where applicable.
This is a great tool if you have team members who aspire to grow professionally. It encourages them to “embrace the suck” and to dig deeper into who they are as people to understand their limits and abilities. It is also not a tool for everyone.
Some folks are content to show up at 9:01 am, fill out their Jira tickets, close the machine at 4:59 pm, and go back to living their lives. There is this massive push right now to label these people “quiet quitters” and make it a pejorative term.
Yes. This means I have failed to “not talk about quiet quitting” this week. We will reset the sign to “zero weeks since we have talked about quiet quitting” and start again. The struggle is real.
This represents a significant amount of the labor force today and that amount is growing. I have spent a large part of my career being inundated with hustle propaganda. I can sense a part of my past self that wants to treat people who just want to do their job with some level of disappointment. At the same time I also know I am not in Kansas anymore, and that these are valuable members of the team.
Figuring out how to maximize output for your teams in these situations is hard. There may be morale issues, product issues, and even funding issues arising from an imperfect team. Sometimes you can remedy the situation by developing people, and other times you can remedy the situation by replacing people. Sometimes neither of these options may be acceptable. You might also be under a hiring freeze or some other situation where you must do your best with the hand you are dealt.
When you are faced with this situation it is easy to default to the new buzzword and start employing “quiet firing” tactics. I sincerely hope that you do not. That is a very dark pattern, and it is not good for the people on the receiving end.
In these kinds of situations I tend to conduct productivity experiments for people. A former peer referred to this as “meddling with warp core”. It is a good analogy. Especially since most times we are doing it while going warp nine. It is tricky to change things when you are trying to move fast. I also think it is important. Here are some ways I “meddle with the warp core”.
Can you introduce a team member to a new technology or type of work that is non-urgent?
Building tools for internal teams is a nice way to create value and give growth opportunities to people without blowing up production deliverables.
Can you give an opportunity for one of your aspiring leaders to try delegating and managing?
Another thing to do is to take some team members you are grooming to lead and give them a sense of the challenges they will face—under carefully controlled circumstances. Most of these wind up with the original developer reclaiming some tasks, but it is a good tool to get them to be aware of what they might experience in the future.
Can you leverage them to build a throw-away prototype?
In addition to your day-to-day business tasks, sometimes you will need something built to prove or demonstrate something. There are some downstream benefits to this because sometimes you need to build out part of a product or feature to reduce “unknown unknowns”. I have always found building out prototypes to be a great teaching tool in addition to a great learning tool.
Can you give them lower priority work from deeper in the backlog?
Finally, is there something less risky you can give to them that will fill out the team’s workload effectively?
For those of you who have worked with me in the past, you might recognize one or two of these things. I am always happy to share tools and techniques with people to help improve their teams and their productivity. The most important thing here is to try different things and to discuss them with the parties involved. This includes leadership. People sometimes have urges to bury these things from their bosses and managers, and I believe that is a bad idea. Sometimes you might even get suggestions from your boss on what to do!
Thank you again for reading along. I am sadge that I did speak briefly about “quiet quitting” this week. I did my very best not to. I shall comfort myself through this difficult time with a delicious keto snack. I shall even link it to you as an Amazon Affiliate so you may partake of its low sugar goodness!
