Malcolm Gladwell and Adam Grant on Teams

One of the benefits of commuting across the top of Toronto on North America’s busiest highway is I have lots of time to listen to my favorite podcasts.

One series I follow is called Revisionist History, a podcast hosted by Malcolm Gladwell, an author known for writing about research in social sciences, often presented alongside observations and stories. This season has started with a discussion between Malcolm Gladwell and Adam Grant, where, among a number of topics, they talked about the impact of teams on individual contributions and outcomes.

I have not fact checked anything they have stated, and I don’t know anything about basketball, hospitals, or flying airliners to comment, but some of the ideas are interesting to think about.

Here are a few interesting excerpts from the transcript:

On the impact of moving from one team to another:
“One of the best guards in the game this season was this kind of Victor Oladipo on Oklahoma City, and was considered a disaster, and he simply moves teams to a new environment with a presumably better coach, he’s no longer playing with Russell Westbrook who’s probably a very difficult person to play with, and simply by moving teams he went from being someone who was widely considered to be a bust, someone would be washing out of the league soon or a mediocre player, into this suddenly a superstar who’s kind of playing transcendently”

“The best coach in the league is probably Brad Stevens of the Boston Celtics … every time a very promising player is traded from the Boston Celtics they turn out to be terrible … Jae Crowder is a good example. Everyone’s like… ‘oh god they traded Jae Crowder wow i don’t know if they can survive without Jae Crowder’. Jae Crowder goes to Cleveland Cavaliers, …people realize oh Jae Crowder is actually not any good he just was good on Boston”

“You then begin to wonder, how many players on basketball teams who we consider mediocre are actually really good but just in the wrong environment? Is Victor Oladipo is he an exception or is he part of a larger trend? And I am increasingly of the opinion that there must be lots of Victor Oladipo’s out there, I think there are, and I think they’re not just in basketball”

On the effect of moving from one team to another:
“…is I have a different team who knows my strengths and weaknesses, and we’ve developed a set of effective routines, and that kind of suggests that performance and skill and expertise is team specific, it’s contact specific”
This I’ve experience in recreational sports – a less athletically capable, but experienced team, can often defeat a more athletic team, just by knowing where team mates will be, how fast they can run, how far they can pass, etc…

“…over seventy five percent of airline accidents happened the first time the crews flying together, and the evidence goes so far on this that NASA did a simulation showing that if you had a crew that was well rested flying together for the first time they made more errors than a sleep deprived that just pulled an all nighter but flown together before”

On building teams:
“…you hire individuals, reward individuals, promote individuals, … What if … you hired entire teams but you didn’t just do that, you promoted teams, rewarded teams”

Experimenting At Work

A co-worker recently came back from training, and shared some of the techniques that were presented.

One that sounded interesting was, in planning, try swapping roles to elicit different ideas. For example, have a developer act as product owner, and speak to priorities, and have a product owner speak to effort and commitment. Role playing is more common when identifying personas to help define user stories, but I hadn’t heard of anyone doing this within a scrum team – we typically go into a planning session as our assigned roles. This is also similar to the ideas presented in Edward de Bono in Six Thinking Hats, where he suggests you try to place yourself in a specific mode of thinking (eg: emotional, creative) to approach problems from a different perspective.

And this idea of role playing got me thinking of a scenario playing technique that I’d heard about on the Freakonomics podcast, where a psychologist proposes conducting a “pre-mortem” before starting a project. Post-mortems are pretty common – particularly when something “bad” happened (which is interesting on its own – as if there were only lessons to be learned when something bad happens). In a pre-mortem, before the project starts, the team meets, and pretends that the effort has been a failure, and spends 5 minutes writing down all the reasons they can imagine why the project failed. The idea is there is now “prospective hindsight”, to adjust for over-confidence at the beginning of a project, and provide input into the planning process. It’s a different way of collecting input for a risk register.

Along with other ideas circulated on LinkedIn news feeds, and blogs, does anyone ever try to shake things up and try different techniques at work? Ever schedule an outdoor walking meeting? Should we wait for the “best of” processes to get collected and codified, and then formally adopt them (PMP, SCRUM, etc…)? Have you introduced anything to your teams after reading about it or talking with peers? Did it stick?

Antifragile – Hidden Benefit of Chaotic Systems

Although not related to IT, there are ideas worth considering as we think about our systems in the following book:
Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb

“Just as human bones get stronger when subjected to stress and tension, and rumors or riots intensify when someone tries to repress them, many things in life benefit from stress, disorder, volatility, and turmoil. What Taleb has identified and calls “antifragile” is that category of things that not only gain from chaos but need it in order to survive and flourish.”

The idea is that a bunch of un-aligned, disorganized systems suffer from a bunch of small, recoverable failures which make the whole more resilient. Whereas large, organized, homogeneous systems may suffer from fewer small failures, they are susceptible to larger failures which can lead to catastrophe.

I have seen some evidence of these patterns at work. I worked for years on a product which required an Intel server running RedHat acting as a proxy, an Intel server running Windows handling connectivity with other systems, a Sun server running the SunONE application server, and a Sun server running Oracle (all before Oracle bought Sun!). When I worked in support, a “Severity 1” server down alert might mean an issue with the application server, and a single client would be out of service.

In 2012, significant upgrades were made to our infrastructure. All of those Intel servers for all of our lenders were consolidated onto VMWare clusters. All of our Sun servers were consolidated onto larger Sun servers. Significant savings were realized in infrastructure expenses, and systems became easier to manage. The number of incidents decreased.

But as we consolidated our infrastructure, an outage now had much greater scale. A “Severity 1” server down alert now meant that multiple customers were out of service. As we consolidated our servers, we also consolidated our incidents. A Sev 1 became bigger and more complex. If we were using the number of Sev 1 incidents as a performance metric, were we counting the same thing?

As we look to the cloud, the potential scale is even bigger – here are a few examples:

What happens when all applications are hosted by Amazon AWS, Microsoft Azure and Google Cloud? When every server runs Linux on Intel?

Given the choice, I don’t think anyone wants to manage a impossible patchwork 1000’s of systems unsupported by vendors that no one understands with different versions of everything. However, the dangers of homogeneous systems should be considered as we design and assess our systems – there can be strength in disorder!

Hiring for Potential and Building The Amiga Team

I spent a good portion of my childhood in front of a Commodore Amiga 500, an amazing home computer for the late 1980s. I purchased mine used, after having saved months of hard-earned income delivering newspapers.

When author Brian Bagnall created a Kickstarter campaign to fund Commodore: The Amiga Years, a book about the history of the Amiga in 2015, I backed it. As Kickstarter projects go, 2 years later, I received it (now you can buy it on Amazon).

The Amiga was a really neat computer with great capabilities for its price point, much of it enabled by a number of custom chips. The design of these chips was lead by Jay Miner, a former Atari Engineer. I was surprised to learn that for one of the chips, Jay Miner hired Glenn Keller, an oceanographic engineer visiting California looking for work in submarine design, with no prior experience in chip design.

From The Amiga Years:
The engineer who would end up designing the detailed logic in Portia seemed like an unlikely candidate to design a disk controller and audio engine, considering he had no prior experience with either and didn’t even use computers.

In 1971, MIT accepted his application and he embarked on a masters in ocean engineering, graduating in 1976. As an oceanic engineer, Keller hoped to design everything from submersible craft to exotic instruments used in ocean exploration. “I’m the guy that builds all those weird things that the oceanographers use, and ships, and stuff,” he says.
When the oil crisis hit in 1973, Western powers began looking for alternative sources of energy. One of those potential sources was the power of ocean waves. The project caught Keller’s eye while he was attending MIT, and in 1977 he moved to Scotland to work for Stephen Salter, the inventor of “Salter’s duck”, a bobbing device that converted wave energy into electrical power.
The British government created the UK Wave Energy program and in turn, the University of Edinburgh received funds for the program. This resulted in them hiring Keller to work for the university.
The experience allowed Keller to develop skills in areas of analog electronics (with the study of waves playing an important role), digital electronics, and working with large water tanks to experiment with waves. “That resulted in some actual power generated from ocean waves,” he says. “It was a lot of fun.”
In March 1982, with oil prices returning to normal, the UK government shut down the Wave Energy program and Keller returned to the United States ready to continue his career in oceanographic engineering. He soon landed in California, where much of the development of submersibles was occurring. “I was up in the North Bay looking for oceanography jobs and ocean engineering jobs,” he recalls.

Soon, Keller was boarding a train for what would become a life changing experience. When he exited the train he was greeted by Jay Miner, wearing one of his trademark Hawaiian T-shirts. “I go to Sunnyvale, I show up at the train station, and there is this guy in a Lincoln Continental with a little dog sticking out,” laughs Keller.

One doubt Keller had was his lack of experience in the computer industry, or with personal computers of any sort. This was 1983, after all, and millions of personal computers had already permeated homes across North America. “I had done programming but I didn’t understand the world of personal computers or indeed the world of Silicon Valley,” he explains. “I hadn’t been there.”
Once at Koll Oakmead Park, Miner brought him into the shared office space with the whiteboards and block diagrams. Although Miner hoped the proposed system would have a great impact on Keller, he failed to get it. “I didn’t really understand why the architecture was so great in a general sense, because I didn’t know that much about where computers were at that point,” says Keller.
Instead, he hoped his diverse electronics background would give him enough skills for the job. “I had done a lot of electronics but no chips,” he says. “But I liked Jay and I always liked pretty colored wires. I had done a lot of different kinds of electronics. Being in ocean engineering, you do everything: digital, analog, interfaces, all that stuff. Even software. You do the whole thing. So I had a pretty broad base even though I hadn’t done chip design.”
Decades later, Keller sounds mystified as to why Miner would hire an oceanographic engineer into a computer company. “He hired me for some reason,” he says, musing the reason might be because, “I guessed correctly the difference between a flip flop and a latch.”
Most likely, Miner knew all he needed was an engineer with a good understanding of both analog and digital electronics for Portia. He could bridge the gap of chip design by mentoring a junior engineer.

A great story about a successful hire based on an assessment of someone’s potential to learn and grow.

Incidentally, in my high school years, that Amiga 500 landed me my first part time job at Dantek Computers, a small store that assembled IBM PC clones. By this time, around 1994, the Amiga was obsolete, and parent company Commodore was bankrupt. At my interview, Dan of Dantek looked at my resume, saw “Amiga”, and said in French:
“Amiga – ça c’est un signe de bon goût “. I started the next Thursday at 4 PM – I worked there after school for 2 years, and saved enough to pay for a good chunk of my engineering degree.