Leadership is a funny thing. You cannot lead someone to where they are not ready to go. You have to lead them to where they are able to go next.
Blanchard calls this “Situational Leadership.” It is up to a leader to be able to evaluate where someone is, figure out the steps to get them to a point of excellence, and then help them to take the first step.
For example, let’s say I want my son to be an accomplished swimmer. I can say “Dive in and give my a lap with a breast stroke and a lap with a backstroke”. I can say it… but if he can’t swim for 10 feet in a row, and his breast stroke is more of a flailing thrash, then my request will not produce the desired result. I will have taught him nothing. He will be frustrated and resentful. Nothing positive will occur.
On the other hand, if I ask him to show me where he’s at, and I explain that the next step is to work on his breast stroke, and we are going to take it slow… then both of us feel a lot better and he makes one more step towards becoming an accomplished swimmer.
Why the analogy? Because the same thing works for teams and departments and organizations.
If you have a team of mainframe CICS developers, good ones, throwing them into a SOA implementation may be a stretch. Or maybe not. CICS is really a message-based mechanism, and if that team is used to developing their systems from a message-oriented approach, then you are simply teaching technology, not entirely new concepts.
You have to ask them to show you where they are at. You have to evaluate, ask questions, find out what they do well. You have to perform that ‘skills gap analysis’ before you can begin to take a person, a team, an organization down the road. And then, you can’t ask for the full lap with the breaststroke if that is not what the are able to do.
Lead from the place where your follower is standing. You cannot successfully lead from anywhere else.
This is not a technology problem. This is a human problem. But in Enterprise Architecture, it is tempting to assume that every technology can be considered, because, of course, “it’s just software and we know software.” That’s bizarre. It’s like saying “everyone can do anything.” To make it worse, if we ask the developers, they will say that bizarre assumption is true, even when it is not. That really throws the notion of personal accountability out the window, but it is typical of software people.
Let’s say you need to create a roadmap. The domain is something small… let’s say property management. (“Small” in that, for most enterprises, there are not a laundry list of integration points). Let’s say you, as the architect, have led a process to pick a good commercial package. You find a nice application. (We will call it “Propman”). It has the features your business wants. It has a secure, reliable, scalable architecture. It even has web services. That’s good because your financial system also has a web service interface. No one uses it yet, but Xavier, one of your team members, keeps telling you that he’s dying to try “doing SOA work.”
Do you propose a roadmap that shows data integration from the “Propman” app to the financial system using web services?
Maybe. As long as you have evaluated Xavier and you are absolutely certain that he is up to the challenge. Odds are, he’s not. It is more likely that he’s read about SOA in a magazine and he’s eager to try… or he wants to improve his resume and bolt for the door. Your roadmap is incomplete because the technology is possible, but the people are not ready.
Architectural roadmaps have to take things into account that extend far beyond technology. They have to take into account things like corporate culture, technical readiness, local availability of talent, financial implications, deadline implications, strategic directions, company policies and, yes, company politics. These things will affect your choices. They must. You have to lead the organization from where it’s at, not where you wish it was at.
A close advisor told me the other day, “be aware of your radar… keep it turned on.” Look for all angles that may influence the potential success of your domain roadmap.
If you look only at the technology, you may miss the fact that the team is not ready to use it.
And that is one way (of many) that projects end up under water.