Summary

What is a good framework to differentiate the different roles of stakeholders within a project?

In service design, whenever you do a project, there is plenty of people involved. So it's often smart to be very clear about who has which type of power within that project.

In an interview with Nilay Patel on the Decoder podcast, Github CEO Thomas Dohmke shared a framework that they use a lot at GitHub that really resonated with me.

It's the View, Voice, Vote, Veto Framework.

I looked around to find the original source for it, but didn't find it. Nevertheless, it's still super interesting.

And in fact, in this video, I will share four reasons why I think this framework is pretty useful and how I'm going to implement it in my own practice in the future.

But before that, we need to talk a little bit about the four parts of that framework.

So basically the framework separates people within four different worlds.

People who have the view role can basically see stuff. But can't comment or give much feedback on. They are in the know, at least.

People with the voice role, they view stuff and they can also share a bit about what they think about it.

When you have that voice role, you are a feedback giver. It doesn't mean that your feedback is a decision, but it's still something inspiring that can get used by the team.

When you have the vote role, you are part of the decision making. You can give your vote for one or the other option.

And obviously you can view everything and you can share your feedback or share your voice about it.

If you have the veto role, you can do all of the previously mentioned things.

So you can view, you can share your voice or feedback, and you can vote, but you have a final veto, which means that You are the person who can give the final yes or no.

With such a framework, you can very easily on board a lot of people and still make very clear progress.

For example, you could have within a company, hundreds of people who can see something and be in the view role, maybe have a few dozen people who are in the voice role who share feedback. Then have a smaller team of maybe five people who can vote on something. And then finally have one clear veto person who is like the final decision maker.

You can basically see this as a participation funnel where there is a lot of people at the start and less people at the end.

But still a lot of the company gets involved.

That's all good and great, but what are the four reasons why I love this framework so much?

Reason number one. It's a great kickoff template for new projects.

Making clear at the start of a project who has the vote role, and who has the veto role will make things much more smooth.

And what I like about it is that it's granular enough. So instead of asking just who is the decision maker, we have four different levels of participation.

And therefore, this framework ensures that we are not just making great decisions, but that we are also preparing the company for what's about to come and using the brains of the company or organization we're working with to make sure that these decisions are the best.

Reason number two. It helps to understand a culture. If you are aa freelance service designer or a service designer working in an agency, you get thrown in different cultures a lot. You switch from company to company and obviously each company has its own culture.

For these types of service designers, this framework can help to quickly understand what's the general culture about decision making and information sharing within that company.

In fact, in some organizations, which are very top down, you might even have nobody in the view role. And in other companies, you might have a lot of people into the view and voice roles. And this tells a lot about the culture of that company.

It also tells you how the internal communication works within that company or organization.

Reason number three. It helps to give better feedback.

Whenever you share a feedback, you can use these keywords to make sure that the person who will read your feedback knows if it's just a voice, a vote, or a veto.

In fact, before even sharing your feedback, you could say, this is my voice for this information, or this is my vote for this information, or this is my veto about this information.

And then the person who receives the feedback knows at what level that feedback is.

Let's imagine that within a project, Bob gives a feedback to John. Before sharing his feedback, he clearly states, this is my veto feedback. Don't do this. And then he shares the details.

John receives the feedback and he sees very clearly, this is a veto feedback. But there is an issue here. For John, Bob doesn't have the role of the Veto. He doesn't have that power.

Instead of arguing about the content, he can check first if Bob really has that power. And if yes, he would have to accept it because it's a veto feedback. If John realizes that Bob in fact has not that power, but is in a voice role, He can then go back to Bob and clarify the role that Bob has and what type of feedback he should share.

Reason number four. It creates a common shared language.

A lot of my work as a Service Design Practitioner is to create a shared language so that everybody speaks about the same thing with the same words.

And this framework creates a shared language around roles and who can share what type of feedback.

This framework resonates a lot with me. But how will I use it in the future?

The first place where I'm going to try to use that framework is within the onboarding and kickoff of new projects.

By using it at the start of a project, I'm making sure that I know what are the different roles and who we have to involve at what level.

As I will use that at the start of a project, it will create a shared language that I then can use again and again within the project to make sure that I understand clearly the feedback that I receive.

It will help me to lower and clarify tensions. By having conversations like: You're sharing with me a veto, but I feel you are in the vote role. So what's your vote?

All of this shows once again, that words have a wonderful power and that The way we use words with other teammates is also a part of Service Design.