You can’t do a better job if you don’t change what you’re doing, but change is hard.  It’s especially hard when what needs to change is your colleagues’ approach to software development. Moving your team forward often requires persuading your peers to change their behavior, sometimes to do something they’re not doing, other times to stop doing something they’ve become accustomed to.  Whether the issue is to embrace or avoid C++ language features, to adopt new development tools or abandon old ones, to increase use of or scale back on overuse of design patterns, to adhere to coding standards, or any of the plethora of other matters that affect software creation, moving things forward typically requires getting your colleagues to buy into the change you’re proposing.  But how can you do that?

Like you, Herb and Andrei and I have co-workers we sometimes need to nudge in one direction or another, and as authors, trainers, and consultants, we often find ourselves needing to convince diverse sets of people we barely know to modify what they do.  In this panel session, the three of us share how we go about doing this, and, because specific examples are worth a thousand generalities, we take your questions, too.  In fact, we encourage you to post your “I just can’t get my colleagues to see the light!” stories, questions, and advice as comments on this blog post.

Scott