The overriding theme of every disruption story I’ve ever heard is that firms thought they had more time than they did. So, I’ve been pondering the why. We can see disruption happening all around us, but why is it so difficult to get out in front of it?…
Huawei Technologies started out nearly 30 years ago as a small private company with 14 employees and 140,000 yuan in capital. By 2015, its total revenue exceeded $60 billion. Huawei is already a global company, but its globalization journey has been a …
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.
I thought this might be a useful guide or overview to think over or discuss the blueprinting process. it’s a decent start anyway. From the ASAP 7.0 Methodology Click for […]
Extracted from Re/Code “Big Tech Is Going Down” with my comments in brackets. “The pace and nature of change in the core underlying technologies, product development, selling models and buying […]
I recently had the pleasure of joining a discussion among organizational development professionals. During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geograph…
One of the chief complaints of senior executives in midsize and large companies is that their organizations don’t “execute” on the goals that they set. This concern is so common, it’s the butt of jokes. Entire systems of governance and measurement are created specifically to provide assurance to senior execs so that they can maintain some level of public integrity. Yet, when Enterprise Architects describe their roles to their peers, it is surprisingly rare to hear them talk about this issue. That is a mistake. Let’s talk about how to tell the story of Enterprise Architecture as the maintainer of executive integrity.
In 2003, when Motorola sent their CEO Chris Galvin packing, USA Today wrote about what a “good guy” he was:
He turned out to be a lackluster CEO, which, sadly, often seems to be the case when good guys land in the corner office. Friday, Motorola said Galvin would resign. Motorola under Galvin had suffered through six years of disappointing results, laid off one-third of its workforce, failed hugely on new ventures like Iridium, and waited for turnarounds that never happened. The board apparently had had enough; Galvin thought he’d better leave.
I have to say I feel bad for Galvin. Of course, I wasn’t a Motorola shareholder who watched the stock go from $60 (split-adjusted) in 2000 to about $11 last week. Nor am I a laid-off Motorola employee. And yes, Galvin was paid handsomely: $2.8 million in salary and bonus last year.
Did Galvin fail, or did Motorola fail to execute on Galvin’s strategy? The board of Motorola, and the board of any company, won’t see a difference. Note that this story has happened over and over in high-tech, from Steve Ballmer to Michael Dell, usually without the board firing their CEO. Far from being limited to high-tech, stories abound of retailers (Best Buy), manufacturers (General Motors), and financial services companies (too many to name) that have suffered through strategies that failed to pay off.
Here’s what stockholders see: you said “X” would happen and it didn’t. You lied.
From their perspective, the CEO loses credibility for lack of integrity.
Integrity is a personality trait and a virtue. A person has integrity when they can be trusted to perform exactly as they said that they would perform. In other words, they “do what they said they would do.” This person makes a commitment and keeps it. This means that they make commitments that they are fairly sure that they CAN keep, and they don’t forget the commitments that they made. In every high-performing team that I’ve been a part of, each member had a high level of integrity. Integrity is key to developing trust. If you do what you say you will do, people will trust you.
Executives need to develop trust just as much as individual contributors do. For private for-profit organizations, those stakeholders own stock, and purchase the goods and services of the company. For public organizations, those stakeholders are voters and legislators. Where an individual contributor must earn the trust of his manager and his or her peers, an executive is in a very visible position. They have to build trust daily.
Building that trust requires that they make bold pronouncements about the things that the organization will do under their leadership… and then their organization has to perform those activities. And that’s a key difference. When an individual contributor says “I will do this,” they are talking about their own performance. Rarely are individual contributors held accountable for failures of the people that they cannot control. Executives, on the other hand, are not talking about their personal performance. They are talking about the performance of the many (often hundreds, sometimes thousands) of people under them.
An executive doesn’t actually “control” the people under him. He or she must lead them. Sure, there can be an occasional “public hanging” (as Jack Welsh used to encourage), but, for the most part, the executive’s ability to speak with integrity comes from the trust he has in his organization to perform. In other words, how will with “they” correctly do what “I” said they would do?
Enterprise Architecture is a keeper of executive integrity
Enterprise Architecture is the only profession (that I know of) that is focused on making sure that the strategy announced by an executive actually comes to pass. Enterprise Architects exist to make sure that the needed programs are created, and executed well, keeping in mind the end goals all along the way. EA’s go where angels fear to tread: to execute strategies and produce the desired results if they can be produced.
If you value executive integrity, EA is an investment worth making.
Dear EA bloggers, Thanks to you, EA Voices is a great source of enterprise architecture wisdom. Now aggregating blogs and writings by over 100 bloggers, the database is rounding 2 million words, and grows with around 100 posts monthly. I think all this wisdom deserves even more attention than the website and apps can offer, and … Read more
One of my startup heroes Steve Blank wrote in a blog post that “value proposition is the fancy name for your product or service” It is with some trepidation that […]
When planning and measuring business benefits there are three basic contributing elements: revenues, costs and intangibles. If you look for guidance on “types of cost” most sources decompose cost types […]
An article by Tom Graves defining the scope of “business” every organisation is also ‘a business’ the business of an organisation is whatever the organisation does, for whatever business-reasons and […]
Last week I presented about a topic that focuses on improving enterprise architecture effectiveness through our soft skills. There is a great deal to cover in this area but I wanted to build a primer and get some your thoughts…