How can I manage team distractions like chit-chat?

Question

I work with a team of developers who are talented but often distract each other with chit-chat. They can waste hours of the day with these 20-30 minute, non-project related jam sessions. Since I am PM on many of their projects I get frustrated with the lack of focus but I'm not necessarily in the position (nor want to be) to micro-manage them or reprimand them. Currently I just kindly interrupt their chat with questions about progress on specific items. This helps them get back on track, sometimes.

Ideally the developers would have expectations that would require them to stay focused and manage their own work. I get a lot of resistance from attempting to setup benchmarks due to the nature of the current projects and management structure. Even when I ask how long it might take to complete items (which I can complete in a very accurate time frame) I get negative feedback which indicates a desire to suppress accountability. Which incidentally facilitates a chit-chat filled work day.

So while I encourage the business management team to give me tools to establish clearer expectations, does anyone have a simple or clever way to keep people from overdoing the symptomatic chit-chat?

Answer 1

Conversation is Not Inherently Disruptive

I work with a team of developers who are talented but often distract each other with chit-chat.

You say they are "talented but distracted." What makes you think they are talented? Why do you think they are distracted? What is your metric for determining that the team or the process is operating at a sub-optimal level?

You haven't really made a case for any of those things, except insofar as we're supposed to agree ab initio that "chit-chat" (which has a rather pejorative connotation) is disruptive to the project. How have you determined that the team's communications style is preventing your project from succeeding?

Self-Managed Teams and the 100% Utilization Fallacy

Ideally the developers would have expectations that would require them to stay focused and manager (sic) their own work.

While I agree that an ideal team is self-managing, I have no knowledge of your hiring practices, corporate culture, or organizational incentives for teams to be self-managing. However, the fact that you appear to be in a role where you are tasked with managing a team that isn't self-managing argues that expecting such may not be reasonable without changes to your organization or process.

In addition, "staying focused" is often management-speak for "looking busy." As above, unless you can make the case that your team is failing to perform, it really does sound like how they behave is more important than what results they produce.

In fact, by making "how" an issue, you're acting contrary to the very principle of self-management you seem to want. Even if the team is truly disengaged, your time would be better spent figuring out how to engage them rather than on ways to make them look engaged.

Developers are often odd ducks. Some developers work best in catacomb-like silence or working at 2:00am; others thrive on cross-talk and team engagement in the office. Regardless of work style, though, all developers need thinking time to be productive---more clicks on the keyboard (e.g. higher utilization) does not lead to more throughput or higher-quality code.

"Accountability" and Project Process

Even when I ask how long it might take to complete items (which I can complete in a very accurate time frame) I get negative feedback which indicates a desire to suppress accountability.

Again, your conclusion isn't based on information in evidence. There may be other reasons your development team doesn't want to give hard deadlines.

1. "Accountability" is a buzzword for a way to shift blame.

   If your organizational culture likes to affix blame, and projects are often late or otherwise doomed to failure, why should the team want to be held accountable?

2. Commandments from on high aren't commitments.

   If the team isn't part of the estimation or scheduling process, then they are being "held accountable" for delivery dates that they didn't sign up for. Ask yourself honestly whether developer estimates are solicited and honored as a project baseline, or whether project deadlines are set outside the team.

3. Estimates aren't commitments.

   If a developer tells you something will probably take three days, but the job takes five, what happens in your organization? Is someone to blame? Does the developer get punished or denigrated for the mis-estimate? If so, why should they do anything other than slog onwards at whatever pace they feel is sustainable?

4. Commitments aren't guarantees.

   Developers are rarely stupid. If they know something will take two weeks (due to complexity, process overhead, or organizational obstacles) and you think it will take two days, what's their incentive for giving you a different deadline? If the organization routinely cuts their estimates, and then holds them accountable, where is their incentive? If they give honest estimates, and fail to meet voluntary commitments through external impediments, does the organization expect a money-back guarantee in the form of unpaid overtime instead of trying to resolve the impediment?

Even if we assume that your conclusion that the team wants to avoid accountability is true, you haven't dug deeply enough into why. There's clearly an organizational or process issue at work here, and solving the perceived problem isn't really addressing the root cause---or buying you anything if you are ultimately being "held accountable" for a project that is failing.

What Next?

Take an honest look at your organization, your project management process, and the members of your team. Try to be objective, and see if the incentives actually align with the interests of the developers. If not, start there!

Holding a Scrum-like retrospective might help, too. If the real problem you want to solve is getting honest estimates from the development team, the only people who can tell you how to get them are the members of the team. Of course, you will need to earn their trust (if honest communication hasn't been the norm), and there are no silver bullets. Still, it's one of the best tools out there: ask the people with the actual answers!

There are always other things you can inspect-and-adapt. Still, you need to start somewhere, and holding honest and open dialogs is almost always the very best place to do that.

Answer 2

I don't know why aclear16 deleted his answer. His answer is perfect. There are a ton of positives with idle, unproductive time by way of teaming. It matures the team and you want that. I'd even go as far to say that, if you are running behind, let the social time continue because the positive aspects of that will help, not hurt. And likely the down time was not the cause.

If you try to squash it, you run a far greater risk of destroying the teaming and alienating yourself.

What you are feeling is you don't have control of your team--thay don't even have the decency of looking busy when you are around. Meet your insecurity. Get over it.

Answer 3

The first issue you must face: Are distractions good or bad? I think this can not be answered with either a clear yes or no.

First, no developer can work 8h on end and still remain sane. On a good day you get 4-6h of concentrated work. But don't think that, since they are not sitting concentrated at their desk that they are "not doing work". In my experience the best ideas and insight come in down time.

Second, morale is a very important aspect of productivity. A motivated developer can do more work in 2h than a unmotivated one in a whole day. It is important to recognized, that looking busy does not equate with "working hard".

Third, distractions can really harm productivity. Not really in lost time, but rather in interrupted flow. No matter if it is the colleague asking about the latest trend in web technologies or the manager who wants to discuss the latest TPS report. It just takes forever to get back into sync.

Adding metrics may help. Without putting pressure on the developers, you can start to collect simple metrics like issues/time. This may make some healthy competition between developers about who can get the best score. But be very careful, overdo it and people will start to game the system. Like incentives, putting pressure on people who need to do creative work, reduces their output.

In the end it is about having a healthy work environment.

Answer 4

I second @sqreept opinion (+1!), you're trying to deal with the symptom rather than with the cause.

Having said that, my opinion below only represents a few between all possible scenarios.

Now, the scenario:

my team is chit-chatting a little bit too much

Why? Because they know they have loose deadlines to meet.

Why? Because developers tend to be reluctant to provide estimates.

Why? Because they don't want to get accountable for dates.

Why?

• OR they don't have good specs, and then the team feels allowed to add a huge padding to their estimates
• OR the specs aren't considered good enough by the Dev team, who refuses to work under a tighter deadline for ellegedly bad specs
• OR there's a culture in place that allows them to behave this way

So, answering your question, you'll need to assess the causes for this behavior and deal with the cause, not with the symptom.

Bear in mind that no one works productively 8h straight, though. If you believe the chit-chatting is CLEARLY impacting in the overall performance of the project, you may need to act. But don't try to push your team too hard, because it simply won't work.

A side note: Asking how's the progress to clearly ends up with a chit chat may sound rude. You're trying to deal with something you consider a real problem without facing it directly. If, after assessing the scenario you really believe it's a problem, be candid with your team and let them expose their opinions. Side actions (or side questions, in this case) won't add much value, as your demonstrating you're not facing the real problem. Step up and solve the problem (if there's one) without going round and round.

Answer 5

Your question has one answer & one hidden question in it: "overdoing the symptomatic chit-chat?"

overdoing: When is normal chit-chat become overdone? symptomatic: Yes, you're right. This is merely a symptom. Don't try to fix the symptom.

But, from experience, if you worry about chit-chat and that becomes visible, they'l unconsciously do more of it :) I know, it makes no sense.

The thing that you should concentrate now is making the product more 'their product' and less 'your product'. Build on their pride, on their self-respect. Never on fear!!!

And, good luck! You have a bigger task ahead than the product, whatever you do...