6 ms·

> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should a

by hnick 6y ago

> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like when web companies disable your account and won't say exactly why. Not gonna take the risk you prove them wrong, are they? It would be nice though if all laws had a purpose included.

whatshisface 6y ago
On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.
- ardy42 6y ago
  > On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt. Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook. This seems like one of those areas where there are unavoidable tradeoffs: * clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas. * clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions. * policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.
  - whatshisface 6y ago
    You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.
    - ardy42 6y ago
      > You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful. I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.
      - whatshisface 6y ago
        I'd explain why you're misconceiving the tradeoff, but we have a policy against omitting policy rationales, and that's that. ;) >Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful. Well, it's supposed to only be a handful: the handful of people who know more than the policymaker.
    - dragonwriter 6y ago
      > You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception Very often part of the purpose of the policy is to end debate about how to handle an issue, and to get the “crackpots and geniuses” to STFU. That's not a motivation that policy sponsors usually want in print, though.
  - hinkley 6y ago
    It’s almost as if there is no single technique for reaching all members of a target audience... You need two documents, minimum. One with rules, others to justify them.
- hnick 6y ago
  I think it depends on the person. For myself (and probably many people with the hacker mindset), I don't like useless rules and want a justification or I tend to think I "know better" which is of course sometimes true and sometimes not. I used to think this was a rebellious streak but perhaps it's just from that desire to know how things work. Absent a reason, I'll find my own. A lot of people don't care either way, rules make life simple so there's no need to complicate it further.
- dragonwriter 6y ago
  > On the other hand, a reason can convince people, Policies very often have official reasons for just this propaganda purpose, but it's worth noting that the reasons cited for the purpose of motivating compliance are often chosen for the specific purpose of how well they are anticipated to motivate compliance and not how well they reflect the actual reasons the policy is adopted, and thus they often are not in practice a good tool for understanding how to challenge the policy effectively.
thaumasiotes 6y ago
> It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. There's more to it than that. There are two separate groups of reasons: 1. The reasons a policy was put in place. ("Why did we do this?") 2. The reasons a policy succeeds. ("Why is this a good idea?") You can know the reasons in group 1. But nobody cares about those. What matters are the group 2 reasons, and they were probably never known in the first place.
- hinkley 6y ago
  I was working in a throughout computing problem domain. About the time I got there, some asshole in HR had everyone’s (current and former employees) tax information on their work laptop and lost it. Tens of thousands of people, because there was no policy against putting such information on portable equipment. And as far as I’m aware there still isn’t. No, within the year (might have been a lawsuit, I can’t recall) new policy became everyone’s machine has whole disk encryption. Including engineering. So my software was instantly 30% slower, and a half a day added to setting up any new machine. I don’t know how many times I had to explain that it’s not our code that got slower, the whole company got slower. It took me months of work to get us back to zero. That person should have been run off and anyone in their dept caught doing the same should have been put on probation. I don’t know how you figure that it’s “fair” for everyone to suffer for the mistakes of one member. In a small team setting? Perhaps. But not for something like this.
  - compiler-guy 6y ago
    Thinking about the policy in terms of punishments and fairness isn’t the right approach. Something happened that cost the company a great deal of resources, so the company is trying to prevent such a thing from happening again. It may be doing a poor job at that, but it isn’t punishing you and it isn’t about fairness. It’s trying to prevent a future mistake. And because the company is a single entity, it is the company choosing to bear the cost. It may make your job harder and they may not modify its expectations properly after imposing this cost on you, but that isn’t punishment or fairness. It is poorly thought out systems.
fjwefjh 6y ago
Or policy writers copy n pasted something off web. In my Mega Tech corp, we have security team that has created hodge podge of conflicting policies. For example, they ask some applications to be internal network only and other are accessible via web. But they can never provide their reasoning and get annoyed when we ask any details. The worst part is that some of their policies directly contradict with each other. For example, policy is to never run as root inside docker container but then there are some applications provided by them that runs as root in docker. And every time you use it, you have to remind them that these are their apps or else they will ask you to stop running it as root. Finally, I had pleasure of talking with one of their Security and Compliance expert. They could not even knew how to list file perms in Linux, and other a lot of basic ideas. This person clearly had memorized interview questions but had clearly no understanding of those concepts. Only way to hide their incompetence is act elite and don't explain their reasoning.
- dragonwriter 6y ago
  > Or policy writers copy n pasted something off web. The fact that policy sponsors are more than anything looking to a single answer to end debate and establish uniformity is why policy writers can copy and paste stuff from the web and get it adopted as policy without a clear rationale connected to the organization’s particular circumstances. They aren't conflicting, alternative explanations.
dragonwriter 6y ago
> A reason can be argued against while a policy must just be followed. And if you talk to people directing policy efforts (who are often not the ones writing, or even actively choosing, policy but generally are the ones formally signing off), you often don't have to dig very far to find that settling discussions is as important of a rationale for the policy as any of the others. This obviously conflicts with ideals like continuous improvement, but it's true lots of places including those with nominal commitments to continuous improvement.

by hnick 6y ago

whatshisface 6y ago

On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.

ardy42 6y ago
> On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt. Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook. This seems like one of those areas where there are unavoidable tradeoffs: * clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas. * clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions. * policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.
- whatshisface 6y ago
  You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.
  - ardy42 6y ago
    > You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful. I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.
    - whatshisface 6y ago
      I'd explain why you're misconceiving the tradeoff, but we have a policy against omitting policy rationales, and that's that. ;) >Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful. Well, it's supposed to only be a handful: the handful of people who know more than the policymaker.
  - dragonwriter 6y ago
    > You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception Very often part of the purpose of the policy is to end debate about how to handle an issue, and to get the “crackpots and geniuses” to STFU. That's not a motivation that policy sponsors usually want in print, though.
- hinkley 6y ago
  It’s almost as if there is no single technique for reaching all members of a target audience... You need two documents, minimum. One with rules, others to justify them.
hnick 6y ago
I think it depends on the person. For myself (and probably many people with the hacker mindset), I don't like useless rules and want a justification or I tend to think I "know better" which is of course sometimes true and sometimes not. I used to think this was a rebellious streak but perhaps it's just from that desire to know how things work. Absent a reason, I'll find my own. A lot of people don't care either way, rules make life simple so there's no need to complicate it further.
dragonwriter 6y ago
> On the other hand, a reason can convince people, Policies very often have official reasons for just this propaganda purpose, but it's worth noting that the reasons cited for the purpose of motivating compliance are often chosen for the specific purpose of how well they are anticipated to motivate compliance and not how well they reflect the actual reasons the policy is adopted, and thus they often are not in practice a good tool for understanding how to challenge the policy effectively.

thaumasiotes 6y ago

> It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. There's more to it than that. There are two separate groups of reasons: 1. The reasons a policy was put in place. ("Why did we do this?") 2. The reasons a policy succeeds. ("Why is this a good idea?") You can know the reasons in group 1. But nobody cares about those. What matters are the group 2 reasons, and they were probably never known in the first place.

hinkley 6y ago
I was working in a throughout computing problem domain. About the time I got there, some asshole in HR had everyone’s (current and former employees) tax information on their work laptop and lost it. Tens of thousands of people, because there was no policy against putting such information on portable equipment. And as far as I’m aware there still isn’t. No, within the year (might have been a lawsuit, I can’t recall) new policy became everyone’s machine has whole disk encryption. Including engineering. So my software was instantly 30% slower, and a half a day added to setting up any new machine. I don’t know how many times I had to explain that it’s not our code that got slower, the whole company got slower. It took me months of work to get us back to zero. That person should have been run off and anyone in their dept caught doing the same should have been put on probation. I don’t know how you figure that it’s “fair” for everyone to suffer for the mistakes of one member. In a small team setting? Perhaps. But not for something like this.
- compiler-guy 6y ago
  Thinking about the policy in terms of punishments and fairness isn’t the right approach. Something happened that cost the company a great deal of resources, so the company is trying to prevent such a thing from happening again. It may be doing a poor job at that, but it isn’t punishing you and it isn’t about fairness. It’s trying to prevent a future mistake. And because the company is a single entity, it is the company choosing to bear the cost. It may make your job harder and they may not modify its expectations properly after imposing this cost on you, but that isn’t punishment or fairness. It is poorly thought out systems.

fjwefjh 6y ago

Or policy writers copy n pasted something off web. In my Mega Tech corp, we have security team that has created hodge podge of conflicting policies. For example, they ask some applications to be internal network only and other are accessible via web. But they can never provide their reasoning and get annoyed when we ask any details. The worst part is that some of their policies directly contradict with each other. For example, policy is to never run as root inside docker container but then there are some applications provided by them that runs as root in docker. And every time you use it, you have to remind them that these are their apps or else they will ask you to stop running it as root. Finally, I had pleasure of talking with one of their Security and Compliance expert. They could not even knew how to list file perms in Linux, and other a lot of basic ideas. This person clearly had memorized interview questions but had clearly no understanding of those concepts. Only way to hide their incompetence is act elite and don't explain their reasoning.

dragonwriter 6y ago
> Or policy writers copy n pasted something off web. The fact that policy sponsors are more than anything looking to a single answer to end debate and establish uniformity is why policy writers can copy and paste stuff from the web and get it adopted as policy without a clear rationale connected to the organization’s particular circumstances. They aren't conflicting, alternative explanations.

dragonwriter 6y ago

> A reason can be argued against while a policy must just be followed. And if you talk to people directing policy efforts (who are often not the ones writing, or even actively choosing, policy but generally are the ones formally signing off), you often don't have to dig very far to find that settling discussions is as important of a rationale for the policy as any of the others. This obviously conflicts with ideals like continuous improvement, but it's true lots of places including those with nominal commitments to continuous improvement.