To do a hackdays successfully, I find good projects have already had a lot of personal upfront investment before the hackdays project. The hackdays project then assembles a team of potential labor that might (or often not) accelerate the idea to a demo. And then, even if there's a snazzy demo, you have to engage in a tremendous push after the hackdays to turn them into successful projects.
I can just as easily spend my time doing this in normal planning channels. And instead of hackdays, maybe we should encourage prototyping and demos to be part of the normal planning process, not some out of band activity likely to screw up schedules and deliver nothing.
Please, companies, stop these mandatory corporate fundays. And just fix your normal planning processes.
So with that in mind, as a leader, I view them as opportunities for sanctioned on-the-job learning. I would hope that you spend the time automating existing processes or learning a new technology that might be useful. At our most recent company hackathon, we focused on a new way to do the old thing. Everyone could build basically whatever they wanted, but they had to use the new tool to do it. Not because we want the output, but because we want everyone to feel comfortable with the new tool. There was zero expectation about turning anything into a production project, although we did have two projects come out of it that are likely to go to prod soon without disrupting the roadmap.
I get where you're coming from, and I agree wholeheartedly with your assessment. If your work is doing hack days, and then getting mad because features aren't shipped, that's pretty shitty of them. Might want to try and find another place with better culture -- easier said than done!
I get paid for a job and I do it really well. But, I don't get paid enough to overthink creative ideas, burn midnight oil to meet an arbitrary submission deadline that only benefits the company.
Not to mention that if I don't meet my OKRs, mentioning that it's delayed because I was working on a hackday idea wouldn't help me at all.
> you don't pay me enough for my good ideas. If I had an idea that could make the business $5M, I'm better off going into business for myself.
In a knowledge based role, your good ideas are exactly what the company is paying you for. If you have an idea that could make the company $5M it is very unlikely that it would do so sustainably and profitably in isolation as a new company. This is why companies exist, to pool efforts. I work for a company that has billions in turnover and I'm directly involved in decisions that affect our profit or market share and making decisions to save or create millions is a normal part of my job.
You are paid to create value for your company that far exceeds your salary. Maybe this doesn't apply to you but this attitude annoys me because I've had experience of working with colleagues who are unmotivated and coast along doing the bare minimum then complain that they are bored or never promoted. Often their colleagues end up picking up the slack. I understand that many people don't want to exert any energy in return for their paycheck but personally I spend about 6 hours a day working and prefer to put some effort in so that I enjoy it more. If you are unmotivated & unrewarded financially or intellectually then perhaps find a new job.
In a knowledge based role, the company is paying you to churn out solutions to their problems because the technology stack is setup to serve the CTO's purposes.
He has to start a new company to change the setup.
Your annoyance sounds like sour grapes.
Yes, in a limited domain, this is true. However, my employer does not own my brain. Any idea I have that isn't directly related to whatever projects my employer is paying me to be part of are mine, not my employer's. Particularly if they are potentially valuable.
Most people have very little insight as to how much value beyond their salary they create so we can assume there is a base level of value created factored in for doing the bare minimum. In many cases that’s just keeping the business going. If the company wants innovation from the rank and file then they should be willing to pay for that.
and
>> I spend about 6 hours a day working
Which company is this?
That depends on how you interpret hack days.
A lot of great hack day projects I've seen aren't introducing a new product line, they're "what if we used this new framework, what's possible?" "What if we used transformers to replace our convolutional neural network" etc. - things that aren't a new product, but have a shot at improving the development flow/end user experience by 20+%, but are speculative enough that are hard to get scheduled in normal flow of development.
> At our most recent company hackathon, we focused on a new way to do the old thing. A lot of what great hackathons are.
Most hackathon projects are not something you'd be able to start a company around, if they are, maybe you're doing it wrong and overindexing on demos to PMs rather than potential company impact.
One of the most naive things I have read today. Ideas are cheap. If you were capable of just "having an idea" and turning it into any considerable amount of money you would have done it already. Let's face it, most "software engineers" aren't anything special. We aren't founders. We aren't innovators. We are just glorified bluecollar workers slinging code.
However we are the closest to the product, we should know (or at least be able to imagine) lacking features and thus hackathons are a good way to try to tease out potential future paths plus it gives your average coder a chance to explore new technologies or just try different shit.
What if I told you that I've done exactly this and very successfully? :)
The second half of your comment is in agreement with the spirit of mine, though. Hackathons are for giving your average coder a chance to explore new tech, try different shit, and basically have a safe space to do something without being penalized for failure.
I always tell folks at any hackdays I coordinate: talking about a tool you thought might be used, explored and learned wasn't a fit is just as much a win as a cool demo.
At our most recent hackathon, for example, we automated about 80% of project setup. Whereas it used to take 4-6 hours to set up a new project, we got it down to about 30 minutes, and we have a clear line of sight to a 5 minute set up process. It's quite nice!
Going into the hackathon, however, people were like "Ugh, this is too much work to set up a project! Why should we bother?!" rather than thinking "Hey, this is an opportunity to make setting up a project much easier."
So yes, agree completely. Thanks for your insights!
If hack days are used to prototype work that's definitely going to be done anyway, that's a planning problem. (You'll have to figure that out with your company.)
If people are investing work upfront just to make a good impression at hack day, that's a cultural problem. (You'll have to figure that out with your company.)
But generally, just relax and do something creative and fun and low-pressure.
Instead it just piles up "hack days" on top of those
Another possibility is that the company is capable of solving problems. It identifies a problem, creates a plan, and comes up with a solution. OP feels good in such a process.
Maybe the company is solving the wrong problems and is using hack days to surface novel problems it has not identified before. Maybe the company did not explain the value of the hack day in a way that someone who enjoys working in a structured way will not see it as a waste of time.
A couple of hackday projects were proof-of-concepts that eventually made it to prod, in a very organic way. Other teams would learn what was done and adapt it for their needs. They do sort of play out like R&D playtime. I was so lucky to have started my career at companies that actually did software Research as well as Development.
Often it'll be a case of "hey this table is actually searchable now" or "that page is now split into two" or "I removed a tonne of deprecated code"
It's actually really enjoyable in my company, we all like it. My only issue is that I rely on structure, and given "free-reigns" I tend to pick too big of a thing that I can't get done in a day or two, and I end up doing too much = nothing at all.
I usually use it as a "level up" day (which we also have, so I get 2) which is just a day to go learn something new and level up your skills as a developer.
I think the issue isn't so much the "hack day" but rather your company is trying to get more golden eggs out of it, rather than looking after the goose.
Ah, how does that gel with regression testing? We've tried something similar but got swamped by the need to test those code changes and the testers got upset being lumped with additional work while the rest of the team got to play with whatever they liked. Did you forgo testing for the sake of morale or did you come up with another solution?
So each code change needs to be kinda demonstrated that it works, whether it's through new tests, or screenshots, video, etc.
Usually if there's a specific bug that's been fixed, there is a test to catch if that bug occurs again. Most of the time it's been good enough.
I thought hackathons were dumb in college (most people just cheat and bring pre-baked projects) and it's still dumb after that.
If you want to get out of it, just send an email explaining your health and productivity is implicitly tied to your sleep. Worst case just do what I did and get a doctor's note that staying up too late for non-work essential tasks is damaging to your physical well-being.
And the next day was presentation of your achievements.
And the day after back to normal.
First day, I "hackathoned" from 9 to 5 and went home. I didn't win...
The best speed/quality ration of features came from hackdays for us because we actually cared about what we were implementing.
When I was working full time, my idea of "hack days" changed quite a bit. I took it as time to work on the weird idea in the back of my mind. My demo's were not impressive by any means but I learnt quite a bit out of it. I also think its part of the team dynamics, some teams embrace hack days while others do not. Think if the tech lead of a team actively encourages hack days the vibes would be completely different say compared to just doing your day job and planned activities.
At my old company, people would often go and work on projects that were somehow meaningful to the business. It's no wonder people like that didn't enjoy it. Go work on a VR first person shooter game based on your company's mascot; that's what's gonna get the votes!
We feature-flagged this buggy implementation and turned it on for our internal accounts that we used for dogfooding. It was an instant hit. We fast-tracked emoji support, made the implementation stable enough to put in front of customers, and released it.
The good news is that it was well received and used extensively.
The bad news is that emoji support has surprising edge case issues (not talking UTF8 and display) and we've carried that burden ever since :).
if you include the hackday as a day that counts towards velocity, then you will fall behind. because that’s hackday. if your scrum master is doing this, call them out on the dishonesty. make it their problem. let them complain about the velocity hit, and you have some hacky fun.
ultimately you have to make the call - are you too fed up to collect that paycheck? or are you comfortable leaning into the insanity for a buck?
Re: rushing things to prod, that's what feature flags are for!
If you hate hack days that much, interview and find someplace to work that doesn’t do them. Or help your company “just fix” their normal planning process. Or take PTO on hack days.
You’ve got plenty of options. The idea that the company has to change to make you happy is the wrong way of looking at it.
Specifically instead of running hackathons just give a team a very open ended business problem and ask them to investigate how they can use tech to improve or solve the problem. Give the team a month for an initial investigation and if they come up with something interesting provide them time to develop a POC.
Hackathons in my experience just end up with people rushing into mostly useless POCs because they neither have adequate time to investigate a problem or the time to actually build something interesting. You'll generally just get devs building things that already exist with whatever the new hot tech stack is at the time.
I'll also add that corporates generally do these things because a management consultant like McKinsey told them it's a good idea. It's the same reason why agile is so poorly implemented in corporations because they have no real care or understanding of it, they're just implementing the guidance given to them to the letter.
I've started several successful businesses based on an idea that I conceived and built (to MVP) in a single day. I actually consider that one of the keys to my success.
You can sit down and plan out a route along the map. That will work. You'll find a way to get there. It will feel safe and controlled.
You can also wander, drop into an alley, and potentially find a shortcut through a park. That path was not on your map, so you would not have found it had you followed your map. Along the way, you might discover something that will make your trip memorable and unique.
Many companies follow a planned approach to feature development. The draw up a map, and then follow it. A hack day allows people to wander around the idea space and solution space unencumbered. Sometimes, a hack day brings forward a shortcut, a novel idea, or shows off a piece of functionality which would not see the light of day with the traditional approach. Often, it's a matter of catching someone's attention by showing them a good idea™ in action. Companies are sometimes in a rut, and a hack day creates a chance for new things to surface.
Are hack days fun? For some people, sure. For others, no. Do they serve a business purpose? Absolutely. It isn't all fun and games, even if it feels like it.
I have personally seen "hack days" accelerate concrete and valuable functionality.
