Is giving a software team "Free Fridays" for their own projects mutually beneficial? [closed]

Question

I'm starting to manage an existing small team of software developers (5 people) at a large (1000+ employee) company. While taking over the team, I've asked them for ideas on how to improve things in the office.

One of the most common ideas is "Free Friday", where developers get to work on anything they want on Friday. Can be R&D, can be different products in our company, can be creating new products, can be open source projects, can be long overdue refactors, can be training or experiments. whatever they want.

Many have given examples of work that they would like to start with, and their reasons usually involve "Breaking monotony" in long bug pushes before release, or wanting to let out a creative side, or to conduct research on ideas they've had. Someone suggested that Google does it so we should try it.

Letting them go free for a day per week will obviously make them happier, but is it beneficial for the company as well?

Answer 1

Yes - it can be very beneficial to both the company and the developers.

Try it for a few months and see!

Just giving them the day off may also be a productivity boost.
Microsoft tried a 4 day week and saw a 40% productivity gain. So anything they do on that day is just additional win.

But I'd suggest once a year/quarter/whatever get them to show something they built in this period. Stress that it can anything, need not be complete, but pair it with a "show and tell" and your company will benefit from it.

Internal tool development
Free time dev gives people a way to improve their own productivity, and sharing that around the company improved productivity immensely. One of the first things I did when getting my "free-second-Friday" (one day per fortnight) was redo our compiler toolchain. I was able to turn a 45 minute full build (C++ without optimisations) into a 6 minute build with a few hundred lines of Python.

Pre-research
When word spreads around the company of a new project, ideas started forming in my mind. Having some unscheduled time allowed me to start R&D'ing my ideas. So when the project came to be officially proposed I already knew some of the gotchas and optimisations.

This makes meetings at the start of new features/products more productive - your staff are free to prethink problems so can respond on the spot better. At least one time this stopped us from developing towards a dead-end, saving man-months worth of effort.

Open source tools become a better fit
Allowing your staff to contribute to open source projects will mean those projects were written with your use cases in mind. You'll be able to leverage open source projects better if you had a developer maintaining them.

Training
Your devs will learn new things, things they won't learn fixing bugs in their area of specialty. They'll grow in skill faster than they would if they were focused.

Optimisation of forgotten code
Our company had a "write once then forget" attitude, once developers got free time, they started revisiting old code and improving it. Some embarrassingly parallel code written in the 80s got refactored to run much faster, which we were able to ship as a feature. That was only discovered due to a free developer who'd learnt some parallel coding patterns.

Answer 2

I did this years ago and it sort of worked and the company got some great ideas and small projects.

The difficulty you face is when management (clients) demand things and you then have to justify your "unused" capacity (their Fridays). You either push back firmly, ask for volunteers for the next (eg) six weeks, or simply order people to do it.

I can tell you from experience having to do this will kill productivity and morale faster than if you had done nothing to start with.

But if you have approval of senior management, and enough political capital to start with it can work.

Another "trap" is when projects take more than a day and the engineer asks to bring forward this weeks Friday so their velocity isn't broken. Say "no". If it's that good and that much excitement, they'll have worked the weekend on it. Depending on what it is, you might want to bring it out as a proper project and have it worked on full time.

An alternative is to spend (eg) 2 days a month on "team building" - which is basically the same thing, except the engineers (developers/testers/etc) get an uninterrupted block. Bonus points for you if they gel into an even more cohesive team.

Answer 3

There is no one universal answer here, it will all vary on individual circumstances and what do you actually hope to achieve. Taking the example you've brought in the question:

One of the most common ideas is "Free Friday", where developers get to work on anything they want on Friday. Can be R&D, can be different products in our company, can be creating new products, can be open source projects, can be long overdue refactors, can be training or experiments. whatever they want.

This is something that was popularized by google, though at this point it was told and re-told so many times that the version passed around doesn't resemble much of reality anymore. While there were leeway days given for work on other projects, they usually had to be work related, and on top of that many of the google software houses were otherwise working 10h days to begin with. So by the time you got to the "free Friday", you already have did your 40 hours of that given week. This varies from one google cell to another, but as far as I can find from ex-google friends, it was never a bonus day off to do something software dev related, instead it was repaid to the company one way or another.

Similarly most of the companies (as far as I know, first hand or through grapevine) that do 4 days work week usually embrace 10-11h long work days, so you are still doing the same amount of hours but condensed into longer days. Same amount of hours is being worked as with 5 days long week. The rest paid the people adequately less, so if you did work 32 hours, you got paid on that basis, despite being hired for 40 of them, with the "free day" making up for the lower salary.

With that mythology out of the way we can circle back to your original question.

Letting them go free for a day per week will obviously make them happier, but is it beneficial for the company as well?

I am going to assume that you mean the scenario where employees get paid for the full 40h a week, but are expected to only work 32 of them, with the rest spent on work-related interests.

There is one benefit for the company from such scheme: employee retention and ease of recruitment.

Hiring is expensive, so anything that improves retention is certainly worth considering, though must be carefully considered as 20% of work time is a hefty price to pay. Some may make the argument that then the employees will make up for the lost productivity in the other days but I can't find a single sizeable company who tried that and didn't revert back as soon as the dust settled in. I wouldn't put too much stock in such claims - especially as those are very hard to measure, and I don't think that would be transferable across companies and even teams.

By similar fashion hiring and attracting talent will become easier, as you can dangle in front of them the same salary, but only expect them to work for the 32 hours every week, with the other 8 that they can spend on whatever tickles their fancy. Something worth considering for sure, but again, do your own calculation as that's 20% of salary that you are paying for someone to play around.

If your company is starved for talent and got money to throw around then this may not be a bad option to go with (and that was the case where I've implemented such scheme for a client). And then once you build up the talent pool you can do what google did and dump the scheme altogether.

Answer 4

I have worked for several companies trying this out.

Just because Google does something, doesn't mean it's a good idea, or it will work for your company.

If your company is a software house / agency, this can end up turning into something else. You start off doing cool things, but inevitably management will put higher value on pandering to clients than it does on innovation.

The result is usually "Ticket Friday", and before you know it, your Friday has gone from OK to Cool to the most mundane stressful day of the week.

To innovate and do R&D, 1 Friday a week is not enough. By the time you pick up from the previous week and re-familiarize it's too late to do any significant work. If you want to innovate, then use Friday as a collaborative research day.

Have employees sit in a room together and discuss ideas using a white board, pens and paper. You can gamify this a bit and make it fun. Come up with a project and then have it run as any other project throughout the week.

The only time I have seen successful innovation projects is in companies that either have huge budgets, or where employees work 14 hours a day, so Thur-Fri are basically free.

Is it mutually beneficial? Not really. All of this is still work, and the company owns anything produced. Like a Games Room. It's not done for employee benefit, it's 100% for the company's benefit disguised as an employee benefit.

What is mutually beneficial? Letting them take the Friday off (maybe), it depends on the employees. Some will work harder Mon-Thurs as a result, and productivity will be higher, but some employees won't.

The only thing you can do is try it for 3 months and see what happens.

Answer 5

Your problem isn't your team, it's your management. You need to show value. At the very least, you need to show that your team aren't just browsing the web or playing their game of choice.

There is an answer here.

They can do anything they want to do, but they must submit it and be able to justify its value for the company

That's submitting it in writing to you. This only needs to be a one-pager, but they do need to say

• what they'll be doing;
• how long they think it'll take;
• how it helps the company

So they can't just do anything. It could be training for you, it could be checking out the competition, it could be refactoring, it could be working on a new feature, whatever. But it has to be work-related.

And the main reason it has to be work-related is that you have to justify this to your management. It shows them that you're not letting your employees slack off, and there actually is some value being generated for the company.

Because on that theme, never forget that whatever your guys do on company time, the company owns.

Answer 6

Internal Hackathons

Instead of open-ended project days, which depend a lot on developer discipline and motivation, you can instead lobby for periodic 2-3 day hackathons. This is logically equivalent to gathering several "Free Fridays" together for a single sequential event, monthly, quarterly, etc. The advantage of a hackathon is that you oblige teams to declare what they are working on, and also to demonstrate their work at the end. Of course, "team" is any group of employees that agree to conspire on a project, and does not have to relate to the org chart in any way.

Because they will demonstrate their project publicly, teams are naturally influenced to make a company-relevant effort, whether something public-facing or an internal development toolchain effort. The public demo brings accountability that Free Friday does not, but also gives workers a nice forum to improve their visibility outside of whatever projects they got stuck on. It also gives them a good networking outlet, assuming the hackathons are more than team-wide (VP-level org-wide is a good starting point, but the broader group, the more serendipity you buy).

Many times, employees have good ideas but are bad at internal marketing. They lack the political capital to sell their idea, or management isn't interested in hearing about it, or they tried it and it didn't work, etc. A hackathon allows such employees to build a proof-of-concept to demonstrate how they could do it better, or make it possible, or just provide a vision by building something real for folks to interact with, even if woefully incomplete. Of course, you then want to promise that the top projects get a chance at actual funding.

Note this avoids most of the downsides of Free Friday while capturing most of the upsides. It's not my original idea. I'm just relaying what an employer did that I think was conceived and implemented well. They went so far as to recruit hackathon teams with promotional videos and internal marketing, because the project ideas and POCs they generated were considered so valuable by upper management.

Answer 7

I would say that with a twist, you can get some of the benefits for the employees without losing 20% of their worktime.

I support the other answers in saying that this is a very expensive proposal indeed, and the increased productivity through higher satisfaction/occasional retention probably doesn't make up for time spent doing the work. Also, it can backfire - if you don't have the power to change deadlines or reduce the amount of regular tasks (support inquiries, etc.), then they either have to cram their normal work in 4 days, or they have to give up the personal friday you told them they are entitled to, to get the work done. This is worse than never have been promised that time.

The largest benefit for the employees here comes from the autonomy and self-direction you are granting them. People just feel better about their work if they decide to do it, as opposed to the task being handed to them. Also, if they have to think themselves about what needs to be done, as opposed to letting the product owner think it up, they feel more responsibility and pride for the result.

I believe you can get that effect by combining your idea (seld-directed Fridays) with the main project. Instead of having them develop their own project, tell them that they still have to work on their main product - but instead of picking items off the backlog (which you have created based on all the new features the customers cry for), they can decide personally, or in groups, what to improve. Every product that has been in development for a while gathers its own cruft, which starts bugging people while working on it, but you as a product owner are not even aware of these thorns in your team's heel. (you may vaguely know they exist, but you don't know which is the most painful). Let them deal with them as they wish. This will result in the repayment of technical debt in your main product, which, unlike the personal project day, will have long-term benefits on your business goals.

Of course, you may not need this if you have other mechanisms for getting rid of technical debt. However, I don't think there are many companies where senior management approves whole "rewrite this" sprints, and sticking rewriting tasks on the normal backlog reduces the self-direction benefits. So, if you can ensure that the team has a day (or even half a day) free from new-features-writing, giving them this kind of freedom can be beneficial.

Answer 8

From my psychology dropout stundet view:

I think you have to consider different factors. It can work in your group if the motivation for the project and the cohesion of the group is high. It can be detrimental if they are just for the money, they would start to procrastinate or dedicate their time to only one aspect of the code.

If the motivation is notorious, it may be helping to specialize your people in aspects they like the most.

If there is not that much, you should consider making and standardized test on motivation and try to work that side. The "free friday" can be an excuse to rest instead of work.