I recently read a question on here about - How to balance Teamwork and Babble? - and David Espina's answer pointed out that despite developers being contracted as 100% FTE (full-time equivalents), in reality they only deliver between 45% and 75%.

For simplicity's sake, translating that statistic into hours implies that in a typical 8 hour day (9 to 5), developers only work around 4 to 6 hours.

Based on my experience at work, I would tend to agree with David. In other words, I have also found that developer stamina and / or willingness to work varies quite a bit from one developer to the next.

Some developers enjoy working 8 hours per day. Other developers experience stress when they work for prolonged periods of time and require regular breaks during the day in order to perform at their best.

In other words, a 4-hour per day developer (let's call him laid-back Larry) gets stressed if he is required to put in 8 hours per day. This reduces Larry's morale and thus impacts his long-term productivity.

Likewise an 8-hour per day developer (let's call him workaholic Winston) gets stressed when Larry takes regular breaks, because he feels like he's the one doing all the hard work whilst Larry is free-riding. But levelling the playing field by inviting Winston to work 4 hours per day instead of 8 results in a loss of long-term productivity as well.

So how do you manage a team of developers when their preferred working hours vary?

  • "laid back Larry" and "workaholic Winston" would imply a qualitative judgment about their work patterns. Was this intentional? Commented Aug 28, 2012 at 17:10
  • @Andrew Clear: Yes, and it implies unsound judgment. If Larry doesn't do his job, but gets paid the same, Winston is the idiot. You get paid to work 8 hours, you have to work 8 hours. Not 4. Not 2. Not 9. Not 10. And Winston won't do that for long. If you don't keep the problem in check, you'll soon have a Winston that works only 4 hours as well (or possible 2, to compensate for the time he was an idiot). I can tell you, we have the same problem with one demotivated dev. Nothing was done, although it was obvious even to a blind. And soon, you had 10 demotivated developers only working 50% ...
    – Quandary
    Commented Jun 17, 2015 at 7:35
  • 50% at best, I might add. Though of course everybody getting paid 100%. The long-term problems this creates are mounting at record-scale.
    – Quandary
    Commented Jun 17, 2015 at 7:37

10 Answers 10


I would be focused on the team and not the individual. If an individual on my team is focused on the lack of productivity of another, that would be a sign and symptom of a weakness on the team. Ideally speaking, a high performing team has a sense of collective success and failure, in which the individual strengths are exploited and individual weaknesses are protected. Indeed, extremes of performance variability needs to be addressed in some way...on both side: meaning a very low producer and a very high producer. It sounds very counterintuitive to "address" the high producer; however, if it is adversely affecting the overall team's performance in some way, it needs fixed.

Performance variability will always exist but I think you will find most to hover around the same level. I think if you promote a good teaming environment, the variability by individuals will be protected by the team...at least ideally speaking.

  • +1 for focusing on the team, rather than the individual. Ideally, your team should be able to work such matters out within themselves. Commented Aug 28, 2012 at 15:24
  • @David Espina: As long as it is "only" performance variability, I agree. But you have to face the fact, that this isn't necessarely a performance variability, but simply deliberate and open impunity, which amounts to indecency towards your co-workers (they are the idiots). I can tell you, I had such a co-worker. And I might add, there was also a performance variability. The two things often occur together, they are tightly coupled. Idiots are usually worse performing than non-idiots, and it also takes an idiot to belive your co-workers will put up with this for long without saying anything...
    – Quandary
    Commented Jun 17, 2015 at 7:43
  • React, or face the consequences. To every action, there is an equal and opposite reaction.
    – Quandary
    Commented Jun 17, 2015 at 7:50
  • An excerpt from a typical workday of this person: Appearing at 10 to 10:30 in the morning (regularly). After arrival, coffee ritual for 30 mins. After that, 30 mins smoke-brake. After that, lunch break. 12 o'clock. Total time worked: 0 minutes. After lunch, on the phone with a private customer. For about one hour. Then smoke break - Appears back one hour later. After that, you hear the sound of ICQ starting. When you go to the toilet, you see he's chatting in Skype (with his Thai "gf"). Then he actually does some work (=copy some code from code-project). Of course nothing works.
    – Quandary
    Commented Jun 17, 2015 at 8:01
  • Then he checks in (just overwrites) everything with his version from yesterday. Nothing works. He added the /bin folder to the project, and checks the bin out EXCLUSIVELY. So nobody else can do any work anymore. Tells boss he's finished (nothings works), that only person XY needs to add the permissions. Boss happy. Boss leaves at 16:00. 16:15, said corworker leaves. You look into the code, and see method "Filters": with this comment: // To be done, didn't know how... Then you get that crap, and soon after, if anything doesn't work, it's just a "permission bug" (=next day, your problem).
    – Quandary
    Commented Jun 17, 2015 at 8:05

Focus on the goal, not the process.

You have a project, you and your team know when it's got to be done. Everyone's agreed. Now if everyone is responsible for an aspect of that work, then it doesn't matter how long they work, or when, as long as the work gets done as agreed.

It's only when those preferences for hours impact others that you need to worry about managing them.

  • You have a leak in the ship, you can focus on whatever goal/destination you want, you'll never arrive. That's physics, pure and simply. If nobody fixes the leaks (nobody does the work he should do), you'll sink. Having a co-worker who doesn't do his work (deliberately) demotivates the entire team. You do nothing, you'll have an entire demotivated team. You have an entire demotivated team, nobody does the work he should do, that he/she is paid to do. React, or face the consequences. To every action, there is an equal and opposite reaction.
    – Quandary
    Commented Jun 17, 2015 at 7:47

Unless it becomes a large issue, I don't think you should be micro-managing developer hours. Rather, you should be focusing on the amount of work they are contributing to your project. To use a college analogy, the Professor should not be concerned with the amount of time it took to write a paper, only with the quality of the paper and whether or not it met the requirements.

If it becomes an issue, I would prompt my team to speak about it in their next retrospective. If that doesn't solve the matter, consider a visual KanBan style board where everyone can see the tasks that everyone else has in progress and completed. Winston may be simply working under the assumption that Larry is performing less work because he is working fewer hours (Obviously this would only work if Larry is performing a comparable amount of work. If he isn't, then you have an entirely different issue).

  • If you work fewer hours, you'll usually get less work done. That is usually the case, because very few people are that much more gifted (compared to their peers) that they can make up for an hour in 10 minutes. Occasional exceptions excepted of course. But there's a 95-99% chance Larry isn't one of those exceptions.
    – Quandary
    Commented Jun 12, 2015 at 8:37
  • Not necessarily. I've found that most variance in work output is related to concentration of effort and ability to avoid distraction, rather than pure skill. If Larry doesn't take a lunch, and doesn't like to hang out at the water cooler, then he can prob do a full day in 5-6 hours Commented Jun 12, 2015 at 14:39

First off, different people provide with different output per hour. This is normal, and this is why their hourly rate (or monthly salary) might differ. There is no specific gauge to measure how much each individual working hour would cost, so there's usually a certain average, FTE.

What happens here

In your example, let's assume Winston is working 8 hours and each hour is equal. Larry is maybe working 4 hours. If Larry manages each of those 4 hours are that prominent he can deliver the same work as Winston does, a good manager should tolerate that.
Even more, if Winston is late to the office due to the personal reasons, his work for today is certainly late. It does not apply Larry who may concentrate and accomplish today's tasks during a second half of the day.

On the other hand, if their average hourly productivity is equal, Winston should receive a twice as higher rate.

Work and hours spent are different terms. They are both measured in hours but they have totally different nature: spent time is an effort (physical time), while work is the actual result.

And yet another consideration. People may be productive at different time of the day, but the key to success is collaboration, not the individual work. A PM has to manage this difference.

What a PM can do

  1. I would say you need both types of developers for best long-term results.
  2. A good idea is letting the developers know how many billable work they deliver daily or weekly. Even if the project has nothing to do with outsourcing, maintain the time tracking as if the project was billable. This alone lets all people to see the "big picture". They no longer blame on you for paying same salary to people who work different hours a day just because they see how much added value everyone produces.
  3. Having internal or side projects also lets Larry to work more effectively, here's why. Ask yourself, why people get bored? In many cases, it's just because they don't feel courage to do a certain work. But they will likely want to do another work. I usually keep a bunch of lower-priority tasks specifically for such situations.
  4. As per people who have different productive time, you may let them agree among themselves on critical time slots when everyone is available. These slots are usually assigned to local meet-ups.
  5. Everything above is only valid if the corporate discipline is kept well. Limiting people make them unhappy, but absolute freedom is harmful as well. :)

I hope this helps.

  • Tracking billable hours, and making that visible to the team is a double edged sword. If it takes Larry 1 hour to perform a task, and Winston 2 hours, tracking billable hours can lead to seemingly disproportionate contributions to the project, when in fact their contributions are similar. Commented Aug 28, 2012 at 15:27
  • @aclear16 Exactly. This is why billable hours reflect work. With given assumptions, it is very possible that Larry may spend 4 physical hours to deliver a work that worth 8 man-hours (assuming all man-hours represent equal amount of work, which might not always be the case). Commented Aug 28, 2012 at 15:56
  • Ah, so you are weighting billable work hours somehow. Do you suggest having your team decide how many billable hours each task is valued at? Or do you decide that a different way? Commented Aug 28, 2012 at 16:19
  • @aclear16 It's rather a separate, big question, but yes. In an ideal world, the team suggests initial work estimate. If they do it in common units, you retain flexibility to (re-)assign tasks, adjusting expected task duration according to each person's expertise (and therefore, their performance) as per the individual task. Commented Aug 29, 2012 at 0:35

As CTO at Blueprint software I had a team of 25 developers in Russia and 25 in Toronto, so due to the timezone's there was little overlap during the day. We actually had the team in Russia start around noon their time and work to about 8pm, providing more overlap.

The reason for mentioning this is that the key issue you run into when allowing developers to work their "own hours" is ensuring there is enough time everyday when they can interact with each other, help each other and frankly just feel part of the team.

Allowing people to work their own hours is something I have practiced for the past 10 years. They only requirement I would have is that there be some core hours where you must be in the office to ensure team collaboration could happen.

If people are measured based on what they produce and less about the hours they put in, this is an important change in thinking that will allow you to see who your top performers are and frankly more importantly, helps motivate the team, as they are and feel more empowered.

Nothing will zap a teams energy if they feel they are just coding drones.

So the key points here are 1) let your team work their hours 2) make sure there are core hours for team collaboration - at least 3 to 4 hours per day 3) measure more on what they accomplish than the hours they work. 4) if you have distributed teams in different timezone, figure out a schedule that supports (2)


Working habits are very personal and trying to change them can only create conflict. Nevertheless, as a PM, it's your responsibility to get the maximum performance from every team member for various reasons:

  • Individual contribution to the project must be rewarded fairly, based on productivity, that you will need to measure and compare properly considering the task value, complexity, appeal (not all tasks are motivating), pressure, timelines, etc. This is most difficult part.

  • Different tasks will require different skills and, at the same time, different work habits indicate, in my personal experience, different skills too. Take advantage on the observation of working habits while you get to know better your team members to assess their skills. Specifically, laid-back Larry may be best for tasks that require talking to several people to collect the required know-how to integrate some complex modules or coming with a brilliant idea that can simplify an existing solution or solve a challenging issue. Larry may be just wandering around while the ideas are shaping in his head. Winston instead may be a very meticulous and systematic person who needs to stay in front of the screen double-checking every configuration, unit test and deployment scenario. Do not try to swap their tasks, both will feel miserable, in most cases.

The conflict then happens because of misperceptions. You must be able to recognize both profiles accordingly. The Kanban board is a good way and probably you can use it for other purposes too.

My favourite option would be to have Larry and Winston working together or collaborating on a task where they can see each other special skills put in place. This way they will learn to value each other contributions.

It is also important, that Larry doesn't look like lazy during his 'low intensity' periods. If this is the case, you should push him a bit more assigning some real tasks that while keeping him busy prevent him from affecting the productive atmosphere of others, that could be tempted to join him in his 'leisure gaps' or get demotivated by the perception of Larry's attitude.


All of our developers are local, but many have varying hours. Some work 7-4, others 10-7, etc. My expectation (as PM) for them is that they be in the office during "core hours," so that I (and others) can schedule meetings and discussions as appropriate. For our purposes, I define "core hours" as 10-3; so I assume folks will be here during those hours.


Define the Problem Better

Is the issue whether there is sufficient overlap of "core hours" for members of the team to communicate, or is the issue that you have team members with different levels of skill and/or productivity? You mention both issues, but you can't solve for everything simultaneously.

Core Hours

The idea of core hours dovetails well with the Scrum and XP practices of "sitting together." While it is considered a practice and not a methodology requirement, it is worth listening to what the proponents of the methodologies have to say about the practice.

"Sit Together" predicts that the more face time you have, the more humane and productive the project.

Beck, Kent; Andres, Cynthia (2004-11-16). Extreme Programming Explained: Embrace Change (2nd Edition) (Kindle Location 893). Pearson Education (USA). Kindle Edition.

The idea is that a certain amount of face-time among team members, while not strictly required (and sometimes counter-productive in certain environments or for introverted team members) is still generally considered a generic best-practice because it enhances the level of teamwork through non-verbal communication, as well as fostering a sense of cohesion and allowing team members to pick up additional information through osmosis.

A healthy agile team works together in high-bandwidth, high-quality communication.

Adkins, Lyssa (2010-05-18). Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) (Kindle Locations 2459-2460). Pearson Education (USA). Kindle Edition.

The amount of overlap required to implement "core hours" is somewhat fluid, but in my own practice I've generally found that the core hours of 10:00am-2:00pm work well for most teams. It allows the early birds and the night owls to overlap for at least a few hours every day, while still providing plenty of flex-time so people can avoid traffic and avoid working against their natural biorhythms.

Of course, if you implement core hours at all, it's important that any all-hands meetings (e.g. daily stand-ups or Sprint Retrospectives) be scheduled to start and finish within the bounds of the core hours. This isn't really hard to do, but it's something that one should keep in mind if your team values any sort of consistency.

Skills and Productivity Have No Relationship to Wall-Clock Time

If you are managing an agile project, life is simple. Things are either "done" or "not done." As long as the team as a whole is meeting its commitments every sprint, and the team retrospectives don't indicate that there is dead wood on the team, then how people organize their own work (and by extension, their own work hours) should be fall under the M.Y.O.B. rule.

If Alice handles her fair share of user stories, helps others on the team as needed, and even occasionally finds time to pull additional stories off the backlog, why on earth would you care if she only works four hours a day?

On the other hand, if it takes Bob 8-10 hours per day, every day, to keep up with his fair share of the user stories and he never finds time to pay down technical debt or pull additional stories, there still isn't a problem unless:

  1. Bob can't mind his own business about how other people work.
  2. Bob is being allocated more than his fair share of the stories.

The first is a social issue, in which Bob is the toxic element. The second is likely a process issue--one that needs to be addressed by the team in a retrospective, or by the Scrum Master by bringing it to the team's attention.

In other words, as long as both people are pulling their weight, adding value to the team's overall efforts, and ensuring user stories meet the team's definition of done, then any "problem" is illusory. Such illusory problems are often holdovers from a management style that values high individual utilization over system throughput.


Always, always make sure you understand the root cause of a problem. In some rare cases, you may actually have a lazy or unproductive team member. In other cases, you may just have a busy-body on the team who can either be coached or voted off the island. Finally, the problem may just be a process that values perceived effort more than actual results.

Measure the productivity of your team as a whole rather than by micro-managing individual work habits, and define the validity of the overall process by its throughput. If the majority of your sprints are delivering tangible value and user-visible features, then don't break a process that's clearly working successfully!


There is almost always going to be variability in the productivity of individual developers. And the developers themselves have a good sense of who gets what done. @DavidEspina said that this fact is "protected" within the team. I would use the word "accepted". The developers simply know the pecking order. Usually, if it seems like the less productive developers are doing their best and are not otherwise disagreeable, it doesn't cause a problem. And if it isn't causing discontent among the developers, and management is OK with what is being produced, then it's probably not something that needs to be addressed explicitly.

If it is causing problems, then it absolutely has to be addressed. If management isn't happy about results because of specific developers, then more pressure or support needs to be applied to those developers to let them know that they need to step up their game. If they can't make adjustments and management still isn't happy, then you have to consider more severe consequences.

If the developers themselves are unhappy with the situation, then you really have to swing into action and deal with the problem quickly. Every day, the more productive developers will be building up resentment for the people who aren't pulling their weight and that's the kind of problem that reduces everyone's productivity at best, and destroys the team at worst. The productive will start to resent helping the unproductive. The unproductive will become more hesitant to ask for help when they really need it. It's a totally negative, viscious spiral.

The other thing is that when it comes time to hand out raises, bonuses, promotions, etc., these things have to go to the more productive developers. If there is a stable team situation with unbalanced abilities, rewarding the less productive members of the team is one of the quickest ways to destabilize things.

Having people of varying abilities around is the norm. We live it every day. There are people who are stronger, weaker, faster, slower, prettier...less prettier. We're used to that. We accept it. But when people see someone they know is far less productive getting rewarded more or even the same as they are, it's untenable.

And if the less productive people complain that they aren't being rewarded, you simply have the facts ready and explain why. It's unassailable.


Both Jesse and Trevor contributed answers that pertain to Resource Allocation in the thread I've linked below, but I think their thoughts play well with your question.

How can I make company-wide scheduling and resource allocation decisions?

This is also in line with David Espina's answer in this thread about focusing on the team and not on an individual.

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.