Shopify: Project Champion & Team Structure

What about the team structure?

One of the things that’s important with a of team structure is the multi-disciplined approach. Here’s a couple of things. One is that you realize that, generally, in any team, for that team to be successful, it’s going to have to have a balance of skills and experience in it. If I had a music ensemble, I’m not going to have five bass players, in a quintet; it just doesn’t really make sense. I need different disciplines to come to the table. So generally, if I was going to build any kind of a product, I’m going to have at least someone who knows a lot about the implementation and the building; someone who has an engineering mindset and, at least, someone who has a mindset about the experience and the design of it and someone who is going to look at the needs of the customer or the actual problem and whether or not we are building the right thing. That person might be more business oriented. So that’s one thing, to actually have those multiple disciplines.

Another thing that I think is extremely powerful is the idea that that is decoupled from the leadership, what you might call the project management, of who might lead a project. In Shopify, for example, we had this concept of Project Champions, who were people who run the project. It’s important to understand that that person is not someone who has the answers to everything; they don’t make all the decisions. But what they do is, they make sure all the decisions get made and they facilitate that. If they don’t know something, they will find out and they will find out who has the answer.

But the idea is that the ability to do that, that role, is totally separate from the discipline of the person. One interesting way to look at it is that if you look at a project and you say, okay, what is the greatest risk on this project; perhaps it’s a technical risk of building it? Maybe that’s going to be the hardest thing. Or maybe the hardest thing is going to be coming up with this fantastic experience that people will love. Maybe the problem is trying to figure out, exactly, how to scope the problem and bring it to market. Perhaps one way to go is to say, okay, if we think the technical problem is the greatest risk, perhaps we would have the person who is in that discipline who would actually lead the project.

That’s one way to go. Traditionally, in most organizations, they would have a project manager; it’s a professional role of someone who organizes the project. But often, those people aren’t actually doing anything on the project, other than organizing. There is often this tension that is created. This person is telling us how to do stuff and running stuff, but they don’t actually have any skin in the game because they’re not actually building parts of it. The idea that you would have someone leading the project who, actually, is one of the people working on building the thing, I think is very powerful.

If we go back to the jazz analogy, you don’t typically have anyone who leads a jazz group, who is just out the front and waving their hands. It’s always someone who is in the group, who is actually part of the process of actually building the performance.

A credibility thing with team members?

Yes, and also, almost an insider knowledge. They really know what’s going on. You don’t have that abstraction. Sometimes, when I worked in some other organizations in the past, especially big organizations, you see people who get shuffled around, who are managers of whatever. Last week, they were the manager of something and now they’re the manager of something else. They come to manage this thing and they have no background experience, knowledge or anything, about the domain at all. But supposedly, because they are a manager, it means that they can manage the thing. Sometimes, that doesn’t really go very well. It’s a powerful thing to think about leadership in a different kind of way.