Today many companies focus on cost containment, risk management, productivity and outsourcing as their “best practices” approach to their IT¹ software portfolio. These approaches diminish the essence of the software craft – they achieve goals in the short term: cost containment focused on spend reduction instead of value opportunity, “productivity” on a false panacea of measurement metrics, and the ultimate savings through outsourcing – a complete denial that software is a craft deeply steeped in knowledge work and the essence of any modern organization.

Software in IT¹ organizations have been driven to a supposedly commoditized activity which can be managed through outsourcing and cost containment. In many organizations IT is seen as a cost center not a value opportunity. Several colluding factors have brought us to this unfortunate juncture:

In the last thirty years software has evolved from an insignificant cost to a significant one in a company bottom line. The expense varies by organization, but in my observation IT costs (as a subset of total operational business cost) can be between 5 to as much as 20%, depending on how intrinsic technology is to corporate activity. It is difficult for companies to determine value on their IT spend (the dreaded ROI question) but no company seems to be able to compete without IT.

• Software technology is changing rapidly – this makes it difficult to manage investment and determine return on investment. Repeatability exists in methodology but new technologies always provide new opportunities and new learning curves.
• The corollary to rapid technology change – business change is occurring more quickly (BTW, due to technology advancements being adopted by competitors). Since software is a knowledge embodiment of human activity, the software must change respectively.
• Companies treat software as projects not products. Once the software is in production often the software is left to atrophy.
• The corollary to projects versus products – businesses treat teams as temporary organizations assembled for a specific task. Beyond the immediate activity at hand, the value of teams and their interpersonal knowledge is lost by hiring temporary workers and disbanding or assembling groups solely for the length of a specific project.
• Younger people are generally more tech savvy. By my observation, it is not unusual for senior executives to be on the late majority side of technology adoption. In this regard IT has been a disruption to be tolerated, not something to explore and leverage.
• Finally many organizations segregate software developers from business specialists, rather than integrating teams of people. The industrially byzantine approach of functional team throwing their segment of work over the wall to next functional team almost killed the American car industry in the seventies and eighties. Learning the whole business of the business makes any specialist more effective at contributing their constituent piece as a part of the whole.

One might believe that such significant cost and dynamic change in IT would bring forward the most savvy of technology leaders. Rather corporations have frequently moved to czars of cost containment, contract negotiation and subcontract management. This is akin to using pharmaceuticals to manage one’s health, rather than learning that the human body is a complex system which needs care and feeding. What one eats and how one lives has a profound impact on their well being. Why take care of oneself when one can pop a pill? If the IT department is constantly in the doctor’s office or in the emergency room, it likely needs that operation or pharmaceutical prescription. But realize that the IT department in arrears likely got there from years of neglect and focusing on the wrong factors. The medicine and operation staves off the crisis … but never addresses the cause.

The current trend to treat IT as a commodity yields these results:

• People in the software business laughingly spell out CIO as, “Career Is Over.” If the CIO was performing a strategic activity in the company, this would not be the case. Rather they are being asked to cut the IT nose off to spite its face. There are exceptions to this observation – they are typically in extremely tech centric organizations, such as multimedia publishing companies.
• Subsequently many CIO’s are finance majors and MBA’s. Not computer scientists or engineers. And if they are computer scientists or engineers, they typically performed little technical work in the craft before becoming project managers or directors. In other words, our CIO’s are often not steeped deeply in the craft and leverage of software. To wit, if the job of CIO is cost containment, what crafts person would find such a responsibility inspiring?
• Business adaptability is stifled as software is built and treated as a commodity. Pick up the phone and call Pizza Hut – your software will be here in 30 minutes or less (and nothing could be further from the truth). This is not to say that standards, 3rd party packages and platforms stifle adaptability – to the contrary any mature solution, where business leverage by innovation is not feasible in the near term, should be an adopted commodity. Yet treating custom software like one would treat a commodity can have profoundly negative consequences. Plastic plants and live ones need very different care and feeding!
• Corporations reduce their competitive advantage both by lack of IT innovation as well as neglecting the IT organization which helps the business operate more effectively. A more subtle yet intrinsic loss lies in a workforce of often intelligent and creative people whose energy is not harnessed for the advancement of the company. Finance departments have no way of measuring such observations – beware – just because one can not measure does not mean something profound is not in one’s midst.

I was originally an accounting and economics double major. My graduate work was in tech management MBA land. While I have a computer science degree, I don’t despise finance or MBA experience – the disciplines have necessary value in the operational functions of a business. Furthermore to this writer, the inner working of a business are fabulously more interesting and complex than any software system or IT portfolio. So why am I harping on The-Finance-and-MBA-Tech-Leader-Centric-View-Of-IT? Simply businesses are not asking for expertise in software craftsmanship to create positive business leverage; they are asking for someone with finance and management chops to reign in the cost. In many situations we have corporately failed to see the opportunities in technology, relegating the activity to a necessary corporate evil.

Why would we want technology experts in technical leadership positions for corporate America? From my perspective, the difference is not so much that expert software developers are formally schooled in the principles of computing but rather that they spent a dozen years or more of their lives deeply steeped in the craft of writing, maintaining and repairing software systems. That’s a significant amount of time spent thinking and executing against problems and challenges through the lens of how software can be used to help solve those issues or markedly improve them. In the trenches this includes the nature of software and its creation throughout the lifecycle, the ecosystem of a project (and how software teams get work done), the nature of customer and management needs and how they impact a project. I haven’t even broached the depth of technical and technology knowledge one acquires honing their craft skills. Such knowledge of a craft can only be assimilated by having been in the craft for years, not months. Writing software for two years doesn’t make one an expert. Try the Malcom Gladwell Rule – 10,000 hours in an activity more likely defines expertise.

So with the above thoughts in mind, I offer these suggestions:

1. “Technical” means someone has done significant technical work with their bare hands. Not managed it. Would you call a restaurant owner a chef? Owning a kitchen is nothing like being the person in the kitchen making it hum and produce culinary delights.
2. Hire Technology Leadership with software development chops. If the business is going to spend 5 to 20% of its budget on something, would not common sense mandate an expert at the helm to leverage that investment? Why would I ask an Air Force pilot to captain a naval destroyer? Right. Then why don’t we have software experts leading our organizations to best leverage IT?
3. Stop outsourcing. Software is knowledge work – it is an extension of the workforce. How work is done is deeply tied to how software is written. The brains of a company are, in part, embodied in the software that runs the business along with the people that care and feed that software. It may cost more to keep the work in house today, but tomorrow the business will run better and the long term risk of significant software technical debt (which impacts the ability for a company to adapt to the market) will be significantly decreased. Especially if one hires a software leader that is an expert. Experts will in turn hire other experts in their craft. And they might even listen to them! As for managing the cost of insourcing, focus the software portfolio investments to what really matters for the business and use the savings to insource.
4. Realize that software is a craft not a science. To become proficient, people have to steep in a craft. Name a craft where its practitioners are good at it overnight or don’t improve as their experience grows? Creative people in a craft is a good thing. Gilding the lilly is not – a key part of any craft is knowing how to design parsimoniously and see elegance in the simplicity of properly designed solutions.
5. Software isn’t Pizza Hut. The notion that people write a specification and someone else produces a worthy outcome is asinine. Give me $2M and a drawing of your dream house and come back when I’ve built it. Think you’ll be happy? Hardly. Software is no different. It is progressive revelation, both for those constructing and those making use of it. We only realize what we want in a house as we experience it come to life and even more so as we live in it. I suggest you’re on that home site a couple times a week if you want to be happy with the house you’re going to be living in. Software is no different. It is messy and involving to get it right. So what else in life comes easy?
6. … and I leave the most important advice for last … Place technologists deep in the business activity. As software developers better know the business activity, their software products more effectively align to improve the business activity. Many companies create walls between technology and business – often with account managers or product managers, which is not to say that such roles are not without merit. Being a wall or a gate between business and technology is not a merit. Technologists and business specialists working together creates a far more capable set of employees and a far more potent business.