Adding my thoughts to a spot-on article I came across.
So this morning, this piece on “Ways to improve communication between developer teams and non-technical stakeholders” landed in my inbox. It felt pretty familiar just by the title and it was indeed. Working with tech stakeholders as their non-tech counterpart a few years in a row, I can confirm every single bit of the learnings the author brings forward. Not a bad opportunity to put my two cents in, I thought.
So here are a few best practices we tested with tech teams and decided to stick to.
Have some “business” documentation in place.
Naturally, the team keeps one or more roadmaps to plan and monitor the work. These roadmaps can have all types of details and assumptions, but do they really contain the business pitch, business case, the executive summary if you will, behind the endeavour? Including such a section within the existing roadmap or drafting a separate live doc with this content can act as the starting point for any stakeholder or team within the organisation – from the CEO to your occasional non-techies.
Share your mock-ups.
And generally share visual examples. No matter how good of a storyteller you are, why let people imagine what you’re working on, or wait for the polished design before the launch? Make the idea tangible early on, and keep refreshing while going. Simple things like “here’s what the feature can look like”, “here’s how clicking here should work”, “here’s how the user navigates around” can be part of your “sharing is caring” attitude all along, not only your roadmap.
Talk about your testing.
Are you testing? Maintain a dedicated space to announce these tests to the company (yes, the company) in a wrap-up with all essentials: what the eye-catching name is, what this is about really and why, how the test is happening, what you’re expecting to see, who’s impacted. Provide updates where relevant. The minimum expected here would logically be to follow up on the outcome of the given test. But this exercise can certainly go beyond, making plenty of information and analyses available to a circle wider than your team. After all, there is business knowledge there ready to be consumed.
Run (more) inclusive sprint reviews.
True, sprint reviews aren’t for everyone, and they don’t serve the casual purpose some far stakeholder might be thinking about. However, the bigger your company gets and the more your stakeholders add up, you will inevitably start seeing faces that aren’t part of the team. The first step here would be to understand if you want to proactively include those people in your reviews, or if you’d rather keep it to the basics – your team plus a few relevant externals. Either way, you might need to spend some extra time adjusting the content and the actual presentation to those additional people. Nothing spectacular and overly time-consuming, though. This is more about fine-tuning the jargon or pointing at work and takeaways that are relevant to or impact people, teams, and work outside your immediate surroundings.
Consider putting an actual product marketer in place.
Especially if the company has significantly grown in terms of product output and employees, sending the relevant information as well as receiving the right message can get tricky. The moment you hear someone whispering “Who should do that anyway? It’s not in my scope…”, you know it’s time for a product marketer. This person is here to help. She understands the tech part of the story to such extent that she can create the effective communication for the non-tech buddies who need it either to get the memo or to work with it. After all, it’s also about selling the very idea you’re working on, so why not trusting an expert to do it right?
Allow communication between tech and non-tech stakeholders to flow.
I’m pretty sure you’ve heard all these great things about the value of great communication and how great communication creates all those other great things. This is pretty much the point to be remembered here. Any stakeholder is a stakeholder: she can have an opinion, she might be curious to know more, she should be able to share an idea or even give feedback given her role. Even if it’s not about co-creating something in particular, maintaining some healthy communication flow between a tech team and everyone else fosters good relations and understanding even before you get to the tech talk.
Image via Season 14 GIFs on GIPHY.
I walk fast. 