How can you incentivize the right behavior so that your enterprise architect (EA) doesn’t become a blocker?

Open transparent discussions using design reviews

This is a very complex topic and without more context it's hard to give solid recommendations but some general issues with EAs tend to be:
- Ivory tower syndrome
- Post technical and out of touch (or worse, vendor driven)
- Disconnected from business outcomes
- Too many of them

Writing objectives, or whatever you use for incentives, to address these points goes a long way to making architects in general enablers rather than blockers.

You're looking for metrics that define a job well done by the architect. Specifically what do you want out of your software development team? I try to push as much as possible to the ICs, so architects, QA, product managers typically work as consultants to the ICs tasked with developing software. Their job is to accelerate the ICs and help them have a complete view of what they're developing.  

So I focus on "evolutionary" architecture -- principles that are built for making rapid evolution of our software possible safely. Therefore the architect's job is to talk through a story or an epic with the principle IC involved in developing it, and then to provide periodic "lightweight" review of decisions and documentation about those decisions.

If you have an architectural review step, set expectations about how long a project sits in that step. Or revisit the idea of having one at all and add architecture into the review and grooming processes. This means you have to increase the autonomy and trust levels you put into your ICs, but if you do that you're generally rewarded with better velocity and better developer engagement and retention.  

Overall the less engaged an architect is with the software developer's daily grind, the more aloof and the more "blocky" an architect gets. The more context they lack, the more they have to deal in abstract principles and the less useful they are to good software development. 

There are a lot of folks building these enterprise architecture fiefdoms who would say that what they're doing is providing value, and that it is a necessity for the organization. But how do you measure that value? And how can you start to understand the purpose of architecture in a way that a layperson, someone outside of IT, can look at it and say, “We can't do this without that. Enterprise architecture is valuable to us.” The challenge is that within IT, we get so wrapped up in the idea that we're providing value even when we might be the ones that are dragging our feet. 

It depends on how you define the role and therefore, how you define the reward. What behavior are you rewarding — what does good look like? And what's bad? Bad enterprise architects (EAs) are rewarded for defining the pattern and pushing everybody to adhere to that pattern. When I look at the EA as a senior solution designer who’s considering the whole, I’m looking at how we are delivering business value as an entire group and their role in designing that key piece of it — how are they contributing to help design that future? How do we move the business forward? If we're not looking at how we move the business forward then IT is failing. We're not doing IT for IT sake.

As a practical example, one of the things we did at a particular organization was moving our ERP to the cloud. We also brought in MuleSoft to provide an enterprise service bus in order to move away from point-to-point integration. Both of those projects were driven by our enterprise architect when it came to how we moved forward and how we would add value to the business. There was direct business value from both of those changes. Moving the ERP to the cloud made a significant impact because the ERP had been holding the business back in terms of their ability to produce and deliver to customers. That’s tangible business value.