3 ms·
Numbers are comforting because they are "objective". Take the law; if you drive on a nice day on an empty new highway doing 5-10 mph or Km/h over the limit and
by lazyant 4y ago
Numbers are comforting because they are "objective".
Take the law; if you drive on a nice day on an empty new highway doing 5-10 mph or Km/h over the limit and there's a speed trap, you get a pic of your car with a nice timestamp and speed and you get a ticket. You drive on a rainy day with traffic and make a couple tight passes, it would be up to a cop's judgement to ticket you for reckless driving, and it's subject to interpretation, even if the first case is "safe" and the second way less. Lots of examples with other figures that are encoded in law.
For people working in teams (thinking software teams for ex), I've been asked in interviews several times "how do you measure the team's success" or variants ("productivity" etc) and my canonical answer now is: a) metrics and numbers are OK to look at but can be deceiving, can be gamed and still need interpretation. Ultimately I look at b) are the objectives being fulfilled? (are we doing the work?) – which it's also kind of subjective because we can establish ambitious goals or sandbag – and c) are people happy?, basically asking them.
- crispyambulance 4y ago> Numbers are comforting because they are "objective". Yes, your commentary basically nails it IMHO. There's a lot of worship for "results driven" people and approaches, and in some places and times that's needed. The problems come, like you said, when the metrics get punked by folks with selfish motivations. There's another facet to the problem and that's when there's a lack of information and an environment of chaos and change. What one thinks are "the facts" might not be the full story and acting blindly on that basis without knowledge of other unknown but more relevant facts will be MORE harmful than operating on instinct alone. This burns operations folks all the time. They often straddle the line between "results-driven" or "process-driven" approaches. But there's another way that can be more helpful when things are more dynamic and complicated: what I call a "purpose-driven" approach.