So, if I'm understanding you correctly, you think the way to advance your career is to spend 20% of your time working on unsanctioned side projects in work time, writing code that will be owned by your employer that you can't publish legally without permission, all the while taking longer to do your assigned tasks and looking like you slack off for a day a week? And you think that if that gets you fired you'll move up your career ladder? Would you seriously hire someone who'd done that?
I wouldn't do that. I'd take some of my spare time, a few weekends, to document the idea and maybe hack together a prototype, and take that to "the right people". If they're going to be happy with the project then it's better to do it without pissing off everyone else.
I agree with GP. Can't really answer the hiring question (because I am not interested in being anyone's boss), but why not? Do you think that the way to advance your career is always do what you're being told? GP's suggestion, at least, makes life a lot more interesting.. And people willing to take risks and make their own projects typically will have better CVs.
I would rather see somebody genuinely advance in the organization by genuinely improving something (and taking some risk), while taking time from a stupid project, rather than by taking credit for work of someone else (but that never happens, right?). And in fact it's the latter people who get angry, so for that really doesn't matter on whose time you do it.
As for your suggestion, why is it OK for employer to steal employee's free time and not OK for employee to steal employer's time? We are talking about improvement to the employer's business, after all.
I would rather see somebody genuinely advance in the organization by genuinely improving something (and taking some risk), while taking time from a stupid project, rather than by taking credit for work of someone else (but that never happens, right?).
What you don't seem to realise is that there are no stupid projects. Someone in the business believes that the "stupid project" is a good idea that's worthwhile paying a developer to work on, and they've persuaded the people higher up that this is the case. If you just decide that it's not worth your time and something else is more important then you're effectively telling everyone who has agreed to let the "stupid project" go ahead that they're all wrong and you know best. That is not the best way to further your career.
Open a dialogue. Provide evidence. Don't just say "I know best!" and forge ahead while ignoring everyone else's input. If you're right then people will listen.
I have at times needed to keep projects "secret" because I knew that there would be a 95% chance that the idea would be shot down immediately in any meeting due to being infeasible, politically/personally tricky in some way, difficult to explain, and so on. So I have worked on these ideas sometimes at off hours, or while also making progress on other tasks. Thus far, these skunkworks have been very successful. There is an element to it in many things I do... I often prefer a bit of vagueness around what I am actually doing, since it gives me more freedom to consider solutions that might not be in line with what everybody would expect. Which sometimes makes me wonder if I am being a "cowboy coder" or something. Some of it is due to my skills of persuasion and communication—if I were better at that, maybe I wouldn't need secrecy. But I also just know that some good ideas will not fly in a group meeting before a prototype exists. Then my duty and passion for the product and company override my duty to clear everything with the whole team, I feel. It's not an easy question.
It seems akin to saying there are no stupid moves in chess. Because every move is vetted by the player, and he has a good reason to do it. Unfortunately, people do make mistakes and at least, better moves - than the ones you decided to do - happen.
> you're effectively telling everyone who has agreed to let the "stupid project" go ahead that they're all wrong and you know best
But sometimes you do know best. I didn't say you have to drop work on the stupid project entirely, I just think you should be entitled to be part of the decision too.
Speaking about that, what is the theoretical ideal of how the hierarchical decision-making should look like? I mean, when someone decides things on higher level, how can they do that? If they were to made optimal decision, they need all the information that individual decision makers under them have. So isn't the decision they made always suboptimal? Isn't actually the best way how to make decision in a hierarchy at all to let all the deciders on a lower level decide what decisions have to be made on the upper level?
There should be a mathematical model supporting how hierarchical decision making works, but I have never seen one.
> That is not the best way to further your career
If you do what I suggested, you're taking a risk. It may give you a good result or a bad one, as it happens.
> No one ever succeeds on their own
Even if that is true, which isn't, you can still at least spark a success on your own.
If you can't find 20% of your wasted time in your normal day-to-day work to direct to something more useful, then you are in the 1% most productive office workers.
Or you need to invest in automating some of your grunt work, so you can do the same work in less time. Laziness is a virtue.
> all the while taking longer to do your assigned tasks and looking like you slack off for a day a week?
The difference between a hirable employee and a fireable employee is not 20%. There is usually 2x or more of variation amongst people in a pay grade. As long as you're in that ballpark of productivity, you're fine. Personality conflicts will get you fired long before a 20% dip in stories checked in.
In fact, there's a good chance that taking the 20% of time off will actually increase your productivity the rest of the week. But if it drops you below the "worth their weight in pays stubs" line then you are already on very thin ice.
Wrong focus. Unplanned, but valuable and necessary side projects, that focus on the long term, setting aside for a moment that permanent focus on the short term next milestone next sprint next story next task next function next line of code cyclic trap of short term focus - that product managers (along with literally everyone else, myself included) fall all too easily into.
If my employer doesn't trust me to have some sense of what constitutes valuable and necessary, why the hell did they hire me in the first place? And why do I want to work there? And how soon will I be laid off, fired, or quit of my own accord - leaving for greener pastures where there's higher morale, and less micromanagement? These things will translate directly into better productivity, in turn translating into moving up the career ladder faster?
(I should note: I pick jobs where I consider my "20%" projects to be business relevant. That doesn't mean they're sanctioned.)
> I'd take some of my spare time
1) I can't focus on proper work projects outside of work. I've tried it. Even if I could, reducing my weekends to 1 day a week sounds like a great way to burn out. If somehow I don't burn out, bluring the line between work and play enough for the last day of the weekend I kept for myself to never quite feel like I've left work at work.
2) Prototyping is insufficient.
3) What spare time?
> writing code that will be owned by your employer
That's a feature. Do you have a copyright assignment clause in your contract for all your home projects? Is it legally enforceable in your jurisdiction? Nebulous. Here's the deal: I work on things at work, they get to own it - clearly and unambiguously. Best case scenario? I get recognition, praise, raises, bonuses, promotions, and they ask me to work on it even more. Worst case scenario? I'm off on an adventure, in search of employers that better value my talents. Win/win situation.
> all the while taking longer to do your assigned tasks and looking like you slack off for a day a week?
If it looks like you're slacking off, you're doing 20% time wrong. I have no games open, no social media, no reddit, no HN - my 20% time is sit down and write some code time. You'll hear my keyboard, and you'll see code if you look at my screen. In the lulls, you'll see me thinking hard, unaware of the world around me.
Even if I made it as regular as one specific day a week (I don't - it's hours here and there, fit in and around the normal ebb and flow of my daily work) I'd wager that fluctuation in stats-measured productivity would still get drowned out by the standard deviation of noise in normal work. Some days I commit 10, 20 things with relative ease - other times a single obscure bug wastes 2 weeks of my life to track down - and you're worried about a day a week?
> If they're going to be happy with the project then it's better to do it without pissing off everyone else.
Here's the thing: 20% time (possibly rogue, possibly unsanctioned) is how you pull this off. Which is easier to plan project schedules around: Consistent 80% time spent per week on the project, or sometimes 100% and sometimes 0%? Which sells better:
A) "I want to add an unplanned week to the project schedule so we can replace some terrible tools that we've been limping around with. No, it's not a customer requirement, why do you ask?"
Or:
B) "By the way, I wrote a spiffy new tool that replaces that old terrible one. We can now get those customer requirements that require the tool done faster. You're welcome!" (Unmentioned: You implemented it in about a week, amortized over the previous month or so.)
I wouldn't do that. I'd take some of my spare time, a few weekends, to document the idea and maybe hack together a prototype, and take that to "the right people". If they're going to be happy with the project then it's better to do it without pissing off everyone else.