I just returned from vacation and was reviewing some photos in my cel phone when I found some old photos from a previous trip to SF. In the airport there was an exhibition about TV sets and some old remote controls got my attention. Here’s a picture of them:
Old TV remote control
Checkout the number of buttons in the remote control. The maximum is 4. There are some remotes with only one button. When I was a kid I remember the first TV bought in my house with a remote control that had only 2 buttons, one for volume and other for changing channel. That simple! That was around 1975. At the time, the technology for making a remote control was too expansive, so it could not be too complicated and have too many buttons, otherwise it would be too expansive to be sold in the market. That was the restriction that drove the simplicity of those 1st generation remote control. Now we don’t have that restriction and we get remotes that can accomplish much more tasks but are way more complex. Take a look at the picture below (and I even picked a not-so-complex one!):
Digital TV Remote Control
So maybe next time we want to design something more simple, we can think of imposing some restrictions to the design process!
I mentioned earlier about “The Checklist Manifesto” book. The post was originally written in Portuguese but you can find a Google translation here. In this post I mentioned about the use of checklist in surgeries and other medical procedures and how we could use checklists in the IT environment.
I was reviewing my Kindle highlights for this book and found this highlight:
Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them.
But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.
Dr. Gawande found out that in order to address the unexpected, checklists should not only include task checks but also communication checks. Dr. Gawande got to that conclusion visiting a 700,000-square-foot office and apartment complex construction site with between two to five hundred workers on-site on any give day managed by a man called Finn O’Sullivan. The volume of knowledge and degree of complexity O’Sullivan manages is impressive and it was as monstrous as anything Dr. Gawande had encountered in medicine. Here’s the explanation:
It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed.
The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.
So next time you design a checklist, remember to include not only task checks but also communication checks.
Those who has been following my posts know that I like to borrow ideas from medicine and relate them to software development an management. Below are two posts that make comparisons between medicine and software development and management:
By the end of February/2011 I was submitted to a cervical spine disc replacement surgery like the one shown below (it’s just an animation with no actual blood):
The result is in the x ray images below:
frontal x ray
x ray side view
The doctor did the surgery on February, 25th. However, the healing process will take months. According to the doctor, it can take one year until all the symptoms that motivated the surgery disappear.
The comparison
What caught my attention is that the surgeon only did an intervention but all the healing process is done by the body. The same happens when a doctor prescribes a medicine, which is also an intervention, but again is up to the body to actually heal itself.
Leading a team is quite similar. The leader should do some interventions when necessary but is up to the team to do the work in order to get to the goals.
Agile leadership
Leadership is topic that I really enjoy studying and discussing. It’s one of my top topics in this blog with more than 40 posts so far. And I already discussed about agile leadership in some of these previous posts:
In one of my reading session on leadership I found an interesting comparison between leadership and gardening made by Jurgen Appelo, who writes frequently about agile management:
I often compare managers to gardeners. An unmanaged garden is typically full of weeds, not beauty. From a biological perspective, there’s no difference. Either way, the ecosystem in the garden is self-organizing. It takes a gardener (authorized by the owners of the garden) to turn an anarchistic garden into something that the owners will enjoy. Likewise, it takes a manager (authorized by shareholders) to steer self-organizing teams in a direction that delivers value to the shareholders.
Even though I like this comparison, it considers that the gardener/manager has to constantly interfere, which I don’t believe is an appropriate behaviour for a manager. In my view, a manager’s interference should be done only when needed and, after the interference, the team should work by itself to solve things out with little or no intervention by the manager. Hence my comparison to a doctor who interferes only when needed by prescribing change of habits, medicine, physical therapy and / or surgery and who let the body do the work and be in charge of the healing process.
Next time you are in a team, either as part of the team or playing the role of leading the team, think about the leadership role similar to the doctor and the team work similar to the healing process carried out by the body. It helps understand the roles and responsibilities.
When we implemented agile methodologies at Locaweb, the same way that some developers asked to leave because they were not willing to adapt to some of the agile principles that we decided to embrace, some of the existing managers also didn’t adapted well to the changes in their roles and responsibilities and asked to leave.
At the time, I discussed this topic with people from other companies and they mentioned that it’s not unusual to have developers and managers leaving the company when moving to agile. I remember even someone mentioning that in average 10% of developers leave. That was back in 2007 / 2008. I’m not sure if this tendency have lowered lately, since agile is becoming more and more mainstream.
I also read – and continue to read – a lot about the topic. One of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.
Customers shouldn’t be the ones who define your products; they should be the inspiration for your products definition. (via @sjohnson717)
In general I think that anger is a sign of weakness and tolerance a sign of strength. (via @DalaiLama)
Very good article by @simonsinek: Good Marketing vs. Bad Marketing – http://bit.ly/f4kuna
…people spend most of their time either jumping to conclusions or else taking no notice at all of facts. (via http://bit.ly/guRxQw)
Different modes of behaviour on the part of the wise are to be regarded as due to differences in individuality, not of quality. (via http://bit.ly/guRxQw)
Anyone “software professional” who is not humble about the software business is is not actually a professional. (via @JerryWeinberg)
Really beautiful REAL Google Earth FRACTALS! But missing Brazil though… http://bit.ly/hja6PX (via @cristobalvila)
Yip is reading what seems to be a very good book on variation, Understanding Variation: The Key to Managing Chaos. In this book the author Donald J. Wheeler, according to an Amazon.com reviewer, “provides managers a rational way to look at daily, weekly, monthly, and yearly figures and tell whether the actions they take have resulted in improvement”. It seems to be a very interesting book from what Yip’s been posting:
That’s a good way to see the possible outcomes of a group of people under pressure.
I like to use balloon as a metaphor to help understand under pressure situations.
Balloon
Here’s why:
there’s pressure from inside and from outside.
pressure from inside and from outside needs to be balanced.
to much pressure from the inside or to little pressure from outside and balloon explodes.
to much pressure from the outside or to little pressure from inside and the balloon explodes unless it is one of those balloons where the more outside pressure it gets the harder it is to explode.
Lessons learned
There’s no such thing as “no pressure”. A group of people needs pressure from outside (the goal, the target date, lack of resources) as well as from inside (motivation) to exist and do things, just like a balloon.
Inside pressure and outside pressure needs to be balanced with some tendency to have a bit more pressure from the outside.
Under pressure, a group of people either explode or get stronger.
. In this book the author Donald J. Wheeler, according to an Amazon.com reviewer, “provides managers a rational way to look at daily, weekly, monthly, and yearly figures and tell whether the actions they take have resulted in improvement”. It seems to be a very interesting book from what Yip’s been posting:
