4 ms·

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 fro

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.

deleted 5y ago
[deleted]
andyjohnson0 5y ago
The way you describe your role sounds like the way a Technical Fellow is supposed to operate within an organisation.
fleischhauf 5y ago
So you work in some scrum framework with tasks and sprints? I wonder how feasible that is in frameworks like that
- nicoburns 5y ago
  Easy enough in my experience. You just build in time for these projects into your estimates.
  - newswasboring 5y ago
    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)
    - nicoburns 5y ago
      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.
      - lostcolony 5y ago
        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.
    - lostcolony 5y ago
      '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.
- newswasboring 5y ago
  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.
  - papito 5y ago
    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.
    - deleted 5y ago
      [deleted]
- Aeolun 5y ago
  I’m sorry, my task just isn’t done yet, it is much more work than was estimated.
- sumtechguy 5y ago
  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'.
  - aqme28 5y ago
    In my professional experience, scrum often means that 100% of your time is tracked. Should it be that way? No, but it sometimes is.

deleted 5y ago

[deleted]

andyjohnson0 5y ago

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

fleischhauf 5y ago

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

nicoburns 5y ago
Easy enough in my experience. You just build in time for these projects into your estimates.
- newswasboring 5y ago
  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)
  - nicoburns 5y ago
    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.
    - lostcolony 5y ago
      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.
  - lostcolony 5y ago
    '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.
newswasboring 5y ago
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.
- papito 5y ago
  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.
  - deleted 5y ago
    [deleted]
Aeolun 5y ago
I’m sorry, my task just isn’t done yet, it is much more work than was estimated.
sumtechguy 5y ago
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'.
- aqme28 5y ago
  In my professional experience, scrum often means that 100% of your time is tracked. Should it be that way? No, but it sometimes is.