Archive

Posts Tagged ‘John Gall’

Same Old, Same Old

November 5, 2013 2 comments

After stumbling across this announcement, “Navy orders Raytheon to stop work on next-gen radar“, I just had to laugh. It’s the same old, same old “iterative” process:

  • The Department of Defense issues a request for proposals.
  • The usual suspects (Lockheed Martin, Raytheon, Northrup Grumman, etc) submit bids.
  • A winner is selected – Yay!
  • The sore loser(s) protest the decision.
  • By law, the decision must be revisited and re-evaluated.
  • The decision is either upheld, or a new winner is selected.
  • If a new winner is selected, the previous winner protests.

I’ve worked in the aerospace and defense industry for 30+ years and I’ve seen this dysfunctional, time and money wasting, game play over and over like clockwork. Tick tock, tick tock.

Sometimes the bid-win-protest cycle goes on for years and it takes longer for the hundreds of bureaucrats, lobbyists, committees, and politicians to resolve the dilemma than for the eventual winner to actually build the system. In addition, after all the political shenanigans have played out and the ultimate winner starts the ball rolling, the contract is sometimes cancelled in midstream after millions of dollars and engineering hours have been spent.

Despite repeated calls for procurement/acquisition process reform, the system is so big and there are so many intertwined players that any substantive change is virtually impossible. But hey, it’s taxpayer money. No problemo.

proposal fight

The System Always Fights Back – John Gall

A Danger To Themselves And Others

May 16, 2013 3 comments

“Efficient systems are dangerous to themselves and others” – John Gall

A new system is always established with the goal of outright solving, or at least mitigating, a newly perceived problem that can’t be addressed with an existing system. As long as the nature of the problem doesn’t change, continuously optimizing the system for increased efficiency also joyfully increases its effectiveness.

However, the universe being as it is, the nature of the problem is guaranteed to change and there comes a time where the joy starts morphing into sorrow. That’s because the more efficient a system becomes over time, the more rigid its structure and behavior becomes and the less open to change it becomes. And the more resistant to change it becomes, the more ineffective it becomes at achieving its original goal – which may no longer even be the right goal to strive for!

Eff vs Eff

In the manic drive to make a system more efficient (so that more money can be made with less effort), it’s difficult to detect when the inevitable joy-to-sorrow inflection point manifests. Most managers, being cost-reduction obsessed, never see it coming – and never see that it has swooshed by. Instead of changing the structure and/or behavior of the system to fit the new reality, they continue to tweak the original structure and fine tune the existing behaviors of the system’s elements to minimize the delay from input to output. Then they are confounded when (if?) they detect the decreased effectiveness of their actions. D’oh! I hate when that happens.

Thought Actual

Sensors AND Actuators

Encroach And Dominate

Systems tend to grow, and as they grow, they encroach – John Gall (The Systems Bible)

Complex societies, once established, tend to expand and dominate – Joseph Tainter (The Collapse Of Complex Societies)

Assimilated

How Can We Make This Simpler?

The biggest threat to success in software development is the Escalation of Unessential Complexity (EUC). Like stress is to humans, EUC is a silent project/product killer lurking in the shadows – ready to pounce. If your team isn’t constantly asking “how can we make this simpler?” as time ticks by and money gets burned, then your project and product will probably get hosed somewhere downstream.

But wait! It’s even worse than you think. Asking “how can we make this simpler?” applies to all levels and areas of a project: requirements, architecture, design, code, tools, and process. Simply applying continuous inquiry to one or two areas might delay armageddon, but you’ll still probably get hosed.

If you dwell in a culture that reveres or is ignorant of EUC, then you most likely won’t ever hear the question “how can we make this simpler?” getting asked.

EAC

But no need to fret. All ya gotta do to calm your mind is embrace this Gallism :

In complex systems, malfunction and even total malfunction may not be detectable for long periods, if ever – John Gall

The New G-Spot

March 31, 2013 2 comments

Before reading any further, please contemplate this Box cutter:

Essentially, all models are wrong, but some are useful- George Box

Now, let’s start with a pair of “model” problem-system and control-system templates:

Templates

Next, let’s hypothesize a new composite system that you designed, built, and deployed to “solve a vexing socio-technical problem“. You diligently employed the dorky BD00 templates, your brain, and your positional power to form a “semieffective” marriage between your specific problem (indicated by the blue, scoped boundary) and your specific controller (indicated by non-white components):

Effective Marriage

Although your new system may appear to be alleviating (or least containing) the problem, looks can be (and usually are) deceiving. Before you pat yourself on the back for being a “problem solver“, please contemplate these Gall-isms:

New systems generate new problems – John Gall

Systems Develop Goals Of Their Own The Instant They Come Into Being – John Gall

Intra-system Goals Come First – John Gall

Thus, according to the Gallster, the a-priori and noble “G” you designed into your fabulous controller subsystem will eventually be usurped (sooner rather than later) by the emergent “G” of the new composite system entity. Sometimes the new “G” totally obscures the original “G” so thoroughly that, given enough time, nobody can even remember what the original “G” was. D’oh!

Orig To New

And what might this new system “G-Spot” be? Could it be to perpetuate and maybe even exacerbate the original problem so that the new system (especially the controller subsystem) can grow and thrive? After all, if the problem gets solved, then there will be no more need for the controller subsystem. In effect, the new system would be devouring itself as it solved the problem. But wait! That can’t happen because it would be a fruitless attempt to violate this Gall-Shirky pair:

Systems Tend To Grow, And As They Grow, They Encroach – John Gall

Institutions Tend To Preserve The Problem To Which They Are The Solution – Clay Shirky

An alternative BD00 quote rip-off is:

Systems, like people, tend not to consume themselves as food.

Can you concoct another alternative rip-off quote?

Come To Papa!

March 20, 2013 4 comments

I recently listened to a fascinating podcast interview of Valve Inc‘s “economist-in-residence“, Yanis Varoufakis. According to Yanis, the company is still organizationally flat after 17 years of existence.

The thought early on at Valve was that the maximum limit to flatness would be around 50-60 people. Above that, in order to keep the wheels from falling off, some form of hierarchy would be required for concerted coordination. However, currently at 300+ employees, Valve has managed to blow through that artificial barrier and remain flat. Mind you, this is not a company solely made up of like-thinking engineers. There are also artists, animators, writers, and accountants running around like a herd of cats inefficiently doing the shit that brings in $1B in revenue each year.

According to Yanis, in order to maintain their egalitarian culture, Valve can’t afford to grow too quickly. That’s because they have to deprogram people who are hired in from hierarchical borgs as former bosses who expect others to work for them, and former workers who expect to be “directed” by a boss. If Valve didn’t do this, their culture would get eaten alive by the pervasive and mighty command-and-control mindset. The spontaneity, creativity, and togetherness that power their revenue machine would be lost forever.

Papa

Nevertheless, Valve is pragmatic with respect to hierarchy:

“Valve is not averse to all organizational structure—it crops up in many forms all the time, temporarily. But problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers.” – The Valve employee handbook

Whether Valve knows it or not, their success is due to their respect of some of Gall’s system laws:

  • Systems develop goals of their own as soon as they come into existence – and intra-system goals come first.
  • Loose systems last longer and work better. Efficient systems are dangerous to themselves and others.
%d bloggers like this: