Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Science of happy developers: How to boost your engineering team's mojo

public://webform/writeforus/profile-pictures/marcus-34-small.png
Marcus Blankenship President, MarcusBlankenship.com
Neon
 

"I've lost my mojo!" —Austin Powers

Losing your mojo is traumatic for everyone, but when it happens to your dev team, it might seem like Dr. Evil has got the best of you. Unfortunately, too many tech teams (and their leaders) start looking for a solution in the wrong places.  

Newer languages, tools, platforms and processes are where developers and managers usually look to get their mojo back. Unfortunately, these fail to deliver on the promise of optimizing for developer happiness, and only waste valuable time and resources.  

If you're thinking that moving your ASP.NET team to Node.JS, or your PHP team to Rails will improve their happiness, you're going down a dead-end road.

What's the answer? Thankfully sociologists have come to the rescue with research showing that your developer's job performance and job satisfaction are directly linked to their relationship with you. Here's how Leader-Member Exchange Theory (LMX Theory) can deliver for your team.

 

Learning from LMX theory

In the early 1980’s, sociologists and organizational psychologists began to look at leadership from a new perspective. Traditional leadership theories have long been based on “Great Man theory,” attributing the team’s performance to qualities of the leader.

Setting this aside, these sociologists began to study how the quality of relationships between managers and employees affected outcomes.  This has evolved into an area of research known as LMX theory, which studies the effects of these key relationships on happiness, productivity, turnover, and motivation.

In short, Gerstner & Day, in an article in the Journal of Applied Psychology, found that:

The relationship with one’s boss is a lens through which the entire work experience is viewed.

Take a minute to re-read that. Your developers' entire work experience is viewed through you. You are their lens.

Researchers found a significant correlation between the quality of relationship that developers have with their manager, and performance and satisfaction in the job.  This agrees with Gallup’s finding that “managers account for 70% of variance in employee engagement.”  

This focus on the quality of the relationship between leader and employee, rather than only on the traits of the leader, provides hope for all managers who want to create high-performing teams. Instead of attempting to cultivate particular “great man traits” within themselves, managers who want happy developers should cultivate high-quality, individual relationships with their team members.

Know the ins and outs of your groups

LMX research found that all employees fall into one of two groups under their manager: an “in-group” and an “out-group.” Managers do not intentionally create these groups, but they form naturally as the manager builds relationships with individual team members. 

In-group members enjoyed more advancement opportunities, greater trust, more autonomy, and were happier and more productive than their out-group peers. They were able to negotiate tasks, and collaborate with their manager to find win-win outcomes.  They are generally motivated, happy, and satisfied with their jobs.  

Out-group members are the opposite. They are promoted less often, given less autonomy for how work is completed, and are less productive. Their job performance is lower. They often appear to be "9-to-5ers," doing only the minimum needed to get by, and may be seen as simply punching the clock. Instead of negotiating win-win outcomes with their manager, the get assigned tasks without any opportunity for discussion. Unsurprisingly, they are less motivated, happy and satisfied.  

What does this mean for you, the manager? First, you can start to identify your groups. How is the in-group composed? How do you feel differently about them? Do you see a difference in their happiness or job performance?

Next, think about why people are in these groups.  Do you have common sports or social activities, religious viewpoints, or world views?  Do your personalities just click?  Do you share the same communication style?  

You didn't intentionally create these groups, but they do exist. You might feel bad about this, but you shouldn't. It's completely natural. Instead, focus on building strong relationships with everyone on your team.

Two steps to create better relationships

Equal investment is the key to creating better relationships with everyone on your team. Often, the in-group gets the most attention and time, so you need to spread your investment evenly across the team. Here are a few tips:

Hire selectively, prioritize for soft skills

Keeping this in mind, managers should seek to hire programmers who understand and value strong relationships, and who have the soft skills necessary to participate in them. While hard technical skills are important, the soft skills are an important indicator of success in relationships with managers.

Many managers perform “culture fit” interviews, hoping to find programmers who will succeed at their companies. This is a good start, but adding questions that explore past managerial relationships, their abilities, and your willingness to give candid feedback and understand the importance of good relationships will help you find candidates who are ready to be in your in-group.

Hold weekly one-on-one meetings

In his book, The 27 Problems Managers Face, Bruce, Tulgan states, “When things are going wrong, the common denominator is unstructured, low-substance, hit-or-miss communication.” One-on-one meetings are the cornerstone practice that creates and sustains strong relationships between managers and developers. One-on-one meetings aren’t simply a status meeting, or a delegation meeting, or even a coffee meeting. Rather, these meetings provide a private, consistent place where leaders invest in their team, trust is built, feedback is given (and received) and the relationships deepens.

One-on-one meetings are an activity meant to build deep professional trust, reveal training and feedback opportunities, and allow the developer a safe place to give the manager the kind of candid feedback needed to improve.

When I was a new tech manager I didn’t understand the real purpose behind one-on-one meetings, viewing them as “busy work” to be minimized (allowing me to get back to the “real work” of coding!)  But that led to unwanted outcomes.

Frequency and consistency are key attributes of these meetings.  Managers who see one-on-ones as an investment understand that canceling a meeting sends the wrong message, and hurts the relationship. They choose a frequency, which they can commit to, and remain consistent in keeping and conducting the meetings.  

While not every meeting is the same, they ensure that time is given to discussing project impediments, giving affirming and corrective feedback, and asking for input and feedback on their own management practice.  Without this feedback, managers are driving blind,  without a way to understand what their teams need from them.

Some managers object to spending time this way, pointing to their “open door” policy as a better style of management. In Cancelling One-on-One Meetings Destroys Your Productivity, Elizabeth Grace Sounders writes, “When you cancel one-on-ones and compensate with an open-door policy, your time investment mimics that of a call center employee who takes requests in the order they are received, instead of an effective manager and executive who aligns his time investment with his priorities.”

Experienced managers also understand that team members are reluctant to use their open-door policy for fear of “wasting their managers' time.” Without a scheduled, consistent one-on-one meeting, managers are depending on developers to use their best judgment to decide when and on what to consult with their manager. This reluctance often leads to unnecessary miscommunication, incorrect assumptions, and frustration on both sides.

Get your mojo back, baby

It's tempting to think that new languages, platforms and tools can solve your mojo problems, but they won't. I've never met a developer who quit to get away from a technology, but plenty leave to get away from a manager.  

I've seen plenty of programmers working on old technology, with old processes, on old platforms, who love their jobs. When I ask them why, they tell me that they love their boss, company, and teammates. They feel their boss "has their back," and wants the best for them.

That only comes from great relationships, consistent time investment, and clear and direct bi-directional feedback.  

That's the kind of mojo you want for your software engineering team. Don't settle for anything less.

 

Image credit: Flickr

Keep learning

Read more articles about: App Dev & TestingApp Dev