Friday, July 29, 2011

The implicit bias with flexible working hours

I'm a big fan of flexible working hours. I'm one of the few that gets in early and leaves early due to family commitments. I do seem to be in the minority as most techies seem to prefer to come in late and leave late. I also don't have to stress about being late, because my employer knows that I'll make up those hours.

One problem I've discovered being an early starter is around crunch times. I've found that there's an there's an implicit pressure and bias by the team to have everyone working late until the same time. This isn't so much of a problem for late starters, but for early starters they may have already put in 2 to 3 hours of work before others arrive.

All I ask for is teams with flexible working schedules accept that around crunch times early starters might stay late, but not as late as their later starting colleagues.



  1. I was an early starter at one time, but as a tester, found myself ending up staying late because programmers would check in fixes late in the day and I wanted to verify them. That was before I was on a team that automated all regression tests and had them running in a CI process - now, the test suites can verify fixes for regression failures. If it's a problem in new code, the programmer has already verified the fix before checking it in - hopefully!

    After a couple of years of struggling with this, my team learned how to manage our time well, so that we don't HAVE crunch time. Yes, sometimes stuff happens, and someone who comes in early ends up having to stay late to make sure a release can go ahead, but this is extremely rare. And we also have the flexibility to take some extra time for ourselves when needed, as well as putting in extra time for the team when needed.

    I think this dilemma is a symptom of a bigger issue that the team needs to work on together, trying small experiments to see if they can ensure that no team member feels unfairly burdened.

  2. It strikes me that "crunch time" is the time when pairing and high-speed team communication is most crucial, and when regular scheduled release times are helpful as well. My tendency would always be to count the time when the entire team is present as "work" and everything else as "design spike and learning" time even in normal workload times, but especially when there's pressure from externalities like "deadlines".

  3. I've been starting to rethink working hours based on writing down my thoughts and reading your comments. I'm going to start writing a new post about it. Thanks to you both for shaping my thoughts on this.

  4. No one should stay late. I work in the software industry and personally never leave the office any later than 5.30 (6 at a real push)