The Developer’s Hierarchy of Needs (original) (raw)

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:

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.

Developer's Hierarchy of Needs

Developer’s Hierarchy of Needs: How to help the team achieve their best work.

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 solution is foundational and involves a combination of clear policies, robust planning, and consistent follow-through.

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

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:

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”:

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

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:

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:

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

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:

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).

The Burning Match Rule is used to keep updates short. The idea is that anything that takes longer than a matchstick takes to burn should be moved to a follow-up discussion. But use this as a rule of thumb, there can be exceptions made when necessary.

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:

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:

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.