Side projectsSun 07 October 2018
Over the past couple months I've been declaring all of my side projects to my current employer. It's been a very interesting experience, because, strictly speaking, I don't work for them as an engineer.
Joel Spolsky has written an interesting note about side projects. His main thesis is that, from a legal perspective, employers have to try to own all inventions by engineers, to protect themselves when they seek future liquidity (say, in an IPO or major investment round). Folks in management or strategy roles don't usually sign such agreements because they aren't seen as creators of company intellectual property, and I didn't.
So why ask permission? Mainly because I want a nice document in writing saying that they're okay with me working on the side, and exactly what criteria I have to abide by in order to continue doing so (I can't hire colleagues to work with me, for instance). I would not even consider using such a document in court - even when I'm legally in the clear, my ability to prevail against a large company is effectively nil. It's mostly because, so long as the executives who I checked in with remain at the company, it'll be clear that the decision to let me do this was on them. If something changes, say one of my projects becomes dramatically successful and they would like a percentage...the same executives would have to judge themselves as bad decision makers. In my experience this never happens, especially when the decision is in writing.
There's a few things I noticed when building this. First of all, as a diligent reader of this blog might also have observed, I wrote a lot more. There's something about being in the process of doing something that unlocks creativity in other realms. I'd like to explore this more in a future essay.
Second of all, my day job was affected, but not in the way you'd think. In terms of raw output, I was more productive. In some ways I suffer from a form of perfectionism; if I'm not sure the outcome is going to be good, I'd rather procrastinate on delivering the outcome at all. 99% of the time this is a bad thing - executing is usually the best way to get something to perfection, rather than just thinking about it. Because I had limited time each day to work on my side project, I would move as fast as possible to go from idea to working code. And somehow, since I was in that mode, I would stay in that mode at my actual job - I delegated faster to members of my team, and for the items I was individually responsible for, I got it done, fast.
So maybe this side project gig has positive externalities outside of its intrinsic value. That would be nice, since I have no idea at all if it even has intrinsic value - I've built a working v0 and found that unsurprisingly, no one cares about it yet.