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 function, but they are also fundamentally different from one another in terms of how they work, the tools they use, and the way they prefer to communicate with others on the team.
This workflow tension between stakeholders is widespread 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 with each other.
But sometimes, the most common issues are the ones that are least defined and most misunderstood.
Sure, everyone knows that these issues exist, but they don't give them much thought. They just roll with it, mutter some stuff under their breath and continue on to the next all-hands meeting.
And so, over the course of the past year, I decided to give these issues more serious treatment. I took a deeper dive into how developers and non-developers work together throughout the product development workflow. What works and what doesn't work.
And what exactly each persona is thinking about the other at every step of the way.
My main motivation for doing this was joining Livecycle - a devtools startup that enables the whole team to leave contextual feedback on top of any preview environment.
Since the whole premise of our product is to speed up feedback loops and reduce workflow tensions, I felt like I really needed to understand what those tension points were all about in the first place.
I reached out to 200 software development teams from around the world and asked them about their workflows. I inquired about their interactions and their frustrations. I gathered responses from people across all of the key engineering and non-engineering roles working in companies ranging from seed-round startups to publicly traded corporations.
Some of what the data revealed was to be expected, but much of it was revealing; and all of it fascinating.
Here's a summary of what I learned.
Developers and non-developers communicate differently.
The first thing that jumped out at me was the extent to which developers and non-developers communicate (and operate) on different wavelengths. The cadence and style of communication are unique to each persona on the team.
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 feedback:
- 53% of developers said they often don't understand review feedback from non-developers and 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 numbers showing these developer frustrations are notable, but not entirely surprising.
What was really interesting though, was discovering that the rest of the team doesn't even realize 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 of 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 a challenge.
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 developers' interruptions.
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 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 the 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 make my time at work less enjoyable in a direct and significant way."
- 52% of developers agreed with this statement.
- By contrast, 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 communication and collaboration issues.
Developers see the cause & effect of poor collaboration more acutely
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 tension 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?
In the quest to improve collaboration between developers and designers, the utilization of a visual feedback tool becomes crucial for efficient UI Design Reviews. Such tools streamline the process, allowing designers to quickly gather and implement feedback without the disruptive context switching that developers loathe.
The data points presented thus far give us broad indications about the state of "development workflows", "collaboration" and "communication", 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 to better understand exactly which workflow tasks could use the most improvement in 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 with team members 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 gloomy outlook of the general developer population, we have to ask ourselves - what is a team to do?
If development workflow communication and collaboration are so critically important to the success of a product and a 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 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 (and if you'd like an invitation to try our SDK with any preview environment provider, just let us know).
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.
