Influence Change: Part1

Something I love doing is going into a new environment to learn. I have a fairly broad set of interests which helps but I love to approach every situation, even those that seem familiar, as an opportunity to walk away knowing something I hadn’t known going in. It is with this curiosity that I have approached taking on new career opportunities or tackling problems that have been tossed my way. It is with this curiosity that I have discovered some of the biggest opportunities to impact the various organizations that I have worked for. This leads me to my theory for today - that in order to influence change you must see a problem to be solved and then be able to explain it to get others to see that problem as well. Without accomplishing this any efforts to actually make change will either outright fail or will lead you back to needing to discovering these points before getting to the end.

Some may say that this seems obvious but I challenge anyone who has been around in the Software Industry more than a few years to think about about two scenarios.

Scenario 1: Asking (or telling) your boss that it is important to try out technology X

I suspect most of us have been here, perhaps some more then others. I certainly have been. At any reasonably sized company that I have worked with the response might start with something such as “That looks really interesting…”, at which point my hopes are up, finished by “…but we have other things to get done and don’t have time right now.” Every so often you might ask the question again but it always seems to end the same way. With every attempt you become frustrated and eventually give up.

Scenario 2: You are told to implement using technology X

For those in a slightly more senior role there is nothing more frustrating. We all have the tools that we love and being hand-cuffed to a technology isn’t fun. It could be something simple like being told you must use some internal tool rather then one you (and perhaps the team) is more familiar with (perforce vs git, home grown tracking system vs JIRA, you name it). Ultimately upon reflection you may find that you drag your feet for hours attempting to fight the decision which is costing the company, and most importantly your customers, from receiving value.

A better approach: Why before How

At this point I hope a number of readers can relate to such situations; so why is it that they seem to occur so often? I would argue that it is human nature and it leads to one of the most common pitfalls that I encounter when we as leaders are attempting to institute change and that is focusing on a Solution rather then focusing on getting agreement on a problem. Think about it for a minute. If you are able to state a problem that you would like to have solved with enough detail that you can hand it off to a small team of engineers then that team can be empowered to own a solution. This is a powerful cultural tool - having engineers that feel that they developed the solution makes them owners of that solution. In practice those engineers, should something go wrong, will feel inclined to go off and fix the problem that they introduced. Alternatively if they were simply told to implement a solution that was given to them should it fail those same engineers may resent being called on a weekend to fix a problem (in large part because someone else created the problem for them).

This isn’t just true of small change. I posit that this strategy works at an individual team level up through the most senior ranks. When I attempt to influence change across an entire company my tact is focused on personally understanding a problem well enough that I could whiteboard it and walk away with at least more than 50% of the room agreeing that they too understand the problem. At this point I look for a team where that problem is causing them enough pain such that they are incentivized to help me solve the problem. With this team we might form a hypothesis (how we would like to solve the problem) and put the solution it into practice and measure the results (a fun way to set this all up is to think of the scientific method). In the end we can document the outcome. Assuming there is success we now have a clean problem statement and a correlation with a solution that can be leveraged. At this point we can work our way across other teams. Because the problem has a solution the incentives for the next team don’t have to be quite as high as the cost of implementation is now lower. Take this process, rinse, and repeat.

The takeaway for today: to really get the wheels turning understand the problem and WHY it is worth solving. Never start from HOW you would like to implement something.