Software architect is like a captain of football team
I am software engineer for more than 9 years. I am captain of football teams for more than 20 years. And I have experience with leading football teams and with following of various types of software architects. I am not entirely sure why I was electing as a captain, maybe for my faith, skills, charisma or there were no better person. At some point I discovered that mentioned roles have some similarities … so how to be a good architect or captain?
Some preconditions
First of all, if you would like to be a successful architect or captain you need to go as an example. If you are making some decision you need to be first follower of this decision and there is no difference between you and any other team member. Even when you have all decision rights and for you it’s easy to just override your own rules to make some thing in easier way, it’s not right. At some point your team members discover that you are giving them arguments why they might not follow your desired behavior. This rule in football I am calling it "run around the last cone in training pitch”. Which means to go over all obstackles layed out by your trainer even when you are tired, your trainer is not looking on you or you are just so without faith that this particular excercise is right for you. In my journey through several software projects I met of course several architects. And I have to say that I was running away from projects where architect was preaching water and drinking wine. One example. When all members are forced to use pull requests with code review before merging to master and you are seeing some direct commits in your master branch from programming architect, your motivation to produce high quality software is decreasing in time.
Decision making
Other than that your decisions and behavior should be understandable from broader perspective.
At some stage there are no easy decisions.
Either you are taking decisions under pressure from business, from some friend of yours or you are strong enough to take independent solution. In both cases all team members which are receivers of your points should understand your arguments and be ok with that. Ok, there can be more than one good choice at some point and only time can in some situations show if your choice was right or not. But with given circumstances at decision time you have to be sure that your choice was right for software or football team. Once I threw away penalty shoot because refree was forcing us to win but with usage of his (influenced by third-party) power and not our skills. We (I) are usually playing some minor league where is more important delight from game than results. I still believe that my own decision which I taken without any discussion with other team members was understandable for almost whole team to have clear mind and sleep well. And almost whole team was ensuring me that it was right decision.
Responsibility
Also you have to take responsibility on ourselves and in case that you were wrong raise the white flag and admit own mistake. Also do everything for removing of dependency to your bad decision and replace it with better one and/or do everything to not making same mistake again. Once my software architect was prefering some more robust common solution for some easy thing (you probably know that) to be prepared for some predicted usage in future. As we are in very frenetic times, software and feature requests are still changing. Predicted usage was never on the desk and our "easy" solution was very good starting point for next feature request. Architect was clever enough to be in first line of removal of this robust thing and was spending time above his limits to replace this solution. And I was happy to see that my motivation to work on that project have increased because working with such liable guy was just superior.
And the last thing …
If you are playing with an idea that you can be good software architect or football captain, your skills should be one of the best in the team, you need to have ability to listen to your team members, guide whole team with good strategy to desired goal and in all cases be in the front line and not drive team from trenches. In my professional career I met several architects but unfortunately majority of them were failing with in at least one mentioned thing. There are still things for improvements so time to time I am in discussion with my architects about things that in my opinion are not good from their side. And fortunately majority of them were/are listening and improved their architecture skills.
P.S. If you enjoyed reading this blog post, could you do me favor and tweet it? Thanks!