So I was driving down the highway this morning and I started thinking to myself. Wow there are a handful of goals that a lot of these people have in mind as they are all seemingly doing the same thing (driving).
- Some people want to get where they are going as fast as possible.
- Some people want to see how many people they can cut off in one drive.
- Some people want to get to where they are going alive.
Among other things, there are obviously way too many to list…
What’s fascinating about this is that even though everyone is participating in the same exact task (driving, yeah I needed just one more parenthetical reference so I could drive it home and also give myself an opportunity to make a pun…) they all make very different decisions about how they perform that task based on the goal they have. Some people swerve in an out of lanes, some people drive like turtles and so on.
So then I started thinking about the balance you need to strike to continue down the road and hit the goal. Let’s take “Get to my destination alive” for example. If you drive like a teenager hopped up on a double espresso and late for your 3rd shift job at the Wendy’s then you run the risk of not achieving your goal in a very spectacular way that usually involves a shovel as a cleaning implement. If you drive too slow, you may never reach your destination. Well, as a sidebar, I suppose my goal should be time-bound as well but this is just an example. So you will conceptually “never” get there. So there is a balance you need to strike in order to reach your goal in the case of driving to work.
This relates to software solutions in that essentially what happens is a lot of people have a lot of different goals that they try to hit within the project. But instead of driving to work its build the new XYZ application or build the next big web service… Generally I find that these goal conflicts come in 2 distinct flavors:
- Personal goals (usually driven by values, yup I keep coming back to driving)
- Initiative goals that may or may not be aligned with what the initiative owner had in mind (or more likely just straight up are not goals at all).
So let’s take the first one, personal goals driven by values.
If you value Safety, you make decisions on the project that are all low-risk. If you value Variety, you might make decisions on the project that don’t lead you down familiar paths, therefore introducing risk. So if it’s you making the decisions on the project it pays dividends to know what you value and how you think so you can get in front of these things. If you have team members who are working on the project then you are going to have to use equations and active listening to see where their decisions are coming from. Here’s a great example I ran into the other day:
My buddy says: “I think it’s been like a year since that team has been working on that feature set, it’s awful that it’s taking that long.”
My buddy’s co-worker says: “How can you say that? You’ll demotivate the team if they hear negative talk like that and then they won’t finish the features for the release.”
Whoa, horsey. What would make my buddy’s co-worker say something like that? Well I can think of a few things. One is that this person definitely wants to keep the peace so one of their values is “making people happy.” Or perhaps they are looking out for who is going to point fingers at them if they get found out that the project is actually not doing that awesome. One thing is clear: this person is not connected to the goal of the initiative. When I hear things that sound like “let’s not rock the boat” I immediately think: ah this person is non-confrontational. OK I can can’t have them be in situations where they need to confront people. Oh, so this person is the delivery manager on a project that has fires all over it and the client is mad as hell. Yeah, this is going to tank…
The other thing that can get you random decision-making and then random outcomes is when the people on the project are not in line with the goal of the initiative.
Here’s an example:
Me: “So tell me again, what are we trying to do on this project?”
Person 1: “We are trying to make money.”
Person 2: “We need to give the clients the best possible way to see the data.”
Person 3: “We need to add a field to the database.”
Ugh, shoot me. None of these things are goals. They are whatever the people picked up from a meeting where I’m willing to bet that a goal was never clearly stated. Here’s the deal with not clearly stating goals. If I stood in a room full of people and said: “Hey guys, we need to lose 20 pounds in two months. OK, GO!” In two months I would get results back from people who:
- went on the Atkins diet
- cut arms off
- went on crystal meth…
Whoops, I just got bad outcomes because I basically told everyone to go out there and achieve an objective, not a goal. The goal is found by asking one question:
“Why?”
Why do you want to add a field to the database?
So that the client can see the data they need.
Why does the client need to see that data?
So that they can make excellent decisions about how they spend their money.
Done. Now we are at the goal level of the initiative. The reason why we are at the goal level is that going further beyond this question in asking why for the “Initiative” gets us to the reasons why that initiative exists in the first place which are usually company or at least division goals.
So what? Why does it matter that the guy who wants to add the field to the database is not aligned with the goal of “providing the best client service solution in the world”? Well, that will affect his decision. What if in order to really enable the client to make the best decisions we need to add more information? What if to have the best client service in the world we actually have to open up a phone line that and put a human being behind it and that’s what’s stopping up from achieving the goal and the extra data is pointless?
So to conclude here: If you have clear goals that everyone on the team knows and can connect to, then you will stand a chance at getting expected results. If you have goals that are not clearly stated or not understood by your project team you might end up in an awkward meeting with a crystal meth user who now goes by “Lefty.”
