Blog Insights How do developers and managers feel about their jobs?
Published on: March 20, 2018
6 min read

How do developers and managers feel about their jobs?

How do you assess job satisfaction? Here's a look inside the findings and methods of our Global Developer Report.


Our 2022 Global DevSecOps Survey is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals.

One of the goals of our 2018 developer survey was to establish a benchmark for how satisfied software professionals generally are in their jobs. Using the detailed demographic information we captured at the beginning, we were able to sort and compare the opinions of different groups within our sample of over 5,000 respondents. One of our key findings was that, for all their differences, developers and managers agree with each other on a lot of things, but managers tend to have a slightly rosier outlook when their views diverge.

How we determined overall satisfaction

Surveys are tricky, and humans are trickier, so we had to brainstorm a bit on what exactly we were interested in learning, and how we could coax out this information without introducing our own biases. We used a series of likert scales to get at these groups’ perceptions of their autonomy, team dynamics, support, and other fuzzy things that we think can really drive happiness in a role (we also asked about details on tooling and workflow later on in the survey). We’ve published before on what happens when your business and engineering teams are out of sync, and we wanted to ask about other symptoms of that same problem. Here are some of the questions, along with the raw data that we used to compare satisfaction between developers and management.

Managers % Developers %
My team is set up to succeed 84 I feel set up to succeed 75
My team is given realistic deadlines 68 I’m given realistic deadlines 65
Project expectations are set up front 60 Project expectations are set up front 50
My team rarely needs to sacrifice quality to meet a deadline 53 I rarely need to sacrifice quality to meet a deadline 50
My team is able to make decisions about their work 91 It’s important to me to be able to make decisions about my work 96
My team has the authority to make decisions 88 I have the authority to make decisions about my work 83
My team's ideas and opinions are valued 93 My ideas and opinions are valued 84
My team has access to the best development tools 81 I have access to the best development tools 74

Tying individual attitudes to culture

What are some other things that might contribute to a frustrating or dysfunctional culture? To try to hint at big, sometimes implicit things like psychological safety, bureaucracy, and whether their team is more democratic or autocratic, we had to come up with a list of concrete indicators, which you can see below:

biggest challenges to adopting new tools and practices

When we asked about the biggest challenges teams face when adopting new processes or tools, the top three responses were replacing ingrained practices, resistance to change, and cross-team communication. Developers and managers are in agreement here almost exactly, although developers are slightly more likely to name resistance to chance (51 percent) than managers (46 percent).

We saw this echoed in other ways, with the greatest number of developers (42 percent) naming unclear direction as their top challenge to getting work done. Relatedly, just 57 percent of developers say they have visibility into what their team members in operations, security, and product are working on. Managers feel slightly better off in this regard, with 69 percent reporting that they have visibility (we also found some differences in how remote versus in-office teams view the issue, which you can read more about here).

What we want to learn next

Communication, and structures or habits that might enable or impede it, is a theme that we’re interested in learning more about. It’s a predictable problem with no easy fix, so we ran a Twitter poll to get some input on how teams have wrestled with communication issues in the past.

One suggestion for how to overcome the cultural barriers to adopting DevOps is to embed team members to improve cross-team collaboration, but that doesn’t always seem doable because it’s an organizational change, requiring buy-in from many more people than just the developers involved. It wasn’t surprising, then, that this option was chosen the least. Regular social activities and working sessions seem like much cheaper options, but were barely more popular. The greatest number of people simply chose our equivalent of ¯\_(ツ)_/¯.

We heard from a few devs about solutions that didn’t make our short list, and they’re rarely about just talking to each other more. Tellingly, the responses we got were much more likely tying communication to big, pervasive cultural things, like compensation incentives and respect for others’ work.

When we asked Netflix engineer Randall Koutnik for more details on his tweet (below) he wrote a post with examples of how dev teams can be undermined by policies tying financial incentives and promotion criteria to individual performance goals, rather than company performance.

Why is this predictable problem so stubborn? What has your team tried? Tweet us @gitlab.

Photo by Dylan Gillis on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert