Dude, you can’t solve all the problems by yourself

I think that the gist of this post should be pretty clear. Unfortunately I've fallen in that same trap myself many times. So often, I had to refrain myself from pulling somebody's keyboard from under their hands, just because I thought I could fix the problem at hand myself much faster. But with the risk of sounding arrogant, quite often I can. And sometimes, when the circumstances demand, I do. But in almost every occasion I did, a bit of patience would have increased the chance that the involved colleague could have solved the problems themselves or even propose a better solution. And isn't that a much better approach for scaling development projects? So assuming you recognize this kind of (mis-)behavior, here are a few more good reasons for keeping your patience.

• People might second guess your solution, potentially identifying a flawed design more quickly. Similarly, by clearly explaining your solution or approach, you might surface new insights yourself (a.k.a. the cardboard programmer). At the same time, you might get more buy-in from your team.


• It increases trust and respect the people have for you. They won't only see you as the fix-it-all-guy, but also as the go-to-guy for advice. In a way, it makes you approachable. Especially if you're filling a high-profile role, being approachable by new people or people without strong communication skills is essential for an open and efficient work environment.


• Seeing your colleagues solving the problems with a bit of help can increase the trust you have for them. And if you trust the people you're working with, you’ll also more easily delegate responsibility to them. I'm pretty sure that will make your live much easier.


• Gives people more autonomy and allows them to learn from their mistakes, which will significantly increase the capacity of those people. In retrospect, the single biggest mistake I made in my career is to try to keep people from making mistakes. It has cost me a lot of energy, and never gave them a chance to learn and experiment. 


• If you teach somebody a new shortcut key, a debugging trick or a convenient command-line tip as part of a solution, chances are that that person will cascade that knowledge on to other colleagues, much faster than you do alone.


• If people feel the solution is theirs, they usually also feel more responsible for it, automagically increasing the commitment they'll give to it. At the same time, successfully solving a problem will increase their security level and increase the energy they will take up the next challenge.


• Being the one with all that knowledge and skills may put you in a powerful situation for a while, but at some point, you simply won't be able to handle all that work anymore. Being able to distribute the work to others so that you can take a couple of days off to spend some time with your family or attend that awesome conference will quickly become a difficult or impossible thing to do.

If those arguments are not enough, what do you think this will do to the strength and autonomy of the team as a whole? So the next time you tend to make that mistake, think of the old phrase "The whole is more than the sum of its parts".