[brennvin]

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.

[Aurornis]

> 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]

> 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]

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.

[tremon]

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]

Well if in 80% of enterprises engineers do not talk in open that good vs bad environment hardly matters.

[bombolo]

Sounds to me like you're getting micromanaged.

[natpalmer1776]

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.

[Spooky23]

It depends on the business. Many places have no idea wtf they want, and presented with something interesting they’ll ditch what they are doing to do it, because they don’t know why they are doing whatever they planned anyway.

The existence of this thread belies this. Running everything like a product is the fad today. It’s a fad because running a “product” means understanding its lifecycle and resourcing it as appropriate. But the mandate in BigCorp is to run printer ink fulfillment with the same methodology as an actual product, so lots of leadership time is spent thinking about toner or whatever.

It’s inefficiency created in the pursuit of efficiency via control.

[ResearchCode]

It's not a problem, that's how you create software. You can put some of those initiatives on a "road map" if you want, but there must be space for them. 50% "slack time" is a good standard for software engineering. Your software engineers likely know better than your middle-managers how to spend that time.

[gochi]

You can't get important work into the roadmap while also complaining that people are trying to blow up the roadmap when they try to get important work into the roadmap.

Kind of a big problem here, as you're defining the right way as also the way that frustrates you (and assumingly others) the most.

[vbezhenar]

> 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.

May be it's actually a management challenge to turn this enthusiasm into money?

What's a problem for one person makes an opportunity for another person.

[w10-1]

> 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]

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]

> 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]

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.

[hallarempt]

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

[gloryjulio]

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