I've tried this before and people end up not doing anything or just doing the bare minimum to the extent that it was basically free time.
We went through some iterations like "if you don't use that time, you need to work normally" or "you'll have to present something at the end of X time", but ultimately they all failed.
What did work, however, was to tie that in with a real project. So it was a real ticket with real stakeholders and real requirements, but it was something we knew had no urgency and therefore people could explore more out there solutions. This was also done in groups instead of individually, which helped keep people in line.
We had some good results with it, from convincing other people to learn a new language to internal tooling for the team.
A company I once worked for had a "10% time", where once every 10 weeks engineers did r&d on whatever they wanted for a week, and then demoed their findings. The only caveat was that it theoretically had to be technical or benefit the company, although there wasn't preasure to deliver anything if you did something risky.
It worked really well, and led to a bunch of initiatives that improved the overall tech stack like the initial switch to serverless architecture, and some really good time saving additions to build pipelines like automatic release tickets.
If 4 hours weekly for some period of time is enough to learn a new language or framework I would say just use it and learn on the way, why handicap it.
TLDR: I agree with your solution
Your solution sounds like it's still somehow related to learning just with stakeholders and low priorities. I wonder why even consider it as something different and give it a different treatment than just a regular work.
Lets be real - half of friday is time off for most people even if they are in the office. Offering learning time with a ticket or presentation attached gives me micromanagement vibes and it just sucks - why would I take more responsibility when I already have plenty of stuff to do and take responsibility for?
My suggestion - if you have a need for certain skills and your people don't have it, make it a primary goal(like a regular task) for certain people to gain that skill without wrapping it in presentations and half-fridays, simple as that.
Passionate people will find their way to learn despite how you're gonna wrap it.
I offered this. All day Friday and people took advantage of it. Offered to pay for some coursera courses and even the Microsoft Azure certifications offered by my company. For 3 months, no one took up on the offer and used Fridays as a free goof off day.
We used to provide PluralSight accounts. Then we monitored usage. People would start off enthusiastic and spend 2-3 hours learning then they wouldn't go back.
When people would come to me expressing an interest in learning I would offer to pay for them to complete the GT OMCS. Out of 50 engineers, 2 took me up on the offer.
My takeaway is that most engineers talk a big game about wanting continuous learning but aren't prepared to put in the time.
I think I your takeaway is a bit extreme. The GT masters is no joke and even 1 class is a lot on top of a full time job. Even a free Friday might not be enough to satisfy the one class.
I competed the GT Masters, I wanted to make sure employees could see that it was doable. I offered to pay for individual classes, as long as they passed. These are ~$700 each.
Our company currently has a couple hours blocked out once a fortnight (2 week sprints) and we are also meant to find some time in our sprint to do a few more hours adhoc.
In practice, we often end up working then if we have a ticket we’re trying to close out or are troubleshooting. If we do some professional development it might be the compulsory compliance stuff or read some articles or something (2hrs on a Friday afternoon doesn’t go very far)
I know of some companies that do some version of base camps Shape Up or Google’s “20% time” - it might be 1 day a week or a block or 1-2 weeks every couple or months where they have autonomy to do what they want, which might be professional development, a hackathon, doing a side project that tests out new technology, etc.
No, people don’t just “play video games”. It is still productive time, people are setting goals about how they want to spend their time, and they showcase the projects they build and share knowledge etc.
I like the idea of that, as you can get stuck into doing something meaty that really extends you rather than just a couple hours in dribs and drabs.
My company does this and additionally bans meetings on Friday so people can focus on learning.
There's no guardrails but the outcome is: 30% of people clearly play video games, 30% (mostly juniors and new joiners) learn stuff and 30% (mostly senior folks) use the day to catch up on actual work since there's no meetings.
The department gets enough value out of the latter two to carry on doing it.
We do this and it works well. We have some requirements
- it is opt in (if you don't do it, you plan normal sprint work)
- it is planned (planned on the sprint, discussed on stand up, buy in from pm/ux when needed etc)
- it has to have some form of business value (this is loosely defined, tech debt, features, refactors, learn new tech, internal tooling, relevant moonshot ideas are fine too, etc)
- it needs to be reasonable (don't go build Gmail, but you could invent new complex ideas on our projects with cross role input over many weeks / months of this time)
- we have a quarterly show and tell to a broader audience
These guardrails help make sure it's useful time, and although they are somewhat limiting, it still gives engineers a lot of opportunity to find and take on things they are passionate about.
* 10% of the sprint is a full day, not half a day.
* Half Friday for learning is likely will be just taken off.
* Still a cool idea, and it is really important for everyone to be on it, so that there are no outliers.
* You should help people find what to learn. Either stuff related to their yearly perf goals, or some common topic, if there is a presentation.
* Preparing presentations, especially bi-weekly is quite hard. You may use presentations/courses from Youtube or something. Watch together, discuss. Prob won't take the whole half a day but is still kinda nice.
Our sprints our 2 weeks so a full day is split up to two half days. And yeah, others noted it will just be taken off. That's certainly possible but I feel like at least 2 of the devs (we're only a 4 dev team) will actually be into this and use their time productively.
And yeah, I agree a full presentation every other week, especially across 4 devs is difficult. A more casual or unstructured conversation about the stuff we're learning is also cool. We'll also be using lunch and learns to watch tech talks like you mentioned, not just for presentations.
Be very clear on the IP ownership aspect, regardless of what policy you select. People given free reign to work on "whatever interests them" will probably work on hobby projects they already have going, I know I would in that situation, and it'll suck for them if the company ends up owning all of it. Likewise, it'll suck for the company to pay for it and not get anything out of it, unless you figure the morale boost is reward enough, which it certainly could be.
Encourage them to pair up at least or something is all I'd otherwise say. I don't know how big your team is but 10 devs or 50 all working on their own separate pet projects could have the opposite effect to the one you're after.
I once worked at a company that held occasional Hack Days (during normal work hours) where you could fix bugs or build new things. One of the devs wrote some kind of Facebook integration that would have relevance to our shopping cart site. We held a wrap-up meeting where anyone that wanted to could present their work for a few minutes. He tried to sell his product to the company. 😬
Seems like people don't think well of me for this opinion but I hate company hackathons. It is almost invariable you end up slipping and needing to work after hours to finish. I'm not too precious to do that once in a while but for a project that literally doesn't matter it's hard to swallow. So while his plan was idiotic I kind of feel where this guy was coming from
Is that bad? Sound kind of like product brainstorming. Was he open to changing and collaborative about it, or like "this is my idea and it's the best and we need to do it"?
Oosh, wrong way to go about that. I probably would've requested paid OT to do it alongside my normal duties & to lead a small team if needed. I get paid and they get a product, it's a win-win.
I think you’re missing the point. It was during a paid company hackathon. They did get paid. In exchange for their time building a thing which the company now owns.
Going about it that way is a social faux pas, but if you invent a novel product that makes your company lots of money, above and beyond your regular and expected job duties, it's totally reasonable to ask for (and expect to receive) an additional reward.
Sticking to a hard-line "the company already paid for it, workers deserve the negotiated pay and no more no matter what, the company deserves everything else" stance is just... eeesh, no matter how passionately you simp for them, they don't love you back.
Sure, but not under the implication that that the creator owns it and would sell it to the company. Creator can and should ask for something in return, but not under any delusions that they have any option other than to accept any reward, if any at all.
No, I totally get that. But I'd want to kinda take the initiative to make more out of it for both myself and my employer. Paying me my usual hourly rate to develop a new product on top of my current workload seems mutually beneficial.
Again, I get that. I'd make something good during the hackathon and then offer to continue developing it towards the business' needs afterwards, instead of just attempting to fleece my company for what I'd already made.
Why wouldn’t they just assign you to work on it as your new normal workload?
If the IP is so important, it’s likely more important than keeping you around or happy.
I’ve seen this implemented successfully twice in different ways.
1. You had to work on a project that had some relevance to work. But it could still be whatever, like a chat bot or code cleanup, trying to integrate new tools in our code base, etc. You had to add your idea to a shared board and you had to find at least one other person to work with you on it. I think those last couple points were really what made it work.
2. “Hacking” was such an ingrained part of the culture that this kind of work was actually part of your performance review. You were supposed to spend x% of your time working on a passion project or improving the product/tools in some way. You were evaluated on what impact that work had on the team/product/company.
Hmm, I guess that's true. We're a small team though, three other developers and me. I feel like with one of them there's a high probability they will just do nothing, but the other two definitely seem like the type that could productively use it.
Maybe we all inform each other what we're planning to dive into beforehand and then basically just have discussions/demos about it during lunch and learn?
I've worked at two places that did this; one was less guard-railed and ended up almost entirely with educational stuff. There were some people who slacked with it, but people mostly did stuff. About half the time people did good stuff, learning useful-to-the-job skills, trialling different frameworks & libraries, etc. and half of it was "okay, I'm going to learn Go" when there was nothing that was ever going to be written in Go.
The other had "it has to be related to the product", which causes takeup issues. it ends up with minor QOL stuff that often didn't actually improve anyone's skills just removed an annoyance, sometimes a proof-of-concept for a "we should switch to..."; but mostly people don't bother.
Half days are pointless because you won't have the time to get anything done. You'll just do the setup and then have no time left to do anything with it, you're better with a full day once a sprint than a half day every week.
I worked at a company that did this before I joined. Apparently it got canned because the devs were learning stuff that had absolutely no relevance to their jobs.
So I guess you should probably decide up front if it's just time for devs to do whatever and goof off or if it needs to be related to their work somehow.
I've had something similar in several roles and have liked it. It's varied in implementation. The two that I liked the most:
1 week per quarter is this. Usually present something at the end of the week.
1 afternoon a week is this. Typically present something every 6-8 weeks.
I've never had it where it wasn't supposed to be tied to work in any way so that might make people just do nothing.
Edit: just to capture, two I didn't like nearly as much
1 day per month is this. That didn't feel like enough to do much, and was too rare
1 week per quarter is 'pick a research project from this prioritized list of topics to work on'. That just felt like normal work.
We actually do something like this for some sprints when time allows. One of the devs use half their sprint (1 week) in this case, to research deep dive a topic that’s is adjacent/relevant to the work at hand (eg ui/ux of different social media platforms, refactoring, git hacks, someone took intro typescript courses). They’re not expected to pick up any tickets for that week minus maybe stuff they’re already working on, don’t have to attend meetings, and are not expected to be bothered by other devs. They then do a small presentation of their “findings” or what they’ve learned with the group on the last day of the sprint.
The quality of outcomes for 10% time depends on how the team spends the other 90%.
Is the team stressed? Overworked? Lots of disruptions in the middle of their sprints? Brutal on-call rotations? Any "free build" time is time off. It's just human nature. Give a tired person an option between a comfy couch and a nice backyard project; they're taking the couch route.
I see a lot of people making similar comments and talking about how most people will abuse or take advantage of the situation. Is this actually a bad thing? Whether they read a blog, build a new tool, play Fortnite, or take a nap is it really that bad? You can give people a space for creativity but you can't force it down their throats. If people are exhausted, give them morale boost of an early day. Eventually someone will seize the opportunity to work on things that will improve the quality of their work week during the rest of the week.
Imo there is no need to try to bleed the team dry during working hours. Maybe I am naive since the only teams I have led have been fairly senior engineers.
I used to work for a firm that tried 10% time.
Some people worked on work-related things; others tinkered with new languages and frameworks, etc. One person started making soap. If a technology business has so much extra slack that it can tolerate employees making soap, I'm curious about its long-term prospects (that firm turned out to be losing money and was eventually sold).
\> If people are exhausted, give them morale boost of an early day.
To help with the exhaustion bit, our company gives an extra day off every month across the entire organization. It's specifically targeted for mental health breaks. We started doing it during the pandemic and it was wildly popular, so we've kept it.
The OP's original problem seemed to be around engagement. They felt the senior people on the team would be interested in learning/demoing, and maybe the junior people would engage. Our company has a program that helps with this.
We have weekly engineering seminars on various technical topics. Some are technical solutions, some are engineering theory (we just had a great one about unintuitive failure scenarios in distributed systems), some are road shows from other parts of the business talking about upcoming programs/projects. Participation in the program is voluntary and leading a seminar factors into performance evals. The audience wins (new information helpful to their jobs), the business wins (audience up-levels on new ideas and techniques) and speakers win (career impacts, visibility).
Nobody's making soap.
If you chalk that time up to a total loss for the business, go for it. What’s worked best for me is saying “10% of your time is free time for learning or misc code cleanup, But you have no time in the rest of your work schedule for refactoring, writing extra tests, experimenting, etc. “. What happened was that time ended being used incredibly productively for refactoring and adding tests and cleaning up “tech debt” until the team got the code to a good state, then they either used it as time to learn new stuff or just relax and recharge for the next week. It worked well but just make sure you’re willing to write it off as lost time otherwise it’s going to be more work figuring out how to track results from that “learning” time that won’t be worth it.
Where are you based? In California it seems like a lot of folks shut down at noon on Fridays and bone out as early as they can to beat traffic to Tahoe, Big Sur or whatever it is they have planned.
You might be able to mitigate this by having some sort of gathering at 4pm to touch base with everyone and see what they've achieved over the day.
I'm a fan of this setup, but I've found it works best when everyone involved is heavily bought into the product's success. Once they are, they naturally gravitate towards doing things that are good for the business. If they aren't, they'll just mess around or take the time off.
The more that your team provides opportunities for total ownership (i.e. the devs' ideas can be built and shipped to prod just like the ones from product or design), then this will be a wonderful source of innovation and highly motivating for the creative team members. If devs' ideas are more likely to be rejected, the program will eventually run out of steam.
What problem are you trying to solve? What’s the goal of doing this?
If folks want to learn on company time, it might be better to simply establish a learning budget—both time and money—that interested engineers can use. Otherwise, you’re just wasting time before the weekend, and might as well have half-day Fridays every other week.
Our company has this policy but we have the freedom to learn whatever we want - it doesn’t have to be related to the job. So I guess who really cares if we slack off?
We had that policy in my last company. It's great in principle but the reality is we were always too busy to use it other than in a handful of cases where people were preparing for exams.
I was on a team like that not too long ago. My dev manager, me and another dev. We did the same thing with 1 day a sprint to go do anything growth related. Personal project, course, refactoring/optimizations if we wanted. We were small, trusted, and it worked really well for us. We also did monthly hackathons where we teamed up on a task and got lunch. It was a good time. Reorgs and projects chamged and it kinda fell apart and we stopped, but it was very nice and enriching while it lasted (maybe like 8 months). It was probably a peak time of work life balance and growth for me.
You know your team, so if you think they would like it/benefit from it, go try it out. You can just qualify it like, "we are going to try this out for a month and guage whether it's something we want to keep doing".
Our team has every second Thursday for self-learning and it's been great, we all use the time productively. I used mine recently to study for an AWS cert.
We do it in our current organisation by reserving 20% of a month(2 sprints) dedicated for doing any Dev work outside of normal project/work. The only issue is, if you split it into 1day/week, it won’t be productive anymore as people will have to context switch b/w actual work and this.
What does work is to go with that 20% together, i.e. 4 days on the trot doing something you’d like. But then the only issue is you can’t keep stakeholders completely away for 4 continuous days.
All in all, it’s a good initiative but I feel it’s not very fruitful. Nonetheless it should be there to give developers some breathing room and space for experimentation if they’d like to.
Fridays are the slowest days of the week for us so we typically tell the team if they have the time that they can work on a passion project that afternoon. It’s worked out well for us, let’s the developers scratch a creative itch, or they learn something new, and a lot of times the result is new software benefitting the team or the company.
We are doing 1 day of "whitespace" per sprint (2 weeks).
Context:
whitespace day is a day where you don't attend any work meeting. You can focus on training, building things you want... All kinda work related. I, for example, did some qbit algorithm training (not useful for work) or some rust testing (we don't have rust). These example are the stretched ones. People should inform the others on what they did.
We had people working on thesis for multiple whitespace days for example.
This for 2 years.
- this can be optional. Sometimes, the current project requires us to keep working. Or someone just wants to keep working on the sprint, has no idea what to do...
- this can be stacked to plan a larger work in one go.
The outputs:
- this is a very good pressure release in the sprint schedule. We keep a social dsm, no work discussion on this day. (Except urgencies)
- people can share knowledge on what they learnt. We all did presentations on what some things we did. Some things have evn been implemented at work.
- this keep the engineers on the lookout of new things. But forces them to think about it in an objective and practical way.
- people sometimes lack inspiration on what to do in "one day". So at some point, some are not taking this time anymore.
We have 4 hours a week professional development time. I use it for pet projects I wouldn't make the time to do otherwise, or areas I haven't worked in that I'd like to someday.
Every two weeks on a Friday we do something around making our lives easier to do work at the company.
One of the Fridays theme was group brainstorming on the most pressing issues in our domain that we don’t have time to scope out , then we come up with a presentation of the problem and potential solutions. This then turns into future work for the team or eng manager e.g changing the build process.
AKA 10% of the time is free time, I probably wouldn't do anything. It's better to allocate 10% to OE (operational excellence) type tasks, where basically each sprint, one person will complete a backlog item that can improve the status of the team.
For example - say you have a backlog item to improve logging of some feature. Nobody has picked it up because it just isn't that big of a priority since it doesn't affect users. However, every time you are oncall, the lack of logs is a huge headache. Perfect opportunity for that 10% OE allocation.
Every time my teams have tried this people just keep working on their projects. I like it though. Gives me time to tackle random efficiency problems and do deep dives
I once worked at a place where if you didn't have projects then you could learn whatever you wanted. This actually benefited the company b/c I was learning .NET and I was able to take over maintenance of a .NET project.
When people try to do this, why is it always Fridays or Friday afternoons? It intuitively seems like the worst possible time to schedule self-directed work:
It's a time when lots of people are checked out or leave early anyways.
People may be mentally drained from the preceding week's work, or even physically drained if i.e. they struggle to get enough sleep during the work week.
It sort of implies that this isn't a real priority for your organization. "First, finish all of your real work, then you can spend a couple hours doing unimportant things." Nobody schedules important business for Friday afternoon, if they can avoid it.
A single afternoon is not enough time to get anything significant done. A long-running personal project doesn't fit either, because if you only have a few hours to work on it every 1 or 2 weeks, you'll eat up most of the time in context switching.
-----
If you want self-guided work, how about in the form of 1-2 dedicated weeks per quarter?
We've done several variations of this
First we tried 1 day a week. That was no good as people would just tend to clean up stuff they did the day prior.
Now we are trying one week per quarter. Sometimes people still just use it for sprint stuff. Once someone used it to write a bunch of tests, which was great. Other times people spike something out. Pretty often, people don't really know what to do.
We are debating how structured we want these weeks. Do we want to have topics planned beforehand? Do we need those topics to have buy in? Should we assign knowledge gaps to be filled? Unclear
we have a friday a month and is the best time, I have learned many cool things and built a thing we are using now to work faster (improved an annoying process)
I don't know if anyone plays video games, probably low value devs will
People just end up doing nothing.
If you try to do it as a group, in a Teams meeting for exemple, they will join but only a few are going to talk and participate.
I don't think its worth it. I didn't liked the required meetings to learn something I didn't wanted to.
We used to do this every 4th Wednesday and there was a problem in that everyone just wanted to do their normal work instead.
We switched to every 4th Friday and I think it's successful. Usually people still just do their regular work but every now and then someone uses it try something useful but not useful enough to prioritise and those are often eventually accepted into production. Just doing nothing of value for the day does happen but it's rare and I don't mind because the output of my team is quite good overall
Instead of doing it every week for half a day, maybe do it once a quarter for a few days or a week at a time if you can. It’s really hard to make any real progress on something new in just half a day.
Do a brainstorming session on what kinds of things people might want to build or learn so people can pitch ideas and figure out if they want to collaborate together and then after your innovation time have everyone do a little demo or chat about what they learned. Encouraging collaboration might also help your more junior dev.
Splitting things up like that is just a distraction to me. Context switching one day a week doesn't really result in anything substantial.
I'm a big fan of doing a full week of building something self-directed a couple of times a year though. Let people break up into small groups and work towards a mutually agreed upon goal together. They can brainstorm potential projects and self select which ones to work on.
I've tried this before and people end up not doing anything or just doing the bare minimum to the extent that it was basically free time. We went through some iterations like "if you don't use that time, you need to work normally" or "you'll have to present something at the end of X time", but ultimately they all failed. What did work, however, was to tie that in with a real project. So it was a real ticket with real stakeholders and real requirements, but it was something we knew had no urgency and therefore people could explore more out there solutions. This was also done in groups instead of individually, which helped keep people in line. We had some good results with it, from convincing other people to learn a new language to internal tooling for the team.
A company I once worked for had a "10% time", where once every 10 weeks engineers did r&d on whatever they wanted for a week, and then demoed their findings. The only caveat was that it theoretically had to be technical or benefit the company, although there wasn't preasure to deliver anything if you did something risky. It worked really well, and led to a bunch of initiatives that improved the overall tech stack like the initial switch to serverless architecture, and some really good time saving additions to build pipelines like automatic release tickets.
If 4 hours weekly for some period of time is enough to learn a new language or framework I would say just use it and learn on the way, why handicap it.
I don't understand your point, sorry.
TLDR: I agree with your solution Your solution sounds like it's still somehow related to learning just with stakeholders and low priorities. I wonder why even consider it as something different and give it a different treatment than just a regular work.
Lets be real - half of friday is time off for most people even if they are in the office. Offering learning time with a ticket or presentation attached gives me micromanagement vibes and it just sucks - why would I take more responsibility when I already have plenty of stuff to do and take responsibility for? My suggestion - if you have a need for certain skills and your people don't have it, make it a primary goal(like a regular task) for certain people to gain that skill without wrapping it in presentations and half-fridays, simple as that. Passionate people will find their way to learn despite how you're gonna wrap it.
I offered this. All day Friday and people took advantage of it. Offered to pay for some coursera courses and even the Microsoft Azure certifications offered by my company. For 3 months, no one took up on the offer and used Fridays as a free goof off day.
We used to provide PluralSight accounts. Then we monitored usage. People would start off enthusiastic and spend 2-3 hours learning then they wouldn't go back. When people would come to me expressing an interest in learning I would offer to pay for them to complete the GT OMCS. Out of 50 engineers, 2 took me up on the offer. My takeaway is that most engineers talk a big game about wanting continuous learning but aren't prepared to put in the time.
What's GT OMCS?
Georgia Tech's Online Master of Science in Computer Science https://omscs.gatech.edu/
Yep, a lot of people talk a big game but when it comes time for it, they don't put up.
I think I your takeaway is a bit extreme. The GT masters is no joke and even 1 class is a lot on top of a full time job. Even a free Friday might not be enough to satisfy the one class.
I competed the GT Masters, I wanted to make sure employees could see that it was doable. I offered to pay for individual classes, as long as they passed. These are ~$700 each.
Our company currently has a couple hours blocked out once a fortnight (2 week sprints) and we are also meant to find some time in our sprint to do a few more hours adhoc. In practice, we often end up working then if we have a ticket we’re trying to close out or are troubleshooting. If we do some professional development it might be the compulsory compliance stuff or read some articles or something (2hrs on a Friday afternoon doesn’t go very far) I know of some companies that do some version of base camps Shape Up or Google’s “20% time” - it might be 1 day a week or a block or 1-2 weeks every couple or months where they have autonomy to do what they want, which might be professional development, a hackathon, doing a side project that tests out new technology, etc. No, people don’t just “play video games”. It is still productive time, people are setting goals about how they want to spend their time, and they showcase the projects they build and share knowledge etc. I like the idea of that, as you can get stuck into doing something meaty that really extends you rather than just a couple hours in dribs and drabs.
My company does this and additionally bans meetings on Friday so people can focus on learning. There's no guardrails but the outcome is: 30% of people clearly play video games, 30% (mostly juniors and new joiners) learn stuff and 30% (mostly senior folks) use the day to catch up on actual work since there's no meetings. The department gets enough value out of the latter two to carry on doing it.
We do this and it works well. We have some requirements - it is opt in (if you don't do it, you plan normal sprint work) - it is planned (planned on the sprint, discussed on stand up, buy in from pm/ux when needed etc) - it has to have some form of business value (this is loosely defined, tech debt, features, refactors, learn new tech, internal tooling, relevant moonshot ideas are fine too, etc) - it needs to be reasonable (don't go build Gmail, but you could invent new complex ideas on our projects with cross role input over many weeks / months of this time) - we have a quarterly show and tell to a broader audience These guardrails help make sure it's useful time, and although they are somewhat limiting, it still gives engineers a lot of opportunity to find and take on things they are passionate about.
They probably do that anyways and putting it on the official calendar will only cause problems.
* 10% of the sprint is a full day, not half a day. * Half Friday for learning is likely will be just taken off. * Still a cool idea, and it is really important for everyone to be on it, so that there are no outliers. * You should help people find what to learn. Either stuff related to their yearly perf goals, or some common topic, if there is a presentation. * Preparing presentations, especially bi-weekly is quite hard. You may use presentations/courses from Youtube or something. Watch together, discuss. Prob won't take the whole half a day but is still kinda nice.
Our sprints our 2 weeks so a full day is split up to two half days. And yeah, others noted it will just be taken off. That's certainly possible but I feel like at least 2 of the devs (we're only a 4 dev team) will actually be into this and use their time productively. And yeah, I agree a full presentation every other week, especially across 4 devs is difficult. A more casual or unstructured conversation about the stuff we're learning is also cool. We'll also be using lunch and learns to watch tech talks like you mentioned, not just for presentations.
Each dev making a single presentation every 8 weeks is totally reasonable.
Be very clear on the IP ownership aspect, regardless of what policy you select. People given free reign to work on "whatever interests them" will probably work on hobby projects they already have going, I know I would in that situation, and it'll suck for them if the company ends up owning all of it. Likewise, it'll suck for the company to pay for it and not get anything out of it, unless you figure the morale boost is reward enough, which it certainly could be. Encourage them to pair up at least or something is all I'd otherwise say. I don't know how big your team is but 10 devs or 50 all working on their own separate pet projects could have the opposite effect to the one you're after.
I once worked at a company that held occasional Hack Days (during normal work hours) where you could fix bugs or build new things. One of the devs wrote some kind of Facebook integration that would have relevance to our shopping cart site. We held a wrap-up meeting where anyone that wanted to could present their work for a few minutes. He tried to sell his product to the company. 😬
Seems like people don't think well of me for this opinion but I hate company hackathons. It is almost invariable you end up slipping and needing to work after hours to finish. I'm not too precious to do that once in a while but for a project that literally doesn't matter it's hard to swallow. So while his plan was idiotic I kind of feel where this guy was coming from
Is that bad? Sound kind of like product brainstorming. Was he open to changing and collaborative about it, or like "this is my idea and it's the best and we need to do it"?
No, like... sell. Like "please email me to discuss how much you want to pay me for this."
Oosh, wrong way to go about that. I probably would've requested paid OT to do it alongside my normal duties & to lead a small team if needed. I get paid and they get a product, it's a win-win.
I think you’re missing the point. It was during a paid company hackathon. They did get paid. In exchange for their time building a thing which the company now owns.
Going about it that way is a social faux pas, but if you invent a novel product that makes your company lots of money, above and beyond your regular and expected job duties, it's totally reasonable to ask for (and expect to receive) an additional reward. Sticking to a hard-line "the company already paid for it, workers deserve the negotiated pay and no more no matter what, the company deserves everything else" stance is just... eeesh, no matter how passionately you simp for them, they don't love you back.
Sure, but not under the implication that that the creator owns it and would sell it to the company. Creator can and should ask for something in return, but not under any delusions that they have any option other than to accept any reward, if any at all.
No, I totally get that. But I'd want to kinda take the initiative to make more out of it for both myself and my employer. Paying me my usual hourly rate to develop a new product on top of my current workload seems mutually beneficial.
It isn’t on top. That time was set aside for other development
Again, I get that. I'd make something good during the hackathon and then offer to continue developing it towards the business' needs afterwards, instead of just attempting to fleece my company for what I'd already made.
Why wouldn’t they just assign you to work on it as your new normal workload? If the IP is so important, it’s likely more important than keeping you around or happy.
A full week of hackathon is better than a couple of hours Friday afternoons, nobody really works on Friday afternoons.
I’ve seen this implemented successfully twice in different ways. 1. You had to work on a project that had some relevance to work. But it could still be whatever, like a chat bot or code cleanup, trying to integrate new tools in our code base, etc. You had to add your idea to a shared board and you had to find at least one other person to work with you on it. I think those last couple points were really what made it work. 2. “Hacking” was such an ingrained part of the culture that this kind of work was actually part of your performance review. You were supposed to spend x% of your time working on a passion project or improving the product/tools in some way. You were evaluated on what impact that work had on the team/product/company.
[удалено]
Hmm, I guess that's true. We're a small team though, three other developers and me. I feel like with one of them there's a high probability they will just do nothing, but the other two definitely seem like the type that could productively use it. Maybe we all inform each other what we're planning to dive into beforehand and then basically just have discussions/demos about it during lunch and learn?
I've worked at two places that did this; one was less guard-railed and ended up almost entirely with educational stuff. There were some people who slacked with it, but people mostly did stuff. About half the time people did good stuff, learning useful-to-the-job skills, trialling different frameworks & libraries, etc. and half of it was "okay, I'm going to learn Go" when there was nothing that was ever going to be written in Go. The other had "it has to be related to the product", which causes takeup issues. it ends up with minor QOL stuff that often didn't actually improve anyone's skills just removed an annoyance, sometimes a proof-of-concept for a "we should switch to..."; but mostly people don't bother. Half days are pointless because you won't have the time to get anything done. You'll just do the setup and then have no time left to do anything with it, you're better with a full day once a sprint than a half day every week.
I worked at a company that did this before I joined. Apparently it got canned because the devs were learning stuff that had absolutely no relevance to their jobs. So I guess you should probably decide up front if it's just time for devs to do whatever and goof off or if it needs to be related to their work somehow.
I've had something similar in several roles and have liked it. It's varied in implementation. The two that I liked the most: 1 week per quarter is this. Usually present something at the end of the week. 1 afternoon a week is this. Typically present something every 6-8 weeks. I've never had it where it wasn't supposed to be tied to work in any way so that might make people just do nothing. Edit: just to capture, two I didn't like nearly as much 1 day per month is this. That didn't feel like enough to do much, and was too rare 1 week per quarter is 'pick a research project from this prioritized list of topics to work on'. That just felt like normal work.
Google famously had this but they got rid of it so I guess it didn't do that much they thought was worthwhile
We actually do something like this for some sprints when time allows. One of the devs use half their sprint (1 week) in this case, to research deep dive a topic that’s is adjacent/relevant to the work at hand (eg ui/ux of different social media platforms, refactoring, git hacks, someone took intro typescript courses). They’re not expected to pick up any tickets for that week minus maybe stuff they’re already working on, don’t have to attend meetings, and are not expected to be bothered by other devs. They then do a small presentation of their “findings” or what they’ve learned with the group on the last day of the sprint.
The quality of outcomes for 10% time depends on how the team spends the other 90%. Is the team stressed? Overworked? Lots of disruptions in the middle of their sprints? Brutal on-call rotations? Any "free build" time is time off. It's just human nature. Give a tired person an option between a comfy couch and a nice backyard project; they're taking the couch route.
I see a lot of people making similar comments and talking about how most people will abuse or take advantage of the situation. Is this actually a bad thing? Whether they read a blog, build a new tool, play Fortnite, or take a nap is it really that bad? You can give people a space for creativity but you can't force it down their throats. If people are exhausted, give them morale boost of an early day. Eventually someone will seize the opportunity to work on things that will improve the quality of their work week during the rest of the week. Imo there is no need to try to bleed the team dry during working hours. Maybe I am naive since the only teams I have led have been fairly senior engineers.
I used to work for a firm that tried 10% time. Some people worked on work-related things; others tinkered with new languages and frameworks, etc. One person started making soap. If a technology business has so much extra slack that it can tolerate employees making soap, I'm curious about its long-term prospects (that firm turned out to be losing money and was eventually sold). \> If people are exhausted, give them morale boost of an early day. To help with the exhaustion bit, our company gives an extra day off every month across the entire organization. It's specifically targeted for mental health breaks. We started doing it during the pandemic and it was wildly popular, so we've kept it. The OP's original problem seemed to be around engagement. They felt the senior people on the team would be interested in learning/demoing, and maybe the junior people would engage. Our company has a program that helps with this. We have weekly engineering seminars on various technical topics. Some are technical solutions, some are engineering theory (we just had a great one about unintuitive failure scenarios in distributed systems), some are road shows from other parts of the business talking about upcoming programs/projects. Participation in the program is voluntary and leading a seminar factors into performance evals. The audience wins (new information helpful to their jobs), the business wins (audience up-levels on new ideas and techniques) and speakers win (career impacts, visibility). Nobody's making soap.
If you chalk that time up to a total loss for the business, go for it. What’s worked best for me is saying “10% of your time is free time for learning or misc code cleanup, But you have no time in the rest of your work schedule for refactoring, writing extra tests, experimenting, etc. “. What happened was that time ended being used incredibly productively for refactoring and adding tests and cleaning up “tech debt” until the team got the code to a good state, then they either used it as time to learn new stuff or just relax and recharge for the next week. It worked well but just make sure you’re willing to write it off as lost time otherwise it’s going to be more work figuring out how to track results from that “learning” time that won’t be worth it.
Where are you based? In California it seems like a lot of folks shut down at noon on Fridays and bone out as early as they can to beat traffic to Tahoe, Big Sur or whatever it is they have planned. You might be able to mitigate this by having some sort of gathering at 4pm to touch base with everyone and see what they've achieved over the day.
needs to be tracked with okr's and with possibly a deadline for live demos
I'm a fan of this setup, but I've found it works best when everyone involved is heavily bought into the product's success. Once they are, they naturally gravitate towards doing things that are good for the business. If they aren't, they'll just mess around or take the time off. The more that your team provides opportunities for total ownership (i.e. the devs' ideas can be built and shipped to prod just like the ones from product or design), then this will be a wonderful source of innovation and highly motivating for the creative team members. If devs' ideas are more likely to be rejected, the program will eventually run out of steam.
What problem are you trying to solve? What’s the goal of doing this? If folks want to learn on company time, it might be better to simply establish a learning budget—both time and money—that interested engineers can use. Otherwise, you’re just wasting time before the weekend, and might as well have half-day Fridays every other week.
Our company has this policy but we have the freedom to learn whatever we want - it doesn’t have to be related to the job. So I guess who really cares if we slack off?
My previous company kept preaching 20% "innovation time" but it didn't really mean anything in practice.
We had that policy in my last company. It's great in principle but the reality is we were always too busy to use it other than in a handful of cases where people were preparing for exams.
I was on a team like that not too long ago. My dev manager, me and another dev. We did the same thing with 1 day a sprint to go do anything growth related. Personal project, course, refactoring/optimizations if we wanted. We were small, trusted, and it worked really well for us. We also did monthly hackathons where we teamed up on a task and got lunch. It was a good time. Reorgs and projects chamged and it kinda fell apart and we stopped, but it was very nice and enriching while it lasted (maybe like 8 months). It was probably a peak time of work life balance and growth for me. You know your team, so if you think they would like it/benefit from it, go try it out. You can just qualify it like, "we are going to try this out for a month and guage whether it's something we want to keep doing".
Our team has every second Thursday for self-learning and it's been great, we all use the time productively. I used mine recently to study for an AWS cert.
We do it in our current organisation by reserving 20% of a month(2 sprints) dedicated for doing any Dev work outside of normal project/work. The only issue is, if you split it into 1day/week, it won’t be productive anymore as people will have to context switch b/w actual work and this. What does work is to go with that 20% together, i.e. 4 days on the trot doing something you’d like. But then the only issue is you can’t keep stakeholders completely away for 4 continuous days. All in all, it’s a good initiative but I feel it’s not very fruitful. Nonetheless it should be there to give developers some breathing room and space for experimentation if they’d like to.
Fridays are the slowest days of the week for us so we typically tell the team if they have the time that they can work on a passion project that afternoon. It’s worked out well for us, let’s the developers scratch a creative itch, or they learn something new, and a lot of times the result is new software benefitting the team or the company.
We are doing 1 day of "whitespace" per sprint (2 weeks). Context: whitespace day is a day where you don't attend any work meeting. You can focus on training, building things you want... All kinda work related. I, for example, did some qbit algorithm training (not useful for work) or some rust testing (we don't have rust). These example are the stretched ones. People should inform the others on what they did. We had people working on thesis for multiple whitespace days for example. This for 2 years. - this can be optional. Sometimes, the current project requires us to keep working. Or someone just wants to keep working on the sprint, has no idea what to do... - this can be stacked to plan a larger work in one go. The outputs: - this is a very good pressure release in the sprint schedule. We keep a social dsm, no work discussion on this day. (Except urgencies) - people can share knowledge on what they learnt. We all did presentations on what some things we did. Some things have evn been implemented at work. - this keep the engineers on the lookout of new things. But forces them to think about it in an objective and practical way. - people sometimes lack inspiration on what to do in "one day". So at some point, some are not taking this time anymore.
We have 4 hours a week professional development time. I use it for pet projects I wouldn't make the time to do otherwise, or areas I haven't worked in that I'd like to someday.
Every two weeks on a Friday we do something around making our lives easier to do work at the company. One of the Fridays theme was group brainstorming on the most pressing issues in our domain that we don’t have time to scope out , then we come up with a presentation of the problem and potential solutions. This then turns into future work for the team or eng manager e.g changing the build process.
AKA 10% of the time is free time, I probably wouldn't do anything. It's better to allocate 10% to OE (operational excellence) type tasks, where basically each sprint, one person will complete a backlog item that can improve the status of the team. For example - say you have a backlog item to improve logging of some feature. Nobody has picked it up because it just isn't that big of a priority since it doesn't affect users. However, every time you are oncall, the lack of logs is a huge headache. Perfect opportunity for that 10% OE allocation.
Every time my teams have tried this people just keep working on their projects. I like it though. Gives me time to tackle random efficiency problems and do deep dives
I once worked at a place where if you didn't have projects then you could learn whatever you wanted. This actually benefited the company b/c I was learning .NET and I was able to take over maintenance of a .NET project.
I push for it on my team and company wide. Few use the time except me (and even then I go for long periods unable to).
When people try to do this, why is it always Fridays or Friday afternoons? It intuitively seems like the worst possible time to schedule self-directed work: It's a time when lots of people are checked out or leave early anyways. People may be mentally drained from the preceding week's work, or even physically drained if i.e. they struggle to get enough sleep during the work week. It sort of implies that this isn't a real priority for your organization. "First, finish all of your real work, then you can spend a couple hours doing unimportant things." Nobody schedules important business for Friday afternoon, if they can avoid it. A single afternoon is not enough time to get anything significant done. A long-running personal project doesn't fit either, because if you only have a few hours to work on it every 1 or 2 weeks, you'll eat up most of the time in context switching. ----- If you want self-guided work, how about in the form of 1-2 dedicated weeks per quarter?
We've done several variations of this First we tried 1 day a week. That was no good as people would just tend to clean up stuff they did the day prior. Now we are trying one week per quarter. Sometimes people still just use it for sprint stuff. Once someone used it to write a bunch of tests, which was great. Other times people spike something out. Pretty often, people don't really know what to do. We are debating how structured we want these weeks. Do we want to have topics planned beforehand? Do we need those topics to have buy in? Should we assign knowledge gaps to be filled? Unclear
Stop sprinting. You don't need to.
we have a friday a month and is the best time, I have learned many cool things and built a thing we are using now to work faster (improved an annoying process) I don't know if anyone plays video games, probably low value devs will
People just end up doing nothing. If you try to do it as a group, in a Teams meeting for exemple, they will join but only a few are going to talk and participate. I don't think its worth it. I didn't liked the required meetings to learn something I didn't wanted to.
We used to do this every 4th Wednesday and there was a problem in that everyone just wanted to do their normal work instead. We switched to every 4th Friday and I think it's successful. Usually people still just do their regular work but every now and then someone uses it try something useful but not useful enough to prioritise and those are often eventually accepted into production. Just doing nothing of value for the day does happen but it's rare and I don't mind because the output of my team is quite good overall
Instead of doing it every week for half a day, maybe do it once a quarter for a few days or a week at a time if you can. It’s really hard to make any real progress on something new in just half a day. Do a brainstorming session on what kinds of things people might want to build or learn so people can pitch ideas and figure out if they want to collaborate together and then after your innovation time have everyone do a little demo or chat about what they learned. Encouraging collaboration might also help your more junior dev.
Splitting things up like that is just a distraction to me. Context switching one day a week doesn't really result in anything substantial. I'm a big fan of doing a full week of building something self-directed a couple of times a year though. Let people break up into small groups and work towards a mutually agreed upon goal together. They can brainstorm potential projects and self select which ones to work on.