Category Archives: Soft Skills in Software

This series of posts comes from discussion points I had developed for a panel discussion I was invited to for CodeMash v2.0.0.8.

Keep a long-term perspective; know your “sales cycle”

(This is part two in a series I have titled “Soft Skills in Software”, which came out of points I came up with for a panel discussion at CodeMash 2008.)

When introducing change in a technology practice, you can save yourself some frustration by being aware of the “sales cycle” for new ideas within your group and maintaining a perspective that always bears the long-term in mind.

As technologists, we often have great enthusiasm for new ideas that we perceive to hold value in terms of their (potential) positive effects on our work. The value is so apparent to us that we often see no reason not to put this new idea to work right away. However, the speed with which a new idea can be adopted is affected by a number of factors. Let’s start with these:

  • The organization’s general disposition toward change
  • The change agent’s standing as a thought leader within the technology practice
  • The resultant impact of adopting the idea in question
  • The temporal context in which the new idea is introduced

Depending up on the value of each of those variables (and more), the length of time it takes for a change to be adopted can be anywhere from a few weeks to months to years — or a special category I have, “not for the foreseeable future”. I use that category instead of “never”, because there have been times when I thought there was no way a given thing would ever happen, and suddenly a merger or regime change or some other major external change suddenly opened the door for the previously-infeasible.

I use the term “sales cycle” because it was in a previous career of mine where I first learned this lesson. I used to sell industrial packaging and marking systems, and when I first started, I was greatly frustrated at the seemingly low number of sales that I would close. I would follow up with some clients to the point of irritating them, convinced that “something should have happened by now”. I eventually learned that the different types of systems that I sold had different sales cycles. Because of a given system’s cost and the role it played in the manufacturing process at large, there was a minimum amount of time it took to get approval, move through a cusotmer’s procurement process, and finally issue me a purchase order. Some systems took 4-6 weeks to sell, while others were 6, 12, and even 24 months. In general, the longer the sales cycle, the bigger the sale. Once I understood this, I found myself far less frustrated, and there were fewer of those awkward interactions between my customers and I.

Introducing new ideas to your development group is quite similar. There is a direct relationship between the level of change and the time it takes for a team to agree and then adopt the idea. I have witnessed more than a few programmers who had good ideas that they presented and expected everyone to just approve right away. Their frustration with what they perceived as stalling and/or rejection typically resulted in undesireable outcomes. Even the most-valued technical person is only indulged a few temper tantrums before being labeled as “damaged goods”. Recovery from this sort of thing within an organization is discouragingly rare. The person is usually avoided in discussions about strategic direction, and their ideas are usually dismissed or stifled. In general, if letting person Y talk about changes has resulted in discomfort in the past, the typical solution is to just not let that person talk about changes. It’s warped, dysfunctional, and counterproductive, but that’s mainstream corporate culture for you.

One area where technical change differs from sales is the possibility of incremental change. It’s not always possible to sell only a piece of a large system; changes in software development, on the other hand, are well-suited to incremental change. Being able to adjust one’s expectation from demanding a single big win to being content with a series of methodical, steady, small victories is a valuable skill in software. For some big changes, that can be the only way to introduce them. For example, a company may not be open to switching to Agile Software Development overnight, but having daily stand-up meetings and developing in 2-week iterations certainly seems benign enough.

Having said all that, there have been times where something with a 12 or 24-month sales cycle was adopted immediately for me. Urgency, crisis, severe failure with the current situation, any number of things can result in exceptions to the rule. The art is knowing when to spot these factors and acting appropriately to leverage them. If I could sum all that up in a blog post, I’d probably be in a different line of work ;-).

Believe in what you’re selling

(This is part one in a series I have titled “Soft Skills in Software”, which came out of points I came up with for a panel discussion at CodeMash 2008.)

Let’s get right to the point, then we’ll unpack it. If you do not believe in what your company is doing, seriously consider finding work that you can believe in.

This was the first point in a series of observations I wrote down in preparation for a panel discussion on the topic of “talking technology to humans”. (The astute reader will have noticed that this recommendation does not directly relate with how to convey one’s thoughts on technology to others with a less-technical bent. My hope is that those shining stars will read on before posting a comment or sending me flame mail.) I put this recommendation first because introducing change in technology practices is a taxing process. Since introducing change requires so much of your energy, I’d only recommend it if you believe that your organization’s work is worth what you will expend of your emotional energy.

If you don’t think that a lack of belief in your company’s work is affecting you, I’d challenge you to try a few things:

  • Ask your spouse or significant other if they think your mood and attitude toward things in general are affected by your job.
  • Ask your spouse, significant other, or children if they feel like they are walking on egg shells when you get home from work because they don’t want to “set you off”. If they look uncomfortable and say “no”, that means yes, and it’s so bad they aren’t even comfortable admitting the problem to you for fear that you may erupt. I speak from experience here.
  • Pay attention to how you answer the question “and what do you do for work?” the next time your are in a social context where that comes up; is your explanation apologetic or do you use a tone of sarcasm that indirectly lets the person know that you do not identify strongly with your company and/or the services it offers?
  • Pay attention to how you feel on the average day as you commute to work; are there more positive days than negative days?
  • Does reading this blog post incense you for reasons you can’t fully explain, and you already have a litany of reasons who people shouldn’t expect to be able to feel good about what their company does? :-)

Here’s the thing; life is short. Too short to while away most of the hours of years of your life contributing to something you don’t even agree with. Too short to have your family members’ memories of their years with you be colored with how negatively your work affected you. You don’t need the hypertension, and your loved ones don’t need the unjustified bile.

Am I saying that finding work you believe in will eliminate stress and make you some fount of perpetual positive emotional energy? Why, of course not. Work is going to take something out of you, but it is going to take even more out of you if you’re doing it against your conviction, without the benefit of an additional resultant gain.

Oh, and one last thing. There may be some who say, “well my company does sell anything.” Sure they do. Everyone is selling something, a service in exchange for a form of compensation. The consumer may not be the payee, but something’s being provided. Don’t let that semantic keep you from examining whether or not your employer’s work resonates with you.