LAFORGE: The tank can’t withstand that kind of pressure.
SCOTT: Where’d you get that idea?
LAFORGE: What do you mean, where did I get that idea? It’s in the impulse engine specifications.
SCOTT: Regulation forty two slash fifteen, pressure variances on IRC tank storage?
SCOTT: Forget it. I wrote it.
- Star Trek: The Next Generation, “Relics”
At some point in every job, you will come across a rule or decision that makes no sense to you and is getting in the way of you doing your job.
At this point, you have a choice whether to be a maverick developer who doesn’t play by the rules, or to play it safe and just follow procedure. But which is the right choice?
To answer that, you often find yourself running around trying to find someone to make the decision for you, despite the fact that you probably have the most information of anyone involved. But before you do that, you should think about the specific question you want to ask them:
What made people come up with this rule in the first place?
Rules vs Values
Let’s take the simplest, most common form of values vs rules thinking: Time Management.
Suppose an organisation has a rule that people have to be at their desks from 9pm till 12pm and from 1pm till 5pm.
Now suppose one of their employees is a father who has to pick up his child before 5pm. According to the letter of the rules, that dad cannot work at that company. But this is clearly nonsense. Nobody wants to lose a valuable, productive employee, and it is easy enough to make an adjustment or exception to the rule if asked. The value takes precedence over the rule.
On the other hand, suppose a company goes hard the other way and simply says:
“We don’t care how much you work as long as the work gets done”
This seems like the most sensible solution, but the problem is that you quickly encounter Parkinson’s Law, which states that “Work expands so as to fill the time available for its completion”
An anecdotal example of this at a major software firm was an employee suffering from a serious case of stress-related burnout because she was overworking.
Now, the company hadn’t asked her to work the extra hours, they were entirely happy with her performance, and crucially until she handed in her notice, they had no idea that anything was wrong. They would have been perfectly happy if she’d worked just her core hours, but her own commitment to the job was driving her beyond what she could comfortably afford to give.
The solution was to make the rule about when she needed to work very strict. At the end of her day’s work, her manager would simply apply the rule “She has to leave. No, now. That’s the rule.”
By taking ambiguity out of the equation, and imposing a firm rule, they allowed her the certainty that they were happy with her performance, rather than forcing her to guess how far she should go in following their values.
At the core of both decisions is a collection of values that drive all time management rules
1) The company/client requires a way to know that their workers are genuinely contributing to the business
2) Employees should not get the idea that the work they’ve been hired to do doesn’t matter
3) When someone needs advice or information, there should be a person available to support them
As long as those values are understood, the rules are flexible. But if you get rid of all the rules, then people have to try and guess how to interpret those values, which is distracting them from doing the actual job you’re paying them to do.
Navigating Rules-based Systems
So, how do you navigate conflicts between rules and values?
Firstly, you have to acknowledge that Rules Are Important. In a system entirely defined by values and “common sense”, people have to guess whether they’re doing something wrong, and different people will come to different conclusions. The resulting arguments and stress can be more toxic to a company even than rigidly applied rules. This effect is much worse in larger companies, because you can’t rely on close relationships and shared values to smooth out the conflicts.
Secondly, recognise that Rules are Expressions of Values. People (mostly) don’t come up with rules just because they want them there. The rules are normally designed to solve a problem, be that requiring tests to make your software more reliable (Value: Reliability), or demanding time spent on tests be justified with a business case (Value: Efficiency).
As a corollary, you cannot reasonably ask for change or exemptions from a rule until you’re sure you understand the values that drove it. What’s more, it is vital that the person in charge understands that you respect those values.
Very often this can be expressed as a Value-driven person who can’t understand why the rule matters at all, or a Rule-driven person who can’t understand why adherence to this rule may be compromising the value that rule was put in place for.
Often, the best thing to do in this case is to focus on the specific problem in question that is causing frustration, with a focus on the values of the company.
But if you find you are having the same arguments a lot about a particular rule, it is probably time to reassess why that rule exists, and whether it is still expressing the values originally intended.
Because surprisingly often the answer that comes back is “Forget it. I wrote it.”