The Business of Contradictions

Found this very interesting link by Jeff Sutherland, famed Scrum co-founder and trainer who I took my certification class from, on a paper published by Harvard Business Review. The paper is titled “The Contradictions That Drive Toyota’s Success”. One of the paper’s authors is Hirotaka Takeuchi who co-wrote another famous paper in HBR that was the inspiration and impetus for the Scrum project management movement and which I wrote about before.

As the paper states:

Quite simply, TPS is a “hard” innovation that allows the company to keep improving the way it manufactures vehicles; in addition, Toyota has mastered a “soft” innovation that relates to corporate culture. The company succeeds, we believe, because it creates contradictions and paradoxes in many aspects of organizational life. Employees have to operate in a culture where they constantly grapple with challenges and problems and must come up with fresh ideas. That’s why Toyota constantly gets better. The hard and the soft innovations work in tandem. Like two wheels on a shaft that bear equal weight, together they move the company forward. Toyota’s culture of contradictions plays as important a role in its success as TPS does, but rivals and experts have so far overlooked it.

Toyota believes that efficiency alone cannot guarantee success. Make no mistake: No company practices Taylorism better than Toyota does. What’s different is that the company views employees not just as pairs of hands but as knowledge workers who accumulate chie—the wisdom of experience—on the company’s front lines. Toyota therefore invests heavily in people and organizational capabilities, and it garners ideas from everyone and everywhere: the shop floor, the office, the field.

At the same time, studies of human cognition show that when people grapple with opposing insights, they understand the different aspects of an issue and come up with effective solutions. So Toyota deliberately fosters contradictory viewpoints within the organization and challenges employees to find solutions by transcending differences rather than resorting to compromises. This culture of tensions generates innovative ideas that Toyota implements to pull ahead of competitors, both incrementally and radically.

I think much of Toyota’s ability to understand and overcome contradictions is due to the cultural roots of Eastern thinking, which really never viewed contradictions like the West did starting with the Greek thinkers like Aristotle. His legacy of the “Law of the Excluded Middle” permeated the whole of Western thinking and much of the reductionist, logical system on which the sciences and systematic process thinking that industry still drives on.

The Japanese on the other hand do not view contradictions as things to avoid, but rather like the Yin and Yang, as just different manifestations or phenomenon of the natural world which when viewed as a whole, is really just a unity of oppositions. Thus, this thought process would enable the company culture of Toyota to embrace, temper and balance opposing contradictory forces.

The paper found 6 ways Toyota unifies contradictory tendencies:

1. Toyota moves slowly, yet it takes big leaps.
2. Toyota grows steadily, yet it is a paranoid company.
3. Toyota’s operations are efficient, but it uses employees’ time in seemingly wasteful ways.
4. Toyota is frugal, but it splurges on key areas.
5. Toyota insists internal communications be simple, yet it builds complex social networks.
6. Toyota has a strict hierarchy, but it gives employees freedom to push back.

Traditional Western management practices would consider a company running under such an ideological platform as a badly managed company, but that's exactly why Toyota succeeds, because embracing and unifying such contradictory tendencies acknowledges first, that contradictions are a natural way of life (which it is), and that second, adopting such a mindset would allow a corporation to manage their organization in a more dynamic and fluid way. This will prevent complacency and continuously challenge an organization to push it self, whereas “most enterprises stop growing because they stick to processes and practices their past successes have generated.”

But one may mistake such a notion as giving a company license to dispense with all systematic and rigorous processes in favor of chaos, when on the contrary companies “must teach employees how to deal with problems rigorously and systematically, or they won’t be able to harness the power of contradictions”. Again, that’s to embrace, temper and manage the rigorous process and creative fluidity.

Summary of Toyota’s approach:

Three Forces of Expansion

Three forces of expansion lead the company to instigate change and improvement

• Impossible goals
• Local customization
• Experimentation

Three Forces of Integration

Three forces of integration stabilize the company’s expansion and transformation

• Values from the founders
• Up-and-in people management
• Open communication

Characteristics of Toyota Executives

• Willingness to listen and learn from others
• Enthusiasm for constantly making improvements
• Comfort with working in teams
• Ability to take action quickly to solve a problem

The banalities of the creative generalist

I discovered this pretty interesting blog posting about the notion of being a creative generalist. He describes the notion that:

Nothing can substitute for depth of analysis, and there's proven value in specialization – it's what education, career paths, scientific research, and technological innovation are built on – but generalism is a secret talent. With so much complex information, fragmented in so many ways and developing faster and faster, it is increasingly important to have generalists around to make sense of it all, of the big picture. People who appreciate diversity, who are in the know about the wider world and who understand how things interact are invaluable observers, matchmakers, and pioneers of the intersectional ideas so vital for success in today’s knowledge economy, conceptual age, and global community.

But what exactly do generalists do? That’s the question most often asked of me and it’s not an easy one to answer. By definition, generalists tend not to focus (actually, they do focus but just not to the extent that specialists do), they don’t often travel in groups (lacking common associations, designations, and unions), and their shape-shifting versatility changes them frequently. But they are definable and there most certainly are essential traits and skills inherent to them.

It's a pretty long post, that's peppered with anecdotes and quotes from famous writers, thinkers, and business people both past and contemporary who have been known to exemplify broad generalist thinking that was done in a very creative manner. One particularly good example, was the inclusion of the writer Frans Johansson, who is the author of the famous book Medici Effect: What Elephants and Epidemics Can Teach Us About Innovation.

A great example from the book, was the French telecom engineer whose passion for entomology led to close observation of ants that suggested algorithms now widely used to route traffic around the Internet. This is certainly a prime example of creative, generalist epiphany at its finest. Though while I'm a believer and a strong advocate for adopting a creative generalist approach to solving business, as well as any problem, I feel there is the danger inherent to this type of thinking and that is if it is pursued unchecked and irrationally, it succumbs to triteness and banalities. Even worse, it can lead to sloppy thinking.

Here's my rationale:

1. The majority of people still do not adopt proper analytical and logical skills to problems. Its no secret that this country suffers from a lack of scientists and engineers, and is why so much of these functions are imported in from other countries or outsourced. But underlying this problems is not such much a shortage of technical skills and education, as bad as that has gotten, but really is a lack on educational institutions teaching of how to think critically, analytically and logically not only in science and technology, but in other disciplines as well. Having people adopt a more holistic, generalist view without proper rigorous analysis is dangerous. In addition, the whole idea of "creativity" if not defined properly become merely intellectual fluff.
2. Like those infamous "team-building" exercises that have become popular in corporate America, where you have employees engage in goofy exercises with each other, in order to spark creativity and teamwork that has now become a source of dread for most employees, the same could happen if you try to artificially induce creative generalist thinking. The example of the French telecom engineer from Johansson's book was no doubt a combination of years of study and passionate pursuit of different fields of study, that converged at some serendipitous point and lead that engineer to his extraordinary discovery. I think if you try to hard to artificially induce such discoveries, you run into the problems of making the process banal and even drudgery much like the team building exercises. Google is a prime example recently of company known for having a creative work environment, yet despite this has had an exodus of key employees recently due to boredom.
   
3. Again, like the example of the French telecom engineer just mentioned, it seems we get enthralled by what seems to be a spontaneous spark of creative genius that leads to such incredible discoveries, and forgot that many such individuals got to that point from years of research and study, and probably toiled for years with painful detail to data and analysis. Like Edison said, its "1% inspiration and 99% perspiration" and I think its important to emphasize the hard work, dedication and attention to details it takes to achieve such insights as well as being more creative and holistic in your thinking.

Nevertheless, the blog was an excellent read and I recommend the site and thought I wholeheartedly agree with the sentiments and pursuit of being a creative generalists, I do so with the above caveats in mind. I actually go further then the author and believe that in order to compete in today's competitive and intense global world, that you have to have subject matter expertise in a few areas AND the ability to generalize and think creatively through problems.

An Ontological Critique of Object Oriented Programming

Had a very interesting conversation with a work colleague Rudy yesterday, which started off about linguistics, philosophy and mathematics [yes, we're geeky software developers!], which ignited a observation I had a while back ago on the similarity of Wittgenstein's later philosophy to object oriented programming. But thinking a little more deeply about this and referring back to some philosophical literature, I think Wittgenstein philosophy is actually critical of the basic tenets of OOP and would incorporate a methodology that may actually better map to the real world.

There's no doubt that the complexity of software construction has increased at an almost exponential level in the past decade or so, especially with the explosion of the internet and our societies increasing reliance of computer software to manage this. This has lead a push to create more higher levels of abstraction in programming languages so that developers can think in more natural metaphorical manner with respect to things in code that do things or map to things in the real world. Therefore, let's say we are building software to automate the manufacturing of automobiles in a plant, using an object oriented language we could model the notion of a car with a car object and the action to which this car object interacts with methods associated with this object. A pseudo-Java like implementation would look like the following:

public class Car
{
  void Start()
}

This fulfills one of the three basic tenets of OOP, namely encapsulation since the data structures and the algorithms that act on those data in fully encapsulated in the object. The others would be inheritance, whereby you could derive a particular type of car from a base car type, such as a SportsCar object which would share the same characteristics as all cars, but have distinguishing features such as a bigger engine, sporty chassis, etc., and the need to be able to start in order to run like its base car type. And last would be polymorphisms, since the Start() method could be used in a derived object as if it were the base object.

In the older procedural programming method, you would typically have to define a lot of separate functions and a long series of select case statements to achieve the same results. This proved to be more time consuming and error prone, hence the need to create better levels of abstractions.

But the above is actually quite grounded in the notion of classical categorization. As Booch states in "Object Oriented Analysis and Design" that classical categorization "comes to us first from Plato, and then from Aristotle... the classical approach uses related properties as the criteria for sameness among objects. Specifically, one can divide objects into disjoint sets depending upon the presence or absence of a particular property".

This would agree with the basic outlines of OOP just articulated, for the car class would define in an abstract manner what all possible object of that class would be like. There is a set of necessary and sufficient properties to distinguish if an object belongs to a certain category. It either does or does not; there are no graded boundaries. It is a matter of two-valued logic: a statement of type "object x belongs to the category X" is either true or false. In Aristotle's terms this is the essence of a category.

The implications of this view, are that objects are entities that are suppose to correspond to the external world, are in fact internal representations of the external realities. In other words, real world objects are mere shadows of the classes, and we are seeing only the shadows, and mistakingly taking them to be real, to put it in Plato's "Allegory of the Cave" theme. Maybe this is why despite progresses in software engineering such as OOP, we are still delivering buggy software over budget, and not on time is because our notions of real world objects and their interactions are mere "shadows" of classes!

This is where Wittgenstein comes in, as he was one of the notable figures in Western philosophy that reacted strongly against this ideology (Nietzsche was another). According to Wittgenstein, objects would not be some outcomes or mere "shadows" of Platonic classes, but rather that they are entities that come in "families". A family is a set of real objects that would "resemble" each other from various points of view. For example, a "sports car" is a set of all the objects that we call by that name. But we group together these objects in one single family, not because they share some common essence, but out of historic or contextual perspectives.

In OOP terms, buttons and windows on a web page are not derived from some predetermined class that force you to modify it in very specific ways, but would belong to a "family" of buttons and windows that resemble the function or features we seek. We know this because historically we empirically witnessed what a family of buttons and windows could do [for example, buttons and windows behave quite differently on a web form then they do on a client/server form] and our particular context would determine what kinds of methods to utilize for these dynamic objects to interact [e.g., I have a Flash form on a web page that have buttons and windows that resemble the family of client/server applications, but will interact through a web page. Thus, I will have buttons and windows incorporating aspects of both].

It's interesting to note that recent developments in software design such as Aspect Oriented Programming seem to be gravitating towards this Wittgensteinian mindset. AOP for example, has the notion of breaking units of code down such as they overlap in functionality as little as possible. As such, a typical OOP system provides the packages, classes and methods to support the separation of encapsulation and concerns into single focus. But as anyone who has designed and programmed OOP knows that not all "concerns" can be so neatly encapsulated. This is where AOP proposes the notion of "cross cutting" concerns. A Wikipedia example uses the notion of a logging module that would be a cross-cutting concern since "a logging strategy necessarily affects every single logged part of the system. Logging thereby crosscuts all logged classes and methods".

With this in mind, one can see how this very much maps to Wittgenstein's notion of family resemblances, as each cross-cutting concern "resemble" each concern from various points of view, and that view is how well it maps to the historical and contextual perspective of the person(s) building the software system.

I have only reached the tip of the iceberg with regard to this, and is interesting to see how my studies in philosophy actually map to something I do for a living. :-)