Alignment or Misalignment by design

  • Index
16 minutes

A sense that perhaps not everyone is pulling in the same direction, or that teams and departments don’t really focus on the most important activities, is what drives many organizations to adopt a goal-setting framework. Their hope is that by defining organizational goals, they will give everyone a shared direction and help them set appropriate objectives.

While a goal-setting framework is definitely a step in the right direction, it will not, in itself, be sufficient to create the necessary alignment.

How can this be?

Well, organizational goals provide a shared direction and emphasize the strategic priorities of the organization. However, alignment is not just about having the same direction; it is also about coordinating our efforts.

The part pertaining to effort coordination is what’s missing from the very popular OKR framework that most organizations have probably come in contact with when looking for goal-setting frameworks.

At Sengi, we’re not the biggest fans of the OKR framework, and we do explore some of its intrinsic limitations and dangers in a different article. The gist of it, however, is that you define corporate goals (confusingly, the OKR framework calls them Objectives) and then you define 3-5 objectives (which the OKR framework calls Key Results) representing tangible business outcomes to support those goals. After that, each department comes up with its own OKRs, defined at their departmental level, to support these corporate OKRs. Some organizations take it even further by encouraging teams within departments to define their own OKRs and even encouraging people within teams to define their own individual OKRs to support the team OKRs.

We’re not going to discuss why going below the department level is counter-productive in this article, for now, let’s explore why simply having some goals and objectives is not enough to achieve alignment. This is not specifically a problem isolated to the OKR framework either; any goal-setting framework is insufficient to ensure alignment in and of itself. We’re bringing up the OKR framework because it actively encourages activities that actually prevent alignment. Let’s see how this is a problem with the OKR framework as well as with other goal-setting frameworks.

Goals exist to emphasise the current organisational priorities. They are expressed qualitatively and in broad, high-level, vague terms. They are the highest-level statement of need for what’s currently important in the organisation.

Let’s take an example

Let’s take “Increase profits,” as an example, because it’s reasonable to see how at a certain point in time, an organization might want to focus on their profits, among other parallel goals.

This goal is saying is that we must focus on increasing our profits and it is sufficient to make everyone aware that this is important for the organization at the moment. The goal is not meant to be achieved, since goals aren’t quantitatively defined. Therefore, lacking a quantitative statement such as “Increase profits by 10%,” leaves us with the aspirational goal of increasing profits as much as possible. This goal will remain in effect for as long as increasing profits is the organizational priority. At a certain point in time, other goals might become more important, and we’re going to shift our focus to them. This is not to say that we stop caring about profits or that we’d likely ever wish to decrease them. It just means that we’re happy enough with whatever the profit margins are at that point, and we’re focusing on something else.

So far so good. Everyone knows that at the moment we should be focusing on profits. When time comes to do something about this, or in other words, to actively pursue this goal, we have to think about what profit is and how we might increase it. Profit is revenue minus operational costs. So, increasing profit could come from either increasing revenue while maintaining the same operational costs, reducing operational costs, or both. It’s noteworthy that increasing revenue with a proportional increase in operational costs will not increase the profit.

This exploration of possible initiatives that we could realistically undertake to progress the goal is the critical point where alignment is achieved or lost. Many frameworks, including the trendy OKR, would have organizations define objectives (or Key Results in the case of OKRs) at this point to provide some quantitative outcomes related to the goal of increasing profits. In other words, these frameworks make a critical mistake here, which is to skip over exploring possible avenues for increasing profits and jump straight to defining precise and specific business outcomes to be achieved in support of the goal to increase profits. Moreover, as explained earlier, many organizations would take this corporate goal and have individual departments define their own individual objectives to support the goal.

We call this approach misalignment by design because it completely foregoes any attempt to coordinate the efforts of multiple departments towards the shared goal of increasing profits. Instead, it actively encourages every department to think in isolation and make decisions in their own silo.

What could happen wrong?

For example:

Sales might decide to increase prices by 10% before EOY.

This is a unilateral decision taken by Sales since “Increase price by 10% before EOYr” is a Sales objective. They’ve been encouraged to own it and commit to it, so it’s theirs and theirs alone.

Tech, the department in charge of building and operating the organization’s tech landscape supporting many critical business flows, might set themselves the objective of reducing technical operational costs by 10% before EOY.

When defining the objective, they were thinking high-level that maybe rebuilding a part of the architecture to make more efficient use of the Cloud infrastructure would potentially cut as much as 10% of the costs. However, since the goal-setting framework adopted by the Management Team encourages departments to come up with objectives without thinking too deeply about the initiatives to deliver them, the Tech department hasn’t performed a deep analysis of what this re-architecture work would actually entail. The OKR framework is particularly onerous here since it suggests that for a given Objective (note: Goal), Key Results (note: Objectives) are defined in such a way that these KRs don’t have to be realized completely. They suggest that accomplishing 70% of these KRs is the sweet spot – if you accomplish more, your KRs weren’t ambitious enough; if you accomplish less, you were too ambitious. In other words, the approach is to do away with the well-known idea of SMART objectives where “A” stands for Achievable. The focus then is to achieve around 70%, give or take, from the stated KRs. Armed with this confidence, the Tech team feels it’s okay to commit to a 10% reduction of costs without having to do a deep assessment of the re-architecture project they’re basing this cost-saving assumption on.

At the same time, Operations, the department in charge of maintaining customer relationships, customer support, and a good amount of data entry, might decide to also cut 5% of costs before EOY.

They think they might be able to do so by automating a part of their work through the procurement of a CMS.

Last, but not least, Product, the department responsible for defining the products and services sold to customers thinks they might be able to create up-sale opportunities of up to 15% more revenue.

Product hopes to get up to 15% more revenue on the same products by introducing an additional pricing tier for reports sold to customers.

The devil’s in the details

Note how all of these departmental objectives actively support the goal of increasing profits. There is clearly no misalignment in agendas here. However, there is still room for misalignment during the execution of these objectives and given the fact the objectives were defined in silos, misalignment is highly likely. When all of these departments commit to these objectives and begin executing them individually, we’ll see how we immediately run into problems.

Marketing and Legal couldn’t come up with any meaningful objective related to increasing profits since they don’t directly contribute to profits. As such, they were not too involved in this process and took a back seat, listening with reduced interest to what Sales, Operations, Product, and Tech were explaining. They were particularly bored by what Tech was explaining in terms of capacity planning, resource utilization, thread usage, and the relationship between rate monotonic scheduling and their SQS usage.

However, when Sales do actually want to increase the price, they realize that it’s not that simple. Many of the customers have a yearly contract with a fixed price, and the company cannot unilaterally alter the contract. Legal would have to get involved, but remember Legal didn’t set any objective for themselves insofar as increasing profits is concerned. They might have set other objectives supporting other goals, unrelated to profit. For them, it feels like being dragged into a Sales-driven project, and they feel late to the party. Marketing, on the other hand, realizes a 10% price increase might be too much for their client segment profile. They would have to look at different customer segments that can afford to pay more. Marketing is happy to help, but Sales can’t really come up with a new pricing model until Marketing figures out how to define this new, richer, customer segment. Sales is stuck!

In the meantime, Product has a problem as well. They’ve spent 6 weeks defining the new paid reporting capability together with the new pricing tier for advanced reporting which, of course, comes along with more features to manage and control who has access to use what report. However, when they wanted to implement these brilliant new features, they were unceremoniously turned down by Tech, who does the actual software development. It turns out that Tech is busy with their new re-architecture plan which will keep them occupied until the end of the year at least. They have their own objective to cut Cloud infrastructure costs and don’t want to jeopardize that by working on new features. Also, they’re also 6 weeks into the new architecture project, and the codebase is in no position to be extended with new features now.

A similar sad story happens for Operations in another corner of the organization. They spent the past 6 weeks attending countless product demos from different CMS vendors, and they finally made their choice. They now only need the new CMS system integrated into the existing technical landscape so they can log into the system with their corporate accounts, ensure the system has access to the existing information held in multiple databases, ensure the CMS can send them emails on their work email for various notifications and, of course, the data flow between the new CMS and the other systems in their organization is set up. All in all, this is estimated to 6 months of development work, and, who would have guessed it, this project goes completely against what Tech has planned for the year. So, unfortunately, Operations is going to get a “no” from Tech as well.

In the meantime, Marketing comes back with market insights. They found the rich customer segment happy to pay 10% more. But alas! They’re playing in the big leagues, and our organization was focused on a lower-tier customer segment. If we want to swim with the big fish and gain access to this richer customer segment, they’re going to have to make some changes. Not only do they require SSO (Single-Sign-On) through their own corporate identity provider which, of course, requires work from Tech, who proves to be quite stubborn in pursuing their individual objective, but to make it worse, the paid pricing tier that Product was so proud to define is provided for free at that higher price range by all competitors.

Understandably, during the company QBR, Sales, Product, and Operations raise their frustrations regarding their dependency on Tech and also regarding the mismatch between Sales and Product who have a conflict of objectives which now becomes apparent – Sales wants to increase prices, Product wants to get more revenue through a premium feature but these things can’t both happen. Either we increase prices and give the new premium feature included in the price, or we don’t increase prices but charge for the premium feature.

The Management Team feels they need to step in since most departmental objectives are now stuck, and Tech’s architecture improvement initiative is at risk since the project proves more complex than anticipated. The Management Team decides to re-prioritize things and unblock the situation – they tell Sales to forego the 10% price increase since tackling the new customer segment and re-negotiating contracts with the existing customers is too complicated. They also tell Tech to suspend their architecture work and re-focus on Product’s new set of features and the integration of Operation’s CMS.

Tech is understandably unhappy about this since they’ve invested a lot in the architecture project plus we’re now more than 6 months in with no time available to tackle both the new feature set and the CMS integration. Furthermore, when did they become the bad guys since they’ve put in as much work as everyone, if not more, to fulfil their objective. In the end, they’re the only ones, beside Product, who’ve made any significant progress towards their objective; they depend on no one and all others depend on them.

Sales are also not happy since their objective was simply scraped at the first sign of a problem. Are their objectives not important? They feel they’re the ones bringing in the money, so their objective should come first, right?

Pressured by the board, both Tech and Sales have to comply. It might feel natural to get frustrated at Tech here since they seem to be the general naysayer. However, it’s important to realize that a lot of the organizational issues are only evident when they manifest, which happens, more often than not, in the last segments of the value stream, among which is, of course, Tech. Also, who can blame Tech for taking the much-recited gospel of accountability, empowerment, and owning your objectives and commitment to heart? They did what they were told – they defined their objective and they’re following through.

Discussion

Let’s explore the outcome of the hypothetical, but all too common, scenario described above.

We can safely say that it was a complete failure as in the end, none of the departmental objectives were met. A lot of time, effort and budget was spent on basically nothing to show for. To make matters worse, the promise that the Management Team will not micro-manage but instead manage by objectives, encouraging autonomy and agency, has proven to be nothing but hot air.

All departments, but primarily Tech and Sales, are feeling let down by the Management Team and lost trust in the autonomy, empowerment and objective-driven culture that was promised. They feel that, as expected, at the first sign of trouble, the Management Team is all to happy to revert back to the old command-and-control approach they used for years.

On the other hand, the Management Team is completely confused – how did we end up this way? We did all the OKR dances – we did the motions, we said the right things, we recited all the correct mantras so why didn’t it work?

As we said at the beginning of this article, some frameworks, or at least the way in which they’re commonly applied, generate misalignment by design. Misalignment is simply baked deep within the recommended approaches and there’s little that can be done to avoid it.

If only the Management Team adopted a goal setting framework which also includes elements of initiative planning. Then they would have encouraged the departments to not think in silos and come up with departmental-scoped objectives with made up business outcomes. Instead, they would have recommended that the departments do a few brainstorming sessions to map out what initiatives are possible to increase profits and what each department has to do as part of these initiatives. Perhaps one or two initiatives that included many departments would have been proposed, approved and executed successfully instead of none.

What do we recommend?

As a common theme throughout many articles that we share, the approach we recommend is as follows:

  1. Define goals
  2. Think about initiatives that might progress these goals. These initiatives are often cross-departmental. Describe these, their participating departments with their required activities, their objectives and the goals they support, their risks, implications, preconditions, estimated completion date and also the date where the business outcomes promised by the initiative objectives are expected to be realized. Propose these initiatives as shared projects, across departments as opposed to department-siloed initiatives.
  3. Consider all proposed initiatives together, not in isolation, as business cases and approve the subset of initiatives which is congruent (there are no conflicting initiatives within the set).
  4. Execute these initiatives where each department has a part to play. When the initiatives complete, wait until the date the actual business outcomes associated with the initiative objectives are expected to be realized and review the extent to which these outcomes have actually been realized.
  5. Learn from what went wrong and apply these lessons for the next round of initiative proposal, approval and execution.

At Sengi we provide alignment by design by implementing the process described above. We enable the definition of corporate goals but we deliberately don’t allow free-floating objectives to be defined supporting these goals. We call these unbound objectives because they’re not connected to any initiative that would deliver them.

Instead, we enforce initiatives to be defined to pursue goals and ensure that objectives are defined as part of those initiatives. We also make a big deal out of helping organizations look at these initiatives as cross-departmental projects as opposed to departmental-siloed projects.

In this fashion, we’re sure that a scenario like the one debated in this article, which is all too common in our experience, does not happen in your organization.

Ready to put these concepts in action?

Start Free Trial