Out of Owls

View Original

The Other Digital Divide

You’re probably familiar with the concept of the Digital Divide - the unequal distribution or access to resources (broadband, equipment, education, etc) which creates an advantage for those with the means to take advantage of it. It’s a thorny issue, one that’s difficult to solve that cuts across geography, class, and other social factors.

There’s another Digital Divide - one that we impose upon ourselves. If you’ve ever been on a product development team and talked about what “the business” wants, you’ve experienced it. Or if you’ve ever complained about waiting for “IT to deliver the requirements.” Or if you’re regularly in discussions where nothing can be decided until someone meets with “the stakeholder.”

It’s the divide we put between people in the same organisation, working on the same goal… but not actually working together on it. It comes down to one fundamental flaw: we’ve confused the definition of a team with an org chart, rather than a unit that is designed to get things done.

I’ve written before about Who Belongs on a Product Team

A Product Team is a group of people who can:

  1. Ask a question

  2. Get an answer

  3. Understand that answer

  4. And take action based on that understanding

Most teams - most companies of any scale - still fall victim to Conway’s Law. So how can you overcome this artificial divide?

I wish there was a magic answer that always worked. Every organisation is different, personalities differ, and there are lots of barriers in the way. That said, there are a few approaches that I’ve had success with in the past.

  1. When dealing with multiple stakeholders, create a council.
    Bring the stakeholders together so that they’re actually talking to each other and reacting to your strategy, updates and challenges. They need to take responsibility for the success of the objective, not just be cheering or jeering from the sidelines.

  2. Schedule regular get-togethers with the whole team.
    This isn’t about stand-ups and Jira - it’s about making sure that the strategy and needs for the whole objective is achievable by the people in the room (or on the call). It’s about creating a relationship between the people responsible for creating the capabilities, the ones who are selling & marketing it, handling compliance & legal, and anyone else who might contribute to the success or failure of what you’re trying to accomplish.
    If it’s important for the company to get hit this goal, then it’s important to ensure that the people who can make it happen have the time and impetus to contribute to it.

  3. Make sure you know who is on the team - and their level of involvement.
    Use Emily Webber’s Team Onion or similar to ensure that you know everyone whom you might need - as well as everyone that believes that they should be involved.

  4. Work out loud.
    Map out who you need to keep informed about the work you’re doing and ensure that they’re kept up to date - both with good news and bad. (Bad news delivered early enough can be factored in, dealt with, and sometimes fixed before it’s a problem - Bad news delivered late is a disaster for everyone.)
    Use the Power & Interest matrix - which really should be renamed Influence & Interest, to be honest. The CEO’s PA, for example) might not have much in the way of formal power, but I guarantee that they have a ton of influence. 

Publish weeknotes, or short videos, of what you’ve learned. These shouldn’t be dense: keep in mind who your audience is. To ensure that they’re read/watched, keep them short, interesting and useful, and be clear about what decisions have been made as a result. People like to be kept up to date, and they like stories.

Most importantly, ask your key partners about the type of communication that works for them - there’s nothing worse than spending time and energy on something that no one’s going to pay attention to.