I asked 200 dev teams how well they work together. Here's what I learned.

Product development is (almost always) a team sport.

To build a successful product, multiple stakeholders must work together during the development cycle to get things done. This includes engineers (obviously), product and project managers, designers, QA, and even the folks in marketing and sales.

But getting “developers” and “non-developers” (non-engineering stakeholders) to work well together isn’t trivial. Because not only does each role fill a different technical function, but they are also fundamentally different in terms of how they work, the tools they use and the way they communicate with others on the team. And when asking people with different roles, personas and styles to collaborate on a complex task - there's bound to be some tension.

This workflow tension between stakeholders is wide-spread and well-known across the industry. Just look at the number of memes and jokes that are out there poking fun at how developers and non-developers interact.

But what's interesting is that sometimes, the most commonly recognized issues are the least defined and most misunderstood.

Sure, everyone knows that cross-functional collaboration issues exist, but most of us don’t give it much thought. We just roll with it, mutter some stuff under their breath and continue on to the next all-hands meeting. It seems a lot easier to accept it and suffer, than to analyze, understand and correct.

So I decided to go against the grain and take a closer look at this. For the past year, I (together with my team) have studied how developers and non-developers collaborate and communicate throughout the product development workflow. I looked at what works and what doesn’t work, and what exactly each persona is thinking about the other at every step of the way.

If you're wondering why anyone would spend so much time on this, it's a fair question.

The truth is, I've experienced this tension first hand having worked in product and marketing roles for several companies, But my main motivation was joining Livecycle. Because by doing so, I was tasked with helping to build a product designed to solve this very issue.

Since the primary value of our product is to speed up feedback loops and reduce workflow tensions (by enabling contextual feedback on top of any preview environment), I felt like I needed to deeply understand what those tension points were all about in the first place.

And what better way to do that than to speak to hundreds of people who are affected by this every day?

So I got to work and ended up hearing from representatives of 200 software development teams from around the world (how I got them to talk to me is another story entirely). I asked them about their routines and workflows. I inquired about their interactions and their frustrations. I gathered responses from people filling all of the key engineering and non-engineering roles working in companies ranging from pre-seed startups to publicly traded corporations.

Some of data reinforced what was perhaps to be expected, but much of it was revealing. And the whole process was really fascinating.

I've put together a summary of some key data points and takeaways, with the hope that my efforts can be valuable to some of the other teams out there.

Developers and non-developers communicate differently

The first thing that jumped out at me is the extent to which developers and non-developers communicate (and operate) on different wavelengths. Each persona on the team has their own unique cadence and style of communication.

Some of the key numbers:

Developers get interrupted way too often

• 41% of developers admitted to being “annoyed on a regular basis” because non-developers interrupt them with random questions.

Developers don’t understand the feedback they get

• 53% of developers said they often don’t understand review feedback from non-developers, and they need to invest more time to review it with them in order to proceed.

Developers are asked to use too many tools

• 54% of developers said that they are forced to use too many tools for the sole purpose of communicating with the other stakeholders on the team during the development workflow.

Developers are more frustrated about this than the rest of the team realizes

The fact that developers are frustrated about these kinds of things is notable, but not entirely surprising.

What was really interesting though, was discovering the extent to which the rest of the team has no clue that their engineering colleagues feel this way.

When we asked non-developers how their developer colleagues felt about these issues, a significantly lower percentage of non-developers answered affirmatively compared to the direct responses from the developers themselves.

Here’s a side by side comparison:

“Developers are annoyed by frequent interruptions by non-developer colleagues”

• 41% of developers agreed with this statement
• But only 15% of non-developers felt this was true

“Developers often don’t understand product review feedback from non-developer colleagues”

• 53% of developers agreed with this statement
• But only 29% of non-developers felt this was true

“Developers are forced to use multiple tools to retrieve feedback and context from non-developer colleagues”

• 54% of developers agreed with this statement
• But only 23% of non-developers felt this was true

This shows that on average, “non-developers” don’t realize how frustrated their engineering colleagues are about these workflow and communication pain points.

Context switching negatively impacts developer productivity

As a general rule, developers like to stay focused and they hate context switching. A typical collaborative workflow involving multiple stakeholders makes this challenging.

Two types of context switching

Through our discussions with developers, it became clear that this aversion to switching context manifests itself in at least two ways: switching tasks, and switching environments.

Switching tasks is when developers are asked to stop (current) task 1 and focus instead on (new) task 2. Developers can’t stand this.

Switching environments however, is more subtle and is possible even within the context of the same task. This is when developers are forced to leave the context of a preferred tool (say, GitHub for example) and move to a more foreign tool or platform to complete the task at hand (this might include reading an email or reviewing a Jira ticket).

The impact of context switching

The bottom line is that any type of context switching negatively affects a developer’s ability to be productive. In our research, 44% of developers admitted that “interruptions and context switches regularly and negatively impact my productivity” in a significant way.

This is even more significant when combined with our previous findings about developer interruptions. Remember that above, we highlighted that non-developers are 50% less likely to realize that developers are annoyed by their questions and interruptions.

That means that non-developers are twice as likely to keep asking these “innocent” questions and causing context switches during the development workflow.

Poor collaboration has a direct impact on developer experience

As an industry, we’ve coined a new phrase in “developer experience”. If “user experience” is the level of comfort, accessibility and joy that an end user feels when using a product for its intended purpose, “developer experience” is the level of comfort, accessibility and joy that an engineer feels when actually writing code and developing software.

Technical employees are expecting work environments and tools that will enable them to do their best work. Companies are realizing this and taking deliberate steps to make the actual workflow more enjoyable. Some companies have gone as far as introducing a new Developer Experience function on the team whose sole responsibility is literally to enhance the work experience of the development team.

And so, as part of our research, it was important for us to try and assess the impact of poor collaboration and communication on a team's overall developer experience.

To do this, we asked developers and non-developers if they agree with the following statement: “Poor communication and collaboration with other stakeholders makes my time at work less enjoyable in a direct and significant way.”

• 52% of developers agreed with this statement
• By contrast, only 26% of non-developers agreed

This discrepancy is in line with our findings above, that non-developers are ~50% less aware of the workflow frustrations of their developer colleagues. And it is significant that more than half of the developers we surveyed felt that their developer experience was negatively impacted by the team's communication and collaboration issues.

Developers see the cause & effect of poor collaboration more than non-developers

It’s difficult to measure the impact of poor workflow collaboration and communication in real business terms, so instead, we tried to at least understand how the impact is perceived by the people involved. We asked the product development teams to indicate the extent to which poor workflow collaboration and communication directly affected their product quality, delivery schedule and tensions with outside parties.

Here’s what we learned:

Poor workflow communication leads to lower-quality products

• 45% of developers said that these issues have directly and negatively impacted the quality of their product Interestingly, only 18% of non-developers felt this way when asked the same question

Poor workflow communication leads to delayed deliveries

• 47% of developers said that these issues have directly caused delays in product delivery.
• 32% of non-developers felt this way when asked the same question

Poor workflow communication leads to tension with customers and management

• 46% of developers said that these issues have directly created tension between the team and company management, or between the company and the customer
• 38% of non-developers felt this way when asked the same question

Cross functional collaboration affects how people accept & leave jobs

The impacts of poor workflow collaboration and communication aren’t limited to product quality and delivery delays.

Our research found that these issues are having a real effect on the HR department as well.

Nearly 60% of developers and 65% of non-developers indicated that the ability (or inability) to collaborate effectively with other stakeholders during the product development workflow is a key consideration when deciding whether to take or leave a specific job.

In a time when tech companies are scrambling to find, hire and retain quality talent, these are startling numbers. It’s clear that the productive interaction between developers and non-developers as they build products together is a lot more serious than just another funny joke or clever meme.

Which workflow tasks need the most improvement?

The data points presented thus far give us broad indications about the state of cross-functional collaboration during the “development workflow”, but they don’t help us understand specifically what actions need to be improved. Every workflow contains a series of specific activities that have the potential to be trouble spots for the multidisciplinary team tasked with executing them.

So we took a deeper dive on this point to better understand exactly which workflow tasks could use the most improvement with regards to cross-functional communication and collaboration.

Here’s the data we came back with:

• UI Design Reviews = 57% of respondents said their team needed to improve this.
• Bug Reporting = 37%
• Acceptance Testing = 35%
• Copy Reviews = 28%
• Setting up staging environments = 26%
• Code Reviews = 20%
• Documentation = 4%
• Analytics = 2%
• "Our workflow is perfect!" = 2%

Developers are slightly less optimistic than non-developers

Finally, after hearing so much about the problems and frustrations, we were curious to know if these development teams held any hope for change and progress. To do this, we asked our respondents if they agreed with the following statement: “Developers and non-developers will never fully collaborate or communicate. It’s like cats & dogs or oil & water. They just don’t go well together.”

45% of developers agreed with this statement. As opposed to only 3% of the non-developers.

Go figure.

In conclusion

It’s clear that developers are frustrated with the state of communication and collaboration during their pre-release development workflows.

Non-developers are relatively oblivious to their feelings on the matter and they don’t correlate the effects of poor communication and collaboration the way that developers do.

Everyone agrees that these issues are fundamentally important and that they have the potential to affect many areas of a team’s day-to-day operations.

And while many developers believe that there is nothing that can be done to improve this, the vast majority of non-developers remain optimistic.

Putting aside the developers' gloomy outlook, we have to ask ourselves - what can a team do about this?

If development workflow communication and collaboration are so critically important to the success of any product or company, what can we do to make improvements?

At Livecycle, we’ve built an entire platform (and company) around solving this issue.

We enable non-technical stakeholders to provide visual feedback on the latest code changes by leaving comments on top of the latest preview environment. Developers receive the feedback in context and can react to it without interruptions and context switching.

By finding a way to level the playing field and bring non-technical stakeholders into the developer’s natural context, we create a common workflow denominator that sidesteps most of the workflow's friction points. And since everyone is reviewing things asynchronously, everyone on the team can enjoy fewer unnecessary meetings, faster feedback loops, and higher quality code (if you’d like to try installing it on your existing preview environments, just let us know.

Just being aware of these friction points, understanding their prevalence, and appreciating their impact are important first steps. That awareness together with the adoption of developer tools such as Livecycle is proving to be a combination powerful enough to dramatically improve - if not completely reverse - these negative trends.

So all things considered, we’re pretty optimistic about where things are headed.

Despite what half the developers out there might tell you :-)