Performance Zones

I couldn’t make it too long into a management gig without a post on people management, right?

Helping people thrive in their careers and grow their skills/capabilities is, in my mind, one of the most important aspects of people management. Yes, there is a critical business delivery component and no, you can’t always let people work on only the exciting stuff. As much as possible though, it’s beneficial to help people take on new challenges. Developing people in your team and your organization helps them become more capable of taking on those critical business deliveries as the demands from your team shift and expand.

I like to visualize it as follows:

This is my own opinion with no scientific background, though it’s modelled slightly after overtraining

These zones are not always linear, and don’t necessarily grow linearly. Due to personal circumstance, energy levels, and a myriad of other personal and professional factors, these zones can fluctuate wildly. Some days, no matter how trivial the task, you’ll be stressed out. Other days, no matter how exciting and invigorating, you’ll be bored and a little bit disengaged. This is not a failing – it’s being human.

In an ideal case though, the amount of challenge one can take on increases over time :)

Understanding the Performance Zones

Reading the titles of these zones as I’ve poorly named and coloured them, it would seem obvious that “Engaged Zone” is the optimal zone and that all other zones are bad, right?

I disagree. In my mind, NONE OF THESE ZONES ARE BAD (in small doses), and everyone should experience all four to a varying degree.

Bored Zone

At the bottom of the chart we have the Bored Zone. This is where an individual on your team is not challenged and simply going through the motions. Maybe the work you’ve given them isn’t interesting. Maybe they’ve mastered what they’re working on and are ready for a new challenge. Maybe they’ve just been working on the same thing for too long.

The Bored Zone is an essential one. I’m of the firm belief that boredom sparks creativity and ingenuity. If you give a senior developer a boring repetitive task for example, you can almost guarantee that they’ll find a way to automate it or eliminate it altogether.

It’s also an important rest zone. Sometimes if a developer has been overworked and stressed for too long, giving them some simple boring tasks can be a useful way to help them get on-the-job rest. It can be refreshing to do some simple work, and the shortened action->reward cycle of a small task can have a positive impact on them. Have you ever tried zeroing out your inbox? Do you remember that sense of accomplishment doing a menial task to the tune of some music before checking it off your list? Yup, that’s the Bored Zone at work!

Engaged Zone

The Engaged Zone is where people do their best work. It’s a comfortable state of being where someone is capable of doing their work and enjoys doing it. Some people want to stay in this zone indefinitely. I don’t think that’s a bad thing per-se, but note that the capacity for boredom increases over time. Someone doing the same thing they’ve always done for too long a period of time risks slipping into the Bored Zone.

This is where you want to keep your developers most of the time. This breeds the most happiness, engagement, and sustainable output from your developers. Consider this your developers’ core skills in their role.

Stretched Zone

The Stretched Zone is a fine line between the maximum of what an individual can handle and being overwhelmed. This is where you’re giving someone a new challenge. It could be more work, harder work, more complex work, or anything else of the sort. Those seeking growth should regularly push into the stretched zone. This is where people learn, grow, adapt, and develop the most.

You’re challenging them to do something new. This requires expanding upon existing skills and/or developing new skills. It’s not always comfortable, but it is useful change and growth.

Stressed Zone

The Stressed Zone is, simply, overexertion. It’s too much, to the point where someone can become overwhelmed or burnt out over time. Much like boredom, I feel like a temporary spike into stress and fatigue can spark creativity and ingenuity. If you give a developer something overly challenging, they will be forced to adapt, compensate, or get creative. It’s the Streched Zone amped up even higher, but risks burning out much faster.

I would expect someone’s jourey through these zones to look a bit like this:

The key is that they’re spending most of their time in the Engaged Zone, occasionally dipping into the others.

Personal Experiences

When thinking about these different performance zones, I like to reflect on my own career and remind myself how each of these have helped me.

Bored Zone

I hit the bored zone towards the end of my tenure as a lead developer on APIs. My team had put in plenty of work to build a core set of internal and external APIs for interacting with our domain. Hexagonal architecture? Implemented. World-class documentation? Already written. Unit test coverage? Literally the highest in the company. Code autogeneration? Implemented.

Simply put, there was little left to do. The project was complete, and we were iterating on and improving it in a stable and predictable manner. It took us almost two years of hard work to get here, and it was fun for a few sprints to see the fruit of The work was getting done, but it was no longer exciting or engaging. I remember sitting at my desk one day after a backlog refinement session and thinking “is that it”?

Sitting in the bored zone was the spark I needed to pursue further career growth.

Engaged Zone

It’s hard to pick just one example, because this is where I feel developers should spend the majority of their time in a role. I believe your time spent here is directly related to your job satisfaction, and that incrementing responsibilities/workload on a basis that’s suitable for you.

The engaged zone is where I feel in the zone.

Stretched Zone

Rewinding the clock from my previous story, I found myself in the stretched zone when I first took over the lead position at that company. I had been a lead developer before, but at that time I was only ~3 years into my career and frankly speaking not experienced enough with either technology or people to be effective. I spent a few more years in a senior role at a new company, with the explicit goal of becoming a lead developer again.

I found myself in a lead developer role again not too long after. Our team wanted to move from “just go get it done” to actually providing estimates and communicating deliverables and timelines to stakeholders. We did this with Scrum, and being the chatterbox I am, I was given those responsibilities. It was a challenge at first, but a rewarding one no doubt. It gave me a chance to flex my personality a bit more, and do more than just ship lines of code. I had to take on Scrum Master duties, and learn to balance my own deliverables with unblocking the team. For the first time in my career, I was not only producing code but helping others produce code more efficiently.

The stretched zone helped me expand my skillset.

Stressed Zone

People Management. Thanks for reading!

No, seriously though, that first foray into people management was an eyeopener. Suddenly there were more stakeholders, more meetings, more accountability, more meetings, more interpersonal issues to solve, more meetings, more admin tasks, more meetings, and more. Did I mention there were more meetings?

Anyone who knows me now may think of me as an organized person (zero inbox, Slack channels carefully curated, updated calendar, detailed to-do list, diligent notetaking), but that was not who I was when I first jumped into people management. Sure, I took some notes down on paper, and yes I made sure to update my calendar, but the idea of a to-do list was mystifying. Wasn’t that the purpose of the sprint board? Zero inboxing was equally foreign, because I could usually just glance at my inbox and tell what was from the build agent and what was from a co-worker or adjacent team.

The initial firehose of information was overwhelming. I had information overload and, as a new manager, lacked the heuristic to filter out the important from the noise. Admist this overload of information, I sought out anything I could – mentors, books, articles, tech-talks, blog posts, etc. If it existed, I consumed it. I tried Trello boards, paper notes, creating blocks for everything on my calendar, sticky notes all over my monitor (no passwords, I promise!). Eventually, I found a system that worked for me. It was stressful, and there were days I wanted to give up and go back to my IDE, but in the long-run those skills have made me far more effective. Without those, I don’t think I’d have found a way to commit myself to maintaining a monthly(ish) blog, after all.

The stressed zone forced me to improvise, adapt, and overcome.

Applying These Zones

I try to keep mindful of these zones when I’m managing my direct reports. It’s as much an art as it is a science, and it’s not something you always get right. Getting to know your direct reports and understanding their skillsets, strengths, weaknesses, ambitions, development paths, etc is key to making this work for you. I’ve been fortunate enough to help guide struggling intermediate developers into senior+ roles and guide seniors into managerial roles by tactfully applying these principles and giving them the appropriate challenges (or lack thereof) where I felt it was needed. Regular touchpoints and appropriate levels of guidance and support are needed to make this work, especially when you’re pushing someone outside of their comfort zone and potentially causing tolerable/manageable stress.