Fighting Burnout with Yoga Rooms

Fighting burnout with yoga rooms, what happens before and after meetings, picking which customers you’re going to lose, a more subtle form of mentorship, and why you don’t want to turn a startup into a spreadsheet.

Monday, November 11, 2019

On Monday, November 11, I shared a link to an episode of the Agile Uprising podcast featuring Brandi Olson with host Andy Cleff. Andy asked Brandi about what she means by multitasking. At the individual level, she says we use the word multitasking to describe what is happening when we are trying to do more than one thing at the same time. It is a misnomer though, because our brains do not actually do more than one thing at the same time.

Her bigger interest is in what happens when you have groups of people trying to multitask all day long. She calls this “organizational multitasking.”

Say you have a team and they have a backlog. Organizational multitasking happens when somebody tells that team, “You need to get all ten of these things done this week and you need to start them all and I want to see the progress you are making each day.” 

The opposite of that, organizational focus, happens when you say, “Work on this thing first before you work on the next thing.”

At the team level, she says, there are a number of illusions about how to be more productive and effective. One illusion is that getting started on everything is the way to get it done and if everything is important we have to do it all at the same time. This breaks down because of the reality of how our brains work.

Research shows that when a person has to juggle two projects throughout a day, they will spend 40% of their brain capacity and energy on context-switching. For three projects, energy devoted to context-switching jumps to 60%. Not only does this take time away from more productive work, but we don’t even notice the time we lost.

A further cost of having entire teams of people running around at 40% brain capacity is that they are less likely to identify the real problems to work on and it feels like they cannot slow down to figure out what the real problems are.

Andy asked whether the solution should come up at the individual level where someone starts to say, “No,” or is it something that starts at a leadership layer. Brandi says it is not a problem that can be solved individually. It needs to start with our leaders. Some of the problems that start to show up in these contexts are a failure to solve the right problems, a reduction in quality, an increase in employee turnover, a reduction in equity and diversity, and burnout. These problems, as she says in the above quote, typically get addressed by solving the symptoms.

Andy asked what she does to help organizations separate the symptoms from the cause. Brandi says she does this by making the costs of multitasking visible. She told the story of a company that surveyed 600 companies and their HR leaders about the biggest threats to their workforce. Over 80% of those leaders said that employee turnover was the biggest threat. The company then surveyed the employees at those same companies and the employees overwhelming named having too much overtime and unrealistic work expectations. Going back to the same HR leaders, a fifth of them wouldn’t be doing anything about their turnover problem in the next year because the leaders themselves had too many competing priorities.

The overwhelming illusion that too many leaders buy into is that, while turnover and burnout are problems, we cannot do anything about it because there is too much important work to do. A further illusion is that we can capacity plan by cutting everybody’s time up; we can break up your time among projects and it will all add back up to 100%.

Wednesday, November 13, 2019

On Wednesday, November 13, I shared a link to an episode of the Engineering Culture by InfoQ podcast featuring Judy Rees with host Shane Hastie. Shane asked Judy if it is possible to have an effective remote meeting. She says, “absolutely,” and backed it up with an example of one of her own students telling her recently that participants in the student’s remote meeting considered it better than an in-person meeting.

Shane asked about the secret sauce of a good remote meeting. Judy says it is probably planning. She also said that when remote, each person brings part of the meeting room with them.

She says people don’t realize how important the environment is to conversations. When you put people in a small space, they pay attention to small details and administrative kinds of things. For “blue sky thinking,” take people outside or to a room with a big view.

In real world spaces, we already know where to find small rooms and rooms with big views, but online, we need to create equivalent spaces. You need not only to ensure that all participants turn up with a decent headset, cameras turned on, and light on their faces, but also to figure out the activities so that you have enough social time at the beginning, during, or end of the meeting. As Judy points out in the quote, the beginning and end of the meeting are critical parts of a meeting. Online, we often miss out on these beginnings and endings and it affects the quality of the conversations.

She also says that most people find it easier to engage and participate when the meeting is small. This connects with what Courtland Allen said on Software Engineering Daily about communities in the previous fortnight’s review. She says that if you can’t limit the space, you can limit presentation time to 5 to 7 minutes and get then people doing something. She also says to use breakout rooms and use liberating structures like 1-2-4-All (https://www.liberatingstructures.com/1-1-2-4-all/).

Knowing Judy’s expertise in Clean Language, Shane asked how might Clean Language be used to enhance remote meetings. Judy says that teaching people on remote teams to ask more non-judgmental questions about what somebody means by what they say can have a profound effect. Because of the missing socialization in remote meetings mentioned earlier and the fact that remote teams often have more cultural differences than co-located teams, misunderstandings are more likely. Therefore, learning to ask questions to clarify in a way that doesn’t sound like an interrogation but helps both parties to get clearer more quickly becomes particularly valuable.

Friday, November 15, 2019

On Friday, November 15, I shared a link to an episode of the Agile FM podcast featuring J. J. Sutherland with host Joe Krebs. J. J. Sutherland is the CEO of Scrum Inc. and the son of Jeff Sutherland, the co-creator of Scrum. J. J.’s new book is called “The Scrum Fieldbook.” Joe asked what made him pick such a title. J. J. said he wanted to write a book about all the places Scrum Inc. has been all over the world and the many different domains far beyond software. He also wanted to show how Scrum Inc. thinks about Scrum and what are the patterns and anti-patterns.

He says that Scrum is a universal framework for accelerating human effort with applications in aerospace, banking, and even beer-making.

No one does Scrum just to do Scrum. Scrum is designed to produce value, which requires knowing more than just the Scrum guide. It involves understanding why Scrum works the way it does, understanding complex adaptive systems theory, knowing that you need to empower your teams and ensuring your teams are the right size.

Scrum is about running experiments and getting feedback from the customer and adapting to that feedback. He sees people spending six months to a year planning how to do Scrum before they even start. Instead, he says to just do something. That is where you’ll get the information to iterate towards the right thing.

Joe expressed his appreciation as a Scrum coach for the chapter in the book on the difference between busy and done. When J. J. worked in radio, producers used to talk about how much effort they put into the radio programs and he would have to point out to them that no listener cares how hard you worked on it; they care about what comes out of the box.

He told the story in the quote above about a company with a regulatory date they had to hit who had him evaluate their agility. When he gave them the message, they didn’t call him back.

Monday, November 18, 2019

On Monday, November 18, I shared a link to an episode of the Developing Up podcast featuring Angie Jones with host Mike Miles. Mike asked Angie what she considers the ultimate goal of code review. Angie says the goal is to ensure everyone is aware of and content with what is being contributed to the code base; it is not a nitpicking session or an opportunity to bash your least favorite developer.

Code review is also a good way to catch missed requirements. Angie encourages code reviewers to review the unit tests just as closely as the implementation. 

Angie says the best code reviews are those you block out time for and make part of your routine. They aren’t something you skim while you drink a cup of coffee. When she reviews code, she always pulls up the requirement in the spec, doc, or ticket to see that the code under review fulfilled it. She looks for whether the implementation is efficient and at the right level of abstraction. She says that code reviewers have the opportunity to think at a broader level and see opportunities for code reuse.

Angie sees code review as a form of mentoring without having an official mentorship relationship. Official forms of mentoring can feel like an obligation for the mentor because they have to set up meetings, learn the mentee’s career goals. As she says in the quote, code review is a more subtle form of mentorship that is just as powerful.

Wednesday, November 20, 2019

On Wednesday, November 20, I shared a link to an episode of the Unlearn podcast featuring Eric Ries with host Barry O’Reilly. Eric described how he started his company IMVU and how, when he wanted to do practices like split testing, he got pushback. People thought of it as a direct marketing technique, not a product development technique. He would argue, “Shouldn’t we use the scientific method to test our hypotheses?” He wanted customers involved from day one and he wanted to ship more frequently than was considered normal at the time. Looking back, he sees how extreme his ideas were at the time and is glad his cofounders didn’t fire him.

As the company got more successful, his techniques got more controversial because the company now had more to lose. He said, “When you do things in an unconventional way, every problem the company has gets blamed on the unconventional method.” Barry pointed out that having to constantly explain the value of these unconventional methods likely made his thinking more resilient and could have been the seed for his next step.

At one board meeting, he felt like he was going to be fired. He was tempted to apologize and compromise, but made the conscious choice to advocate for what he actually believed despite the potential negative consequences. He rationalized it like this: this is a small business and a small business is like a small town. In a small town, everybody knows everybody and he wanted people to know what he stood for. If people don’t like it this time and they fire him, okay. A day will come, he reasoned, when they are going to be in a situation where they need to get something done fast and will remember him because they know what he stands for. He radically misjudged the situation: the more he stood for those values and explained them, the more they resonated with people. If he hadn’t had the courage to put his career and reputation at risk, he never would have found out who the ideas resonated with.

Eric says it wasn’t until later that he understood the importance of iteration happening within the context of a long term vision. Today, people understand Lean Startup as scientific hypotheses, a testing philosophy, small batches, and pivoting or changing strategy without changing vision. They know it is logically incoherent to have a pivot if you have no vision. As Eric says in the quote though, companies who were early disciples of Lean Startup did not understand this.