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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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)

Answer 6

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.

Answer 7

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.

Answer 8

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.

Conclusion

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!

Answer 9

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.

Answer 10

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.