Hacker News new | ask | show | jobs
by necheffa 800 days ago
> Product should have nothing to do with refactors on the systems. That should be an engineering responsibility.

In practice, Product often controls the budget. So even if Product doesn't have the explicit power to veto a refactor, they have a lot of implicit power to deny this by only allocating enough to get a feature done.

Now if you care, you just pad estimates and don't mention that there is a 20% tax or whatever for refactoring.

That doesn't work in all cases, especially if the code base is particularly tangled. But you can get a lot of small things done this way.

1 comments

When we cant communicate honnestly its time to pack it up. If there is not trust how can you get anything done?
Your job, as an engineer, is to keep the ship battle ready. Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reigns and do what needs doing.

If there was no trust, they wouldn't be asking you to do the work in the first place.

Ridged top-down organizations wither away and die because they lack the agility and insight to respond to unexpected conditions. Leadership can set the high level goals of a mission, whether they like it or not, they need to also give the autonomy and authority to the field commanders to achieve those goals however they see fit.

If you are concerned your field commanders are going to go off and not stay focused on the goals then you've promoted too early.

The time for sitting around a table and talking openly at a higher organizational level is when deciding what goals to set, not in the heat of battle, unless it is to call a retreat.

It is only time to pack up when leadership is so full of itself that it cannot understand this.

Of course, you could argue that having a funding structure that necessitates padding in the first place is the early signs of the wheels coming off - which I would agree with.

> Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reins and do what needs doing.

Problem is organisational power. What happens when the "another entity" is the one that has the decision making power and is the one that can use that power to pressure you what to do and what not to do?

Asking cause this was my life for a while, and its an endless and gruelling battle of persuading, educating, trying to make someone understand things they don't want to understand ...

If they are also carry the responsibility over the wrong decisions, it's OK. If not, the organization is doomed.