Agility. Cloud. Mobile. BYOD. Agile. DevOps.
Empty buzzwords. When it comes to communicating how technology can enable business innovation, it’s difficult to create a talk-track that brings it home. It’s hard to have a conversation that takes it from buzzword to meaningful & actionable plan in anything shorter than a thesis. Personally, I make these connections, I communicate value, though metaphor or culturally relevant observations.
This post is the latter. It’s also a way to frame how critical software is to business/policy innovation and why we’re so far away from capturing software innovation en-masse.
Men Are From Mars, Women Are From Venus
In our case, it’s more like business people are from Earth, and technology people are from Orion. As I thought through the importance of capturing innovation it became clear to me that the problem is not about technology, at least not at the highest level of thinking. The problem is how people making decisions communicate (with each other).
Businesses that are agile & willing to embrace cloud infrastructure will have an advantage over ones that don’t.
We’re all aware of the top technical trends and the top financial trends1 . The trick is, how do we interpret these trends in context? How do we make the technical trends comprehensible to the business people? How do we make business trends relevant to the technical staff or software developers? How do we do this in a way that helps everyone do a better job?
My favorite example is the observation by most non-technical people — why does it take IT so long to deliver something, when apps on my phone get updated so much faster?
One of my favorite quotes on this comes from a bug AT&T has with it’s voicemail on the iPhone:
iOS 7 came out almost four months ago. Four. Months. Complaints have been constant since then. What possible excuse could they have for not pushing out an update already?
It’s not about explaining what mobile is. It’s not about explaining what cloud is. It’s about explaining what matters to the person.
Why does it take so long to deliver, and more importantly, what can we do about it?
The crafts of software development and enterprise technology (2 distinct disciplines) are critical crafts to success. But I don’t believe that as a whole we realize just how critical they are (and what we need to do about it to enable more rapid software innovation while protecting the enterprise).
An Apologetic President
I’m a subscriber to Mark Andreesson’s view that “software is eating the world.”
We are at the point where innovation (or public policy) is so intertwined with technology that the two can’t be separated. You simply cannot innovate without technology. You can’t implement policy, no matter how noble, without technology. Don’t believe me?
What do you see in the photo above?
I see the President of the United States, arguably the most powerful person in the free world, apologizing for a failed website.
Sure, chuckle all you want (that’s what happens when I present this slide). Then, stop & think.
The President of the United States “failed” at his initial implementation of universal healthcare because he couldn’t launch a website.
Policy (or innovation) and the technology required to implement the policy (or innovate) are the same. Fail at the technology, fail at the policy.
Fail at the technology, fail at the innovation.
The Gulf Between Business & Technology People
I don’t care about the politics of it. I don’t care about blame. I don’t think universal healthcare is doomed because the website failed. It’s not about that. It’s not about the obviously poor project management. It’s not about the lack of time testing the site. It’s not about unrealistic expectations, poorly trained workers, or complexities around privacy or partisanship.
All those things are symptoms. In fact, they could even be addressed on a project-by-project basis to create an organization that was more successful. Though I’d argue that addressing these things one-by-one doesn’t scale, and isn’t the point.
Here’s a quote from the press. I don’t believe this quote was anything other than sensationalism and President-bashing. However, put that aside and ask yourself how unrealistic is a question like this for a project less emotional:
Why can’t they just take everything from Maine, change ‘Maine to Oregon’ and save $225M?
For my non-American readers a little explanation is necessary. The US healthcare “thing” is a balance between federal (the United States as a country) & individual state implementations. Each state must implement a healthcare exchange, where citizens can shop-for and purchase insurance. States can build their own exchanges, or they can use a federal exchange. The decision to build their own or outsource to the federal government is a policy/funding decision beyond the scope of this post.
Maine implemented a successful exchange on-time. In Oregon, they spent $225M and weren’t able to accept a single on-line healthcare sign up.
People don’t understand why this technology stuff is so hard/complicated. And, importantly, no one is explaining it to them in a way that doesn’t look like an excuse2.
Well Executed Software Innovation Requires Better Teamwork
I was in business school a long time ago, but even then was shocked at the lack of technical knowledge in my non-technical classmates. These are the people who confuse memory & storage, or who would stick the phone cable into the ethernet port and wonder why they couldn’t connect to the network.
If someones level of technical understanding is of the level of “why can’t we just change ‘Maine’ to ‘Oregon’ and be done?” how do you think their decision making will be when assessing top banking concerns, when those concerns are addressed with technology?
How will business people assess operational risk?
How will business people understand the best ways to become compliant with appropriate regulations?
How will business people make decisions around pursuing business innovation, when that pursuit is accomplished (in-part) through software innovation?
All these questions have the same answer: Poorly.
The Definition of Insanity
Is to keep doing the same thing, expecting a different result.
Well, why do we keep delivering IT projects the same way… getting the same result, and then going back and trying to improve the skill set and project governance. We need to do more; we need to change the method with which IT delivers.
It reminds me of American tourists in non-English speaking countries. When a local tells them they don’t speak English what does the American do? He talks louder and slower. What does IT do when a project gets off-track? They talk in even more technical detail with people who don’t speak the language.
There’s a huge disconnect, and it’s beyond some training to bridge the gap between disciplines. There is a fundamental structural flaw in how IT delivers innovation. With all the talk of breaking down IT silos, we still deliver technology as if we were back in the mainframe era. There’s a process for creating/testing/deploying software, and each new project goes to the top of the funnel and works its way through to deployment. Every new idea that business has, becomes another piece of work for IT, executed through the approved process. Need I remind you that no one looks back on the mainframe era and says remember how quickly we delivered software innovation back then?
The increasing complexity, the increasing pace of change is accelerating the break between business & technology. It’s reinforcing the need to change how we communicate about technology, which interestingly has a technical solution. Along the way, we’ll see how with the right technology platform we can change the “us vs them” relationship between IT & “the business” into a successful peer relationship that enables companies to capture software innovation quickly and effectively.
If you enjoyed this post, you should also read “Getting to Yes” — they’re part of the same series of posts in which I develop the business case, strategy, and implementation for my software innovation platform.
Funny enough there’s this article in the LA Times today about how little American’s understand about technical terminology. There aren’t enough details to gain insight into the research’s sample population, but the results don’t surprise me.
- Mobile, cloud, social, big data; Capital & efficiency ratios, data security, regulatory governance & compliance, multi-channel/omni-channel, and ‘what the heck do I do with my branches’ [↩]
- Thinking point: how do you respond, emotionally, to someone who seemingly keeps giving you excuse after excuse? [↩]