If, after quitting your job, you hear or get notified about your ex-leader doing these :

1. Speaking negatively about your departure
2. Undermining your decision by criticizing you, your new role or company
3. Attempting to make you feel guilty
4. Spreading resentment throughout the organisation
5. Taking the resignation as a personal attack
6. Prioritizing their own interests over those of the team
7. Being absent or unavailable for the team during the transition
8. Spreading gossip about you
9. Delaying or writing vague performance appraisals or recommendations for you
10. Displaying an “it’s all about me” attitude
11. Failing to acknowledge their own mistakes or shortcomings
12. Blaming others for failures or problems within the team

These behaviours scream insecurity, selfishness, and a lack of confidence in building and retaining talent. They crush team morale, erode trust, and send a clear message to the rest of the team: ‘You’re disposable too.’

Back in 2014, I was at a meeting with a prominent French bank about a challenging project. At the time, “low-code” was a fresh concept, and the bank aimed to build its own low-code IDE to let business analysts craft UIs and speed up delivery.

The team already knew each other from previous projects, so introductions were a formality. Our manager introduced everyone: “This elegant lady is the delivery manager, that serious gentleman is the team lead…”
When he got to me, the bank’s IT manager interrupted, winked, and joked, “The guy’s doing nothing!”

We laughed sincerely and moved on.

Imagine, if you will, that building a SaaS application is like constructing the perfect sports car. Sleek, powerful, a marvel of engineering.

I, of course, am Jeremy Clarkson in this scenario — the architect with the vision, the genius behind the wheel. My engineers? Well, they’re supposed to be the pit crew, precision-tuned experts ready to make my dream a reality.

“I hate and categorically refuse quick wins”, I angrily yelled.
The managers in the meeting jumped. They weren’t used to seeing me lose my zen and calm temper so often.

“I have a huge ethical problem with this organisation’s culture of quick wins. We are adding more layers of band-aids before even healing the scares”, I continued.

Being an Architect is like being a conductor¹ in an orchestra. You’re not playing all the instruments, but your job is to make sure everyone is in concert [pun intended] and that the result is harmonious.

I once saw Simon Rattle conducting 6 Berlin school orchestras playing Edvard Grieg’s Peer Gynt Suite. As a matter of fact, they never worked nor rehearsed together before. Their first play was awful and cacophonic, but after multiple corrections and rehearsals, Rattle transformed the final performance into a beautiful and majestical piece.

After a heavy lunch break with a team, Dorian, one (among others) young and competent developer, enthusiastically asked me: “How does someone become an Architect, and what’s the path to follow and what to learn to be one?”

I wasn’t asked this question for the first time, and to be honest, I was never able to answer it properly.

As I am in my late 40ies, I’ll be closing my 25th year as an IT engineer this year and my 20th year as an architect.

As I was reflecting about the journey, I wondered: Am I really a Senior or just a Vintage, a Relic?

We often tend to think that a person with considerable years of experience is usually a respected Senior (as a rank and age), but Experience in some careers is viewed as universally positive, but that’s not necessarily the case in tech.

In other careers, the craft matures. It becomes less technical and more artistic, and people gain more knowledge while effortlessly getting things done.

Lawyers and doctors are respected when they cross into their 50’s. They are held in high esteem. Tech workers don’t collectively share the same belief.

In our case, the rapid change in technologies and tools, plus the weird label that stuck to us as technology handlers, are making us prone to being obsolete in a few years, if not months.

During an after-work with some dear colleagues, one asked: “How can we define our success?”.

People started throwing answers like : by the customer’s happiness, by listing the greatest achievements, the metrics hit, by the completed tasks and goals, the career evolution or even by the gain accumulated.

Unsurprisingly, I was unsatisfied. These answers looked more like a standard pitch to succeed in an interview rather than deep thoughts.

In my opinion, one’s success can’t be measured only by corporate expectations; a career can’t be measured only by goals, achievements or accumulated wealth; a professional can’t be successful only by positive feedback or customer satisfaction.

And what about Architects, as the disgraced-and-always-blamed people in an organization ?
How can they measure their successes, especially since they only provide listening, more questions and rarely one option?

In a world where specialization is often hailed as the pinnacle of success, I find myself cheerfully perched atop the hill of ambiguity, happily wearing the badge of a “polyglot” in the tech cosmos.

This term, I’ve grown quite attached to it over the years, It’s morphed from its linguistic origins to become, synonymous with an approach that values versatility over specificity.
Yes, I’m the Architect who dances between the raindrops of technology stacks, merging them into a harmonious symphony.

Today, I’m here to share some thoughts about the unique and somewhat underappreciated role of a polyglot architect.