What?

Flow is a positive psychology concept that was first proposed by the Hungarian psychology professor Mihaly Csikszentmihalyi (pronounced “CHICK-sent-me-high-ee”). It has since been widely referenced across a variety of fields, like education, sports and music, but I’ll focus on flow in the workplace, and more precisely flow in agile software development projects. It’s possible to achieve flow both individually and as a group, but my focus will mostly be on individual flow. Simply put, flow is a state of complete immersion in an activity. The world around you falls away, and, without making the conscious decision to do so, you lose awareness of all other things: time, people, distractions, and even basic bodily needs, like food or going to the bathroom. This occurs because all your attention is on the task at hand; there is simply no more attention to be allocated.

Before we dive into the sea of flow, I should probably point out that I’m not a psychologist by trade, nor do I have any training in the profession of psychology. But I’m a computer programmer, a line of work that can benefit greatly from flow. These are my own subjective observations based on my experiences from work and articles I’ve read on the internet. You might go as far as to consider what I write baseline knowledge, bits and bytes that you can use to achieve flow easier yourself, but not much more.

Why?

Happiness at work is essential. You spend 40+ hours there every week, and perhaps an hour or more every day going to and from work. It can be depressing spending this amount of time doing something that doesn’t make you happy. Through flow, it’s possible to be happier at work and happier with what you’re doing. Not only will you get a good feeling by achieving flow itself, but you’ll get important things done. You’ll also complete stuff more often, rather than starting and stopping frequently. All of this is hugely satisfying and rewarding.

It’s obvious, but it doesn’t hurt to say it anyway: A happy worker is a much more productive worker than an unhappy worker!

How?

In 1997, Csikszentmihalyi published his flow model, illustrated to the right. It shows how getting the right balance between challenge in a task and the skills you have to perform the task can help you achieve flow. If the balance is not right, say, for instance, that both the challenge and your skill level is low, you will not achieve flow. Instead you’ll fall into apathy. However, if both the challenge is high and your skill level is high, you can potentially achieve flow. We’ll talk more about these two conditions for flow in a minute.

But first: There are more than just a perfect balance of challenge and skills that are necessary to achieve flow. 16 years after Csikszentmihalyi, in 2013, Owen Schaffer, Lead Usability Analyst at HFI, proposed 7 flow conditions. They include Csikszentmihalyi’s “challenge” and “skills”, but also other conditions:

1. Knowing what to do
2. Knowing how to do it
3. Knowing how well you are doing
4. Knowing where to go (if navigation is involved)
5. High perceived challenges
6. High perceived skills
7. Freedom from distractions

In the world of computer programming, all these conditions - sans the condition covering navigation unless you have to maneuver through a complicated office plan to find a meeting room - are relevant. We’ll skip navigation in this context and break down Schaffer’s six other conditions:

Knowing what to do

If you have no idea what to do, the challenge of your task is way there on the top of the the Csikszentmihalyi model’s vertical challenge level axis. You have become the fortune teller, and you can be sure the your employer or client excepts you to tell their fortune with a 100 percent accuracy. An impossible task - you have to know what you are sitting down to do.

Agile software development methods say that you should not plan everything in detail up front, which is reasonable: After all, conditions change over time and what was a valid reason for a decision last week can be void today. But when you sit down in front of your keyboard with an actual (small) task, you have to know all the details to achieve flow. All clarifications have been done; you know with absolute certainty what you are going to do. If you find yourself in the unfortunate, but perhaps not unfamiliar, situation where the necessary clarifications have not been done already, or if you are unsure about anything, it’s your responsibility to do your best to gather the information you need before you start working on the task. Of course, additional questions might arise when you work on the task, but the more you know before you start, the better.

Knowing how to do it

Even though you might know what you are going to do, you have a problem if you have no idea how to do it. The task itself is perhaps described well enough, but you might simply lack the skills. The technology could be unfamiliar, or maybe the domain language is too complex. With a low skill level, you run the risk of apathy, worry or - in a worst case scenario - anxiety. To parry this problem, you should select tasks you are comfortable with compared to your skill level: The task should not be too easy, or you can get bored. Nor should it be not too hard, or you’ll start pulling out large chunks of your hair for no good reason.

All of this is sounds great in theory, but in the real world, finding tasks like these is usually very, very hard: It might be your first day on a new project, and you’ve been told to fix a bug that’s hidden somewhere in a dark hole of 10 years worth of legacy code. The domain language is totally unfamiliar to you and even though the code is written in a programming language you mister, it might as well have been written in Welsh (if you are, in fact, Welsh, the code is written in Greek). No matter how skilled you are in the particular programming language used, you’ll have a hard time achieving flow. This is a good time to seek out the help of a fellow code monkey, preferably one who has been on the project for some time. While working on the task together, there is a much higher chance you’ll both achieve flow: He or she knows more about the legacy code and the domain, you can shine with your impressive knowledge of the programming language.

More often than not, you will find yourself in a situation where you simply don’t have the skills to achieve flow, and there’s nobody around to help you out. In this case, you will eventually learn the necessary skills while performing the task, and can potentially achieve flow the next time you perform a task that requires the same or similar skills.

Knowing how well you are doing

Feedback, feedback, feedback. The more of it you get, the better. It might be from your employer, your client, a co-worker or from the programming technique you are using. In my personal experience, the more you involve the client, the easier it is to achieve flow. Involvement helps you both to better understand what to do and how well you are doing. And how well you are doing is often down to how well the client thinks you are doing. If you use SCRUM as your agile software development method, you probably have regular demos where you show the client what you have done since the last demo. But these meetings are too far apart. If possible, involve the client often, at least once a day - after standup might be a good time (because the product owner is present at stand up, right?) Frequent feedback ensures that you are always on the right path towards finishing the task in a way that will please the client. If the client is not available, or you desire additional feedback, a co-worker can also be a good source. This can be achieved with pair programming, frequent code review or simply by showing your work to another member of the team.

Showing your work and code can be intimidating, especially if you are like me; most comfortable in solitude with your headphones on. But breaking out of that shell can turn out be one of the smartest things you ever did. Showing your work to the client and a competent co-worker will provide you with constructive feedback, new ideas and a good indication on whether or not you are solving the task you are working on correctly.

Another way to get a lot of feedback is Test Driven Development, TDD. The technique relies on a very short development cycle: First the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Instant and continuous feedback from your code. Keep in mind that TDD shouldn’t be a substitute for getting feedback from the client or a co-worker when you work on a task - it doesn’t really matter how excellent your tests and code are if they don’t solve the actual task.

High perceived challenges & High perceived skills

We’ve already talked about this, but it might be even easier to understand with a practical example: In game design, both computer games and board games, designers try to find a perfect balance between game challenge and player skills. This relationship between challenge and skills is referred to as the learning curve. If the learning curve is too steep, many players will find the game too hard to learn and master and will soon lose interest. The same is the case if the game is too easy - there’s no real challenge, the player’s skill level quickly becomes to higher than the challenge and the player gets apathetic or bored. If the balance is just right, however, the game designer has done his or her job perfectly: The player can easily become totally consumed by the game, unaware of time, people and distractions.

Exactly the same goes for tasks you do at work. And with a perfect balance between challenge and skill, your skill level will increase over time, enabling you to take on even harder challenges. By constantly balancing on the edge of your skill level, you will learn new things, and learning while at the same time feeling that you are mastering can contribute greatly to flow.

Freedom from distractions

This is an important, and unfortunately often ignored, condition for flow. If you look at ten random minutes of your work day, in what ways are you distracted and how many times? E-mails, instant messages, SMS messages, the sound of the coffee machine grinding beans, a cell phone ringing and a heated discussion between co-workers next to you. I’m betting you are distracted at least once every minute. In the conditions described here, it’s impossible for most of us to achieve flow. So you have to get rid of all these distractions. Turn off your e-mail notifications, put your cell phone in silent mode, log off all the instant messaging services, move the coffee machine out of the office space (this will also mean more exercise to get to it, which is another good thing) and create a separate room where people can have heated discussions without disturbing their co-workers.

Putting the cell phone in silent mode and turning off the e-mail notifications can make some people a little uneasy. Relax. You are not that important. It’s perfectly safe for you to go offline for a while. What you might experience, however, is the need to educate some of your co-workers. Most companies use Exchange as their e-mail service, and Exchange immediately notifies you when you receive an e-mail. This has caused many people to view e-mail as instant messages: As soon as they’ve sent an e-mail, they assume the receiver reads it. And this, in turn, cause them to except an immediate reply. If you run into a co-worker who is annoyed because you didn’t reply to an e-mail immediately, tell them you’ve turned off instant e-mail notifications and of course why you’ve done it. This could help as your co-worker should no longer expect you to reply right away. But it might also backfire: Instead of sending e-mails he or she will simply show up at your desk and poke you on the shoulder. This brings us to the next great distraction for flow: People.

In some cases, you might have to go to great lengths to remove distractions: The open plan offices most of us work in today can be a killer for flow. Even though you’ve managed to turn off every other distraction, like your phone and e-mail, people are hard to turn off. In an open plan office, there’s no office door you can close to indicate that you do not want to be disturbed. It takes a little more effort and planning than that. People have to be informed that you are trying to achieve flow. This can be done by placing a token of some kind on your desk. Or perhaps put on a cap or a hat. Tell people that when the token is on your desk or the hat is on, you do not wish be disturbed. Doing this can feel a bit rude; but it’s not any worse than closing the door to your office, and most people have no problem with that, right?

Wrapping up

Achieving flow is hard. Even though Schaffer’s seven conditions for flow are fulfilled, there’s no guarantee it’ll actually happen. There can also be an direct economical cost associated with flow: Perhaps the office layout has to be changed or the coffee maker replaced with a model that doesn’t sound like the building is falling apart every time someone makes a cup of coffee. In addition, there might also be sociological consequences in the process of learning how to achieve flow. Many offices have a resident chatter box, that person who needs to talk to someone all the time. Unless the talking is actually contributing to the flow - or work - in some way, the chatter box has to be told to take a break, a message that can, in worst case, be considered as a personal insult. I’m not saying that you should suddenly refrain from all non work-related chatter in the office, of course, this kind of interaction is an important part of crowd psychology and group dynamics, but politely telling people that you are trying to achieve flow and asking them not to disturb you for a while should not be a problem.

Even though achieving flow is hard, you might eventually learn how to achieve flow quickly and often. But don’t expect to stay in the flow zone all day, especially if you’re working as part of a team. If everyone is just sitting in the zone all the time, there won’t be much of a team left and a being part of a great team is important for happiness at work. Techniques for achieving flow might be hard to explain and justify to the management, and compared to the negative number on the invoice for the new coffee maker, the positive effects of flow can be hard to measure. But it’s my claim, supported by the research of Csikszentmihalyi, Schaffer and others, that by achieving flow, you will get more stuff done, learn new skills faster and generally feel happier at work.

So why not try it now?

Sources

• Wikipedia: Flow (psychology)
• Leo Babauta: 9 Steps to Achieving Flow (and Happiness) in Your Work
• Coert Visser: Good Business: Leadership, Flow, and the Making of Meaning
• Wikipedia: Mihaly Csikszentmihalyi
• Wired: Go With The Flow
• Rogish Reading Writing: Open Plan Offices Must Die!
• Verywell: What Is Flow?
• MindTools.com: The Flow Model