Hacker News new | ask | show | jobs
by ChrisMarshallNY 1579 days ago
This woman always has such great things to say.

Like the previous discussion on safety regulations and societal boundaries, I feel as if tribal knowledge and heuristics are the best approach. This gives training, loyalty, good management, mentorship, experience, and personal judgment extra weight.

Not a popular stance, these days. Everyone wants to figure out how to have vast, transient, armies of disloyal, inexperienced –and, possibly, even incompetent– mercenaries, developing their product. No one wants to filter for the types of employees that can operate in an environment without guardrails and strict rules. They are expensive, and often require a very different management style, from the norm. I used to manage just such a team.

"Any proposal must be viewed as follows. Do not pay overly much attention to the benefits that might be delivered were the law in question to be properly enforced, rather one needs to consider the harm done by the improper enforcement of this particular piece of legislation, whatever it might be."

-Lyndon B. Johnson

2 comments

Whenever someone suggests introducing process that could lead to just as much harm as good, I remind them that we should prefer to hire smart people, and trust that they are smart enough to recognise when they've made a mistake so they can, if not outright fix it, at least ask for help in fixing it.

Sometimes an ounce of prevention beats a pound of cure. Often an ounce of prevention turned into process becomes several pounds of prevention and the cure is easier.

Smart people also don’t want to be spending their time assessing the risks of unknown situations. E.g. something I came upon recently when someone asked if they could work remotely from abroad for a while. Sure, from a technical contribution perspective it made sense to approve straight away. But if there was no policy and process I would never think to inquire about the tax implications with the relevant team. You don’t only count pounds and ounces but also who has to lift them. I don’t like smart engineers having to learn tax legislation, and at least some processes act more like interfaces between teams rather than stupid controls within a team. When it’s about the latter I am all with you as long as you add responsible team members next to the smart condition.
That's pretty much what I mean by “an heuristic approach”: "Always consider fiduciary obligations. Here's where to find..." etc. In the WTF, there are likely to be specific directions and policies, but having a "navigator" for these policies ("A) Which nation is the employee in? B) Which office will be directing their work?, etc.) is a good idea.
Came here to say something similar. Sometimes the best policy is to avoid creating policies.
I love it. It reminds me of a story. My friend who joined the Big Search Company as tech lead was asked to report progress in four places. He thought it was ridiculous. So instead, he didn't report at all. He got two questions why is he not reporting? So for year's he was reporting in just two places instead of four. Two others were unused/unnecessary. However, still done by all other tech leads.
> Two others were unused/unnecessary.

Not necessarily (in general)! It could be that those other two locations are part of the eyes for someone in management. This report not adding a status update could represent 10% of 25% of the stuff they're tracking on a regular basis. Do you notice if some small percentage of all the things you're tracking stops reporting? Or does it fall through the cracks? I'm betting the people tracking that work in the other two locations would notice if everyone stopped reporting.

Should they notice the reporting drop off? Yeah. But we're only human and must rely on process and the cooperation of other humans for everything to work efficiently.

(In no way am I saying someone should have to report in four places. They should fix their process so they're reporting in one place and anyone who need eyes on those people can check there.)

Push vs pull solves it neatly; the idea of requiring subordinates manually / proactively to push status updates to various management nodes seems kind of absurd.
It's push and pull. Someone not giving regular updates is just as bad as a nagging manager.
Well sure; basic communication skills are prerequisite (and assumed). I was talking about GP's ref to formal processes that required frequently pushing updates to 4 different upstream management nodes, which I maintain is doing it wrong.