6 ms·

Bob shouldn’t be working at a place where he’s only allowed to work on tasks that are assigned to him by a manager, and twiddle his thumbs when he has none. He

Bob shouldn’t be working at a place where he’s only allowed to work on tasks that are assigned to him by a manager, and twiddle his thumbs when he has none. He should be able to create his own tasks, do some experiments, R&D, self-directed training, open source work, whatever he finds compelling.

faizshah 4y ago
Yea, this is where I like the amazon model of ownership. It’s something like: SDE I - can work on clearly defined components of a project assigned to them SDE II - can work on an ambiguous project with multiple components lead by a technical strategy SDE III - lead influence and define strategy for ambiguous projects across multiple teams This person is operating at an SDE II level but is being managed at an SDE I level...it’s time for a promotion. What’s worse is the manager is micromanaging the engineers. Instead the employee needs to be given more ambiguous project level work that aligns with the team/product strategy where they can define their own tasks. Also the manager should consider falling back from managing at the task level, instead helping facilitate at the project (or “story”) level. The fact that the manager is managing at a task level and is unable to find work for this engineer tells me that the team doesn’t have a strong tech lead who is familiar with the team/product strategy and can help mentor/lead other engineers. In terms of retaining the engineer and making them less insecure about their role, when the manager gives the team member more insight into the team’s strategy and the way that the manager is evaluating their work it helps team members feel more secure in their role. A lot of the anxiety comes from guessing what your manager is thinking and how you are being evaluated and shows a lack of communication between manager and team on strategy, values and performance evaluation. The manager should consider holding weekly 1:1s focusing on these topics.
- closeparen 4y ago
  Absolutely, but this is a particular feature of product-oriented tech companies. Enterprise could maybe work like that but usually doesn't. Consultancy absolutely can't. This is why it's so important to work in Silicon Valley and not just any software development role.
- gfdsgfdsf 4y ago
  >Why you don't promote Bob? >Bob doesn't want to lead or be a manager, pretty sure at amazon or any "big tech" you get fired for this
  - fknorangesite 4y ago
    Isn't this exactly what Staff+ roles are for? Being able to continue getting promoted but staying on an IC track.
  - faizshah 4y ago
    At amazon the engineer track has leadership level roles: SDE I -> SDE II -> SDE III -> Principal Engineer (SDE IV) - you provide technical advisory and strategy across an organization -> Distinguished Engineer/Sr. Principal Engineer etc. (SDE V) Some choose to stay at SDE III level until the end of their career though since it offers the most freedom to code. You absolutely don’t get fired for this. This track exists at Oracle and Google. I am not familiar with the others. There’s a whole book on this: https://staffeng.com/book https://staffeng.com/book
    - gfdsgfdsf 4y ago
      you get fired if you dont make it to IC3 or 4 (depending on company) eventually, and getting promoted to those levels does require leadership. sounds like bob just wants to work on bug fixes forever, there is no path to promotion there.
      - gloryjulio 4y ago
        There are different types ics. You absolute can stay as a type of programmer who concentrate on your own project with 0 people leadership. But you do need tech leadership. You are taking this kind of project because your are technically sufficient and that's your leadership. It doesn't mean it's a solo project. It just means you have the technical direction and you can let ppl manager to handle ppl side of things and you do almost 100% tech side of work. If you have 0 tech leadership and can only work on tasks assigned to you, you are not even ic4 worthy, that's absolutely ic3 ie ng level. Again this is more of a feature in big tech where this kind of projects are available
roflyear 4y ago
You know why these companies don't really exist, right? Because the majority of people just won't work in those environments, and they are also the environments where it is really difficult to keep track of what people are doing.
- itsboring 4y ago
  I’m not sure it has to be one or the other extreme. Plenty of places have the “20% time” where you’re free to work in a self-directed way, learn about new stuff that interests you, etc. Maybe for this hypothetical Bob, that 20% is more like 50%, but it doesn’t mean that everything has to go totally wild west.
  - roflyear 4y ago
    Right, this will probably solve OPs problem for sure.
- SpicyLemonZest 4y ago
  They don't exist on a company-wide basis, but I've seen plenty of companies where engineers who are capable of setting their own tasks are allowed to do so. (As a sibling comment points out, this is very common in the stereotypical big tech companies, and in fact your promotions are typically based on the scope of things you can get done on your own initiative.)
- sbf501 4y ago
  30+ years in software engineering, ~20 in management, and I've never had difficulty keeping track of what people are doing. Can you elaborate your experience of environments where this isn't possible? It sounds like just the clusterf*ck companies?
  - roflyear 4y ago
    I work in fintech, my experience is if you're operating this way you'll have an even harder time to get recognized.
Test0129 4y ago
The counterpoint to this is if you aren't specifically assigned tasks you're basically expected to go through the backlog to hunt for things to do. In most companies the backlog is never empty and so you don't really get any time for any of these ancillary tasks. This is part of the reason performance optimizations and other improvements never get done. PMs are encouraged to stuff backlogs full of nonsense related to new features because that's what the people up top want to see. When the reality is, allowing your engineers even 8 hours of unstructured time a week will often produce better work. The exception to this rule of course tends to be the top of the ladder (senior principal, whatever) who generally get to do whatever they want as long as it's company related. 99.99% of engineers will never reach this point, however, and so the vast majority of these high performers are subject to the tyranny of JIRA and it's subsequent negatives.
- ryandrake 4y ago
  > The counterpoint to this is if you aren't specifically assigned tasks you're basically expected to go through the backlog to hunt for things to do. In most companies the backlog is never empty and so you don't really get any time for any of these ancillary tasks. Yea, instead of thumb twiddling, just go fix some bugs! Every company I've ever worked at had 1. more bugs than could ever be fixed and 2. had an incoming bug rate faster than the team's fix rate, therefore the bug count perpetually grew. Some of these could be long standing bugs that annoy actual users that just perpetually get ignored by the company. Go fix one and make someone's day. There is no such thing as a Software Engineer with nothing to do. When I read HN comments from software engineers who say things like "yawn, my work fits into about 6 hours a week, and the remaining 34 hours I just take it easy, maybe work on a side project, maybe horse around on Facebook..." my mind boggles! Where do you work where there are no bugs in the backlog to fix?? If there are really no bugs to fix, maybe look into cleaning up the code base. Turn a few compiler warnings on or run the static analyzer and go looking for trouble. Re-factor that gnarly part of the code that's always tripped up new employees. Add unit tests. Add integration tests. Automate some part of the build. Maybe work on a nicer bug dashboard.
  - stackbutterflow 4y ago

faizshah 4y ago

Yea, this is where I like the amazon model of ownership. It’s something like: SDE I - can work on clearly defined components of a project assigned to them SDE II - can work on an ambiguous project with multiple components lead by a technical strategy SDE III - lead influence and define strategy for ambiguous projects across multiple teams This person is operating at an SDE II level but is being managed at an SDE I level...it’s time for a promotion. What’s worse is the manager is micromanaging the engineers. Instead the employee needs to be given more ambiguous project level work that aligns with the team/product strategy where they can define their own tasks. Also the manager should consider falling back from managing at the task level, instead helping facilitate at the project (or “story”) level. The fact that the manager is managing at a task level and is unable to find work for this engineer tells me that the team doesn’t have a strong tech lead who is familiar with the team/product strategy and can help mentor/lead other engineers. In terms of retaining the engineer and making them less insecure about their role, when the manager gives the team member more insight into the team’s strategy and the way that the manager is evaluating their work it helps team members feel more secure in their role. A lot of the anxiety comes from guessing what your manager is thinking and how you are being evaluated and shows a lack of communication between manager and team on strategy, values and performance evaluation. The manager should consider holding weekly 1:1s focusing on these topics.

closeparen 4y ago
Absolutely, but this is a particular feature of product-oriented tech companies. Enterprise could maybe work like that but usually doesn't. Consultancy absolutely can't. This is why it's so important to work in Silicon Valley and not just any software development role.
gfdsgfdsf 4y ago
>Why you don't promote Bob? >Bob doesn't want to lead or be a manager, pretty sure at amazon or any "big tech" you get fired for this
- fknorangesite 4y ago
  Isn't this exactly what Staff+ roles are for? Being able to continue getting promoted but staying on an IC track.
- faizshah 4y ago
  At amazon the engineer track has leadership level roles: SDE I -> SDE II -> SDE III -> Principal Engineer (SDE IV) - you provide technical advisory and strategy across an organization -> Distinguished Engineer/Sr. Principal Engineer etc. (SDE V) Some choose to stay at SDE III level until the end of their career though since it offers the most freedom to code. You absolutely don’t get fired for this. This track exists at Oracle and Google. I am not familiar with the others. There’s a whole book on this: https://staffeng.com/book https://staffeng.com/book
  - gfdsgfdsf 4y ago
    you get fired if you dont make it to IC3 or 4 (depending on company) eventually, and getting promoted to those levels does require leadership. sounds like bob just wants to work on bug fixes forever, there is no path to promotion there.
    - gloryjulio 4y ago
      There are different types ics. You absolute can stay as a type of programmer who concentrate on your own project with 0 people leadership. But you do need tech leadership. You are taking this kind of project because your are technically sufficient and that's your leadership. It doesn't mean it's a solo project. It just means you have the technical direction and you can let ppl manager to handle ppl side of things and you do almost 100% tech side of work. If you have 0 tech leadership and can only work on tasks assigned to you, you are not even ic4 worthy, that's absolutely ic3 ie ng level. Again this is more of a feature in big tech where this kind of projects are available

roflyear 4y ago

You know why these companies don't really exist, right? Because the majority of people just won't work in those environments, and they are also the environments where it is really difficult to keep track of what people are doing.

itsboring 4y ago
I’m not sure it has to be one or the other extreme. Plenty of places have the “20% time” where you’re free to work in a self-directed way, learn about new stuff that interests you, etc. Maybe for this hypothetical Bob, that 20% is more like 50%, but it doesn’t mean that everything has to go totally wild west.
- roflyear 4y ago
  Right, this will probably solve OPs problem for sure.
SpicyLemonZest 4y ago
They don't exist on a company-wide basis, but I've seen plenty of companies where engineers who are capable of setting their own tasks are allowed to do so. (As a sibling comment points out, this is very common in the stereotypical big tech companies, and in fact your promotions are typically based on the scope of things you can get done on your own initiative.)
sbf501 4y ago
30+ years in software engineering, ~20 in management, and I've never had difficulty keeping track of what people are doing. Can you elaborate your experience of environments where this isn't possible? It sounds like just the clusterf*ck companies?
- roflyear 4y ago
  I work in fintech, my experience is if you're operating this way you'll have an even harder time to get recognized.

Test0129 4y ago

The counterpoint to this is if you aren't specifically assigned tasks you're basically expected to go through the backlog to hunt for things to do. In most companies the backlog is never empty and so you don't really get any time for any of these ancillary tasks. This is part of the reason performance optimizations and other improvements never get done. PMs are encouraged to stuff backlogs full of nonsense related to new features because that's what the people up top want to see. When the reality is, allowing your engineers even 8 hours of unstructured time a week will often produce better work. The exception to this rule of course tends to be the top of the ladder (senior principal, whatever) who generally get to do whatever they want as long as it's company related. 99.99% of engineers will never reach this point, however, and so the vast majority of these high performers are subject to the tyranny of JIRA and it's subsequent negatives.

ryandrake 4y ago
> The counterpoint to this is if you aren't specifically assigned tasks you're basically expected to go through the backlog to hunt for things to do. In most companies the backlog is never empty and so you don't really get any time for any of these ancillary tasks. Yea, instead of thumb twiddling, just go fix some bugs! Every company I've ever worked at had 1. more bugs than could ever be fixed and 2. had an incoming bug rate faster than the team's fix rate, therefore the bug count perpetually grew. Some of these could be long standing bugs that annoy actual users that just perpetually get ignored by the company. Go fix one and make someone's day. There is no such thing as a Software Engineer with nothing to do. When I read HN comments from software engineers who say things like "yawn, my work fits into about 6 hours a week, and the remaining 34 hours I just take it easy, maybe work on a side project, maybe horse around on Facebook..." my mind boggles! Where do you work where there are no bugs in the backlog to fix?? If there are really no bugs to fix, maybe look into cleaning up the code base. Turn a few compiler warnings on or run the static analyzer and go looking for trouble. Re-factor that gnarly part of the code that's always tripped up new employees. Add unit tests. Add integration tests. Automate some part of the build. Maybe work on a nicer bug dashboard.
- stackbutterflow 4y ago