I have reached the point in my career where I want to move into a pure management position. That’s not to say I don’t want to write code anymore, or won’t, but that I want my daily activity now to be managing a development team. Part of the reason is that I have simply lost the passion for writing software that I once had. Most of it, though, is that I think I can do more as a manager these days. I crave the chance to mentor others, and to help a team achieve the best it can. Finally, I’m a little tired of being subjected to really bad managers, and I think it’s high time I put up or shut up. The following are my thoughts on what being a good manager requires.
Before I begin, however, I want to say that I’m a pretty big nerd, even though my nerdiness is no longer my prominent personality trait after transitioning. As such I want to tell my fellow nerds that you probably already know a lot of good management techniques because of the media you’ve consumed. For example, Star Trek is a great showcase for management styles both good and bad. Comic books, movies and TV shows have been showing what it takes to be a good leader all your life, and whether you realize it or not, you’ve most likely encountered a lot of what I’m about to tell you.
Communication
A good team runs on its ability to communicate. A good manager must learn how each member of their team best interacts with others, and then not just facilitate, but foster that interaction. Dev teams have so many ways to stay in touch these days. We have a plethora of online chat tools, the favored being Slack. We often sit in proximity of each other so that we can just talk to one another. And then there is the omnipresent daily stand-up where everyone catches each other up on their respective activities. So one would expect that it should be easy for a team to talk to each other, after all, they have all the tools present to do so.
The problem is that a lot of people are not good at talking to each other, especially in person. And this goes doubly so if there is some sort of problem they are bringing up, whether that is related to the project, the job, an individual, or even just a difficulty they themselves are having. As a manager, it’s my job to help them overcome that difficulty. There are several ways to do this. The goal of each is to let them know that no matter what their concern is, they will be listened to.
For the shy employee that never seems to talk or always seems to get talked over, I have to make sure that they have a chance to speak, and to speak with authority. The first step is the aforementioned daily stand-up. This gets everyone accustomed to speaking in front of each other. Then in other team meetings, be sure to ask them their opinion. However, don’t do it in an aggressive open-ended way, such as, “What’s your opinion?” That puts someone on the spot, and they’ll often shrink from the spotlight and get defensive. Instead, ask them specific questions pertaining to their expertise, such as, “We know we can implement X in iOS this way, how would you recommend we do it in Android?” This calls upon their critical thinking and sidesteps their emotional center, and since they know the subject matter they’ll be engaged immediately. Also, it gets the rest of the team accustomed to seeing this team member as the subject matter expert they are.
Good leaders want everyone on their team to contribute and be heard, after all, we never know where the best idea is going to come from. Even if it’s not someone’s specialty, they may still have an insight that leads to the best solution. Managers have to be sure to take in all the relevant opinions they can before making a decision. Remember how Captain Picard would sit in his ready room and expect everyone to contribute, no matter how insignificant they thought their idea might be. Diverse opinions lead to more discussion and options. So my goal is to keep the team talking until either we’ve found a solution or we’ve exhausted our options for the day. But it’s also my job to realize when we don’t know enough to find a solution, and should therefore stop to do more research. Pointlessly hashing out a concept, either when no new ideas are forthcoming, when the team is too tired to continue, or when a good solution has already been achieved/agreed upon, is detrimental to morale.
Leadership Style
I have two major analogies that I use for leadership style: Kirk vs Picard, and the platoon lieutenant. Now, before anyone decides to nitpick my analogies, let me offer my apologies. Please know they are simplistic reductions and generalizations meant to convey a point.
Kirk v Picard
Both James T Kirk and Jon Luc Picard we’re captains of the USS Enterprise on Star Trek, but they had polar opposite leadership styles. Kirk was an egotistical hothead who often would only heed his own advice. Furthermore, he firmly held to the concept of my way or the highway, meaning that if you did not agree with his lead you were expected to not say anything about it. Picard on the other hand, expected his team to work together to solve problems, and to correct him if he had wrong information.
Both captains did surround themselves with a competent crew and expect them to be experts in their fields. The difference came in how they led their crew. Picard would rarely attempt to override his team and instead would expect each of them to be able to lead in his stead. This was often seen as Picard himself did not usually lead away teams. Kirk, on the other hand, was always the first one out the door. Sure, he trusted his team in their specialties, but not much further. He did not trust them to make decisions without him.
To me the lesson to take from Star Trek is that as good manager, I need to surround myself with competent team members who are experts in their fields. Then I must trust them to be able to get the job done even if I’m not present. My job is not to build the product, it is to enable my team to do so. If I can’t trust them to do that, then I’ve got the wrong team members.
One last comment on Star Trek. Under Picard, we often witnessed leaders mentoring their team. We saw almost every manager do this: Picard with Data and Riker, Geordi with Barclay, etc. Furthermore, you would see those mentored crew members get promoted and commended for doing well. Good managers are invested in seeing their team members grow. I want to see my team get praise, awards and promotions for doing a good job.
The Lonely Lieutenant
A military lieutenant is in essence a facilitator. They sit between higher command and their platoon. A good lieutenant will shield their platoon from superior command while at the same time providing whatever the platoon needs to accomplish the mission. The most significant aspect, I believe of a military officer, beginning with the lieutenant but going all the way up, is to be both arbiter of their command and mediator between their command and higher officers.
To me this means that whenever my team does well, they get all the praise. Conversely, whenever they team fails, I take all the blame and shield my team from retribution. If a member of my team has a problem, or perhaps is a problem, I should try to resolve it before getting my manager or HR involved. If I can do this, not only is the problem resolved, but they don’t get any black marks from other managers that might hinder their progression. On the other hand, I do have to know when it’s time to call for reinforcements and bring in HR or my manager to help resolve an issue.
In general, I want my team to be viewed as a single unit to the rest of management. I want their achievements as a team noted, but not really their failures. I tend to think that their failures are more of a reflection of my failure to properly lead or provide for them. If I did not do something right, I don’t want my team to take the blame. If I screwed up and need help in getting my team where they need to be, so be it. I don’t get to have an ego in this. I can take pride when they succeed because I helped them get there, but I have to be vigilant to make sure my ego stays in check. I’m not the one doing the work, they are. I am more replaceable than they are.
I also want my individual team members to be recognized for their outstanding work. I will not hesitate to praise them to my managers, or nominate them for awards that they have earned. Furthermore, if they have earned a promotion, I need to make sure they get it. I also have a responsibility to ensure that they are growing their skill set. In the tech world, skills get stale really fast. I have to do my best to stay on top of new training opportunities for my team, even if that means that I learn something just to pass it along. After all, I can’t let my skills get stale either.
Conflict Resolution
One of the most basic responsibilities I have as a manger is to resolve conflicts within my team. This can be anywhere from a simple disagreement on coding style to a heated argument over the best way to architect a new feature to personality conflicts. Ideally, I would like to be able to resolve the issue myself with a simple conversation, but that is not always going to be the case.
If there is a technical disagreement, then my gut is to go with the expert on my team. If this is the lead or architect, and my opinion differs, so be it, that’s why they are on the team. They are the expert, and I’m inclined to trust my team. The only justification I would have for overriding a technical decision is a business one. Unfortunately, that does happen, and honestly, no one likes that. In cases where there is no clear expert, I will listen to both sides and use my expertise to make a decision. That’s what a leader has to do, but I also have to make sure I am not being biased in my decision. Furthermore, I have to communicate my decision in a clear, unequivocal manner that indicates technical merit only, without making the choice seem personal at all. Even when I manage that properly, it will not always be taken as such, and sometimes I will have to take a team member aside and let them know I have nothing against them personally.
Personal conflicts are another problem entirely because those can escalate beyond my capacity to resolve. First, I must determine what the conflict is, and try talking to the individuals involved. If the conflict is something I can not resolve, I will have to ask HR for advice, or even simply turn the problem over to them. Some conflicts, such as obvious harassment, are not in my perview to resolve; instead, with those I get HR involved immediately.
People who work close to each other every day are going to eventually have a conflict with each other. That’s just human nature. I don’t want to punish any one for that, but I do want to resolve it quickly. For this, there is an escalation path that I feel is appropriate: myself -> my manager -> HR -> upper management, where my manager and HR can be interchanged depending on the type of conflict. The key, I think, is understanding the severity of the conflict at hand, and how much intervention is appropriate before escalation. That sometimes just comes down to a judgement call, and I do my best to call it correctly.