How to deal with a team lead direct report that acts unprofessionally?

Question

I am a team leader. I have a team member who directly reports to me and who came from a small company and who had strong programming skills and very very poor communication skills and poor corporate etiquette. He is also in the role of module lead.

He wants to concentrate only on programming and hates meetings or anything related to organizing, planning and managing. As a team leader I need his involvement to plan, organize and manage the deliveries. And I am having a very tough time to get his participation in those activities. He doesn't even like sending status mails to myself and other stakeholders of the project or assignment that he is involved in. When I ask him to send mail or something he in return asks me to do it instead of him. The reason behind this is that he wants to spend more time on programming and related activities.

He has poor listening skills also. In any discussions he quickly jumps into the conclusions and reacts emotionally. At such situations it is very tough for me to get the discussion back on track. Most of the time, I exclusively instruct him to listen carefully till I complete before he speak. While in the discussions itself I usually remind him that I am not done and to listen patiently until I finish my speech.

In any of the meetings with project stakeholders and higher management, he quickly jumps into the conversations or discussion when I am leading those, and tries to speak or tries to add his points. Most of the time his points deviates the discussion or creates confusions instead of adding any value to the discussion. I feel it would be better if he discusses that point with me before he speaks in the meeting. Sometimes his untimely and unwelcome intervention leads to unwanted expectations from the team for other stakeholder which again I have deal with.

Any comment or feedback or opinion which is not positive about him or his work or his way he feels very emotional about and sometimes it leads to emotional and heated arguments which are very tough for me to handle.

In our organization we don't have the basic tools for tasks assignment and tracking etc. though we have barely sufficient tools for development. Mostly we have to depend on Excel sheets. I tried to simplify the process by creating Excel trackers which has again certain amount of manual intervention requires like to update the Excel by end of date and publish across the team etc..

Unfortunately I cannot take the decision about tools, infrastructure and etc. All I can do is suggest for the tools and put request for the tools. But getting approval from the other teams like hardware and infrastructure department and higher management is very difficult. There is highest possibility my request get rejected. I am also suffering here due to lack of tools. But this is an organization and management decision; I cannot help here myself.

He doesn't even like to send any tracking and preparation mails. He wants to give updates orally and would like to finish the conversation as soon as possible. And I usually have a tough time to probe for more information. I have to give justification for each question that I am posing.

Answer 1

In the end, the only correct answer to any question about managing a troublesome team-member is "Understand their motivations, react accordingly."

We can't really tell you what his motivations are. I can hazard a guess, because I've been accused of most of the things you describe, but that doesn't mean that we're similar people. It would just be my projecting my own frustrations in the workplace onto your team member, which might be right, but equally might not be.

The only way to truly understand a person's motivation is to listen to them. A lot.

Take them out of the office, into a comfortable location and ask a few gentle probing questions. And once he starts to talk, listen. Rands in Repose told us all how to do this in an excellent article called The Update, The Vent and The Disaster.

Same time each week. When you become a manager of people, an odd thing happens. You’re automatically perceived as being busier. Whether you are or not is irrelevant; folks just think you are. Consistently landing your 1:1s at the same time on the same day is a weekly reminder that you are here for them — no matter how busy.

Always do it. Ok, so you are really busy. You’re running from meeting to meeting. It’s easy to de-prioritize a 1:1 because unlike whatever meeting you’re running to or from, a 1:1 doesn’t represent an urgent problem that needs solving. I’ll beat this perceived lack of value opinion out of you later in this piece, but for now understand that each time you bail on a 1:1 they hear, “You don’t matter”.

30 minutes, at least. Another favorite move of the busy manager is to schedule a 1:1 for 15 minutes or less. It’s the best I can do, Rands. I’ve got 15 people working for me. First, those 15 people don’t work for you; you work for them. Think of it like this: if those 15 people left, just left the building tomorrow, how much work would actually get done? Second, if you’ve got 15 people working for you, you’re not their manager, you’re just the guy who grins uncomfortably as you infrequently fly by the office, ask how it’s going, and then don’t actually listen to the answer.

The one thing I am almost sure of is that the person you're talking to is not being malicious. Most people aren't. (If he is one of the few then be sure of that and then fire him.)

When people react emotionally in inappropriate situations, it's usually because nobody's giving them an appropriate situation in which to vent their frustrations. So, give him that, I think you'll be surprised how easy this problem is to fix.

He'll tell you what he wants, if he believes you're listening and that you're on his side. If you can't give it to him then tell him that (and tell him why, so he understands), straight up, and encourage him to think of an alternative.

EDIT: One last thought, which might be obvious, but is worth stating anyway.

Don't do this only for the person who causes you problems. For one thing you shouldn't single him out. For another, you shouldn't encourage bad behaviour by letting him think he's now earned himself a special status.

But worse, you might also find that other people are quietly seething about the same issues. If you leave them seething, they might eventually blow, in a much more destructive way than the individual who allows his frustrations out at any opportunity, even when he shouldn't.

Answer 2

Unlike pdr, I'm not afraid to project :). Reading between the lines, I see someone who knows he was hired for his strong programming skills put in an environment where you don't have the basic tools most of us take for granted. For example, most version control systems can be integrated with ticketing systems, often free ones. For example, we use SubVersion and we've integrated it with Trac. So if you don't have a ticketing system, likely you don't have version control. And if you don't have version control, that implies there are many issues with your code and environment that he may be scrambling to deal with.

This guy may be in a situation where he feels pressure to perform as a programmer, but he is in an environment where that is very difficult. So he may well feel that even if he spends 110% of his day doing the programming tasks you've hired him to do that he can't meet your expectations because of the environment you've put him in. I've been in this situation, and it leads to the symptoms you've described--cutting people off who you feel are in the middle of making a point they already made so you can get it answered and get back to work, being defensive so people will realize that you're in a difficult situation, and saying "no" a lot so you can finish what's on your plate before they start piling on more tasks.

From his point of view, he may feel that the programming tasks are ones only he can do, whereas the communication tasks can be offloaded on someone who can safely spend attention on it without affecting the critical (to him) tasks he is engaged in. This is a vey "programmer" way to look at things--the tasks are being accomplished in parallel, each by the resource that is best equipped to handle it.

You may want to look at exactly how much pressure this guy is under and figure out whether there's a way for you as his manager to relieve it. Keep in mind that some of this pressure may be internal to him--he may have set goals for himself that you're unaware of, and his drive to meet those goals may override your expectations of him to communicate more. If the pressure is external, you may need to buy him a little space so he feels comfortable devoting time to things that he may perceive as detracting from his ability to meet (possibly unreasonable) deadlines. If the pressure is internal, you may need to just talk with him so he gives himself permission to devote time to tasks that you value.

Answer 3

In our organization we don't have the luxury of tools. Mostly we have to depend on Excel sheets. I tried to simplify the process by creating Excel trackers which has again certain amount of manual intervention requires like to update the Excel by end of date and publish across the team etc..

Tools are not a "luxury." At least not the tools mentioned so far (bug trackers and version control). These are extremely basic ways for developers to more effectively produce good quality code and to concentrate on creating value for the customer.

Time spent creating a custom tracker in Excel would be much better spent installing and configuring an existing free tracker. Even the best VBA programmer in the world would need literally thousands of hours of work to implement the basic functionality of any major bug tracker. Using a bug tracker means that everybody can update information at the same time without collisions (a fundamental problem with any shared single document), which already means less time spent for each update to check whether anyone else is editing, lock the document somehow, and then unlock it at the end.

Version control is another extremely important tool for developers. If that is not available, then quite simply don't be surprised if you can't hire good developers.

Providing such tools will benefit you as well: Most version control and bug tracking systems are excellent at automatically creating status updates. For example, in both Git and Bugzilla, getting a list of the changes in the last few days is trivial, and you can often tweak the amount of detail these reports contain. This doesn't require any additional work from the developers except a basic knowledge of how these tools work.

---

It is important to keep in mind that he is most likely aware of above. As you mentioned, he has "strong programming skills" - this means in particular that he is capable to detect routine activities and sense that these can be made easier. This also means he is capable to search and discover efficient tools for particular jobs (otherwise, one could not qualify his skills as "strong").

Because of that, it would be safer for you to assume that he is aware about wide variety of affordable, feature rich and efficient project management tools - even quick web search reveals an example list of such tools at respective Wikipedia page, along with many other resources.

Taking into account a likely awareness described above, it would be inaccurate to assume that he perceives lack of tools as a matter of simple inconvenience, it is really more dangerous than that.

From a perspective of a tool aware employee, such a lack might indicate either rather profound inability to resolve a simple management issue ("hey why don't you just check the list at Wikipedia and pick the affordable appropriate tool, it's that simple") or equally profound sense of negligence to their needs ("not willing to do such a simple thing shows how unimportant I am in your eyes, it's that simple").

Note how either of these perceptions come against top two of famous Packard's principles:

1. Think first of the other fellow. This is THE foundation — the first requisite — for getting along with others. And it is the one truly difficult accomplishment you must make. Gaining this, the rest will be "a breeze."

2. Build up the other person's sense of importance. When we make the other person seem less important, we frustrate one of his deepest urges. Allow him to feel equality or superiority, and we can easily get along with him...

This essentially destroys his trust in your managerial skills which in turn makes it really hard to collaborate on any matters.

---

As for dealing with the employee directly, you can try setting up regular 1:1 meetings with all the developers to understand challenges and frustrations before they are vented at the biggest available group. This person may be verbose and confrontational, but the concerns behind might be shared by others in the group (or conversely, may be considered unimportant). As pointed out after the jump, it is difficult to establish useful 1:1s, but it can defuse conflict before it spreads.

Answer 4

I work with people like this all the time. What you have to do is cause there to be a benefit to him of doing what you want. It's too large-grained for the only benefit to be keeping their job.

So, this person doesn't like meetings. You don't like what he does in meetings. You want him to send emails and update work items or tracking items or status lists or whatnot. This can totally be worked out.

1. Make the process as lightweight as possible. For example a work tracking tool that's integrated with the programming tool so that you just select something from a dropdown when checking in a change, and the status of the item is updated for you (Visual Studio Express does this paired with hosted TFS, which is free for 5 devs or less. Great tools don't have to cost tens of thousands of dollars)

2. Give him what he wants in exchange for doing what you want. "If you get that status email to me by 9am, I'll have time to look it over and ask you anything before the meeting, and you don't have to come to the meeting." "If you send me a point form status email I will make it into sentences and send it to all the stakeholders." "If you set aside 15 minutes for a one-on-one we can update the status document together and I will do the typing"

Bring benefit to him, let his job be more like what he wants it to be, and your value is clear. Many developers see PMs and project leads as shields to keep management and users away from them so they can code. If you're willing to be a shield for him, he will help you with what you need to do that.

I have sat with devs and support people and helped them to enter and update "tickets" and items in various trackers. Once walked through it a few times, they start to gain from it. When someone interrupts them for status, I point out that they can just look in the tracker (and leave the dev alone) and after that happens a few times the dev starts to see the point. Nothing is more frustrating than somebody interrupting your progress to ask about your progress! You can patiently teach this dev that pro-actively reporting and updating status will leave plenty of time to code in peace. If the dev doesn't like typing sentences, you can help with that. Getting the progress rolling (and seeing for yourself where the pain is - updating shared Excel sheets is pretty darn awful) will make a bigger difference than correcting and pestering the dev to do what they are not motivated to do.

Answer 5

If these skills that you describe as week or non-existent are important to his role on the team, then the selection of this employee for that role was wrong or the training was an issue. If they have never done these tasks then they were not properly trained on what is required in the role, or the training did not pickup a reluctance to do those tasks.

If they see their only real role as coder, then that may be the role for them. An unwillingness to communicate properly (to their team, to your team, to customers) is a sign they either aren't ready for this, or may never be ready for this role.

Emails delivered on a set schedule on a set topic are not managing. These emails are quickly viewed as a chore, especially if they appear to be nothing more than something to check a box. Walking around to all parts of the team on a regular basis, with you then keeping notes when you get back to your office, can relieve reluctant communicators.

I can produce for you a regular email, everyday that makes you believe that steady progress is being made; or that we are overcoming difficult hurdles; or that we are is desperate need of additional resources. If that is your only window into progress you are not leading the team.

Regarding communication with the clients. It might not even be necessary to have him there. I have known many people who were very happy never to talk to the clients.

You need to boil down the essential skills need for the task , both programming and non-programming. Then you need to decide what that person can do now, can do with additional training, and what they will never be able to do. Then you need to find a way in your team to mitigate these issues. That can be additional tasks for you, or somebody on your team; or a change is role for them.

Answer 6

Personally I believe you have a person who is in a role he is not suited to fill. Once you take a lead position, coding is your secondary responsibility and it should take up no more than 50%- 70% of your time (personally I go with 50 but he is a module lead not an overall lead, so maybe 70% is more appropriate). I would sit down with him and ask him how much time he thinks he should spend on management tasks vice coding and then tell him your actual expectation of the split between the two and then ask him if he would rather be a developer than a lead if the two estimates are way out of whack and he is not willing to change to your estimate. Having a lead who devalues time spent managing means you don't have a lead.

Answer 7

It could be a direct personality clash. I was one of two Team Leads for a particular company. The other Team Lead had a developer who sounds extortionately like yours. As the problems grew and the difficulties increased, the developer was moved to my team. I managed to turn him around by seeing the problems he had with the other Team Lead and using a different set of criteria to motivate and challenge him. In many respects I was more assertive, challenging and harsher (as in setting aggressive time-scales, and really taking apart his work and making him do it again) to him. This caused him to thrive, especially as I listened a lot to what he had to say and put him forward to conduct show-and-tells and speak directly to senior management about projects. After three months, my manager discussed a promotion for this guy with me and we duly did it. Three years in the other team he went no-where, six months on mine, he turned himself around and shone.

Ultimately, I did little different from my Team Leading colleague as all the basic managerial processes were the same across the teams. It really did boil down to my personality was different.

I'm not intending to be overtly critical of the OP, but there is a world of difference between Team-Leadership and Team-Management. It read to me that the situation is more of a managerial process based one, rather than actual leadership.

Answer 8

It will help you cope with your situation if you reconcile with several irefutable truths:

1. Software engineers are skilled knowledge workers who do not like to do paperwork. They like to program.

2. Software engineers, at least good ones, as was said above, easily detect operational pitfalls (e.g. "In our organization we don't have the luxury of tools. Mostly we have to depend on Excel sheets." and too many useless meetings) and, because they are talented knowledge workers they are easily annoyed by that circumstance and being subject to have to do more drudging, meaningless, bureaucratic work because their managers were sloppy or cheap to invest in proper infrastructure. If they are good, they will not put up with that and will go work elsewhere. I am noticing the tone of your exclaiming that you do not have tools as though you are almost proud of that (akin to "when I was 8 years old, I had to walk to school 11 miles through snow") whereas it is quite an embarrasing state of your organization.

3. Your associate, according to your account, likely has Asperger syndrome. Guess what, that's the scientific term for the ultimate nerd to whom most of technological achievement can be attributed. You don't like Aspies, their introversion and awkwardness and you'd rather have your developer be a frat boy used car salesman with ... uhm ... people skills? Well, the frat boy don't know how to program. How about reverting back to the Stone Age if interpersonal skills are so important? You can't have both. If you want software built well, you will need to adjust to the nerdy types.

My final answer to you is to accommodate your Aspie associate. I see myself in him 100%. Why should someone who knows how to program be required to sit in meaningless meetings half a day? Or be filling cover sheets on their TPS report? Put some thought to your process and make it lightweight for everyone's benefit. Once it becomes simple and streamlined, perhaps your associate won't mind spending 10 min a day submitting necessary artefacts to keep everyone in the loop.

Answer 9

It sounds to me like your coworker is very creative. Guess what? Managing creative people is a creative field in itself. I'm reminded of a skit from Hee Haw:

Patient: Doctor, it hurts every time I move my arm like this! Doctor: Well, stop moving your arm like this then!

If you're tired of having arguments with him, stop arguing with him. I don't claim to have all the answers. However, I'd like to point out that you do have two reliable solutions: convince someone to fire him. Or quit your job and work some place else.

As you deal with this programmer, you should bear one thing in mind: the problems you're having with him may very well also be the things that make him useful to you. What I'm hearing from you is "This is a very competent employee. However, at our company we expect people to behave in x manner, and this employee is not behaving in this manner."

I completely understand the need to have a common direction and some common rules. However, research has shown that (broadly speaking) it's a good thing for organizations to have their dissenters. In fact, you may actually consider this a "good problem to have". Some people just march to the beat of a different drum, and not only is that ok, you should probably be encouraging it.

On the other hand, your organization has practical constraints. You can't let this employee act in such a manner that it brings everyone else down. My suggestion is to think practically. Identify two things:

1. The major battles that are truly worth fighting. I tend to ask myself what I'll say about it 20 years from now. In 20 years time, will you really say "I wish I had gotten him to communicate via email better"? More likely is that you'll find yourself saying something more along the lines of "I wish I had found a better way to harness his talent. Boy, he said some funny things in meetings though."
2. The low hanging fruit. Things you can fix without much problem. I suspect that by the time you've gotten to where you are, you've probably already fixed most of these things. Nonetheless, it's worth looking out for.

These are the things you need to do something about. My suggestion is to fight the urge to just "fix" the problems in category 1, because you probably won't be able to fix them. That said, if you and he are able to figure out a couple of important, concrete problems to focus on, chances are solving them will be much easier.

Answer 10

Why did you hire this person/why did he accept this job? Somewhere a disconnect occured when matching this person with this position. Of course a programmer doesn't "want" to do non-programming things, but if he took the job and agreed, I would suggest sending him home and allowing him to return when he's ready to work.

Take advantage of the skills he does have. If your company thinks they can hire and compensate top-level programmers by making them some type of manager, this is a perfect example of why this is a mistake. You're losing money every minute he's not programming. He wants better tools, tell him to start implementing and integrating some of the open source products. Let him share and teach the other devs how to use them. You'll get a larger return on the investment in this person if your other programmers can learn something from him. Put him on the tough projects. Let him build the repositories, frameworks, and API's that can be leveraged by others.

Improved Meeting Strategy I hate it when a manager pulls me into a meeting where they have a clear agenda of how to handle the client/situation, but never bothered to explain it to me beforehand. It takes great effort to avoid contradictory opinions and getting off-topic. Meet first. Let him know this is the time for dissent and when you get into the meeting, be a team player and stick to the plan whether you like it or not.

Communications Anyone who has an aversion to communication better learn to STFU hold their tongue at my meetings. You don't get to have it both ways. Of course, you should avoid putting this person into this situation in the first place.

Answer 11

Another approach is to start small. Status emails to yourself are a nice safe place to start. As the team lead/manager, it is perfectly reasonable for you to ask for a weekly (or daily) status email. I'd actually want to start with daily to improve the communication between you two. It's not a big deal for him to send you an email once a day.

And ultimately, we all do things we don't like. That's why we get paid. If someone wants to code without interacting with anyone else, that's coding a s a hobby not a job.

When talking to him, this is an important point. That our job is NOT to code. It's to produce value for the customer. Coding is part of that. Not all of it.

Answer 12

The worker may be quite creative as previously mentioned, or may be highly focused on problem solving (the problem as he understands it) and be much less concerned with the big picture (creating software that meshes seamlessly with other groups projects, for example).

An idea I have would be to demonstrate to him some of the problem he may be introducing by being so focused and unwilling to communicate with others. My idea is to write up an exercise for all of the team members to complete at the start of a (low priority) meeting. The exercise should begin with an instruction such as "This exercise is for discussion purposes; errors are expected, and are acceptable. Please read through the entire exercise before beginning." (Bring extra pens in case people only have pencils, and have the pens available near you, probably in a small pile in front of you, but don't hand them out.) Have a space at the top labeled Name: (where they would fill in their name) ;-)

The idea of the exercise is to ask for answers that will change based on information (additional details) provided later. It is a trick exercise, hopefully demonstrating that a worker assuming that he understands the needs well enough and not coordinating status and updates will lead to mistakes and rewrites.

Assuming all team members are programmers), the exercise might be like this:

1. Write a simple program or flowchart that includes the steps of inputting user names and addresses, assigns them a client number, and prints out the client number and user names and addresses.

   (include a blank half-sheet of paper.)

2. Users should be able to sort the data by a number of identifiers, including the client number, the client's name, the client's city, the client's zip code, the client's telephone number, the client's SSN, the client's account open date, or the client's last transaction date.

   (Include a blank about third of a page.)

3. Please use only a pen for your work, and do not discuss the exercise during this meeting.

4. Important: Please disregard the above instructions. Instead, only write your name at the top and put a check mark by instruction numbers 1, 2, 3, and 4, and quietly wait for the others to finish.

---

After about two minutes, say Thanks, that is all the time we have for this. Please turn in your work where you left off. Then proceed with the normal meeting.

Probably many or most will go through the instructions starting with 1, then 2, instead of reading all of it first and just doing what 4 asks. This is your opening for that employee, or if you wish, for the entire group, either singly or as a group (but singly would be better for a better conversation with the problem child) about the value of sharing information, keeping current on changing needs, etc. Be sure to apologize for the trick, but you did want to have a way to point this out in a low cost fashion, as opposed to major rewrites that could occur costing overtime, bad reviews, etc.

Answer 13

I was once a team lead of the software development of my company for over 2 years and I have observed that many times the productivity of each team member relied on their level of motivation and for some recognition. I once had a guy in my team with relatively more experience than other members and I really needed his input. I realized after a number of talks to him that his lack of cooperation was because he didn't want to be treated like other members of the team. what I did was to give him some responsibilities and made reference to him. This way he became more cooperative so I Tried to find or create a responsibility and place him in charge of it, more like let him lead in an area. So you may need to come up with something very creative like Jason said. the whole point is to try to find a way to put him in charge/responsible for something so he feels a sense of responsibility and valued and many times it works. I know it can be frustrating managing such a person. A similar way to express this strategy is giving workers opportunity to create "impact" in forbe's "The Top 9 Things That Ultimately Motivate Employees to Achieve"