Welcome back to another episode of Armchair Architects. Have you ever heard people say that it’s like architects are in the ivory tower?
This may seem a bit controversial, but we’re going to talk about the roles and the relationships of architects themselves to the rest of the organization. People have this notion that architects are sitting up in the stone castle speaking their wisdom down to the peasants. Where did that come from and is this a common stereotype?
It may help to talk about our own failures. In my journey, early in my career, we thought it would be good to gather a whole group of really talented architects, think of them like chefs and put them in the same kitchen and say if we just funnel all of the organization's problems through this Center of Excellence with the center of competency, only high-quality stuff will come out. I thought I would put my stamp on it and be as collaborative as possible.
The challenge became when we had other members of the Center of Excellence saying, hey, don't paint the picture that way, put a mustache on that Mona Lisa, it’ll look a lot better. And I'm like, no, no mustaches on the Mona Lisa. This is how the picture must be painted.
And so you slowly begin to realize that a center of competence or center of excellence is basically like trying to paint a picture where everybody has a brush or there are too many cooks in the kitchen, whatever your favorite analogy is. And eventually the way that the organization evolves is you become removed from the implementation realities, the timelines, the rules of the road associated with actually doing something meaningful with an architecture or software solution.
We have to avoid that. We have to avoid occupying the ivory tower, being principal pontificators, hurling lightning bolts of hey, you're not doing it right, and instead adopt a position of a community servant. I am here to actually help you achieve your goals, not actually criticize and talk to you about how you didn't implement the ambassador principle in the right way.
The balanced architect sees both the trees and the forest.
When architects are not in the real trenches, they don’t understand what the pressures are, what the realities are and you’re telling others to use this technology a certain way without really having a detailed understanding what the implications are. I think the goal for a higher-level architect is to drive the direction of the work and when you are in the trenches, you always look at the tree and you don't really look at the forest anymore. You need this balance between a very detailed understanding but also be able to zoom back out and make sure we are still on the right path.
That's the complexity that we see when we talk to enterprise architects that try to drive a direction of investment of capabilities. The individual teams have to make the daily decisions. And the only way you can really avoid getting into this relational complexity is you have to be part of the conversation. The trick is to still be able to go back and forth – to understand the tree, but make sure that the tree still fits into the forest.
You also need to update the enterprise architecture strategy based upon the learning that you have in the trenches. That feedback loop often doesn't happen and that's why people often think about the ivory tower people. What they say makes sense in principle, but then the reality hits and it doesn't quite make sense anymore. The feedback loop doesn't happen.
If the enterprise architecture doesn't get updated with the real life feedback then it can start drifting apart. And I think that's one of the lessons. You need to give it direction and strategy, but then go deep with the team that has to live with these decisions and learn from their detailed conversation. What is it that you are actually trying to do with this stuff? Does this really work? And that's the key piece: engage, learn, and alter the overall strategy if it makes sense.
We talked about things you shouldn’t do. Are there things you should do?
Architects have to zoom in and go deep. Wallow, learn, and then zoom out and say, does this make sense strategically? But I think the way to approach it, is to be part civil servant and part community organizer. So the civil servant part is being of service to a team that actually has to do something to launch: an app, to write code, to satisfy a business requirement. And part of that is actually getting your hands dirty and not floating above. It's more of, how can I help, what kind of help do you need? Here are some of the techniques and things that you might want to think about as you implement it. And then if you do it, here's the context in which it will actually benefit. Not just you, not just your customers, but the business all up.
And then as the community organizer, I can actually take what I learned from you, tag you in it so that you can get the credit and the visibility associated with what I learned and then help me synthesize and disperse that knowledge to the rest of the organization. Again, from a servant perspective, I'm successful when teams stand on my shoulders and actually do real stuff in the real world.
You have to be the friendly ball thrower once in a while. You have to be the person to keep the team on the right path. We can make alterations but still have to respect the basic requirements and can’t just make assumptions that we’re free to make any updates we want. We need to be smarter than this. Sometimes the people that are building the software either get so excited or so lost that they need the outside input to keep going in the right direction.
I consider myself to be a collaborative agitator. Hopefully in the best of ways. Sometimes I'm annoying, but it's very purposeful and it's all in service of making sure that the rocket ship that team is on actually reaches orbit and doesn't splash back into the ocean. I don't like the term of throwing lightning bolts, but sometimes if you find yourself explaining to the same people or different people and over again, then you kind of have to take the messaging to the next level.
How do you get people to listen to you?
There's two ways in which I do it. So the first is you have to kind of realize a couple things. The first is people really want to do a good job. Nobody wants to just write something and have that uncomfortable feeling like I don't know if this is going to work or not, but my name's all over this thing.
The second thing is when you're trying to affect change or influence the way in which something's going, you have to realize that it’s human nature, that people don't really make factual decisions most of the time. They make emotional decisions and then look for facts to back it up. And the way to get around that is you actually have to be willing to invest the time to help them get to a comfort state where they can listen to your points. If they're not willing to listen to your points, you might be 100% right, but that's only 50% of the battle. So you really need to get in and get them to a place conversationally or collaboratively where they're really interested in hearing what you have to say and they're willing to change their own mind. If they're not willing then you have more work to do there.
Then secondarily, once you get involved with them, you need to be in the boat with them. You can't necessarily say, do it this way and I'll check back with you in 3 months. Instead, it's what can I do to get you here, here, here and here. And again, you might only be one architect amongst a bunch of projects, but the more you can invest in that area, the better it'll be.
It can also help to bring in external evidence. If you're an internal Microsoft Architect, make sure that you have the right facts available, such as customer evidence. Or if you’re having trouble reaching people, maybe there are other people that can connect with them better.