Greg says:

I’ve been hearing concerns in multiple organizations from people who work remotely, whether “remote” is a branch office or home office.

The complaints? That remote colleagues are missing out on important conversations that only happen in hallways, company break rooms, or around the foosball table.

Looking through the looking glass, there’s a managerial aspect of the situation, which, perhaps surprisingly, constitutes a breakdown of the old RACI chart (if you aren’t familiar with the framework, it’s an account of who does what on all project tasks – who performs work (Responsible); who decides something (Accountable); who influences (Consulted); and who cares (Informed; except for when the “I” stands for “Ignored”).

Virtualizing the workforce has revealed that RACI is no longer complete, and probably never was. RACI, as it turns out, is limited to a transactional view of employee interrelationships: Many project decisions are made “around the water cooler,” beyond the reach of project task assignments. To manage well we need another “I” – “Informal.”


 Bob says:

Maybe this is just a tangent, but one of the great leadership challenges virtualizing the workforce creates is that “What employees want” is only exceeded in its fogginess by “What management wants.”

As you point out, employees miss the watercooler effect and all the related socializing, informal brainstorming and so on that remote work has left behind. At the same time they like the convenience of not having to commute to a centralized office.

Meanwhile, managers want to be able to establish a consistent business culture – a goal already made difficult in a branch office situation even before Remote Work became a thing – while also keeping management/employee interactions relational rather than deteriorating into a purely transactional mode.

And while they want all of this, this they want to keep their workforce happy with their work situation.

So fess up, Greg. You manage people. How do you handle, and encourage them to handle, the growing gap separating the addition of Zoom to the missing RACI entry?


Greg says:

To be honest, there doesn’t seem to be a magic bullet–yet.   What seems to be the best solution so far is regular, face to face interactions, where people get these watercooler interactions that they need.  When technology has been tried, such as tablet based virtual telepresence robots or collaborative smart boards, they generally end up collecting dust.  When Google tried to replicate the sense of being in a room and working together to solve a problem, they ultimately gave up.

I am cautiously optimistic that AI tools will help us sift through the communications and help us find those important nuggets of information that lead  to feeling  “Consulted” and “Informed”.


Bob says:

I keep wondering if some of the solution is as prosaic as the Surface Pro stylus, coupled with a decently intuitive White Board app, along with sufficient training in its use, plus leader commitment to actually using it. The goal is to replicate the chemistry of a bunch of people in a room together, surrounded by whiteboards and fully charged Dry Erase markers.

Or am I just engaging in optimism bias, with a generous dose of wishful thinking?

Bob’s article is a classic on pilots.  This rerun works well with our previous topics.

I was sitting with Moe, Larry, and Curly at lunch the other day (not their real names but I feel an obligation to protect the guilty) when the conversation turned to information technology.

My colleagues (we’ll call them S3 for short) recently left the military, so their perspective on IT is a bit broader than that of most IS professionals. Moe led off with a mention of genetic algorithms. Here’s how these amazing things work: You feed the computer any old airplane wing design (for example) and a definition of what it means for a wing to be optimal. Let the computer churn for a day or two, and just as an automatic bread-maker magically produces bread, it will pop out an aerodynamically perfect wing design.

The algorithm is called “genetic” because it mimics evolution, randomly mutating the design in small increments and accepting those mutations that improve the design. Very cool stuff. If you support an engineering design group, this technology is in your future.

From there, Curly somehow got to artificial intelligence, and in particular the AI golf caddy. Apparently, these little robots actually exist, following you around the golf course and recommending the perfect club for every shot. Larry pointed out the hazards of combining the AI caddy with Y2K: “Carnage on the course,” he called it.

If you haven’t noticed, people are doing amazing things with computers these days. So why is it that most IS departments, in most projects, can’t seem to design a database, create data-entry and transaction-entry screens for it, design and code a bunch of useful reports, and hook it all to the legacy environment without the project going in the ditch?

When I started in this business, a typical big project needed 25 people for three years and was completed about a year after the deadline — if it got completed at all. Compared with the simple compilers we had when I started programming, our integrated development environments should easily make us 100 times more productive. So why is it that as I write this column, a typical big project needs 25 people for three years and is completed about a year after the deadline — if at all?

Do the math, people. One programmer should complete everything in nine months. What’s the problem?

It isn’t, of course, quite that simple. It also isn’t that complicated. Try this: Start with a small but useful subset of the problem. Then, understand the data and design the database. Create edit programs for each table. Work with end-users to jointly figure out what the update transactions are, and design transaction entry screens for each of them. Design a navigation screen that gets you to the edit and transaction screens. Build a simple batch interface to the legacy environment. Do it as fast as you can. Don’t worry about being sloppy — you’re building Quonset huts, not skyscrapers.

Put it all into production with a pilot group of end-users for a month. Turn your programming team into end-users for that period so they experience their system in action first-hand. At the end of the month, start over and do it all again, this time building the system around how the pilot group wants to work. After a month with the new system they’ll have all kinds of ideas on what a system should do for them.

Build Version 2 more carefully, but not too much more carefully because you’re going to loop through the process one more time before you’re done. In parallel with Version 2, though, start building the infrastructure — real-time legacy interfaces, partitioned business logic and so on — that you’ll need for Version 3, the production application that needs a solid n-tier internal architecture and production-grade code.

Does this process work? It has to — it’s just a manual version of a genetic algorithm. I’ve used it on small-scale projects where it’s been very successful, but haven’t yet found anyone willing to risk it on something bigger. Given the risks of traditional methodologies, though (by most estimates, more than 70 percent of all IS projects fail) it almost has to be an improvement.