Many business leaders hesitate when you ask them to share their biggest mistake. Not Cynthia Maxwell. She keeps hers front of mind. In fact, she turned it into a management tool that she uses every day.
Back when Maxwell was the Director of Engineering at Yahoo!, she was tasked with building a brand-new, multi-platform messaging product. It was the type of big, ambitious project engineers want to sink their teeth into — and she easily recruited one of her former coworkers from Apple.
Then, one day, after a few months, he told Maxwell he was returning to Apple.
There had to have been a red flag, so she stepped back to examine the broader context: Her team was building a flagship application, and carefully integrating stakeholders in design, engineering and leadership. She was deeply plugged into precise metrics like scrolling speeds, crash rates and memory usage. Eventually though, she realized the problem was less about the work itself, and more about how her people were feeling about doing the work. If she only had a clearer line of sight into how they were feeling, she could have responded better and earlier — and perhaps retained that talented programmer.
Resolved to never again lose a great developer unnecessarily, Maxwell turned her engineer’s mind to the gaps in her management tooling. She was missing a way to turn emotion into data, and she found it in an unexpectedly fuzzy place: the age-old concept of flow.
In this exclusive interview, Maxwell, who’s held engineering management roles at Slack, Apple, Yahoo! and Pinterest, explains how she built a concrete evaluative framework around flow. She shares the simple graph that has become one of the most powerful resources in her management toolkit. And she describes how anxiety and boredom creep into a team, and how managers can supportively nudge engineers back into the ideal state of flow.
As she grew from one management role to the next — leading interns and architects alike — Maxwell had always cared about her engineers’ feelings toward their work. But she kept bumping up against the limits of conversation. “No matter how strong your toolkit is for effective one-on-ones, not everyone will open up right away,” she says.
I've been at three companies that scaled 5x while I was there. At that speed, a "slow boat" to trust won’t cut it. You have to teleport to it.
She needed a way to assess job satisfaction quickly and candidly. First, though, she had to find a framework for more clearly defining satisfaction. The tools in her work life — from NPS to qualitative satisfaction surveys — didn’t quite capture it for her. In looking for an answer, her mind would shift to her off hours as a yoga aficionado and DJ, during which she’d experienced firsthand the power of flow.
Indeed, the term is often associated with artists and athletes, who are understood to do their best work when they’re “in the zone.” Gamers, too, might intuitively understand flow; it has been applied to game design for years, where deep user engagement is the benchmark of success. But how to channel this as a manager?
“My goal is to try to create what Csikszentmihalyi, the psychologist who defined flow, calls ‘autotelic jobs,’” says Maxwell. “I have a quote of his here: ‘The more a job inherently resembles a game — with variety, appropriate and flexible challenges, clear goals, and immediate feedback — the more enjoyable it will be regardless of the worker’s level of development.’”
Maxwell had experienced flow at work, too, so she knew it was possible. “I can recall a few times where I thought to myself, ‘If I won the lottery tomorrow, I would still come into work.’ That’s flow,” she says. “Truth is, it doesn’t have to be the lottery. It can be an offer from another company, the call of launching a startup or any number of professional gravitational pulls. It’s about basic retention. That’s how vital it is to help your team members experience — and create — a sense of flow in their work.”
The immersive, pleasurable state of flow is hard enough to describe, let alone generate and track. “As a manager, I wanted to find ways to recreate those moments for my team,” says Maxwell. Around that time, she took the Search Inside Yourself training, based on Google’s Chade-Meng Tan’s popular course. On the second day, during a discussion of flow, she saw a deceptively simple X-Y graph, and things began to click. She’s since adopted, added to and iterated on it to fit her needs as a manager and to use in 1:1s she has run members of her team:
At its most basic, the process is simple: during 1:1s, Maxwell asks her reports to mark the above graph to indicate where they are professionally. The version her team sees is stripped down to just its X- and Y-axis descriptors and the “flow beam.” Terms included above, like “apathy” and “boredom,” are just for her reference. Using them in conversations would drain some of the objective, quantitative value from the exercise.
Instead her reports see this more simple version of the chart:
Maxwell’s job is to help guide her team into that effortlessly productive state, where skill and challenge meet: flow.
New tools are rarely completely comfortable right out of the gate (this one was no exception), but it did resonate with the engineers on her team. “It sounds silly, but the familiarity of the axes and slope helps. It feels as much an equation to solve as an emotional state to plot,” says Maxwell. She’s found that extroverts discuss with curiosity and introverts like the boundaries that the graph sets. “It suits both personality types. Externalizing a question that has a lot of importance into something non-threatening like a graph works for both extroverts and introverts.”
It was also better for Maxwell. Where she was once digging fruitlessly for nuggets of candor in 1:1s, she suddenly had data, collected periodically, that led her to insights. “I realized that sussing out your team’s satisfaction doesn’t have to be a gut feeling. You can actually capture a moment in time, track it over sessions and get a sense of the trajectory of one’s flow. It helped me calibrate when I needed to be concerned and tweak the direction of a person’s course of work.”
This is not a performance evaluation. This is a performing evaluation. The question is: how I can get you more into your work, not get more work out of you?
And that means also adjusting how she manages. “It’s not a secret. I tell my team this is a tool for two-way evaluation. As your manager, my goal is to keep you in a flow state. This exercise shows me how I’m doing,” says Maxwell. “It’s not only about how my team is doing, but what I’m doing to support them. I tell my reports: ‘I want to be able to ask you how you feel about your work periodically, so that I better understand how to support you in an ongoing way.’”
Even simple tools benefit from best practices, and Maxwell has developed a few to help her get the most out of this experience with each report:
THE TOOLS: Maxwell uses Google Sheets, for a couple of reasons. Thanks to its easy version control, she can quickly glance at each person’s history to see how their marks have moved. When meeting with remote employees over video, it also helps her simulate the experience of using this tool in-person together. She can see what they’re doing in real time.
THE TIMING: For optimal results, Maxwell likes to randomize when she asks her team members for their input. When you ask, and at what intervals, is somewhat up to your intuition. You’ll want to at the end of a big project, for example, or following a particularly grueling sprint.
While it might be tempting to simply make this a weekly task, Maxwell cautions against it. “Let’s say I’m an engineer doing this every week, and I don’t see my dot moving. I might start to infer something really negative, and think, ‘Oh, forget this job.’” It can take a little while to get back into the flow zone once you leave it; often it takes moving to a new project, which then needs time to ramp up. “I wouldn't want someone to jump to a conclusion because they weren’t moving quickly enough, and start to be too hard on themselves.”
She likes a cadence on the order of every two weeks. For new hires, she waits three weeks to first roll out the graph, to give them time to complete onboarding and start getting up to speed on a project.
THE PROCESS: Maxwell typically saves this exercise for the end of a one-on-one, once her report has had a chance to bring up whatever issues they brought to the meeting. “In the last ten minutes, I’ll ask them to fill it out. Once they’ve placed their mark, we talk about it.”
Her prompt is typically a simple, high-level question. “It’s usually something like, ‘How do you feel about the work that you're doing right now?’" She asks team members to consider the time period since they last completed the exercise. She’ll wait until they plot a point before they discuss. She’ll have the digital version of the last few completed exercises on her computer, so she can pull in context and discuss trends, as needed.
Ideally, Maxwell wants to see all her reports land on the “beam,” that diagonal where skill and challenge match. “People should feel like they know more this month than they did last month, so they're moving to the right all the time. Meanwhile, they should feel like the tasks you're giving them are bigger and more important, growing more challenging at the same pace as that move rightward.”
But realistically, achieving and maintaining flow is a necessarily dynamic process. “You want to push your team just a little bit into anxiety and hope that they move back into flow over time.” There are the rare people who can stay right in the middle of the graph indefinitely. “And that’s cool, as long as long as you keep pushing them out of their comfort zone.” But the vast majority of paths will look more like a staircase — up from the “flow zone” and over back into it, over and over again.
The secret is not to let people get too far out into the anxious or bored states. A little is a good sign of growth. Too much and you risk losing them.
Perhaps more important than recognizing flow, then, is recognizing its absence. Typically, engineers who fall out of flow will land in one of three common ruts:
Apathy — Low Skill and Low Challenge
Maxwell looks for one big red flag to spot this one: a consistent failure to chime into the conversation. An apathetic team member offers no suggestions about product features or team processes. They don’t share an opinion of job candidates, and try to avoid weighing in on ideas when asked. “It's almost as though they're hoping they don't get called on,” she says. “They're not being challenged, and they don't care.”
Managers at larger companies in particular may need to look out for one specific type of apathetic employee: “Rester Vesters” or people who just phone it in until their stock options fully vest.
Anxiety — Low Skill and High Challenge
When someone is pushed to tackle challenges their skill set can’t accommodate — or at a pace that isn’t feasible — anxiety is an understandable outcome. Maxwell urges leaders to keep an ear out for telltale anxiety-based phrases, and know how to translate them.
“Listen for things like, ‘Oh, this is a speculative fix,’ or ‘I wouldn't normally do things this way, but given the time constraints…,’” she says. “People who are feeling anxiety might also start blaming others for not meeting a deadline. Or they may say, ‘I have too much on my plate right now.’"
Boredom — High Skill and Low Challenge
“Usually people will fall into boredom because their skillset has increased. They've taken a leap forward, they’ve learned a lot. Maybe they just shipped something or conquered an obstacle, and now they don't feel like they're being challenged,” says Maxwell.
A bored engineer is usually executing the same tasks again and again, finishing them quickly and then spinning their wheels waiting for a new assignment. “Boredom might manifest as resentment over how projects are being assigned across the team,” says Maxwell. Keep an eye out, too, for anyone who creates unnecessary projects, or over-engineers simple problems, just to flex underused muscles. “If you see an increase in exotic, latest-and-greatest libraries entering your codebase, you might have a bored team.”
Of course, human emotion — like human workplaces — is complex, and people will likely spend some portion of their time moving between states. Those periods of transition, as someone moves out of flow in one direction or another, can be particularly impactful times to guide employees back toward flow:
Doubt — From Flow Toward Anxiety
When someone takes on greater challenges, without expanding their skill set to meet them, it’s logical that they would begin to experience self-doubt. In these cases the person suspects they’re lacking the skills to achieve the task. They might start to take offense to otherwise harmless code reviews. Or get stuck in analysis paralysis. They might spend a lot of time seeking advice from senior developers.
Left unchecked, the danger is that doubt becomes infectious. Engineers in this state may begin to not only doubt the value of the project but their leadership team, too. “They may begin to think, ‘Are they making good decisions? Have they put us in an unreasonable timeline? Are they asking us to do something that's just not possible?’" says Maxwell.
When you see reports plotting themselves on the graph in this direction, encourage them to speak up about any concerns they’re having. Simply acknowledging those feelings of doubt can be the fastest way to move back into flow. “One good rule of thumb is think smaller. That means breaking a task into smaller parts to build up confidence. Or celebrating smaller wins than you would otherwise,” says Maxwell. “If that fails, they may need some scaffolding. Get the person in a pair-programming situation so the world doesn’t feel like it’s resting only on their shoulders. As the person regains confidence, introduce more independent work.”
Nostalgia — From Flow Toward Boredom
The move toward boredom typically follows a period of skill-building; the engineer no longer feels challenged because they’ve grown. Falling out of flow in that direction is often marked by feelings of nostalgia. “They want to recreate what it felt like to be in flow, and they don't know exactly how,” says Maxwell.
There’s a hopefulness to this moment, though. A person experiencing nostalgia doesn’t want to be bored; they want to recapture the feeling of learning and growing. And that’s prime material for a manager looking to coax that engineer back into a productive state. “Help them identify what they’re nostalgic for. For example, is it the size of the team, or the ambition of the project?” Work with them to recreate the conditions they’re missing, while they’re still fresh in their mind.
The best managers will use every tool at their disposal to understand what’s going on within their teams, including, of course, their own observations. But while looks are famously deceiving, quantitative assessments are more concrete. In many cases, giving your team an objective way to articulate dissatisfaction is the only way to uncover important trends.
Maxwell appreciates that fellow veteran managers might be reluctant to employ a graph to initiate a conversation about flow. After all, it took experiences like the following for her to roll out the system to all of her engineers and interns in earnest. But once she did, it caught signals that she had missed — or worse, misinterpreted.
Maxwell recalls an engineer she recently worked with, who, by all appearances, seemed deeply engaged in his work. As an engineer for a startup known for rapid releases, he rarely had any downtime. And he was great at his job, always ready with a status update. Surely, he had achieved flow.
“He was actually always in the boredom state, maybe even apathy,” says Maxwell. “It turns out he wanted a complete career change. From an external view, he was in flow. People thought, ‘That guy's on, he knows everything. He's right there.’ But internally, the passion was wavering for what he was doing.”
Without that engineer’s self-reporting during one-on-ones — using a clear, safe framework for sharing it — Maxwell might never have realized she wasn’t supporting him the right way. “I worked with him for a long time and I don't think I ever would've been able to get to it,” she said. “After that conversation, I helped create projects for him to build muscles outside of typical software engineering — ones that focused on release quality, and user experience metrics and reporting. These were the areas where he showed natural drive and interest.
Here are a few more memorable cases from Maxwell — and the lessons each one taught her about nudging her team back into flow.
CASE STUDY #1: The Anxiety-Prone Newbie
Maxwell has learned some of her most important lessons from interns, whose short-term engagements offer a compressed overview of how the flow matrix can play out. In one case, she onboarded an intern with a strong iOS background who wanted to take on a big project right away. “He had a plethora of projects to pick from, and landed on a pretty ambitious one. That immediately put him into the anxiety state, because he had gone past his depth a little bit.”
To counter that trend, Maxwell found and assigned a mentor to direct — and, as needed, step in to handle — the bulk of coding. As a result, the intern spent most of the summer in a flow state. But as the internship neared its end, it looked like he wouldn’t be able to complete the project — and anxiety returned. “He was interested in continuing to work during the school year, though. So I said, ‘Okay, what if we cut the rest of the project in half? You can do half now and the other half during the school year.’ That alleviation of anxiety got him right back into flow. He was able to complete the first half effectively, without being clouded by pressure.”
The lesson for Maxwell was that conditions aren’t fixed. Managers can — and should — tweak things like magnitude of task, support, timeline, etc. if it can help move their reports back into flow.
CASE STUDY #2: The Steady Climber
Other times, though, Maxwell has seen reports demonstrate an intuitive understanding of how to stay in flow — and her job has been to let them do just that.
She recalls another intern who began cautiously, and expressed an interest in building his fledgling iOS skills. Handed a relatively small project for the summer, he completed it in two weeks. “So I assigned him new projects. ‘Okay, well, prototype this new keyboard experience.’ Done, still in the flow. I couldn't find anything big enough, that would make sense for an intern to do, that would knock him out of flow state.”
Perhaps needless to say, Maxwell ultimately made that intern a full-time job offer. “His approach was to be a little bit more conservative, and as a result, he was moderating himself in the flow state. I was never able to kick him out of it,” she says. “There were large, ambitious projects that were going to launch around the time he joined full-time. By starting on the ground floor, he got the opportunity to experience the full scope — and responsibility — of seeing it from start to finish. This got him out of his comfort zone — and growing.”
Your goal is to keep each report moving rightward along that “flow beam.” Most engineers will need an occasional push into anxiety to do that, but some may be able to follow a clean line. As long as you’re pushing each person in the way they need, you’re doing your job.
CASE STUDY #3: The Bored Bug Fixer
This one is actually an aggregate, a common trajectory that Maxwell has seen seasoned engineers fall into again and again. Almost every newly hired developer starts in anxiety, following the information overload of onboarding, then settles into flow as they dig into a project. As projects get ready to ship, though, developers are at increasing risk of boredom.
“This is particularly concerning for projects where 80% of development is ‘greenfield’ joy and 20% is aggravating bug-fixing and convergence. The trick is to make that last 20% as painless as possible,” says Maxwell. “I’ve seen a lot of people sink into boredom, sometimes deep boredom, as they move out of the creative phase of a launch and into cleanup,” says Maxwell. “It’s dangerous to keep someone picking off a bug list for too long.”
If you observe a developer following this particular path, it’s time to ask why they’re lingering in the final stage of that project. “Was there something wrong in the architecture that’s causing it to be so riddled with bugs? Is there scope creep that you need to wrestle?” says Maxwell. “Get the thing shipped so you can get your engineers into their next project, or the V2 of that project, and back into flow.”
Try out this flow framework personally and pilot it with your team. Ask your reports to identify the point on the graph that most resonates with how they are feeling about their work. Consider taking the last ten minutes of 1:1s to have the conversation — and have each team member mark the graph digitally. That’ll allow you to track trends. Experiment to get the right cadence with your team, but start with every few weeks and around milestones, such as kickoffs or releases. Keep an eye out for movement outside of the “flow beam” into areas such as anxiety or boredom — or intermediate stations, doubt and nostalgia. Don’t panic if that happens. Most employees naturally move in and out of flow. Your job is to be as an accurate of a radar as possible — and to guide them back into their flow state.
“In short measure, the flow framework sparked conversations I’m sure I’d never had otherwise. Over my 18 months using it, it’s advanced careers, triggered promotions, facilitated transfers and improved retention,” says Maxwell. “But that’s not what I’m most proud of. In one of the engagement surveys that I last sent, 100% of my team said they felt like they were involved with decisions about their work and part of the team. That, to me, is what it’s all about. If a simple graph helps, it’s a no-brainer.”
Photography by Bonnie Rae Mills.