5 ms·

I suppose it varies a lot from one organization and industry to another. My experience is that managers don't like it when people rock the boat, they prefer the

I suppose it varies a lot from one organization and industry to another. My experience is that managers don't like it when people rock the boat, they prefer their subordinates to just quietly execute the tasks given to them. Growth-oriented people like myself are sometimes seen as a problem because they cause things to happen that are not in the road map. In my field (fin tech) managers often do not have the background to be able to assess the value of spontaneous technical contributions. So they assume that if something was not planned and requested by management it did not need to be solved.

gabereiser 3y ago
The problem is they can’t justify your cost if you go outside the planned work load. They could probably still quantify it but it’s difficult to assess your impact when your effort doesn’t count towards velocity and delivery of business outcomes. If you work does impact those things, it should be a ticket/story/task so that the impact of work can be measured (seen…). I would suggest, in the future, adding these things to the backlog as you come up with them and bring them up during planning.
- brennvin 3y ago
  > The problem is they can’t justify your cost if you go outside the planned work load Cost? It's a freebie. I'm still doing my tasks, in addition to saving them tons of money with better tools.
- ResearchCode 3y ago
  The measure is called an accepted pull request. You don't need a ticket to submit a patch to the Linux kernel. If you're in a dysfunctional agile micro-management environment with "stories" and "backlogs" then look for a real job.
Aurornis 3y ago
> Growth-oriented people like myself are sometimes seen as a problem because they cause things to happen that are not in the road map. Creating new work that wasn’t in the roadmap (excluding tech debt and other necessities to get roadmap work done) is a problem. The right way to grow is to learn how to work with the company to get important work into the roadmap. I’ve worked with some peers who had good ideas and good intentions, but they’d unintentionally try to blow up the roadmap and reset planning by prioritizing their work over the things we needed to get done. Working with the business to get things prioritized is a necessary skill. A lot of engineers just want to work on whatever they want to work on most, but that’s a problem in the context of an organization trying to coordinate.
- brennvin 3y ago
  > Creating new work I am not talking about creating additional work, I am talking about solving problems not on management's radar screen. Some problems are only visible from the floor. > The right way to grow is to learn how to work with the company to get important work into the roadmap. That is not always possible because valuable things sometimes have to be demonstrated to be understood. Not all things can be explained in the abstract, sometimes you have to build the thing first before people understand how useful it is.
  - natpalmer1776 3y ago
    I agree with this sentiment. A good (software) engineer needs to have the discernment to know when to ask for permission, and when to ask for forgiveness.
    - bombolo 3y ago
      Sounds to me like you're getting micromanaged.
      - natpalmer1776 3y ago
        I fail to understand how you manage to extrapolate my working conditions from a generalization of what soft skills are required to be a good engineer.
    - tremon 3y ago
      A software engineer only needs to make those judgement calls in a bad environment. In a good environment, such situations can be discussed in the open.
      - geodel 3y ago
        Well if in 80% of enterprises engineers do not talk in open that good vs bad environment hardly matters.
- 3y ago
sndjdn 3y ago
[flagged]
- brennvin 3y ago
  > but it’s one you made up. You just made a bunch of things up.
hallarempt 3y ago
"managers" -- if there are managers on top of the maintainers, then, yes, it won't work.
gloryjulio 3y ago
You need to discuss with ur manager about the priority of the tasks. This also help u with the bookeekping. When things break u can say that u have already had this discussion and it was not ur responsibility to fix it at the time
w10-1 3y ago
> My experience is that managers don't like it when people rock the boat That's what's missing from Graydon's analysis: risk-aversion is also a strong incentive in many corporations. I would argue it's the rule for middle managers, with growth being the exception. Also missing is telemetry and coordination, where companies use FOSS to find out what other companies are doing, or to coordinate policy, esp. when they fund a leading contributor from whom other companies need buy-in. Put another way, a FOSS contributor is not an individual, they are a company representative, and their opinion has the weight proportional to the companies' influence. The contributor's influence also depends on the composition of the other contributors. Alternate influences become impossible when a company dominates the contributors; hence e.g., the CNCF tracks metrics for ensuring that it takes a plurality to dominate. But really this posting isn't about FOSS contribution at all; it's about the under-valuation of avoided future costs. But that's a much harder problem, because you get all sorts of illusory accounting when people project potential costs they're avoiding. E.g., I um heard that at (big firm with ~1000 developers), the QA team was successful arguing for additional funding because they were finding more bugs. So the kernel team started tracking edits as fixing potential bugs, to restore the balance of funding. They hated the game, but had to play it.

gabereiser 3y ago

The problem is they can’t justify your cost if you go outside the planned work load. They could probably still quantify it but it’s difficult to assess your impact when your effort doesn’t count towards velocity and delivery of business outcomes. If you work does impact those things, it should be a ticket/story/task so that the impact of work can be measured (seen…). I would suggest, in the future, adding these things to the backlog as you come up with them and bring them up during planning.

brennvin 3y ago
> The problem is they can’t justify your cost if you go outside the planned work load Cost? It's a freebie. I'm still doing my tasks, in addition to saving them tons of money with better tools.
ResearchCode 3y ago
The measure is called an accepted pull request. You don't need a ticket to submit a patch to the Linux kernel. If you're in a dysfunctional agile micro-management environment with "stories" and "backlogs" then look for a real job.

Aurornis 3y ago

> Growth-oriented people like myself are sometimes seen as a problem because they cause things to happen that are not in the road map. Creating new work that wasn’t in the roadmap (excluding tech debt and other necessities to get roadmap work done) is a problem. The right way to grow is to learn how to work with the company to get important work into the roadmap. I’ve worked with some peers who had good ideas and good intentions, but they’d unintentionally try to blow up the roadmap and reset planning by prioritizing their work over the things we needed to get done. Working with the business to get things prioritized is a necessary skill. A lot of engineers just want to work on whatever they want to work on most, but that’s a problem in the context of an organization trying to coordinate.

brennvin 3y ago
> Creating new work I am not talking about creating additional work, I am talking about solving problems not on management's radar screen. Some problems are only visible from the floor. > The right way to grow is to learn how to work with the company to get important work into the roadmap. That is not always possible because valuable things sometimes have to be demonstrated to be understood. Not all things can be explained in the abstract, sometimes you have to build the thing first before people understand how useful it is.
- natpalmer1776 3y ago
  I agree with this sentiment. A good (software) engineer needs to have the discernment to know when to ask for permission, and when to ask for forgiveness.
  - bombolo 3y ago
    Sounds to me like you're getting micromanaged.
    - natpalmer1776 3y ago
      I fail to understand how you manage to extrapolate my working conditions from a generalization of what soft skills are required to be a good engineer.
  - tremon 3y ago
    A software engineer only needs to make those judgement calls in a bad environment. In a good environment, such situations can be discussed in the open.
    - geodel 3y ago
      Well if in 80% of enterprises engineers do not talk in open that good vs bad environment hardly matters.
3y ago

sndjdn 3y ago

[flagged]

brennvin 3y ago
> but it’s one you made up. You just made a bunch of things up.

hallarempt 3y ago

"managers" -- if there are managers on top of the maintainers, then, yes, it won't work.

gloryjulio 3y ago

You need to discuss with ur manager about the priority of the tasks. This also help u with the bookeekping. When things break u can say that u have already had this discussion and it was not ur responsibility to fix it at the time

w10-1 3y ago

> My experience is that managers don't like it when people rock the boat That's what's missing from Graydon's analysis: risk-aversion is also a strong incentive in many corporations. I would argue it's the rule for middle managers, with growth being the exception. Also missing is telemetry and coordination, where companies use FOSS to find out what other companies are doing, or to coordinate policy, esp. when they fund a leading contributor from whom other companies need buy-in. Put another way, a FOSS contributor is not an individual, they are a company representative, and their opinion has the weight proportional to the companies' influence. The contributor's influence also depends on the composition of the other contributors. Alternate influences become impossible when a company dominates the contributors; hence e.g., the CNCF tracks metrics for ensuring that it takes a plurality to dominate. But really this posting isn't about FOSS contribution at all; it's about the under-valuation of avoided future costs. But that's a much harder problem, because you get all sorts of illusory accounting when people project potential costs they're avoiding. E.g., I um heard that at (big firm with ~1000 developers), the QA team was successful arguing for additional funding because they were finding more bugs. So the kernel team started tracking edits as fixing potential bugs, to restore the balance of funding. They hated the game, but had to play it.