Flashover

In September 2018, I made it my goal to publish and maintain three open-source projects by the end of the year. I wrote a blog post about it. I made a plan and a scoreboard. I was feeling bold and up to the challenge.

But then I didn't do the work.

I did keep writing code on my own time. However, that code didn't result in a single solid project. I'm not really sure why things turned out the way they did. Therefore, I'm not really sure how I should actually feel about this failure. Maybe I got lazy. Maybe I chose the wrong goal. I don't know. Let's try to find out.

Strong start, weak finish

After deciding on the goal, I tried to design a support system for it. I wanted to make it as easy as possible for me to work towards my goal, and conversely, make it as difficult as possible for me to slack off. The most important part of my system was a scoreboard which I used to track deep work hours (hours of coding without checking social media or taking unplanned breaks). I would also review my hours on a weekly basis.

The scoreboard did its job. During the first weeks, my deep work hours were very low. In the weekly review, I had to face my mediocrity. It wasn't fun. So I promised myself to commit to more deep work hours. Because of that, I actually saw the hours going up during the next weeks. This was great.

However, at some point, the weekly hours started dipping. I also stopped doing the weekly review altogether. First, I could see my results dropping–after that, my overall motivation. Eventually the whole scoreboard turned from a tool of self-management into a visual reminder of my shortcomings.

What happened? Why did those weekly hours start to dip?

Poor habits, stress, and career

First, it's normal to have higher levels of motivation and energy at the beginning of a project. There is this natural high that carries us through the first days of our new endeavors. We might stay up late and sometimes we even forget to eat.

However, at some point this high will start fading away. This is when the grind starts. And if you haven't taught yourself to show up even if you don't "feel like it", you're in trouble. You start putting off your work or looking for something new and fun to do.

I haven't committed to deep work as strongly as I would like to. I still struggle to fit deep work hours into my week. Not necessarily because I lack the free hours, but because I'm afraid to push myself to focus on something for long periods of time. I need to build better habits for deep work, and more importantly, I need to get more serious about it.

Second, life happens. Work got more stressful during the fall and early winter. There was suddenly much more stuff to be done than I could fit into my work week. Luckily, I worked at a company that didn't have a culture of overtime and therefore, my overall work hours didn't increase noticeably. However, I did find it harder and harder to turn off work mode even when I got home. I was feeling more exhausted and less thrilled to start working on my own projects after a full day of client work.

Finally, I started thinking more and more about my future career as a developer. Primarily, I couldn't decide whether I should try to specialize or be a jack of all trades (and master of some). This internal conflict affected my personal projects since I kept second guessing whether a particular project was a good fit in terms of my career development. I spent a lot of time spinning my wheels instead of doing actual work. In the end, I decided to prioritize my interests and curiosity over the interests of my potential employers. I wrote more about this in my post "What to Learn in 2019".

Final notes

I haven't actually set a goal like this for 2019. To be honest, I'm a little afraid of reproducing the demoralizing aspects of this experiment. I'm afraid of losing my joy of coding. And I do believe that play and having fun advance our learning and ability to ship much more than we give credit for it.

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.

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:

• Back to Basics with Agile
• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation

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.

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.