Tuesday, November 17, 2009
Principles 28-29
(Metropolitan Development as a Complex System: A New Approach to Sustainability, Judith E. Innes and
Monday, November 16, 2009
Thoughts about Thinking-Intentions Profile (TIP)
Last Saturday I was introduced to Thinking-Intentions Profile, a powerful coaching technique. The process is conducted in a group of 3-5 people and is divided into five stages:
1. The coached person clearly states his or her problem statement or some other issue.
2. Group coaches start asking direct questions.
3. The coached person steps out from the the discussion and the coaches discuss impressions as if the coached person is not in the room.
4. The coached person is re-invited into the discussion and is offered a list of solutions
5. The coached person is given an opportunity to select appropriate recommendation and commit to them.
Prime deliverable of the coaching session: validation or invalidation of the problem statement. If the coached person is able to validate or invalidate of her/his problem statement by the end of the coaching session, then the minimal goal of the session was achieved. In other word, it is important for the coached person to verify her/his perception in the actual context. By context I mean the social environment of the given individuals. Collective coaching represents a micro-model of such environment.
Thrust and objectivity of the coaches. Trust established between the coaches and the couched person helps the questions to be asked and answered as clear as possible. In other words, distrust between two parties creates distraction for the cognitive process. Such process should not tolerate any elusive statements and unspecified assumptions. Limited experience with this method does not allow me to say if the coached person should be taken out from his/her comfort zone. Perhaps such techniques can be useful when the group reaches a preliminary conclusion that the initial problem statement is invalid.
Discussion requires self-discipline form the coaches and tolerance from the coached person. The “out of the room”/ “behind back” simulation opens door for initial discussion. However, the substance of the discussion has to be sustained within or near acceptable border of the coached person. Otherwise, sharp criticism or insensitive comments may easily turn defensive mechanisms of the coached person ruining the purpose of the session. It is important that the coaches are able to skillfully balance on the border of acceptable and unacceptable criticism/comment/etc. Defining such borders by trail and error (forward and backward, expansion vs. contraction) is key in shaping physiological portrait of the coached person.
Solutions. This stage allows infinite number of possibilities and solutions. The level and degree of the relationship between the coaches and the coached person dictates the dynamics of this stage. Difference or similarities in age, gender, race, religion, language, culture, etc will define acceptable limits of this stage.
Commitment can be the most sensitive stage of the coaching. It is only a temporary or formal closure of the process. Once the process of coaching is started, it has a life of its own. Afterthoughts and reevaluations may take numerous iterations, time, effort and emotional energy. It is an important detail that some amateur coaches are not ready for. It is the biggest warning that should keep away such amateur coaches from taking this responsibility from the beginning. Another important detail is that the coached person may or may not commit to the suggested solutions. Depending on the situation, the coached person may not openly commit to some suggestions and tacitly reject other suggestions.
Lessons learned. I call it an emotional cycle. Thrust creates clarity. Trust also builds connection/bond. Clarity helps to identify problem and give suggestions. Commitment to some of the suggestions reinforces the bond. The bond cannot be broken if you want to maintain the thrust. The art of coaching is an ability to understand this dynamic and stay outside of it at the same time. It is similar to the skills of the successful doctor, who is able to remain empathetic and professional at the same time.
1. The coached person clearly states his or her problem statement or some other issue.
2. Group coaches start asking direct questions.
3. The coached person steps out from the the discussion and the coaches discuss impressions as if the coached person is not in the room.
4. The coached person is re-invited into the discussion and is offered a list of solutions
5. The coached person is given an opportunity to select appropriate recommendation and commit to them.
Prime deliverable of the coaching session: validation or invalidation of the problem statement. If the coached person is able to validate or invalidate of her/his problem statement by the end of the coaching session, then the minimal goal of the session was achieved. In other word, it is important for the coached person to verify her/his perception in the actual context. By context I mean the social environment of the given individuals. Collective coaching represents a micro-model of such environment.
Thrust and objectivity of the coaches. Trust established between the coaches and the couched person helps the questions to be asked and answered as clear as possible. In other words, distrust between two parties creates distraction for the cognitive process. Such process should not tolerate any elusive statements and unspecified assumptions. Limited experience with this method does not allow me to say if the coached person should be taken out from his/her comfort zone. Perhaps such techniques can be useful when the group reaches a preliminary conclusion that the initial problem statement is invalid.
Discussion requires self-discipline form the coaches and tolerance from the coached person. The “out of the room”/ “behind back” simulation opens door for initial discussion. However, the substance of the discussion has to be sustained within or near acceptable border of the coached person. Otherwise, sharp criticism or insensitive comments may easily turn defensive mechanisms of the coached person ruining the purpose of the session. It is important that the coaches are able to skillfully balance on the border of acceptable and unacceptable criticism/comment/etc. Defining such borders by trail and error (forward and backward, expansion vs. contraction) is key in shaping physiological portrait of the coached person.
Solutions. This stage allows infinite number of possibilities and solutions. The level and degree of the relationship between the coaches and the coached person dictates the dynamics of this stage. Difference or similarities in age, gender, race, religion, language, culture, etc will define acceptable limits of this stage.
Commitment can be the most sensitive stage of the coaching. It is only a temporary or formal closure of the process. Once the process of coaching is started, it has a life of its own. Afterthoughts and reevaluations may take numerous iterations, time, effort and emotional energy. It is an important detail that some amateur coaches are not ready for. It is the biggest warning that should keep away such amateur coaches from taking this responsibility from the beginning. Another important detail is that the coached person may or may not commit to the suggested solutions. Depending on the situation, the coached person may not openly commit to some suggestions and tacitly reject other suggestions.
Lessons learned. I call it an emotional cycle. Thrust creates clarity. Trust also builds connection/bond. Clarity helps to identify problem and give suggestions. Commitment to some of the suggestions reinforces the bond. The bond cannot be broken if you want to maintain the thrust. The art of coaching is an ability to understand this dynamic and stay outside of it at the same time. It is similar to the skills of the successful doctor, who is able to remain empathetic and professional at the same time.
Friday, November 13, 2009
Principle 27
"Do not plan a testing effort under the tacit assumption that no errors will be found" (Nancy Leveson, ESD.355)
Thursday, November 12, 2009
Brain-storming on my thesis "Founder-CEO succession"
Well I have one more year to go but I started to think about what topic should choose for my thesis. If we assume that Founder-CEO is a designer and an operator of a company. Company is a system. Founder-CEO knows how the system operates and how it behaves. Successor is a less experienced operator with only formal knowledge of the design of the system. What is the operator-system interface? How can we customize such interface for new operator? How will new operator learn about “behavior” of the system? What are key symptoms for system’s failures?
For now there are three initial and very raw thoughts.
Topic A: Roadmap for Founder-CEO succession: key symptoms and characteristics
(1) Successful transition
(2) Failed transition
Topic B: Metal models for Founder-CEO succession:
As in Good to Great (?) from level 1 to level 5 (?)
Topic C: Rule-based system as a model for Founder-CEO succession
For now there are three initial and very raw thoughts.
Topic A: Roadmap for Founder-CEO succession: key symptoms and characteristics
(1) Successful transition
(2) Failed transition
Topic B: Metal models for Founder-CEO succession:
As in Good to Great (?) from level 1 to level 5 (?)
Topic C: Rule-based system as a model for Founder-CEO succession
Wednesday, November 11, 2009
Thoughts on STAMP (Systems-Theoretic Accident Model and Processes)
New Accident Model for Engineering Safer Systems (Leveson, http://sunnyday.mit.edu/16.355/)
Symptom – “something that indicates the existence of something else”, Webster dictionary http://www.merriam-webster.com/dictionary/Symptom
It is my understanding that STAMP focuses on “constraints necessary to limit system behavior to safe changes and adaptations” (p.12). The model briefly touches upon a symptom as “the process leading to an accident (loss event)... described in terms of an adaptive feedback function that fails to maintain safety as performance changes over time to meet a complex set of goals and values” (p.26).
Reading this article I kept asking myself if complex systems are just “complex and often imperfect human artifact”, could one characterize symptoms of upcoming accidents? In other words, if we can classify accident factors (p.21), can we characterize accident symptoms?
The article briefly mentions that “proximity” to systems has changed over time (p. 14). In the past, operators had direct access to their systems and were able to get “direct physical feedback” from the system. More experienced operators could have indentified changes in the system’s behavior or “feel” erroneous symptoms (or what is called “detect maladaptive changes” p.26). Such ability usually came from “gut feeling” or intuition, which in reality was based on previous experience and undocumented assumptions.
Modern complex systems do not give us luxury of “feeling” the system. Moreover, post-mortem accident investigation may not reveal the symptoms that operators failed to recognize before that accident. Available factual data may not necessarily lead us to the correct interpretation of that data (p.26). But we may assume that such symptoms are usually non-linear, dynamics (with feedback loops) and adaptive to the environment.
It might sound as gross generalization, but I argue that STAMP should not only help to control the “beast”, but also explain “why and when the beast wants to get out from the cage”. I will take a risk of classifying such symptoms into three categories:
(1) external symptoms: symptoms that emerge as the result of external socio-technical environment (including change and adaptation of new safety constrains) that forces the system to adapt and lead to maladaptive changes. This can be categorized as expected and inevitable results if and when erroneous processes influence the system and its environment.
(2) interface symptoms: symptoms that emerge as the result of interaction between the system and its operator, the system and other systems. This is the closest we can get to the old way “feeling the vibration” the system and being able to get feedback from it.
(3) internal behavioral symptoms: unintended or unforeseen symptoms that can be best identified by the designer or peer-reviewers of the system. My intuition, tells me that this is the most difficult symptom to indentify and categorize (and decompose), which can be done only through extensive testing of the system.
Friday, November 6, 2009
Social Processes and Proofs of Theorem and Programs (Lipton, Perlis, DeMillo)
I have to admit that I included this article into my top ten list of articles read at MIT this semester.
“If mathematical process were really one of strict, logical progression, we would still be counting on our fingers.”
The article opened me a small window into the world of mathematicians. Our distorted understanding of the their world lead us to erroneous perception of how software programming “world” operate. In both of these worlds, social processes, which are not necessarily obvious to an outsider, are major driver in test and acceptance of new ideas, theorems, products and systems.
The authors argue that "A program is a human artifact, a real-life program is a complex human artifact; and any human artifact of sufficient size and complexity is imperfect.” Thus people are not able to “create perfect mechanisms and verification process is nothing but a model of believability”. As the result, software programs have to be reliable but not necessarily perfect.
A conclusion that can be drawn from the article is that in software engineering social processes have to more visible and acceptable form of test and acceptance. By social processes I mean per-reviews, beta-user reviews and end-user reviews. These processes may not completely verify the system, but encounter the system with the real-world environment and force the designers of the system to adopt it.
“If mathematical process were really one of strict, logical progression, we would still be counting on our fingers.”
The article opened me a small window into the world of mathematicians. Our distorted understanding of the their world lead us to erroneous perception of how software programming “world” operate. In both of these worlds, social processes, which are not necessarily obvious to an outsider, are major driver in test and acceptance of new ideas, theorems, products and systems.
The authors argue that "A program is a human artifact, a real-life program is a complex human artifact; and any human artifact of sufficient size and complexity is imperfect.” Thus people are not able to “create perfect mechanisms and verification process is nothing but a model of believability”. As the result, software programs have to be reliable but not necessarily perfect.
A conclusion that can be drawn from the article is that in software engineering social processes have to more visible and acceptable form of test and acceptance. By social processes I mean per-reviews, beta-user reviews and end-user reviews. These processes may not completely verify the system, but encounter the system with the real-world environment and force the designers of the system to adopt it.
Bill Warner lecture on Intentions and Inventions (ESD.34, MIT, November 6, 2009
"Transform space 1: I intend to help people tell THEIR story. This is a timeless intention. Transform into timeless human space. Intentions are main drivers. People have multiple and certain intentions. There is one primary timeless intention. This intention is making people tell their stories.
Intention domain (language of intention) - ideas, simple language, make yourself slowdown (this will transform you into different space). Making energy going out from you: "the light that comes out".
Invention domain - what you can see or make. The intent is encoded in the invention. It is not visible, only the person who invented a system can tell the initial intent. The trick of reverse engineering - look how you FEEL when you used the product. You will get closer, but still have fragment picture of the intent.
Beliefs domain - system design requires philosophy all the time. The belief domain is something that connects or blocks intentions from inventions.
Transform space 2: I intend to help people follow their heart.
As long as you have timelessness, it is timeless intention. Everything that is time relevant has to do with invention. It is very easy to invent from primary intention, because you do it for the people who have needs, you really care to commit and solve this problem. It is not driven by your EGO. Almost all the time "your people" are not the one who pay for the product (indirect flow).
Google Inc. is the biggest "INTENTION FLOW" machine ever created in the human history.
Transform space 3: I intend to feel closer together.
You are an architect and you are an architecture.
Your product goal is to help other people.
Your product form is human body, but run on Human Nature 1.0 (a constant over time).
Beliefs are changing over time.
Intention flowing = helping
We OVER-INVENT and UNDER-INTENT.
Intent gives wide range for inventions."
Intention domain (language of intention) - ideas, simple language, make yourself slowdown (this will transform you into different space). Making energy going out from you: "the light that comes out".
Invention domain - what you can see or make. The intent is encoded in the invention. It is not visible, only the person who invented a system can tell the initial intent. The trick of reverse engineering - look how you FEEL when you used the product. You will get closer, but still have fragment picture of the intent.
Beliefs domain - system design requires philosophy all the time. The belief domain is something that connects or blocks intentions from inventions.
Transform space 2: I intend to help people follow their heart.
As long as you have timelessness, it is timeless intention. Everything that is time relevant has to do with invention. It is very easy to invent from primary intention, because you do it for the people who have needs, you really care to commit and solve this problem. It is not driven by your EGO. Almost all the time "your people" are not the one who pay for the product (indirect flow).
Google Inc. is the biggest "INTENTION FLOW" machine ever created in the human history.
Transform space 3: I intend to feel closer together.
You are an architect and you are an architecture.
Your product goal is to help other people.
Your product form is human body, but run on Human Nature 1.0 (a constant over time).
Beliefs are changing over time.
Intention flowing = helping
We OVER-INVENT and UNDER-INTENT.
Intent gives wide range for inventions."
Thursday, November 5, 2009
Principle 26
"1. Capabilities, Not Just Strategy.
2. Pull, Don't Just Push.
3. Scope, Not Just Scale.
4. Flexibility, Not Just Efficiency.
5. Platforms, Not Just Products.
6. Services, Not Just Products (or Platforms)"
(Michael Cusumano, lecture "In Search of Best Practice: Enduring Ideas in Strategy, Innovation and Technology Management" on the 24th Forum on COCOMO and System/Software Cost Modeling), November 5, 2009.
Subscribe to:
Posts (Atom)