Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Dude, You Can't Solve All the Problems by Yourself

DZone's Guide to

Dude, You Can't Solve All the Problems by Yourself

Learn the hard truth about your ability as a developer: you are not a one-man army. Learn to work together with your team.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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".

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,opinion ,agile web development team ,team collaboration

Published at DZone with permission of Dennis Doomen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}