Is Your Center of Excellence a Trojan Horse for Social Debt?


This week, I had an interesting discussion with a client. It's a Civil Engineering corporation that's present in multiple continents. The "company culture" challenge becomes especially important when different cultures all around the globe are mixed toward a same goal. Building a globally-distributed Event-Driven Architecture is no exception.

Everywhere I look, people are trying to fix culture problems with tools. Not because they're dumb or stupid, actually, I'd have committed the same mistake if I were in their position. No blame. The issue is that oftentimes the culture problems appear as technical problems in disguise. You really need to dig deeper to understand the root of it.

However, a new kind of issue has caught my attention recently: Centers of Excellence (CoE). Let me explain...

It was years ago that I heard about CoEs for the first time. If you don't know what it is, a CoE is a team of experts that provide tools, processes, best practices, and support to the rest of the organization. Sounds good, right?

Well, it depends™️. The human brain can be is complex. If there's a CoE, the Social Comparison Theory starts kicking in:

Social comparison theory is a psychological concept that posits that individuals assess their own worth and abilities by comparing themselves to others. This theory, introduced by Leon Festinger in 1954, emphasizes that people often evaluate their qualities against those of their peers.

In other words, if there's a center of "excellence" and I'm not part of it, it means I'm less excellent than my peers in this team. If you're a junior engineer, that might be fine. In the end, when you're junior, everyone looks smarter than you anyway. However, if you're a seasoned engineer, your immediate reaction might be something like "who the heck these people think they are!" (dramatization).

Likewise, if there's a CoE and I am part of it, it means I am more excellent than my peers. Your way of communicating can be affected by this and you may end up talking to your peers in a condescending tone.

And there you go! You have a breeding ground for conflict. Please note this usually happen unconsciously. If you ask people in both sides if that's what they think, you'll get a plain and straight "NO" as an answer. Oh, if humans were that easy...

Does that mean you shouldn't have a CoE in your organization? As always, it comes down to your case but you're warned of the possible subtleties now. I'm not a psychologist. The only idea that comes to my mind is to change its name. Yeah, it might sound stupid (and maybe it is) but I think language matters. A team that should be there to serve, suddenly can be seen as tyrants —in part— because of an unfortunate name.

So, is this post about naming things? Nope. This is about minding the social and psychological aspects of adopting a new technology shift like Event-Driven Architectures. Start with people in mind first. The technology will follow.

P.S. I recently opened early access to my book Shift: The Playbook for Event-Driven Architecture Advocacy. You'll have the chance to be among the first ones to read it, at a cheaper price, and —not gonna lie— this is a big signal of support for me. Get early access to the book.

P.P.S. If you're stuck, need a second pair of eyes on your architecture, or want personalized guidance to accelerate your project, a 1:1 call can provide the clarity and direction you need. Book Your 1:1 Consultation.

1 Question For You

I'm trying to improve this newsletter. I want to make it valuable for you and, usually, I default to telling my own learnings and experiences. The reasoning is that, if it was a learning for me, it will most likely be a learning for some of you too. Anyhow, let me ask this straight:

Is there some topic you'd like me to touch on in future newsletters?

Av. Joaquín Costa, 16, Badajoz, Badajoz 06001
Unsubscribe · Preferences

Fran Méndez

Hey hey! I'm Fran, the creator of the AsyncAPI specification (the industry standard for defining asynchronous APIs). Subscribe to my newsletter —The Weekly Shift— where I share expert advice about building Event-Driven Architecture and share my journey writing my first book, Shift: The Playbook for Event-Driven Architecture Advocacy.

Read more from Fran Méndez
A puzzle

I've spent the last few weeks on over 20 calls with all kinds of companies. From tiny startups to huge enterprises. Every single one of them is wrestling with Event-Driven Architecture, trying to make sense of its promise and its messy reality. And as I listened, patterns started jumping out at me. We're not just talking about tech problems here. We're hitting the deep, human stuff that comes with a big shift like this. One story kept popping up, louder than all the others: culture. Forget...

Writing Shift is proving to be challenging to me. Not in a bad way but in a really really good way. Yesterday, in a conversation with Laïla Bougriâ, I told her that I'm writing the book for me, to learn. Obviously, I'm taking into account the target audience all the time but, even this, is part of the challenge. It's not the first time I've done this though. When I drafted the first AsyncAPI specification, I did it for me, so I could learn the ins and outs of OpenAPI and also Event-Driven...

The biggest problem with Event-Driven Architecture

This week I want to share some interesting insights with you. For the last ~3 months, I've had video-calls with a lot of people from different companies in different markets. Mostly banks, retail, and consultants. I kept these calls informal, like casual chats. I didn't want to bias anyone toward any findings so I prepared myself to run "interviews". Have a look at The Mom Test. I asked open questions all the time and, from there, followed the conversations in a natural way. I tried not to...