How can I get a socially awkward team, which lacks good interpersonal skills, communicating more effectively? [closed]

Question

I manage a socially awkward team and this is leading to problems with communication.

Ever since I started at the company, and before I managed the team, I noticed how quiet the team was, and how reluctant they were to want to engage with others in the office.

My boss has now raised this as an issue to me, saying it is leading to other problems, such as not wanting to talk to other teams when doing so would quickly resolve matters. My team resort to using IT systems in place as a means to avoid making contact with others in the company.

It was put to me that my team, and others in the office, just don't work together as a team and the root cause of this appears to be a lack of willingness to communicate.

I know people on my team lack good interpersonal skills. They have little interest in social events, and often put off other teams communicating with them because of their behaviour.

We all sit next to each other, leading to complaints that we sit too close to each other because the desks are too small. My personal opinion is that by being situated closely to each other I would have hoped there would be no problems with communication.

The office used to be really quiet, but there are some new starters who make a lot of noise, and there have been constant complaints from people on my team about the noise being made, even though I consider the noise to be banter and employee bonding, to improve work relationships.

So the crux of what I need is for the team to communicate more effectively.

One particular example is when a bug is assigned to someone on my team, they take a quick look and can't see the problem, so mark the bug as unable to reproduce. This sends the bug back to the test team and they then have to get more people such as their boss involved to get the bug fixed, when what we really want is for the people on my team to go and speak to the tester who raised the bug so that they can see for themselves what the problem is.

I've said many times to my team about increasing our visibility, about going to talk to other team members, and to socialise in the office more to improve relationships.

It seems that beating the team with a stick and saying this needs to happen has not resolved the issue, so what can I do to make my team communicate more effectively, internally, and with other teams?

Update

Social activities usually take place during work hours. I can only think of events at Christmas where social activities have taken place outside of work hours. For each social event, it is the people in the office who decide what is generally going to happen: the company doesn't force random social events on anyone.

We each have our own desk. Although small, they are individual desks. I have raised the issue of the desks being small before, but we have other offices with the same size desks and the staff are happy with the size of them and this is often cited as a reason for not getting bigger desks amongst other reasons.

The bug reports include videos and the steps required to reproduce the bugs. My boss and I take one look at them and see the problem, but the developers don't follow the instructions and then mark the bugs as unable to produce in a very lazy manner. Then they don't bother to ask the testers who reported the bugs for help on reproducing the bugs.

We have two development teams, and we often have to create specifications to get both teams software to work together, but when the two teams won't even talk to each other, what happens is one team goes off and does one thing and the other team goes off and does something else. As managers we don't want to micromanage. We want to let the teams to define the interfaces because they are senior developers and it is their responsibility within the company to do so.

I was a developer before I was a manager, and I prefer text-based communication over meetings and discussions. That said, I do think there is a balance between quickly just discussing something with someone to get a resolution without sitting there for a couple of days struggling and not saying anything, or just going off and doing your own thing despite being told what specifically needs to happen, with the reason given for doing so as they thought they knew better, yet didn't ask what the reasons were for the decisions made.

My boss has cited me as a role model for what he would like, because I do get up from my desk and go and sit with the testers and go through problems, I do speak to the project manager and I do talk with the other development team to better understand the software they deliver. Trying to teach my team to do the same is easier said than done as they are long serving members of staff and reluctant to change.

Answer 1

One suggestion I would offer is to work with other management to block out some time, during the work day, to do something that requires collaboration between people who don't normally work together directly.

As an example I will offer up an exercise I put together while managing a development team. I created several sets of tangrams out of paper, and a different pattern for each. I broke everyone up into small teams(2-4 people) and handed them the pattern and a notepad. Their job was to write out instructions (text only, no graphics) for someone to build the pattern they were looking at. They had something like 15 minutes to prepare their instructions.

Once the instructions were complete, the patterns were put away, the teams rotated so they were looking at instructions someone else wrote, and the tangram sets were put out. They then had another 15 minutes or so to try to build the pattern described in the instructions. They never got to see the pattern that the instructions were made for, or talk to the team that wrote them.

When time was up, everyone stepped away from the desks and the patterns were laid out next to the shapes that had been made. They were then able to circulate and see how close different teams came to the original patterns. We then had some discussion time about the challenges and lessons learned from the exercise.

In my context the goal was to highlight the difficulties in putting together, and then interpreting, requirements documents, without direct interaction. I pulled PMs, BAs, Managers, and Developers together to do this, but there is no reason you could not do it with QA and business people as well.

Answer 2

I have several observations about your situation, which I shall comment on in turn in the hopes that at least some of the below will be helpful.

I know people on my team lack good interpersonal skills, they have little interest in social events, and often put off other teams communicating with them because of their behaviour.

Let's start with this one. It's been discussed on The Workplace before, but just because your employees don't want to give up their spare time for free to spend more time doing work-related things (i.e. the "social events" you mention which I shall assume are work-related events) doesn't mean they "lack good interpersonal skills". It sounds like you are personally judging people who may not be as extroverted as you, and I think you need to get out of that habit pronto.

My team resort to using IT systems in place as a means to avoid making contact with others in the company.

That's probably not what they're doing. You're judging again. Developer teams use IT systems as a way to communicate asynchronously, without having to break their mental flow every time somebody wants to vocalise some thought or ask some question. This is an extremely productive workflow, and completely commonplace in our industry. As their manager, it is absolutely crucial that you somehow come to understand this.

We all sit next to each other, leading to complaints that we sit too close to each other because the desks are too small. My personal opinion is that by being situated closely to each other I would have hoped there would be no problems with communication.

You can't improve communication by cramming people in like cattle. No wonder your team is feeling crowded and grouchy. Give them space to work.

The office used to be really quiet

They were working. This includes thinking, not just talking all the time.

But there are some new starters who make a lot of noise, and there have been constant complaints from people on my team about the noise being made, even though I consider the noise to be banter and employee bonding, to improve work relationships.

Banter and employee bonding may improve work relationships between people who spend most of their time bantering but, in real terms, constant noise around you is terrible for productivity if you are in a thinking job. I am fortunate enough to work from home half the week, and I can't imagine getting done even 20% of what I currently produce if I had to put up with people constantly "bantering" around me during the day. Although, I have to say, our office is pretty quiet anyway because my workplace already understands this.

when a bug is assigned to someone on my team, they take a quick look and can't see the problem, so mark the bug as unable to reproduce. This sends the bug back to the test team and they then have to get more people such as their boss involved to get the bug fixed, when what we really want is for the people on my team to go and speak to the tester who raised the bug so that they can see for themselves what the problem is.

What you really want is wrong. Once in a while, yes, your team should be prepared to follow-up for more information. But if the testing team are habitually raising issues with such imprecise or lacking information that the issue cannot be reproduced without going back to the testing team and having a conversation, something is very wrong with your issue reporting process.

By quickly rejecting the invalid defect reports, it sounds like your team is reaching the end of their tether on this topic. I would be seriously concerned about their morale, and act to improve your processes, rather than trying to force your team to be some sort of high-fiving bank of "lads" who spend their days gossiping about football rather than doing their jobs.

I've said many times to my team about increasing our visibility, about going to talk to other team members, and to socialise in the office more to improve relationships.

Now, while I stand by everything I've said above, it is true that everybody benefits from a cohesive organisation populated by people who have at least a token amount of face-to-face, human contact during the working day.

Again, though, I think you need to work on your processes and get your team's morale back up before you start forcing people to conform to your idea of social norms.

It seems that by beating the team with a stick and saying this needs to happen has not resolved the issue

Yeah, funny that.

My boss has now raised this as an issue to me, saying it is leading to other problems, such as not wanting to talk to other teams when doing so would quickly resolve matters.

Just because your boss has now raised the same criticisms doesn't mean the criticisms are valid. You now have an opportunity to back up your team and support their best interests, advocating for them and the way in which they work best. As their manager, that is your job, not parroting whatever your boss (who is even more removed from the developer world) has come up with next.

Answer 3

I've been in similar situations in the past. One that specifically comes to mind was a highly specialized team whose clients admitted to be quite competent technically, but with reportedly sub-optimal communication skills.

So, to your points -

[...] I noticed how quiet the team was, and how reluctant they were to want to engage with others in the office.

That means they have a common baseline behavior as a team. I'm assuming as a natural result that there are no intra-team communication issues: these only appear once this team needs to collaborate with other teams with different dynamics. The intra-team collaboration, if existing and natural, is an asset. Work with it.

My team resort to using IT systems in place as a means to avoid making contact with others in the company.

And so do others IT teams around the world work - I'd even daresay the majority of them, if my personal experience may be taken into consideration; tools like Slack, Google Hangouts and similar are natural to them.

But, more important, face-to-face communications are actually frowned upon in some situations because there may be no proof of resolution or commitment. Text-based solutions, be it chat or email, can provide both backlog and proof of commitment.

[...] they have little interest in social events, and often put off other teams communicating with them because of their behaviour.

They may have little interest in the specific kind of social events the company is promoting. Did the company tried asking them what would they like to do? They may reply with proposals to attend a developer-centric conference together or to organize online multiplayer gaming sessions, for example. Listen to them.

My personal opinion is that by being situated closely to each other I would have hoped there would be no problems with communication.

Ask them how they would prefer the environment set up. That may result in valuable insight.

[...] there are some new starters who make a lot of noise, and there have been constant complaints from people on my team about the noise being made, even though I consider the noise to be banter and employee bonding, to improve work relationships.

The new starters are behaving in a way that deviates from the team established behavior. That creates stress. By accepting it and setting it as desirable you may be empowering the new hires and further degrading the working environment.

So the crux of what I need is for the team to communicate more effectively.

My suggestion would be to pick someone to serve as the communication bridge between the technical team and the rest of the company, able to translate the needs of both sides into deliverables. I have seen some Project Managers covering this aspect, but sometimes they have someone dedicated filling this role.

One particular example is when a bug is assigned to someone on my team, they take a quick look and can't see the problem, so mark the bug as unable to reproduce. [...] what we really want is for the people on my team to go and speak to the tester who raised the bug so that they can see for themselves what the problem is.

On the other hand, the QA team could provide better information: Some testing solutions allow, for example, for screen capture - But 99% of time it just takes some additional diligence in describing the scenario to help a developer team to figure out possible causes.

Also, if they're already pressured to tick N 'solved' checkboxes per day then they'll naturally pick the ones that they can solve faster, leaving the poorly written ones in the queue.

I've said many times to my team about increasing our visibility, about going to talk to other team members, and to socialize in the office more to improve relationships.

There are many possible ways. But forcing them to behave in a way that is unnatural is hardly an option. You may need to think of ways to meet them in the middle. They are your team, you win or lose together.

Answer 4

You have a tough task ahead. Developers generally are not the most social of people. But in today's employment market, with modern Agile processes taking hold, they have to be what I call minimally social.

It was put to me that my team, and others in the office, just don't work together as a team and the root cause of this appears to be a lack of willingness to communicate.

Changing this behaviour will take time, and constant re-enforcement from you. Be prepared for some potential departures too, but that is to be expected for a pure introvert.

In every company I have worked for over the last 20 years, it is normal for developers to keep communication with non-developers (and in general) to a minimum. But if we don't communicate with the users and stakeholders how will we ensure that we are meeting expectations and deliver a satisfactory product? As their manager, it's up to you to help pull them out of their shell.

One particular example is when a bug is assigned to someone on my team, they take a quick look and can't see the problem, so mark the bug as unable to reproduce.

Using your example, I would change up your development process and force whomever is assigned the bug to work with the user face to face. Start by having the user explain and demonstrate the bug clearly. This will be an excellent start to upgrading your team's communication abilities.

When new requirements come, have a review meeting which includes the users and stakeholders and ask your team members questions during the meeting forcing them to engage.

You can also add acceptance criteria to your development process. Make certain the developer involved communicates with the user to be 100% certain they understand the criteria.

Change a few things that force more communication. Let the team know they have a reputation for being anti-social and one of your goals as the manager is to alter that perception.

And finally, take a look at implementing some form of an Agile process. Again, this will force your developers to communicate with your users and stakeholders.

Answer 5

It seems that by beating the team with a stick and saying this needs to happen has not resolved the issue, so what can I do to make my team communicate more effectively, internally, and with other teams?

Would you beat a stroke victim because they weren't walking? Social skills are SKILLS like any other and need to be learned.

You are approaching this in 100% the wrong way.

FOCUS ON THE SOLUTION, NOT THE PROBLEM

What you want is for the team to communicate. The solution is to TEACH THEM

1. Lead by example: Teach them by doing and providing a role-model/mentor to them
2. Send them to classes: The self-improvement industry exists for a reason. There are tons of books out there as well such as "How to win friends and influence people" or "The seven habits of highly effective people" which are EXCELLENT in building social skills and success.
3. Do some hand holding. IT people in general tend to be under-confident socially and being technical is where they shine. People avoid things that are unpleasant and to many technical people, interaction with other people is uncomfortable. You will need to hold their hands and show them some VERY BASIC skills that you will probably think you should never have to teach anyone. Guess what? You do
4. Identify obstacles and surmount them: You likely have at least one person on the autism spectrum on your team and possibly other difficulties to overcome. Find out what you're dealing with and cater your approach to it.
5. Approach this as a SKILLS DEFICIENCY and not an attitude problem.

As I reread your question I see an underlying problem coming from you, and perhaps you should pick up some of Dale Carnagie's books for yourself. Everything in your question is about what YOU want and what YOU THINK and no regard for your team whatsoever. You are setting yourself up for failure!

Understand your team: You mentioned noise. That is one of the most frequent complaints we see on this stack, especially from IT people. YOU may see it as more bonding, but your team doesn't, and most technical people don't. When you are trying to concentrate on advanced algorithms, chatter in the room is a distraction. If you want more bonding, block time for it. You mentioned that you think that sitting closer would help the team bond. It didn't work, but rather than rethink your approach, you're thinking in terms of something being wrong with your team.

YOU NEED TO THINK IN TERMS OF WHAT YOUR TEAM NEEDS AND NOT WHAT YOU WISH WERE TRUE

You may love peanut butter and think it's great and nutritious and so you bring some peanut brittle for your team and then resent it when nobody eats any. Well, what you didn't realize, or care to find out is that two people on your team are diabetic, one has a peanut allergy, and three more are trying to loose weight. That's what you did by putting everyone's desks closer together without asking them.

Start by addressing your own issues, stop making assumptions, and LISTEN TO YOUR TEAM

Then, follow the advice above.

Answer 6

I feel you've been trying to be more than accommodating and are cognizant of their social issues. Sometimes people need consequences when they don't do what they're supposed to do.

You work with smart people whose strengths are problem solving. Put that to work.

1. For every bug request that is not repeatable, how are they going to communicate to you that they have contacted the person and discussed the problem further?
2. How does this get tracked? If you're going to have measurable goals, you need a way to keep score.
3. What is a reasonable response time? No team can do everything immediately if you're not staffed fully. Setting some time limit could help them work around their hesitancy.
4. What should happen if they meet a goal or don't meet the goal? Everybody likes rewards and your team is no different. Let them come up with something and then see if the company can implement it.

Rarely does anyone get tasked with only being required to do things they want to do in the workplace. No one is skilled at everything, so it takes some work. Make sure they don't set the goals too high.

Answer 7

There are two types of work communication that you're talking about: 1. necessary communication processes for collaborating with other teams, and 2. general interpersonal interactions where everyone is friendly with one another. It is possible to have one without the other, and I think you should be focusing more on 1 than 2.

Communication between teams is always going to be necessary and if a particular communication process isn't working for either side, it is worth it to go over that process. You're the manager, and making channels of communication better for your team is one of the things you can do to really help them work effectively. "Better" in this case does not necessarily mean "your team spends more time talking to people."

I think it might be worth reviewing all the current communication processes to and from your team. How is your team communicating with each other? How are they communicating with other departments and for each type of request that is directed to them? What annoys them about these communication systems? And what annoys other departments about trying to get in touch with your team? Once you know the current communication processes to and from your team, you can look at ways to improve the processes, and this is the crucial bit: ways that benefit both sides if possible, but that benefit your team first.

This is your team, ask them what works for them. If they want new requests to come through the system they're already using internally because it allows them to stay focused and more easily prioritize new requests, see what you can do to make it possible for people outside the team to do this. If they want you to filter new feature requests, because you're the manager and you need to confirm them anyway, tell other people to email you rather than your team directly. Let the team know that any communication from other teams that is not coming through the expected channel can be forwarded to you, and you will deal with making sure this communication gets into the right channel and that the sender learns the right way(s) to ask your team for something.

If they are annoyed at continually having to send bugs back to QA for not being detailed enough, don't address each bug report individually by having them go over and talk to the reporter, fix the process by getting your team to put together a document for QA of what makes an effective bug report - steps to reproduce, environment in which the bug happens, error logs, etc. Getting a bug report right the first time saves time in both departments, so while this is a communication problem, and the problem is solved by communication from your team, the solution isn't "go sit with QA every time this happens" it's "let's help them define a process so we get what we need, and this doesn't have to happen so frequently."

I think that a Dev team who would rather be coding than talking to people will appreciate any communication improvements you make that allow them to spend less time on back-and-forths with other departments. Once you've cut down the 95% of bugs that needed to be sent back for not being detailed enough, they'll be more willing to go talk to QA that one time it's a really weird bug that just won't cooperate. The important thing is to work with your team first; make their lives easier before you ask them to change, and only ask them to change in ways that are really necessary for effective business communication.

A note on the 2nd type of communication, the "we're all friendly here" type - you are not going to turn someone into an office banterer who doesn't want to be one, and you will probably be resented for trying. However, it is useful for people to have a general comfort level communicating with their colleagues. Based on the fact that your team doesn't seem to like non-work-related small talk, if you want to get them communicating with others, maybe you can figure out if they'd be okay with some knowledge transfer sessions with other teams. You could ask them if they'd be willing to spend an hour sharing some technical knowledge with those who could benefit from it, or organize some other technical department to share some information with them. If it's something that will help them work better or aligns with some of their technical interests, they'll probably be more up for it than for non-work socializing, and ultimately it gets them talking with members of other teams, which is what you want.

Finally, when your team complains about ambient noise, listen to them. They are not complaining about people talking around them because they are anti-social, bad communicators, they are complaining because this noise is completely destroying their productivity. As their manager, you must have their backs here and should intercede with the noise makers on their behalf. Making sure your team can work productively is one of the main points of a manager's job.

Answer 8

We all sit next to each other, leading to complaints that we sit too close to each other because the desks are too small. My personal opinion is that by being situated closely to each other I would have hoped there would be no problems with communication.

You have a mistaken concept of the results of this arrangement. Microsoft has studied it:

Microsoft research scientist Eric Horvitz found that workers took an average of 15 minutes to return to the task they were working on after being interrupted.

Joel Spolsky elaborates:

Here’s the simple algebra. Let’s say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we’re really blowing away 15 minutes of productivity. [..] He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he’s sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

This is what your coders are talking about when they complain of being too close together. It's not a social question. It's a business question. What do they need to do the work we're paying them to do? What they need is long periods of uninterrupted focus. Sitting everyone right next to each other destroys the potential for this. It hurts the business.

They may be spending their entire day trying to recover from continual interruptions. In that state getting any work done is extremely difficult; they may feel they never get to the point where they have time to step away from anything. The first step is to eliminate that interference in their work.

Right now you're seeing how they behave in an environment hostile to their work. Create an environment supportive of their work and observe how they behave in that situation. I predict it will eliminate several concerns.

Answer 9

First the solution to your "Noise" problem is to get a white noise generator for the area. This will drown out the conversations from those hearing them now, and turn it into just regular background noise that is not disruptive to concentration. It may take a few days to get used to it, but its not uncomfortable and after a few minutes of working on something else it will not even be noticed.

As for the mishandling of bugs, that is a serious issue. Dealing with bugs is the least fun, and mostly thankless tasks in programming. And the mishandling of bugs costs money in time for the testers, customers, and other stakeholders that have an expectation that this will be fixed. This may be blamed on being awkward but it is really just laziness, and and an attempt to shirk their responsibilities.

I would solve the problem by assigning one person as the gatekeeper of the bugs. It is their job to make sure that enough information has been gathered to address the bug, and when it is not redirect that bug back to QA. They are also the only one allowed to close bugs as not reproducible. Before they do that, they will have to assign those bugs to a developer to fix. It is also their job to make sure the developer has put in a real good faith effort to attempt to solve the bug.

The gate keeper doesn't actually solve most bugs, their job is to assign them to other developers to fix, and to communicate with the testers to clarify the bug before it goes back to the developers, and to validate that a bug has been resolved. Its often one of the Team Lead's responsibility but it can also be a Senior, this is a position that develops leadership skills, and it solves a major problem for your group.

Answer 10

1. Socializing

Yes, if there are work-sponsored events happening during work hours, and your team is invited, and - importantly - higher-ups are going to the events, the team needs to be there. Not showing up is often taken that they:

• are being anti-social because they think these events are beneath them
• believe their work is too important to go to an event like this

If a VP of your department is able to join, and they for sure have more important things to do, then your team needs to show up. The VP will more likely start to think that they are overworked due to incompetence and inability to manage their tasks. They might get replaced.

They don’t need to go to every event, but they should make an effort to be seen at important ones (you decide for them if it isn't clear), especially if higher ups join in. You need to explain that should budgets get cut and VP Lady needs to eliminate positions, she will not hesitate to cull people from your team vs try to do what she can to keep people around.

2. Set clear expectations.

It sounds like the QA team is doing an adequate job of reporting incidents. Your team is being lazy. I believe that you have not clarified for your team, including the new people, what you expect of them when it comes to fixing bugs, when it comes to working with other teams, etc.

Set up a meeting where you clearly define your expectations. Use actual examples if needed. Document what you talked about. Refer to it again if needed. Allow people to ask questions. Be willing to listen and change your opinion if it turns out your team is right, and you are being unreasonable. You probably need to work with individuals, too.

When you have your meeting, you need to make it clear that although their behavior was fine in the past, the company is making a change. Verbal/better communication is now part of their job description. Their prior behavior will no longer be tolerated, because…reasons. If you don’t have those reasons, you need to get them from your boss -- and they better be good. It is unreasonable to expect someone to change their behavior due to someone’s subjective opinions or pet projects. If that’s the case, they will see right through it and nothing will change.

3. Improve your team's psychological safety

My suspicion about why your team is quiet is due to fear of retribution for making a mistake or sounding stupid. That is, you have no psychological safety at your workplace. In fact, you talk about “beating them with a stick”. My guess is your team is overtly or implicitly afraid of speaking up due to having received negative reinforcement in the past, either due to a mistake or misunderstanding on their part, or poorly defined goals and expectations on the part of you or other managers. I also suspect that the QA team may be giving negative reinforcement as well; this will require discussing how your workplace can improve psychological safety in general, not just on your team. Look into "psychological safety" for teams/workplaces.

4. Noise/office banter.

Again, you need to explain to your long-serving members that things are changing. There are new people, there will be more new people. The company is expecting new behaviors from individual employees. They do not need to be friends outside of work; they do not need to ask about people’s kids. But they should be prepared, and should be encouraged, to participate in ’water-cooler’ office chat. Rather than complain, they need to get with the program because it’s not going away.

For the new people, they need know that they should not assume that everyone is just like them. They need to know that the culture is changing, they are part of that, and they might experience some resistance. They should be told to be sensitive to this, because you do not want to replace people with institutional knowledge over this. As manager, you should also set some ground rules on what is an acceptable level of noise.

5. “We want to let the teams define the interfaces.”

Maybe you are not explaining how things work fully, but it sounds like you need to hire some designers to define the interface, and let the dev teams develop. Maybe it’s also time to get yourself a project manager, and/or product manager.

---

The last thing is you should have a reasonable timeline in mind for when you want to see changes. Some behaviors will probably need to change right away; others can take more time.

Answer 11

This is the definition of the need for Organizational Psychology. What you can do to solve it is minimal, and the problems you may cause may be huge. Just as Snark Knight mentions, it's very possible you have at least one person on the autism spectrum, most likely Arperger (AS). And I'd bet you have more than one, everything you mention is like a book about AS.

The thing with AS is that even those who are not on any autism spectrum, but might be considered borderline will be influenced by people with AS, so you have kind of a snow ball. The fact that the new members of the team are annoying or that your team can't reproduce a bug and much less ask the tester about steps to reproduce it confirms this: AS can follow instructions, but they're really bad to get "outside the box". And their resource is to close themselves into a shell, like "it can be done", refusal to talk or explain, mutism and sometimes some awkward behaviors, specially when pushed.

All this being said, it would be completely irresponsible and unprofessional to tell you a solution, because you need a professional to do an assessment on the particular situation and then create an appropriate strategy. Be warned that you could simply fire one or more of them, but you might be sued for discrimination, so again: try with a professional. Your situation can only go down otherwise, there's not a single scenario where you can improve things by yourself unless you have preparation on the field of psychology (which I assume you don't have).

Finally, this is NOT YOUR FAULT. Not even your responsibility. Try talking to your boss first, try contacting HR to see if they know of any known employee with AS (they may have an ASSQ or similar test on record).

The good news is: once you know HOW to work with people with AS, the rewards might be huge.

Answer 12

I manage a socially awkward team and this is leading to problems with communication.

If what is leading to the problem is you managing a socially awkward team, there are logically multiple possible solutions:

• Eliminate the team. (Have them act as individuals.)
• Eliminate the awkwardness
• Eliminate the fact that you are managing them.

In all seriousness, I'm guessing that you are not going to vote for the third option if that means you lose a position that you appreciate. However, they might not be so opposed to this. If they can operate more independently, so that effectively you are actually managing them less, they might try to achieve that goal.

I know people on my team lack good interpersonal skills. They have little interest in social events,

If their job description does not involve social skills, these observations seem completely okay.

and often put off other teams communicating with them because of their behaviour.

Is this a matter of different expectations? If so, then management needs to straighten this out. Either the team needs to be required to react in certain ways, or other people need to know what they can realistically expect from the team.

there have been constant complaints from people on my team about the noise being made, even though I consider the noise to be banter and employee bonding, to improve work relationships.

They complain. You like the "problem". If you don't address this to their satisfaction, the result will be them losing even more patience/tolerance, having even more dissatisfaction.

[what my team does is] mark the bug as unable to reproduce. This sends the bug back to the test team and they then have to get more people such as their boss involved

No wonder other teams are complaining about your team. The bosses of other teams don't like being forced to get involved. If you don't want the bosses on other teams to get involved so much, and if kicking back a question will involve the boss, then you need to either change the process (so kickbacks don't automatically involve the boss), or change how often kickbacks occur. (I realize that idea is covered by the next part of your quote.) I'm just taking a bit of time to point out that this, involvement of the bosses, is probably a huge cause for one of the things you don't like, which is bosses complaining about your team.

what we really want is for the people on my team to go and speak to the tester who raised the bug so that they can see for themselves what the problem is.

Don't make this be something you want. Make it be something that is required by the employee.

With every kickback, your employee needs to fill out a little (electronic) form that documents what happens when your employee went over to the testing team to work with them. If your team members fail to fill out a form, then it goes back to you to discipline your subordinates, without any need or the other team's bosses to get involved.

If your team complains that they can't work with the other team member due to availability, then fix that problem separately (e.g., require multiple attempts, scheduling, whatever is needed, including escalation if the other person really seems unavailable).

I've said many times to my team... to socialise in the office more to improve relationships.

Forget it. That doesn't sound like your team's job. Don't act so out of place by requiring something that shouldn't be required.

Asking an unsocial person to re-define their anti-social character, which they may have developed over a decade, will seem like an unreasonably infringement upon their right to control their own personal character. You're unlikely to be able to come up with a reasonably actionable goal.

However, what you can do, is to start recording feedback from the other teams. Maybe when your bug reports are closed (whether resolved or as a kickback), you can send a message to the submitter and get a smiley face or a frowny face on whether they were helpful. Now, expecting your team members to be sufficiently helpful, with a sufficiently high enough percentage of faces showing smiles, is an actionable goal that can reasonably be accomplished. Hopefully your socially awkward underlings will be motivated to use whatever social graces they do have in order to help achieve this reasonable-sounding goal.

the developers don't follow the instructions and then mark the bugs as unable to produce in a very lazy manner. Then they don't bother to ask the testers who reported the bugs for help on reproducing the bugs.

Regarding the first part, ask the developers why they did not follow instructions. If instructions are not clear to them (regardless of whether they are clear to you), then this my be a problem with more than just the developers. If that is what's happening, the only way you might know is by asking the developers why they did what they did. There may be other legitimate causes, so asking them why may reveal that. If there are not legitimate causes, then they may be quite uncomfortable when you're asking them why the failed to follow directions, and that may be a good thing.

Answer 13

There seem to be problems in the technical workflow of your bugs.

Your QA team should open the bugs with a precise description that allows to reproduce the bug.

There are several approaches, but the developer team closing a bug as not reproducible when they aren't able to reproduce is also normal. After all, your company is paying your developers to close bugs, don't you? Not to keep bugs lingering around awaiting to be reproduced.

That the QA team needs to involve their manager is wrong. In fact, ideally the reporter should be the one closing the bug, after confirming it has been fixed.

There are multiple ways to fix that: One is simply to allow the QA team to reopen closed bugs. Or to reopen recently closed bugs. You could also define an intermediate status like 'pending close' or 'more QA work needed'. Another way is to work with the bug owner field, so the developers would comment there that the description is insufficient, and assign it back to the reporter (bugs assigned to the QA team would be like closed for the statistics of the developer team).

Go and speak to the tester is not the proper solution.

Sure, it sometimes will be very useful. But in other cases it will waste a lot of time by both developers at testers e.g. the tester should have stated that there was a glitch at 2:35 where X should have been Y, rather than expecting the developer to notice by himself whatever was wrong by watching the full video.

If people from the two teams would need to meet frequently to clarify things, instead of having one side (either the tester or the developer) make an impromptu meeting wit the other, I would recommend having daily/weekly meetings scheduled between the two teams where all the bugs pending from the other side can be reviewed.

It is possible that the testers are "being lazy" and not reporting the bugs detailed enough. It is also possible that your developers are "being lazy" and closing poorly reported bugs too quickly. Probably both are partly at fault, not for being lazy, but due to different expectations. The tester is probably used to 'how X should work', but what he finds evident, is probably not to anyone else.