Setting & Managing Goals – Modeling the Approach
Posted by Dan Vanderboom on December 9, 2007
I’ve been thinking about this question: how do I set and manage goals? What is the most effective way? If there were a tool to maximize our effectiveness in achieving goals, how would it operate?
My first thought is that it has to start with a definition of goals. What are my goals? Although it would be valuable to examine my personal goals, I will narrow the focus for the moment and consider only my career goals. So what do I want to accomplish? Since I believe that being satisfied with my work will maximize the value I provide, maximizing my career satisfaction sounds like a fair answer. The natural avenue to explore is thus my interests, abilities, etc. I need stimulation, love a challenge, am a proficient software developer, and after some reflection, my answer is: to continuously advance the science and art of software development.
Once I can identify a guiding principle, many goals fall into place. Successful software development, like other occupations, requires many skills: communication and collaboration, analysis and critical thinking, risk management, strategic planning, creative problem modeling, organization and prioritization of work, continuously learning new technologies, etc. Improving the effectiveness of each of these creates yet more goals, which keep getting broken down until we identify actions that we can execute immediately. This is the top-down approach, or “beginning with the end in mind”.
Tactically–from the bottom up–we adjust to the changing landscape, taking advantage of whatever opportunities come along, all the while keeping in mind our long-term vision. While the high-level goals are more general and universally applicable for career paths, short-term goals diverge dramatically. While business analysts and software developers may both benefit by learning to model problems creatively, the two professionals will use very different methods to represent their domains, and will implement those designs in completely different ways, utilizing different specific tricks to overcome different specific obstacles.
One question that arises: how can I achieve the optimal balance of focus between long-term and short-term goal-seeking activity?
Also, if I were to examine my goals in great detail, or if I had to track a complicated set of goal seeking behavior across a team, what would be the best way to model this to take full advantage of the information? Perhaps by modeling this goal-seeking-achieving behavior, we can arrive at some insightful answers. I’ve thought about this before, specifically in terms of tracking the goals of developers building a software system, but I want to model it in a way that is generic enough to be reused in other domains outside of software development because there’s a massive core of shared goal-oriented behavior that most industries have in common.
In development, there is the idea of a software defect, or bug. Typically a “bug” gets saved in a bug-tracking database, and when the bug is fixed, it gets checked off in the list, or in some other way marked as “resolved”. On a small, simple project, this may be sufficient. However, one thing I’ve seen in larger projects is bugs being closed and then reopened a lot because the real cause wasn’t understood. The bug recorded in the system was really just a symptom of a larger problem. Sometimes, a single bug can cause multiple symptoms, such that by making one fix, several unrelated “bugs” are closed all at once with no time associated with them.
If we really want to deeply understand the dynamics of problem solving, we might model the situation with a bit more epistemological integrity. For example, in the diagram below, you’ll see that some problem (which is a cause) produces one or more symptoms (which are perceptions). In terms of software, a software defect causes some misbehavior. Someone who is not a developer, such as a support or help desk person, or perhaps even a customer, can save information about the misbehavior without knowing what it’s cause is. They will likely be unqualified to know that anyway. Unhandled bug reports (misbehaviors) can be pulled out of a queue by a developer, who can reproduce and analyze the problem, do some troubleshooting, and upon figuring out what’s wrong, create a software defect record and save it, associating the misbehaviors with it. And if there’s a simple way to tell the system “and here’s another misbehavior that is probably also caused by this problem”, all the better (such as an attribute describing the degree of certainty).
Now that we’ve identified one or more misbehaviors, and identified their root cause, we are now in a good position to recommend a solution. There may be more than one way to solve the problem. So the engineer (in this case) can create an set of ordered actions describing approximately how the problem should be solved. As the problem definition matures and evolves, which may involve other engineers (and possibly some re-design meetings depending on the scope of the problem), other alternatives can be proposed, recorded, and evaluated. Once a solution is selected and approved, those actions become task items which are assigned to one or more engineers.
This scales up better for tracking detailed information about complex projects and scenarios, but it would also be nice if such a system could work on a small scale. If an engineer defines a symptom, he should be able to quickly and effortlessly move into problem definition (if the root cause is obvious and he has permission to do so), and then just as quickly define one or two steps for correction, which get checked off ten minutes later when the problem is fixed and the solution verified. It should be possible to present a user interface that can glue all of these pieces together in a simple way visually, and then expand into a more complex visual structure as the scope of the problem evolves.
In the same way that bugs can be tracked, use cases and requirements could also be defined, executed with a set of actions, and verified. And while there are some specific pieces of information to track in software use cases versus more general business opportunities, there is enough overlap that mechanisms could be shared not only in the persistent data model, but also in a creatively-designed user interface. Ideally, the same system should be usable by many different groups in an organization, including executives for strategic planning, lower level business managers and analysts, as well as developers and others in the IT department. Imagine the level of business intelligence that would be possible if an organization’s strategies could be traced from the CEO or CIO all the way down to specific features of an in-house, custom software project, in a way that made sense for each team.
Ultimately, this model mimics the brain’s own organization as well as the relationship between cause and effect. We become aware of problems (negative, reactive perceptions) and opportunities (positive, proactive perceptions). In analyzing problems, we converge on a cause, whereas in analyzing opportunities, we diverge into a set of goals. But whether we’re talking about a problem (or really, a desire to rid ourselves of that problem) or a goal, we’re talking about intention: a cause for action. Our brains perceive the world, turn that raw data into information, process that into intention, and the output is always action. The better this functional circle operates, the more effective we’ll be at setting and achieving goals.
Another important aspect of goal-achieving behavior is risk management. Where, then, do risks fit into this picture? My first reaction is to think of risks as problems, where the problem has some attribute indicating that it hasn’t happened yet, or where one could specify the conditions under which it would occur. Different sets of actions would be plans for avoidance or mitigation, some of which can’t be executed until some condition is met. Or is a risk a different type of thing altogether?