How do you manage decisions & disagreements among dev team?
As our team grows, I think it's pretty normal that we'll find more places to disagree! We've been managing it OK, so far, but I can see potential issues down the road when, say, two devs or groups have very different opinions on the best solution to a problem.
How do you manage the process of making decisions, on your team? Are there systems that dev teams use for debating one approach vs another, and then deciding on the outcome, presuming there's no one-right-answer?
I'd like to avoid the lead having to make the decision every time - are there fair , effective alternatives?
Trending on Indie Hackers
We've used the following simplified approach in the past with our development team on 6 persons:
First we talk about the problem domain in general and compare it's complexity to your previous products or projects. Then we reflect on the old technical decisions made and their pros and cons as we've found out that usually our team tends to use somewhat the same architectural styles, patterns and structures.
Then, each team member has a chance to present their thoughts about what should we do. Everything is written on a whiteboard. To make the final call, we then list which of these potential options are easy to reverse and which are not.
Simplified example (bolded are suggestions from team members):
ReactJS for UI - used for the last 10 projects - good docs - impossible to replace
Use CQRS in backend - simple to understand, hard to implement "pure" - hard to replace
Don't use CQRS, put everything in controllers - easy and fast, bloats up controllers quickly - easy to replace
Anemic domain models - fast, requires little knowledge on domain, makes refactoring a pain - very easy to replace
And so on, you get the point. In the listings you can go as specific as you want.
After we have written up such a listing, it is easier to decide objectively.
Hope this helps!
If you wan't to follow me on twitter, where I post dev related stuff like this, here is my profile https://twitter.com/zengouu
Like it! Sorry, slow reply 😆
I think it is important to make it clear to your lead that their job is not to have the answer (most feel like it is). Their job is to help everyone on the team grow. A lead making all the decisions is a sign of that lead's failure, not success.
The other issue I think comes into play is that developers are used to working with abstractions. But often times, that can lead to lots of disagreements with no room for compromise. Whenever this happens, I find it helps to start going through scenarios. If you go with Person A's solution, how exactly would it be implemented? What assumptions are there? What are the failure scenarios and how can you recover? Then go through the same with Person B. This helps bring more substance to a discussion other than "well I like things this way".
I also look out for this in the interview process. My interviews are largely around system design which is extremely open ended and ripe for debate. Candidates that can debate using logic instead of emotion attachment to certain patterns tend to be better hires.
I like this a lot - the scenarios really sound like they'd help individuals see the other point of view, and remove them from being quite so attached to a definite decision.
Interesting on the interviews, too - I often use quite open, general questions to get an idea of how people thing, but hadn't zeroed in on the logic vs emotion angle. Very useful!
Yeah, I like to debate in interviews because it's such an important part of the actual job. I try to be cognizant of the fact that candidates may be nervous so it has to be done tactfully. A lot of candidates still get extremely defensive of their ideas in an interview, which is good information to have.
Agreed, great approach