Building Culture Change In An Organization New To Enterprise Architecture

If your organization is embracing Enterprise Architecture, what are some of the cultural considerations and next steps you have to think about?

Culture changes don’t happen overnight, so let’s talk about the path toward positive behavioral changes as new governance processes are getting institutionalized.


First, How Are You Positioning The Change?

In any environment where there’s a struggle to get adoption of technology across the board, we find ourselves asking the IT leadership, “How are you selling this to your business stakeholders and to your IT teams?”

A frequent response? “Well, you know, it’s the hot, new thing. It allows for a faster change rate.”

The hot, new thing doesn’t necessarily instill trust. Especially if you’re asking someone to adopt a technology that they don’t yet understand. Once they understand, it feels real and there’s a better chance for trust to be established.


Enlist Help From Small Teams, Not On A Massive Scale.

So to make a successful transition, we frequently advise building from the ground up in small doses. Find the team, willing to make that journey with you, who shares your vision. Start small and demonstrate the value, both from an IT and business stakeholder perspective. Eventually, if you take prescriptive enough steps and communicate clearly, you’re going to have many teams who are believers.

After enlisting one department or group at a time, how do we make further inroads as far as the culture getting on board with an entirely new enterprise architecture governance structure?


Focus On Where The Visible Impact Is

Culture change happens when people see a reason to change. If they can’t see a reason to change…then why would they?

If there is a fundamental disconnect between the business stakeholders and IT when they’re attempting to make change, the business will often say, “Why do I really need this new thing anyway?” By missing that linkage, you’re stuck. Does the business have a real need and a deficiency? Probably so. Yet until they see the value, they’re going to feel removed.

At Silent IT, not only do we find we need to link stakeholders and IT, but we also have to help companies deliver on the promises that linkage creates. However, forging this link is much bigger than saying, “You folks just need to get closer.” In a larger sense, it’s about focusing on the solutions that will make their business lives better and help them implement it. It’s also crucial that both parties communicate with each other in the same language.

Now, we’ve talked about building trust via small teams, but a natural question becomes, how much of an uphill battle is it to push forward in adopting new processes within a large corporation of tens of thousands of people?

In our view, there are two key phases:

1)  The Project Team Adoption Phase
The big hurdle here is to get one team at a time on board, delivering real, measurable value. When you do, you’ve got a provable success story.

2)  The Company-Wide Adoption Phase
Now that you have that success story or a series of them among project teams, it’s time to start spreading the word and communicating news of these stories by getting in the ears of the company’s senior business and IT leaders.

The key here is to demonstrate how the value achieved among a project team can be measured more broadly. When you hear things like, “I get it and I’m onboard. Just get other teams engaged,” then the effort has the potential to grow like wildfire.


Don’t Stop Customizing And Teaching Too Early!

It’s at this point of buy-in that we can begin to bring in more architects with our same vision and value principles. However, remember that communicating impact among individuals and teams is constantly fundamental to do. You can expect to hear people in the organization sometimes say, “This sounds good, but what do I do with it? Why do I care and what does it look like for me?”

This is actually where a lot of Enterprise Architects can fall just a bit short. They may say, “Well, just do X, Y and Z.” OK, but what if nobody know how to do X, Y and Z? If they’re simply left to their own devices to figure it out, don’t be surprised if nobody gets on board with the changes you’re proposing.

That’s why it’s so important to customize communication and wrap it differently for every part of the organization to essentially say, “Here’s what this means for your goals.” We have to make this real, practical and pragmatic for your people to have lasting change. Otherwise, they might very well resist it.

So when people ask, “What frameworks do you follow,” our answer will often be: “All of them. Because all of them have merit, but we don’t know which applies best to your organization, so let us help you figure out what will bring the most value to you. It may be a part of one framework or a part of multiple frameworks. The key is what has the most value to your organization and that’s where we start.”

See, if you’ve ever put together a puzzle, in the early going, you can’t see the entire picture. Once it’s completed, however, you can back up a bit and say, “Ah! Now I see how those pieces represented something important as part of the bigger picture.”

The two-fold challenge for culture change in an organization new to enterprise architecture is getting your people to understand how it relates to them and their part of the world as well as how it relates to the larger goals and vision of the organization as a whole. You’re asking people with individual applications and challenges to pay for broader success.

It sounds good on paper to say an initiative will take twice as long because it’s for the betterment of the organization, but to the key business stakeholder or IT team member impacted by that timeline, it doesn’t feel very good. No wonder so many people say, “Well, I don’t want to pay for another area’s capabilities,” make poor choices independent of anyone else’s input and build up technical debt.

Consequently, as we move through the journey of culture change amid a new enterprise architecture process rollout, we have to listen hard for what people value most. For some, it might be operations. For others, the question might be help desk-related in terms of how to centralize technology so your company doesn’t need a million people to support a million different apps.

Get them to see how their puzzle piece fits into the whole picture.


You Can Have It All. But Do You Really Want To?

Not long ago, one of the members of our team was having a conversation with a CEO who asked, “Why can’t I have the best of all things in my architecture, including Java and PHP and…”

Our team member explained to the client that she could absolutely have many different things. The problem was, she would have to pay to support all of those things, which would mean her support team costs would be astronomical. There would also be a great cost in inefficiency. Was that type of cost of time and money worth it?

Think about looking through this lens when making decisions on your IT.

When approaching IT teams, we supply them with some of the best advice we’ve ever received ourselves, which is, “How do you make it not your problem?” In other words, how does IT put other business stakeholders in the driver’s seat for making choices?

We can better inform people on how to add value by saying, “Here are your options. Yes, you can have it all but having it all costs x, y, and z. Are you prepared to pay x, y, and z?”

This level of clarity and transparency has never steered us wrong at Silent IT – and it couldn’t be more important in an environment facing the complexities of culture change.