Paul Allen, the NBA’s Portland Trailblazers, and building a team

When Paul Allen, the co-founder of Microsoft, died in October, I decided to read his 2011 Memoir, Idea Man. I thoroughly enjoyed the book.

Seven years after co-founding Microsoft with childhood friend Bill Gates, Paul was diagnosed with Hodgkin’s lymphoma. He left Microsoft, already a very wealthy individual. A few years after successful treatment and recovery, he bought the Portland Trailblazers NBA basketball franchise.

In 1994, Paul Allen hired Bob Whitsitt as the Trailblazers general manager, to rebuild the team. Whitsitt focused solely on basketball skills in his hiring.

What follows is a cautionary tale for anyone building a team – skill is critical, but it’s important to consider team fit, character, balance, diversity, resiliency, empathy, etc… The following passage from the book describes one of those worst-case scenarios of a team built solely on skill:
Whitsitt proceeded to overhaul our aging roster as he’d done in Seattle, drafting young athletes with upside and adding big-name veterans.

He openly professed that he cared only about talent, to the exclusion of character and other intangibles. “I didn’t take chemistry in college,” he told the media. With enough physical ability on the floor, team cohesion would take care of itself. It was a risky assumption for a sport in which five men share one ball.

With hindsight, Whitsitt temporarily staved off decline by using my wallet to load up on pricey long-term contracts, players who were available because they were overpaid or had off-court issues or both.

When you come so close to winning a championship, as we had in the early nineties, it makes you that much hungrier because you know what the Finals taste like. It was the same for Whitsitt, who was desperate to validate his approach with a title. We were perpetually one big-salaried veteran away from contention, and our payroll ballooned. Deep down I knew that something was wrong. In the playoffs, when the pressure peaks and higher-caliber opponents target your weaknesses, a player’s makeup is revealed in performance. In the 2000 Western Conference Finals against the Lakers, we fell behind three games to one and then fought back to earn a deciding seventh game. Up fifteen points in the final quarter, it looked as though we were headed to the NBA Finals against Indiana, whom I thought we could beat. When I watch my team in the playoffs, I get superstitious; I try not to think about how much I want to win. Whatever happens, I’ll be fine with it. The players tried their best. But in that fourth quarter, I succumbed. I couldn’t deny it. I really wanted to beat the Lakers.

Within minutes, the Blazers unraveled. We missed thirteen consecutive shots. Our players suddenly looked as though they’d met for the first time that morning. The coup de grace came when Shaquille O’Neal dunked an alley-oop from Kobe Bryant with forty seconds left.

That seventh game exposed us as a team without leadership or discipline. I’ll never forget the feeling I had when we boarded our plane, still festooned with BEAT LA stickers, and headed home, our season done. It was a crushing defeat, and it took me a long, long time to get over it.

IN 2002, EIGHT years after Whitsitt’s arrival, we fell into the abyss. We led the league in payroll at $106 million, $44 million more than the championship Lakers. We were $65 million over the salary cap and $50 million over the league’s new luxury tax threshold, which had been designed to level the playing field for small-market teams like ours. Our player salaries cost us an outrageous $156 million, all for a medium-to-good fifty-win team that would lose yet again in the first round of the playoffs.

Off the court, it was worse, as the Trail Blazers became exhibit A for all that was wrong with professional sports. I found myself reeling from one lowlight to the next.

November 9, 2002: Bonzi Wells is suspended for spitting on the Spurs Danny Ferry.

November 22: Co-captains Damon Stoudamire and Rasheed Wallace, on their way home from a game in Seattle, are pulled over and cited for possession of marijuana. To settle the case, both agree to attend drug counseling sessions.

November 25: Ruben Patterson is arrested for felony domestic abuse. His wife later asks prosecutors not to pursue charges.

January 15, 2003: Rasheed is suspended for threatening a referee.

April 3: Zach Randolph is suspended after sucker punching Ruben in the face during practice and fracturing his eye socket.

The fans who felt so close to the Drexler-Kersey-Porter Blazers were disenchanted. Our attendance suffered, and our TV ratings fell by half. The wayward players showed little remorse. Bonzi Wells told Sports Illustrated: We’re not really going to worry about what the hell [the fans] think about us. You could see why parents weren’t rushing out to buy Bonzi or Rasheed jerseys for their kids.

One day I said to Whitsitt, “What’s it like in the locker room? How is the team reacting to the latest incident?”

And he said, “Well, Paul, half our guys are normal and half our guys are crazy. The good guys are all freaked out, but the crazy guys are crazy, so they’re fine.”

I’d heard enough. A team might be able to absorb one erratic personality, but who could win with a group that was half crazy? Three days after our season ended, I fired Whitsitt and gave his successor, Steve Patterson, a mandate to clean house. We traded established starters like Rasheed and Bonzi for forty cents on the dollar while letting bad contracts expire. The win-now regime had stunted younger talents like Jermaine O’Neal (who blossomed into a six-time all-star after being moved to Indiana), and our cupboard was bare. In 2004, the Blazers missed the playoffs for the first time in twenty-one years.

And then we sank even lower. An internal investigator came to me with a report on Qyntel Woods: “We think there may be dogfighting at Qyntel’s house.”

Dogfighting? I couldn’t believe what I was hearing.

A few days later: “We think there may be some dogs buried in his yard.”

Buried in his yard?

And a day or two after that: “There’s a room in his house where we hear the walls are covered with blood.”

Blood on the walls?

I was shocked and mortified. Qyntel eventually pleaded guilty to animal abuse and got eighty hours of community service. We suspended and then released him three months later.

The next year we touched bottom. With a record of 21-61, the Trail Blazers were indisputably the worst team in the league. Though things were quieter off the court, I had a new challenge: how to pay for my team’s home court.

As we discovered too late, the financial formula was fatally flawed. Add a local downturn and an unpopular losing team, and we had a perfect storm of red ink and disaffection. The Blazers were getting booed at home, once unthinkable in Portland. Our season ticket holders were canceling in waves amid calls for a boycott, despite our explicit efforts to rebuild and start over. All told, I’d invested more than half a billion dollars in the franchise, at a huge net loss. Something had to give.

Reflections on Workplace Hackathons

I recently participated in a workplace hackathon.

Here are some reflections on the experience:

  • It’s hard to completely step away from day-to-day work for 2 days. Release schedules set long ago don’t change, we choose to keep customer facing meetings, incidents still need to get addressed
  • Conversely, much can be deferred (many emails can wait!), and a lot can still be accomplished in two part days
  • Two days of development and a 7 minute presentation are great constraints which force many decisions

It’s amazing how much you can get done when:

  • We start “fresh”, no legacy code, no figuring out what a predecessor was trying to do or why something was built a given way
  • We pick our preferred tools and infrastructure

There is such a big gap between a Proof of Concept and working production code:

  • We didn’t worry about production readiness (performance, scalability, stability, security)
  • We focus on prototyping ideas, as opposed to working on functional integration of all systems
  • We only focussed on the main flow, we didn’t worry about handling less-used flows or exception handling

Even without regular constraints, some things are still hard:

  • Firewalls make it is challenging to building a project with uses internal systems (even pre-prod environments) and external APIs
  • Data projects work best with production data, which is rarely possible. It would be really cool to have a legal and security teams participate to make quick decisions on what we can and can’t do with production data for a demo.

And finally:

  • For someone who’s not a developer like myself – this is fun opportunity to write some code – it’s fun to build
  • It’s also fun to play with new tools – last year, we played around with the Amazon Alexa API – when else would we set aside time to do this?
  • It’s a great opportunity to present to an engaged audience
  • The event generates such a positive atmosphere
  • The competition and feedback is immediate, which is awesome
  • A working prototype that can be demonstrated in minutes is critical.

Fix a worn out Toronto Public Library card

I’m on a roll this week – a record number of posts (3 in 7 days…).

The bar code on my library card has been worn out for a while.  My last few trips, its probably taken about a minute for me to play around with the positioning of the card on the library’s scanner to get it to read correctly.

Years ago, I’d read how my friend Chris created a custom library card with all of his family’s card numbers on it.  Although I’m sure the instructions he provided would work (I suspect the library’s barcode readers handle many formats), the bar codes his method created didn’t match the one on the card.

Here’s how to get one that matches:

  • The format is Codabar
  • The Start and Stop character is ‘A’
  • The Toronto Public Library’s account number already has a check digit, you don’t have to add one
  • Many online generators exist.  I used abarcode.net

I printed mine and stuck it to my old card with packing tape.

Reverse engineering a recipe

The Hispanic Fiesta Latin-American festival descends on Mel Lastman square in North York every labour day weekend.  The festival has lots of live music, a beer tent, and food vendors.  And every year, I buy a coconut ice pops (“Paletas”/popsicles) from Polar Real Tropical Fruit.  They’re awesome, and I never see them sold anywhere else.  Perhaps its the ambience of the festival, but I prefer them to other coconut ice pops I’ve tried.

So, I decided to try to make my own.  I took a picture of the ingredients and the nutritional information.

Coconut Paleta Ingredients and Nutritional Information

Then, looking at the protein, carbohydrate, and fat content of each key ingredients against the nutritional facts of the ice pop, I estimated the proportions of a 150 g serving as follows:

  • 15 g of shredded, sweetened coconut
  • 70 g of 2% milk
  • 2 g of tapioca starch
  • 13 g of sugar
  • 50 g of water

Here’s how mine turned out:

Homemade Coconut Paleta

It looks very much like the ones from Polar Real Tropical, but the texture was a little more ice-crystal-y, and it was less sweet.  For my next batch, I’ll cook the mixture before freezing it.  This should help the sugar dissolve evenly, and allow the tapioca starch to thicken the mixture a bit and improve texture.

Why do simple things take so long?

“I was in Boston recently and visited Old Ironsides at its berth, coincidentally at a time when the ship was being painted. I chatted with one of the supervisors and asked him about the length of the government specifications for this particular job. He said it numbered two hundred pages and laughed in embarrassment when I told him to take a look at the glass display case showing the original specification to build the ship in 1776, which was all of three pages.” – Ben Rich, from Skunk Works: A Personal Memoir of My Years at Lockheed

Why does it take a 200 page specification a re-paint ship which was built from a 3 page specification? How many kinds of paint were there 1776? How many colours were available? Presumably, when the ship was built, most of the requirements were implicit, just understood and assumed by the builder.

This is partially addressed by one of the principles of the Agile Manifesto http://agilemanifesto.org/: emphasize working software over comprehensive documentation. This can be achieved by having small, self-organizing teams, that understand the domain well enough, they can identify the next task and have what they need to take action. They know the ship has to be painted, they know what paint is required, and know how and when to apply it.

This can be hard to scale. Our development team knows our web stack, and our business domain, really well. We have great turnaround times on turning ideas into functional code delivered to production. But if we need something beyond code – let’s say, we’ve got to introduce a new brand, which requires a new domain – we’re not in a position to assess the interaction between our DDOS-protection vendor, network routing, load balancer, server setup, and have to engage external teams.

Similarly, I’ve encountered these issues when working on projects with Canada’s “Big Five” banks. I’ve seen projects held up for months by small things, such as making small changes to a file transfer – something that ultimately takes the right person a few minutes to implement – once the right person is found, allocated over competing priorities, and changes documented. What is operationally very efficient for the bank is less nimble for changes.

What has changed since the days of a 3 page warship specification? How do we efficiently use 30 minutes of SFTP administrator time a year, who has no context to a broader project? How do we get that 30 minutes allocated at the right time? When using niche skillsets across a project, how do we avoid a 200 page spec? Who has the skill to build a 200 page spec across diverse skill sets when we need something new? How long does that take?

Why do simple things take so long?

Creating Turing-test passing chatbots is getting easier

“The Turing test, developed by Alan Turing in 1950, is a test of a machine’s ability to exhibit intelligent behavior equivalent to, or indistinguishable from, that of a human.”
Wikipedia

I’d heard this neat story recently, on the More or Less Human episode of Radiolab, on how it has become easier to write a chatbot that passes to Turing test, because how we communicate has changed.

Over the last 5-10 years, most of our chat clients (eg: Messages, WhatsApp, Android Messages) have auto-complete, canned responses. Often, when you try to type something unique, the chat client suggests something else.

AND, data entry, whether by keyboard or voice on mobile devices, make it challenging to write human sentences.

Even when a human is writing, because of auto-correct, suggestions, poor data entry on mobile devices, and canned responses, our writing has become a lot more bot-like. Our expectations are for bot-like communication.

So, even without AI advances, it has become easier to write a Turing-test passing bot. Alternately, a human from 30 years ago would probably identify a human using a chat client on a mobile phone as a machine.

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!