Skip to main content
Skip to content

Hierarchy of Needs

13 min read

The Sprint Where Nobody Could Think Straight

I was coaching a team at a mid-size logistics company a few years back. Good team. Solid engineers, engaged product owner, decent velocity. Then the parent company announced a “strategic restructuring” - which, as we all know, is corporate for “some of you are getting fired and we’re not saying who yet.”

The next sprint was a disaster. Not because anyone forgot how to write code. Not because the backlog suddenly got harder. But because every standup had this haunted quality - people going through the motions while their brains were somewhere else entirely. Somewhere closer to “can I make rent in April?”

I pulled up Maslow’s hierarchy in a coaching session with the engineering manager. Not to be academic about it - but because I needed her to see something specific. Her team wasn’t underperforming. Her team was surviving. And surviving people don’t innovate, don’t collaborate deeply, and definitely don’t care about your sprint goal.

Abraham Maslow published “A Theory of Human Motivation” in Psychological Review in 1943, and it became one of the most recognized models in psychology - and eventually, in management and organizational behavior. He expanded it further in his 1954 book Motivation and Personality. The core idea is deceptively simple: human needs exist in layers, and until the more foundational ones are reasonably met, the higher ones don’t get much airtime.

You’ve seen the pyramid. Everyone’s seen the pyramid. (It’s possibly the most-drawn triangle since the Pythagorean theorem.) But most people get the details wrong - and more importantly, most coaches underestimate how directly it applies to team dynamics.

Hierarchy of Needs - from the Agile Coach's Toolkit

The Model Everyone Draws Wrong

Maslow’s hierarchy is typically represented as a five-level pyramid, with the most basic needs at the base and the most aspirational at the peak. Let’s walk through each level - and more importantly, what each one actually looks like when you’re coaching a software team or facilitating an agile transformation.

Physiological Needs

The base of the pyramid. Food, water, shelter, sleep, physical health. The things your body needs to not die.

“But Vic, my team has desks and a coffee machine. We’re past this level.”

Maybe. But are they sleeping? A team running on three weeks of on-call rotations with 2 a.m. pages is operating with compromised physiological needs. A team crunching through a death march with no time to eat properly, exercise, or recover - same thing. Remote workers in inadequate home setups with bad chairs and worse lighting? Their bodies are telling them something, even if they’re not saying it in standup.

Here’s the thing: physiological needs are the ones we’re most likely to dismiss in knowledge work because they seem irrelevant to people who sit at computers. They’re not. Sleep deprivation alone degrades cognitive function to the equivalent of legal intoxication. Your team isn’t lazy. They’re exhausted.

Safety Needs

Security, stability, freedom from fear. In the original model, this meant physical safety - protection from violence, natural disasters, chaos. In a modern workplace, it maps to something more insidious: job security, financial stability, predictable environments, and freedom from organizational threat.

This is the level where that logistics team was stuck. The restructuring announcement yanked the safety rug right out from under them. And once safety needs are activated, they consume enormous cognitive bandwidth.

Safety needs in a team context include:

  • Job security. Are layoffs rumored or in progress? Is the project at risk of cancellation?
  • Psychological safety. Can I admit mistakes without punishment? Can I ask questions without being mocked? (Amy Edmondson’s work on psychological safety maps directly onto this level.)
  • Process predictability. Do I know what’s expected of me? Are the rules consistent, or do they change based on who’s in the room?
  • Financial stability. Am I being paid fairly? Is my compensation predictable?

When safety needs are unmet, you’ll see teams that won’t take risks, won’t surface problems, won’t challenge bad ideas, and won’t volunteer for anything that might make them visible. They’re not disengaged. They’re protecting themselves. Big difference.

Love and Belonging

This is where Maslow’s language gets a little awkward for the workplace - “love” isn’t typically in the Jira backlog. But belonging absolutely is.

Humans need connection. We need to feel like we’re part of something, that people know us, that we matter to the group. In team dynamics, this shows up as:

  • Team identity. Do we feel like a team, or like a collection of individuals who happen to share a standup?
  • Inclusion. Is everyone genuinely part of the conversation, or are some voices consistently sidelined?
  • Trust. Not just “I trust you to deliver your ticket” - but “I trust you enough to tell you I’m struggling.”
  • Social connection. Do we actually know each other? Have we ever had a conversation that wasn’t about work?

Patrick Lencioni’s “absence of trust” at the base of the Five Dysfunctions model lives right here. Teams that skip belonging and jump straight to performance expectations are building on sand. (And sand, as any coastal engineer will tell you, is a terrible foundation. Dad joke? Maybe. Also true.)

This is why team-building isn’t fluff. It’s infrastructure. The retrospective where people first share something personal - a hobby, a struggle, a weird talent - that’s not wasted time. That’s a team investing in its belonging layer so that the esteem and self-actualization layers have something to stand on.

Esteem

Maslow actually described two components of esteem: the desire for competence and mastery (internal esteem), and the desire for recognition and respect from others (external esteem).

Both matter enormously in team settings.

Internal esteem shows up when people feel skilled at their work, when they’re growing, when they can point to something they built and feel proud. It’s the engineer who refactored a tangled module into something clean. The Scrum Master who facilitated a retro that actually changed behavior. The product owner who made a tough prioritization call that paid off three sprints later.

External esteem shows up through recognition - being acknowledged by peers, by leadership, by the organization. And here’s where many organizations fumble badly. They assume that compensation handles esteem. It doesn’t. People need to hear that their work matters. They need to see their contributions reflected in how the team and the organization talks about success.

The absence of esteem produces two failure modes. Without internal esteem, people feel like impostors - going through the motions but never believing they’re good enough. Without external esteem, people feel invisible - doing solid work that nobody notices or values. Both lead to disengagement, but they require completely different coaching responses.

Self-Actualization

The peak of the pyramid. This is the drive to become the fullest version of yourself - to do meaningful work, to grow, to create, to contribute something that matters beyond the immediate task.

Maslow described this as “what a man can be, he must be.” It’s the pull toward purpose, mastery, and creative expression. In a team context, self-actualization looks like:

  • People who are energized by their work, not just tolerating it
  • Teams that pursue excellence because it matters to them, not because someone’s tracking their metrics
  • Individuals who mentor others, contribute to the community, propose innovations nobody asked for
  • The state where work feels like craft rather than labor

This is where high-performing agile teams live. The ones that seem to operate on a different level - shipping great work, supporting each other, continuously improving without being prodded. They’re not magical. They just have their lower needs met well enough that self-actualization gets bandwidth.

And that’s the real coaching insight. You can’t motivate a team into self-actualization by talking about vision and purpose when their safety needs are screaming. Inspiration doesn’t override biology.

The Part Maslow Revised (And Most People Missed)

Here’s an important nuance that gets lost in most pyramid drawings: Maslow himself acknowledged that the hierarchy isn’t rigid. In his later work, he noted that the levels aren’t strictly sequential. A starving artist creates masterworks despite unmet physiological needs. A soldier risks safety for belonging. A parent sacrifices personal growth for their child’s wellbeing.

The hierarchy describes general tendencies, not ironclad rules. Lower needs tend to dominate attention when they’re severely unmet, but humans are messy and magnificent, and we regularly defy neat pyramids. (Because of course we do.)

Critics like Wahba and Bridwell (1976) found limited empirical support for the strict hierarchy, and cross-cultural research has shown that the ordering of needs varies across societies. Maslow’s model is best understood as a useful lens, not a scientific law. It helps you notice what might be going on - it doesn’t give you a diagnosis.

For coaches, this actually makes the model more useful, not less. You’re not looking for a precise level to “fix.” You’re scanning across all five levels to understand which unmet needs might be consuming the cognitive and emotional bandwidth your team needs for their work.

What This Changes About Your Coaching

Team Health Comes Before Team Velocity

Most agile coaches get called in to fix velocity, predictability, or delivery quality. Maslow’s hierarchy reframes the problem: those are all upper-level outcomes that depend on lower-level foundations.

Before you redesign the team’s refinement process, ask: Are they sleeping? Do they feel safe? Do they trust each other? Are they recognized for their work? If any of those answers come back “no,” your process improvement is addressing the wrong layer.

I’ve watched teams double their throughput not through better estimation or tighter sprint goals, but because a manager finally addressed the reorg rumors that had been hanging over the team for two months. Remove the threat, and the cognitive bandwidth returns like water filling a cleared channel.

Psychological Safety Is a Safety Need

Amy Edmondson’s research on psychological safety maps directly onto Maslow’s second level. When people don’t feel safe to speak up, take risks, or admit mistakes - they’re operating in survival mode. And survival mode produces exactly the behaviors we associate with dysfunction: silence in retros, sandbagged estimates, CYA documentation, and an allergic reaction to transparency.

Building psychological safety isn’t a nice-to-have. It’s addressing a foundational need. Every coaching technique you know - from working agreements to facilitation norms to blameless postmortems - is ultimately an intervention at the safety level of the hierarchy.

Recognition Is Not Optional

Many engineering cultures treat recognition as soft or unnecessary. “We’re all professionals here. Just do good work.” That’s an esteem-level failure hiding behind a veneer of professionalism.

Practical recognition doesn’t have to be a formal awards program. It can be as simple as:

  • Calling out specific contributions in sprint reviews (not just “the team delivered” - name the people and what they did)
  • Peer shout-outs in retros or team channels
  • Making sure leadership hears about team wins, not just team problems
  • Giving people credit for the invisible work - the code review that caught a subtle bug, the documentation that saved three onboarding conversations

When esteem needs are met, people take bigger creative risks. They volunteer for the hard problems. They teach others without feeling threatened. That’s not coincidence - it’s Maslow.

Growth Opportunities Are Self-Actualization Infrastructure

Conferences, learning time, stretch assignments, mentoring programs, hackathons - these aren’t perks. They’re the organizational infrastructure that enables self-actualization.

When a team member says “I’m bored” or “I don’t feel challenged,” they’re reporting an unmet self-actualization need. The coaching response isn’t “focus on your sprint commitments.” It’s “let’s find a way to create growth within or alongside the work.” Ignore it, and you’ll lose that person - either to disengagement or to a company that takes their growth seriously.

What It Looks Like in the Room

Darnell had been an agile coach at a regional nonprofit for about eighteen months - the kind of organization that ran on grant cycles, passion, and a prayer. (His words, not mine.) His primary team handled logistics for a statewide food distribution network: coordinating warehouse volunteers, managing delivery routes, and keeping the inventory system from falling over during peak season.

The team had been solid through the fall. Not flashy, but reliable - consistently delivering on their commitments, surfacing problems early, and genuinely enjoying their retros. Then January happened.

Two things landed in the same week. First, the organization’s largest grant was up for renewal, and the executive director made a poorly-timed all-hands comment about “preparing for all outcomes” - which everyone correctly interpreted as “we might not get the money.” Second, the team’s tech lead accepted a position at a larger company. Two-week notice. No succession plan.

By the third week of January, Darnell was watching a team he barely recognized. The standup that used to crackle with energy became a monotone status recital. The backlog refinement that used to generate spirited debate became a rubber-stamping exercise. Two developers who had been collaborating beautifully started working in isolation - headphones on, cameras off, PRs submitted without discussion.

Darnell’s first instinct was to address the process symptoms. Tighten up the working agreements. Add a pairing rotation. Maybe a team-building exercise.

Then he paused and thought about the hierarchy.

The grant uncertainty had punched a hole in the safety level. People were worried about their jobs - not abstractly, but concretely. One team member had mentioned mortgage payments to a colleague in a hallway conversation Darnell overheard. The tech lead’s departure had damaged the belonging level - this was a tight team, and losing a core member felt personal, not just professional.

Process interventions weren’t going to touch either of those.

Darnell did three things over the next two weeks. First, he went to the engineering manager and made a direct request: “The team needs to hear something concrete about job security. Not corporate optimism - specifics. What’s the actual risk, and what’s the timeline?” The manager pushed back initially - she didn’t have certainty to offer. Darnell’s response: “They don’t need certainty. They need honesty. Right now they’re filling the silence with worst-case scenarios.”

The manager held a team meeting the next day. She shared what she actually knew: the grant renewal was competitive but the organization had a strong application, the decision would come in March, and regardless of the outcome, current positions were funded through June. Not everything they wanted to hear - but enough to stop the free-fall of speculation.

Second, Darnell addressed the belonging gap. He didn’t try to replace the tech lead - that would take time. Instead, he facilitated a session where the team explicitly named what they’d lost and what they were worried about. It wasn’t therapy. It was thirty minutes of honest conversation that ended with the team deciding to redistribute the tech lead’s responsibilities collaboratively rather than dumping them on one person. The act of deciding together - not having it decided for them - rebuilt some of the agency the departure had taken away.

Third - and this was the one that surprised him - he backed off on performance expectations. He told the product owner that February was going to be a lower-output month, and that was the right call. Not because the team was broken, but because pushing for normal velocity while safety and belonging needs were unmet would have cost more than the lost throughput.

By mid-February, the team was coming back. Not all the way - the grant uncertainty still hung in the air. But the standups had voices again. The PR reviews had comments again. One developer proposed a small automation project that nobody had asked for - a self-actualization signal that Darnell took as the best possible sign.

The grant came through in March. But Darnell knew the recovery hadn’t started with the grant decision. It had started with a manager who told the truth, a team that grieved a departure together, and a coach who recognized which level of the pyramid needed attention before anything else could work.

Go Deeper

  • Maslow, A.H. (1943). “A Theory of Human Motivation.” Psychological Review, 50(4), 370-396. The original paper. Shorter than you’d expect, more nuanced than the pyramid suggests. Worth reading in full.

  • Maslow, A.H. (1954). Motivation and Personality. Harper & Row. The book-length treatment where Maslow expanded and refined the hierarchy. Later editions (1970, 1987) include his own revisions and caveats.

  • Edmondson, A.C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley. The definitive practical guide to psychological safety - essentially a deep dive into the “safety needs” level as it applies to teams and organizations.

  • Wahba, M.A. & Bridwell, L.G. (1976). “Maslow Reconsidered: A Review of Research on the Need Hierarchy Theory.” Organizational Behavior and Human Performance, 15(2), 212-240. The most cited critical review. Important for intellectual honesty about the model’s empirical limitations.

  • Kaufman, S.B. (2020). Transcend: The New Science of Self-Actualization. TarcherPerigee. A modern reinterpretation of Maslow’s work that incorporates contemporary psychology research. Bridges the gap between Maslow’s original insights and current science.