Fostering a Healthy Developer Experience: Spotlight on Safety, Stability, and Balance
Fostering a Healthy Developer Experience: Spotlight on Safety, Stability, and Balance
Welcome back to DevEx Nuggets! For the third installment, we will continue our deep dive into the world of Developer Experience (DevEx), focusing on psychological safety, security, and belonging. Our journey takes us up the Maslow Pyramid of DevEx, starting from the foundation - safety, security, and belonging.
Psychological Safety, Trust, and Openness
A cornerstone of developer experience lies in the psychological safety of your team. Openness, trust, and respectful communication form the backbone of this sense of security. Psychological safety comes from the certainty that other people share goals and values with us and do not have a secret agenda negatively affecting us.
One way to foster psychological safety is to support personal connections between colleagues. These relationships go beyond the professional and seep into personal domains. Encouraging moments of non-agenda-driven interaction like meetups, virtual coffee chats, or even check-in circles at the beginning of meetings can foster this bonding. These moments may seem insignificant, but they are vital in developing mutual trust and understanding.
As a leader, building such relationships with your team is important, but equally important is fostering these relationships amongst the team members themselves. This leads to better communication, a deeper understanding of one another, and ultimately a more cohesive and productive team.
Here are the most important takeaways:
Psychological safety is built on trust, openness, and respectful communication.
Personal connections among colleagues enhance psychological safety.
Leaders should foster off-topic interactions to strengthen team bonds.
Employees thrive in a well-networked environment, not just in a strong manager-employee relationship.
Familiarity within the team aids in effective communication.
Stability of the Team
Stable teams can achieve remarkable performance. With time, teams learn to work together, cover each other's weaknesses, and amplify each other's strengths. This kind of synergy can't be achieved overnight; it requires time and effort.
Stability doesn't mean stagnation. Teams should change, but the change should come from within and respond to the team's needs. Team restructuring or reformation should be done in conversation with the team and for good reason. Involve the teams early in the process to allow them to understand the need for change, propose alternatives, and be more accepting of the change.
One of the easiest ways to wreck the experience of your engineers is to top-down decide to split or reassemble their team. You might wonder: Who would do something that obviously damaging? It turns out that many managers do this. I have seen this happening in multiple companies within the last year alone. There are many good reasons for teams to change, restructure and reform. And it is easy to miss the importance of involving the teams early in the process.
When you as a leader (or manager) see the need for a change in the teams, discuss the reasons with the teams (trust and openness) and see what their ideas are to satisfy that need. They might come up with a better idea. Or, at the very minimum, you allow them to understand the need for changing the team. People who understand why a certain change needs to happen are far more likely to support that change or at least not boycott it.
Here is what "stable but not stagnant" means:
Whenever the team changes, this happens from a need on the inside. Not by outside force.
New team members have time to absorb the culture before more team members are added.
The team discusses their constellation, their work and needs for change openly. They discuss who should join (or leave) the team if the team should split, and if their scope of work needs to change.
People are free to leave and join teams, as long as it is in alignment with the teams needs.
Work-Life Balance
Work-life balance is a critical component of developer experience. More than just "hours worked," it's about how employees feel about their work. Are they able to disconnect after work? Do they constantly worry about work during their personal time?
Maintaining a good work-life balance involves treating employees like adults, allowing them to determine their work hours and meeting schedules, minimizing compulsory meetings, and fostering an open dialogue about work-life balance.
Here are a couple of tips to consider:
Treat employees like adults. Leave it to them to figure out with their team when they really need to be there and when they can be away.
Don’t get mad when people decide not to join a certain meeting and ask yourself how you could make it more relevant for them.
Do not force people to join informative meetings. Record the meeting or write an email instead.
Respect that people have different personal appointments and responsibilities to take care off and provide means to contribute asynchronously, wherever possible.
Check in with people when you think they are “always on”. How do they feel about it? Do they enjoy it or do they feel pressure to be available?
Discuss this topic openly and ask people (in a survey, anonymously, and in conversations), how they feel about work-life-balance and how they would improve it.
Question of the Week
How are you promoting psychological safety, team stability, and work-life balance in your team? What has worked and what hasn't?
As always, I invite you to share your experiences, insights, and questions. I am looking forward to fruitful discussions. 😊
Tobi's Top Reads of the Week
Developer Velocity: How software excellence fuels business performance— This week, I reread a McKinsey study from 2020 on developer velocity again. Important to note that "velocity" here does not link to "Story point velocity" but more to what we know as "developer productivity and performance". My Highlight: Exhibit 4; it shows the factors from technology to culture and how they affect "developer velocity".
Measuring Engineering Productivity by Ciera Jaspan on how a research team at Google helps other Google teams to understand how their decisions and work impact the developer productivity and experience of their engineers.
Thank you for reading, and see you next week, when we will dive deeper into the DevEx factors around belonging.