Setting goals for a large corporate IT department is an activity where the pitfalls have pitfalls. The two scenarios that I repeatedly experienced were:
- Confusing the “what” with the “how”
- The “No child left behind” Syndrome
The “What” and the “How”
There’s a big difference between strategy and goals. A strategy describes how one will achieve one or more goals. Strategy is how and the goals are what. Allow me to use a low level technical example here. Part of our “strategy” might be to “Implement an Oracle database”. This is a “how” statement, so we need to backtrack to why we decided to implement Oracle. There is likely a goal that describes “what” our application needs to do that will require a relational database and there may be an enterprise goal that we want to leverage our investment in Oracle. Now the “but”, but our enterprise goal for leveraging Oracle may be for “mission critical” systems. That strategic goal may have become divorced from its context and now all systems are leveraging Oracle with a potential multi-million dollar licensing implication. Now we’re squarely in the nightmare that is “goal setting” for the CIO/CTO.
The good news is that the solution to ensuring that goals are properly interpreted is not a mystery. This can be accomplished with a combination of three things (you pick based on your needs):
- Establish linkage from high-level goals to lower-level goals to actions.
- Provide context in the form of rationale and implications
- Establish an IT governance mechanism
In order to establish linkages, get on a white board and begin building a hierarchy from your top level goals on down. This will help your teams to understand your intent as they create the appropriate action plans in their areas. Be careful not to force your goals and activities into a single-threaded model. What I mean is this, a lower-level goal or action may easily support multiple high-level goals. Certain graphical tools like PowerPoint may not permit you to create linkages up to multiple goals from a single lower-level goal. For example, adopting a standard database product may help you reduce support costs, increase service up-time and streamline FTE skill sets. Make sure you draw those linkages.
Context is similar, but more explicit. Linkages imply a relationship. Context makes it clear. For each goal, state a rationale (a “why”) and then state an implication (what it means in a relevant context). This is very, very effective in communicating intent.
Finally, establish a governance process to review progress toward goals at a regular interval. Lots of fodder here for the blog-o-sphere, but I will hold that off for now.
No child left behind
Egad! Where could this possibly be going? If you got the education reference, you get a cookie. We always have folks that can take an order and get it done. In fact, this is an admirable trait for project leads and soldiers. It’s my opinion, though, as generations exit their formal education having been groomed on the notion that if they can regurgitate facts on tests they are successful, we are entering a perilous time. Students are being taught “what” to think, not “how” to think (that darn what and how stuff again). The corollary in the workplace is “give me my goals (aka ‘the test’), tell me what to do and I’m good to go”.
The reality is that any goal, no matter how well written, can have unintended implications. Example time! Let’s set a goal to reduce the average hourly rate for our development and support costs, that’s a common IT goal. Some folks, when given such a goal, will hamstring the organization by eliminating their current knowledgeable “high-priced” talent and replace them with “low-cost” contractors. The only slightly hidden cost here is the impact to service levels. And, yes, this misinterpretation can be fixed by following the three suggestions above, but that’s not the point.
The point is, do you think that the average person today is likely to think critically about that goal and raise concerns OR are they likely to simply take the obvious actions to “make it so” (as Picard would say)? My experience is that the latter scenario plays out much more than I care for. Finding and promoting the “horizontal” and “long-term” thinkers should be a key strategy in trying to remedy this. This may also be an offshoot of short-term thinking, like delivering quarterly profits versus stable, long-term returns. I guess we’ll leave it to the sociologists to determine the why.
One can address this issue in several ways. Certainly providing context for your goals will help. Knowing your staff and their personality and behavior patterns (how they’ve implemented goals in the past) is critical. There is also training available for how to effectively set and interpret goals. The number one thing to do though is to screen for leadership traits during hiring that show an openness to question management, the ability to assimilate new ideas and the ability to accurately assess impacts across diverse teams. Look into “behavioral interviewing” techniques to buoy your interviewing skills.
Setting solid goals is essential to steering the ship, but there’s more to it than 3-5 PowerPoint bullets. What’s your experience?
This is obvious right? We do hire people for their experience and we expect them to leverage that knowledge to do a better job. This works 90 percent of the time. The issue is that when it counts the most, our experience can really backfire.
The two key scenarios are (a) when the world has fundamentally changed and (b) when we are overwhelmed. In these situations, experience may not help at best and be counterproductive at worst.
When the world has changed, what we did in the past may not work. Consider a real world example, remember the images of soldiers standing in rows in brightly colored uniforms firing volleys of musket fire at each other. Muskets were fairly inaccurate. Those rows of soldiers acted as kind of human machine gun increasing the probability of a hit (among other things). When we invented rifles which were much more accurate over longer distances and added tactics like guerrilla warfare, the military units that failed to adapt suffered higher causalities. The old way which had been very effective, was now a liability. The same is true for IT.
The trick is really recognizing when the world has changed. Sometimes a major change arrives as the result of a “disruptive” technology. In IT we do a pretty good job of identifying and even driving this type of change. The major changes that can really blindside us, where our experience may actually have a negative outcome, are changes that aren’t reported in the technology rags. They are major changes in how our company does business or in the scale it does business on. Examples might be:
- Moving from a product to a customer focus
- A rapid increase in size
- Certain regulatory changes
- The addition of substantially different product lines
In these type of situations, it’s important to step back, ask some tough questions and seek 3rd party help. In my experience, my gut is usually the first to raise a red flag. Be wary if there is substantial horizontal impact across the corporation or major changes in capacity requirements.
The second scenario is when we are overwhelmed. This may be due to the volume of work or the complexity of effort. I am personally a victim of this. When I have a lot of work to do, I have two choices. Do I take out the chunk I can do most easily because I know how or do I tackle the more complex tasks which require a lot more thought? The temptation is to whittle down the stack by taking out the “easy” stuff. The easy stuff may not be the most important, in fact, it’s more likely not what is important. The individual can deal with this by being aware of the affect, setting priorities and sticking to them. Management can help by being aware of when your team is overloaded and effectively setting priorities.
The axiom here is “Have the experience to know when you don’t.”
The toughest thing about being effective in IT is the organization. The technology, quite honestly, is the easy part. We can bend those machines to our wills (plural intentional). I’ve not come a cross a technical problem that couldn’t be solved. Focusing all the humans involved on a common goal and ensuring all their actions actually move us toward that goal is the vocation of this blog.
I’ve “grown up” in IT in a large corporation and had, honestly, the pleasure of leading large scale changes across the entire organization. My favorite metaphor is that it’s like shoveling water uphill. The root cause of this is that many factors affect how the organization behaves:
- we can only do what we know
- we know less than we think we do
- we do what we’re paid to (which may not move us toward a strategic goal)
- we fear complexity
- we don’t take enough time to measure
- we misuse the measurements we have
- we like to be comfortable
- we like immediate gratification
- we each have an opinion
I’m actually a people person. I like the people I work with and find staff development to be the most rewarding aspect of my job. Maybe its because I really care that people understand our strategy and have really engaged folks to get their buy-in that I feel this so keenly.
For you experts out there, yes, the solution to this is Organizational Change Management (OCM). But like most managers in IT, I have to bumble through this as my background is technical, not managerial.
Going forward, I’ll work through real-world scenarios. I’ll cover what we hoped to achieve and the behaviors we encountered. In doing so, my hope is that you gain some insights into what you might be up against, where you may be ahead of the game, how you might overcome the challenges and how to press your advantages.