Writing a good objective
Working with abstract concepts doesn’t make us more strategic. It doesn’t mean we understand the big picture. It doesn’t mean we’re doing something more valuable.
When we talk about a solution, we’re talking about a point of time in the future when a new tool, process, or behavior exists. Someone could be able to do something.
When we talk about a problem, we’re talking about the present where a tool, process, or service doesn’t exist. Someone should be able to do something.
Even though we’re talking about two different points in time, we’re still talking about the same thing.
No matter how hard we try, we can’t untangle these two points in time without sacrificing clarity. The more we try to remove the solution from the conversation, the more ambiguity we add to the problem.
We need to sidestep problems and solutions altogether. We need to talk about our work as progress. Only then can we be precise without dictating implementation details.
More often. Less often. More time. Less time. More effort. Less effort. More of this… Less of that…
In these phrases we’re anchoring to something that already exists.
- I want to use [ existing tool ] less often.
- I want to spend less time on [ existing process ].
- I want to do [ existing behavior ] more often.
We avoid stating what’s good or bad about the thing. Just how we intend to change the thing.
What about new things? Things that don’t already exist?
A solution to a problem may not already exist.
Although…
Progress always exists.
Can’t find anyone attempting to make similar kinds of progress? It’s likely they won’t need our version of progress. Designing and building that far into speculative territory is extremely risky.
Beware.
Originally published on my Medium account as The problem with problems.