This article is a report about some observations I made during my time in two different projects. Each of the projects had one architect which, in retrospect, could not have been more different compared to each other. Both of them had great technical knowledge and more than 10 years of experience in IT. Both managed a legacy project that had more than 5 years of development time / uptime. However, my perception of the two was very different. As a disclaimer I have to mention that the circumstances in which the two persons worked were very different and I think that this had a profound effect on the work performance of both architects.

Architect A - The lucky guy

The architect which I will be referring to as “A” had not only the role of the architect but coded like the rest of the developers. He worked directly in the project team and hence took part in every daily standup and every technical meeting. Also, he just managed that one project. That gave him the time to listen to new ideas of the developers, think them through and only after that decide the next step. Once the decision has been made, he strongly enforced it.

Because of his presence and the freedom in his everyday self-management (meaning the absence of phone calls every 5 minutes and other interrupts) he often took the time to read over the code of the developers when making a decision about it. I often heard the words “Well, let’s have a look at your code so I can decide what we do about it”. That way, A could easily monitor if his decisions would be respected.

Architect B - The not so lucky guy

The second architect in my story, “B”, did not code himself. His only role in the project was that of a “flying” architect because he was not constantly present in the team. In fact, I am not sure if he even had a desk somewhere. He constantly moved between somewhat around 6 projects, hence his participation in meetings was extremely sparse. Additionally, his phone rang every minute and he worked (by his own words) “on an interrupt basis”. To be fair, I have to say that he wasn’t happy with this situation at all.

Because of these circumstances, the knowledge transfer from B to the developers was often in the form of short monologues from him. Because of the missing time for discussions and long explanations, he used terms and concepts out of architecture books which the developers didn’t read. No wonder they perceived him as arrogant and shouting bullshit-bingo-words. No surprise the developers often did not respect B’s decisions and he had no instrument to monitor the implementation of his ideas. Worse, the “disobedience” of the developers generated more work for him because he had to clean up behind some code changes which made him even more time-crunched which in turn had not the best effect on his willingness to explain his decisions.

It really was not a good constellation.

Conclusion

These two persons surely are the extreme and, once again, I am not saying that they acted the way they did just on intrinsic reasons and in full awareness. But they are great to learn a thing or two: I will monitor myself and the circumstances I’m working in to avoid being that time-crunched as B. Sure, there are times when that will be the case, but it must not become a constant.