Developers ≠ Resources: Improving your developer relations

Neeraj Kashyap is the founder and CEO of Moonstream.to. He is a mathematician, and holds a Ph.D. in Number Theory from Indiana University. Spent his late twenties in Japan, using mathematics and Machine Learning to build algorithms to diagnose Parkinson's disease and other similar disorders.

I’ve been in many meetings where I’ll hear a senior-level manager refer to developers as “resources”. Frankly, I believe the term “resources” is an incorrect way to describe the people you work with, but most importantly, it’s a matter of belief that applies anywhere. 

You should not dehumanize the people you work with in any circumstance. Sticking to this principle has led me to see people become more invested in their work and deliver better results regardless of the scenario. People are not resources, whether the job involves putting something on the factory floor or coding things out on the computer. 

Here are five ways to improve your developer relations:

• Fix your subconscious demeanor
• Use respectful language with a global team
• Remember that with power comes great responsibility
• Balance your metrics
• Address your peers

Fix your subconscious demeanor

It’s hard to work with someone when you think of them as a resource. You’re only accounting for how people affect items your team should handle and execute. However, you’re not accounting for how it affects that person and not investing in a long-term relationship. You convey a subconscious demeanor and body language that you don’t care about their well-being in the long term. 

Instead, your team should feel you have their back. There’s this case study I once read, where two different individuals were placed in two separate groups and a rule imposed to disallow the drinking of coffee. Person One went and bought themselves a cup of coffee, while Person Two bought their own and their team coffee. For Person One, their team viewed them as a rule-breaker. Meanwhile, Person Two was viewed as the group leader. In both circumstances, Person One and Person Two broke the rules, but Person Two's action of sticking their neck out for the team elevated the respect they received. 

Not to say go and break your organization’s rules, but a leader who puts their team first, sometimes at their own expense, gains trust. 

Use respectful language with a global team

Language is critical when teams are globalized. It’s not about keeping the language clean but communicating through tone and phrasing that you respect the other person at the other end of the screen. People quickly understand if the person they’re talking to respects them or not. 

We have an engineering team with five people spread out globally. Not everyone is proficient at English or up at the same time, but we haven’t had turnover for over two years as it’s starting to feel like a family. We work hard at creating a non-judgemental environment and respecting one another. 

Remember that with power comes great responsibility

When placed in a leadership position, it becomes more about regulating your thoughts and language. As you gain more power, it’s easy to fall into the mentality that your developers are resources. It comes with power, and you have to retract that impulse consciously. Remind yourself that there’s nothing inherently better about being a manager than a contributor.

Learn to make decisions as a team, and communicate that your developers and team have agency in decisions. Be open about what the team sees because the breadth of perspective is valuable. Your developers are also very intelligent, so you'll receive great feedback by opening up decision-making as a team. 

Balance your metrics

Things must be measured, but it’s essential to differentiate between vital or unnecessary measurements. There’s somewhat of an art there. Keep in mind Goodhart’s law stating, "When a measure becomes a target, it ceases to be a good measure." 

The classic metric example is lines of code. Everyone knows it’s a terrible metric to measure work, but it’s easy to fall into the trap of measuring output by counting lines of code. Andy Hertzfeld wrote a story about the early days of Apple, where management brought in the idea to measure progress by counting lines of code. Bill Atkinson optimized the code to become six times more efficient, then communicated the lines of code written as -2000. 

If people start to try and optimize a measurable statistic, whatever you begin measuring becomes more pronounced than other more important goals. Instead, measure how effectively you meet your goals.

Address your peers

Hopefully, this article helps shape your perspective around this topic, but how should you approach your peers? When dealing with peers, it’s more complicated. If you’re on different teams within the organization's scope, it’s not your business. You shouldn’t bring it up with the person directly unless you’re in a good relationship with them. You can bring it up to higher leadership if you have a good relationship and they find the developer relation issues important enough to address. 

Despite your lack of control in how others speak, actively show your developers that you support them in words and actions. In doing so, you'll differentiate yourself from your peers' negative actions or demeanor, while uplifting a culture in improving developer relations.

Final thoughts

It’s a great time to be a developer — as they have the agency and power to walk away. While my team can better answer how our team's culture supports our developers, I’ve always tried my best to be honest with my team and not judge. All I know is that they feel like a family.

We’ve had difficult conversations and hard times that we’ve walked through together. I’ve always tried not to judge and be honest with my team. We’re all okay with others making mistakes and look at mistakes as an opportunity for growth.

No matter the team you lead, everyone should feel free to share without feeling devalued and share in each other’s successes.