Hey dev.to,
I wanted to get your take on the following observations I've had as a PM in large mega-corporation as we as startups. I figured most people on this site are developers, and could possibly help me understand the following behaviors I see from under performing engineering teams. I'd love to learn what I can do better to help the team win!
In the 4 years I've been a PM, I've had the privilege of working with some really stellar engineering teams. I've also worked with some not-so-stellar ones. The great teams are usually great because we're all communicating and trusting each other enough to enable decentralized decision making. When a team member gets out of sync, they quickly come up to speed and don't freak out if they disagree with a decision that's been made. Part of that is because the team is gelling on a personal level, but also because there's precedent for decisions to be revisited when new data is found.
With the teams where we've struggled, I've noticed the following failure modes can lead to our downfall.
First, there's a mode where the team either is very junior or lives inside an organization with a cover-your-ass culture. Either way, people are scared to commit to dates, goals, or even design decisions. If a team member is really into agile, I hear a lot of, "We're agile - we don't do dates" or "It's not agile to make commitments like this". I'm totally bought into customer obsessive, iterative development, but comments like these in this context make it seem like team members are using agile dogma to enable their pathologies.
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. I'm afraid that the resulting work is a product of design by committee thinking.
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. The next day or week, we'll be in standup or retro and someone will be shocked to learn that a customer is expecting "feature X" in March 2019.
So, my question to you guys here is: As engineers, have you seen or experienced teams who've fallen into the patterns as I described, and if so, how has the PM contributed to those issues?
Top comments (1)
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.