Don't Feed the Thought Leaders

My leadership is constantly pushing for “hedgehog” style advice to be depersonalized, encoded in policies, and handed over to bureaucrats or automation to enforce.

Trying to empathize with their position, I think they think failure happens because the right hedgehogs didn’t show up to the design review that day, or forgot to harp on whatever point that time. They are never satisfied with the “it depends, there’s no hard and fast rule, you have to let the experts think about it in context” responses I give them when pressed for policy. This is limiting my advancement. But worse, someday someone will join the team and will write those hedgehog policies, and then I’ll have to live under them too.

Software engineering is a thinking person’s game. I get that management wishes it weren’t, but it is.

This is pretty brilliant.

I think I agree with the main thrust of the article but I view it from a different angle.

>they are always talking about a thing, that is the most critical thing in every case.

Yes, the quality person will always advocate for more tests. The safety person will always prioritize safety. The person managing the schedule will always prioritize deadlines. The cost manager will always prioritize the budget. It’s intent to human biases.

However, unlike the author I think “reaching alignment” is actually pretty important. But I don’t think alignment is about “the thing” central to the domain experts focus, but rather about reaching alignment about acceptable risk.

“What’s really at risk if we don’t meet the standard for test coverage?”

“What’s really at a safety risk if we don’t implement that testing strategy?”

“What’s the risk to the schedule if we miss this deadline because we implemented that extra safety?”

“What’s the risk to the budget if we miss schedule?”

In each of these, if you can reach alignment on acceptable risks it does a lot for the effort. It doesn’t mean any one “thing” has to be a priority in every instance but rather put in the context of overall risk profile. Conversely, if you avoid reaching alignment I’ve worked on teams that will actively subvert the effort because they don’t believe you agree with their “thing” as a priority in any case.

Standards aren’t written in stone but are there to partly guard you against biases. Are you not meeting them because the risk changed to be more acceptable? Or are you just v rationalizing some unconscious bias? Explicitly defining risk helps here.

I will say for that to work you need to have people who are willing to openly accept risk. I’ve also worked on teams where that wasn’t the case and alignment could never be reached because nobody wanted to be on the record accepting risk because if they didn’t make a decision they still had some plausible deniability.

To be a good X you must follow the rules. To be a great X you must have followed the rules so well as to learn why they’re there and when they should be broken.

Works for almost any X - writer, programmer, driving, etc.

This works especially well when you set and own those priorities, or if your management supports those priorities. Everyone who wants their feature will need to justify to you that their feature deserves a better placement on your roadmap.

It does not work if you can not defend your priorities.