A lot of these concepts certainly apply in anything in life, not just software design, but all the same Leading by Example is another great post from Jeff Atwood.
Personally I don't heed this advice often enough. We all know that leading by example, and respecting others is a better way to get things done in the long run than is the "unilateral" force it down your throat approach--that is not a revelation. But at some point you also have to arrive at the consensus (for standards for example, the debate has to end after the input period) and you have to adhere to it. We also all realize that sometimes more direction is required. It is occasionally difficult, for me, to stay patient and not either go to "want it done right, do it yourself" mode, or to become the "enforcer" the article notes.
It's a balancing act. The key though, IMO, is to try to engage everyone and also to show that as a leader you are contributing. Your job is not just "to lead," but to also get stuff done and show why certain standards and approaches are better in the long run.
It's part carrot or stick, and part show me.
Developers are, for the most part, smart and efficient by nature. They don't respond well to being told they are doing it wrong, and even less so when outsiders who haven't been on the front lines are making the recommendations. An open shop where anyone can suggest a change, with their own validation and a discussion, and where general guidelines for style and metrics are in place works well, in my experience. A shop where you have to use these X tools, have to build it like Y no matter what, and where "consultants" (be they external or internal) are doing the design without feedback, is a recipe for disaster (also in my experience).
Chatter
6 hours 59 min ago
1 day 7 hours ago
1 day 8 hours ago
4 days 2 hours ago
1 week 7 hours ago
1 week 11 hours ago
1 week 1 day ago
1 week 3 days ago
2 weeks 1 day ago
2 weeks 2 days ago