A long time ago when I was a team lead, we were in a planning session and I made up the rule of doubling. Jokingly, I said we should just double the estimates of all our developers (at the time estimates were in hours or days, not story points). The reason behind it was the fact that doubling would make the outcome more realistic, as I knew the developers were vastly underestimating tasks. »
I preface this by saying I believe I know very little about management. I am a software developer who happens to also manage, not the other way around. Recently, I have been on a Don’t pass-the-buck kick. What do I mean by this? Imagine the following scenario. Chris the CEO decided that manager Max's team needed to stop working on widget X and start working on widget Y because it has more business value. »
One of the hardest tasks I have as a manager is empowering developers to make their own decisions. I like to think I do it pretty well, but I know way too much about a lot of applications. Sometimes I find myself defining how something should be done instead of just what should be done. For developers turned managers, I imagine you might feel the same way. What it really boils down to is understanding when to step in and when not to. »
Good developers have a tendency to learn, which creates a problem. Everything they did yesterday, they want to rewrite to be better. They are NEVER content with their code! To make things even harder, most developers are pessimists and always make the current state of any application worse than it really is. While these are actually great traits for their role, it can be easy to let developers sell themselves short and miss working on something great in favor of improving the old. »
In war, trenches are a fortified position soldiers use to defend against enemy attacks. They help keep soldiers safer than they would be out in the open, making enemy attacks much easier to fend off. The problem with trenches is they don’t allow progress. You can’t just move a trench, you have to get out, move forward, and build another one. Software developers often have a similar, albeit less deadly, problem. »