Experiences throughout my career have brought me into close contact with IT organizations that have all the raw materials to build and ship complex custom applications. They have immediate access to people who know how to write code, means to solve problems not well-served by any of the common application patterns already in the market, business justification and available funding to succeed in software development management.
So they try, and they fail — either in a spectacular collapse before delivering a solution, or through a much more insidious slow death through atrophy until the project simply can’t be supported anymore and is just abandoned.
Why does this happen?
How Culture Impacts Software Development Management
What is different between how these IT organizations approach custom application development compared to the mentality with which a software product company approaches software product development?
And, why do IT organizations find it so hard to copy the successful software companies? They try paying for the talent, copying the practices, adding foosball tables, beanbags and video games. Yet still, they create a shadow of a software culture. Why?
I think the first clue into delivery challenges is the name itself: IT. “Information Technology” suggests an organization that provides the software technology needed to operate the intended business model. IT doesn’t operate the business — a key distinction — operations does. IT buys or builds the software solutions used by Operations to manage the business, and Operations is constantly looking for ways to more efficiently deliver the company’s established value proposition.
Operations delivers the products that generate the revenue for the company, while IT is a cost center funded by Operations. Unfortunately, this codependent relationship is often strained by a track record of mixed results or failed projects in which applications were purchased or built, taking longer and at a higher expense than expected. Or maybe, they simply failed, period.
When and how did IT organizations start to think that they could build products and successfully complete software development management? I blame the Internet. And, more importantly, the bane of the Internet — the corporate website.
As marketing sites grew into basic electronic commerce portals to support other brick and mortar operations, the size, influence and technical skill of these IT organizations blossomed. With the skills and increased confidence came the belief that this was the same as making software-based products for a market. But then, they usually discovered that simply translating this knowledge to software product development was not enough. Why not?
Software product companies evolved from a different place, and as such, they have different fundamental DNA. First and foremost, they exist to make money by building software. They know this to their core, and they formulate their business strategies believing that building great software is the key to their customer’s experience. They have “Product Strategy” and “Product Development” organizations that exist solely to make sure this happens. They engineer their goods and services to be accessed and augmented by software. And most importantly, they understand that their software needs to change continuously as long as they are in business.
Software Development Management: What Is the Universal Truth Successful Companies Know?
Software is a living thing. It grows taller over time. It gets fatter and thinner. It morphs in appearance and function as you alter your business strategy to meet changing customer needs, and it languishes and dies if you fail to feed it. This happens because software is the one creative medium that most reflects the long-term health, quality of thinking and veracity of the team that owns it.
How to Transition a Business into a “Software Company”
Let’s say you work for a company beginning to realize it not only wants to build software products but, more importantly, knows that it wants to shift toward managing software development as a distinct software company. Is there hope, or are you stuck on the other side of the glass trying to see in through the fog?
Right person, right seat. It’s hard, but it is possible. The road forward starts by tackling the problem both top-down and bottom-up. You have to bring in software DNA into positions of authority and give them the funding and autonomy to begin to build products and services that do not depend solely on augmenting the value proposition of your traditional business.
Customize metrics. You have to measure success differently. Your traditional financial metrics are not going to apply, especially if you come from a hard goods business, and you have to shift your funding mentality from a project-based ROI to continuous investment based on an assumed future revenue stream.
Find committed advocates. You must also find partners who can help you make the transition from supporting business function through software to managing software development. These partners should understand the transformation you are trying to make and commit to helping you build the organization you need long term. In many cases, they will first graft their DNA on to your own until you are self-sufficient. Ideally, they will also understand that you need to do this in a cost-efficient way, and that you have limited time and extraordinary investment in order to show results.
Identify a mentor. Lastly, it helps to have someone who can show you whether you can reach the objective through the organic evolution of the technology you already have or if a green field effort is more appropriate. MentorMate is such a company.
Software Development Management: Particle or Wave?
How IT serves the business can be likened to the “particle” theory of software development. Each project builds on the efficiency/capabilities offered in service of the company’s established value proposition.
It’s fine to think of software as a “particle” if all you want to do is to consume/build it to make your current business more efficient. But, if you actually want to make money by building software, then you must consider the culture and business adjustments that come with it to truly ride the “wave”.
Original post can be found here.