Comment by georgeburdell | Hacker News Reader

Comment by georgeburdell | Hacker News Reader

I'm by no means a prominent employee within the company, but I am unusually well-remunerated for my role. I attribute this to hiding about 1/3 of what I do from my manager until it's ready to demonstrate.

I usually have 1-2 projects my manager knows about and is regularly tracking, then 2-3 "skunkworks" projects in various stages of development that get prioritized based on the word around the org. For example, I might hear from our data center team at a regular meeting that they need to buy 5% more racks based on current usage projections. I might have been working on optimizing a key data saving routine that reduces usage by 10% (fictitious numbers), so this gets bumped up in priority. So when my manager asks the team the following week if they have any ideas on how to improve our code, I've already got something halfway working. My manager (and I) get to look good, and I got to amortize the work across a few months instead of suffering through crunch time.

The way you describe your role sounds like the way a Technical Fellow is supposed to operate within an organisation.

So you work in some scrum framework with tasks and sprints? I wonder how feasible that is in frameworks like that

Easy enough in my experience. You just build in time for these projects into your estimates.

Isn't that cheating the system though? Giving an inflated time estimate is lying to your team. While this gets the job done, I don't think it should be encouraged.

(Just a disclaimer, I do it too)

I guess I just see it as part of doing my job. I wouldn't be able to do it effectively if I didn't do this.

I don't think it's ever been secret in companies that I work for that devs don't spend 100% of their time on assigned tasks. There are always extra things like customer support, ops, urgent requests, unexpected refactoring that come up and have to be dealt with. Project managers I've worked with have mostly cared about the estimate being as accurate as possible taking into account these overheads.

The places I've worked that required time estimates (the wrong way to do it) still built in an overhead factor of ~30-40%. I.e., recognized that a dev would only put in 4-5 hours of 'coding' a day, with the rest taken up by meetings and random miscellany.

'An inflated time estimate' - well there's your problem. If it's a point estimate, as it should be, it's quite easy to do. Your 'real' velocity may be 10 points, but your planned velocity is 7. That not only gives you a little buffer in the event of something unexpected (so you're less likely to miss a sprint commitment due to things your team controls), but in the event nothing takes that time, it's free time to work on what feels important.

The only way I've found innovation happening in scrum is by cheating the system. Either by inflating time estimates or attaching your idea to something which is just a by product.

Right, but the ultimate goal is to help the company succeed and save it from itself and its management, which is just ass-backwards.

At some point I stopped bothering. I can't worry about the company more than the company worries about itself. I think that's fair.

I’m sorry, my task just isn’t done yet, it is much more work than was estimated.

Scrum does not mean 100% of your time is tracked. You usually have some % of time dedicated to your tasks. I usually pick 70% as that works pretty good for me. It allows for '30% other' to get in there and not having to track every detail. If something becomes big enough I bring it to the team and say 'hey I would like some dedicated time to work on this lets add a story to the board'.

In my professional experience, scrum often means that 100% of your time is tracked.

Should it be that way? No, but it sometimes is.

Reply on news.ycombinator.com