Flashover

Page 2 of 10

Previous

Next

You Create for the People, Not for the Snobs

Apr 14, 2019

In the 1960s, American architects Denise Scott Brown and Robert Venturi had grown tired of some of their modernist peers. While they weren't opponents of modernist architecture, they felt that too many modernists were dismissive of the need to preserve older buildings and ask what people actually want. Old, frilly buildings had to make way for efficient, sleek buildings made out of glass and steel. Populism and fun as architectural concepts were looked down upon.

Scott Brown and Venturi were kindred spirits who found each other during their time as University of Pennsylvania faculty members. They would work closely together sharing their ideas and research. They explored more decorative and elaborate architectural styles and taught the same courses. Eventually, this professional friendship turned into a romance and a marriage.

It was Las Vegas where they first confessed their love for each other. But besides having an extremely personal connection to the city, Scott Brown and Venturi treasured Las Vegas also as architects: they saw the city as their nation's anti-modernist capital. Las Vegas was built for people, not for architects. It was colorful, bright, and above all, fun.

One day, Scott Brown and Venturi decided to organize an expedition with their university students to Las Vegas. They wanted to study the city directly on the ground. They wanted to understand why the place would attract more visitors each year than for example Paris or any other large, modern city.

During their 12 week stay, Scott Brown, Venturi, and their students started noticing things. First of all, the famous Las Vegas Strip is like a bazaar built for cars with massive neon signs spelling everything out. Second, even though as an outsider Las Vegas seems chaotic and disorganized, visitors don't actually get lost or overwhelmed. Instead, people found the colorful signs helpful and pleasing. Las Vegas worked because it was built for people, not architects.

Nassim Nicholas Taleb (author and scholar) cautions against activities where we try to impress our peers instead of the people who we are actually supposed to serve. When architects build for other architects, we are deprived of fun and elaborate designs. When writers write for other writers, we end up with literature without soul.

As a developer or designer, how much do you try to impress your peers? If your software is accessible and usable to as many people as possible, have you served the people who you set out to serve? Or do you still need validation from your community?

It's easy to look down on Las Vegas and its kitschiness. However, this year, more than twice as many people will visit Las Vegas compared to Paris. People really love the city. Even though us snobs hate it.

Additional notes

To learn more about Denise Scott Brown, Robert Venturi, and Las Vegas listen to the 99% Invisible episode Lessons from Las Vegas.

Responding to Change over Following a Plan

Apr 7, 2019

Last year, I started writing about the agile software development values. This is the last post of the series. You can find links to the other posts at the end of this one.

As is the case with the other agile values, "responding to change over following a plan" seems almost like an obvious piece of advice. Honestly speaking, are we able to find professionals who don't aspire to act this way? Is any of us willing to publicly argue this value? And if this value is both obvious and undisputed, why do we need to list it as one of the agile values? Why would a software development team choose to follow a plan over responding to change?

One reason for ignoring additional information or a change in the world around us is that we might not like this new perception of reality. It might question the image of us as strong decision makers. We often choose to save face instead of admitting our mistakes. The more responsible for a decision or a plan we are, the more likely we are to justify its excellence even when negative events start to pile up.

In their research paper, Viktoria Stray, Nils Moe, and Tore Dybå study this phenomenon with an agile software development team over the span of four years. In the beginning of this period, the team made a decision whether to base the technology of their product on an existing framework already used inside the company or build their own framework from scratch.

The existing framework seemed to be too immature and complex for the project and therefore, the team decided to build a completely new framework instead. However, three years later, a new plan was made to reverse this decision. All the code for the new framework would be trashed and the team would move current features to the existing framework.

Development with the independent framework had been painfully slow. Almost all the new features required changes to the underlying framework code. These changes would take either hours or days but it was extremely difficult to estimate how big of a change was actually required. New developers entering the team would constantly complain about the code quality and architectural decisions of the framework.

Leading up to the decision to switch frameworks, the daily meetings had become a mess. Instead of coordinating work, developers would report on their finished work in detail in order to convince others of their technical skills. The product owner and new developers would judge the current framework as flawed while the original team members would defend their initial plan as best they could.

This is what escalation of commitment looks like. It's a situation where we refuse to alter course despite the increasingly negative outcomes we face. In group decision-making, escalation of commitment as a behavioral pattern is even more prevalent compared to individual decision-making. We don't like to admit to ourselves that we're wrong. But we like to admit it to others even less. We want to hold on to our social status. We want to be seen as competent and rational. Even after the decision to switch frameworks was made, it took five more months before the original team members accepted this new direction.

Stray, Moe, and Dybå caution us to stay aware of the escalation of commitment at our daily meetings: When we hear our teammates defending their decisions, we should take action. We should work on improving trust and communication. Teams that have open communication and high psychological safety are much more capable of a project turnaround than a team of silence and fear.

Too often our egos and insecurities get in the way. It's easy to delude ourselves into continuing with a bad decision or investment. It's obvious that we should alter course when needed, but the task of responding to change is harder than we think.

Additional notes

To read my other posts about the agile software development values, follow the links below:

Building Psychological Safety as a Teammate

Mar 30, 2019

Last week I wrote about Google's Aristotle project, psychological safety, and promoting teams instead of individuals. It might be a year ago since I first heard about the Aristotle project and its results. Since learning about psychological safety I have come to believe in the idea without reservation. However, I'm not sure how much my own behavior has actually changed in terms of building psychological safety with the people around me.

At some level, I have assumed the building of psychological safety to be the responsibility of my managers and the people who are working more directly with company culture. I might have thought that I could promote psychological safety but not that I should actually do it. In practice, psychological safety hasn't been one of my priorities.

But then I heard a colleague of mine mention how he has learned to abandon some of his extremist or uncompromising developer beliefs in order to bring more joy to his teams.

This got me thinking if I myself bring or take away joy from my teammates. I can have strong opinions. I can fixate on moving fast and locking in decisions early on instead of allowing everyone to voice out their concerns. As a human, I'm able to get annoyed and impatient. Do my everyday actions increase or decrease the sense of psychological safety in others?

Paul Santagata (head of industry at Google) describes a practical reflection activity for increasing psychological safety by recognizing the needs and aspirations of others. It's called "Just Like Me" and it asks you to think about your teammate and consider:

  • This person has beliefs, perspectives, and opinions, just like me.
  • This person has hopes, anxieties, and vulnerabilities, just like me.
  • This person has friends, family, and perhaps children who love them, just like me.
  • This person wants to feel respected, appreciated, and competent, just like me.
  • This person wishes for peace, joy, and happiness, just like me.

This is a reflection you can write down on a card and carry with you. It's a reflection you can come back to when confrontation and team anxiety crop up. It's not a comprehensive action list for psychological safety. But it's a practice you can start creating a habit out of. It can be both my and your first step toward allowing our teammates to take risks and be vulnerable around us.

You Don't Have to Manufacture Psychological Safety

Mar 24, 2019

In 2012, as a speaker at a Google event, Adam Grant (psychologist and author) was asked to describe how he would run the company as an organizational psychologist. Grant proposed that Google should stop promoting and firing individuals and instead start promoting and firing teams.

We often see team performance as the sum of individual skills and expertise. If you want your team to perform better, you bring in smarter and more talented people. However, it turns out that our individual performance is actually highly context-specific.

Robert Huckman and Gary Pisano studied the correlation between patient mortality and the experience of operating surgeons. Unsurprisingly, they found that patient mortality decreased as surgeons performed more operations. But they also discovered that this experience is strongly tied to the hospitals themselves. When an individual surgeon switched hospitals, patient mortality increased as if the surgeon was lacking all the experience they had gained at the previous clinic.

In another study by Boris Groysberg, Ashish Nanda, and Nitin Nohria, researches observed that star financial analysts who get poached by another firm take at least five years to climb back to their old level of performance in the new environment. It's almost as if during those five year a new hire needs to rediscover the right teammates before they can reach their full potential.

People at Google got excited about Grant's idea. Two years later, Google started the Aristotle project with the purpose of finding the secrets of effective teams. In 2016, Google published their findings and identified psychological safety (the sense of safety for interpersonal risk-taking) as the most critical trait shared by high-performance teams.

For many of us this makes sense. But psychological safety is not the focus of this blog post. Instead, I want us to think about another question: why did Google decide to study great teams instead of implementing Grant's original idea of moving teams instead of individuals?

Google did try to figure out how they could keep efficient teams working together even after projects ended and new ones started. However, they found Grant's idea to be impractical. It required too much work and organizational change. To avoid this work, Google would rather study what makes a great team and then try to apply that formula to other teams.

Organizations across all industries are now reading and implementing the results from the Aristotle project. Psychological safety is in the limelight. This is fantastic. But I'm afraid many of us are trying to manufacture psychological safety instead of dismantling the dysfunctional teams and empowering the successful ones.

The simple solution is to move around high-performance teams, not individuals. If you're Google, the solution might be simple but not feasible. However, if you're not Google, Grant's idea might be within your reach. What would it look like if your organization started firing and promoting teams instead of individuals? What would need to change? And at the end of the day, do you think you would be better off?

Additional notes

To learn more about Adam Grant's advice for Google, you should listen to his debate with Malcom Gladwell on WorkLife with Adam Grant.

Exams Are for Students, Experiments Are for Learners

Mar 16, 2019

R. Michael Anderson (entrepreneur and business author) came to our office yesterday to give a talk about his journey from programmer to leader. One of my key takeaways from his talk was the idea of exams vs. experiments. This idea is about understanding how we're taught as a child to avoid swimming in strange waters. It's about changing our inner narrative about failure and perfectionism.

The majority of us have been brought up in a school system that evaluates performance with exams. We get positive feedback from our teachers and parents when we ace a test. When we fail a test or score very low, things get uncomfortable. We face disappointment and the feeling of inadequacy.

We learn that it's really important that we do well in our exams, as in, we don't score low. We learn to avoid failure. And even though as professionals our performance is no longer evaluated with exams, we still treat some of our tasks and challenges as tests we need to pass with good grades.

If we are then given a choice between two tests, an easy one and a difficult one, which one do we choose? What if you get to choose between an easy test and no test? If you're like me, you will choose the no test option more often than you dare to admit. We've been taught to aim for the A's and avoid the F's. If the perfect score seems elusive, we turn to our secondary strategy of avoiding the test altogether.

The fact that we try to avoid failure is not by itself bad. Actually, it's a pretty good modus operandi. But we don't want this failure-avoiding behavior steer us away from difficult but meaningful work. We don't want us to choose to do nothing because of our fear of failure.

This is why Anderson suggests that we train our minds to treat our tasks and challenges as experimentations rather than exams. You fail an exam when you get an F. However, you fail an experimentation when your methods are flawed, or more importantly, when you don't even do the experiment.

Unintentionally, our schools also teach us that perfection is attainable. It is possible to get the perfect test score. However, as a creative, you know that perfect is the enemy of good. There are domains where the definition of perfect doesn't exist or perfection is almost impossible to reach given our inescapable constraints of time and money. It's the perfectionist in us who is afraid to take the first step in a world of ambiguity and challenges.

When you do experiments instead of exams, you start listening to your inner discoverer–not the perfectionist. Experimentations are about charting unknown territories. The goal is not to get the perfect score. Instead, the goal is to learn and do something meaningful.

Your new project, diet, or habit is not an exam, it's an experiment. There is no final grade. You fail if you don't try.

Page 2 of 10

Previous

Next