All Posts in Organizational Design

|In: Leadership|Last Updated:

Is your organization performing as well as it should? As it could?

Do you know? Can you know?

Random notions on the subject:

Notion #1: If you’re confident your organization is performing as well as it could, you’re right by definition. Neither you nor anyone reporting to you will try to improve it because why would you?

If, on the other hand, you’re confident it could be better and you’re wrong, you might do some damage, because if your organization is already doing as well as possible, the best any change can achieve is neutrality. That’s the best outcome. The rest must leave you worse off than where you started.

Notion #2: Benchmarks were popular because an executive could use them to “prove” a recalcitrant manager wasn’t performing as well as possible. They were flawed because they rarely avoided the sin of apples-to-basket-of-randomly-assembled-fruit comparisons.

“Best practices” have replaced them as the flogging tool of choice for those whose closest level of descent is 50,000 feet (15,240 meters if you’ve adopted altitude-measurement best practices).

Best practices are popular because what they prescribe rarely matches how we do things around here. Which means the manager responsible for following less-than-best practices surely deserves a whuppin’.

True story: I once saw a consultant’s PowerPoint slide that promised to “… institute best practices followed by a program of continuous improvement.”

Ahem. If the practices are best they can’t be improved. If they can be improved, continuously or otherwise, they aren’t best yet.

As the KJR Manifesto pointed out there are no best practices, only practices that fit best. Most so-called best practices are one-size-fits-no-one off-the-rack pants. They’re too small for your waist and too short for your inseam, but your boss insists you wear them anyway.

Notion #3: Fixing the root cause isn’t always the best way to deal with a problem.

Imagine, for example, that you, like me, suffer from cluster headaches. Your research determines the root cause is spontaneous activation of nociceptive pathways.

So what. We can’t do anything about the root cause. I don’t even know what the root cause means.

What we can do is take Sumatriptan as soon as a headache starts and wait 15 minutes or so for it to take effect.

Sometimes, suppressing symptoms is the best alternative. Not a good alternative, mind you, but the best one available.

Notion #4: A common and pernicious barrier to organizational change is the Assumption of the Present. It’s the Assumption of the Present when employees are sure a proposed change will fail because otherwise it would have already happened.

The Assumption of the Present is a close cousin of “We tried that and it didn’t work,” only you can suggest the reason it didn’t work is that, “Maybe we did it wrong.”

The Assumption of the Present, in contrast, is circular. And being circular there’s no entry point you can use to rebut it.

Notion #5: Agile isn’t a methodology. It isn’t a family of methodologies. Well, it is, but more importantly it’s a way of thinking about how to accomplish things.

It’s the practical application of Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

What it means to you: If you want to try to improve how your organization functions and don’t want to risk doing more harm than good, figure out ways to improve it one small increment at a time. As you do, consider that each increment should be:

  • Easy to explain: If it’s complicated it isn’t incremental.
  • Easy to integrate: The increment shouldn’t disrupt how the rest of the work gets done, or at least it shouldn’t disrupt it badly.
  • Contained: Its scope should be limited to your organization. Processes have inputs, outputs, and methods. Incremental changes should focus on methods, unless a source of your inputs or consumer of your outputs wants to collaborate.
  • Non-limiting: To the extent you can tell, implementing the increment shouldn’t close off potentially desirable future changes.
  • Reversible: If it doesn’t work out, you should be able to stop doing it without difficulty.

Last Notion: Some managers are good at operations — at keeping the joint running. Others are good at making change happen — at making tomorrow look different from yesterday.

Neither skill is good enough by itself.

Managers who excel at operations but can’t make change happen will lead a long, slow slide into obsolescence. But those who excel at change without being competent at operations have the opposite problem.

They won’t survive until the future gets here.

Comments

|In: Organizational Design|Last Updated:

Once upon a time I had a client that had five semi-autonomous LoBs (Lines of Business for the acronym challenged).

Each LoB had its own CIO who reported to its CEO. The Corporate CIO, who reported to the enterprise CEO, made six.

The corporate CIO owned the company’s data centers, the use of which was charged back to the LoB CIOs, making the latter the former’s customers, by definition. The corporate CIO also owned enterprise architecture, leading the LoB CIOs to report to him on a dotted-line basis.

Yes, that’s right: The corporate CIO’s customers reported to him.

Which leads to this conclusion about organizational charts: There might not be any such thing as a perfect one, a point we’ve explored over the past couple of weeks, but there is such a thing as an org chart that’s more imperfect than it has to be.

Org charts that rely excessively on dotted-line reporting relationships are in the forefront.

Start here: Org charts, before they accomplish anything else, depict delegated responsibilities. If, for example, the org chart has a Chief Revenue Officer, to whom a VP of Sales and VP of Marketing report, it means the CRO has delegated responsibility for selling and marketing.

Because the org chart describes delegation, it also describes who gives work direction to whom. Except … with sales and marketing reporting to a C-level position that reports to the CEO, that leaves the company’s product managers out in the cold. Shouldn’t they, or perhaps the product-line managers they report to, give work direction to the CRO?

Common sense, whatever that is, dictates they should. And so the CEO establishes a dotted-line relationship through which the CRO reports to whoever owns product management.

With perhaps one exception, dotted-line relationships are a mistake. The exception, with few exceptions to the exception: project managers, who will report to the administrative manager accountable for their overall performance, and an executive sponsor, who is accountable for the whole project and, by extension, makes decisions and gives day-to-day work direction to the project manager.

Unless the company wants to run its projects without sponsors (NOOOOOoooooo!) or doesn’t want to give, for example, raises to its project managers, some sort of dual reporting relationship is hard to avoid.

Using dotted-line relationships anywhere else adds, not to put too find a point on it, confusion without clarification. We don’t need a dotted line to figure out the VP of Sales and head of product management are supposed to work together to increase product sales. Nor does the dotted line clarify how the VP of Sales is supposed to resolve the conflicting priorities inherent in selling multiple products and services.

Which leads to the question, why are dotted lines so popular? The answer, I think, is that for many executives, reorganizations are the tool of choice in their how-to-fix-performance toolbox. And to be fair there’s some logic to this thought process.

What it is: On every org chart, each line separating two workgroups adds a barrier to getting work done when the two workgroups both contribute to the work. Therefore, the thought process goes, when work isn’t getting done, re-drawing the org chart so the workgroups in question are closer together should remove, or at least reduce, the size of the barrier.

Which would be just fine and dandy except that the org chart redrawing adds distance between the workgroups in question and other workgroups they have to work with to get other work done.

Reorganizations, that is, mostly fix what’s broken by breaking what’s fixed.

But is there a better alternative? Or, to borrow a line from Argo, is reorganizing, in spite of its flaws, the best bad plan we have?

Fortunately, there are better alternatives. We discussed two of them last week — Centers of Excellence and their less-reliable cousins, Communities of Practice.

A more general solution is to fix the business culture and thinking about what the org chart means.

The shift: When anyone thinks a dotted line will fix anything, redirect their perspective so they understand no line of any kind will help. What will help is the assumption of collaboration, where leaders expect everyone working on anything will automatically bring in whoever else they need to work with get it done.

As for the org chart itself, it’s John Venn to the rescue.

Not, you understand, an actual Venn diagram. Depicting the entire enterprise as overlapping circles isn’t really practical and will just make your head hurt.

But the thought process behind it, re-envisioning the org chart’s boxes and lines as Venn’s overlapping circles?

It will help everyone connect the dots on why not to draw dotted lines.

Comments