How to deal with member that has excessive ownership

Question

I'm currently leading an amateur team of around 20 working on a relatively not-so-small side project, and we plan to deliver the result to thousands of users after a month or two.

However, there is one member (who theoretically should be in charge of UI/UX) that I am worried about.

In my own perspective, I think the member is taking way too much ownership; the member seems to take the whole project as his own baby, take part in almost all sub-teams, use his own understandings to decide what to deliver, and often turn down others' suggestions.

I did not notice this in the early stages of the project; I thought the member was just very supportive and willing to contribute. However, during the past few weeks, this situation has been more and more noticeable; he now also commits as a frontend and even resigned from his own job last month to commit even more to the project. He expressed quite a few times that he wants to deliver the whole project on time and ensure that the output matches his expectations.

While I sincerely appreciate the member's contribution, his excessive ownership and insistence are causing some trouble. He tries his best to make sure the UI team delivers what he expects, not what I or other members think our users would expect. We do have Product Requirements Documents (PRDs), but they are now pretty much just a side reference to him, ignoring detailed descriptions that he does not agree on. He also vetos some PRDs if they violate his own expectations or understandings of the project, and is reluctant to adapt to other points of view.

Unfortunately, we are not in the kind of (atmosphere? society?) that encourages people to directly express their concerns; most members are undergraduates, so they don't naturally feel confident to directly speak out against the senior members. (Yep, some Asian culture.)

I am not sure what to do; my past career (around 3yrs) is mostly as a developer, only with a short time working as a substitute PM while working for a startup. I just really don't want my other members to find out that our users don't like the final results after working hard for months...

---

Edit: a bit of background

The project was a students-maintained service in my alma mater, mainly to serve students and professors for smoother lecturing. Since demands/users have grown from dozens to thousands, the service is both functionally and technically outdated, and really needs some refurbishing. I talked to professors who are in charge of the system, and I volunteered to organize a team to make a brand new version of the service.

I initiated this project, and it is totally volunteer-based. At very early stages I decided all things, and after the member joined we discuss most requirements together. The member volunteered to conduct some user interviews (and I willingly let him), and we will discuss the requirements together.

I guess I have too many roles (I'm also the backend tech leader), so I really do not have enough time to work out all the details, and in the middle stages I usually let the member decide on some details by himself, given that we already reached consensus on meta stuff.

In the past few weeks, the member started to refuse to accept my ideas and we almost had a pretty serious quarrel privately. I thought I was being too (verbally) aggressive and tried to give in a bit, but things seem just to get worse. Now the member strongly insists on his designs and turns down most suggestions from other members. I am still the official person to make decisions, but I'm losing control of the UI designs since he will simply refuse to deliver what I expect and do what he thinks he should do. This recently resulted in inconsistencies between design mock-ups vs. PRDs + backend implementations, and frontenders are sandwiched in-between...

Answer 1

This is an example of what I will call the “startup vs. process” problem. Even though no money is involved, in group dynamic terms, you are the founder of a startup! All startups face the question of when in their growth cycle to put some formal processes in place, and virtually all of them do so too late—after preventable problems have arisen. I am not criticizing you; my point is that your situation is normal. :-)

I advise startups on their processes. At your stage I would advise what your commenters have hinted at, which is to formally define some roles and a work management process. You mentioned meeting a date; throw that idea out. Traditional (“waterfall”) project management and its deadlines have value in some situations, but not in new product development, which is what you are doing. It is impossible to predict a delivery date in your scenario, especially with volunteers. Focus on quality instead.

If you are able to get people to join team meetings on occasion, a light version of Scrum will help. First, identify a "Customer." Ask if one of the faculty members you spoke with is willing to be the person with final say on the business requirements (design and features). This is how things would work if your team was a business with one paying client. Then identify the Product Owner (PO). The PO translates those requirements into language the team can actually work on—which usually includes breaking them into smaller chunks I will call “tasks” in this scenario—and has final say over their priority. Finally, identify a Facilitator (what other people call the “Scrum Master”) to run the meetings and coach the team between meetings. In those meetings, part of the Facilitator’s job is to make sure everyone is treated as equal and everyone's perspectives shape the tasks. The people then pick what tasks they want to work on until the next meeting.

If you can’t have regular meetings, you can shift to a light version of Kanban. In this case, a combined PO/Facilitator merely feeds the requirements into a prioritized list published somewhere that everyone can get to it. Then people claim one task at a time, indicate that in the list, work it to completion at their own pace, and then pick the highest-priority task they can work on to do next.

By taking the PO role yourself, you would gain control over the issues you are concerned about. Or, by giving the PO role to the other member, he would now have some formal control over the things he is claiming for himself now. But he would be forced to defer to the Customer on requirements, and to you as Facilitator during the meetings. If he is not interested in conforming to the process (and everyone else does), you would have grounds to ask him to leave the project. That’s okay. Over the long term you will get a product that is higher quality and fits the users’ needs better.

A detailed description of my light Scrum for startups is here (free and open source): Agile for Entrepreneurs.