When it comes to building high-performing teams, your relationship with your developers is more important than their technical skills.
While technical skills are important, strong developer–manager relationships are the keys to everything you want. Healthy relationships among employees and leaders produce high levels of engagement, motivation, trust, and transparency. These relational attributes are the foundation for an environment where your developer’s job performance and job satisfaction are at their highest.
Most of us leave work relationships to chance, hoping that they flow naturally from personality matches. Good leaders can’t afford to do that. Instead, we must create systems that build strong individual relationships with all of our developers.
When we build strong relationships with our developers, we enjoy distinct competitive business and technical advantages. Higher quality software, deeper domain knowledge, greater productivity, improved teamwork, and lower turnover are just some of the benefits that flow from these relationships.
When I ask technical leaders, “What is your hardest problem at work?”, I regularly hear problems such as…
- “I’ve got old developers stuck in their outdated ways.”
- “I can’t get developers on board with the process I want to implement.”
- “I want to help people without making them dependent on me to solve problems.”
These aren’t technical defects, software scaling issues or problems with architecture. They’re problems reflecting poor relationships between managers and developers.
Developers “stuck in outdated ways” or who won’t “get on board with the process” aren’t simply being stubborn. They’re experiencing internal fear or hesitation about their environment that makes them resistant to change. As the manager, it’s your job to create relationships and environments where it’s safe for them to grow and adapt and to coach them to take risks (such as trying your new-fangled processes!).
In short, these problems are symptomatic of relationship issues, not technical or process issues.
Managers matter most
A recent Gallup report, The State of the American Manager, confirms that manager–developer relationships are the key to success: “managers account for at least 70% of the variance in employee engagement scores” and “50% of those surveyed have left a job to get away from a manager at some point.”
Those numbers are staggering. They go on to report that “just 30% of U.S. workers are engaged, demonstrating a clear link between poor managing and a nation of ‘checked out’ employees.”
Early in my career, I saw developers “checked out” of their work, but didn’t understand why. I mistakenly blamed them when I should have looked in the mirror.
Engagement flows from individual relationships
As Gerstner and Day wrote in the Journal of Applied Psychology, “The relationship with one’s boss is the lens through which the entire work experience is viewed.”
That’s a huge statement. Have you considered that your developer’s view of the company, projects, goals, process and everything else flows from their relationship with you, and that building a great relationship is primarily your responsibility?
If the relationship is good, it builds loyalty, motivation, and trust. But when it’s bad, nothing else can be right. You can’t have the right process and the wrong relationship. You can’t build great systems with the wrong relationships.
Consider Conway’s Law: groups create software systems that mimic the communication structure of the group. This means the output from your team reflects the communication structure and relationship you have with them.
For example, when teams under me didn’t trust their leaders or peer groups, their API interfaces were built to be “defensive” and loudly proclaimed to the caller that if an error occurred it was not the programmer’s fault, but rather must be a mistake on the caller’s end. This reflected the team’s “cover your butt” attitude, adopted in response to being unfairly blamed for problems in the past. This fear of blame displaced their trust in leaders or peers and was reflected in the software they wrote.
Attributes of engagement
So what is “engagement”? What do engaged developers look like? Here are some examples from my own experience.
- Focus on accomplishing their work
- Show high interest in understanding and achieving project goals
- Find innovative solutions to hard problems
- Don’t let “speed bumps” become “road blocks”
- Communicate issues early, collaborating with the team to find solutions, and
- Visibly enjoy their work, spreading joy in the team
For me, those six non-technical attributes are keys to being a great developer.
Though developers get credit for having these attributes, it’s up to you, as the manager/leader, to engage your developers and create an environment where engagement thrives. This is the most important work you can do and will have the largest impact on your team and projects.
You can’t rely on personality matches
Most of us allow our business relationships to grow and change without structure or focus. As a manager, you don’t have this luxury.
You probably have great relationships with at least some of your developers. I’m guessing that the ones with whom you have the best relationships are naturally matched to you in personality. There’s a good chance that you’d be friends even if you didn’t work together.
However, knowing how important engagement is, you cannot rely on these chance personality matches to create strong relationships. You can’t afford to. Instead, you’ve got to intentionally build communication channels and practices that create the relationships you need.
I won’t lie, this requires you to level up your relationship building skills and practices. You can’t expect your developers to initiate these practices, even if they want a good relationship with you. You sit in the greater position of power, so you must take the lead and set the tone and quality of the relationship.
The core practice to create great relationships
You need individual relationships to build engagement, so you’ve got to create individual communication channels and practices between you and each of your developers.
Overall my years working with managers and leaders, the most beneficial communication channel I’ve found is regular, private one-on-one meetings. The one-on-one meeting is the foundation for the relationship, allowing both of you to build trust, collaborate on problems and give honest feedback.
Note the word private. “One-on-one” meetings are meant to be, well, one on one. You might be surprised how many managers try to cut corners by having them with two or three developers at a time. This is a huge mistake. The addition of even one person changes the dynamics completely. It reduces people’s ability to be honest about what they think. It sensitizes people to criticism. It can create a sense of competitiveness. And above all, it sends the message “You aren’t important enough for me to meet with individually.”
This is not a message that builds good relationships.
Of course, no two people are alike, so what you talk about and how will vary. Get to know each developer as a person. I typically ask about family life, hobbies, vacations and personal goals. Of course, to earn the right to ask these questions, you’ve got to be willing to answer them as well. Remember, relationships are bidirectional, so you’ve got to “give before you can take.”
It goes without saying that you actually have to care about your people, or this all comes across as scripted and fake. Don’t just go through the motions, or you’ll alienate them like the Pointy-Haired Boss of Dilbert fame. No one likes to be asked about their family by their boss “because they’re supposed to ask”. That’s just insulting and sours the relationship quickly.
This personal relationship lays the groundwork for work-oriented discussions about career development and goals. Candid discussions about career goals and expectations show the developer you care about them personally and professionally. This “caring” is the cornerstone of the relationship.
It takes two to tango
Not everyone wants a strong relationship with their manager. Some have been hurt in the past and some don’t have the skills or don’t care. That’s their decision, but I try to find developers who want strong relationships with their manager, and I weed out the ones who don’t during interviews.
That doesn’t make these people bad developers, but because good relationships are the primary indicator of developer engagement, I don’t force-fit anyone into the team simply because they have the right skills. Early in my career, I made this mistake, assuming I could build good relationships; I learned the hard way that relationships take effort and investment from both people. I’ve stopped trying to change people; instead, I look for people who value strong work relationships and display the skills necessary to build them.
The competitive advantages of good relationships
While good personal relationships can raise employee morale and make a workplace more enjoyable in general, there’s also a competitive business advantage to having great relationships with your employees.
Consider that Gallup poll again: 50% of respondents have left a job to escape a boss. Clearly, turnover is related to relationships. Bad relationships repel people, sending them in search of a workplace with managers who care about them as people.
Turnover will kill you
Don’t take this lightly: if your best developers are regularly leaving, it’s costing you money.
Your recruiting costs go up: Whether it’s your time spent reviewing resumes and interviewing or the cost of a headhunter, taken on an annual basis, it’s a significant cost.
Your training costs skyrocket: Your new hires never hit the ground running, even if they know the tech stack you’re using. Learning your tools, process, coding standards, deployment practices and how your team communicates takes months to master, not days.
Of course, any investment in an employee feels risky if you’ve got high turnover, so you might start to scrimp on the upfront training, just in case folks don’t work out. Now you’re on a bad road that only goes downhill, leaving you with a less skilled workforce that can’t deliver. Pretty soon, they’ll leave, and the cycle just keeps spiraling downward.
Good people leave poor performing teams
What if you do manage to hire a rockstar ninja amazing programmer into a poorly performing team? They’ll probably take a look around them and head for the door.
Great programmers with good communication skills value working with people as good as themselves. If they find they’re the most skilled, motivated person in the room, they quickly lose interest. So the good ones leave, and the poor ones stay (but don’t improve.) Lose-lose for everyone.
Great relationships with your developers are key to building great software, great software teams, and getting the results you need.
You need highly engaged developers, not just “code monkeys”. Without strong engagement, the smallest issues become blockers and velocity grinds to a halt. Software quality suffers as it reflects the employees’ attitudes and view of you and the company.
You can’t simply hope these great relationships will happen on their own; you’ve got to build processes and channels that create them. Consider talking with your manager or HR department about what practices might already exist in your culture to create strong employee relationships. Most companies claim to value employee relationships, but too often line managers de-prioritize them day-to-day. Create habits and practices that build your relationships consistently and you’ll see improvements before you know it.
These relationships will lead to competitive advantages: higher productivity, improved quality, enhanced job performance and better job satisfaction have all been tied to strong manager relationships.
Remember, your investment in relationships is like water on the seeds you sow. Without a strong relationship, your investment in technical skills, domain knowledge, and the process won’t yield the results you need.
With great relationships, your developers’ skills and the company goals align to produce amazing results.