One of the goals of our 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.
|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:
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 developers that miscommunication is a major challenge to getting work done https://t.co/Cvqwnf5tVH.— GitLab (@gitlab) March 13, 2018
What's the best way to improve communication issues between teams in your engineering organization?
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.
Mutual respect and interest in the work of others. Especially between different but collaborating professions like design and development but also within a group of the same type.— ᴄɪᴛɪᴢᴇɴ ᴅʀᴀɪɴ (@Citizen_Drain) March 13, 2018
Writing documentation, and planning. Old skool and works.— Peter Bowyer (@peterbowyer) March 13, 2018
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.
Too many companies financially incentivize against teamwork. If my bonus is determined by me hitting my objectives, then it's counterproductive to help others instead of focusing in on my own work.— Randall Koutnik (@rkoutnik) March 13, 2018
Why is this predictable problem so stubborn? What has your team tried? Tweet us @gitlab.
Photo by Dylan Gillis on Unsplash