With remote work becoming the new standard for software engineering jobs, it can be hard to feel connected with your devs. What do they want? What do they need? What are they not telling you?
Devs are product drivers who want to contribute and make a real impact on the business. They know when something is or isn’t working, and they’re especially good at sniffing out BS. As such, there are no shortcuts to developer happiness. It takes time, connection, and a deep understanding of how they work. If you can’t create an environment that both challenges and supports your devs, another organization will.
When trying to create a fulfilling work environment for my devs, I think of the Japanese concept of Ikigai. Your Ikigai is your life’s purpose — your reason for being. It’s your passion or dream career. For many of us, it’s what gets us out of bed every morning. As a leader, I strive to uncover each dev’s Ikigai. It’s unlikely that their current role is a perfect fit for their life’s purpose. But by being attuned to their needs and making key decisions to better align their responsibilities with what makes them tick, I can help make their jobs more fulfilling.
Here’s what I’ve learned from my devs about being a supportive manager — and what your developers may not be telling you:
1. They want to work
Devs don’t become devs for an easy ride. They want to work, to learn, to build! But they want that work to be engaging — there’s a reason so many job descriptions advertise visibility and impact. Of course, no job is perfect. There will always be some parts of the job that your devs won’t like. But making sure there’s a healthy balance between more tedious tasks and projects that feel meaningful to your devs will go a long way in keeping them engaged.
As managers, we have the opportunity to recognize and advocate for our devs. If they are taking on a week of tedious but crucial work, make sure to acknowledge their efforts and show gratitude. Positive feedback is crucial.
Similarly, it’s our responsibility as managers to keep an eye out for opportunities to help our devs grow. At Uplevel, we have “dev anchors,” a rotating system where different devs can volunteer to take point on a project and become responsible for its technical details and scope. This system gives our devs the opportunity to get more involved and invested in features they care about. It means there are always opportunities for them to get more engaged in the work, and it ensures that their voices matter in the process.
The same care should be put into thinking about the amount of work your devs are expected to do. Too much work can overload your devs, putting them at risk for burnout. On the other hand, they don’t want to twiddle their thumbs all day either. Having too little work can leave devs feeling undervalued and unmotivated.
At Uplevel, stakeholders can choose either the scope or the deadline of a project, but not both — they must negotiate with the developers on the other. By including developers in early discussions about the scope of each project, our devs have a say in the amount of work they will have, keeping them accountable.
2. They value repetition and consistency
A crucial part of running a tight ship is making sure each member of your team understands where you’re headed. This means sending a consistent message — one you don’t mind repeating over and over.
When you have a lot of information to get through, it’s easy to forget which details you’ve communicated to each of your devs. Even though it feels redundant, being consistent with what you tell them is important to create clarity around prioritizations and expectations.
If you don’t communicate consistent information to all of your devs, it can lead people to believe that their voices don’t matter to the business or the team. That sense of disconnect can lead to feelings of isolation and a lack of direction that prevents them from learning, growing, and doing their best work.
Consider keeping a list of important topics of conversation for each of your 1:1s. Share your thoughts on business priorities, your biggest technical concerns, and important takeaways from cross-team meetings. Your devs will value your perspective on how those things impact your team, while painting a picture of how they fit into your organization’s big-picture goals.
It will also encourage your devs to engage critically with the business as a whole. They can give input, voice appropriate concerns, and focus their efforts to have greater visibility and impact.
3. They have other opportunities
Software developers are so hot right now. The tech industry continues to grow, and qualified devs are in high demand. According to a 2021 Stack Overflow survey, about 75% of developers are either actively looking for a job or open to new opportunities. But attrition isn’t inevitable. Although there are a variety of reasons why developers leave their jobs, the actions that we as managers take — or fail to take — can make a huge difference in dev job satisfaction.
Retention isn’t a passive activity. Checking in and taking your devs’ needs seriously is one of our most important jobs as managers. Have open and honest discussions with them about impact, relationships with their coworkers, growth opportunities, compensation, and what you can be doing better to help support them.
It’s important not to take your devs for granted, especially at times like these. For each dev who leaves your team, you could spend up to six months recruiting and training their replacement. That means a significant increase in project risk. And you’ve also lost a valuable store of domain knowledge and opinions on workflow improvements.
You can’t control every variable that goes into an employee’s choice to leave the company, but you should do everything in your power to keep your devs.
4. They don’t all want to be managers
It’s important to be in tune with your devs’ career paths. Knowing where my devs want to go helps me better support them as they take on more responsibilities. This also means adjusting to their individual pace.
Not all devs — or people, for that matter — are trying to climb the organizational ladder. Some are satisfied right where they are. They don’t dream of managing teams and projects. They just want to build! For these devs, growth opportunities don’t have to follow the management path. As leaders, it’s our responsibility to create new paths that align with their goals.
Radical Candor breaks workers into five performance and growth trajectory combinations, starting with your “superstars” (high performance, rapid growth) and “rock stars” (high performance, gradual growth). Where do your devs fall within these categories? What might a career path look like for each one? No combination is better than the others — just different. Consider each employee’s unique situation and what they want to accomplish in their careers.
5. They want the chance to mess up
Your developers want the chance to grow. But growth doesn’t just happen through victory after victory. Growth means experiencing failure and having the grace to learn from it. It means designing imperfect technical architecture and handling the pain when things go wrong. Growth is causing outages due to bad configurations and learning how to harden your infrastructure. It’s also causing terrible bugs but developing the intuition to quickly track them down.
A crucial part of encouraging growth is creating an environment where failure isn’t punished. Instead, devs should feel encouraged to make informed decisions and take calculated risks in their work. A culture of transparency, trust, and safety — where team members are able to voice their honest opinions — is a prerequisite to meaningful growth as a developer. Your devs should know that you’re willing to go to bat for them and help defend their decisions (even if you don’t fully understand them).
Of course, this doesn’t mean that you should embrace absolute anarchy, allowing each dev to do whatever they want. After all, it’s hard to defend something you know nothing about. It’s important to encourage accountability and follow up on your devs’ decisions when things are unclear. Having a clear process for design reviews, spikes and exploration, and post-mortems for incidents is a great way to instill your devs with a sense of autonomy and responsibility over their domains.
6. They need 1:1s with you
Looking at this list, your devs may have a lot going on behind the scenes. It’s hard to pick up on what your dev is actually feeling without being able to talk to them and connect on a deeper level. That’s where 1:1s come in.
I use 1:1s to stay in tune with how my team is feeling. We approach our meetings with honesty and trust, and we try to get to know each other better as well. They are the best way to stay connected, especially when managing remote teams. Use them to better understand your devs’ needs and pick up on what they might not be telling you at other meetings. Make 1:1s a safe space by following these tips:
- Understand punishment vs. accountability. Give your devs the opportunity to exercise more agency in their work while also learning from their experiences. Support them when things aren’t going well, and challenge them when they are. Avoid punishing them for their mistakes, but encourage them to grow, learn, and better themselves through the process.
- Be an empathetic leader. Show vulnerability, compassion, and levity, sharing details of your life outside of work. This can be especially difficult for remote teams, but human connections are what make people comfortable with each other. Not every moment needs to be strictly business. You can be a supportive manager without being unprofessional.
- Practice honesty. As we mentioned before, devs have an appreciation for honesty and straight talk — you owe them accountability too, after all. Be honest and authentic with them, both about their work and your own limits. Being tactfully truthful is often the greatest gift you can give to your team.
For more of what your devs aren’t telling you and how to be a supportive dev manager, join Uplevel Engineering Manager Brian Park for a webinar discussion. He’ll share expert insights and stories from his time as a dev and as a manager.
This post is by Brian Park, Engineering Manager at Uplevel