Flextime & Work Schedules

Because sometimes it’s a beautiful day outside. Because sometimes it’s not.

Flextime means going on that nice walk instead of merely gazing longingly at its potential. [Photo credit to #WOCInTechChat ❤]

Flextime is the most valuable and most under-appreciated perk that I’ve known in my professional career. It’s a benefit that I’ve used consistently and to great benefit throughout my time at Fog Creek, from my internship in the summer of 2008 through today. I didn’t anticipate it, but my relationship with flextime would change several times over the years, and the sort of value I derived from it would change dramatically.

Flextime in the wild

I’m mostly on board with Wikipedia’s definition:

Flextime is a flexible hours schedule that allows workers to alter workday start and finish times.

I’d expand the definition to include mid-day flexibility as well; most work doesn’t need to be contiguous.

There’s a lot of variety out there in how folks have come to implement this basic principle. A good flextime policy reinforces a culture of trust; a bad flextime policy requires you to explain or document personal details for your manager in an appeal to their human graces, hoping that their cultural norms of acceptable personal time matches with your own.

There are overbearingly corporate flextime templates out there with gems like:

Supervisors approve flextime on a case-by-case basis. An employee must first discuss possible summer flextime arrangements with his or her supervisor, then submit a written request using the Summer Flextime Request Form.

And defensive postures which frame flextime around a precept of approval:

Ask employees to submit a written description of how a flexible work schedule will achieve the same objectives as their current schedule.

And stances that pitch flextime as an employee productivity hack within the tangled strings of the puppetmaster:

the beauty of a working flextime system is that employees feel as if they have more control, but they’re still working under strict regulations that motivate productivity.

I wish the above were satire, but it’s really not. Ok, look, managers, it is fundamentally uncool for you to decide if someone deserves to flex their day or not based on the story they tell you and how it jives with your world view — either their job role supports flextime or it doesn’t. Sampling flextime in the wild reinforces to me that the structure of 9 to 5 is still strong in our culture, and deviations are exceptional and closely-inspected. Thankfully there’s a bit more progressive reasoning over at the Harvard Business Review:

the ability to carve out small, informal flex solutions can be really important for employee well-being, engagement, and retention.

I applaud this, and take it further: Flextime should be overwhelmingly informal. Respect your commitments and be productive; outside of that, flextime policies should give you implicit consent to use your day effectively and tend to what you need to. (Vacation and sick policies too!)

The implementation does matter, and the cultural cues from the implementation are key. I don’t think it’s sufficient for a company to have a “we have flextime” bullet point in their benefits list, nor does it quite work to have any sort of flextime application process. Both of these raise a barrier that will limit the benefit to the people who are bold enough to ask or stressed enough to summon the courage, and there remains a stigma that asking a manager for flextime benefits is asking for a favor which must later be earned back. There’s a tremendous difference between “You can ask your manager for permission to flex your schedule on an ad-hoc basis” and “We’ll assume you’re available from 12:00pm to 3:00pm and outside of that you should design the schedule that works best for you.”

Try to strive for flextime not as an HR policy, but as a cultural norm.

Flextime at Fog Creek

Here’s the current phrasing from our employee handbook:

Our policy for software developers is that you should plan to be on site most afternoons. We tend to schedule meetings right after lunch to avoid interrupting work, and we get a lot of value out of having people overlap at work for at least the afternoon. Other than that, you can design your own schedule.

It’s worth noting that as we became a dominantly remote company, these meanings shifted slightly: to be “on site” is to be at your workplace, wherever that is, and to be online and available; “after lunch” is New York time.

This is our framework. Plant a pillar in the ground and stand by it: Software developers are assumed to be online and available in the afternoon.

It’s a great pillar. Put together a few of them and you’ll have a lovely henge. Here’s a few things that flow from it:

• You mechanically cannot fill a developer’s day with regular meetings. If you want to hold an accessible meeting, it has to land in the afternoon. Therefore, folks have three hours of their day (one of which they spend eating lunch) as interruptible, schedulable time for meetings and coordination, and the rest is free and protected for heads-down coding or essential team-specific activities.
• There’s no manager approval around flextime, whether you have it, or how you can take it: you inherit the afternoon flow by default. If you’re going to miss some of the afternoon, you should check in and probably get it on the calendar that you’ll be MIA, but otherwise you can just go. No external permission needed to depart and go to the gym, to pick up your kid, etc., just give your teammates an informal heads up. You give notice, you don’t ask consent.
• Team leads have implicit protected time outside of 12 to 3 where they don’t need to wear regularly-scheduled management hats and can spend their time digging deeper into specific problems. This helps nudge folks away from a common software development management pathology of being taking away from being able to contribute personally.
• If you need to talk or meet with a dev, you can assume dev availability in the afternoon and just go ahead and book time with them. Though we still avoid interrupting devs, it’s nice to be able to just put something on their calendar (say, for an interview), rather than interrupting them twice: once to ask permission, and once again to actually meet.
• It means that all scheduled meetings should land in these afternoon hours and run efficiently within their time budget. Meetings that don’t are generally understood to be less inclusive. As a slight aside, I’ve come to believe that putting constraints on available meeting times tends to encourage the meeting owners to be more responsible and creative about running the meetings effectively. It’s easy to have meeting sprawl because it’s an activity that “feels like work” but often isn’t.
• Commitments still comes first; If you arrange to meet with a person at a time then your arrangement is the key. You should’ve been mindful of your flex intentions when you schedule the meeting. Meeting time conventions help a lot, but we can’t be absolutists about it; interviews start at 10am, servers can fail at any time, more intense coordination can come up before a big launch. Try to keep good habits around your own flextime and the flextime of others, but stay respectful and try your best to show up for your team.

You made it through the bulleted list! Awesome. Here’s a floppy fire fox. I went looking for a flexible fire fox, but that doesn’t seem to be in their nature.

Let’s not get too point-driven, I want to share some anecdotes with you. These span my working years at Fog Creek Software.

Year 0

I’m an intern, and my hours were more constrained: 8 hour days starting at ~10am, and “ask your mentor” if you needed to do something special. I didn’t have any “professional work” habits yet and I found the structure a welcome piece of guidance. My key flextime uses and values came from city exploration; I would bend my late-afternoons in order to go to Broadway ticket lotteries, the Daily Show, and other daytime New York experiences that a strict working schedule wouldn’t facilitate. My uses were minimal but appreciated.

Early Years

I’m a New Yorker now! I’ve moved to the City and I’m living in Brooklyn with my partner. We’re both night owls, and to add to the intrigue I had decided to delay my thesis defense, so I routinely stay up to the wee hours polishing the document.

My general work hours were noon to 8pm or later. This was the time that I pushed flex-time too far — I had a couple bad weeks leading up to my thesis defense where I wouldn’t show up until mid-afternoon. I broke the contract of fairness. My team lead rightfully scolded me and I got my shit together, defended the thesis, and made sure to get in by noon. (I know, right? So much privilege. Thanks for not firing me; this wouldn’t have been remotely acceptable in most industries.) I feel that Fog Creek handled that well: A person who I respected and was working with daily pointed out to me that, even though I was getting in a 40 hour week and writing a lot of code, I was not showing up for my team. I don’t know that any other human in the organization could have communicated as effectively to me. I thought the code output was what mattered, but that’s only one of the small (and often, easier) parts of software development. This was formative for my opinions around teams being able to resolve issues for themselves rather than through managerial proxies, wherever possible.

My chief flex-time benefit in these years was the facilitation of my night owl habits and my (over-stressed) ability to crunch on an out-of-work project. I preferred to sleep in and have a large chunk of time later in the day; I felt more creative and productive working that way. I’d often end my day by walking out across the Brooklyn Bridge in the fading heat of evening.

There was a funny little thing, though — I dramatically reduced our down time during a couple of partial outages because I was active and online while everyone else had already left for the day. Our sysadmins were the first line of defense, but when they needed to escalate to a dev, I was already present in the chatroom, up to speed, and able to help out. At the time I took this as additional justification of why my late schedule was awesome, but the lasting lesson here is that there are lots of tangential benefits to flexible schedules and distributed work hours.

Mid Years

I became a new parent, and shortly after returning from paternity leave, I also became a team lead. Being present during early childhood has always been a major life priority for me, an inviolable hard line, and I was committed to making that work. I was happy to find that it worked out at Fog Creek as well.

For a year, my schedule started fairly early in the morning at no fixed time.

As a new parent, oversleeping wasn’t a problem that I had anymore. I’d generally sign on with Fog Creek between 7 and 10 am, and then I’d strictly end my day at 3pm to go home to relieve my partner. On top of this, I took a vacation day just about every Wednesday. Yup: for a year, I worked 4 days a week, ending my days at 3pm.

I kept track of the time I was putting in and kept things balanced. I got in a lot of thinking, spec writing, and design iterations while sitting in parks or coffee shops with a sleeping child.

I’m very happy with what the team produced and I felt very proud of my contributions as well. An interesting thing emerged due to my “Vacation Wednesdays”: the team had to function headlessly one day a week, so any sort of interrupt or urgent issue had to be cross-trained to other team members. This often a great practice in theory, and the forcing function of my scheduled absence helped keep the theory well-grounded.

Management / CTO

After my year leading the Platform team, I became CTO. Fog Creek had never had a CTO before, so I felt that I had a lot of work to do in defining what that meant for me and for Fog Creek. My first year as CTO is when I took advantage of flextime the least. Being in a position of a managerial funnel at a very flat company meant that I was now coordinating with a whole lot more people, and just the scheduling requirements of making all those connections made it difficult for me to operate without covering 10am-5pm; my half-day of protected time had shrunk to an hour.

It was further complicated because I found myself as the only software developer on an executive team, and my new peers weren’t from the same flextime culture — they were from cultures born of customer-facing roles. Customer-facing jobs are more challenging to flex; the functions of the job tend to constrain the team to being sure to cover at least a 9 to 5 window. For most of the folks on this exec team, 9-to-5 was an assumed default and flexes were a scheduled (and generally approved) temporary exception.

Our exec team had a lot to do, and I didn’t feel comfortable asserting my hourly constraints. In retrospect I should’ve stuck to my guns; I would’ve rather kept the forcing function on fewer meetings and protected my development time, as well as “stood up for” our dev teams by proxy.

There’s a tendency for management and leadership to exhibit longer hours and fewer concessions for their personal lives. This means that, all policy aside, their direct reports feel a greater need to fall in line and mimic the culture exhibited above. I think this is backwards; the trend needs to be for management and leadership to be clear and open about the work schedule that works best for their productivity, and to be creative and intelligent about using their time well.

These days

Flextime keeps me here. Flextime means that I do one of drop-off or pick-up every day for my kid, as well as being able to handle all manner of special circumstances that come along. Today there’s a preschool graduation ceremony at 4pm and you can bet I’ll be there.

My Neighbor Totoro: Showing us the joys of flextime and remote work since 1988

Now, flextime is much less about making the most of the city or playing to the strengths of my love for nighttime, it’s about having carved out time with family and being consistently able to put them first when a choice comes up, backed by a confidence that I’m still able to do right by my employer.

There’s always a tally in my head.

Always always always. Since my first days of getting more creative with my work hours, I knew that I since I wasn’t doing a consistent “9 to 5” or what-have you, I couldn’t take for granted that I was automatically landing on 40-hour weeks.

There’s a fairness at play that’s very important to me, and I believe that it’s my part of the bargain to contribute well at a rate of, on average, 40 hours a week. During those hours I’ll give Fog Creek the best creative and productive energy that I can.

I keep the running tally of hours for fairness on both sides; I might run short or I might run long, and if I find myself swaying out of balance then I’ll do a few long days or a few short days to bring things back into alignment.

When my personal life was more flexible I was happy to work a long day or a weekend to pull the balance ahead whenever I fell short. I had energy for it and got in a lot of good code at odd hours. These days I’m more likely to spend my precious vacation days instead; the value of my time at home has increased and sometimes it’s not realistic or practical to recover weekday flextime with night and weekend hours, so vacation time can settle the debts.

End

I feel like we all tend to count the hours, thinking that if we put in our 40, we’re pulling our weight… and we also know that ultimately it’s what we produce that matters. If someone is underproducing and shorting their 40 they tend to get the axe for slacking off. If someone is underproducing but meeting their 40, we look around for other causes since they’re clearly “putting in the work.” Overproducers have a different short stick — we tend to look the other way on their hours, leaving them either in a great spot to meaningfully flex themselves, or in an equally great spot to work themselves to praise-reinforced burnout. It’s all somewhat goofy — creative workers aren’t assembly-line workers; our output is a product of the choices we make within the constructs that our company facilitates for us. All else equal, the time we put in can scale that up or down, but more and more we see the diminishing returns of those added hours.

I’m comfortable living up to a contract of 40 hours a week, and in that framework I want to be doing meaningful and productive work. My best work doesn’t come in contiguous 8-hour chunks from 9 to 5, and the best moments of my personal life don’t happen exclusively outside that window.

There’s a magic in the city of millions when you’re the only one.

I started this article thinking that I could share the seeds of a flextime framework, but as I end it I’ve convinced myself that the consequences of the flextime policy have perhaps grown into a greater and more interesting thing than the flextime itself. Sometimes, it’s a beautiful day.

P.S.

The flextime culture I espouse here is one that I desire to be available for everyone, but I write from the background of a software developer and have kept this article somewhat to my own domain. I touched on how customer-facing roles tend to be less conducive to flextime and especially implicit flextime. My suspicion is that above a certain team size, those concerns become solvable and introduce a tension between keeping a small, functional team (I ❤ 2-pizza teams) and the desire to keep a large enough team to ensure coverage. If you have experience working on a customer-facing team, I’m interesting in hearing your thoughts on how flextime can manifest effectively in these sorts of roles.