The Developer’s Hierarchy of Needs

My management philosophy is that “Devs do their best work when they feel useful, supported, and appreciated.” This is a draft of trying to put some of my management thoughts and best-practices in a single place.

Specifically:

• Every dev needs to feel useful.
  • “I bring a set of skills that are valuable to the project. “
  • “The work I do has an impact and is meaningful.”
• Every dev needs to feel supported.
  • “I have the resources needed to improve my knowledge and skills.”
  • “I am supported when I make mistakes.“
  • “I am given the space, time, and encouragement to grow.“
• Every dev needs to feel appreciated.
  • “My contributions are recognized and acknowledged.”
  • “My leader and colleagues see and values my contributions.”

These can loosely align with “Need for Esteem” from Maslow’s Hierarchy of Needs. A similar pyramid for a “Developer’s Hierarchy of Needs” might look something like this. A framework for describing that in order for a developer to do their best work, their base needs must first be met.

• Level 1 – Physiological Need: I have the tools needed to complete my job. I am supported to take leave without fear it will have a negative impact on the project or my career. 
• Level 2 – Need for Safety: My job is secure.  I can bring my authentic self to the office.  I have the psychological safety to bring issues up issues with my leadership.  The team is inclusive and supports diverse perspectives!
• Level 3 – Need for Belonging: I am part of a development team, studio, and/or company.  We have clear team objectives and I know what success looks like. 
• Level 4 – Need for Esteem: I am useful, appreciated, and supported.
• Level 5 – Self-actualization: I am ready for creative problem solving!

As with Maslow’s Hierarchy, if the developer’s foundational needs (“Belonging, Safety, and Physiological”) are not being met, it’s nearly impossible for them to focus on that top tier.

Meeting a Developer’s Physiological Needs (Level 1)

I have the tools needed to complete my job. I am supported to take leave without fear it will have a negative impact on the project or my career. 

So said the developer whose physiological needs were met.

What are some of the way leadership might erode this foundation?

• The physical workspace is uncomfortable (non-ergonomic).
• Loud distractions prevent the ability to focus.
• Developers do not have the required software and/or hardware to do their work.
• The team is in “crunch” and developers are pressured into working longer hours and delaying vacations.
• Individuals refrain from using sick leave because of concerns about impact to their colleagues or the product.
• Regular emergencies and the focus on “putting out fires” keep the stress level high.

The solution is foundational and involves a combination of clear policies, robust planning, and consistent follow-through.

• The company has clear HR policies that are well understood and leaders regularly encourage the team to use their allotted leave.
• Systems are in place to ensure workspaces and engineering systems meet employee needs.
• Ensure robust and realistic project planning includes buffers for meetings, morale events, customer support incidents, expected holiday, sickness, and well-being leave, and that addressing technical debt is included alongside new feature delivery.

But I recommend taking it a step futher to ensure that foundation is strong:

• Encourage flexible schedules and remote working options for those that want it. Ensure team meetings and planning events accommodate any non-traditional working arrangements.
• Encourage individuals to take a breaks and consider what makes them most productive. For some, a 15 minute mid-day walk can do wonders for sparking creativity. For others, meeting-free days or scheduled uninterrupted focus time are most important for their success.
• Support developers to take an ergonomic evaluation of their workspace.

If a developer is distracted, burnt out, or constantly feels underwater they will not be able to do their best work. Pushing developers may result in short-term gain, but can result in long-term damage to the trust.

Meeting a Developer’s Need for Safety (Level 2)

My job is secure.  I can bring my authentic self to the office.  I have the psychological safety to bring issues up issues with my leadership.  The team is inclusive and supports diverse perspectives!

So said the developer whose need for safety was met.

Questions for reflection:

• Do developers feel comfortable bringing problems to leadership before its too late?
• Do the developer’s contributions get shut down because of an unconscious (or conscious) bias?
• Do any of your developers spend all day “faking who they are” just to fit in on the team? Would you know if that was the case?
• Does the developer consider conversations with their manager a “safe space” to bring up issues without fear of reaction or retaliation?

There is a great deal of information on how to ensure a diverse, inclusive workplace, and ensuring developers are able to bring their authentic selves to the office. There is no way for me to do this topic justice in just a few paragraphs. However, my advice is that every manager needs to “go deep” on this topic if they haven’t already. Experienced managers should reevaluate what was “okay in the past” and ensue they aren’t “managing the way they were managed” when expectations might have been different.

For much of my early career, I witnessed leadership engaging in what we would now label as verbal or psychological abuse. It should be obvious but the following is no longer considered, “okay”:

• Yelling at subordinates to get them to understand your point of view is not constructive. (The adage, “the beatings will continue until morale improves” is not something you want your devs mumbling.)
• Making developers feel stupid for not knowing what you know (or having the context you have) is damaging.
• Receiving feedback and immediately defending or explaining yourself is self-defeating.

But building psychological safety is more than just what “not” to do…

• Take a “coach, mentor, model” approach to leadership.
• Encourage allyship among the development team. Team members who consistently stand up for each other and seek to address injustices will create a stronger team.
• Ensure developers have other leaders to talk to for advice and mentorship.

Meeting a Developer’s Need for Belonging (Level 3)

I am part of a development team.  We have clear objectives and I know what success looks like.

So said the developer whose need for belonging was met.

Successful teams will often develop their own sense of identity, culture, and branding. This is often a combination of specific efforts (like creating a team name and logo) as well as more organic evolutions of the individual contributions and personalities that will impact the team’s dynamics.

One of my new engineers recently asked me, “What is it that you do to create such a strong team culture?” and I know my answer surprised him. “Our culture has very little to do with what I do.”

That is, I don’t believe a team leader can create a strong team culture without the buy-in and execution of the individual team members. While it is true, the manager’s can:

• ensure team charter is clear, objectives are understood, and key deliverables are achievable
• set the tone for the meeting or the day
• encourage, organize, and promote social or morale events
• communicate a shared vision
• address actions or behaviors that harm team culture

Creating strong culture is never achieved alone or in a vacuum. The entire team needs to value and feel empowered to take responsibility for team culture. For example, sooner or later the ownership for creating and organizing social events needs to be driven by the team members themselves. Of course, the manager needs to encourage positive contributions to culture and ensure negative contributions are quickly and appropriately addressed.

Addressing Toxic Culture

My experience is that no matter how toxic the culture of an organization, no matter how many people appear to be active contributors to that toxic culture, they usually all want it to improve. They just don’t have the tools or support for change (and often don’t even have the awareness there actions are part of the problem.)

If faced with toxic culture, I encourage managers to give this their full attention, making deliberate and specific efforts to turn the ship around. To quote Peter Druker “Culture Eats Strategy for Breakfast. Culture Eats Strategy for Lunch”.

Specific tools for addressing toxic culture are beyond the scope of this article, but please move swiftly here. This is an area where the team leadership must take responsibility and move forward with transparency and visibility.

Culture of Helping

Finally, to share one more personal perspective. I believe the most important attribute to positive culture is a focus on encouraging the team members to actively seek and provide help to one and other. The only thing worse than being stuck, is being stuck alone.

When we’re organized around delivering a particular objective at the office a “team”, but too often I instead see a collection of individuals competing against each other for highest rewards and most impact. That’s not a team.

Teams contribute to the success of each other. Teams leverage each other’s help. A team is not an ‘Army of One.’

You will go farther, faster, and have a better time on your journey if you are truly traveling with team. We achieve more together. E pluribus unum. There’s no I in Team. You get the idea.

In five years, you are unlikely to remember the details of what you and your team were challenged with on any given day, but you will remember how that team made you feel.

Meeting a Developer’s Need for Esteem (Level 4)

I am useful, appreciated, and supported.

So said the developer whose need for esteem was met.

With a strong foundation in place, now a manager can work to ensure:

• Every dev needs to feel useful.
• Every dev needs to feel supported. 
• Every dev needs to feel appreciated.

In addition, as a project leader, it is my responsibility to:

• As a leader, I am responsible for creating clarity.
• As a leader, I am responsible for generating energy.
• As a leader, I am responsible for delivering success.

There are a variety of tools the team and I can employ to help achieve these goals.

Regular Check-ins / 1:1s

Weekly or biweekly one-on-one meetings with each developer. This provides an opportunity to build better connections with each dev. It is a forum for them to share perspectives, challenges, and successes. It is an opportunity for them to raise concerns. And it provides me a chance to ensure I know how best to support them.

Stand-ups

The morning check-in meeting focused on quick updates to the following questions:

• What did I accomplish yesterday (especially if it was different than planned)?
• What do I plan to do today?
• Am I blocked?

Stand-ups are great because they get the team together (my preference is to stand around a big screen showing the Sprint Board or Kanban Board).

Stand-up updates should be quick and if there is any discussion needed that is quickly taken as a follow-up discussion instead of taking up everyone’s time. If you’re having trouble with this, I suggest the “Burning Match” rule. That is, each person providing an update is holding an imaginary matchstick and can only talk until the matchstick would start burning their finger.

Standups can be a great way to provide quick updates and create clarity each morning as well as ensure any issues or concerns are brought up sooner rather than later.

But make standups enjoyable!

To me, it is most important that the standup meetings are an enjoyable way to kick off the day. At AtomJack, our artist (Floyd) would always show up each morning with a “dad joke”. On another team, while working from home we did a “question of the day” (eg, What was your favorite childhood book? What was is a restaurant you’d recommend?). In a volunteer group, we included “What was something that happened this week that made you happy?”.

It’s a balance to maintain between “not wasting time” and “team culture”. Having 15 people each telling stories about their favorite travel destination can drive some developers crazy.

My suggestion is to have someone lead these meetings (it doesn’t have to be the lead) has great energy, understands that while a primary goal is to keep on top of product status, a secondary goal is to build positive culture.

Daylies

Usually specific to art teams, “dailies” are used by leadership to allow each team member to share their current progress and ensure it is aligned with the leadership’s vision. This is most important when the feedback is subjective and ensures team members don’t spend too long headed in the wrong direction. They are also a great opportunity for leadership to share positive feedback and appreciation every day.

Build Reviews versus Sprint Reviews

I like to alternate weekly between build and sprint reviews with “Sprint Reviews” having a goal of sharing out work, keeping focused on positive feedback, and celebrating successes. For “Build Reviews”, focus is instead on the quality of the build, recording bugs as we find them, and critique.

Team Retrospectives

I like to run a monthly retrospective with the team using the following format.

1. First, each team member fills out sticky notes that answer one more more of the following props. Allow the team 5 to 10 minutes to fill out as many sticky notes as they want. Each sticky note should be noted with:
   1. A thing we should Keep doing…
   2. A thing we should Start doing…
   3. A thing we should Stop doing…
2. Sticky notes are placed on a wall and team members then have five minutes to add “votes” to the items.
3. For the items that have the highest “up votes”, leadership can ask clarifying questions and action items are noted to follow up.

Post-mortems

After major milestones, post-mortems allow for reflection and course correction. They don’t need to be heavy handed, but without some review of what worked and what didn’t, it’s hard to know if proposed suggestions for “improvements” are addressing the right problems. Too often I’ve seen leadership fix processes based on gut reaction from feedback instead of knowing if they were focused on root causes or just symptoms.

Top-of-Mind Updates

Ideally (when I’m on top of it), I use monthly “Top-Of-Mind” updates to share context around big issues, share appreciation around recent successes, and generally share anything that is in fact, on top of my mind this month.

Kudos

Have an easy way for team members to say, “Thanks” to each other. This can be digital or physical note cards that get put on a physical board.

Feedback

Formalized feedback tools are a great resource and are inclusive of team-based critique and code reviews, 1:1 conversations, and HR systems for requesting, sharing, and receiving feedback from colleagues.

Sharing and receiving feedback are both learned skills in which we can almost all improve. There are great resources and trainings to help the team get better. If the team is new to feedback, I recommend focusing on positive feedback initially and practicing giving/receiving feedback for all sorts of small things before moving on to the big stuff. Once you’ve built trust, it’ll be easier for critical feedback to be heard and valued.

The “art critique” is one of the true gifts of art school. Getting practice seeing and hearing other individual’s opinions on an artists work, as the artists chooses which of the comments they find most useful and which they decide to incorporate in future work.

Sharing Feedback: Crafting quality feedback takes time and it can also be difficult to come up with the right words. With practice we can get better, and seeing/hearing examples of positive and critical feedback that are well received can help us frame our own ways of delivering feedback.

For critical feedback, it can be helpful to focus on the impact, not the action itself. The goal is to have improved outcomes in the future, not “scold”.

Sharing Feedback Template:

• You might be unaware, but when you did _____, it resulted in _____. Here is how you could do it differently next time.
• I think you should keep doing ____ because it results in _____.
• I think you should start doing ____ because it will result in _____.
• I think you should stop doing ____ because it results in ____. You could do _____ instead.

Receiving Feedback: Learning to be better at receiving feedback is just as

I love the concept that “Feedback is a gift. I can either consume it, or put it on the shelf and decide its not particularly useful for me at this time. And in either case, I should thank the giver for the gift.”

Receiving Feedback Template:

• “Thank you for the feedback.”
• “Thank you for the feedback, I will give it some thought.”
• “Thank you for the feedback, I’m not sure I understand. Would you be willing to help me dig deeper into ______.”
• “Thank you for the feedback. Do you have suggestions for how I could have done it differently to have different impact?”

Onboarding New Developers

I pair my new developers with an “on-boarding buddy”. We have developed a comprehensive set of onboarding documentation including both technical information as well as internal team bios to help break the ice.

I implemented “mug up” (based on an old Alaskan commercial fishing tradition) which is a 2x per week mid-afternoon break to play games.

I also require all my engineers to schedule a 1:1 with the new hire during the first week with the only expected outcome of getting to know each other and ask questions.

I will usually start the developer off by ensuring they are assigned a small set of low priority bug fixes that give them the opportunity to get a broad sense of the code and architecture. Its also important to give each new developer an area of ownership they can start to ramp up on and feel like they have responsibility over, especially if it aligns with their particular interest or experience.

Need for Esteem Summary

The point is, there are many tools available to leaders to meet the developer’s Need for Esteem. And from my perspective, it is important to keep the focus of these too on the goal of meeting the developer’s needs, rather than simply to maintain a specific Rhythm of Business. Otherwise, meetings, 1:1s, and even morale events lose their value and become a source of frustration rather than a source of support.

Meeting a Developer’s Need for Self-actualization (Level 5)

I am ready for creative problem solving!

So said the developer who is ready to fulfill their need for self actualization!

My proposal is that once you’ve addressed the developer’s foundational needs (Levels 1-4), they are then empowered to be a creative problem solver. The distractions are swept away, they have their basic needs met, and they are now set up to meet the desire to solve complex problems, be successful, and have impact.

There still may be other challenges around the type of work, the knowledge base, or alignment with experience and/or interest, but with the above needs met we’re now have a foundation in which those conversations can be had.

That is, this proposed pyramid should be used as a framework for thinking about what the developers need as humans to be successful. Too often, I am afraid these needs are overlooked or overshadowed by seemingly “more important” software development challenges.

There is more that can be done from here. For example, ensuring there opportunities for skills growth, cross-discipline collaboration, and gaining recognition for successes and/or expertise within the field. As such, this pyramid represents a limited subset of what it means to be a good leader.

Happy to hear feedback. This document will continue to evolve.