Climbing the ladder from EITA to EA
One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem. Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.” The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect. Building those relationships and that credibility takes time… sometimes many years. Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.
I call this “climbing the ladder” from EITA to EA.
While the entire team should work on this, only a few will succeed. Good news: That’s all you need. However, it’s important that everyone makes the attempt to climb the ladder. As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t. I once thought I did, but reality proved me wrong. So everyone makes the attempt. Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.
So, how is this done? How does an individual EITA climb the ladder?
You need four things:
- business knowledge
- empathy (and good reflective communication skills)
- air cover
Business knowledge is the one that should, on the surface, be the easiest of the three to acquire. Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition. What do I mean by business knowledge? I mean the ability to understand the basic concepts of business at a working level. In other words, can you answer these questions coherently:
- Explain the difference between value and cost from the perspective of the provider of a product or service
- For Contoso in Q4 CY2013, they saw sales to new customers increase while market share decreased. Explain.
- Give an example of a disruption in bricks-and-mortar business triggered by mobile computing
- When your company acquires another company for cash, explain how the balance sheet is impacted
- Explain how opening a new channel for your customers can result in a decrease in sales
- Give an example of a good strategy that failed in your industry or market. Why did it happen?
Where do you get business knowledge? There are a gazillion books that will give you the basics. Universities are helpful as well. With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t. I have some friends who insist that an MBA is needed. I disagree with that, but college courses do help. I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University.
Empathy and Communication Skills
There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc. These help with the EITA side of the job. But they don’t do much for the architect who needs to climb the ladder. To successfully make that move, most architects need to invest in training on their soft skills. This means building up the following:
- Listening – Can you elicit the emotional context behind your stakeholders strategies and goals? Can you truly “hear” them? There are courses, and books, and online videos, that can help you to become a more conscious listener. Not only will this help you climb the ladder, it will also help you in your relationships with family and friends.
- Empathy – The art of empathy in business is one where you feel as your stakeholder feels. Don’t confuse with sympathy. Big difference. Empathy is a selfless act, and your ego has to be put into check if you are going to learn empathy. There are many folks in architecture who struggle with ego, ambition, and condescension. I struggle as well. But if you don’t tame this beast, and build your capacity for empathy, your stakeholders will have a difficult time connecting with you. As the old saying goes: They won’t care what you know, unless they know that you care.
- Negotiation – You will be frequently called upon to find a way for two people, with different perspectives, to come to a solution where both people “win”. These “win-win” solutions form the basis for successful endeavors of many kinds, not just in business. But if you don’t know how to negotiate, your usefulness as a bridge-builder is seriously limited.
- Positional Awareness – this means the ability to “see” how the organization works from various perspectives, and to position yourself, and your value proposition as to provide you the ability to influence that system. It also means being aware when other folks are doing the same thing, which has the effect of changing your landscape out from under you. Some folks call this “politics.” I call it necessary.
- Selling – Yep, I said the dreaded “s” word. Many architects view “sales” as a dirty word. After all, Sales people use emotions, leverage relationships, and often don’t even understand the details of what they are selling. The sale is more important than the actual people! Ouch. It’s true. Sales professionals are often competitive individuals who have been known to compromise their integrity for the sake of the transaction. But that doesn’t mean that the tools and techniques of sales aren’t useful, or effective, or critical to success. These techniques are mission critical. So take professional training in sales. How to hook a lead. How to build excitement. How to connect to your stakeholders’ underlying motivations. How to use emotion to communicate. How to ask for the sale. How to follow up. The use of color, design, and simplicity to convey a message. All of that.
Did you know that courage can be learned? I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same. I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project. I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself.
I taught myself courage. I taught others courage as well. Part of teaching, and learning to be courageous, is to put your efforts into perspective. See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.
Courage is not the lack of fear or operating outside of dangerous situations. It is the conscious choice to move ahead despite danger. As the Will Smith character in “After Earth” tries to teach his son, “Danger is real. Fear is a choice.” Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear. The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job. These dangers are very real to many EAs.
Courage means that you will need to move ahead anyway. It does not mean you should be reckless in the face of danger. It is OK to be cautious at times. But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.
There is a difference between “being courageous” and “being stupid.” The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations. This support from above is critical to your success. I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery).
In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted. They believe that you are valuable and that your motivations are in the right place. So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos.
I cannot indicate the importance of air cover. For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace. And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous. You’re being stupid, reckless, or chaotic (take your pick). To climb the ladder, someone has to be holding the ladder. That’s your air cover.
Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA). It takes dedication, support, and some significant innate abilities. However, for many who take on this challenge, the rewards are excellent. I truly love Enterprise Strategy Architecture. I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day.
Caveat: certification and frameworks
You’ll notice that I never mentioned Certifications or Frameworks in the discussion above. That’s because I’ve met and known hundreds of Enterprise Architects. Certification was only useful to make them more effective as an EITA. It made no difference for climbing the ladder. Certification will help with some skills and a great deal of knowledge. A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow. I’m not putting down certifications. I’m just pointing out that this step comes with experience, not certification. At least, not yet.
Technorati Tags: enterprise architecture