Over the last 5 years at Eagle Eye I’ve seen our teams grow from being a rather unstructured hodgepodge of talented individuals, innovating under pressure and sometimes seemingly on a whim to bring new ideas to market, to where we are now, working as largely autonomous Engineers within an Agile framework to deliver a backlog of well refined and prioritised feature and technical requirements.
As we’ve grown, and become more structured and process driven, we have also had the space to reflect on lessons learnt, and to think more broadly of all of the factors which contribute to functioning as cohesive teams of highly engaged Software Engineers.
Every Software Engineer is familiar with the Flow state – that state of mind, associated with a feeling of confidence in your abilities as you are applying your skills to a challenging and interesting problem. You begin to lose track of time, feeling ‘in the zone’ as you work through complex relationships and dependencies in your head – sometimes reaching that crescendo of the 'Eureka' moment when the solution materialises. It is a great feeling, you have been stretched by just the right amount – not too much where the problem is too complex, just the right amount, taking a few risks, making a few mistakes and being able to respond in the moment to self-correct. As you work to code your solution you feel deeply involved and ‘at one’ with the codebase, it’s clear to you what you need to do, you’re doing something new and interesting, applying your creativity and if you’re left alone without interruptions you can achieve so much, even forgetting to eat lunch as you are totally immersed in your work.
Writing is something I enjoy personally, and as I’m writing these words I can actually feel myself entering into some sort of Flow state, feeling more alert as my mind is searching for the right way to convey the premise that all work environments can be improved by considering the employee experience in every decision we make. To some extent we are all in servitude to the economic treadmill, a tiny part of a global financial machine which demands continual growth, but there are the beating hearts of human beings at its core, with their myriad of needs, passions, dreams and desires – it is folly to neglect our common humanity and our thirst for self-actualisation in our endeavours to keep the treadmill moving.
Pattern recognition, seeing connections and associations between disparate elements of a problem, is a key faculty of a good Software Engineer. The Flow state is particularly good for enhanced pattern recognition. And it’s the recognition of causal patterns rather than correlational patterns which is a particularly useful characteristic of Flow. This is what gives the rock climber that ability to naturally envision the holds required to traverse a tricky ascent, and the experienced speed chess player the skill to ‘think’ ahead – it’s not cognitive computation and planning, it is intuitive pattern recognition which is key. Perhaps this is why Software Engineers are often fanatical gamers – that deeply embodied feeling of being in the zone in the midst of a frantic game of Quake is the kind of highly attentive state we would want to replicate when working through a problem in code, although perhaps without the fear of being zapped by someone with faster fingers on the network.
In our Software Engineering department at Eagle Eye we see Flow as the ideal state to strive for. In Flow, your performance levels are high, but you don't even feel like you're working hard, you're effortlessly riding the perfect wave, walking the fine line between chaos and order - we're lost in the experience, tapping into something beyond our normal state of consciousness - Yogis and mindfulness practitioners urge us to be live more in the present moment, well there's nothing that feeling of Flow that is more present, more now, where worries about the future or sombre reflections on the past are far from our minds and we're focused on what we're loving to do with complete absorption in the here and now, as the parts of the brain concerned with time and the networks involved in reflective self-consciousness are quietened.
But we’re also realistic, work can’t always be like this, there are also the mundane and repetitive tasks that are part and parcel of maintaining any sophisticated software platform. Through awareness, and having a language and forum to talk about these things we can at least see where we are at any given time compared with where we'd ideally wish to be.
Flow happens when you feel a natural pull towards something – it is an emergent phenomenon, the intersection of hard work, personal joy, and meaning. Flow can’t be artificially created, it’s a natural state of harmony, of balance, of homeostasis or equilibrium – it is an inner personal experience which cannot be imposed by a manager – you can’t be told to ‘go into the Flow state’. But we can intentionally create the kind of conditions which will increase the probability of inducing the Flow state. We can think about our wider eco-system, our environmental conditions as well as our personal eco-system of everything that makes us human – we are a complex system of cells and organs, each with a variety of functions which are connected through blood vessels, capillaries and nerves, all directed by conscious thought and unconscious autonomic responses to stimuli. We're a crucible of electro-chemical signals, a living expression of that ineffable consciousness which we all feel but can’t explain. How we experience the world is determined by our environment and our unique responses to that environment. So, what actions can we take to improve our probability of experiencing a state of Flow consciousness?
The authoritative work into understanding Flow triggers, those factors conducive to finding Flow, has been documented by Mihaly Csikszentmihalyi, the Hungarian-American psychologist who first recognised Flow as a discrete psychological state. Steven Kotler, in his book ‘The Rise of Superman’ built upon this original work by examining the ‘in the zone’ experience of extreme sports people. Scientific research has been conducted in Jamie Wheal's Flow Genome Product and referenced widely in loquacious bursts of inspiration by the self-styled performance philosopher Jason Silva. Flow is also referenced by Canadian cognitive psychologist, John Vervaeke in episode 2 of a 48 episode exploration into the historical narrative, available on YouTube, which has led us into being zombie like creatures disconnected from the true meaning in life.
My approach to having a Flow discussion with our Engineers and people around the business who care about employee engagement has been guided by a synthesis of these thinkers. We've taken these insights and implemented a practical, albeit subjective, methodology of deriving individual Engineer’s experiences of Flow, and related states, during a fortnight of delivering the work we have committed to within a single Sprint. We have taken the Flow triggers indicated by the aforementioned thinkers and repurposed them towards the work of a Software Engineer:
In addition, there are conditions which are necessary when working in teams, striving for a feeling of Group Flow:
Our methodology is to review a Sprint by talking through the factors above in relation to the sprint tasks to subjectively score our experiences over the previous fortnight. We produce a final Flow rating by attributing the time spent between the states in the chart below, derived from the work by Mihaly Csikszentmihalyi.
So perhaps the Engineer committed to a challenging task in a domain where they have had little previous exposure, they therefore may have relatively low skill levels which in the face of the difficulty of the challenge, puts them in a state of Anxiety. But as they begin to learn the domain and understand the problem they move into a state of Arousal, and finally acquiring the pre-requisite knowledge to deliver the solution in a state of Flow.
Equally, they may feel underutilised, applying their high skill levels to a mundane or familiar problem and land in the Relaxation or Boredom categories.
We apply a weighting to the categories where the percentage of time spent in the undesirable category of Apathy is multiplied by zero, percentage of time spent in Arousal or Control is multiplied by 0.75, time spent in Boredom or Worried is multiplied by 0.25, time spent in Flow is multiplied by 1, and so on.
This gives us a handy metric to measure subjective engagement levels for the individual, the Sprint team, and the whole department.
Getting Engineers to introspect about their thoughts and feelings during a sprint doesn’t come naturally, we can be quite an introverted and sometimes cynical about anything ‘woo woo’, but we’ve worked hard to create an environment of trust and a way of talking about our experiences which has enabled these kind of conversation to take place in an atmosphere of psychological safety.
The data gives the ability to react very quickly, to discover issues we may have been otherwise unaware of and to ensure that those with the power to make the necessary environment tweaks to improve the life of an Engineer are informed and empowered to make changes.
We’ll never reach perfection, but through applying the Agile principles of Inspecting a situation to uncover the truth, and iteratively making the necessary Adaptions we are creating an atmosphere where people feel they are being listened to and their unique human needs are being accommodated – this feeling of consideration engenders feelings of goodwill towards one another. There is nothing more motivating than working with a colleague who finds it natural to get into the Flow state, something which we absorb into ourselves through a kind of psychological osmosis.
Our data gives us trends over time, it exposes our limitations, it highlights problems and can be used to support justifications for change. Perhaps thinking about who could benefit the most from an upcoming piece of work requiring some deep lateral thinking, or what to do about someone who has had several sprints in a row doing repetitive maintenance work.
In addition to thinking about the environmental factors that we can tweak to promote Flow, we have also thought about how we can help people to help themselves. We’ve taken the temperature of people and shared the readings with the teams, and this has led us to ask what more can be done to apply the ‘Physician Heal Thyself’ mantra. With this in mind, some teams have found it beneficial to share and discuss their Flow ratings in their sprint retrospectives, to find their own ways to Inspect and Adapt.
We have also instigated Personal Development Plans for every Engineer to assess their levels of Autonomy, Purpose and Mastery towards their work and to identify opportunities for personal and professional growth in one-to-one sessions and as an ongoing discussion.
The point here is that by considering every Engineer as a unique individual, with unique strengths, passions, insecurities and needs, we can try to tap into what will really make them tick as an engaged employee, working as part of a cohesive team where we are all trying to be more aware of our impacts on one-another in order to grow as a symbiotic organism…
We’ve found that through simply having the regular discussions around Flow and collecting rudimentary data, that we have been able to make informed decisions justified around the need to deliver good quality work in a pressurised environment while doing whatever we can to optimise employee engagement. This has helped us to retain skilled staff and identify new opportunities for growth. It has been particularly helpful to ensure we were doing the right things when navigating the constraints imposed by the government’s response to the Covid-19 pandemic as we already had a solid baseline of metrics and a mature measurement methodology that has been unanimously accepted by the Engineers as being designed with their own interests in mind.
The next ‘nice to have’ would be a handy little app to be able to record, analyse and share our Flow data more easily.
My personal raison d'être at Eagle Eye is to create an eco-system where we can all thrive and Flow. Being able to ‘manage what you measure’ is a vital ingredient towards this goal.
Author: John Durrant, Head of Software Engineering