Hacker News Reader

goals.

taking a different example, you might have a goal to lower outage minutes by 50%, so your output metric is “outage minutes”. in order to change the output, you need to identify what projects/mechanisms you can use to change the output. More often i’ve seen these be referred to as input goals (increase test coverage, adopt feature flagging, etc.) but you could always associate a metric to them.

View on HN

Ok but "outage minutes" is itself an input to something else, like customer satisfaction or whatever. So that label isn't really clarifying anything.

What you're saying sounds the same as "The output of one service is the input to another, so the label isn't really clarifying anything".

There's plenty of value in breaking apart all of the interactions between various parts of the system and looking at their outputs and how they intend to change those outputs through which inputs.

Reply on news.ycombinator.com