More Important Than Code (Dealing With Change) – Part 2

Tags

agile, change, influence, leadership, project management

Change is painful for everyone – and (as we discussed in Part 1) a little sensitivity to this fact helps a lot.  But understanding others when they are going through change is really just a small piece of a much larger topic – how to work with and influence others.

mgcpuzzles.com

These guys did not influence each other very well, did they?

Influence is not about manipulating others to get them to do what I want – it’s figuring out how to work with others to get what we both want.  And this is a primary ingredient in dealing with the incessant change that we pointed out in Part 1 is so much a part of creating software.

So let’s step back to some of the big examples of change we’ve been throwing around.  Imagine again that we are introducing a new tool – a new source control tool like git, or maybe a dependency management tool like maven.  We now know that this is going to be uncomfortable for everyone involved, but if we can appropriately influence those around us to work toward the common goal, we can make it more successful in spite of the discomfort.

It’s important that our software efforts are successful – because they make our lives better and the lives of those around us better.  I’d say it’s so important that we should learn to wield all the influence we can muster with those that are involved in these efforts.

Influence is a skill – one that you can practice and improve at.  And in seeking to become better in this arena, it’s important to understand that many people who think and write about this topic actually call influence by another name…Leadership.  In fact one of my favorite authors, John Maxwell says that “Leadership is influence, nothing more nothing less”.  I know many of us software-types might associate the word leadership with pointy-haired managers and over-ambitious MBA holders.  But we shouldn’t short-change ourselves by unnecessarily avoiding a topic that can have a very direct effect on the important software projects we are working on today.

To repeat myself a little here, influence and leadership fundamentally deal with how we interact and connect with other human beings.  Human beings are notoriously analog in their interactions – and often behave in unpredictable, confusing ways.  The study of how to work with these odd creatures as such is then much more of an art than it is a hard science.  So, the way you can become better at it is by learning from folks who are good at it, and by practicing it.

I am not by any stretch of the imagination an authority on leadership – I simply know the effects that the little bit of ability that I have in this area has had on my software as I’ve developed myself.  It’s been amazing.

So – one place to start is with the author I mentioned earlier, John Maxwell.  His new book is actually on the topic of how to grow ourselves – which is obviously helpful for those of us that hadn’t considered it something that we actually need to work on.

http://johnmaxwellonleadership.com/2012/09/04/we-reach-our-potential-through-growth/

Mr. Maxwell has also written extensively on the topic of leadership:  The 21 Irrefutable Laws of Leadership, Developing the Leader Within You, and many others.

I also recommend Dale Carnegie’s “How To Win Friends And Influence People” as well as Stephen Covey’s “Seven Habits of Highly Successful People”.  There are countless books (and other media) on the topic – the more you can learn, the better of your projects will be.

So remember – because of the ridiculous amount of change involved in software creation today, being able to influence and work together well with your fellow developer, your user base, or any stake holder is an invaluable skill that will reap great rewards.  But you will need to work at developing this, and that means getting as much information on the topic as you can find and practicing.

More Important Than Code (Dealing With Change) – Part 1

Tags

agile, change, programming, project management

Change does not roll in on the wheels of inevitability, but comes through continuous struggle.
-Martin Luther King, Jr.

---

Dr. King was right – change is not easy – it’s a continual struggle.  Creating software, almost by definition, is change.  So, to start with, we need to understand that creating software means that we are the agents of change and thus the instigators of a continual struggle.  This struggle is the cost of making the world, or our little corner of it, better in some way.

Why is change a struggle?  Because it makes people uncomfortable.  Why does it make people uncomfortable?  Because it asks us to change our habits.  Habits take a lot of time to develop and are costly to create (time is, in fact, money).  And whether we know it or not we value our habits greatly – whether it’s stopping for our morning latte, or coding on our favorite IDE.

So let’s take a break right at this point.  The first really important thing to realize is that by asking folks to change, we are asking them to discard valuable habits and replace them with new ones.  That is, we are asking for something valuable from another person.  We might as well be asking them to hand over a sizable amount of money (the amount of money in this analogy might vary depending on just how important or deeply ingrained the particular habit is).  So thinking about this – would we lightly ask someone to put a significant amount of money on the table, regardless our expectation of a high return?

So if we can get our head around the idea that change is asking people to put something valuable on the table then we are ready to look at how dealing with the effects of change so powerfully determines our ability to create incredible software…

I think we’ve probably gotten used to it – everything related to technology changes extremely rapidly at this point.  And it’s only getting faster.  In software, new tools, libraries, frameworks, and even programming languages pop up and then quickly become mainstream.  While how aggressive a particular team is at keeping up with the latest trends varies widely, even the slowest adopters couldn’t be called slow by objective standards.  In order to take advantage of new efficiencies and avoid having their stack become obsolete and unsupportable – teams adopt new/different technologies pretty rapidly, these days.

So, no matter how change-averse you are – I would argue that if you’re making software, you probably are still dealing with a fair amount of change on a regular basis.  The questions is really – are you dealing with it well – or are you letting it suck the life out of your development team?

A team that is handling change well may still be uncomfortable with change at times – but will be hungry for it, excited about it, and invigorated by it.

A team that is not handling change well will probably have something of a knee-jerk reaction of fear and dread when the idea of potential change is discussed.

So think about the last time your team decided to implement a new practice such as pair programming or test driven development.  Or when a tooling change was made – perhaps using a new version control system or a new type of server platform.  What was the general reaction like?  Did the team rally – did it flounder?

As you can probably gather by this point – this particular “people concern” affects every part of software in a big way.  It is “More Important Than Code” in a lot of ways and it is definitely a tool that we all need to have in our software tool belts!

To that end, part 2 of this post will continue by explaining not only how to deal with change but how, with practice, it can be used to multiply our ability to create incredible software.