All Posts in Organizational Design

|In: Career Management|Last Updated:

Humans are the collaborating animal.

Sure, bees dance, termites build mounds, and wolves and orcas hunt in packs. But no other animal gets together to build anything on the level of skyscrapers or Mars rovers, to fight in anything resembling a human armed force, or compose and then sing barbershop quartets, let alone symphonies.

But for every successful collaboration there are probably ten that fail, whether they’re ERP implementations, failed designs for a 9/11 memorial, most legislation, or every Pirates of the Caribbean sequel and every other Disney-theme-park-ride-turned-into-a-movie.

What goes wrong? With Disney, it’s probably the need to manufacture another movie even if nobody has had even a tiny spark of inspiration to justify one. For the rest …

Often, the problem comes down to different people from different organizations coming to the party with different hidden assumptions. When these go undetected and unresolved, the usual outcome is something less than success.

Two weeks ago we looked at one aspect of the situation: How each party values the three bottom-line goods of business — revenue, cost, and risk.

Last week we looked at a second aspect of it: How organizational styles compare, and in particular their levels of empowerment, formality, and communication.

This week we look at one more aspect: Each organization’s operating mode.

At the risk of oversimplifying, organizations have three ways to do their work.

The first is to work through processes and procedures, which is to say recipes. Everything is specified, and if everyone just follows the steps as they’re described, the result will be what it’s supposed to be.

The second is to work in accordance with “practices.” Like processes, practices are organized into an accepted series of steps to follow. Unlike processes, in a practice the specifics are left to the practitioners, who are expected to apply their knowledge, experience, and judgment to each situation they face.

The third is to innovate and improvise — to figure things out based on the logic and context of each situation.

The way it ought to be is that for each type of work that has to get done, the organization responsible for it makes a conscious choice from among these three ways of working, recognizing that really, they aren’t categories so much as they’re three poles in a continuum of possibilities.

The way it usually does work is that for each type of work, whoever does it chooses whichever approach they like the best — the decisions come from hidden assumptions, not explicit analysis.

Likewise IT. So when the two organizations try to collaborate, their two sets of preferences don’t line up, because why would they?

Imagine, just for the sake of argument, that IT’s overall operating mode strikes an even balance between process and practice, with very little improvisation going on.

Now imagine the other organization IT has to collaborate with is Marketing. As the figure illustrates, our mythical Marketing organization is heavy on practice and improvisation. Following recipes just isn’t in its DNA.

Now what?

The starting point is to be conscious: of your own organization’s preferences, and those of the organization you’ll be collaborating with. How can you find out?

Ask. Not using this vocabulary, which might seem strange to anyone who doesn’t read Keep the Joint Running. But just asking, as in, “Tell me about the kinds of work you do here.”

As you listen, keep an ear out for key phrases like, “We just do what makes sense,” a tip-off that improvisation is important there. Or, “This is how we do things around here,” which sounds a lot like process.

“We know our business and get the job done”? That’s a practice orientation.

It will take some conversation, some reading between the lines, and eventually, perhaps, after you’ve built some rapport, some time spent familiarizing your colleagues in Marketing (or wherever) with these concepts. At some point in the conversation you’ll familiarize your colleagues with your IT self-assessment, and you can ask for their self-assessment.

Better yet, you’ll be able to discuss why IT is what it is and why Marketing is what it is.

That’s when both organizations will stop choosing their operating mode based on personal preference and start deciding based on the logic of their (and your) circumstances.

Once you’ve achieved that, you’ll be in a very good position to help your colleagues solve the problems they have in ways that will fit their operating mode, rather than trying to force-fit them into yours.

That’s preferable for a very simple reason: If your solutions fit their operating mode, they might actually adopt them.

Comments

|In: Career Management|Last Updated:

“When we promoted him, we lost a good engineer and gained a bad manager.”

It’s a common complaint. Engineering calls for a very different set of skills, aptitudes, and character traits than management, so there’s no particular reason to expect an engineer, no matter how smart and successful, to become a good manager.

Well, okay, there are actually two reasons to expect it, only one of them often backfires while the second one frequently fails to occur to engineers promoted into management roles.

The one that frequently backfires is that great engineers, like all great employees, have the habit of success: No matter what the assignment, they expect to get it done and get it done well, and they do whatever they have to in order to succeed in their assignments, too.

Including the assignment of being put in charge of a department. Too often, though, instead of this being a strength in their new set of responsibilities, it’s what does all the damage.

That’s because when an individual contributor does whatever it takes to succeed at something, it usually means figuring things out, picking colleagues’ brains, reading and learning, calling in favors, working more hours … you know, because you’re that kind of person yourself.

Managers, on the other hand, are supposed to keep things organized while delegating the actual work to the people who report to them.

The good ones understand that while they remain accountable for the results, they’re supposed to give both responsibility and authority to the employee to whom they’ve assigned whatever task or goal it is that they’ve delegated.

Too many engineers-turned-managers understand this only in their pre-frontal cortexes (cortices?), not their intestines — in theory, that is, but not when the rubber of that’s-how-I’m-supposed-to-delegate meets the road of maybe-the-assignee-won’t-get-it-done-right.

Worse, engineers being what they (we) are, “right” generally means “how I would have done it.”

Which is why so many engineers, when promoted into management roles, turn out to be lousy delegators, micromanaging, taking back assignments and doing things themselves at the first signs of trouble, or both.

They have the habit of success, which means that at the first sign of possible failure they do whatever it takes to prevent it.

On a task-by-task basis.

The second trait — the one that often fails to occur to them, is that they understand the form-follows-function principle and how to use it to design things that serve a well-defined purpose … and, for that matter, how to clarify the purpose of the thing they’re supposed to design, in order to put them in a position to design it properly.

Put in charge of an organization, engineers should be the best choice possible for designing the organization and the processes and practices it uses. They would be, too, except for two common blind spots. The first is that many engineers don’t think of organizational design as an engineering exercise in the first place. That’s easily fixed: Just call attention to it.

Their second blind spot, though, is themselves.

It’s all too common for engineers to organize information flows and approval processes so that everything has to loop back through them, and not just once, but several times.

Which brings us to a bit of communications protocol nostalgia (yes, KJR’s audience is capable of communications protocol nostalgia, and ain’t that grand?) — how the X.25 protocol was changed into frame relay, with an orders-of-magnitude improvement in both latency and throughput for the exact same physical connections.

X.25 assumed a high transmission error rate, and so included error-checking handshakes at every node of a multi-node transmission network. Frame relay assumes a low error rate, and so leaves the error-checking to the end points instead.

So we can call engineers-turned-managers who loop information and approval flows through themselves multiple times “worse-than-X.25 managers.” They’re worse than X.25 because, instead of relying on node-to-node handshakes as X.25 does, they pass all error-checking handshakes back to a central supervisory system instead (themselves). That slows actual transmission to a crawl.

They distrust both the links and the nodes, that is, and so they destroy both the cycle time and throughput (in network lingo, latency and bandwidth) of every process and practice they’re responsible for.

Were they to take off their succeed-at-all-costs hats and put on their engineer-the-organization hats, they’d recognize what they have to do: First, move to X.25, trusting their employees to recognize and correct errors without their having to personally intervene.

And second, establish the kind of staffing and level of trust among team members that reduces the time spent error-checking because there are fewer errors to find.

Comments