/Tag: Leadership

The human element to strategy

By |2016-07-15T23:03:43+00:00July 15th, 2016|Enterprise Architecture|

There is no shortage of business thinkers and authors who will tell us this statement is true:

Anyone can create a good strategy.  The most frequent failure is in execution.

Unfortunately, this underestimates the difficulty in creating a “good strategy.”  While the statement above is absolutely true, it is not unusual to find companies that don’t have a formal strategy at all, or who fail to share their divisional strategies with all of their employees (a key measurement of strategy adoption in a company is “how many of your employees can recite your company strategy”).

One of the obstacles I’ve come to recognize in Enterprise Architecture is unique to companies that either don’t have a formal strategy or who do not share their strategy with their staff — you cannot align efforts to strategy if there is no consistent understanding of strategy across divisions.

I always knew this was true.  I’ve become more and more convinced that it is a hard-and-fast rule.  In other words, if you want to be successful as an EA in a company that doesn’t share strategy, this becomes your First Order Problem — how to develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

That’s it in a nutshell.  To be successful, your organization must develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

First order problem — In other words, focus on this.  Make progress on this.  Measure yourself by your progress on this.  Associate yourself with the people who “should” own this, and align yourself with the people who actually do own this (rarely the same person). Find ways to be involved.  Find ways to contribute. Volunteer.  Make things happen.  Find ways to support incremental progress, while recognizing that the increment may not be good enough in the long run.  For EA to become known for “doing successful Enterprise Architecture,” a clear and communicated company strategy is ground zero.

 

Never Waste A Good Crisis

By |2016-08-09T15:12:51+00:00May 16th, 2015|Enterprise Architecture|

The title of this post is a bit of advice I first heard many years ago, while working on an Enterprise Architecture review of a troubled software development effort.  Never waste a good crisis.

Of course, no crisis is good for the person going through it.  Be compassionate.  And I’m not talking about a personal crisis like the death of a loved one.  I’m talking about a crisis in business, like when a company changes strategy leaving customers out in the cold, or when a new technology simply fails to deliver any value, leaving the champion with less buy-in from his business stakeholders.

These are the little crises of business.  It often starts with someone taking a risk that doesn’t produce an hoped-for return.  If that someone is a senior leader, and they are smart, they have already collected their bonus or promotion and moved on, so they won’t get the blow-back from their own failure.  But just as often, the person who took a risk is still around to get hit with “blame and shame.”

Unhealthy as it is in a corporate environment, blame and shame is common.  When something goes wrong, someone takes the fall.

But for an influencer like an Enterprise Architect, a crisis can be a good thing.  Why?  Because we are change agents.  And people won’t change unless they are forced to change.  John Kotter, in his book “Leading Change” suggests that one of the greatest obstacles to change is complacency.  Change just isn’t urgent enough.  He’s completely right, and a crisis is often what is needed to break through complacency. (more…)

The Architecture Manager – the Forgotten Enterprise Architecture Role

By |2014-11-11T16:46:03+00:00November 11th, 2014|Enterprise Architecture|

I’ve met many Architecture Managers over the years.  Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant.  The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise.  Yet precious little is said about them.

In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.

What value does an Architecture Manager provide

As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides.  In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill.  That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect.  Unfortunately, being an excellent EA is poor preparation for this particular role.

An Architecture manager is:

  • An expert at “selling upwards” – Convincing management of the need, role, measures, and successes of the EA function as a whole.
     
  • An expert as “peer selling” – Convincing enterprise peers of the value of requiring their staff to collaborate with an architect, especially when doing so forces a change on the processes they would otherwise use.   (this is one of the most difficult and valuable activities an Architecture Manager can do).
     
  • A visionary for the development of the function – Convincing the team, the management, and internal partners of the vision and desired impact of Enterprise Architecture in the organization, keeping in mind both short term and long term goals.   Without vision, the function cannot grow. 
     
  • A good people and resource manager – Capable of aligning people to roles that can be successfully performed, helping his or her staff to grow to meet their potential, and finding new resources from within and without the enterprise capable of performing an architecture function.   It’s amazing how many architects move up to a manager role and have no idea how to do this well.  This blind spot can kill a team within a year.

 

In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers.  The ones in need of improvement nearly always struggled at one of the above.

What are the responsibilities of an Architecture Manager

Enterprise Architects are rare birds… especially good ones.  There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA.  Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her.  But an Architecture Manager is in a different position.  They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves.  Sometimes, they succeed.

If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team.  Just copy the following list.

The responsibilities of an Architecture Manager include:

  • To set the vision, goals, and measures of success for the Enterprise Architecture function within an enterprise, recognizing the current team maturity, skills of the team members, and readiness of the enterprise to accept the role as desired.
  • To measure the value of the efforts of the Enterprise Architecture function in a neutral manner and present those measures at appropriate times to stakeholders within the enterprise to earn buy in for the function and the funding it requires.
  • To create, refine, and oversee execution of the internal processes of the Enterprise Architecture function, including documenting processes, building support for points of interaction, and ensuring the deliverables match the expectations and timing needed by internal partners and stakeholders.
  • To manage the team members of the Enterprise Architecture function effectively and within the required parameters set by Human Resources.  This includes hiring staff, setting team goals, and conducting performance reviews.
  • To manage the assignment of resources to necessary priorities within the enterprise to meet conflicting strategic needs, and shielding the team members from being pulled out of role.
  • To act as an evangelist for the role of Enterprise Architect within the enterprise, working to build support for the function and its staff members among internal partners.

 

What should an Architecture Manager know

Some of this is pretty obvious, but it’s worth stating anyway.  The architecture manager has to be familiar with enterprise architecture.  But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).

  • Experience with and understanding of the deliverables and value proposition of Enterprise Architecture.
  • Deep understanding of the methods and processes an appropriate EA framework. 
    • For telecom, this would be Frameworx (formerly NGOSS and eTOM).
    • For US federal government, that would be the FEA or DODAF.  (in different countries, there are different governmental frameworks). 
    • For private business, the leading frameworks would be TOGAF in first, with a tiny number of organizations still using Zachman. 
    • A small but growing number of companies use the Pragmatic EA Framework (PEAF). 
    • Most organizations roll their own, often from TOGAF, so starting there is the safest.  Note that a certification in TOGAF or the Zachman Framework is a great start.
  • Strong written and oral communication skills
  • Strong and demonstrable systems thinking and strategic thinking skills.  The ability to capture the key elements of a system into a simple abstraction that empowers good decisions.
  • Solid business financial skills.  Demonstrable ability to perform cost benefit analysis and manage the budget of a team.
  • Strong business negotiation skills, influence, conflict resolution, and political savvy
  • Demonstrable leadership in Portfolio Management, Project Management and Enterprise Change Management
  • Multiple years of Strategic Planning experience, preferably in a governance role

 

What should an Architecture Manager NOT do

In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect.  They may have been a technical architect, solution architect, business architect, or enterprise architect.  In many organizations, these roles are deeply technical.  Of all the architecture managers I’ve met, the overwhelming majority are technologists.

Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above.  It is tempting to continue to be a technologist once moving to this role.  It is also suicide.  Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect.  This means, for the architecture manager himself or
herself: No modeling,  No coding,  No time spent geeking out.  (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills… but nothing deliverable.)

Where should I look to find a good Architecture Manager

First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise.  Be careful of people who performed  but did not succeed as an Architecture Manager.  Most folks fail.  Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members.  Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.

Second option is to bring in an experienced architect and let them take on the role.  Assuming the team already exists and is well accepted within the organization, this is a reasonable approach.  Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option.  The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career.  If the program does not already exist, see the next section.

Third option is a seasoned manager who has no experience as an Enterprise Architect.  This may be a distinguished technical architect, or the leader of a highly visible program in the past.  These folks are expected to bring expert team leadership skills and deep technical skills.  The biggest challenge that they will face is being able to adequately learn the role.  Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first.  The learning curve is very steep.  To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role. 

Building a program around an Architecture Manager

If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager.  This role will be doing a great deal of heavy lifting in that first year.  Setting up processes and deliverables.  Making sure that the stakeholders buy in to collaborating with those processes.  Hiring and situating staff.  Creating priorities and managing resources.  Setting up measurement and demonstrating value.  It’s a tough road to build from scratch while providing value.

The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before.  That is simply too much for a single person to handle.  Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term.  The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective.  Once they move to another role in the enterprise, the function will likely vanish.

You need the Architecture Manager to be effective.  To build a program with lasting value.  To build a program that matures over time. 

So if you are building a new EA program, build it around an experienced Architecture Manager.  Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.

Conclusion

The single most important person in the Enterprise Architecture function is the Architecture Manager.  This critical role is part visionary, part marketer, part people manager, and part evangelist.  They have to change the organization and keep the change from undoing itself.  The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role.  Choose wisely.

We do what you say we will do – Integrity By Architecture

By |2013-07-06T15:12:08+00:00July 6th, 2013|Enterprise Architecture|

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.

How to Become a Hero for Growth

By |2013-04-22T21:59:33+00:00April 22nd, 2013|Enterprise Architecture|

One thing that happens when you work to develop change across an organization: you detect the “cultural” elements of an organization that often go unnoticed by the people involved.  Just as a “Fish discovers water last,” people working in a cultural context can be fairly unaware of the implications of their culturally influenced decisions.  “It’s the way we’ve always done it, here.”

One cultural influence that I’ve seen, quite often, in organizations that are struggling to grow past a particular size, is the “culture of heroes.”  This pattern of behavior has the following smells:

  • Whenever there is a problem with the servers, call Jack.  While it isn’t his current job, he’s the one who installed and designed the server environment, so he’s the logical one to fix it.  (Extend this beyond “the servers.  For every “area” of the system or the business process, there is a “person” who is the “hero” who can solve problems with that area.  There’s often an “uber-hero” above them all, who has to be called in for every emergency no matter what).
     
  • If someone asks me to do my job differently, I refuse until my manager specifically approves the individual change.  After all, my manager has done this job for years and years, and he or she knows best how to do it.
     
  • If I’m a hero or a manager, and I make a casual remark in a meeting that I want to have control over some minor aspect of a process, a subtle but IMMEDIATE shift occurs so that the process now has an extra step: to ask me for my approval of that minor aspect (even if it is something that has little or nothing to do with my actual accountabilities).
     
  • If an important new project is starting, the kickoff meeting cannot proceed unless a couple of heroes are in the room.  Absolutely no way.
     

These are signs of a culture of heroes.

And they are a big problem. 

Let’s first recognize that, for any snapshot of 100 people in the same role, there are two or three that have risen up to become well respected experts.  There are 20 or so that can lead a group, and the rest are following.  One of those “folks in the rest” may mature, of course, and may be ready in the future to lead or become one of those well respected experts.  These are not labels.  But, at any one point in time, the ratios often work out this way.

This is human nature.  Nothing wrong with that.  The problem comes when you feed it.

As a leader, you cannot avoid a variation in skills and experience.  However, the true leader recognizes that there are people who want to grow.  He or she will want to create an intentional culture that not only fosters that growth, but encourages individuals who are the experts to “step aside” a little, and allow the non-experts to have a chance at solving tough problems. 

If your culture keeps coming back to a handful of heroes, no one else in the team can grow.  The people who naturally WANT to grow will leave.  And you are left with an organization of people who don’t want to grow.

If no one in your organization wants to grow, the organization won’t grow.  Plain and simple.

Not only that, your organization won’t evolve.  It won’t improve.  It won’t optimize.  It won’t do ANYTHING interesting or new.  That’s because all the people who could benefit by change, all the people who have fresh ideas and novel approaches and interesting influences, have run away to other organizations where they can try those ideas out. 

And that is what the culture of heroes does… it kills the spark of change in a group of people.

So don’t let the heroes stunt the growth of your organization.  Look around.  If you have heroes who usually get called, ask THEM to be heroes in a different way… heroes for growth.

A hero for growth makes this decision:

  1. I listen when someone brings me a problem.
  2. I consider whether the person who has the problem should be empowered to solve it.
  3. I consider whether the possibility of them “doing it wrong” means that they will cost a great deal of money or some other business loss. 
  4. Then, I take the DEFAULT position of “let the person closest to the decision make it.” 
  5. I only take on a challenge if the people who should be doing it are asking for my help.  (Not their managers, or their peers, or their staff.)  And when I do, I take the attitude that I want to help that person grow… so I challenge them, include them, and inspire them.  When things work, they get credit.  When things fail, I take part of the blame (giving them a safe space to grow).  I don’t override them, belittle them, or ignore them.  I never ever point fingers.

 

If you are a hero in your organization, I challenge you right here to become a hero for growth.  Who knows… you may change your culture just by your leadership, and your example.

Unraveling the Developer Bias in Agile Development Practices

By |2016-09-28T22:44:07+00:00April 16th, 2013|Enterprise Architecture|

There is a contradiction that shows up in many books and articles on agile software development.  .  And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.

Before I begin my rant, I’d like to tell you where it comes from.  I am an Enterprise Architect.  I am also an agilest.  I am a certified Scrummaster (for many years) and have been on many agile projects.  I’ve seen success, and I’ve seen failure.  I know that agile is good, but not good enough to overcome people who are determined to undermine change.  (more…)

Has in-person communication become the unwilling victim of technology?

By |2013-04-08T04:32:57+00:00April 8th, 2013|Enterprise Architecture|

In Enterprise Architecture, one of the most important aspects of the job is not only to communicate, but to lead change.  In other words, it is great to have the data to point to a problem in an enterprise.  It is better to help that enterprise overcome it by changing something (processes, technology, training, staff levels, departmental structures, roles and responsibilities, artifacts, governance mechanisms, etc).  Change requires more than simple communication.  It requires a kind of in-person, face-to-face, listening and hearing and absorbing interaction that is difficult or impossible over written mechanisms like e-mail, word documents, and powerpoint presentations.

Our technology has led us to the point, in modern business, that we consider outsourcing and remote work to be a net benefit for all involved, but each of these “distance” mechanisms introduces the RISK of poor communication.  That risk is magnified when the person on one end of the line is hoping to change something that the person on the other end is doing.  Change is harder across distance, and that difficulty becomes magnified when dealing with the array of different interactions that are needed at the enterprise level.

I wonder if the PC revolution, that brought us personal access to written communication, has created a deep reliance on written communication in corporate processes.  I wonder, further, if that access to technology isn’t directly harming our ability to look a person in the eyes and communicate with them.

As a culture, we have moved from the age of face-to-face all the way to text-messaging-someone-in-the-same-room in the course of a single generation. 

Enterprise Architecture is more difficult because of this shift in communication patterns.  All forms of face-to-face communication are hampered by it.

Modern technology has done more to damage interpersonal communication than any other paradigm shift in human history.

This worries me.

The most important personality trait of an Enterprise Architect

By |2013-01-10T04:52:36+00:00January 10th, 2013|Enterprise Architecture|

The video below, from RSA Animate, is not about Enterprise Architecture.  At least, on the surface, it isn’t.  In the video, we hear the voice of Roman Krznaric, a philosopher, talk about the need to build a greater reliance on the human emotion of empathy in order to create social change.

But as an Enterprise Architect, I am in the business of creating social change.  I’m actually paid to get things to change (how’s THAT for a cool job).  Of course, I’m paid to make the changes within corporations, and the benefit goes to the corporation by making them more effective, efficient, or timely in their desire to “make tangible” their own business strategy.  However, the reasons and rationale aside, my job is all about change.  And people do change, but not easily and not quickly.

There are many reasons that people don’t change.  My father used to say “the hardest thing for a person to do is to think.  The second hardest thing is to change.  So if you want them to think, don’t ask them to change, and if you want them to change, don’t ask them to think.”  Oh, there’s truth in there.  You cannot get people to change simply by “convincing” them to do it.  There has to be more to it, and there is.  But to understand how to motivate change, it helps to start with a little thought experiment.

Think about the times when you changed.  Seriously… stop right now and think about your own changes.  Have you ever changed a core belief?  Have you ever converted to a religion, or away from one?  Have you decided to change your profession or career?  Have you ever decided that the things that you always assumed were now completely untrue?  Think about family members that changed? 

Did you change because someone asked you to think?  Or did you change because someone asked you to feel?  What led the way? 

I am convinced that the only EFFECTIVE way to motivate change is to reach out and touch someone emotionally.  You can bring them along with logic, but if you don’t find their heart, and connect with their feelings, they won’t feel your message.  Notice, I didn’t say that they won’t hear your message.  They can hear just fine… but without connection, they won’t feel your message.  And if they don’t feel your message, they won’t follow your lead.

We have often heard that change is about leadership.  But how does a leader lead?  Is it through logic and elegant words, or is it through emotion and beautiful thoughts?  The most effective way to lead is to use both, but if you have to use one, use the emotional side first.  In Switch, How to change things when change is hard, authors Chip and Dan Heath argue that you have to engage both the logical side and the emotional side to want to change.  However, their metaphor is one of a person riding an elephant.  The logical side is the rider.  The emotional side is the elephant.  Why, in their metaphor, did they choose an elephant?  Because the emotional side is much larger than the logical side, and we can viscerally understand the metaphor on the basis of size and strength alone.  After all, if the elephant wants to turn around, the rider can do little to stop him. 

In Switch, the Heath brothers argue that change is an emotional journey and that there are three parts: the elephant, the rider, and the path.  If the path makes sense to both the elephant and the rider, then you have removed the obstacles to change.  Make it a clear path.  Appeal to the rider to want to take it.  Appeal to the elephant by addressing the fear or uncertainty that may drive them away from it.  That is the job of the EA.  To make a clear path, and to make it so that it starts where the elephant is actually standing at the moment.

So as an Enterprise Architect, how do I find a way to communicate with the Elephant and the Rider in the people that I want to work with?  I use empathy.  I don’t just use empathy… I live it.  Empathy is the single most powerful, most important, and most useful personality trait that an Enterprise Architect can have, bar none.  It is a skill that must be practiced, and learned, and honed.  It is more than listening, but listening is involved.  It is more than feeling, but feeling is involved.  It is connecting at a deep level with the people that you are being asked to work with.  It is building an empathic bond with them.

Philosopher and author Roman Krznaric explains how we can help drive social change by stepping outside ourselves.

Having a strong sense of empathy means that the EA has a strong internal drive to connect with others.  He or she wants to hear their stories, and learn their troubles, and feel their triumphs, because ONLY by connecting with another individual can an EA understand what is motivating that person to change, and what is keeping them from achieving it.  Only by listening to their struggles, and their successes, and their own efforts, can the EA create a path for that “emotional elephant” that Chip and Dan Heath describe.  Because the job of the EA is to create the path.  The job of the leader is to connect with the elephant to bring them down the path. 

Some people motivate others through fear.  Do this or you will lose your job.  Do that or the company will go under (and you will lose your job).  Do this other thing or we will cut your bonus or give you an assignment that you will hate.  Some will motivate through rewards and recognition.  “Look at what Tom did!  He delivered excellent results and we want to honor him.  You can be honored if you do as well as Tom.”  In our capitalist society, that may even be in the form of income: “Your bonus will be larger if you do a better job.”  (Both of these approaches fail, by the way.  True story.  Watch this TED video of Dan Pink’s presentation on motivation). 

In order to motivate change, especially in creative jobs, you have to make it easy for the eleph
ant (the emotional side) and the rider (the logical side) to follow the path from where they are to where they need to be.  Notice that the path doesn’t start from where you think they are, or where a company thinks their employees should be.  It starts from where they actually are.  Without empathy, you may build the perfect “path” but it may start in the wrong place… where the elephant is not actually standing! 

Empathy also helps you to connect with the person who you want to change, and to discover their intrinsic motivators.  As Dan Pink points out in the TED video I linked above, the most important motivators are intrinsic.  They are internal.  They are not the incentives offered by the business.  They are the things that a creative, thinking person already wants:  Autonomy, Mastery, and Purpose. 

  • Autonomy – the desire to direct our own lives, 
  • Mastery – the desire to get better and better at something that matters, and
  • Purpose – the yearning to serve a greater goal.

 

If an EA wants people to change, that EA has to engage that emotional elephant and that logical rider.  To give people the autonomy that they need, and to demonstrate the mastery that they can achieve, and to give them a purpose to follow, in the world of control, incentives, and finance that the business lives in, you have to first listen and connect and understand. That requires empathy.

The Story behind “Stories That Move Mountains”

By |2012-11-04T18:31:33+00:00November 4th, 2012|Enterprise Architecture|

There is a new book available that I’d like to let everyone know about.  It is called “Stories That Move Mountains.”  I wrote this book with two fantastic professionals Martin Sykes and Mark D. West.  In this post, I’m going to talk about how this book came to be, and why I felt so strongly about it that I invested two years of my life in bringing it to market.

First off, if you are interested in buying the book, and we think you will be, you can click on the image of the cover to take you straight to our “buy the book” page on the book’s sister site, StoriesThatMoveMountains.com

book_cover_image_sm

Edward Tufte and Me

My journey into “rich information” began, as it did many others, when I heard about a book called “Visual Explanations” written by Edward Tufte.  It was 1997, and the dot-coms were booming.  I had left Microsoft to stake a claim in the modern gold rush.  I was working as a development manager in a quickly growing web development company in downtown Seattle called Fine.com International. (see note

On my team was a talented young web developer named Brian Poel who told me about a seminar he attended hosted by Tufte.  In the seminar, Tufte taught about creating visual designs that inform, not just impress.  Brian showed me the materials and I ended up reading Tufte’s book myself  (Another bit of evidence to support the old saying: a manager is only as good as the smart people that surround him).

Visual Explanations: Images and Quantities, Evidence and NarrativeAt fine.com, we used the techniques described by Tufte in every way we could.  His guidance led to design ideas that fed into the Nasdaq.com web site, the Marriott hotels web site, and many more.  I learned the power of structuring information in a way that makes it easy to consume, elegant to perceive, and compelling to read. 

It would  be many years before I needed these techniques myself.  That didn’t really start until I became a management consultant.  The year was 2001, and the dot-com that I co-founded after leaving fine, Acadio, had failed along with tens of thousands of other young start-ups.  I had moved to a consulting company called Sierra Systems Group (headquartered out of Vancouver British Columbia) to make ends meet.  For the most part, I focused on technology activities, but I had to ramp up my communication skills.  So I started using some of the rich information techniques that I learned from Tufte in our marketing and sales materials.  I cannot say that I was particularly good at it.

I Can’t Draw… Seriously

I really can’t.  Not even stick figures.  Which is odd, because both of my parents, my eldest brother, and my daughter, are all gifted artists.  Not that I can’t create useful diagrams… I had trained in high school as a draftsman.  Give me a T-square, two triangles, a nice drawing board, and couple of sheets of vellum and I can draw a complete set of floor plans for your house (well… I could in 1980… maybe not so much now).  But freehand, I am hopeless. 

Beyond Bullet Points: Using Microsoft PowerPoint to Create Presentations that Inform, Motivate, and Inspire (Business Skills) (English and English Edition)So when I tried to create a nice visual representation, and failed, I thought it was because of my lack of skill as an artist. I couldn’t have been more wrong.  Regardless, the best I could do, at the time, was to follow the guidance in “Beyond Bullet Points” and create PowerPoint presentations that were compelling using emotive photographs.  They were nice, but they weren’t the things I wanted to create.

 

Meanwhile on the other side of the Atlantic

Turns out, I was part of movement of sorts.  A growing number of people had taken up the challenge of creating interesting visual representations of complex information.  The “infographic” movement had started, and companies were springing up here and there to provide clear, simple, and compelling explanations of complex information.  On the other side of the world, in the UK, an enterprise architect named Martin Sykes had begun his own journey, around the same time as I had.  Big difference: he didn’t give up.

If you ever get a chance to meet Martin, you will enjoy his company immensely, just as I do.  Martin is clever, thoughtful, easy-going, and funny.  He’s a systems-thinker and an excellent speaker.  Martin was also influenced by Tufte, but he continued on to find many other authors and designers who were publishing and writing about this new way of doing things.  Martin started creating his own single page explanations of otherwise complex information, building up his skills and collecting techniques along the way.  And, Martin took the time to learn how to draw.  That didn’t hurt.

I met Martin Sykes through a mutual friend, Gabriel Morgan.  Gabriel had joined the Enterprise Architecture team in Microsoft IT just a few months after I did, but he came to the practice from his work as a consultant using Microsoft Motion (later renamed Microsoft Services Business Architecture or MSBA).  Gabriel had met Martin a few times, and had seen some of the visualizations that Martin used to explain business architecture.   Gabriel worked with Martin to set up a workshop, for our team, to learn some of these skills.  And in late October of 2007, Martin flew to Redmond and spent a week teaching us how to “tell stories” using a series of visual metaphors.  At the time, he called them “Big Pictures” but that thinking evolved and we now refer to these creations as “visual stories”.

Can we do this again?

imageDuring Martin’s workshop, each of us created a visual representation of some idea or story we wanted to tell.  Martin had distilled his own personal techniques into a FIVE DAY COURSE on creating visual stories.  He walked us through ample examples, storytelling exercises, and a fairly simple process that he used to create visual stories.  I created two visual stories in that class, one of which Martin still uses today… as an example of what NOT to do in a visual story!

The five day class happened once. Over the next few years Martin did four one day classes at different companies where he had been asked specifically to do more following a series of 90-minute presentations he had done at internal and external conferences. But the ideas were not “catching fire”, in large part because Martin was just happy to use what he was learning and focus on his day job of making change happen.

 

Meanwhile, I kept using his materials, and referred often to the binder full of PowerPoint slides that he provided.  I practiced a few times more, and then stumbled into success.  I created a visual story to explain an enterprise architecture roadmap to the Vice President of Operations.  I presented the one page visual, and the meeting went fairly well.  We got the sponsorship we needed.  What I didn’t discover until later: that same Vice President took my one-page presentation and gave it to Steve Ballmer, CEO of Microsoft and one of the most powerful businessmen in the world, to explain how Microsoft’s Operations Division was attacking a key problem within the company.

That single page told a story.  It was not a bunch of data.  It was not a bunch of clever graphics.  There was no hand-drawn art.  It was a careful construction created using Martin’s techniques, and it changed my career.  I was promoted and over time, I was leading a team.  I wanted to bring Martin back to our group to do another one of these fantastic workshops, so that more of us could learn his techniques.  I was willing to teach it myself if I had to.

A book is born

My goal was to put on a workshop for the entire Enterprise Architecture team within Microsoft IT.  I reached out to Martin and asked if he had ever updated those PowerPoint slides.  Thus began a series of meetings that morphed into a book proposal.  We planned to create something visually interesting, to use our own ideas to tell the story of how use these ideas.  Martin reached out to a friend of his, Mark West, a talented artist and designer that had worked with Martin on creating some of his training materials.  Mark was familiar with the process because Mark had lived it.  And he can draw.   (I’m understating rather wildly.  Mark has spent time as an art instructor at a college in Seattle, in addition to running his own design firm.  Mark is a change agent who masquerades as a very cool designer.)

During those early days, we simplified and clarified the process of creating a visual story, and we called it “CAST.”  CAST is an acronym for “Content, Audience, Story, Tell” which are the four stages of the process.  We created a simple “canvas” that anyone can use.  During this past year, Martin has put together a couple of workshops in other parts of the company and has used them to work out the bugs.  We call this canvas  the “CAST model” and I have completely adopted it.  It’s like a simple visual checklist that helps you remember and iterate through the steps to creating a visual story.

We still haven’t done that workshop for Microsoft IT.  We decided to create a book that we could both use to teach anyone we wanted.  We decided to focus on using these skills to simplify the process itself, and to make it easy for folks who, like me, are not artists.  Note: in a professional setting, on projects that are funded to create compelling information, I strongly recommend enlisting the help of a visual designer… but for your own use, to explain your own information, you can follow the CAST process to do the trick.  Just like I did.

The long slog

Anyone who walks the road from idea to a complete book knows that it can be a difficult and time-consuming effort.  We had our moments when each of us thought that this whole thing was nuts.  After all, there were so many good books already on business storytelling and good design principles.  Couldn’t someone just read those books? 

They could, but what I got from Martin, in that workshop in 2007, was not in any of those books.  Martin didn’t change my career with a collection of art tricks and bits from a dozen books.  What Martin gave me, and what we wanted to give our readers, is a simple step-by-step process that a non-designer could follow to create a USEFUL and COMPELLING single-page visualization.  Not high art.  High value.

We knew we had something unique… something that none of the other books and authors and workshops had built.  We had something that the non-artists among us could use to be compelling and useful.  We had a book about change, and making change happen.  We had a book about stories, and using those stories to drive big changes, huge changes… using those stories to MOVE MOUNTAINS.

Most of the text was written between November of 2011 and May of 2012.  Most of the artwork that infuses this book, on every single page, was created in the spring and summer of 2012.  The book is compelling and visually beautiful.  We treated every single pair of pages as a two-page layout, and each was hand constructed by Mark West.  Our publisher, Wiley and Sons, created a new team, with about twice the normal book staff, just to assemble it.  Wiley knew we had something unique, and they were willing to take a real risk on it.  Our team at Wiley did a fantastic job.  I’ve been a co-author before, but never had an experience anything like this one.  The level of communication, collaboration, and shared iterative design was simply unprecedented.  The Wiley team moved a mountain as well. 

image

Sample of a two-page spread used in the book Stories That Move Mountains

What you will get out of this book

In case it’s not clear already, we want this book to be practical and useful.  This is NOT an art book, even though there is one chapter that focuses on detailed visual elements like fonts, colors and layouts.  This is not a typical business book either.  There are no long expositions on financials or sales strategy or performance measurement.  This is a
book about change, and it is for ANYONE that wants to influence another person to lead a change. 

What you will get out of this book is a step-by-step process to follow that results in a visual story.  We walk you through numerous examples, showing how we use the CAST stages to create visual stories and there is a final chapter that literally goes end-to-end in creating another visual story.  We provide advice, and hugely valuable nuggets from a dozen other books that fill out shelves in mine and Martin’s and Mark’s libraries. 

imageOur references chapter is also a simple, clear, layout that focuses on a small and manageable list of excellent books for you to use if you want to “go deep” on any part of the process (you won’t have to, but just in case you want to).  We are also committed to continuing the conversation on the book sister-site http://StoriesThatMoveMountains.com where all three of us blog and upload resources (including a downloadable CAST model template, like the one on the right).  You can also find us on Facebook for a more socially-oriented conversation (www.facebook.com/storiesthatmovemountains) as well.

It should come as no surprise that both Martin and I are Enterprise Architects.  The biggest value we offer our clients is helping them to build the case for change.  But change can be anything.  You could be changing a business, or a team, or a family, or even yourself.  You can create a visual story for nearly any situation where you want people to remember, and connect, with your case for change.

Yep, it still works

I’ll give you an interesting example.  I am currently volunteering my time to a professional organization called the “Center for the Advancement of the Enterprise Architecture Profession” (or CAEAP, pronounced “seep”).  Through that organization, I have been assigned, by CAEAP, to work with another professional organization that they partner with: the “Federation of Enterprise Architecture Professional Organizations” (or FEAPO, pronounced “FEE-poe”).  I’m working on creating an industry-wide perspective on Enterprise Architecture.  I went to a FEAPO meeting just last weekend where I was working with people, in person, that I’ve only met one time before.  They were all aware of my project, of course, but it was not, and is not, their primary focus.  I couldn’t be sure that they remembered anything from the last time we’d met, in February.  I decided to use a visual story to frame what would have otherwise been a boring status update. 

imageOn the plane flight from Seattle to Fort Lauderdale (five hours in coach, on a red-eye overnight flight), I filled out the CAST model and created the entire presentation.  (I had no internet access on the plane, so the graphic images I used were all on my PC hard drive).  The moment I landed, I drove to FedEx Kinkos, printed the visual story on nice, sturdy, 11×17 paper, and drove straight to the 8:30am meeting.  When it came time to present, I handed out the sheets and we turned away from our screens and spoke to each other instead.

Later that evening, as we sat eating dinner at an upscale Surf-and-Turf restaurant, they were reciting back to me the humorous bits of the story that I told.  The story stuck.  It was memorable.  As a result, everyone has a good idea of what I need from them, and what they need from me, because we had a simple compelling visual story to work from.  (I’ll see if I can get a link to that document made available so that you, gentle reader, can see it.  A thumbnail is on the right).

So yes, I think you should buy this book.  I’d say that even if I didn’t help write it, but I did.  This is our way of saying: it’s time to change the world.  This is our mountain to move.  Join us.  The world needs change agents to be effective.  You are a change agent.  If we help you become just 5% more effective, what hurdles will you overcome?  What innovations will you introduce?  What problems will you solve? 

These are interesting times. 

Podcast on the Enterprise Architecture profession–Interview with CIPS’s Stephen Ibaraki

By |2012-08-26T14:53:46+00:00August 26th, 2012|Enterprise Architecture|

Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society.  I just realized this weekend that I had not announced the availability of the second of those podcasts.  Error corrected.

The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself.  Specifically this podcast reflects upon:

  • The role of Business Architecture in Enterprise Architecture?
  • Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
  • How would you define Enterprise Architecture?
  • The value proposition of the Enterprise Architect?

 

For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site.