What business managers need to know
We’ve developed a lot of applications for all types of companies. One thing that has become crystal clear to me is that success depends more on the human aspects than the technical concerns. Technology, while it can be frustrating and is almost always less-than-promised, is somewhat predictable. There is always a reason that something doesn’t work; you just have to find it.
I suppose the same can be said of human beings, but when there is a hidden agenda, the problem is much more difficult to find. There are two distinct areas of development where the human agendas come into play. Each area must be managed properly, or the effort will fail.
You might be thinking, “I don’t develop applications. What could this have to do with me?” But all of us in business are now dependent on software for the success of our companies. If you can’t understand and manage the software development process, you can’t manage your company successfully.
This is true even (and especially) in The Cloud Era, where everything is supposed to be plug-and-integrate. There are still many decisions to be made. And, truth be told, there is usually still code involved.
Let’s look at two of the areas where a development effort will go off the rails, and what you can do about it.
The pride and fear of managers and users
Cloud-savvy companies are eating the lunch of cloud-lagging companies. Why? Because the cloud-savvy companies never build if they can buy. Sounds simple on the face of it, but there is a huge human stumbling block hidden in this simple premise.
The people who are used to doing things a certain way are proud of their proficiency. The old saying, “Pride goeth before the fall,” comes into play here. They are proud of what they’ve created and what they are able to do with the processes, and the technology they’re using – even if that technology is a spreadsheet. If you build, assuming the project ever gets finished, you can get pretty close to that spreadsheet. But if you buy, the new system won’t look or feel like that spreadsheet. It will introduce a new element into the mix: fear.
Next to pride, fear is enemy #2 in the development process. People will do all sorts of sneaky, underhanded, seemingly innocent and well-intentioned things because they are afraid. Afraid of losing their job, their power and prestige, their ability to influence those around them, and their corporate standing. Mostly they are just afraid of looking stupid. They don’t want to go from “I know how to do this” to “How does this work again?”
How do you manage this?
First, you explain to everyone that change is necessary and inevitable. That the whole team can’t keep doing things the way they’ve always done them. And you’ll need to keep reinforcing this as you go along.
Second, start to reward the people who are brave enough to suggest new methods. This is very important. When everyone sees that holding on to the old ways causes managerial displeasure, and that seeking the new ways leads to managerial recognition, they will start to shift.
As the group starts to shift, you will be able to make note of who is holding back. These are the corporate antibodies. Those folks will require some one-on-one attention.
Third, you need to set your own agenda and continue to stress it. For example, if you have proof (which is possible to obtain) that your competition is more agile – getting into new markets faster and disrupting your own market position – you need to keep pointing to that success and communicating that the team needs to find ways to be “more like this.”
It’s important to note that cloud-savvy companies are carrying no burden of legacy pride in what they’ve been doing, because they’re too new. They haven’t been doing anything the “old” way. They are much more open to buying than building, trying/failing and adjusting, and moving to another way of doing things.
Developer agendas
If you have developers on staff, everything that I just said also applies to them. They, too, have created systems that you use to run your business, and they are proud of what they have built. They also have the same fears about getting out of their comfort zone.
But they also feel a strong responsibility to the security and fixability of the company’s systems – something for which they are held personally responsible – and anything that is less in their control will cause concern. If you keep insisting that they leave their comfort zone, watch for the attitude of, “Well, good luck to you, I’m washing my hands of this fiasco.” These people will throw wrenches into the works whenever they can, until they leave – or you let them go.
This situation is much more difficult to manage, because IT guys know more about technology than you do, and can argue their case very convincingly.
How can you separate the truth from the agenda-driven arguments? Frankly, an unbiased business-oriented development expert can be helpful here. Group discussions, with you, your developers, and your expert can help you sort through the real issues and make realistic, solid business and technical decisions.
Again, call out hesitation and encourage new behaviors. Find ways to help them see how they can contribute to the new effort. It’s much better to keep someone who can come over to the new way of thinking than it is to have to find a new person. However, be honest with yourself about their ability to come over to the new way of thinking. Your company’s success depends on it.
For more information on selecting and working with developers for your upcoming app project, please download a guide for CEOs about creating great software from Applied Visions today.
hbspt.cta.load(2637494, ‘7be9b60b-533e-4a11-9fb1-d6f541024810’, {});
