A History of FLEX: 1983-84
This is as much as personal tale as it is a history of how FLEX came to be. I will only put in as much of the personal story as the tale requires. I believe telling it as a story, however, is useful because learning takes place in steps and the order of the steps is often important. So I’ll do this chronologically in the hope it makes the learning of the lessons in the tale easier.
The roots of FLEX
In some ways FLEX starts in 1983 and 1984 with two life changing insights. The first was personal, the second was professional.
A personal insight: Our view of the world is not the world
A personal insight was the value of questioning my assumptions about my life. I took a course called EST and learned that much of what I thought about why I lived my life the way I did was not really accurate. The experience was the start of a journey to look at the assumptions I had been making. I was introduced to the concept of a paradigm – that is, the assumptions and beliefs through which we look at life. Many of the big assumptions we make never get challenged. Sometimes paradigms are just how we look at a situation. For example, a car comes around a corner on a mountain road and is in your lane, barely swerving to miss you and yells “pig” at you. Just as you think to yell back “you’re the pig” you run into the pig on the other side of the corner. Questioning our paradigms is a form of double-loop learning, it is critical for us to be a different way.
At this point in my career I had been programming for about 13 years. Sometime the next year, after discovering a bug in code only I had ever been in, I asked myself the question “what was I doing when I put a bug in the system?” Two thoughts occurred to me immediately. The first was the recognition that I was putting bugs into my system no matter how often I said “I found a bug” as if a gremlin had put them in there. The second was “how could it have taken me 14 years to ask myself this question?” Although I was one of those 10x super programmers I had written many bugs in my lifetime. I am clear this obvious (once it had been made) observation had been obscured by my paradigm of programming. If I was putting bugs into my programs then perhaps I could stop doing that.
A professional insight
I started studying Edwards Deming in 1984. Looking back on it now, I can’t understand why it was so hard. Perhaps it was heritage of coming from a family of entrepreneurs and being brought up as someone who believed that with hard work someone can make things happen as they want to. As a personal aside, this was before I understood what the affects of growing up in a culture of no hope for the future can do to people. While I do believe people are responsible for their lives growing up in a family where you are told you won’t amount to anything has a big impact on people. If your entire community is this way, that’s an even harder ‘prison’ to break out of.
The foundation of Deming is a combination of leadership and systems-thinking. Systems-thinking tells us that one must look at as organization as a whole – that all of the parts in a system are inter-dependent upon each other. Deming took this further by suggesting that people’s behavior were either positively or negatively affected by the system they were in. That managers should not be railing against the people they were managing but needed to recognize that the system they were creating were affecting their people. The managers’ job was to improve the system.
Deming’s view was a paradigm shift
Deming’s view of management was a great paradigm shift. It is a shift that still has not taken place in most of the companies in the world. Agile has not yet embraced it yet as well. The two of these insights together led me to realize that when I was stuck I had to reflect on what I was doing. Perhaps the environment I was in was having a bigger impact on me than I realized. The mantra “work smarter not harder” did not seem to make as much sense anymore. I was working as smart and as hard as I could. I noticed that I started looking more closely at the environment I was. And I notices that instead of demanding more of myself, I could change the system within which I was working.