"Mind the architect" is a series of short articles about becoming an architect and how building the right mindset helps in that role.

Such a post on a technical blog?

The idea of Wunderman Thompson Technology tech blog is to share content created by developers for developers. It’s meant to be technical, free of fluffy speech and business language. As much as I like it, that much I’d like to write about something different. I want to give you a chance to take a breath between reading about cool coding techniques and fancy tools.

I've always preferred to know what lies outside my everyday zone of work. Peeking once or twice beyond the border of software development helped me adjusting my own work to the needs of the people who were not software engineers. Eventually I became one of them. I switched from being a developer, to a technical lead, and then to the role I’m now in - an architect.

This post begins a series of short entries about things I had to do, or realise about, in the process of becoming an architect. If you find it interesting, you’re welcome!

The opinion maker

Once you become an architect, things you say, opinions you express or recommendations you make suddenly become more widely heard and contested. It's not that as a developer or lead you couldn't say what you think, you should always be allowed to do it. It's a feature of a healthy organization or a project team when its members can freely express their opinions and thoughts. From an architect, however, it is expected to get an advice and guidance regarding a very broad set of topics. People require an architect to have an opinion. It would be nice if it was useful and valid. It would be great if architect's recommendation is trusted, respected and eventually...followed.

One way of achieving this is showing to your audience that you are not biased. That's often difficult, as all of us have some preferences because of our experience or simply the taste. But the advisory role is not about architect's preference, but the preference of the advised stakeholders you have to educate to let them make the right choices.

It’s initially a bit difficult to accept that although you have the knowledge, someone else is going to decide. Especially when you know that the choice will have an impact on your work. But after a couple of times, when challenges become tougher and consequences serious, you will find out that decision making is a full time job too. Executives, c-level officers and directors - they all exist for purpose.

Let them do their work and instead focus on the advisory role of an architect. The more you lean towards one of the options, say database vendors to choose from, the less objective you are in the eyes of the people you are supposed to help. Being perceived as a fanboy (or fangirl :) ) is something you should avoid. If you advocate a single option too much, some will think you are sloppy or ignorant. Elaborating on strengths and weakness of other alternatives will render your work unbiased and honest.

Should you be a devil's advocate at all costs? Obviously, no. Going too far on a pointless route is just a waste of your energy and precious time which someone, usually the client, pays for. The key is to share your focus reasonably equally between options you are assessing, than going too deep while exploring one of them.

So basically, what comes out of this post is to be objective and careful. Try not to allow yourself for any “plot holes”. You know, like in the films. These small logical mistakes or unreasonable hero behaviors. For example, in “The Lord of the Rings”, couldn't Frodo be taken by an eagle to Mordor right from the beginning? Not asking Gwaihir (the eagle) for a trip seems to be an unexplored option.

Putting it straight, you want people to react - “Yeah, now I see all the options, I understand them and I agree that this one is the best”. You don’t want them to point out obvious, but somehow missed options...say, the eagles ;)