Item — HN Reader

This is the right answer. Thank you.

But I still have a question :

> Unfortunately, on some teams, a strict hierarchy is imposed and you ARE expected to comply with a peer's instruction in all cases.

Or maybe fortunately? How do you handle weighting benefits when the team is flat, i.e. there is no clear hierarchy?

Say for example, two senior developers disagree on how to structure a piece of code, because each one finds it more readable his way. Now structuring that code would have implications on other dependent pieces, the team using it, and future development.

How do tou handle such disagreement when each member has a strong opinion about the issue?

1 comments

> How do you handle weighting benefits when the team is flat, i.e. there is no clear hierarchy?

First, is there no hierarchy at all or a hidden one? That's the first thing to find out - you need to know the rules of the game before you can play.

> How do you handle such disagreement when each member has a strong opinion about the issue?

If you're a dev, I've had luck in such cases asking for a third dev or a supervisor to step in as a tiebreaker.

Or you can find out who is the most knowledgeable and experienced person on the team in this one problem domain, and go with their opinion.

Disagreements are not necessarily a negative thing, but an inevitability that can become positive or negative depending on how you handle them.

If you're a manager, then you set the rules of the game. Just let everyone know what those rules are and make sure they are followed.