I remember reading “The Fractal Geometry of Nature” by Benoit Mandelbrot many years ago. Mandelbrot made chaos cool. Since then the term “chaos” has been picked up by many disciplines, not the least of which is software product development. Often, chaos is the term we use to describe a messy, complex situation that we do not fully understand but that is required for creativity. Perhaps our perception of chaos is simply a lack of understanding of the fundamental geometric shape that can elegantly describe that creative process. Is there a fundamental geometry for problem solving and the creativity that comes with it?
Prior to Mandelbrot’s work on fractals, generating interesting graphical images by computer was extraordinarily processor intensive. Taking inspiration from Mandelbrot, Loren Carpenter realized he could create complex and realistic graphical simulations of nature using mere triangles, thereby greatly reducing the computation requirements. If you have not seen the movie he presented at SIGGRAPH in 1980, check it out here. Imagine creating all that from just triangles! This breakthrough was a turning point in the computer industry.
Isn’t problem solving another artifact of nature just like natural landscapes? Might not there be a fundamental fractal geometry for problem solving as well? In previous blogs, I have described an 8-step problem-solving process (9-steps by Enneagram count.) I often invoke an 8-section wheel to describe the process. I imagine that there is another 8- section wheel connected to each section of the main wheel, and another to each section of that, and so on in recursive fashion. This structure might form a problem-solving fractal.
Take the simple example of starting with step 1, defining the problem. At step 1, the problem is that “the Problem” is not yet defined. We need to find someone to clearly articulate that problem. We need to consider various ideas for how we might articulate the problem. We need to understand the impact of any articulation and the pros/cons of such articulation. We need to settle on one articulation and to make sure that everyone is in agreement with that articulation. We need to move on and use that articulation to drive the problem-solving process. And, we need to review that articulation periodically in order to ensure that it remains the correct articulation in light of any new data. In this fashion, we just used the entire problem-solving process to describe one section of the overall process.
Having an awareness of the scalability of the problem-solving process helps us better understand the ebbs and flows of the process and helps keep the team moving forward through the process. And, like using triangles for graphical simulation, it can be used to efficiently address the current problem confronting you, your team or your company, regardless of scale.
_________________________________________
Matt Schlegel remains a fan of Benoit Mandelbrot and recently enjoyed reading Mandelbrot’s book on markets entitled, The (Mis)behavior of Markets.
More...
Monday, January 18, 2010
Saturday, January 9, 2010
Problem Solving, the Brain, and the Enneagram [Matt Schlegel]
On the topic of problem solving and the brain, I want to bring to your attention a fascinating book called Personality and the Brain written by a local computer scientist and entrepreneur, Peter Savich. Peter became interested in the Enneagram and realized that there must be a link between how the brain operates and the core modality described by the Enneagram. His book makes a very compelling case for this link.
Peter asserts that there are two parts of the brain that drive personality, an old brain component, the amygdala, and a new brain component, the prefrontal cortex (PFC). The amygdala is in essence the fear processor, and the PFC is the optimism/pessimism processor. He goes on to describe how each of these brain components has a right side and a left side, corresponding with the right side and left side of your brain. And, each half invokes dominant characteristics. For instance, one side of your amygdala is your fear-aware processor (the flight processor) and the other is your fear-unaware processor (the fight processor). Likewise, one side of the PFC is your optimism processor (glass half full) and one side is your pessimism processor (glass half empty).
Just like there are 3 states of handedness, right-handed, left-handed or ambidextrous, Peter asserts that both the amygdala and the PFC have three dominant modal states, and it is the combination of these states that give us the 9 states of the Enneagram. How cool is that! He goes on to examine studies from the body of neuroscience literature to show how pathologies in these brain components accentuate or diminish the behaviors that map to the behaviors described by the Enneagram, thereby making a very compelling case for connecting the dots between the brain and the Enneagram. I cannot thank Peter enough for developing and publishing this fascinating thesis.
With the help of this understanding, we are able to connect the dots from 1) a problem-solving process described by the Enneagram, to 2) the behaviors and capabilities important for each phase of that problem-solving process, to 3) our own unique set of behaviors and capabilities and, finally, to 4) our brain which governs those behaviors and capabilities. Just like the brain determines whether we end up being right-handed or left-handed, it also plays an important role in how we contribute to the problem-solving process.
____________________________________
According to Peter Savich’s framework, Matt Schlegel has an amygdala that is fear-aware dominant and a prefrontal cortex that is pessimistic processor dominant. This makes Matt uniquely suited for that part of the problem-solving process he characterizes as “finding the path of least danger.”
More...
Peter asserts that there are two parts of the brain that drive personality, an old brain component, the amygdala, and a new brain component, the prefrontal cortex (PFC). The amygdala is in essence the fear processor, and the PFC is the optimism/pessimism processor. He goes on to describe how each of these brain components has a right side and a left side, corresponding with the right side and left side of your brain. And, each half invokes dominant characteristics. For instance, one side of your amygdala is your fear-aware processor (the flight processor) and the other is your fear-unaware processor (the fight processor). Likewise, one side of the PFC is your optimism processor (glass half full) and one side is your pessimism processor (glass half empty).
Just like there are 3 states of handedness, right-handed, left-handed or ambidextrous, Peter asserts that both the amygdala and the PFC have three dominant modal states, and it is the combination of these states that give us the 9 states of the Enneagram. How cool is that! He goes on to examine studies from the body of neuroscience literature to show how pathologies in these brain components accentuate or diminish the behaviors that map to the behaviors described by the Enneagram, thereby making a very compelling case for connecting the dots between the brain and the Enneagram. I cannot thank Peter enough for developing and publishing this fascinating thesis.
With the help of this understanding, we are able to connect the dots from 1) a problem-solving process described by the Enneagram, to 2) the behaviors and capabilities important for each phase of that problem-solving process, to 3) our own unique set of behaviors and capabilities and, finally, to 4) our brain which governs those behaviors and capabilities. Just like the brain determines whether we end up being right-handed or left-handed, it also plays an important role in how we contribute to the problem-solving process.
____________________________________
According to Peter Savich’s framework, Matt Schlegel has an amygdala that is fear-aware dominant and a prefrontal cortex that is pessimistic processor dominant. This makes Matt uniquely suited for that part of the problem-solving process he characterizes as “finding the path of least danger.”
More...
Saturday, January 2, 2010
Take stock of your problem-solving talents [Matt Schlegel]
In the last blog, I wrote about a talented right-handed pitcher. When it comes to throwing a ball, it is pretty easy for most of us to figure out which arm throws best. But what about problem solving? Each of us has a style that lends itself to contributing to the problem-solving process. How do we figure out what that style is and how we best contribute?
As you have read through the previous blogs describing the problem-solving process (and I hope that if you are reading this you will have done that), you may have been thinking to yourself about how you contribute at each phase in the process. You may have recognized those areas in which you feel you are strong or which you enjoy the most. Those are important clues in understanding where your personal talents lie when it comes to solving problems.
If we accept the 8 steps of the problem-solving process and acknowledge that as individuals we are strong in a few of the steps but perhaps not all of them, what happens when as individuals we attempt to solve problems? I can tell you from personal experience, I will focus on the steps in which I am strong and minimize or skip over the steps where I am weak. Here is how I would characterize myself: Firstly, I am not one to even make a big deal about problems. I may ignore them, live with them or tough them out. On the other hand, occasionally I get a “brilliant” idea that I want to try out. This idea will be a solution to a problem that I may or may not actually have. Yet, I will be so enthused about the idea that I will move forward and implement it, and I will be tenacious in doing so. After implementation, I will take steps to measure how effective the idea is in order to determine if it performs as I envisioned. At this point I usually stop and move on to the next thing.
So, which steps of the problem-solving process are my strengths and which are the weaknesses? Let’s start with weaknesses. I did not start off by having a clear problem statement, nor did I have any goals. I did not enlist the help of others. I did not consider many ideas, just the one that popped into my head. I did not explicitly analyze my idea, but there was the implicit analysis that my brain did to come up with the idea in the first place. I got very enthused about the idea, but I did not necessarily get others enthused about it. And, I worked hard to implement the idea and went back to see how well it worked. From this, you can see that I am personally weak in steps 1, 2, 3, 4, and 6 of the process. On the other hand, I tend to be strong on steps 5, 7 and 8. Good to know.
And, dear reader, in terms of the problem-solving process, which steps do you identify in yourself as strengths? I encourage each of you to take stock of your strengths and understand how you best contribute to the problem-solving process.
Matt Schlegel lives in a household of 5 people, each contributes differently to the problem-solving process and two are teenagers. Matt’s keen awareness of his own problem-solving inadequacies may come from the constant and frank reminders of these inadequacies voiced by these teenagers. Kindly, his wife reminds him of his strengths.
More...
As you have read through the previous blogs describing the problem-solving process (and I hope that if you are reading this you will have done that), you may have been thinking to yourself about how you contribute at each phase in the process. You may have recognized those areas in which you feel you are strong or which you enjoy the most. Those are important clues in understanding where your personal talents lie when it comes to solving problems.
If we accept the 8 steps of the problem-solving process and acknowledge that as individuals we are strong in a few of the steps but perhaps not all of them, what happens when as individuals we attempt to solve problems? I can tell you from personal experience, I will focus on the steps in which I am strong and minimize or skip over the steps where I am weak. Here is how I would characterize myself: Firstly, I am not one to even make a big deal about problems. I may ignore them, live with them or tough them out. On the other hand, occasionally I get a “brilliant” idea that I want to try out. This idea will be a solution to a problem that I may or may not actually have. Yet, I will be so enthused about the idea that I will move forward and implement it, and I will be tenacious in doing so. After implementation, I will take steps to measure how effective the idea is in order to determine if it performs as I envisioned. At this point I usually stop and move on to the next thing.
So, which steps of the problem-solving process are my strengths and which are the weaknesses? Let’s start with weaknesses. I did not start off by having a clear problem statement, nor did I have any goals. I did not enlist the help of others. I did not consider many ideas, just the one that popped into my head. I did not explicitly analyze my idea, but there was the implicit analysis that my brain did to come up with the idea in the first place. I got very enthused about the idea, but I did not necessarily get others enthused about it. And, I worked hard to implement the idea and went back to see how well it worked. From this, you can see that I am personally weak in steps 1, 2, 3, 4, and 6 of the process. On the other hand, I tend to be strong on steps 5, 7 and 8. Good to know.
And, dear reader, in terms of the problem-solving process, which steps do you identify in yourself as strengths? I encourage each of you to take stock of your strengths and understand how you best contribute to the problem-solving process.
Matt Schlegel lives in a household of 5 people, each contributes differently to the problem-solving process and two are teenagers. Matt’s keen awareness of his own problem-solving inadequacies may come from the constant and frank reminders of these inadequacies voiced by these teenagers. Kindly, his wife reminds him of his strengths.
More...
Wednesday, December 9, 2009
Comments Are No Longer Moderated [Robert Lasater]
Comments are no longer moderated on this blog. That means you can enter a comment and it should appear immediately. You will have to pass a Turing Test (more accurately, a CAPTCHA test) to demonstrate you are indeed a human.
More...
More...
Sunday, December 6, 2009
Newton’s 4th Law (of Meetings) [Tanya Berezin]
Some time ago I was taking over for a project manager who was leaving. We had a couple of days for the transition and we talked about all the things you’d expect: the current state of things, upcoming milestones, strengths and weaknesses of the team, partner relationships, and so forth. And, of course, she forwarded me the invitations to all of the standing meetings for the project.
There were daily meetings (two), weekly meetings (three or four), and monthly meetings (who’s counting!). I couldn’t attend them all even if I wanted to. It was impossible to know which meetings were important, they mostly sounded alike. I knew I had to clear my own and the team’s calendars so we could get work done.
I created a spreadsheet listing all meetings I knew about. For each, I asked the team to fill out several pieces of information:
1. What is the objective of the meeting?
2. What is the typical agenda?
3. Who runs the meeting? Who attends?
4. What is the frequency and duration of the meeting?
I saw three things, as I expected: more meetings got added to the spreadsheet – clearly, I didn’t catch every single one in my review; for many of the meetings no one could crisply state the objective; and the agendas and attendee lists tended to overlap quite heavily. Once I published the resulting list, it became clear to everyone that things needed to change.
I developed a proposal for the meeting structure going forward: removed obsolete meetings, consolidated repetitive ones, shortened the remaining ones, and trimmed the invitee lists. This, with some minor changes, was adopted by the team.
Newton’s first law of motion is: every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it. Substitute “meeting” for “object” and “recurring” for “state of uniform motion” and you get what I call Newton’s 4th law – a recurring meeting, once established, tends to go on forever, unless someone starts asking questions.
No one intends to create unnecessary or repetitive meetings – each one seems like a good idea at the time. After a while they outlive their usefulness but no one takes the trouble to notice and cancel them, so people continue to show up. If this is happening on your project, ask the questions above. You might gain a few hours to get something done.
Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin
More...
There were daily meetings (two), weekly meetings (three or four), and monthly meetings (who’s counting!). I couldn’t attend them all even if I wanted to. It was impossible to know which meetings were important, they mostly sounded alike. I knew I had to clear my own and the team’s calendars so we could get work done.
I created a spreadsheet listing all meetings I knew about. For each, I asked the team to fill out several pieces of information:
1. What is the objective of the meeting?
2. What is the typical agenda?
3. Who runs the meeting? Who attends?
4. What is the frequency and duration of the meeting?
I saw three things, as I expected: more meetings got added to the spreadsheet – clearly, I didn’t catch every single one in my review; for many of the meetings no one could crisply state the objective; and the agendas and attendee lists tended to overlap quite heavily. Once I published the resulting list, it became clear to everyone that things needed to change.
I developed a proposal for the meeting structure going forward: removed obsolete meetings, consolidated repetitive ones, shortened the remaining ones, and trimmed the invitee lists. This, with some minor changes, was adopted by the team.
Newton’s first law of motion is: every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it. Substitute “meeting” for “object” and “recurring” for “state of uniform motion” and you get what I call Newton’s 4th law – a recurring meeting, once established, tends to go on forever, unless someone starts asking questions.
No one intends to create unnecessary or repetitive meetings – each one seems like a good idea at the time. After a while they outlive their usefulness but no one takes the trouble to notice and cancel them, so people continue to show up. If this is happening on your project, ask the questions above. You might gain a few hours to get something done.
Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin
More...
Friday, November 27, 2009
Finding the Problem-Solving Super Highway [Matt Schlegel]
Returning to Marcus Buckingham’s book “First, Break All the Rules,” I delighted in his analogy of people’s strengths and weaknesses as super highways and country lanes in the wiring of their brains. I subscribe to this line of thinking; however, it leaves me wanting for a way to identify predictably the super highways and bumpy country lanes of candidate team members, be they for a problem-solving initiative or a spot on a development team. So began a search for a navigation tool to find those super highways and avoid the country lanes.
Many people subscribe to the romantic notion that if you try hard enough you can do anything. I don’t. There are things you are naturally good at and things that you are not. Further, there are things that you are passionate about and things that you are not. The magic occurs when there is alignment of your passions and your natural talents.
Let’s say that you are John Rittman, Head Coach for Stanford’s softball team. And, let’s say that your ace pitcher throws right handed. The problem is that the teams in your division hit much better against right-handed pitchers than against left-handed pitchers. What is the solution to this problem? Are you going to tell your right-handed ace to start practicing with her left hand because if she tries hard enough she can be as great with her left hand as she is with her right hand? Or, are you going to let your ace right hander continue to hone her skills as a right hander and go out and find some left-handed talent to round out the roster?
I am right handed, and last weekend I went out and practiced throwing with my left hand. It is remarkable to me how absolutely inept I am at throwing with my left hand compared with the right. Both accuracy and power suffer, as well as my whole body feels off balance. My brain definitely applies its resources to giving me some competence at throwing right handed while neglecting that capability with my left hand. My right hand definitely got the super highway to my left hand’s country lane.
What we need is a navigation device that can help our teams navigate the problem- solving process. This device needs to not only find the shortest path, but keep us on the super highways whenever possible. I will describe such a device in the next few blogs.
As an engineering manager, one of Matt Schlegel’s most satisfying roles was finding the alignment between people’s natural talents and their passions, and guiding them towards roles in which they could be fabulously successful.
More...
Many people subscribe to the romantic notion that if you try hard enough you can do anything. I don’t. There are things you are naturally good at and things that you are not. Further, there are things that you are passionate about and things that you are not. The magic occurs when there is alignment of your passions and your natural talents.
Let’s say that you are John Rittman, Head Coach for Stanford’s softball team. And, let’s say that your ace pitcher throws right handed. The problem is that the teams in your division hit much better against right-handed pitchers than against left-handed pitchers. What is the solution to this problem? Are you going to tell your right-handed ace to start practicing with her left hand because if she tries hard enough she can be as great with her left hand as she is with her right hand? Or, are you going to let your ace right hander continue to hone her skills as a right hander and go out and find some left-handed talent to round out the roster?
I am right handed, and last weekend I went out and practiced throwing with my left hand. It is remarkable to me how absolutely inept I am at throwing with my left hand compared with the right. Both accuracy and power suffer, as well as my whole body feels off balance. My brain definitely applies its resources to giving me some competence at throwing right handed while neglecting that capability with my left hand. My right hand definitely got the super highway to my left hand’s country lane.
What we need is a navigation device that can help our teams navigate the problem- solving process. This device needs to not only find the shortest path, but keep us on the super highways whenever possible. I will describe such a device in the next few blogs.
As an engineering manager, one of Matt Schlegel’s most satisfying roles was finding the alignment between people’s natural talents and their passions, and guiding them towards roles in which they could be fabulously successful.
More...
Wednesday, October 21, 2009
Managing Risk in IT organizations [John Levy]
Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy.
1. IT Operations and Development must be managed differently. Development is Engineering and must be managed as such. Outsourcing of Development does not convert it into Operations – it is still Engineering.
2. Measurements for IT Operations and Engineering (Development) are different: Development should be measured based on expected ROI plus certain strategic factors; Operations should be measured based on predictability of spending and certain Quality of Service measures, along with regular and consistent assessment of relevance of those measures to the business. [This is analogous to market risk in financial portfolios]
3. Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy. In addition, the probability of future failures remains undiminished so long as the management shortcomings are not addressed.
4. The cost of failure in IT Development always exceeds the allocated budget for the activity, because failure has consequences beyond the immediate failed project, both for people and for other projects. For example, one major factor of risk that increases when a development project fails is the loss of key people. It is rare to find IT management mitigating this risk immediately on learning of a development failure.
5. Failures and losses in IT Operations usually involve either directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less known, to Operations managers. [Cf. Failure in Microsoft-provided services for Sidekick smart phones, Oct., 2009] [This is analogous to credit or counterparty risk in financial transactions]
6. IT management should be able to communicate to top management the nature of the tradeoffs in IT Operations and Development, so that strategic implications of decisions in IT are well understood at the top level. This means that financial factors must not be the exclusive determinants of IT decisions. The CIO should not report through the CFO.
7. Multi-year planning is essential for both IT Operations and Development. A roadmap for rationalization and integration of resources and services is necessary, even if it must be revised multiple times per year as new equipment and services are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.
Above thoughts on IT management are based on my recent experiences at a client company and were triggered by a paper, “Risk Management Failures” by Prof. Rene Stultz, Fisher College of Business, Ohio State University, published by Cornerstone Research http://www.cornerstone.com/
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on high-tech management, Get Out of the Way, is due out in 2009. More info is at http://johnlevyconsulting.com
More...
1. IT Operations and Development must be managed differently. Development is Engineering and must be managed as such. Outsourcing of Development does not convert it into Operations – it is still Engineering.
2. Measurements for IT Operations and Engineering (Development) are different: Development should be measured based on expected ROI plus certain strategic factors; Operations should be measured based on predictability of spending and certain Quality of Service measures, along with regular and consistent assessment of relevance of those measures to the business. [This is analogous to market risk in financial portfolios]
3. Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy. In addition, the probability of future failures remains undiminished so long as the management shortcomings are not addressed.
4. The cost of failure in IT Development always exceeds the allocated budget for the activity, because failure has consequences beyond the immediate failed project, both for people and for other projects. For example, one major factor of risk that increases when a development project fails is the loss of key people. It is rare to find IT management mitigating this risk immediately on learning of a development failure.
5. Failures and losses in IT Operations usually involve either directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less known, to Operations managers. [Cf. Failure in Microsoft-provided services for Sidekick smart phones, Oct., 2009] [This is analogous to credit or counterparty risk in financial transactions]
6. IT management should be able to communicate to top management the nature of the tradeoffs in IT Operations and Development, so that strategic implications of decisions in IT are well understood at the top level. This means that financial factors must not be the exclusive determinants of IT decisions. The CIO should not report through the CFO.
7. Multi-year planning is essential for both IT Operations and Development. A roadmap for rationalization and integration of resources and services is necessary, even if it must be revised multiple times per year as new equipment and services are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.
Above thoughts on IT management are based on my recent experiences at a client company and were triggered by a paper, “Risk Management Failures” by Prof. Rene Stultz, Fisher College of Business, Ohio State University, published by Cornerstone Research http://www.cornerstone.com/
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on high-tech management, Get Out of the Way, is due out in 2009. More info is at http://johnlevyconsulting.com
More...
Subscribe to:
Posts (Atom)
