Career

The manager called me in.
I already knew.
I’d known for weeks, in the way you know something before you’re willing to say it out loud.
The conversation was ten minutes.
The decision had already been made, by both of us, long before that.

I was in the war room at 2 AM, staring to the aftermath of what was supposed to be our next evolutionary leap.

We pushed the final piece of our cloud migration at midnight.
By 12:07 AM, 60% of our customers couldn’t log in.
By 12:15 AM, the rollback plan failed because the servers it was meant to restore to didn’t even exist anymore.

Despite the thorough migration plan, the old system was gone … extinct in a single night, and our “evolved” architecture had nowhere to run.
We didn’t anticipate the blind spots, and the post-mortem read like a crime scene report where we were both the victim and the suspect.

That’s when I realised Darwin’s theory applied to software too: Software behaves like living organisms.

So there I was, 8 years old, dragged to the shopping center by my dad because, apparently, shopping for socks is a family event. We’re walking through this temple of consumerism when—BAM!—I spot a computer showroom. Not just any computers. MSX/Sakhr machines .

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.’

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?

Most architects get pushed toward deeper specialisation over time. I went the other way, and I’ve grown comfortable with the ambiguity that comes with it.

The word “polyglot” has drifted well beyond its linguistic origins. For me, it describes an approach that values breadth over depth in any single stack.

I’ve always been fascinated and reflecting about the peacefulness and the respect that emerges when watching some masters doing their professions.
So, I spent lately some years time observing and trying to see the world through their lenses and may be, and if I’m good enough, adopt their skills and get inspired to improve myself personally and professionally.

The role of the software architect remains a subject of considerable debate: it is vaguely defined, difficult to pin down, and sometimes leads to nonsensical responsibilities in certain job descriptions.

I will not discuss here the precise day-to-day responsibilities of an architect within a team or company, but I will attempt, through my experience, to describe some of the aspects and qualities that any architect should possess.