As technical professionals, developers are often accused of ignoring human issues and focusing too much on the technical aspects of a solution. Hugh MacLeod said it best:
Habits, values, and attitudes, even dysfunctional ones, are part of one's identity. To change the way people see and do things is to challenge how they define themselves.
Being a Big Swinging Developer is all about changing the way that people see and do things and that second sentence up there explains a lot of the resistance you'll face. It's not enough to show people what they can do, you need to show them who they can be. For example, I know lots of programmers who love agile development techniques and have trouble getting others to follow suit. This can lead to a lot of frustration as the Agiles think that the Non-Agiles "just don't get it." I don't think that that's the case. I think the folks who resist agile techniques do so because they don't want to be agile developers. Really, it may be as simple as that. Not everyone wants to code quickly and safely, or be able to change their mind, or do the things that agile techniques enable. If you look at it that way then you start to realize that someone who codes slowly and (at least in their mind) carefully will view writing unit tests as extra work that lowers their productivity. They may see putting prototypes in front of users before all the requirements are known as opening themselves up for (gasp) more work down the road.
If the view of people defining their identity by their habits, values, and attitudes is correct then the happier they are with their identity, the harder it will be to change how they see and do things. This may explain why the multi-decade veterans stick to their ways while the freshly minted grad will try out whatever you throw at him. It's not that the new guy understands better, it's that his identity isn't as firmly cemented which means changing what he does results in less of a change of who he thinks he is.
The next time you have an idea for process or organizational change, make sure that it either fits with who the organization is or who they want to be. If it's going to be a significant departure then spend extra time painting the picture of who they can be if your change is adopted. If you can't sell the idea of the new identity, chances are you won't be able to sell the technical aspects of the change. If, however, you can make people want to be who your change enables them to be then you'll find yourself surrounded by support instead of resistance.
One of the most important skills for a Big Swinging Developer to learn is how to focus. This is more than a matter of shutting the world out while slinging code. If it were that simple, then anyone with headphones could be a BSD.
To us, "focus" means pursuing the goal of shipping great software in addition to addressing all the other "distractions" that may pop up. Someone asking for help may seem like a focus-breaking request, but if helping that person makes the system better then it’s in keeping with the goal. Researching a new technology may be a huge breakthrough, or a huge waste of time.
I found myself in this position earlier today. I signed up to look at a new way of doing something in our system. After 30 minutes it became clear that the change (pretty much regardless of what it was) was going to be more time and effort than we could afford. This wasn’t the answer I wanted — I wanted a breakthrough. The problem was that even a breakthrough wouldn’t be worth implementing. This put me into a serious funk, but the alternative was to spin my wheels looking for (and probably finding) options that all had one thing in common: they wouldn’t be implemented and, therefore, they wouldn’t make the system any better.
It’s hard to stop short of solving a problem. It’s often easier to search and search and search until you’re told to stop, because then you can feel like the reason you didn’t solve the problem is because someone told you to stop. It’s easy to blame your predecessors, your vendors, or even your colleagues for getting the system into a state that you can’t "fix" within the given amount of time. But none of these makes the system better, so it’s your job to focus relentlessly by doing the right thing and getting back to the problems that have solutions.
In the last post I revealed that the key to becoming a Big Swinging Developer was to realize that you’re now in the sales business (don’t worry, it’s a part time gig, you still get to code) and covered the importance of The Ask. Another aspect that’s covered in sales training is Overcoming Objections. In the world of the Big Swinging Developer, there are 3 main objections to overcome:
It’s too expensive
It’s too much work
It’s too risky
There are likely to be other objections that are specific to your situation that are often given the blanket label of "Office Politics". We’re going to ignore those for the time being — like a Physics teacher ignoring mass and friction to teach a more general concept.
The objections above are listed in the order in which you’ll need to overcome them. In a business setting, if something is too expensive, it’s simply not going to be approved. If something is too much work, that has a loose correlation to being too expensive because the person responsible for approving the work will do a rough calculation in the wages required and throw back the opportunity cost objection. Risk is the most nebulous objection on the list because it can mean anything from risk of losing money (see also "too expensive") to risk of looking foolish.
As with most posts in the Big Swinging Developer series, there is a key to the solution:
Whenever possible, take on the burden yourself
"It’s too risky" doesn’t hold water once you have a working solution or, in some cases, a prototype. "It’s too much work" isn’t a barrier once the work is done. That only leaves "It’s too expensive". This is where our final sales lesson comes in:
Sell money
Do you need a software component? Don’t ask for it because it’s really cool and easy to use. As for it because it will save 20 hours of development work and costs less than 20 hours at the average developer rate. This is a reversal of the previously mentioned opportunity cost argument. A faster build machine (or, even better, a farm) won’t necessarily be purchased to make your life easier. There’s a much better chance of getting the funding if you can show the benefit in monetary terms. Of course, before you ask you should drive the chances up even higher by using a trial version of the component or setting up a prototype of the build system on your own. By taking on the burden, you’ll remove the risk and the fear of it being too much work and it will put you in a great position to sell it as money.
It’s free, it’s almost no work, and you can cancel anytime: Use the link on the left to subscribe so you don’t miss a single post!
