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?

5 Answers 5


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.

  • 3
    figuring out how to engage them rather than on ways to make them look engaged +1!
    – Tiago Cardoso
    Dec 26, 2012 at 22:31
  • 8
    I'm a developer, and I think this advice is spot-on. It's primarily how the company I work at manages things. Also, that "idle" chit-chat isn't necessarily a waste of time. It might be for hours on end, but some chit-chat I'd consider beneficial. The usual chit-chat times are when two people are stuck on a problem. For me, it helps to forget about the problem for a few minutes and do something else, and then come back to it with a fresh mindset. If they aren't chit-chatting, they're reading the onion or whatever. Don't try to eliminate this because you'll always fail.
    – Earlz
    Dec 27, 2012 at 8:18
  • Thank you for taking the time to write a thoughtful and well constructed answer that challenges the why. The root of the problem is our internal management, and as I stated is a symptom. I'm not attempting to usher in a renaissance of fascism starting with my team, just keep the chit chat from becoming a runaway train. Every great athlete has had a coach that drives them and tells them to "do it again." All of your challenging questions are helping me to find a clearer path to becoming better playing team. p.s. Next time I will include footnotes to support my statements. Thanks!
    – ChrisFM
    Dec 27, 2012 at 18:10
  • 2
    +1, and two notes: Every time a dev does something they've never done before, estimating it will be impossible anyway. By holding devs to deadlines, you kill creativity and innovation. Also, the "chit-chat" helps engender trust, which can help devs reach out to each other for help when they need it, which saves a lot of time in the long run.
    – Lunivore
    Dec 28, 2012 at 20:54
  • Unless you're a developer (or some senior iteration of a developer like an architect) then you should never be telling them how to do their jobs, because frankly you don't know how to do their jobs. Unless you're looking at the frequency of their commits and the quality of the code that they're putting in then you're in no position to be their coach. They might spend half of their day with their hands behind their backs leaning back in the chair and talking about the weekend, and be way more productive than someone who stares at the screen for 8 hours straight and keeps their mouth shut.
    – MrFox
    Jan 14, 2013 at 16:15

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.


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.

  • Those sort of metrics aren't a good idea. You want cooperation, not healthy competition.
    – Nathan
    Nov 11, 2016 at 8:22

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.


  • 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.

  • Yes, I stated it's a symptom intentionally. It is precisely that. Doctors treat symptoms all the time. Is it the best way to treat a problem. No, The best way is to live healthy and avoid the problem altogether, but symptoms normally must be treated until the root of the problem is resolved.
    – ChrisFM
    Dec 27, 2012 at 18:24
  • "If you believe the chit-chatting is CLEARLY impacting in the overall performance of the project, you may need to act." Exactly, this was the question. I was looking for temporary, pill-popping, highly addictive symptomatic treatment for over indulgence of chit-chat, like hours and hours of chit-chat. I am asking for tactful ways, if they exist, to address this while the management rebuilds the entire company structure.
    – ChrisFM
    Dec 27, 2012 at 18:29

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.