Hey! I think this is a very complex problem with a variety of factors to it. I really don't know your exact situation, but here are my thoughts:
Either way, people are scared to commit to dates, goals, or even design decisions.
I think this might occur when things change too fast or too much. In this case a clear long term vision could help a lot. When I think about software flexibility I usually imagine a tower or a bridge in my mind. The more beam the structure has, the more rigid it becomes. The same goes for software, the more code you write, the more feature you add, the more it becomes rigid. That's why you have to be really careful when making big decisions, you have to identify the directions in which you want to keep your software flexible.
Because the technical team members don't want to make decisions, I end up having to spend a ton of time with the entire team getting everyone to come to consensus.
This doesn't sound bad at all. I mean, it depends on what type of decisions you are making here, but I think higher level decisions, or decisions affecting many aspects should be made this way.
The worst part about this is after we've supposedly come to an agreement, team members seem to have sudden onset amnesia, even if I send out an email summarizing what we agreed to afterwards.
If you have come to an agreement about something important it should be in written form. Emails are not the best choice in my opinion, they represent an event-sourcing type of model: you usually don't get the broader picture from one email, but multiple ones (and sometimes slack, verbal communication). You have to collect these bits of information then organize them in your mind in chronological order. And what if you get a new email? Then you have to diff them, or decide if an older one is obsolete or not, etc. Engineers need specifications. Living documentation is the best I think, because you always know where the information is, and that it is the actual information. For example JIRA has a lot of useful functions: you can create issues, you can update them, comment on them, check their history, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey! I think this is a very complex problem with a variety of factors to it. I really don't know your exact situation, but here are my thoughts:
I think this might occur when things change too fast or too much. In this case a clear long term vision could help a lot. When I think about software flexibility I usually imagine a tower or a bridge in my mind. The more beam the structure has, the more rigid it becomes. The same goes for software, the more code you write, the more feature you add, the more it becomes rigid. That's why you have to be really careful when making big decisions, you have to identify the directions in which you want to keep your software flexible.
This doesn't sound bad at all. I mean, it depends on what type of decisions you are making here, but I think higher level decisions, or decisions affecting many aspects should be made this way.
If you have come to an agreement about something important it should be in written form. Emails are not the best choice in my opinion, they represent an event-sourcing type of model: you usually don't get the broader picture from one email, but multiple ones (and sometimes slack, verbal communication). You have to collect these bits of information then organize them in your mind in chronological order. And what if you get a new email? Then you have to diff them, or decide if an older one is obsolete or not, etc. Engineers need specifications. Living documentation is the best I think, because you always know where the information is, and that it is the actual information. For example JIRA has a lot of useful functions: you can create issues, you can update them, comment on them, check their history, etc.