As an engineer, my view on days/hackathons is pretty simple: 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. Instead, I'm going to do whatever I can to try something new and different to learn
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!
As an experienced and seasoned engineer, this is exactly my view. Though as a new college grad I used to work overnight for hackdays. Now I see new college grads doing the same.
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.
Whilst I agree that these hack days should be considered a learning experience this sentiment has annoyed me:
> 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.
He sounds plenty motivated. He's willing to start his own business to chase a $5 million dollar idea.
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 good ideas are exactly what the company is paying you for.
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.
“ You are paid to create value for your company that far exceeds your salary”
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.
> As an engineer, my view on days/hackathons is pretty simple: you don't pay me enough for my good ideas.
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.
> If I had an idea that could make the business $5M, I'm better off going into business for myself.
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.
> 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.
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.
Yes, I'm all about the experimentation. I feel like often times during work, we don't have time to pop our heads up and look around at tools and processes that might help us do our jobs better or with less toil.
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.
Absolutely. So many times we fall into a rut of using our familiar tools that we don't realize that sometimes there are new innovations that can make our lives easier. Or, at the very least, automations we can put into place to make our lives easier!
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!
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!