Ways to Improve Communication Between Developer Teams and Non-Technical Stakeholders

Keeping communication lines open between developer teams and non-technical stakeholders can be difficult, here are some tips to make it easier

Whether you’re working on a startup or a big company, keeping your stakeholders and non-technical partners engaged and up to date on what the tech team has been building can be hard.

Here are some of the things I’ve done with my work team and side project team to help keep stakeholders in the know and tightly engaged in our process.

Create a demo page

While my work and side project team plans for the tasks/stories we’ll be working on for the next sprint(or whatever period of time you’ll be working), we add them to a demo page with a table containing each task, an easy to understand description, the name of the person who worked on it as well as a screenshot of the completed work.

Here’s an example in Notion, but this can be done in anything from google docs to confluence.

Having a page like this gives 3 advantages:

1. Easy way to track progress and things that have been worked on for the team. You can go back and reference these things when future questions crop up.
2. Allows stakeholders to see the progress easily and visibly: instead of getting asked a billion times what’s the status of the project or what’s been done so far, it’s much easier to send a link and have them read through the page.
3. It provides a quick reference for other external teams to know what you’ve worked on. Some times if you’re cross collaborating with other teams, they would like to know the status of the project or what led you to this direction.

Have a product demo every couple of weeks

For my team, this means clearing out a 30-minute window every 2 weeks to present to our non-technical partners what we’ve worked on this past sprint. It’s best to choose a time frame that works for everyone but if that’s not possible, either do the demo twice or choose a time where the maximum number of people can attend. I recommend having a demo at least once a month or twice a quarter.

The benefits of this are as follows:

• The stakeholders are aware of the team members. Putting a name and face to the online communication helps build camaraderie between the stakeholder and the development team. It will be helpful is minute ways and make non-technical partners more mindful when decisions are made, features are pushed, and just general awareness of how the product is evolving.
• The non-technical partners are aware of what is being worked on as well as any blockers that may have happened as they happen. This means there are no surprises at the end of the quarter for certain features not being completed. Everyone is on the same page and knows what’s been going on.
• It gives you as a developer a deeper understanding of your task. Thinking about how you will communicate a deeply technical task to a non-technical person in an easy to understand manner is something everyone should practice. This allows you to do that.

Include non-technical partners in critical alert channels

My team has multiple slack channels(separated by environment and priority) where we get alerts about the status of our services. We usually only add our partners in the production channel and for critical alerts like when a service goes down. This has been the happy medium of them getting alerts they’re interested in without being overloaded by the noise.

We’ve found that doing this helps keep them in the know so that they have the necessary information to report to other impacted people or higher-ups.

This is something that should be decided at your discretion. If you’re a startup you might not want your stakeholders hearing about every-time your service goes down, but if you are a team that has other teams depending on your product, it would be helpful to your partners if they have a bit of head's before they begin getting multiple angry messages from other people that the product is not available.

Have an errors page

Tying into getting alerts, having a simple page where stakeholders can post the errors they may encounter while using the application rather than emailing the team or individual developers. It can be a simple page where they type out information about the problem or it could be a ticket service like JIRA’s where they fill out a ticket and track the progress to completion. When the problem is resolved, a simple description of the fix can be posted

The benefits of this method is that:

• Clear documentation of the errors as well as who it happened to.
• Central location to store those errors. It becomes easier to track and see if a similar error happened in the past.
• If multiple stakeholders are experiencing the same error, it is clear and they can follow the progress.

Visible functional tests

This is a bit of a weird one and is not really for everyone as it depends on how involved and technical your stakeholders are. In my teams’ case, we had a pretty technical product owner and other non-technical partners who were familiar with writing business cases or rules.

Since most of our functional tests are written in gherkin/cucumber(chosen for how legible it is for non-technical people), we were able to have the functional tests written on JIRA. The tests were written in an easy to understand way.

Whenever a code merge happened, the JIRA tests were pulled and run against the new changes. The results were then published on JIRA which allowed our stakeholders to view at a glance which functionalities were passing and failing.

Passing functional test execution set in JIRA

Again this is not for everyone out there. Additionally, if you don’t use JIRA I’m sure there are other visualization tools to do this with or you could crank a quick one out.

Conclusion

These are some of the things my work team has incorporated in the past year that have helped build a great relationship with our stakeholders. We’ve noticed that they are more engaged, look forward to finding out what the team’s progress has been, really appreciate the effort we put in, and love having a central location for viewing the application progress.

If you have tips on other things to do to improve communication, I would love to hear them. If you’d like me to do a tutorial on how to link tests to JIRA using Java or any other language let me know.