[keyle]

I've been in those companies where "struggling departments" ended up getting all the praises and raise in budgets the following quarter because of the heroic saves they did, and raising awareness on how important they are... For stuff they totally caused on themselves.

Meanwhile, my perfectly purring department was struggling to keep the lights on.

It's a serious problem in this industry due to the disconnect between non-technical management (who understands how to double click) and engineering (who holds the company standing).

<insert IBM story about IT department cost cuts>

I'm not sure how we solve this, other than having management come from engineering.

[al_borland]

I think a good place to start is tracking all the proactive things being done and reporting them. At least then maybe someone will see why it’s quiet, because you’ve anticipated the problems and stopped them before they start.

When things come up with other teams, you’ll have a catalog of tasks that were done to show why you didn’t have the same issue. The work was done, just at a better time to avoid downtime.

[qurren]

> start is tracking all the proactive things being done and reporting them

Speaking from experience, this does nothing. If you're at a company that is okay with average performers, then absolutely, 100%, fix all the bugs in advance, make the system rock solid and stable, prevent downtime, be a good engineer.

If on the other hand if you're at a company where 10% of people must get stack ranked and PIP, or at a company where "meets expectations" actually means you're going to get the stick, and you're supposed to be "redefining" expectations every year ... then yeah, don't do anything preventative. The optics are better when you take the 3am on-call and fix the issue (that you secretly knew in the first place would happen some time in the future in your coworker's code, and already knew how to fix -- but don't actually fix it until it surfaces). Be the savior that the VPs praise in the next meeting, that's your insurance against the PIP.

They set the rules of the game, you just play the game. The rules were their choice. They could have chosen different rules.

[HerbManic]

This thinking eventually results in The Scream Test. When the screams come as a system fails that is when they act on it.

Alas, for many parts of society there is a large amount of people that would rather be reactive than proactive. It means it is easier today but harder long term.

[willXare]

The tragedy is that “nothing broke” looks like “nothing was done” to people far enough away from the system.

[_carbyau_]

Things keep breaking - "What are we paying you for?"

Nothing ever breaks. - "What are we paying you for?"

Management can choose their burden.

[markvdb]

> It's a serious problem in this industry

s/in this industry//

[kamaal]

>>I'm not sure how we solve this, other than having management come from engineering.

Given the whole point of management is to work to ensure their own survival and growth, it would in their interest to kill genuine competition when its coming up.

Who wants to raise their new competition and lose to them, no one!

[esafak]

Track leading indicators, pricing them if possible.

[ChicknNuggt]

I feel that disconnect is everywhere, when the suits dont see anything and act on reports

[kshacker]

lol. I hate presentations. I like to run a tight ship. But that does not shine, so they made me do presentations every quarter. If you do some work, you must "take" credit. It is kinda a need when you manage people since you need to build their careers.

I finally moved on to be an IC. Same story, same pressure :) You need to present to directors not because they need to know, but because your managers have a quota of N presentations per quarter, and if you back out, someone else needs to step up.

Needless to say my productivity reduces by half and sometimes to almost zero during the week or fortnight of presentations every quarter.