It’s official, to the extent these things become official: The new magic buzzword for the old magic “people” third of the PROCESS / Technology / people magic triangle is “hybrid workforce.”

Arguing by analogy has its limits, primary among them being that it has no virtues. But still, it’s worth remembering that the archetypal hybrid, the mule, is sterile.

Unlike arguing by analogy, a mule does have virtues, combining as one does the toughness, health, and higher intelligence of the donkey with the horse’s superior speed and endurance.

Something like that.

Hybrid workforce proponents hope this staffing strategy will also combine the best of two beasts – in this case, the best qualities of on-premise and remote employees. (And I’m beggin’ you – please! don’t look for parallels to the mule’s inability to reproduce. KJR is, after all, a family blog.)

Anyway, analogy or no analogy, I’m not convinced the hybrid workforce is going to combine more of the on-premises and remote employee strengths than it will incorporate their disadvantages.

Which brings us to this week’s topic. We’re going to home in on one dimension of the hybrid workforce that has, I think, received far too little attention: emotional support.

I’m not talking about employee assistance programs, or how to create a supportive culture, or how to identify employees who are struggling. Google the subject and you’ll find lots of material covering this ground.

No, I’m talking about something so commonplace that in an on-premises workforce it’s less signal than background noise. That’s the emotional support available to employees who are being driven nuts by a: bad manager; distractingly unproductive co-worker; business stratagem that’s too dopey for words; project they’re assigned to whose schedule was established by “right-to-left” planning  … all the crazy-making day-to-day sturm und drang that happens in a typical organization.

On-premises organizations have a well-established pressure relief valve for helping employees maintain their sanity. It’s a buddy’s empathetic ear, complemented, when the situation calls for it, by “C’mon, I’ll buy you a beer.”

A typical hybrid organization, to the extent there is such a thing, might set Tuesdays and Thursdays as mandated on-premises days, leaving Mondays, Wednesdays, and Fridays to employee discretion.

To the mathematically minded it might appear that the hybrid model provides 40% of a traditional workforce’s empathy provisioning. Poor as that metric might look, the true value is worse. With only two days a week in which employees are even in reliable proximity, “buddy” overstates the level of trust they can actually form with such limited contact with colleagues.

On top of which, what we might call “empathy encounters” aren’t planned, schedulable events. So if the need arises on a Wednesday, it will have to wait until Thursday to be satisfied.

Which means it won’t be satisfied at all. By then the situation will have come and gone, leaving behind another increment of un-dealt-with stress to accumulate onto the already existing pile.

What can you do to mitigate this issue? Good question, which is ManagementSpeak for “I don’t have a terrific answer.” The best I have to offer: Set up assignments and other situations in which collaboration among two or three employees is required for success, without the set-up seeming overly contrived.

It’s two or three employees and not more because a small number allows for less-structured interactions, which in turn encourages relationship-building without forcing it. That, in turn, makes it more natural for a stressed-out employee to reach out for a sympathetic ear.

One more thought: often the best connections – and of special value to you – are between employees in your organization and those in others. So work with other managers to extend the connection-building.

You might even find this extends your own support network. You aren’t, after all, immune from the same kinds of day-to-day stresses you’re trying to help the employees in your organization cope with.

Bob’s last word: The workforce transformation from on-premises employees to some permutation of remote, is no less implacable than the tide King Canute ordered to stay out.

That doesn’t make you, as a manager, a helpless victim of the onslaught, but neither does it mean you should uncritically embrace the trend and just let it happen.

This week’s gotcha is just one of the details effective leaders need to recognize and deal with.

If you have a better solution, or if you have other thoughts to offer, please take the time to post it (them) in the Comments.

Bob’s sales pitch: The newest in my CIO Survival Guide series is now available for your reading pleasure on CIO.com. It’s titled 3 consultant mistakes CIOs can’t help making.

Which I hope isn’t accurate: Read the article and you’ll discover ways to avoid making the mistakes in question.

Speaking of thinking about thinking, it’s time to talk about systems thinking – a topic spotlighted in Peter Senge’s groundbreaking The Fifth Discipline (1990).

Systems thinking is about breaking any whole into not only its component parts, sub-parts, and sub-sub-parts ad infinitum, but also their sub-parts’ interrelationships. It’s a big subject – so big there’s no point trying to provide links to useful sources.

Most likely, you’re already familiar with many of systems-thinking’s tools and techniques. They’re essential for just about any IT-related endeavor.

But there’s a difference between, to take one example among many, using a swim-lane diagram to design a business process and using one to think through who should be responsible for what, to decide if that’s really such a good idea.

What follows are a few tools, techniques, and principles I’ve found useful over the years to help me think things through.

Law of 7 ± 2: This really should be the law of 7, + 2 if absolutely necessary. What it means is that whatever technique or tool you’re using to figure out a system, no representation should ever have more than seven elements in it – nine if you just have to. If you need more, make one or more of the elements more inclusive – a category of elements. Think through its complexity in a separate, cross-referenced diagram that also follows the law of 7, + 2 if absolutely necessary.

Why seven? Humans can easily grasp a collection of seven or fewer items. More than that and we have to inspect. We can verify the correctness of a diagram that obeys the law. With more elements we’re left hoping we didn’t miss anything.

Black box: If you’re trying to understand a business function – a process or practice – black-box thinking is essential. Black box descriptions describe what something does, not how it does it. They cover five subjects (thereby obeying the Law of 7, + 2 if absolutely necessary):

  • Outputs – what the function is for. They’re its products and byproducts.
  • Inputs – the raw materials the function converts to outputs. Any input not needed by at least one output isn’t an input at all. It’s a distraction, unless it suggests a missing output.
  • Resources – the tools the function uses to turn inputs into outputs.
  • Constraints – restrictions on what the process does or how it does it.
  • Controls – mechanisms for adjusting process operation, such as turning a process on or off, changing its speed, or setting a configurable output characteristic.

Relationships: Six ways each system element can influence other system elements:

  • Component – an element could be part of another element.
  • Container – conversely, other elements could be part of the element.
  • Output / Input – one element’s outputs could serve as another element’s inputs, and vice versa.
  • Resource – one element could produce resources used by other elements.
  • Constraint – one element could place constraints on other elements.
  • Controls – one element could affect the operation or characteristics of other elements.

Feedback: A special type of relationship that describes how a process’s output encourages (positive feedback) or discourages (negative feedback) its own operation or characteristics. Diagrammatically, black-box diagrams represent feedback as arrows connecting process outputs to their controls.

As a matter of nomenclature, “positive” and “negative” are unfortunate word choices. They suggest feedback is either complimentary or critical.

From a systems perspective, positive feedback drives a process to produce more of whatever it is that it does; negative feedback causes it to produce less. Positive feedback accelerates a process, negative feedback keeps a process in control.

Output / Input Loops: Not all loops are feedback loops. Some make one or more of a function’s outputs one of its own inputs. The well-known OODA loop (for Observe / Orient / Decide / Act) is an example. Some outputs of its Act sub-function are inputs to its Observe sub-function, and in fact each sub-function’s outputs include inputs to the next sub-function.

Decoupling: Eliminating or reducing the strength of system interrelationships is, as a general rule, a good idea. It makes the system more resilient by reducing the ripple effects of any changes being considered.

Bob’s last word: We’ve barely scratched the surface of systems thinking. It’s a highly consequential subject because without it, it’s all too easy to fall into the trap of focusing on a particular element, optimizing it without taking the change’s ripple effects into account.

Bob’s sales pitch: The next “CIO Survival Guide” is ready on CIO.com for your viewing pleasure. It’s titled “The Hard Truth of IT Metrics,” and I think you’ll find it useful. And as always, if you have any feedback for me (see above), please share your thoughts about it.