4 Ways to Optimize an Agile Environment with Nudge Management

From a Behavioral Economic Lens

What if I told you, we could subtly tap into the unconscious mind to improve working conditions and productivity? Well, we can with something called nudge management. Today, we are going to cover what nudge management is, and four ways you can apply it in an agile environment to make for a happy team.

Nudge Management — What is it and Where did it come from?

First, let’s start with a solid definition.

Nudge management is a management approach that applies insights from behavioral science to design organizational contexts so to optimize fast thinking and unconscious behavior of employees in line with the objectives of the organization. -Erbert and Freibichler 2017

Unconscious behavior? Let’s break this down. Nudge management was inspired by thinking of the mind as two very different processes. Psychology knows this as the dual-process theory. The first process is the unconscious process. The second process is the conscious process. The unconscious process is our emotional/intuitive side, while the conscious process is our logical/reflective side.

I look to metaphors to better understand concepts. The elephant and the rider metaphor refers to our emotional side as the elephant and our logical side as the rider. Often we go through life as the rider, believing we are in control as we rely on reason to guide us. At times, the elephant overpowers the rider, and our emotions take over. Our emotions may even cause turbulence. We react in ways we do not understand. We may behave irrationally. For many of us, our emotions remain unconscious unless a person works hard to bring the unconscious to the surface.

What are Knowledge Workers?

Another term to understand is knowledge workers. Knowledge workersare people whose job requires them to think for a living. At Echobind, our team is paid to think and solve problems. As an account manager here, I often consider how I can improve the working conditions for my team so they can solve problems faster and make our clients happy. When I came across an article on how to increase knowledge worker productivity, I was pleased to discover that we are already implementing 3.5/4 of the suggestions.

4 ways to Optimize an Agile Environment

Now, let’s dive into the four ways you can optimize an agile work environment to tap into the unconscious behavior of your team.

1. Improve Meeting Productivity

Is it me, or do people dislike meetings? It is no wonder that they do when approximately 50% of knowledge workers’ time is spent in meetings (Erbert and Freibichler 2017). On one hand, it makes sense that a knowledge worker such as a developer needs to be in meetings. They need to give their daily reports and any blockers they are facing. They need to share knowledge with other team members on the project. Software is not created in a vacuum, so a developer cannot work solo all the time. But, the code must be written. This cannot happen if a developer’s time is consumed by meetings. So what can be done to improve meeting productivity?

Meetings — We do them well. We do not have meetings to have meetings. As an account manager, it’s my job to have an agenda for every meeting to keep everyone on track. If I cannot write an agenda, it is a good indicator we do not need to have a meeting. We do not schedule follow up meetings. Instead, I spend some time after a meeting creating action items. This is a win for everyone because I love making checklists and my team can get back to work. The best part — they do not have to worry about attending a followup meeting to talk about what was discussed at the meeting prior.

Standups — an agile necessity. Something I like to do is have my team post a written status in Slack instead of video conferencing (yes, we are remote). This allows them to post their updates when it’s convenient for them and is less note-taking for me. Another win-win. A tool I recently starting using is called Status Hero. I highly recommend it. My favorite feature — it prompts your team to include an emoji about how they are feeling. You can bet I am interested in the feelings of my team. 😉

The article suggests a different approach to improving meeting productivity. They suggest changing the social constructs around the default of meeting times. The norm or default duration of a typical meeting is 60-minutes. They say to change the default duration to 30-minute meetings. At Echobind, we schedule the appropriate amount of time for the task at hand. This goes back to what I said about not having meetings just to have meetings. Don’t schedule a meeting for 60 minutes when all you need is 30 minutes. However, what the article is saying is, by changing the expectations of what is considered a typical meeting length, more people will comply with this organizational construct because they will not want to stand out as the one scheduling long meetings. If you build the construct, professional people generally try to follow it.

2. Improving Planning

Being that one of our core values at Echobind is transparency, I’ll be honest — planning is an area I would like to help my developers improve in. No, I am not saying that developers are poor planners. Many developers are INTJs — the J standing for judging, which makes them exceptional planners according to the Myers-Briggs Type Indicator. Let me tell you specifically what I mean. In my experience, developers are too optimistic about what they can get done. This makes trying to plan a sprint a nightmare for me. It is not their fault though. Many people do this, and it has nothing to do with being a developer. It is known in psychology as the planning fallacy. It is the occurrence of people underestimating the amount of time a task will take due to being overly optimistic.

The article suggests using implementation intentions as a remedy. The article states that

…the idea is that employees plan and openly communicate their key objectives, thereby committing themselves to these plans in front of their peers.

In my opinion, a sprint planning session does just that. The developers break down the task, assign it a point based on the complexity (we use the Fibonacci scale), and then someone takes ownership of the ticket in front of their peers. So, why does this not work? It all goes back to the planning fallacy. So here we find ourselves in a loop. And not to knock the authors’ suggestion, but I may have an alternative solution. I propose that developers should be empowered to self manage their expectations through reflection.

How to Empower Self Management

To self manage, they need to evaluate their estimations with the goal of becoming more aware of their accuracy. They will need candor and a way to track time. When a developer picks up a ticket, they should start time tracking, account for breaks, and once the ticket is complete, they should reflect upon the accuracy of the estimation by leaving a note on the ticket. They could simply indicate: accurate or inaccurate. Developers should be familiar with this, it is just like a boolean, either true or false. Let’s follow that up with an if statement. If false (inaccurate), indicate what it should have been. You may have noticed that I bolded account for breaks. Yes, developers need breaks and they should include them in the time tracking. Usually the more complex the ticket, the more breaks they need. I have heard developers say a countless number of times:

It was when I walked away that I solved the problem.

3. Improving Task Productivity

I mentioned earlier, a productive developer is a happy developer. Many of the developers I have worked with and know in my personal life enjoy productivity for the pure sake of being productive. Not only that, but they also need to be to get their work done. According to the article,

Unplanned interruptions are among the most effective productivity killers for knowledge workers.

Unfortunately, there are many workplace interruptions in an agile environment with one of the main ones being Slack. Don’t get me wrong. Slack is great. But with all the notifications sounding off, it sure can stomp on productivity.

So, how is a developer to achieve a sense of deep work? At Echobind we have Slack etiquette that helps eliminate unnecessary messages. This ultimately leads to higher productivity for our team.

1. We encourage the team to set their status during our core working hours instead of messaging a specific channel or person(i.e. relocating, taking the dog out).
2. We ban using @here or @channel unless it is urgent.
3. We encourage thread-use to avoid clogging up channels with conversations. That way people are not reading things that do not pertain to them.
4. We have a #life channel. It’s optional to join. If you want to see pictures of your co-workers’ dogs or kids — great! If you don’t — great. We leave it up to each individual to decide.
5. We encourage people to close Slack or use the “Heads down” if they don’t want to be interrupted.

4. Knowledge Sharing

We love sharing at Echobind. Especially, knowledge. I have found that many of my co-workers have diverse backgrounds. The more I get to know my team, I am blown away to discover all the hidden gems. Just recently I discovered that one of my co-workers, Joe, has a background in marketing and almost pursued a master’s degree in Italian linguistics. You can bet I run to him when I need to come up with something catchy for Twitter!
The point being, we all have knowledge and experiences that make us experts in certain areas and we do our best to capitalize on this.

Some ways we do this are:

1. We have a Today I Learned or #TIL channel in Slack. (We also have a monthly This Month We Learned Blog post where we share some of these learnings with you!)
2. We have lunch and learns.
3. We encourage our team to make write-ups/case studies if we learned something new on a project.
4. We have something called investment time. Read more about it here.
5. We have a 15-minute rule. If someone is stuck on something for more than 15 minutes, they must seek help.

Knowledge is wealth. I am glad to work somewhere that nudges us to share the wealth.

I hope you enjoyed looking at Echobind from a behavior economic lens. I encourage you to look at your workplace and see if any of these nudge management tips can be generalized to your work environment. If you end up implementing anything, leave me a comment and let me know how it went. I would love to hear from you! Remember the subtle effects of nudge management may be hard to detect at first but it’s worth the thought.

Resources

Ebert, P., Freibichler, W. Nudge management: applying behavioural science to increase knowledge worker productivity. J Org Design 6, 4 (2017) doi:10.1186/s41469–017–0014–1