| HN Mirror

Like the Agile Manifesto it's all about balance (IME).

One of the (many) ways I failed as a manager was to not trust my gut. To want to enable my team, even when what I thought they were pitching was questionable. I'd hoped that some technology, or this particular team would prove my own previous experience wrong. That through the power of team work and ambition it would turn out differently this time, but most of all, I couldn't figure out how to present a convincing argument to the team why I was skeptical and I didn't want to leave it at "because I said so".

On reflection, a cure might've been to ask for further analysis, both rewards and risks, balanced against costs. But that often comes with it's own cost and what I really wanted to say was: "We're not doing this because the solution in hand is good enough and better at any non-trivial price doesn't serve our business interests."

Of course being a developer myself that's a difficult message to internalize.

I guess it comes down to: I'm still not sure how to handle this situation, but experience definitely needs to be weighed heavily IMO and if your processes (and management experience) are lacking in maturity a lack of leadership in preventing a less experienced team (though very technically skilled, enthusiastic and hard working!!!) from making bad decisions can be devastating as well.

I guess what I'm trying to say is that, through my own mistakes managing teams, I think a lack of confidence and projected authority can be just as bad as any of the sins listed here, and is an important balance to consider on the flip-side of Arrogance.

That said, the rest of the list here is spot-on. The only nit I'd pick is Sloth. A description closer to my own experience might be one where the requirements are known, but not communicated thoroughly and clearly.

When a developer can say: "Show me where I was told this" and you can't respond with a URL to an Issue, instead relying on a months old email, Slack message that wasn't acknowledged, or no proof at all, then you have a big problem. Knowledge that isn't communicated, or analysis that's only half done, can mortally wound any project where the developers don't have the authority to decide the success parameters (time, budget or scope).